Wikipedia talk:Manual of Style/Layout/Archive 14

This is an archive of past discussions about Wikipedia:Manual of Style. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 10

←

Archive 12

Archive 13

Archive 14

Archive 15

RfC Verifiability in See also sections

I have encountered the claim that adding a link doesn't require a citation, even when WP:CHALLENGEd. (To be clear: I did not ask for an inline citation, merely that one be provided on the talk page.) Another editor subsequently claimed that MOS:SEEALSO's criterion of "editorial judgment and common sense" is among the things that go [...] beyond the verifiabilty principle.

My reasoning is that, since See also links have to be relevant, adding a link comes with the implicit claim that the linked topic is relevant to the one at hand. In this particular instance, the stronger claim was made that the linked topic is an instance of the topic linked from. Since all content must be verifiable, I don't see how See also should escape one of our pillars. That needs to be clarified here, regardless of the outcome of this RfC. Paradoctor (talk) 15:16, 23 May 2020 (UTC)

Per Nikimaria: Does "editorial judgment" override WP:V for the purpose of determining whether to keep links in See also sections challenged on the grounds of relevance?

Hi Paradoctor, if you want to start an RfC here could you please include a brief neutral question as per WP:RFCOPEN? I could infer one from your statement but it'd be better for you to make it clear. Nikkimaria (talk) 15:28, 23 May 2020 (UTC)

Actually, I'm going to remove the RFC tag. This does not seem ripe for an RFC at this time. The question is probably reasonable but we don't need all and everyone to comment on the topic at this time. --Izno (talk) 16:30, 23 May 2020 (UTC)

That's not your call. If you don't wish to comment, then don't. Paradoctor (talk) 16:48, 23 May 2020 (UTC)

Actually it is (and any one's) per WP:RFCBEFORE. Only questions which have have had previous multiple content dispute mechanisms tried, and consensus failed to be obtained, should resort to using an RFC. To boot, this is a relatively benign question. I'll remove it once more, but if you feel you must resort to an RFC on the matter, feel free to restore it. --Izno (talk) 18:03, 23 May 2020 (UTC)

Instead of asking for a "citation" consider asking for an "explanation." As Layout#"See_also"_section says: "Editors should provide a brief annotation when a link's relevance is not immediately apparent ..." That helps all readers, not just the person who asks for a citation on a talk page. (And nothing stops you from "improving rather than reverting" and adding your own explanation to clarify a See also entry.) Butwhatdoiknow (talk) 16:39, 23 May 2020 (UTC)

Oh, an explanation exists. I disagree with it, because it is speculation not supported by the literature. This RfC is about links that have been challenged, about the standard for evidence that they are, in fact, relevant. Paradoctor (talk) 16:48, 23 May 2020 (UTC)

Apparently this is a content dispute. Its specificity is to be related to the see also section. So this should be discussed in the talk page of one of the article, with notification to the talk page of the other articles, and to the relevant project(s). In case of a lack of consensus, the usual dispute resolution methods must be used. The manual of style cannot predict and avoid all content disputes. D.Lazard (talk) 17:35, 23 May 2020 (UTC)

"Very long" sections

The MOS says that "Very short or very long sections and subsections in an article look cluttered and inhibit the flow of the prose. Short paragraphs and single sentences generally do not warrant their own subheading." But is there an agreed definition of "very long"? Reviewing this article for A-class, I highlighted some sections that seemed to be "very long" (eg #Bolero—nine paragraphs) because they were over one screen length for me despite using small font, and likely to be several screens for mobile users. Is that a correct assessment of what is considered "very long"? Thanks! b uidhe 06:45, 26 May 2020 (UTC)

It's subjective, so no firm rule would be valid. --Redrose64 🌹 (talk) 09:35, 26 May 2020 (UTC)

Advice that needs changing

The page currently gives, as the last item (#9) in "Before the lead section", "Navigational boxes (header navboxes)". This is bad advice, more often wrong than right. It should either be removed completely (probably best) or considerably softened. For some years, these navboxes have proliferated hugely, as unfortunately we now have far too many editors who prefer writing these to actual sentences of text. Frankly, in a high proportion of articles they should just be removed, and an appropriate horizontal navbox used instead, where there is one. They should only be at the top of an article if there is no infobox or suitable lead image. In visual arts articles, my usual area, this is literally never the case. Yet drive-by fiddlers take the mention on this page, which I accept is cautiously worded, as justification to impose navboxes right at the top of the page, citing this policy as though it was a MOS obligation to have one. Johnbod (talk) 15:02, 27 June 2020 (UTC)

Please point to an edit that you would like to have prevented, or which you did not like. --Izno (talk) 17:58, 27 June 2020 (UTC)

Sure, this one - he is a persistent offender, always citing the policy. Or this one, from another. Johnbod (talk) 02:59, 29 June 2020 (UTC)

I absolutely agree. in 80-90% of cases these boxes are just unnecessary clutter that adds nothing to the article, however, in a small number of cases they can be useful. b uidhe 05:29, 29 June 2020 (UTC)

In those specific cases, it seems those navboxes should be outright deleted per WP:NAVBOX: There should be a Wikipedia article on the subject of the template.—Bagumba (talk) 08:41, 29 June 2020 (UTC)

I don't actually seek to have the templates deleted, I just want this page giving the impression to careless tinkering editors that the MOS says they NEED to be at the top of the article. In this case - Template:History of Dutch and Flemish painting - Art of the Low Countries is the "main article" covering the same subject. This template isn't used on that many pages, and having removed it from the top of some (putting it near the bottom), I have left it near the top of others, especially where it occupies a central space opposite the TOC, so does not reduce the more important images. Johnbod (talk) 16:20, 29 June 2020 (UTC)

Can we say something at WP:Layout#Navigation_templates about when to use header navboxes as opposed to footer navboxes? If so, what? Maybe "Avoid using header navboxes when there is a suitable infobox or lead image"?Butwhatdoiknow (talk) 18:19, 29 June 2020 (UTC)

That would certainly be an improvement, though I'd also like to see changes in the list at the top. In the list, pretty much all the other items (1-8) should be at the top, where they exist. Navboxes are very different. The list:

"....the elements (such as sections and templates) that are used typically appear in the following order, although they would not all appear in the same article at the same time:

Before the lead section
1. Short description^[1]
2. Hatnotes^[2]
3. Deletion / protection tags (CSD, PROD, AFD, PP notices)
4. Maintenance / dispute tags
5. English variety and date style^[3]
6. Infoboxes
7. Foreign character warning boxes
8. Images
9. Navigation templates (header navboxes)"

^ Discussed in 2018 and 2019.
^ Wikipedia:Hatnote § Placement.
^ These templates can also be placed at the end of an article. The matter was discussed in 2012, 2015 and 2014.

- Note that at the moment there isn't even a footnote as there is for Engvar & date format templates "These templates can also be placed at the end of an article". Generally, if smaller navboxes are needed at all, there may be many places in the article where they are best placed - for example in a section with no images. Maybe we should just add "(optional)" in the list, and "Avoid using header navboxes when there is a suitable infobox or lead image" to the section below, as suggested above. Is there approval for that? Johnbod (talk) 21:03, 29 June 2020 (UTC)

Johnbod, I don't think that navboxes necessarily have to be avoided in every case where there is a sufficient lead image, see genocide for an article that currently has a navbox and a lead image below. I would support "Avoid using header navboxes when there is a suitable infobox or a lead image that is the subject of the article". (t · c) buidhe 22:15, 29 June 2020 (UTC)

" a lead image that is the subject of the article" won't I think mean any changes in practice - "shows" the subject of the article, would be better, though likely lead to rows - how do you show genocide? Even persistent fiddlers would rarely I think put a navbox template above an image of the person in a biography. Most of the examples I see are subjects where the article subject is just an item in the navbox, not the same subject. Even so, I would have put the strong, horizontal pic at the top, leaving the navbox visible below. Johnbod (talk) 23:25, 29 June 2020 (UTC)

Agree with above..... need to distinguish the difference between an infobox vs a navigational box. Nav aids definitely should be the last thing in the lead if there at all. We have a big problem as of late of editors trying to redirect readers to other pages before they've even seen the contents of the page they are on... this can be seen in the spaming of navigational templates, hat notes and banner templates.--Moxy 🍁 22:45, 29 June 2020 (UTC)

Indeed - the genocide area does seem full of these. As well as Template:Genocide, there is Template:Genocide of Indigenous peoples, Template:Denial of Mass Killings, Template:Discrimination sidebar, and so on. Many of the articles coming off Template:Genocide have two of these in succession at the top. Johnbod (talk) 23:32, 29 June 2020 (UTC)

Fortunately for the majority of reader's (60%+ mobile viewers) just see the lead image and not the look away from this article box.--Moxy 🍁 23:40, 29 June 2020 (UTC)

I agree that two is overkill but I think one sidebar can be helpful especially on the main article. (t · c) buidhe 23:48, 29 June 2020 (UTC)

A bot to move incorrectly placed hatnotes?

I often see hatnotes placed below maintenance templates, and occasionally also below infoboxes. I'm thinking of asking for a bot to go around and move such hatnotes back up where they belong according (per MOS:ORDER and WP:HATNOTEPLACE). Does anybody think this might not be a good idea?

The main question is whether such a bot should only move a hatnote if this is going to make a visual difference, and so skip e.g. hatnotes that only have engvar templates or protection icons above them, or if it should move all "incorrectly" placed hatnotes even if this means that no changes will result in the rendered page. The former has the advantage of avoiding flooding watchlists with minor, almost cosmetic, edits, while the latter should be easier to program and would result in greater consistency in what appears in the editing interface. Thoughts? – Uanfala (talk) 23:28, 23 April 2020 (UTC)

I am for this! comrade waddie96 (talk) 12:05, 15 May 2020 (UTC)

@Uanfala: I fully support the creation of a bot; I spend a lot of time fixing these hatnotes when I see them! Of the two options you present, I support moving ALL incorrectly placed hatnotes, because part of the justification for WP:ORDER is stated as follows in WP:HNP: Text-based web browsers and screen readers present the page sequentially. Correctly placing all hatnotes would fix problems for these non-visual methods of display. — Goszei (talk) 09:07, 29 June 2020 (UTC)

Do screen readers read maintenance templates? If not, WP:COSMETICBOT ought to be observed. -- Michael Bednarek (talk) 10:53, 29 June 2020 (UTC)

Why wouldn't they? Just in case, I've just tested with one screen reader simulator on a random page, and yes, it does read out the {{refimprove}} template; and because of all the links in there, it takes a very long time doing so. – Uanfala (talk) 15:49, 29 June 2020 (UTC)

I meant those that you mentioned earlier: engvar, protection, and use-date-format, citevar. -- Michael Bednarek (talk) 01:50, 30 June 2020 (UTC)

Annotated links

Watchers here may be interested in a discussion I've started at Wikipedia talk:WikiProject Short descriptions#Annotated link template, where I've suggested deprecating use of {{Annotated link}} in mainspace. This would also require a tweak to the text in the MOS:SEEALSO section. –Deacon Vorbis (carbon • videos) 20:22, 10 August 2020 (UTC)

...or not see also...

Todays featured article is about a vaudeville performer of the 19th/20th centuries, Harry Relph. Of the links in the text appearing on the main page, 5 of them are links to featured articles.

The combined see also sections of those five articles amount to a list of five items. The reason for that trend seems to come back to the instructions on this page, which suggest a comprehensive article does not include a see also section, and avoiding any repeated use of links already used in the article.

A see also section is not an indication of an articles quality, comprehensive, good, bad, indifferent. It is a navigation tool, only. Nothing else should be of concern regarding a see also section except its value as a navigation tool.

A see also section is not a guide to unused links in an article. It is a navigation tool for a reader. No it should not simply repeat all of the links in an article, nor should it be dismissed in favour of forcing the reader to navigate by searching through the legnthy text of a branching topic.

Navigation tools are a basic element of the wider encyclopaedia, not just Wikipedia, but a key feature of pride in encyclopaedias of yesterday such as Britannica, whose navigation indexes were renowned and covered whole volumes of the encyclopaedia itself. The reason Wikipedia put Britannica out of business was because Wikipedia is supposed to be a better encyclopaedia.

Please reword this guideline so that it is supportive of see also sections, which are a fundamental and characterising aspect of this encyclopaedia. ~ R.T.G 10:27, 21 July 2020 (UTC)

We have navigation templates specifically intended for use as navigation tools. Nikkimaria (talk) 11:49, 21 July 2020 (UTC)

Except they're not visible on mobile, which is what half the readers use.—Bagumba (talk) 11:55, 21 July 2020 (UTC)

So seek to change that, rather than doubling the feature for the other half. Nikkimaria (talk) 12:02, 21 July 2020 (UTC)

Navigation templates are rarely specific to a particular article. And regarding fixing templates for mobile devices... that's been in the request system for years. As far as I recall it is an issue with the software on the end of the mobile devices themselves. ~ R.T.G 14:49, 21 July 2020 (UTC)

No, it was a deliberate design decision to reduce the HTML sent from the servers to your mobile device, which are most-usually in a low-bandwidth or low-data or both situation compared to your desktop computer. This, combined with the fact that the design of a navbox on mobile is a remaining design issue for wikis to figure out. They do not look good on the resolutions available to the average mobile device. --Izno (talk) 15:07, 21 July 2020 (UTC)

And navboxes are not visible to non-mobile casual wiki-users who do not know to hit the "end" key to find the buried navboxes. They're also not as far ranging as a See also section can be. I support the proposed change. Or, alternatively, permit a statement in See also that says something along the lines of "more related links at the bottom of this page." Butwhatdoiknow (talk) 16:18, 21 July 2020 (UTC)

Oppose any change. "See also"s tend to spiral out of control - Butwhatdoiknow's talk of "far ranging" is alarming. Templates & navboxes are also far too common - cruft that some people like to add everywhere, cluttering up pages. The category scheme is generally all the reader needs. Johnbod (talk) 16:27, 21 July 2020 (UTC)

I think we can trust our editors to keep things from spiraling out of control. Then again, I can see how someone who starts at category listings being generally sufficient can quickly become alarmed at the thought of anything in a See also section. Butwhatdoiknow (talk) 05:43, 22 July 2020 (UTC)

He, ha, really? The point, as reflected in the prejudice at FAC, is that if anything is really worth "also seeing" it would be mentioned and explained in the main article. In practice, over 50% of the links in SA sections one is cleaning up are already mentioned and linked in the text, and are removed for that reason. Johnbod (talk) 14:25, 22 July 2020 (UTC)

Precisely! Due to your efforts (and those of other editors) See also sections do not spiral out of control. Thank you for your service. While throwing the baby (useful See also links) out with the bathwater (inappropriate links) makes your job easier, I suggest it does not make Wikipedia a better resource for users. Butwhatdoiknow (talk) 16:44, 22 July 2020 (UTC)

Please don't add insult to injury. Obviously, with 6 million articles, I only edit a minute fraction - much better to argue here for a general effect. Very few SA links are actually useful, but if I think they are I leave them, or better yet, integrate them in the article. Johnbod (talk) 18:17, 22 July 2020 (UTC)

Well I interject here. All see also links are useful... or else they are not relevant to a see also section. As for "widely ranging", well I too support the idea that see also should not be wild, but that much is a simple matter. ~ R.T.G 20:32, 22 July 2020 (UTC)

(E/C) @Butwhatdoiknow, I recognize you're proceeding here in good faith, yet I don't accept your reasoning. Consider the following statement.... Due to the clean-up efforts of public highway departments and organizations like Keep America Beautiful we can repeal the anti-littering laws. That sounds sort of silly, no? To elaborate, take a random article's SeeAlso and subject it to FAR. As noted, a bunch (maybe 50%) of the links are redundant with the main text and can go away. Call those Group-A. Another bunch (let's just say 30%) are probably important ideas that would be included in a top-level summary article and so the main text needs work to pass FAR, and these links can be added to the main text with those edits. Call those Group-B. That leaves just a few that were not important enough for the main text (Group-C). Group-C is probably referenced in indexes and categories and sub-articles but doesn't make the cut for the main body. So you want to rely on users like Johnbod to clean up the litter as these things bloat up, all to include links from Group-C (which are not important enough for the main text). In my view, there is very little bang for buck here, and I'd rather just enforce existing no-littering laws so Johnbod and others can focus on other work. NewsAndEventsGuy (talk) 18:23, 22 July 2020 (UTC)

I managed to get past the superfluous and condescending "I recognize you're proceeding here in good faith ..." Compare with all due respect. But I gave up and stopped reading when you drew the false equivalency between See also entries and litter. Or, perhaps, it is not a false equivalency for you because you think we shouldn't have See also sections at all. If that is the case then I don't accept your premise. Butwhatdoiknow (talk) 23:12, 22 July 2020 (UTC)

If you extend me the same courtesy of assuming good faith, please read my entire comment and try to understand what I'm saying. I was afraid the analogy might sting, but that really-truly is how I see it, and if I could lessen the sting I would. NewsAndEventsGuy (talk) 00:50, 23 July 2020 (UTC)

No, really, you have got to stop with the introductory put downs, This time you as much as say that I am not assuming good faith on your part. Turning to the substance of your reply, let me set your mind at ease: your analogy didn't sting, Why? because I don't understand it. Please help me see why you really truly believe that See also entries (which can be good or bad) are the equivalent of litter (which is always bad). Butwhatdoiknow (talk) 06:02, 23 July 2020 (UTC)

The requested explanation can be found in the second half, that you previously said you didn't read. Further behavioral commentary is better addressed at my user talk page. NewsAndEventsGuy (talk) 11:31, 23 July 2020 (UTC)

Regarding "behavioral commentary," I accept your apology. Butwhatdoiknow (talk) 16:22, 23 July 2020 (UTC)

Okay, I've looked. I don't find that the rest of your post supports the "See also entries are litter" analogy.

Group A is "important ideas" - not litter (i.e., trash).

Group B is "not important enough for the main text" - also not litter? It's hard to tell what you have in mind to do with those, leave them in See also? Put them somewhere else? Delete them because we shouldn't have See also sections?

Group C is "referenced in indexes and categories and sub-articles" - also not litter. Assuming that indexes and categories are at all useful to the casual user (a proposition with which I disagree), the current See also text is too often used by those who remove links from See also without bothering to check whether they appear in categories or indices.

Surprisingly, you don't mention Group D, true litter. That is what I have in mind for Johnbod and others to police (and "others" includes me - it is part of every editor's job "to keep things from spiraling out of control").

But here's the real problem (again, assuming the dubious proposition that hiding things in indices and categories is an adequate substitute for putting them in See also): too many editors remove Group B and C items without taking the time to put them somewhere else. When that happens Wikipedia becomes less useful to its readers. Butwhatdoiknow (talk) 16:22, 23 July 2020 (UTC)

I could have been more clear I suppose. Group A belongs in the main text; when they needlessly reappear to clutter up the SeeAlso the redundancies are litter. Same with Group B after they are added to the article via additions to the main text. That leaves GroupC, items not important enough for the main text. If they're really relevant to the article tree, they will be linked in subarticles. So one on hand we have dubious value of including these in a See Also section for a full and complete Feature level article. On the other hand, its not fair or reasonable to rely on cleanup editors to maintain a lean mean SeeAlso with a few nonredundant links from Group C. Since there is so much opposition and we don't communicate easily I'm going to disengage until consensus on the main question requires I respond again. NewsAndEventsGuy (talk) 19:53, 23 July 2020 (UTC)

Yes, I think this discussion has run aground. The change is clearly not going to happen. Johnbod (talk) 21:12, 23 July 2020 (UTC)

User:NAEG says they want to prevent clutter of a see also section. They also say they want to prevent see also section entirely. The idea that a see also section is certain to be wild and unmanageable is pure fantasy. We already have see also across the whole site. There is no such issue. What is up for debate here is the growing trend towards removing them entirely, based on fanciful arguments such as these. If see also sections were going to be a problem... they'd already be a problem. There is no proposal for something new and experimental in this request. It is about protecting something old and intrinsic, which is being accused without basis of creating unmanageable problems. ~ R.T.G 22:20, 23 July 2020 (UTC)

They are a problem, if not a fatal one (fortunately being at the bottom of articles, which few readers ever actually reach in non-stub ones). They always have been. There is indeed something "new" in this proposal - adjusting the MOS: "Please reword this guideline so that it is [more] supportive of see also sections". This has been opposed by several editors, but no one has suggested changed MOS to be less supportive than it is now. Johnbod (talk) 00:22, 24 July 2020 (UTC)

@Johnbod: when Butwhatdoiknow talks about a farther range in see also, they could alternatively have said that navboxes are generally sibling groups only, rarely focused to a specific article, such that they can provide similar and related items specific to that particular article. What you are fearing, the opening of a floodgate, ruins that almost as much as having no see also at all. Neither should see also be depreciated, or should they be wild and unmanageable, no way. Do you know who is the best in this whole wide world at doing see also? Experts and lecturers. The value of see also has nothing directly to do with cruft at all. How about a change to the wording of the request:- "Please reword this guideline to be more supportive of see also sections, (with care not to invite lists of cruft or anything like that, only including strikingly similar and obviously related items with a view to being a short listing of enlightening tangential topics, striking and enlightening, not simply a list of sibling articles, which is what navboxes are for)" Can you do anything better than support letting the feature die, please? ~ R.T.G 08:36, 24 July 2020 (UTC)

Unclear alternative it all sounds a big vague. I would need to see some draft text, ideally via a test diff showing changes, in order to form an opinion. To me, it seems like the primary agreement-in-principle you seek is ending FAR editors' current practice of getting rid of See Alsos for featured articles. If my perception is correct and you choose to offer draft text for the MOS, please make the impact on FAR explicit in the draft so everyone understands the substantive change(s) being made. NewsAndEventsGuy (talk) 12:32, 24 July 2020 (UTC)

Some test edits, the worst possible thing to do in the middle of a discussion. The substantive change being made is clear, the depreciation of see also, referencing a guide which clearly stated no intention for changed policy. ~ R.T.G 13:28, 24 July 2020 (UTC)

"FAR editors' current practice of getting rid of See Alsos for featured articles" DING, DING, DING -we have a winner!! Now I understand why there is so much resistance to RTG's proposal: it would make it more difficult for the FAR "I hate See alsos" clique to ignore MOS:seealso policy - which does not call for getting rid of See alsos - and follow their own made-up rule. Butwhatdoiknow (talk) 15:56, 24 July 2020 (UTC)

Oppose as Johnbod says, too much "see also" is a much bigger issue than too little. We should focus on reducing these sections, not expanding them. (t · c) buidhe 16:36, 21 July 2020 (UTC)
I don't see the point of this request. MOS:ALSO neither requires see also sections, nor does it disallow them. The matter should be decided on a case-by-case basis. Calidum 16:36, 21 July 2020 (UTC)

@Calidum:The current wording can be construed to favour both, that a quality article does not have a see also section, and that links used in the article prose should not be repeated in a see also section at all. From the archives it seems that this is complained about regularly. The issue seems to have originated here, where it was complained about, and has been complained about in each talkpage archive since. The wording was changed here in 2011, specifically stipulating the intention of the edit was simply concision. If you are familiar with WP:FA and GA, they are sort of fanatical about following any and all implications in the MOS, which makes sense because they don't have time to argue there. They simply follow the guide. The see also section has gradually suffered, never so apparently as with this whole set of FAs on the main page today, which almost totally lack such a section. See also is an important navigation tool which navboxes and categories simply are not focused toward completely replacing. ~ R.T.G 18:07, 21 July 2020 (UTC)

Opposed Just days ago the OP argued the same points in the thread Talk:Global warming#Gulf Stream and general thermohaline shutdown. Although the opening post uses a different article to illustrate RTG's desired changes, and although no notice about this proposal was provided at Talk:Global warming, RTG's desired change to the MOS is precisely what the Talk:Global warming argument is all about. I oppose for reasons stated in the earlier thread, and concur with others here. Also, I appreciate RTG's research into the origins of this guideline. Apparently it has stood for nine years, despite many complaints. If it were badly broken, the community probably would have supported reform by now. NewsAndEventsGuy (talk) 18:26, 21 July 2020 (UTC)

As they have not expressed an opinion here, I will try to keep it real by quoting User:NewsAndEventsGuy from the thread they linked, an article being prepared for featured article review:- "Per the WP:MOS we don't list items in "see also" that were linked in the article body." ~ R.T.G 06:57, 22 July 2020 (UTC)

True in addition I also opined on the merits. There's no need to copy paste that whole discussion here, interested parties can follow the link to the earlier thread. NewsAndEventsGuy (talk) 15:24, 22 July 2020 (UTC)

"See also" sections are problematic as they require no sourcing to explain the connection, and can be used to suggest connections which may or may not be appropriate: see this diff in a spat over the section for a controversial BLP medium, where some editors wanted to list every other fake medium. PamD 07:08, 22 July 2020 (UTC)
PamD, a source wouldn't stop undue links. However, WP:SEEALSO already states that inclusion is "a matter of editorial judgment and common sense."—Bagumba (talk) 07:57, 22 July 2020 (UTC)
@PamD: is correct. This is probably the most problematic aspect of having see also sections. So PamD, you support depreciating see also, as an indicator of poor quality in an article, or should the guide be worded so that it cannot be construed as purposely saying that? Note: It does not purposely say that at this time. ~ R.T.G 22:30, 23 July 2020 (UTC)

We have nav templates omitted from mobile view because of pop-culture articles that are just honorably spammed with templates..like Meryl Streep#External links. Would need to change the horrible rule at WP:BIDIRECTIONAL that causes spam of this nature all over pop culture articles, as anyone can make a crap nav template and spam it all over. Before a change would happen with mobile view output we would need to cleanup lots and lots of template spamming with mass deletion from articles.--Moxy 🍁 23:51, 22 July 2020 (UTC)

Oppose, I routinely come across relatively short non-FAR articles where the See also section is a pointless reiteration of links in the article (usually quite prominent in the lead and often repeated a few times in the article body. If some narrowly focused update is needed to avoid the perception that removal of See also is mandatory for FAR, that is another matter that I care little about. older ≠ wiser 15:42, 24 July 2020 (UTC)
@Bkonrad: the request specifically supports your view. It says, "[see also] should not simply repeat all of the links in an article". ~ R.T.G 19:23, 24 July 2020 (UTC)
The request, such as it is then, is hopelessly unclear as to what change is actually wanted. older ≠ wiser 20:10, 24 July 2020 (UTC)
@Bkonrad: the text is being increasingly taken to suggest that a "comprehensive article" does not have a see also section. Also, the text is commonly taken to suggest that no link ever should be repeated in a see also section. Let's use slightly different wordings, without condoning clutter, but without further entertaining the confusing suggestion that see also is somehow a bad thing in general... ~ R.T.G 20:46, 24 July 2020 (UTC)
What specific change do you want to see made to the wording? Nikkimaria (talk) 21:12, 24 July 2020 (UTC)
The part about "some comprehensive articles do not have a see also section" has been complained about perennially, and that complaint was predicted since the very time it was shortened to its current iteration. This is also with the part which says "as a general rule" links used in the article body are not used in the see also section. This is endlessly invoked as telling us that links in the article are banned from see also, just not enforced in lower quality articles. These inferences were never intended, as the history of the guide and the talk shows. These were never instructions, but they were simply intended to be a pared down wording of the original lengthier explanations, why we do not have massive see also sections, to keep them short, concise, and relevant. I'm sorry that it is difficult to reference such sections for every article, but since when do we reference a navbox or a category? We don't. We judge what should be in them in the various ways that we do, and we should have no interest in reducing such navigation devices, except where it is not short, concise, and relevant. Quality over quantity, but something over nothing. I am going to bet that nobody has ever gone to the Village Pump or anywhere like that and said let's depreciate see also. It is totally coming from this wording where it is not intended to produce that effect, and nor should it produce that effect without a significant request at the VP. What if the sky falls down all over the place, some people seem to be saying, and youse wonder why it is difficult to make sense. What if it doesn't? What if it just stays up there forever? Anyone got an answer for that one? ~ R.T.G 22:34, 24 July 2020 (UTC)
So again, as Nikkimaria just asked, What specific change do you want to see made to the wording? Please don't repeat the basic complaint or vaguely opine about goals or ideas. We'd like to see specific proposed text changes. Alternatively, if you think FAR editors are misapplying the current MOS in a DISRUPTIVE way, you can reach out to them if that has not happened, and failing to find satisfaction you can bring those concerns to the admins or arbs. NewsAndEventsGuy (talk) 00:31, 25 July 2020 (UTC) NewsAndEventsGuy (talk) 00:26, 25 July 2020 (UTC)
Don't keep your foot on me. You are the one being disruptive. You are specifically, above all here, being purely disruptive. Your original reply here shows that clearly. You cannot wait to abuse SNOW and template with total disregard to the value of the output, which is the only thing up for discussion here. WP:BATTLEGROUND. You seem to feel like you are placeholding for editors like Ser Admantio, who in fact can most often be found going around linking, categorising, and editing see alsos and other navigation features... Disruption is not classy at all. Not even nearly. The output of the site is for the reader. Any focused effort contrary to that equates sabotage, no matter how you belittle. If you want to disrupt an argument, disrupt one that is out of control. Depreciating see also is a mistake. Please take notice of reader-response criticism. ~ R.T.G 07:36, 25 July 2020 (UTC)

I think the verbiage of the present document is fairly reasonable. It encourages editors to integrate links into the article-proper as a matter of good context for the user. It says not to duplicate links in the article or navboxes (hence, it is see also). It notes that high-quality articles may not have see also sections but does not ban them entirely from such. The repeated claims it does so are accordingly false. --Izno (talk) 00:51, 25 July 2020 (UTC)

I may have made that false claim myself, but regardless... as I understand it, the core issue here is that current practice among FAR editors is tantamount to an outright ban even though the MOS doesn't make an outright ban. NewsAndEventsGuy (talk) 01:00, 25 July 2020 (UTC) PS I just noticed that although FAR seems to be at the crux of this complaint, no one ever invited FAR to the discussion. I'm not going to do that, even though I noticed, because right now its very long, but still lacks specifics. NewsAndEventsGuy (talk) 01:04, 25 July 2020 (UTC)

The article prostate does not have a see also section. Cancer does not have a see also section either. Human... does. Life... has a see also section. Often when we see that an area of subjects are mostly being looked after by editors who appear to be experts, we are comforted. Oh... the experts have come home and found a place, and it is going to turn out with such high quality... except.. it gains the air of quality, but when whole areas are aloof it is a comparative. They are distant from everything else, or as they say in "the west", inaccessible. Medicine, politically charged topics, mathematics, and several other large genres... are all pared down this perception of high quality everything, but dissemination becomes a neglected topic. The best encyclopaedia can be disseminated by a child from top to bottom, and is popular for no reason other than how well it disseminates. Depreciating see also, or worse, allowing it to be depreciated, is a mistake for the wider encyclopaedia. See also should be restrained, but not smothered. Any widely branching article which does not have a see also section is out of sync with the building of an encyclopaedia, and if a range of such articles do not have see also, something is wrong here in the guidelines. See also helps disseminate. Removing see also removes that with no genuine replacement available. ~ R.T.G 17:57, 31 July 2020 (UTC)

Comment for clarification, A well chosen and sufficiently annotated set of "See also" links can be useful to the reader as a navigational aid. A person looking up a topic will not always know the most useful search strings for related matter, or the strings they know may not be represented in Wikipedia - more so in the case of article titles, so a search may fail to find the desired information even when it is present because the user did not think of the right search string. Titles which exist in Wikipedia can be listed in See also, linking to articles that do not exist is not a useful navigational aid, though some redirects to sections could be useful.. The section links should be restricted to topics which lead the reader to information they are likely to be looking for when they visit the page. This can include highly relevant topics already linked in the text, and topics that are not already linked in the text, including some which may be in a navbox, but should not include trivia, excessively tangential topics, and links used merely as explanations of terminology (such as may be needed in the body text for clarity). It should be clear what connection the linked topic might have with the containing article, so bare links are often not useful. Navboxes connect a group of related topics in one way, but all links in the navbox are necessarily part of that group described by the navbox title. See also is specific to topics related to the article in which they are listed, like having a specially focused navbox tuned to the article. There will often be an intersection between the topics in a navbox and those in a see also section, and possibly also in a category, but each serves a different purpose, and in the general case, there will be differences.· · · Peter Southwood ^(talk): 08:32, 15 August 2020 (UTC)

That's not really clarifying anything.... do you think we need to change the wording of the MOS, and if so, what new wording do you propose? NewsAndEventsGuy (talk) 20:35, 15 August 2020 (UTC)

Discussion related to application of MOS:SEEALSO

I've started a discussion at WT:Songs relating to advice given here under MOS:SEEALSO, so it's seems appropriate to post a notification here. Any interested editors, please weigh in at WT:SONG#Inclusion of charts-related lists in "See also" sections. JG66 (talk) 11:45, 26 August 2020 (UTC)

DISPLAYTITLE

So, about {{DISPLAYTITLE}} (and, for that matter, probably {{Italic title}} as well) ... where in MOS:ORDER should it go? I came to this page trying to find out where it goes, and did not find the information which I sought. My common sense tells me {{DISPLAYTITLE}} belongs directly above or below {{DEFAULTSORT}}. Steel1943 (talk) 06:19, 20 August 2020 (UTC)

On a technical level, it doesn't matter, unless two are present. Bear in mind that some infoboxes - such as {{infobox book}} - contain a DISPLAYTITLE which will override one placed earlier on the page.

On a conventional level, it's usually at or near the top, because it affects the page title which is earlier than anything else. Sometimes it's near the bottom, where the usual position is between the navboxes and the DEFAULTSORT. It really shouldn't be placed between DEFAULTSORT and the cats, because they are very closely related and convention is to put them together. --Redrose64 🌹 (talk) 21:46, 20 August 2020 (UTC)

I get what you mean, and I realized there was something I forgot to state: I think that at the minimum, the DISPLAYTITLE should be placed after any infoboxes. It seems that any title formatting forced by any string of code in the infobox can only be overridden by DISPLAYTITLE, in most cases, if the DISPLAYTITLE is placed after the infobox. My assumption on this is that the last-called formatting to the title is the one that gets precedence. Steel1943 (talk) 22:22, 20 August 2020 (UTC)

This was talked over in this 2014 discussion. – Uanfala (talk) 00:44, 21 August 2020 (UTC)

The previous discussion didn't get any further than we have here. I did some sandbox experiments. You get a red error message in the rendering if you override with {{DISPLAYTITLE}} or {{italics title}} or whatever more than once. Yes, the last override is in effect but, because of the ugly error message, its not something anyone will want to do on purpose. Even if hidden in an infobox or other template, there should be only one. It doesn't matter where it is. If it is not hidden, we should give direction on where to put it. I suggest, since it pertains to the title at the top of the page, it should go between {{Short description}} and hatnotes. ~Kvng (talk) 15:50, 29 August 2020 (UTC)

I agree that there should be a preferred place, and I agree with Kvng's logic, that that should be at the top of the page. Debresser (talk) 15:52, 19 October 2020 (UTC)

Semi-protected edit request on 15 December 2020

This edit request to Wikipedia:Manual of Style/Layout has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

I would like suggest that the Tetrahedron Paper below be added as a general reference for beta elemene: (-)-trans-β-Elemene and related compounds: occurrence, synthesis, and anticancer activity July 2009Tetrahedron 65(27):5145-5159 DOI: 10.1016/j.tet.2009.04.062 BetaElemene2020 (talk) 19:46, 15 December 2020 (UTC)

Not done: this is the talk page for discussing improvements to the page Wikipedia:Manual of Style/Layout. Please make your request at the talk page for the article concerned. ‑‑ElHef (Meep?) 20:06, 15 December 2020 (UTC)

"See also" section at Edit count

There is currently a discussion whether the article Edit count should have a "See also" link to Wikipedia:List of Wikipedians by number of edits. Input is welcome at Talk:Edit count#Project link. – Uanfala (talk) 19:39, 25 February 2021 (UTC)

LAYOUT needs some conforming updates to match WP:MOS#Section_organization

FYI

– Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:Manual of Style/Archive 221#"Section organization" section updated; conforming work needed at LAYOUT

Some updates need to be made here at MOS:LAYOUT, since this this page is the expanded version of WP:MOS#Section organization. — SMcCandlish ☏ ¢ 😼 10:22, 23 November 2020 (UTC)

As a preliminary matter, I wonder whether changes should first be made here and then WP:Manual_of_Style#Section_organization conformed to those changes rather than the other way around. That quibble aside, what prevents you from making the updates you believe are in order here? Butwhatdoiknow (talk) 15:50, 23 November 2020 (UTC)

A1) The main MoS pages takes precedence over its subguidlines. Major changes (even if they are just updating to match reality and not changes of underlying "rules") are better implemented there first. A2) I don't have infinite time available for this stuff; while I'm probably the principle maintainer of many MoS pages (responsible for most major merges, etc., over the last several years, and I likely do more "policing" of WP:POLICYFORK problems in them), others are certainly welcome to step up and help. :-) — SMcCandlish ☏ ¢ 😼 04:15, 4 April 2021 (UTC)

Here's a copy-paste of what I posted over at the main MoS talk page (where it met with zero push-back, and eventually archived):

I've updated WP:Manual of Style#Section organization (the main MoS page's summary of WP:Manual of Style/Layout) to account for things like {{Authority control}}, {{Short description}}, sister-project link templates, sidebar navigation, disuse of "Bibliography" as a section heading, etc. Looked like this material hasn't been substantively updated in several years. It was also confusing that this section said a whole lot about the lead, and a whole lot about all the "appendix" stuff that goes after the main body of content, but nothing at all about pre-lead elements like hatnotes and cleanup/dispute banners.
The main page for this at MOS:LAYOUT also needs some conforming updates. Both pages are important, as newer users are apt to read the main-MoS summary section, since various welcome templates direct them to the main MoS page as a major guideline, while old hands are more apt to refer to MOS:LAYOUT, knowing that it exists and has all the fine-grained details about layout (or, rather should – thus the need to update).
A minor quibble: LAYOUT says that the rationale for putting {{Authority control}} where it goes is that it's metadata. Yet the RfC on where to put {{Short description}} rejected that as a rationale to put it down there with other metadata where it used to live, or even after navigation hatnotes. So, that pseudo-rationale should be removed; it's perfectly fine for {{Authority control}} to go where it goes simply as an arbitrary decision by the community, just as with {{Short description}}, without LAYOUT trying questionably to explain it.

I think that makes it pretty clear what needs updating. And, yeah, I would probably get around to it eventually if no one else did, but this already dates to over four months ago. — SMcCandlish ☏ ¢ 😼 04:14, 4 April 2021 (UTC)

Proposed edit to See also

This edit request to Wikipedia:Manual of Style/Layout has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Edit1:

In the MOS:NOTSEEALSO section, replace the following

link to pages that do not exist (red links),

with the following

link to pages that do not exist (i.e. no draft article exists^note1 and there is a red link),

or

link to pages that do not exist (i.e. there is a red link without a draft article linked to it),^note1

Justification:

Benefits and rationale are self-evident in the note added to the proposed edit itself. See detailed justification here. Similar concerns have been already documented by numerous other editors Wikipedia:Why Wikipedia is not so great, my proposed edit mitigates some of those concerns.

Thanks. 58.182.176.169 (talk) 06:29, 7 January 2021 (UTC)

Not done for now: please establish a consensus for this alteration before using the {{edit semi-protected}} template.—Bagumba (talk) 15:34, 7 January 2021 (UTC) See Wikipedia:Edit_requests#Planning_a_request. Butwhatdoiknow (talk) 17:25, 16 January 2021 (UTC)

I am ignorant regarding Draft space articles. If you link to them do they show up as a red link? Butwhatdoiknow (talk) 17:25, 16 January 2021 (UTC)

I figured it out: they don't. I've edited the article to clarify that the See also section can link to draft articles. (If the draft is later deleted without being created in the mainspace then the red link will be subject to deletion as well.) Butwhatdoiknow (talk) 18:44, 16 January 2021 (UTC)

Non-existent pages in Draft: space are no different from non-existent pages in any other namespace - a link to one of these will show up red, e.g. Draft:New York City. --Redrose64 🌹 (talk) 21:22, 16 January 2021 (UTC)

Thanks. Similarly, a page that exists in Draft: space will appear as a blue link, which (I think) solves the problem the original poster had. Butwhatdoiknow (talk) 03:45, 17 January 2021 (UTC)

Our live articles should not be linking to draft-namespace or user-namespace drafts as "See also" material or otherwise. This is material that has not been vetted by the community, and is most often rejected, frequently because it contains copyvios, extreme PoV pushing, advertising, fringe or other nonsense, or is just incompetently written. If someone feels confident that a draft will soon be approved, then just red-link the expected target mainspace page name it will live at, and then it will no longer be a red link when it is approved. If it is never approved, then it is still a red link that will encourage article creation, and we should eventually end up with an article there; or someone will remove the red link eventually because it wasn't actually a viable article subject to begin with. — SMcCandlish ☏ ¢ 😼 04:21, 4 April 2021 (UTC)

"Body," "contents," or a name to be named later?

In the Order of article elements we refer to the lede, table of contents, and segments before "Works or publications" collectively as the body of an article and the segments that appear after the table of contents and before "Works or publications" as the content. Another editor suggests that "body" should refer only to the segments between the table of contents and "Works or publications."

(1) Should we change "content" to "body"?

(2) If we should, what should we call the lede, table of contents, and segments before "Works or publications"?

Butwhatdoiknow (talk) 17:13, 16 January 2021 (UTC)

Butwhatdoiknow, "content" and "body" can mean different things to different editors. We should avoid both of these terms where they could cause confusion. "Lead section" is an example of an unambiguous term that can be used instead. It may take some rewriting to explain things using unambiguous terms but I think the effort is worth it. ~Kvng (talk) 16:54, 18 January 2021 (UTC)

Kvng (and anyone else who wants to weigh in), what unambiguous term do you suggest to replace "body" as the collective label for the part of an article consisting of the lead section, table of contents, and segments before "Works or publications"? "Substance" maybe? "Subject matter"? "Topic matter"? Something else? Butwhatdoiknow (talk) 19:40, 18 January 2021 (UTC)

Butwhatdoiknow, I beleive this is the change under discussion. In this case "lede section" lets us avoid ambiguous terms. Other solutions would be required in other cases. ~Kvng (talk) 21:20, 18 January 2021 (UTC)

Kvng, my bad. Sorry I haven't been clearer. Here's the problem I'm trying to fix: later in Order of article elements (a) the word "body" refers to the part of an article consisting of the lead section, table of contents, and segments before Works or publications and (b) the word "content" refers to the part consisting of the segments below the table of contents and above Works or publications. It seems to me that, whatever we do elsewhere, we should make the effort to be internally consistent in the Order of article elements section of this page.

You reverted my edit saying, in part, "I think of the body as following the lead." It seems to follow that we should change "content" in Order of article elements to "body." So far so good. But what should we change "body" to if not "content"? Or should we come up with new unambiguous terms for both? Butwhatdoiknow (talk) 03:40, 19 January 2021 (UTC)

Butwhatdoiknow, when I said, "I think of the body as following the lead" I meant that literally. I'm not claiming to be Right but I would claim that there are other editors are likely to share this POV. So, yeah, we need to look for unambiguous ways to identify different areas of an article. This is not something I'm going to spend time on but I will keep this on my watchlist and pipe up if I see changes that are making things worse. ~Kvng (talk) 14:39, 19 January 2021 (UTC)

Kvng, do you have any objection to going ahead and, for now, switching "body" and "content" where they currently appear in Order of article elements? Butwhatdoiknow (talk) 15:23, 19 January 2021 (UTC)

Butwhatdoiknow, I'm a little bit lost at this point so why don't you go ahead make the changes, and I and other watchers of this page will review them. ~Kvng (talk) 14:42, 22 January 2021 (UTC)

Kvng, are you okay with changing "Before the lead section" to "Before the article content"? Butwhatdoiknow (talk) 22:34, 25 January 2021 (UTC)

Butwhatdoiknow, "Before the lead section" is less likely to be misunderstood. What does "Before the article content" have going for it? ~Kvng (talk) 22:53, 25 January 2021 (UTC)

Kvng, I will go with you so far as to say that, in isolation, "Before the lead section" is more meaningful. But the phrase does not appear in isolation. It appears as part of a list of article elements. And the very next heading at the same level in that list is "Article content." With that in mind, "Before the Article content" is equally clear - or perhaps more because it coordinates with the title for the next clump of article elements as opposed to the indented title below "Article content" that refers to only one element.

The use of "Article content" in the "Before the ..." line has the added benefit of harmonizing with and giving more substance to the "Article content" label that Layout now attaches to the lead, table of contents, and body elements of an article. Butwhatdoiknow (talk) 06:15, 27 January 2021 (UTC)

Butwhatdoiknow, I'm lost again. Why don't you go ahead make the changes, and I and other watchers of this page will review them. ~Kvng (talk) 15:34, 28 January 2021 (UTC)

Change made. Here it is in context: Wikipedia:Manual_of_Style/Layout#Order_of_article_elements. Butwhatdoiknow (talk) 15:42, 28 January 2021 (UTC)

I don't like it. I think agreed ambiguity is worse than supposed disharmony. ~Kvng (talk) 15:16, 31 January 2021 (UTC)

We do not have an agreed ambiguity. I say (above): "'Before the Article content' is equally clear - or perhaps more" so in context.

I gather we also disagree that referring to "article content" at the label level for the first list of article elements is more consistent (harmonizing) with the use of "article content" at the label level for the second list of article elements.

That brings us to my third rationale: "giving more substance to the 'Article content' label." Recall that we changed "Body" to "Article content" to accommodate your preferences. Now that we have done that it seems appropriate to do what we can to make that term less ambiguous by using it in context when possible. And there is no more "in context" placement than the point just above where the term is defined by the list of elements that follows it. Butwhatdoiknow (talk) 16:45, 31 January 2021 (UTC)

A common phrase is "the main body of the article", and it means the article content per se below the lead, and usually includes the citations, but generally isn't inclusive of see also/further reading/ext. links, nav templates, infobox, succession boxes, and other meta material. "Content" is rather too vague, and we usually mean that in a way that is inclusive of the lead. — SMcCandlish ☏ ¢ 😼 04:24, 4 April 2021 (UTC)

Question about "See also" wording and possible changes

Greetings and felicitations. Regarding this sentence:

"Other internal links: {{Portal}} and {{Wikipedia books}} links are usually placed in this section."

I note that the {{Wikipedia books}} template is currently deprecated. Should mention of it be removed, or the sentence altered to mention removing the template where from "See also" section where it still exists? —DocWatson42 (talk) 16:02, 24 February 2021 (UTC)

I have no objection to removing books....William, is the complaint department really on the roof? 16:08, 24 February 2021 (UTC)

Hmm. This is not actually marked deprecated, it's marked historical. But it's not clear why, since WP:Books itself is not. There seems to be an error here (though I'm not sure in which direction it runs). — SMcCandlish ☏ ¢ 😼 04:26, 4 April 2021 (UTC)

Changing the location of GA and FA icons

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

There's consensus to edit the guideline so that it recommends placing the icon templates at the top of the article, after hatnotes. (non-admin closure) (t · c) buidhe 06:01, 1 May 2021 (UTC)

Related: User talk:Some Dude From North Carolina#Good article, Wikipedia:Administrators' noticeboard/Incidents#Beyond My Ken disruptively editing --Redrose64 🌹 (talk) 19:23, 20 April 2021 (UTC)

Currently, {{Featured list}}, {{Featured article}} and {{Good article}} (where appropriate for article status) is listed as point 5 under "end matter". Instead, it should probably be as part of "Before the article content". Currently, the bot that adds GA icons doesn't follow the MOS and instead places them at the start of the article. Additionally, it doesn't make much sense to have these icons at the opposite end of the article as protection icons, given that they're both... icons. Elli (talk | contribs) 11:12, 20 April 2021 (UTC)

Support Most of the good article ones are at the top and it makes life a bit easier when doing maintenance. Aircorn (talk) 11:28, 20 April 2021 (UTC)
Support. I'd place them between MOS:ORDER 1.2 (hatnotes) and 1.3 (maintenance tags). If an article has passed one of those rigorous reviews, let's advertise the fact to readers and editors to show what our best articles look like (and to discourage minor tinkering). Narky Blert (talk) 11:31, 20 April 2021 (UTC)
@Narky Blert: As far as advertising the fact to readers is concerned, it doesn't matter whereabouts in the page source the {{good article}} etc. tags are placed, because the template is expanded to
```
{{#tag:indicator|[[File:symbol support vote.svg|20x20px|link=Wikipedia:Good articles||This is a good article. Click here for more information.]]|name=good-star}}[[Category:Good articles]]
```
The #tag:indicator here shows that the MediaWiki software converts them into indicators, which are always displayed in the same place (immediately before the page title) regardless of where they occur in the page source. There's a category too, which in similar fashion will always display in the box at the bottom regardless of the place it appears in the source. So, an argument could be made that {{good article}} should be at the bottom of the page source, to be with the categories. --Redrose64 🌹 (talk) 19:07, 20 April 2021 (UTC)
True. But notifying other editors is best done at the top. Narky Blert (talk) 19:40, 20 April 2021 (UTC)
Stuff that appears at the top when viewing the article should be at the top of the edit box, where else would you try to look for it? {{good article}} should be right there with the protection templates. I have no idea why the MoS says otherwise, but had not even been aware that the MoS contradicts standard practice in this particular issue. —Kusma (𐍄·𐌺) 12:09, 20 April 2021 (UTC)
Support move between hatnotes and maintenance tags. Some Dude From North Carolina (talk) 12:20, 20 April 2021 (UTC)
Support per nom and my comments at ANI. Vaticidalprophet 12:38, 20 April 2021 (UTC)
Support I see no logical reason to put it at the bottom. Argento Surfer (talk) 12:39, 20 April 2021 (UTC)
Oops, didn't check the talk page before. Mea culpa. De facto (due to having boldly removed it) support as lacking any logical reason to be at the bottom of the wikitext when it is at the top of the article. And to avoid MEATBOT behaviour about it. RandomCanadian (talk / contribs) 15:16, 20 April 2021 (UTC)
Its been restored while discussion is ongoing, which is fair enough. Aircorn (talk) 18:56, 20 April 2021 (UTC)
Comment - Here are some related readings I found in the archives. A few years back talking about the relation of position and Legobot.[1] Then a little over a year ago talking about what should go at the bottom.[2]. Finally the note on the actual good article documentation.[3] PackMecEng (talk) 22:25, 20 April 2021 (UTC)
None of these seem to list a reason for why the template would go at the bottom, and I find some comments from a couple of users about them being logically at the top. But yes the template documentation will need changing, I assume. RandomCanadian (talk / contribs) 23:24, 20 April 2021 (UTC)
Support: Just makes sense, and makes finding the template easier. Already how it is in most articles anyway. — Berrely • ^Talk∕_Contribs 06:17, 21 April 2021 (UTC)
Support: Just like the protection templates (which just placed 1.2 (hatnotes) and 1.3 (maintenance tags)), this makes the life easier and to prevent bot-like edits. Chompy Ace 08:24, 21 April 2021 (UTC)
Support per above supports (nothing left to add to the discussion). Mjroots (talk) 15:19, 21 April 2021 (UTC)
- This seems eligible for a SNOW close, then? RandomCanadian (talk / contribs) 17:20, 21 April 2021 (UTC)
As long as people aren't explicitly editing solely to move them around merely because a style manual says so, and the guidelines aren't ridiculously over-specified. I don't find arguments about the wikitext too compelling, simply because in my experience of clicking the edit button there is quite a lot of wikitext for templates at the tops of articles and the exact placement of all of these "must see" items, when they are all vying for primacy, is going to be a never-ending argument. ☺ Per Wikipedia talk:Manual of Style/Layout/Archive 13#Nothing should go between navboxes and authority control, the "crap that displays at the top" is logically placed near to the top of the wikitext. But that means that you've entirely forgotten about {{lowercase}} and its ilk. ☺ Uncle G (talk) 21:04, 21 April 2021 (UTC)
Support per the above comments. Sea Ane (talk) 14:18, 27 April 2021 (UTC)
Oppose really at this point only a moral oppose given the above but I'll chime in anyway.
I find the arguments to the effect of "A bot is doing it so it must be right" unconvincing, and actually nocuous. In theory bots shouldn't be doing anything that doesn't have consensus, but in practice it happens, sometimes to the degree they need to be blocked. The solution is to fix or deactivate the bot, not just comply with the operator's whims.
More substantively, the area above the lead is already cluttered. I mean what's next? Should we place defaultsort up there by default? Categories? Anyway, these icons don't need to be added or removed often; mostly they just get in the way and require more scrolling. I'll add, and this opinion will be very unpopular, that my assessment is the same for stylevar maintenance templates (e.g. datevar, engvar etc.) and protection icon templates. Maybe when protection icons were manually added/removed it made sense to place them at top to speed things up, but now IIRC it's all automated, and so that placement is no longer helpful. The fact that we started doing things a certain way doesn't mean we have to keep doing things a certain way for ever. Even with short descriptions I'm somewhat on the fence, unconvinced that top is best, but at least there the intuition behind the placement makes some sense.
I'll admit that this mostly comes down to personal preference some people like the wikitext to be just so in one way, and some to be just so in another. What aids my workflow will impede someone else's and vice versa, but we need some standard however arbitrary to tamp down on endless fiddling. I prefer things at the top clean and uncluttered but YMMV, and let's be honest I edit so little these days it doesn't matter much for me personally, and if the MOS says to place something there I'll place it there even if I think it's not best. Our readers, of course, don't care since their experience is not affected one iota by the layout.
Which brings me to my next point. All of these changes are cosmetic. There is almost never a good reason to make a cosmetic edit. Whichever style gets settled on don't go around changing things unless a non-cosmetic change is also being made. Can easily be bundled in with genfixes if that will speed things along. And don't get to hung up on details that are ultimately just trivial. Hopefully someone finds some part of this helpful. Regards, 31.41.45.190 (talk) 15:48, 28 April 2021 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I have just changed the page, placing the FL, FA, GA templates immediately after hatnotes, per User:buidhe's close. This puts them before protection tags, although the discussion and close do not seem to explicitly say it has to be that way. It seems reasonable (to me) that somebody might want to move the templates to after protection but before Maintenance. That would arguably be in keeping with the close (they're still "after hatnotes") and wouldn't necessitate another RfC, IMHO. But maybe User:buidhe or somebody disagrees. — JohnFromPinckney (talk) 12:59, 1 May 2021 (UTC)

Yes, I think either placement would be consistent with the discussion and the close. Most participating editors did not specify exactly where they thought the icons should go, mostly focusing on at the beginning/at the end of the article. (t · c) buidhe 16:30, 1 May 2021 (UTC)
Just a reminder to all: reordering templates takes up time for people reading their watchlist, is cosmetic so that it has no affect to readers (and almost none to editors), and is a waste of your valuable time which could be spent doing one of the hundreds to thousands of important tasks we have backlogged. Two suggestions: (1) WP:CCI; (2) assessing unassessed articles by quality and importance. — Bilorv (talk) 13:46, 6 May 2021 (UTC)

Discussion at Wikipedia talk:Manual of Style § Do explanatory footnotes go before or after references?

You are invited to join the discussion at Wikipedia talk:Manual of Style § Do explanatory footnotes go before or after references?. {{u|Sdkb}} ^talk 15:46, 9 May 2021 (UTC)

3.1 Works or publications

Should this bit be taken to mean that no other sections can appear between the "Works or publications" and "See also"? For example, "Awards" in an artist's biography is a possible section that seems logical to place after a listing of creative works. If this instruction actually just means that "Works or publications" should never be below "See also", it should be amended as such (where does the consensus stand here?). — Goszei (talk) 03:47, 15 May 2021 (UTC)

I don't read it that way (your opening question). I consider the page as mostly guidance on ordering, then form and content. For film and TV artists, directors, etc., we do typically have an Awards table after Filmography but (naturally, at least for me as longtime Wikipedian) before See also. The section already says "Publications", "Discography", or "Filmography" are occasionally used where appropriate;...~~, perhaps we should include something like ...used where appropriate (possibly including an "Awards" table);...?~~. The Specialized layout section does point to the Film and Television pages, but they seem to be about films or shows/series (not biographies) and don't actually prescribe such a table anyway, instead suggesting an "Accolades" or "Reception" section. I guess if you want something more explicit in the "See also" section section about it always being the last bit (when present) before Notes/References, you could add that. I don't feel a strong need but maybe I've just become acclimated to WP custom more or less implicitly. — JohnFromPinckney (talk) 12:19, 15 May 2021 (UTC)

Naw, scratch that bit about "including Awards". — JohnFromPinckney (talk) 12:21, 15 May 2021 (UTC)

Putting aside wp:Ignore all rules, I take 3.1 to mean that, "for biographies only," "Awards" are part of the "article content" and "Works" are part of the "appendices." Possible rationale: an uncurated list of an author's work is dangerously close to a directory and, hence, should not appear as part of the article content. Whatever the actual reason, as explained at the footnotes to "3. Appendices," this ordering is unlikely to change even if your approach is a better one. Butwhatdoiknow (talk) 16:02, 15 May 2021 (UTC)

empty sections

If I want an article expanded in a certain fashion, can I create an empty header for that content and then simply add an {{empty section}} template? — Fourthords | =Λ= | 12:34, 14 May 2021 (UTC)

You can give it a try. If the work doesn't progress, another editor may rightfully revert. ~Kvng (talk) 13:58, 18 May 2021 (UTC)

Columns in body

What do you think about the potential utility (and appropriateness) of columns with template-formed sections in an article? (Example -- I tried it here to make the arguments easier to follow and compare.) It doesn't affect how the page displays on mobile resolutions. — Alalch Emis (talk) 19:33, 16 June 2021 (UTC)

If Layout doesn't prohibit this and the editors of the article think it improves the presentation then who am I to object? Butwhatdoiknow (talk) 01:00, 17 June 2021 (UTC)

Portal bar and authority control

Given the updated look of Authority control looking more like navboxes I feel like it would make sense to switch the recommendations for the order of AC and portal bar. Is there any good reason for this order or does my proposed change sounds good? --Trialpears (talk) 21:09, 13 July 2021 (UTC)

I would suggest instead we have portal bar up with portal. Nikkimaria (talk) 21:38, 13 July 2021 (UTC)

Nah, {{portal}} is a right floating box which need to go at the top of a section not to look weird. Portals are lower priority than navboxes and hence we shouldn't put them above the navboxes. --Trialpears (talk) 21:41, 13 July 2021 (UTC)

Why would it make sense to put them in different sections depending on formatting? Nikkimaria (talk) 00:50, 14 July 2021 (UTC)

Because they look very different. {{Portal}} should go at the top of "See also", if present. That's the current advice and doesn't need to change. If there is no "See also", {{Portal bar}} should go to the bottom. The previous advice, placing it above {{Authority control}}, seems now odd, and I agree that it probably looks better below. -- Michael Bednarek (talk) 03:03, 14 July 2021 (UTC)

Disagree - it makes more sense to have internal links before external, and therefore both portal and navboxes before AC. (Looking at the archives, I note there has previously been arguments to put navboxes into See also as well). Nikkimaria (talk) 13:28, 14 July 2021 (UTC)

Generally I agree with that, but in this case we're talking of like half a centimeter. The internal links also have significantly more visual prominence as well. --Trialpears (talk) 22:59, 14 July 2021 (UTC)

Just to make it easier to visualize the proposal: Here's an example of the status quo and proposed change using real templates.

Status quo

Proposed change

--Trialpears (talk) 23:04, 14 July 2021 (UTC)

Alternate

Or we could take out the icon to reduce prominence? Nikkimaria (talk) 00:13, 15 July 2021 (UTC)

Of the three examples, the one with the portal bar in the middle just looks weird, the other two are much more aesthetically pleasing. Putting the portal bar first is logical, since they are internal links. So it's Alternate for me. --Redrose64 🌹 (talk) 09:14, 15 July 2021 (UTC)

Putting it first is definitely better than in the middle, but I still think last is preferable since now it has significantly higher prominence than the navboxes which I would imagine are more useful to readers. --Trialpears (talk) 09:23, 15 July 2021 (UTC)

Status quo - This is the most logical ordering. The fact that it looks "strange" should be addressed by changes to {{portal}} not reordering. The Alternate proposal makes it look like the navbox and authority are subsections of the portal. The Proposed change separates sets of internal links with authority information. ~Kvng (talk) 15:15, 18 July 2021 (UTC)

Clarification: DISPLAYTITLE

{{DISPLAYTITLE}}, {{Lowercase title}}, {{Italic title}}, and {{Italic dab}} do not appear to be covered within MOS:ORDER. Where should they go and should this be stated explicitly in the guideline? IceWelder [✉] 15:19, 22 July 2021 (UTC)

Prior discussion here. MB 15:30, 22 July 2021 (UTC)

The older discussion does not appear to yield a definite answer. The notion there (as well as this 2014 discussion) is that it should be close to the top of the article. I would boldly suggest that we place it in second place (after Shortdesc). IceWelder [✉] 14:29, 2 August 2021 (UTC)

No, navigational hatnotes have to go before everything except the Short Description, for the benefit of screenreaders etc.

I think either before or after Engvar/Dateformats would be best. PamD 20:13, 2 August 2021 (UTC)

@IceWelder: The point about a manual of style is that it describes how to achieve the best experience for the reader. The order of things like hatnotes, maintenance templates, infoboxes etc. does affect the reader experience; however, the position of the DISPLAYTITLE has almost zero effect on the reader experience. I say "almost" because there is one situation that I know of where the reader experience may be affected: if a DISPLAYTITLE is placed between two banners (such as a {{pp-vand}}, maintenance templates etc.) the border between them may appear double-thickness, or may have an actual gap (it depends upon the browser). Most people won't notice this extra-thick line, so we don't make a big thing of it. --Redrose64 🌹 (talk) 20:15, 2 August 2021 (UTC)

@Redrose64: But it makes life easier for editors if they know where to find a particular element within the article, and that leaves those editors more time and energy to improve the encyclopedia for readers. So it's helpful to have a defined place for everything. PamD 20:27, 2 August 2021 (UTC)

PamD, testing this in my sandbox, title modifications do not appear to make any difference to the generated HTML code (apart from the revised title and some metadata), meaning it would have no impact on screen readers. Due to their nature of use, I would place them as high as possible. As said before, I would prefer the second spot. However, if you still think it creates a screen-reader issue (maybe your tests yielded different results), I would put them just after the hatnotes. They belong before article icons, as these logically come after the title. IceWelder [✉] 06:17, 3 August 2021 (UTC)

@IceWelder: See explanation at WP:HATNOTEPLACE. Because a hatnote helps the reader who has landed on the wrong page, it needs to be at the top (bar SD) to save the screenreader-user's time and help them get to the other article which is what they need. Beyond that, it seems to me that the tags which affect the whole article logically come first, then the tags which only affect the article title ... in fact I've changed my mind from previous post, the title tags should come after Engvar and Date format, which affect the whole article. PamD 06:57, 3 August 2021 (UTC)

Looking at the list again, I don't see why the language maintenance templates come after the Infobox. They should be listed along with the other maintenance etc tags. PamD 07:00, 3 August 2021 (UTC)

Screen readers are never affected by this. Compare this and this revision: The {{Italic title}} is placed below the navhat in the former, above it in the latter. Compare the generated HTML code of both with a diff-check tool (like this one) and you will find that they are (outside of invisible metadata like revision ID and modification date) completely the same. The placement of the template has no effect on screen readers whatsoever as magic words are discarded during rendering (which is even less than short descriptions, which are divs with "display: none;"). WP:HNP cites the list here as its reasoning. At the moment, both merely fail to consider title modifications in any capacity and HNP would be adjusted appropriately if required.

I would like to argue the placement of DISPLAYTITLE templates on a purely logical basis. The code modifies the title, which is the very first element of each article. Hence, it should be as high up (close to the title) as possible. Given the above knowledge, this should be right after the short description. Alternatively, they could be paired up with the article quality icons, which likewise modify the title bar (and therefore belong to the same logical grouping). This would be #2 (before the hatnotes) or #3 (after the hatnotes). I fail to see any logic in placing a template the does not affect the body between a template that prescribes a body style and content that is part of the body.

Regarding the language maintenance templates, I agree that they are currently misplaced and should be where the other maintenance templates are. I don't know what the reasoning for the current placement is but spot checks show that it is generally not respected (ex.: Al-Jidʽ, Myanmar Girl Guides, National Scout Association of Eritrea, Gerace, Misako Rocks!, Jombok Hoas). This should be discussed/handled independently of the DISPLAYTITLE issue, though. IceWelder [✉] 10:36, 3 August 2021 (UTC)

@IceWelder: On hatnotes and screenreaders, I only know what I've read at WP:HATNOTEPLACE. You seem to disagree with what is stated there.

On logical arguments for {{italic title}}'s position: maintenance templates etc apply to the entire article, including its title, as do English variations (the title itself might include "Colour" or "Color", and conceivably a date - dmy or mdy - could be included in the title of an article). So it makes sense for a template which only applies to one element, the title, to come after those general templates: directly before the infobox. PamD 12:10, 3 August 2021 (UTC)

I always place them at their real-world location, the top of the page. Never thought of putting them anywhere else although once in a great while will see one at the bottom of the page. Randy Kryn (talk) 12:14, 3 August 2021 (UTC)

As noted above, HATNOTEPLACE/HNP has no bearing as it uses this guideline as its justification. Both entirely disregard DISPLAYTITLE (or any other magic words, e.g. NOTOC), which creates no elements (not even invisible ones) on a rendered page and cannot, in any way, interfere with screenreading. Changes here would lead to changes there.

The cases where the title is affected by date/EngVar templates and DISPLAYTITLE are arguably scarce. By the same logic, such templates must come before short descriptions (and other free-text elements) as their contents are also affected, even more so than the title.

I concur with Randy Kryn's POV. I believe that, in principle, we can agree that DISPLAYTITLE et al. should be included in this guideline, with only the exact placement being contentious. If we do not find an amicable solution through discourse, I am considering opening an RfC on the issue. IceWelder [✉] 13:15, 3 August 2021 (UTC)

Layout question: References attached to section headings?

Example: Napa cabbage#Pests and diseases

This style seems very wrong to me, creating possible accessibility issues and adding clutter (especially in the Table of Contents, where they are visible but cannot be clicked), among other concerns. Am I the only one who thinks so? I can find nothing in the MoS that addresses this bizarre placement, which I have seen from time to time, so I thought I would ask here. Thanks! 1980fast (talk) 02:59, 14 October 2021 (UTC)

See WP:CITEFOOT. Nikkimaria (talk) 03:30, 14 October 2021 (UTC)

@1980fast: Also MOS:NOSECTIONLINKS: Section headings should: ... Not contain citations or footnotes. --Redrose64 🌹 (talk) 15:09, 14 October 2021 (UTC)

@Nikkimaria and Redrose64: Thank you both! I've fixed this in the past, but it's great to know I was right to do so. 1980fast (talk) 22:37, 14 October 2021 (UTC)

RfC: Position of DISPLAYTITLE

IT'S COMPLICATED

In this RfC, editors discussed how the Manual of Style should specify the DISPLAYTITLE family of templates be listed atop a page. While three options were proposed in the RfC, only two gained support; one proposed to place the templates right after the short description (option A), while the other proposed to place the templates right above the infobox (option B). There was no rough consensus in favor of option A nor option B on their own. However, there was a unanimous consensus' that the placement should be standardized in some way. While three editors supported option A as their primary choice and two editors supported option B as their primary choice, consensus is not ascertained by a vote but by the quality of the arguments given on the various sides of an issue, as viewed through the lens of Wikipedia policy. The arguments made, read in light of policies and guidelines, seemed to be of relatively equal merit in support of both option A and option B. The weak lean of the five participants' first preferences towards option A is not enough to establish a consensus here, especially with the lack of substantial stated objections among many option A editors to option B.

Editors should continue to pursue future discussions in order to achieve a community consensus on where to put these templates. For now, however, there is no consensus to make a specific change to the MoS regarding DISPLAYTITLE and related templates.

(non-admin closure) — Mikehawk10 (talk) 04:41, 10 November 2021 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The above discussion shows that there is some consensus to include the DISPLAYTITLE family of templates—{{DISPLAYTITLE}}, {{Lowercase title}}, {{Italic title}}, and {{Italic dab}}—in the "Order of article elements" section of this style guideline. The central argument is completeness: Several editors (including myself) use this guideline to determine where to place various elements, and the lack of a common template type like DISPLAYTITLE is destined to cause inconsistencies. There was no concurrence on where these elements should be placed within the list of elements. I announced my intent to open an RfC on the matter, which was not met with any opposition, so here we are. IceWelder [✉] 09:00, 3 September 2021 (UTC)

Options

Option A: Right after the short description. – DISPLAYTITLE modifies the title, the very first element of an article. Therefore, the template should be as high up as possible. The short description should be the very first element in any case, so DISPLAYTITLE should come right after.
Option B: Right before the infobox. – Hatnotes, maintenance templates, etc. constitute meta information, whereas DISPLAYTITLE is a mostly cosmetic change. It should be logically paired with the rest of the article content and therefore come just before the infobox and any text.
Option C: Do not include the DISPLAYTITLE family.

Arguments to avoid

Screen readers: DISPLAYTITLE is a magic word that exclusively alters the title and does not produce any additional HTML elements. For this reason, screen readers are indifferent to any changes to the DISPLAYTITLE template placement. WP:HATNOTEPLACE, which asks editors to place navigational hatnotes before anything but the short description, is based on our guideline and therefore subject to change based on changes here, not the other way around.

Survey

Option A per the argument I added as initiator. IceWelder [✉] 09:00, 3 September 2021 (UTC)
I support Option B, reasoning as set out above. These templates don't relate to the entire article but to one component, the first, so that's the logical place for them. Thanks. PamD 09:43, 3 September 2021 (UTC)

Although screen readers are said to be irrelevant to this discussion, option A would move away from the simple, established, rule of "Hatnotes come before everything except short description", making a more complex rule for editors adding hatnotes (who, I imagine, hugely outnumber editors who add Displaytitles). Option B is more consistent. PamD 20:56, 3 September 2021 (UTC)

I don't think that this is a widely enforced rule; I have mostly seen people place hatnotes just before the infobox in spite of MOS:ORDER, as they are the first visible elements. When these were placed atop, it was mostly because people used Twinkle for that (which even prepends short descriptions). "Hatnotes before everything but short description and DISPLAYTITLE" or "Hatnotes first for body-related content" is not a too stark deviation (nor will it affect that many people, as you noted). Regards, IceWelder [✉] 12:05, 12 September 2021 (UTC)

A, have always put title coding at the top of the page. Randy Kryn (talk) 10:47, 3 September 2021 (UTC)
A, I think since it relates to something near the top of the article it logically belongs near the top. No substantial objection to "B" either (second choice) - it's more important just to have some defined place so we don't have to discuss this again. MB 15:22, 3 September 2021 (UTC)
B Since the short description is metadata, it is best to keep the metadata together. Hawkeye7 (discuss) 09:16, 13 September 2021 (UTC)

Comments

Pinging contributors to the aforementioned discussion: @MB, PamD, Redrose64, and Randy Kryn. IceWelder [✉] 09:00, 3 September 2021 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

single sections

What is the value in a single body-encompassing section? I can't find anything in the MOS about such a thing, though I'm surprisingly unobservant. — Fourthords | =Λ= | 19:47, 17 February 2022 (UTC)

Space between word and reference

Hello, when a reference follows a word, rather than a punctuation mark, what does MOS suggest doing? In this sentence, from the lede/lead of the article Nagorno-Karabakh conflict, "ended" and the reference have a space between them, and I'm wondering if that's what MOS suggests: The president of Azerbaijan, Ilham Aliyev, claimed that the conflict has thus ended [61] however the ceasefire agreement was followed by the 2021 Armenia-Azerbaijan border crisis from May 2021 onwards, with continued casualties from both sides. — Mainly 17:07, 19 February 2022 (UTC)

FWIW, I have put the reference right after the word and no space in between....William, is the complaint department really on the roof? 17:16, 19 February 2022 (UTC)

I agree. References should generally be touching the part of the sentence they're referencing. They should touch on their left, and after punctuation. Not sure if it says this in MOS, but this is generally how I see it done. –Novem Linguae (talk) 17:33, 19 February 2022 (UTC)

Thank you! That sounds good. — Mainly 17:36, 19 February 2022 (UTC)

MOS:PF is clear that refs should always follow, and touch, punctuation of some sort, so " when a reference follows a word, rather than a punctuation mark" should just never happen. Otherwise it looks awful. There are a couple of exceptions. You either have to fiddle the text to include punctuation, or wait until the next occurs. Johnbod (talk) 17:41, 19 February 2022 (UTC)

MOS:PF actually says All ref tags should immediately follow the text to which the footnote applies, with no intervening space. Refs are placed after adjacent punctuation, not before (apart from the exceptions below). Also, per WP:INTREF2, They are generally added either directly following the fact that they support, or at the end of the sentence that they support, following any punctuation. Neither of these requires that there be some form of punctuation between text and ref. --Redrose64 🌹 (talk) 18:24, 19 February 2022 (UTC)

Well, it should say what I said. The other looks awful, is rarely seen, and would not be acceptable at FAC. Johnbod (talk) 15:46, 21 February 2022 (UTC)

I don't see that it looks awful, and regardless, verifiability is more important. WP:CITEDENSE says some may even require more than one inline citation per sentence and If a word or phrase is particularly contentious, an inline citation may be added next to it within a sentence. Tsergo Ri landslide, for example, has two citations not next to punctuation in the first paragraph of the lead. It's not that uncommon. MB 17:40, 21 February 2022 (UTC)

(Couldn't comment yesterday because my IP range was shut down for 24 hours!) Sorry, @Johnbod: but I don't agree with your interpretation of MOS:PF: the rule is that the ref goes after punctuation if any (unless perhaps it's a closing parenthesis), and that there is no space before a ref or between refs, but it is quite acceptable to have a ref immediately after a word - and the third sentence of Wonderful_Parliament#Richard's_absence, a recent TFA, shows two examples. PamD 20:09, 21 February 2022 (UTC)

I would certainly have raised this if I had reviewed it, & don't think this is normal or good. If WP:CITEDENSE says "some may even require more than one inline citation per sentence", an epic understatement as far as many of our article-writers are concerned, this suggests it has been little changed for 15 years or more, and badly needs updating to reflect current tastes. Johnbod (talk) 22:30, 21 February 2022 (UTC)

Are those tastes reflected in external style guides? Graham (talk) 06:02, 10 March 2022 (UTC)

It's certainly appropriate to have a footnote immediately after a word, but contrary to the usage at Wonderful Parliament, I would think it's typically desirable to have the footnote following a clause if there is no intervening punctuation. Graham (talk) 06:06, 10 March 2022 (UTC)

Paragraph guidance

I find the current guidance on the use of paragraphs rather vague and unhelpful. I was looking at several online grammar guides, such as these [4] [5] [6] [7] and there seems to be a broad consensus that paragraphs should consist of information related to a single central topic, idea, or theme, and if the topic or theme changes, then there should be a new paragraph (i.e. you don't bunch random unrelated topics in the same paragraph).

I propose that the current guidance be altered to reflect the consensus. G-13114 (talk) 06:03, 4 May 2022 (UTC)

I'm thinking that "layout" is not the place to talk about content. Then again, I'm not enough of a Wikipedia manual of style maven to know where else it would go. Perhaps Wikipedia:Writing better articles#Paragraphs. - Butwhatdoiknow (talk) 15:32, 4 May 2022 (UTC)

I'm not sure I follow your reasoning. How is guidance on how to structure information into paragraphs not relevant to the layout? G-13114 (talk) 16:00, 10 May 2022 (UTC)

Layout deals with "the arrangement of visual elements on a page." In contrast, writing style "is the choice of words, sentence structure, and paragraph structure, used to convey the meaning effectively." Hence, my suggestion of Wikipedia:Writing better articles#Paragraphs as the place for content structure guidance. - Butwhatdoiknow (talk) 18:32, 10 May 2022 (UTC)

See here. Please revert or improve as needed. Wtmitchell (talk) (earlier Boracay Bill) 15:48, 4 May 2022 (UTC)

Template:Improve categories

Hey PamD. I did a Twinkle test, and Twinkle places {{Improve categories}} below stubs. Any objections if I shift {{Improve categories}} back to the bottom? Thanks. Diff from TestWiki. –Novem Linguae (talk) 01:52, 17 February 2022 (UTC)

@Novem Linguae: Yes, I do object. Twinkle should follow the MOS, rather than us modifying the MOS because Twinkle is getting things wrong. All stub templates should be at the very bottom of the article. It's a long-established rule and keeps things simple for editors who stub-sort or destub articles: they know where to find the templates. If Twinkle is misbehaving, please report it as a bug in Twinkle. Thanks for coming here to discuss, as per WP:BRD. PamD 08:20, 17 February 2022 (UTC)

It was previously not in the MOS. I added {{Improve categories}} to this page a month or two ago, in this diff. It was stable until today. I wonder if there is a WP:SILENT consensus that {{Improve categories}} should go at the very bottom, since Twinkle has been doing it this way for a long time without objection. I pause for feedback from other editors. If insufficient feedback is received, I may self revert and remove {{Improve categories}} from this page, as I think that would be superior to suggesting it be placed in a spot that doesn't match where it is usually placed. I also note that the documentation for {{Improve categories}} states It is recommended that this template be placed at the bottom of the page, where readers will look for the categories. –Novem Linguae (talk) 09:13, 17 February 2022 (UTC)

@Novem Linguae: I interpret "at the bottom" in that quote as being "adjacent to the categories, which are at the bottom, albeit not the extreme bottom, of the page" - as distinct from most or all other similar maintenance templates which go "at the top of the page" (except for short description, hatnotes, etc). But it will be interesting to see what other people say. I will mention this at Wikipedia talk:WikiProject Stub sorting which is where the people most interested in stub templates can be found. Although this discussion is nominally about {{improve categories}} and {{uncategorized}} (which should unquestionably go in the same place as each other, and I would agree that place should be adjacent to the categories, although there seem to be two views as to whether they should be before or after the categories), it is in effect a discussion of the placement of {{stub}} and all other stub templates: whether they should be the very last item in the page. PamD 09:28, 17 February 2022 (UTC)

Sounds good, happy to get more input. {{Uncategorized}} is interesting, Twinkle places it on top, and its documentation says top or bottom is fine. So I removed that one from MOS:ORDER earlier today to avoid confusion. –Novem Linguae (talk) 09:32, 17 February 2022 (UTC)

@Novem Linguae: I've just checked Template:Stub#How_is_a_stub_identified? which states "at the very end...", rather than anything less precise. PamD 09:36, 17 February 2022 (UTC)

It has long been agreed that stub templates go last of all (until the advent of Wikidata, interlanguage links were last of all with the stub templates second to last). The templates {{uncategorised}} and {{improve categories}} clearly relate to categories, so if they are not to go with other maintenance templates before the article content, the logical place for them is where the categories are - or where they would be, if there aren't any. So this revision is correct. --Redrose64 🌹 (talk) 21:58, 17 February 2022 (UTC)

Notified: Wikipedia talk:WikiProject Categories, Template talk:Improve categories, Wikipedia talk:Twinkle. –Novem Linguae (talk) 01:22, 18 February 2022 (UTC)

I attempted to remove {{Improve categories}} from MOS:ORDER today but was reverted. I am not comfortable leaving {{Improve categories}} as the second to last item with only a 2:1 consensus, as this is a policy, and that doesn't really take into account the WP:SILENT consensus of Twinkle doing it this way for 3 years and thousands of edits without objection. I'd prefer to just remove {{Improve categories}} and {{Uncategorized}} and go back to the status quo ante of ambiguity. I think our other option is to RFC this but I am not sure it is worth the effort. Thoughts? –Novem Linguae (talk) 20:13, 23 February 2022 (UTC)

RfC: Category maintenance templates in MOS:ORDER

Option F. See below that the most sought after option is to remain with the current version of the page (Option F). Option A, to not include either in the list, was not far behind in case more discussion would be helpful. Closure requested at WP:CR (permalink). Good health to all! P.I. Ellsworth , ed. ^put'r there 02:51, 2 June 2022 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

.

The maintenance templates {{Improve categories}} and {{Uncategorized}} are unique because their documentation pages state they are allowed to be placed at the bottom of articles. Should {{Improve categories}} and {{Uncategorized}} be included in MOS:ORDER? If so, where?

Option A. Do not include either.
Option B. Include only {{Improve categories}}. Include it second to last (below "Categories")
Option C. Include only {{Improve categories}}. Include it last (below "Stub templates")
Option D. Include {{Improve categories}} and {{Uncategorized}}. Include them second to last.
Option E. Include {{Improve categories}} and {{Uncategorized}}. Include them last.
Option F. Include {{Improve categories}} and {{Uncategorized}}. Include them second to last, with a note stating "(These can alternatively be placed with other maintenance templates before the article content)" as here

–Novem Linguae (talk) 02:37, 28 February 2022 (UTC)

Option F added, to reflect current (recent) version of the page. PamD 09:27, 28 February 2022 (UTC)

Survey

Option C first choice, Option A second choice. I prefer Option C because this is where Twinkle has placed {{Improve categories}} without objections since May 2019. I believe there to be a WP:SILENT consensus for this, since no one has objected until now. I also think Option A is fine. Option A was the status quo for over a decade, until I changed it on 2021-12-24, and then it was changed again on 2022-02-16. This is a guideline page, and this has implications for re-writing user scripts and editing the location of tags in thousands of articles, so it is important we get this right. I do not think {{Uncategorized}} should be included in MOS:ORDER at all because Twinkle places it at the top, and the documentation page for the template says it can go either at the top or the bottom. Trying to say {{Uncategorized}} goes in one spot when it is allowed in two spots could be confusing. –Novem Linguae (talk) 02:37, 28 February 2022 (UTC)
Option C per Novem Linguae. ― Qwerfjkl talk 07:04, 28 February 2022 (UTC)
Option F, second choice Option D. Strongly oppose Options C and E, which contradict the statement at {{stub}} that "Place a stub template at the very end of the article, after the "External links" section, any navigation templates, and the category tags." (Italics for emphasis included on that page: the phrase is also a link to WP:ORDER here).
Twinkle should implement the rules, not dictate them: if Twinkle is getting it wrong, change Twinkle.
{{uncategorized}} and {{improve categories}} need to be in the same place, because they are saying the same thing, in whole or in part, and also because an editor often needs to change the former to the latter (eg after adding Category:Living people and birth date cat).
The template description for {{Improve categories}} says: "It is recommended that this template be placed at the bottom of the page, where readers will look for the categories."; the description for {{Uncategorized}} says "It is recommended that this template be placed at the bottom of the page, where readers will look for the categories, although it is a somewhat common practice among some editors to put it at the top." ( I haven't checked the histories to see whether either of those statements has been controversial, though the talk pages of both templates show attempts to discuss placement over the years.) We need to ensure that we are consistent. I think that "at the bottom" in those descriptions means "among the stuff at the bottom of the page" (just as "at the top" means "in among the stuff which is above the content of the page"), as distinct from the "at the very end" used in the stub descriptions. PamD 09:41, 28 February 2022 (UTC)
Option F/D per PamD. MB 15:12, 28 February 2022 (UTC)
F/D PamD has it bang on. "At the bottom" does not mean "literally last of all, after absolutely everything else". Consider MOS:APPENDIX: if the phrase "they should appear at the bottom of an article" were interpreted that way, the refs would be after the categories and stub templates. But nobody does that, because they understand that it means "after the article's prose". These two tags relate to categories; logically, therefore, they should be placed with the categories. --Redrose64 🌹 (talk) 20:33, 28 February 2022 (UTC)
Option A; second choice option F – Especially on pages that use multiple maintenance templates (particularly pages that use {{multiple issues}}), there's no reason to separate {{improve categories}} and {{uncategorized}} from the rest of them. (For the purpose of clarification, I should note that I understand option A to entail a literal reading of the page, meaning these two templates would be grouped with the rest of the maintenance templates.) Graham (talk) 05:59, 10 March 2022 (UTC)
Comment Option A, silently specifying that both these templates go only at the top, would require the documentation of both templates to be amended, for full consistency. PamD 07:02, 10 March 2022 (UTC)
Certainly. I understand option A to entail consensus to conform the template documentation to the newly amended guideline. Graham (talk) 07:23, 10 March 2022 (UTC)

Just noting for the record that I envision Option A (the status quo ante of ambiguity) being a return to ambiguity. That could be a good compromise option if the community is uninterested in tackling this issue. –Novem Linguae (talk) 08:54, 10 March 2022 (UTC)
The status quo ante existed because what was a long-standing practice, as recognized by the template documentation, contradicted the MOS. The solution, of course, is to either (a) modify the MOS or (b) enforce the MOS, preferably after consensus for the existing MOS provision is reaffirmed. If there is a consensus to neither add an exception for these two templates to the MOS nor make any changes to the provision, that is necessarily a consensus to reaffirm it.

I can understand the view that the MOS shouldn't take a position on the matter. I can also understand the MOS not taking a position on the matter as a result of a lack of consensus. I would disagree with both of those outcomes, but I can understand the motivation behind them. I do not, however, know who could possibly support the position that template documentation and the MOS should directly contradict one another. While it is inconceivable to me, if that is a view that we think one could possibly have, we should have an "option G" to accommodate this. I imagine that such an option would add language saying that, for the purpose of MOS:ORDER, {{improve categories}} and {{uncategorized}} don't necessarily constitute "maintenance / dispute tags". Graham (talk) 06:10, 11 March 2022 (UTC)
Option A and amend the documentation of those two templates, and (I'm honestly sorry to even be proposing this) amend Twinkle's behavior as well. If we actually wish people to notice that an article needs categories, then we should recommend these banners go at the top of an article, where they'll be noticed. Ajpolino (talk) 00:04, 11 March 2022 (UTC)
Other banners that apply only to a section, as opposed to the entire article, go in that section. These apply only to the categorization of the article, so it is logical that they go in that "section". Furthermore, these banners don't need to be widely seen to be effective, editors monitor the category and find/fix them that way. category:Uncategorized from March 2022 is the only month that exists, all prior months have been zeroed and the category deleted - evidence that there is no "notice" problem. MB 00:25, 11 March 2022 (UTC)
The edit I've just made to The Sinks shows how helpful it is to have these templates, both of them, adjacent to the categories. I added one category, removed {{uncategorised}}, added {{improve categories}}. If I was on my phone (and I often edit on my phone) I would only be able to edit one section at a time, so this would have been very cumbersome if I had needed to edit top and bottom of the article in two separate edits. PamD 08:51, 12 March 2022 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Position of Italic title

This is a technical issue and not a style issue. {{Italic title}} should be placed directly beneath {{Short description}} as described in its documentation. Moving it from there creates an extra whitespace. See previous revisions of Hāfu, Sakana, and Exsurge Domine. 9³ (talk) 04:10, 13 January 2022 (UTC)

In these specific revisions, the double-newline right after the title style template is to blame for the extraneous spacing. Nontheless, I agree that the guideline should match the template's documentation on this issue. IceWelder [✉] 06:54, 13 January 2022 (UTC)

In my experience, no other properly written template creates extraneous spacing because of double-newlines. Either it is a technical limitation in MediaWiki or the template is just poorly written. I'm unable to find a style guide for wikitext markup but I think that forbidding double-newlines would create readability problems not to mention having to remove them from literally every single article. 9³ (talk) 07:33, 13 January 2022 (UTC)

I've gone ahead and edited the guideline at the two parentheticals to reflect this, as I see no objections and the template is still broken. 9³ (talk) 21:37, 9 June 2022 (UTC)

I think this makes MOS:ORDER too complicated. I recommend picking one spot for {{DISPLAYTITLE}}, {{Lowercase title}}, {{Italic title}} and sticking it there. Having it twice with long explanations like "(may also be placed before the infobox except for {{Italic title}} when the article has a short description, see below)" is not ideal, and creates succinctness and maintainability concerns. –Novem Linguae (talk) 21:41, 9 June 2022 (UTC)

I fully agree that it looks unwieldy and would support a proposal for a single position. @Redrose64: Is it still not possible for {{Italic title}} to be rewritten to allow for placement at either position regardless of the existence of a short description, as with DISPLAYTITLE and Lowercase title? 9³ (talk) 06:50, 10 June 2022 (UTC)

You mentioned me: where is the comment of mine that you are replying to? --Redrose64 🌹 (talk) 09:01, 10 June 2022 (UTC)

Portal bar vs Authority control

Since {{Authority control}} is a navbar, it looks out of place when placed after a {{portal bar}}. I suggest that their order be swapped around, as is often the practice. Hawkeye7 (discuss) 20:21, 1 July 2022 (UTC)

There was a similar proposal last July at Wikipedia talk:Manual of Style/Layout/Archive 14#Portal bar and authority control which raised some principles (order of internal vs. external links) and different alternative arrangements. -- Michael Bednarek (talk) 03:24, 2 July 2022 (UTC)

Looks like the way forward is to delete {{Authority control}} templates from the articles. Hawkeye7 (discuss) 05:50, 2 July 2022 (UTC)

Short description before hatnote?

I noticed Wikipedia talk:Manual of Style/Lead section#Short description before hatnote? so cross-referencing in an effort for future readers not to get lost... --Joy [shallot] (talk) 21:34, 9 July 2022 (UTC)

Further differentiation

The text at MOS:NOTSEEALSO says that links to ambiguation pages should not be included in See Also sections, but it includes an exception in parentheses: "(unless used in a disambiguation page for further disambiguation)". The link for the text "further disambiguation" is unhelpful and even confusing. Perhaps it is meant to point to MOS:DABSEEALSO, which is a subsection of the page. In any case, this link doesn't seem to clarify what is meant by the phrase "further disambiguation". It might be better to not link to anything at all and let the phrase stand by itself. The guidance that needs clarifying is whether it's ok to include links to disambiguation pages in the See Also section of articles. In general the answer is no. However, it's generally ok to link to disambiguation pages in the See Also section of other disambiguation pages. The way it's written doesn't make that entirely clear. As written it sounds like this is only ok if for "further differentiation". I think any link included in the See Also section of a disambiguation would be for "further disambiguation", so why not just say "(unless used in a disambiguation page)". Or maybe there should be a clarification that is not in parentheses, such as: "It's generally acceptable to link to disambiguation pages in the See Also section of disambiguation pages)". 15:09, 25 July 2022 (UTC) Coastside (talk) 15:09, 25 July 2022 (UTC)

After reviewing the history, I think we should just update the link to point to MOS:DABSEEALSO as that was the original intent.Coastside (talk) 15:23, 25 July 2022 (UTC)

[1] Discussed in 2018 and 2019.

[2] Wikipedia:Hatnote § Placement.

[3] These templates can also be placed at the end of an article. The matter was discussed in 2012, 2015 and 2014.

[1]

[2]

[3]

v t e JavaScript
Code analysis	ESLint JSHint JSLint
Supersets	JS++ TypeScript ArkTS
Transpilers	AtScript Babel ClojureScript CoffeeScript Dart Elm Emscripten Google Closure Compiler Google Web Toolkit Haxe LiveScript Morfik Nim Opa PureScript Reason WebSharper
Concepts	JavaScript library JavaScript syntax
Debuggers	Chrome DevTools Firefox Inspector Komodo IDE Microsoft Edge DevTools Opera DevTools Safari Web Inspector
Doc generators	JSDoc
Editors (comparison)	Ace Cloud9 IDE Atom CodeMirror Brackets Light Table PhpStorm Orion Visual Studio Visual Studio Express Visual Studio Code Visual Studio Team Services Vim
Engines	List of ECMAScript engines
Frameworks	Comparison of JavaScript frameworks List of JavaScript libraries
Related technologies	Ajax AssemblyScript asm.js Cascading Style Sheets Document Object Model HTML HTML5 JSON WebAssembly WebAuthn
Package managers	npm pnpm yarn
Module bundlers	Webpack Vite esbuild
Server-side	Active Server Pages Bun CommonJS Deno JSGI Node.js
Unit testing frameworks (list)	Jasmine Mocha QUnit
People	Douglas Crockford Ryan Dahl Brendan Eich John Resig

Authority control databases – Alexander Graham Bell
International	ISNI VIAF FAST WorldCat
National	Germany United States France BnF data Japan Italy Australia Czech Republic Spain Portugal Netherlands Norway Chile Greece Korea Poland Vatican Israel
Academics	CiNii Scopus Leopoldina
Artists	ULAN MusicBrainz
People	Trove Deutsche Biographie DDB
Other	IdRef NARA SNAC

v t e JavaScript
Code analysis	ESLint JSHint JSLint
Supersets	JS++ TypeScript ArkTS
Transpilers	AtScript Babel ClojureScript CoffeeScript Dart Elm Emscripten Google Closure Compiler Google Web Toolkit Haxe LiveScript Morfik Nim Opa PureScript Reason WebSharper
Concepts	JavaScript library JavaScript syntax
Debuggers	Chrome DevTools Firefox Inspector Komodo IDE Microsoft Edge DevTools Opera DevTools Safari Web Inspector
Doc generators	JSDoc
Editors (comparison)	Ace Cloud9 IDE Atom CodeMirror Brackets Light Table PhpStorm Orion Visual Studio Visual Studio Express Visual Studio Code Visual Studio Team Services Vim
Engines	List of ECMAScript engines
Frameworks	Comparison of JavaScript frameworks List of JavaScript libraries
Related technologies	Ajax AssemblyScript asm.js Cascading Style Sheets Document Object Model HTML HTML5 JSON WebAssembly WebAuthn
Package managers	npm pnpm yarn
Module bundlers	Webpack Vite esbuild
Server-side	Active Server Pages Bun CommonJS Deno JSGI Node.js
Unit testing frameworks (list)	Jasmine Mocha QUnit
People	Douglas Crockford Ryan Dahl Brendan Eich John Resig

Authority control databases – Alexander Graham Bell
International	ISNI VIAF FAST WorldCat
National	Germany United States France BnF data Japan Italy Australia Czech Republic Spain Portugal Netherlands Norway Chile Greece Korea Poland Vatican Israel
Academics	CiNii Scopus Leopoldina
Artists	ULAN MusicBrainz
People	Trove Deutsche Biographie DDB
Other	IdRef NARA SNAC

v t e JavaScript
Code analysis	ESLint JSHint JSLint
Supersets	JS++ TypeScript ArkTS
Transpilers	AtScript Babel ClojureScript CoffeeScript Dart Elm Emscripten Google Closure Compiler Google Web Toolkit Haxe LiveScript Morfik Nim Opa PureScript Reason WebSharper
Concepts	JavaScript library JavaScript syntax
Debuggers	Chrome DevTools Firefox Inspector Komodo IDE Microsoft Edge DevTools Opera DevTools Safari Web Inspector
Doc generators	JSDoc
Editors (comparison)	Ace Cloud9 IDE Atom CodeMirror Brackets Light Table PhpStorm Orion Visual Studio Visual Studio Express Visual Studio Code Visual Studio Team Services Vim
Engines	List of ECMAScript engines
Frameworks	Comparison of JavaScript frameworks List of JavaScript libraries
Related technologies	Ajax AssemblyScript asm.js Cascading Style Sheets Document Object Model HTML HTML5 JSON WebAssembly WebAuthn
Package managers	npm pnpm yarn
Module bundlers	Webpack Vite esbuild
Server-side	Active Server Pages Bun CommonJS Deno JSGI Node.js
Unit testing frameworks (list)	Jasmine Mocha QUnit
People	Douglas Crockford Ryan Dahl Brendan Eich John Resig

RfC Verifiability in See also sections

"Very long" sections

Advice that needs changing

A bot to move incorrectly placed hatnotes?

Annotated links

...or not see also...

Discussion related to application of MOS:SEEALSO

DISPLAYTITLE

See also - proposal

Semi-protected edit request on 15 December 2020

"See also" section at Edit count

LAYOUT needs some conforming updates to match WP:MOS#Section_organization

Proposed edit to See also

"Body," "contents," or a name to be named later?

Question about "See also" wording and possible changes

Changing the location of GA and FA icons

Discussion at Wikipedia talk:Manual of Style § Do explanatory footnotes go before or after references?

3.1 Works or publications

empty sections

Columns in body

Portal bar and authority control

Clarification: DISPLAYTITLE

Layout question: References attached to section headings?

RfC: Position of DISPLAYTITLE

single sections

Space between word and reference

Paragraph guidance

Template:Improve categories

RfC: Category maintenance templates in MOS:ORDER

Survey

Position of Italic title

Portal bar vs Authority control

Short description before hatnote?

Further differentiation