This is an archive of past discussions. 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.

Just with regard to this -- In July 2007, a consensus of four editors had a cursory discussion which is now to be found in archive 1 here as a result of which this edit was made. I would have objected at the time, if I had known, but I'm afraid that during this period I was not aware that I needed to watchlist obscure manual of style subpages to prevent people from very insistently enforcing these ill-thought-through rules on content that I maintain. The matter has annoyed the hell out of me in the past and now it's irritating me again: let's revert and remove. There's a longstanding consensus supported by excellent reasons about why redlinks are allowed on Wikipedia ---- see WP:REDLINK which has extensive archives. Why and how does it make sense for "See also" sections to be a special exception?—S Marshall T/C 21:12, 19 December 2016 (UTC)

The difference is the very purpose of the section—its name, even. You can't explicitly tell people "See this" if "this" doesn't exist.

More fully: Words and phrases in the body of article would be there whether or not linked. Linking them is only giving added value, providing potential paths to useful information on those words and phrases (which may not even have any information relevant to the current article, unlike See also links). In some cases, one might feel that there ought to be an article, that a word or phrase used in the current article, while properly included, is obscure enough or useful enough to merit giving the reader a hand, so that if there isn't an article now one might be reasonably anticipated or even suggested via the red link. Meanwhile, as long as the link remains red, the words and phrases are still serving as the means through which information in the article is being communicated.

See also isn't the body of the article. There are no words or phrases there that would still be there if unlinked. Their only purpose is to aid navigation, and they serve no other purpose if not doing that. It's the same rationale for proscribing red links on disambiguation pages, unless we provide a blue link to something related. Largoplazo (talk) 21:17, 19 December 2016 (UTC)

• Well, I understand that, but it rests on a proposition I don't accept, which is that it's unhelpful to point people to a gap in the encyclopaedia. It's clearly appropriate to tell our users where to go for more information, and --- Wikipedia being unfinished --- some of those places to go for more information will be articles we need but don't yet have. So we draw attention to the fact that these articles still need to be written and show them a space where, if they happen to be so inclined, they can add it. It's not a good idea to conceal the gaps in Wikipedia. And besides, our aim is still to convert readers into contributors, or so it was the last time I looked ---- redlinks are a key tool for doing that.—S Marshall T/C 21:46, 19 December 2016 (UTC)

"See also" means see information we have, not information we don't have. It's that simple. While red links serve a valid purpose in the body, they run counter to the purpose of the section in this section. Largoplazo (talk) 02:54, 20 December 2016 (UTC)

I don't think that follows at all. The purpose of the section is to point people to the articles they should visit for further information. Some of those articles might not exist yet. Why is that a problem?—S Marshall T/C 18:22, 20 December 2016 (UTC)

If "the purpose of the section is to point people to the articles they should visit for further information" then, since redlinks don't "point people to the articles they should visit for further information" (since those links lead to no related information at all), it follows that they fail to serve the purpose of the section.

To argue that those links may lead to information some day in the future is like arguing that we should include an article on a garage band now because they may be notable some day in the future. When the band becomes notable, then there can be an article. When an article exists, then See Also can have a link to it. Largoplazo (talk) 14:21, 26 March 2017 (UTC)

I prefer to keep the current prohibition against red links in see also sections. Without this prohibition, one could foresee the see also sections becoming collections of article titles that some editors think ought to exist but can't be bothered to create. I don't see how that's helpful. CUA 27 (talk) 22:16, 19 December 2016 (UTC)

The purpose of "see also" is to list a few related articles, not to list mind dumps from drive-by editors. There is no point discussing this unless someone can provide a couple of examples where it would be helpful to have a redlink in a see also section. That is, what redlink was removed when it should have been retained? My feeling is that any worthwhile redlinks should be integrated into the article. Johnuniq (talk) 23:55, 19 December 2016 (UTC)

In my opinion it is useful to point out gaps that ought to be filled. We have lots of people here looking for projects and we can help them with auggestions in this way, using red links. Rjensen (talk) 00:55, 20 December 2016 (UTC)

If it's currently a gap, then readers can't "see it also" because it isn't here. Imagine that the title of the section were, instead, "Related information that we have", and then it had links that weren't to information we have. Largoplazo (talk) 02:57, 20 December 2016 (UTC)

Imagine the title was "Useful information you might want to check out" -- note that even if it's red a user can always use google to find info he may want to know about. That is even if we have no article on it we can guide reader to useful info. Rjensen (talk) 04:15, 20 December 2016 (UTC)

Like disambiguation pages, the See also section is a navigation aid to Wikipedia, not to Google or the entire Web. Largoplazo (talk) 13:27, 20 December 2016 (UTC)

I don;t think that redlinks should be a part of a See Also section. Someone has already pointed out that doing so defeats the purpose of See Also sections (as they are currently defined). Redlinks - thinking back to my early days and still had my dad (a since-retired editor) breathing down my neck about editing correctly. Redlinks were meant to offer opportunity for new articles to be created on subjects that would likely get them sooner rather than later. Redlinks are not similar items - they are opportunities to become similar items. Its distracting to follow a link of supposed similarity only to have it lead to a dead end. - Jack Sebastian (talk) 06:21, 20 December 2016 (UTC)

I have to agree with you S Marshall. I don't have much else to say on it, because everyone else in the thread's disagreement overpowers whatever I may say, but I agree with you that red links should be visible anywhere possible. If they weren't, we'd all have less knowledge that there needs to be a new article there. I think people should be stimulated to go and research something that isn't there for themselves and create it - it's great practice. SpikeballUnion 12:48, 26 March 2017 (UTC)

In the first sentence of MOS:ORDER, “simple article” links to a section of WP:STUB that was renamed in revision 659534886 from “Ideal stub article” to “Creating and improving a stub article”. The link here should be updated to reflect the change, I believe. (Or an anchor added there and linked here, not sure if this is necessary.) Being unable to edit semi-protected pages yet, I propose the change here. Palec90 (talk) 00:32, 31 March 2017 (UTC)

Thanks for this heads up. I've updated the link. Butwhatdoiknow (talk) 07:19, 31 March 2017 (UTC)

If you are interested in MOS:APPENDIX questions (such as where to place templates like ((authority control))), then please see Template talk:Medical resources#RfC on placement of Medical condition classification and resources template. WhatamIdoing (talk) 18:20, 15 May 2017 (UTC)

Belated note from original poster: although I pinged Ettrig as a courtesy as they were the editor I noticed moving an Expand template from top to bottom, I posted this message here hoping for wider discussion among those interested in the layout of articles. PamD 11:51, 5 June 2017 (UTC)

@Ettrig: The documentation at ((Expand French)) says: "This template marks an opportunity, not a fault. It is less important than a stub mark. Therefore it should not be used as an urgent warning in the beginning of articles." but gives no indication where it should be placed. Presumably all this family of templates have similar wording - I've checked ((Expand Afrikaans)) and it certainly does.

There is no mention of this group of templates in WP:ORDER, as far as I can see. It would be useful if these templates had a mention in WP:ORDER - somewhere in "Bottom matter", perhaps after the "Featured list" etc templates?

One of these templates has recently been moved from top to bottom of an article, with edit summary (Moving template to bottom, this is not the most important info): I don't disagree but am sure I've seen these templates at the top of many articles and would like to see a statement in this MOS guideline.

Ah, have just noticed discussion at Template_talk:Expand_French#Do not place at the top, and now found Template_talk:Expand_language#Attempts_to_change_the_placement_of_expand_language_templates_without_consensus. Lots of reading there, but extremely relevant to this MOS guideline which is where people will look for a definitive answer. PamD 07:51, 5 June 2017 (UTC)

Thanks! (The latest part of that discussion is two steps further down.) I think the cause of the peculiar state of this phenomenon is a general lack of interest. The usage is rather low intensity. The existing pattern is to put the template at the top. Several protests have been "voiced", but the discussions die out without a firm conclusion being reached. The users of the template think (reasonably) that the existing pattern constitutes a consensus.

I think you point at a couple of places that may be good for settling this issue. Could you suggest one place to start? --Ettrig (talk) 08:04, 5 June 2017 (UTC)

Hmm. You already HAVE started. Thanks again! Let's see what this leads to. --Ettrig (talk) 08:05, 5 June 2017 (UTC)

I'll add my opinion later, but first, some background: Historical usage since template creation in 2008 was to place ((Expand French)) at the top of the page. (For a while, vagueness of the instructions led some users to place it on the Talk page, which resulted in Talk pages being auto-categorized as "needing Expansion from French" until that was corrected.) This template is part of a series of templates (((Expand Spanish)), ((Expand German)), etc.) which are generated by ((Expand language)). The latter transcludes its documentation in the usual way, and also via Expand language/howto in the case of the green sentence quoted by PamD above; that is why it is included in all of the series of "Expand" templates. The howto page was created in 2009, and the first mention of "opportunity, not a fault; less important than a stub mark" and of positioning at the bottom of the page was on 30 Aug 2016, here. Thereafter ensued a slow edit war about positioning, which remains unresolved. Attempts to implement bottom positioning of the template by fait accompli started 18 April 2017, I believe at least as far back as August 2016, involving hundreds of edits, followed by a pause on May 5. These edits have resumed again as of May 30, with another 500 edits since then. And that's where we stand now. A prior discussion about this is here. Mathglot (talk) 10:05, 5 June 2017 (UTC) update by Mathglot (talk) 10:15, 5 June 2017 (UTC)

My request is that this template should be placed near the bottom of the articles and that the documentation should say this. The main argument for this is the principle that the articles should have the most important information first, combined with my evaluation that this template does not hold important information. The only value for the reader is the potential indirect effect of inspiring to a translation effort. This hope is dubious. Of the last 100 articles that I checked and changed, a vast majority of the articles were tagged in 2008, so they have disturbed the reader for a very long time, without the wanted effect. Exactly 83 (of the 100) pointed to articles in French that were marked as stubs. The vast majority of them were bot generated. So the request wasn't even reasonable. This shows that the process around this template does not provide for reasonable quality of marking, which in turn points at low importance.

The only counter argument that I have seen is that there is a consensus for status quo and that therefore a consensus must be reached for a change to take place. This argument is not valid. Already the second discussion on this talk page raises the same concern. That discussion died out without reaching a conclusion. It mentions two RFCs that showed the same pattern. When I much more recently raised the concern, the one answer was positive concerning the substance.

The Expand template can be compared to the stub marking. Stub marking marks a deficiency. Still it is put at the bottom of articles, so as not to disturb the reader more than necessary. Expand does not even mark a deficiency, so it is less important. Therefore it is even less reasonable to let it disturb the reader a much as it does when it is placed on the top of the article. The stub template is also smaller and therefore even less disturbing. It can be assumed that the handling of the stub template is more thoroughly thought thru, since it is orders of magnitude more common. --Ettrig (talk) 10:59, 5 June 2017 (UTC)

I prefer that these notices go on the top of articles, with a second preference for the talk page. Using this at the bottom of articles is unsightly and unexpected. (Stub templates look different from other templates -- as far as I know, there is not a single template using the ambox master template that goes on the bottom of article pages.) My preference for placing this on the top of article pages is partly based on the usefulness of this template to readers of the article -- which was more clear a few revisions back of the template. This template includes a link to Google translate, so casual readers are notified that there is a better article in another language and given a link to a machine translation. This is now hidden in the collapsed part of the template, but is theoretically accessible. If this template is placed on an article talk page, readers will not be informed of the existence of a better article, and potential translators are unlikely to see the template. On the other hand, these templates are admittedly acted on fairly rarely. I'm not sure it's fair for Ettrig to cite the random geostubs that got tagged with this template en masse, but even articles viewed far more are rarely translated. That's why my second choice is on the talk page -- like the requested photo template (another request that few readers are capable of fulfilling). Calliopejen1 (talk) 20:59, 5 June 2017 (UTC)

Yes, this template is unsightly at the bottom. However, it is just as unsightly at the top. This is because it is modelled after templates made for alerts, for alerting the reader to deficiencies in the article. But this template is not about a deficiency. It only expresses a wish by one user that other users do work that this user thinks should be done, but cannot or does not want to. The argument about unexpected is vacuous. I wish that Wikipadedia editors were more interested in reading statistics, but the community isn't. A very large percentage of these templates point to geostubs. This is a fact that should be weighed in. --Ettrig (talk) 03:57, 6 June 2017 (UTC)

((Ambox)) is used not just for "alerts" (admittedly, I'm not entirely sure what you mean by this term) but also to various ways that an article could be improved by Wikipedia editors. There is ((Underlinked)), ((Travel guide)), ((Arabic script needed)), ((Alphabetize)), ((Missing-taxobox)), etc. etc. These all "express[] a wish by one user that other users do work that this user thinks should be done, but cannot or does not want to". I'm not sure why you believe this box is different in kind from those templates. Not all editors are equipped to fulfill translation requests but then again not all editors are equipped to add Arabic script to articles. And as for "unexpected" it is unexpected at the bottom because these banners indicate that there is a problem with the text/article that follows the banner. (E.g. when the banner is at the start of a section, it means that the section that follows needs some sort of work.) And I don't see why the usage of this template on geostubs is relevant to the placement of the template. Re: unsightly I personally find it strange and unbalanced to have a bright banner at the bottom of the article, but I suppose perhaps I should just strike "unsightly" in favor of "unexpected" because that is by far the bigger issue. Calliopejen1 (talk) 05:41, 6 June 2017 (UTC)

I would like to contribute some substantive comments to the point under discussion, namely the proper position of this template, but I feel that something important is standing in the way.

Since this discussion began (11:51, 5 June 2017 (UTC)), User:Ettrig has altered the template position on an additional eighteen one hundred sixty four articles while this discussion is going on. What can be the meaning of this? You have already been clearly asked to stop acting unilaterally about this question on more than one occasion. Continuing along this path of trying to establish a fait accompli for your favored position on the one hand, while engaging in a discussion of the very same point on the other, is contemptuous of your fellow editors. You can hardly expect to have a reasoned discussion with others while you are doing whatever you please behind the scenes to implement your point of view.

I propose that this discussion of the proper positioning of the ((Expand language)) series of templates be put on temporary hold, until such disruptive editing stops. I'm not sure how others feel about this, but to me, the latter is a minimum bar to a reasonable discussion among equals having mutual respect for each other. Mathglot (talk) 06:42, 6 June 2017 (UTC) updated by Mathglot (talk) 09:20, 11 June 2017 (UTC)

It is a good thing that this discussion is now occurring. My actvities promted it. (See the beginning of this thread.) I repeat: There is no consensus on this issue. There has been protests before. They have been largely ignored. The protester has not persisted. Thus there has been no conclusion. Neither has there been an instruction on where to put the template. Now there is (peculiarly). It says that the template should not be placed at the top of the article. Yes, I put it there myself. But I have not ignored the protests. But my answers to the protests have been ignored.

The examples of similar templates are interesting. There are a lot of Underlinked. My view on that is the same as on Expand: It should be made more like Stub, for the same reasons. Travel guide is used much less (<500 occurrencies). This is a real style violation that merits an alert. Arabic script occurs almost exclusively (but sparingly (<100)) on talk pages. That is fine with me. Alphabetize and Missing-taxobox are also very few. Again: We can assume that they are less well thought through than Stub.

The beginning of the article is very important for the reader. This is where the reader starts looking. This is where we should strive to provide what the reader needs. This space should not be squandered on ineffective processes of editor administration. --Ettrig (talk) 08:30, 6 June 2017 (UTC)

Ettrig, you are proposing a drastic change to the placement of maintenance templates that is not specific to ((Expand language)) -- I don't think it's fair to say that the placement of these templates has not been thought through. There is nothing that makes ((Expand language)) unique here -- yet another reason not to unilaterally move it to the bottom of articles (or elsewhere). Calliopejen1 (talk) 21:08, 6 June 2017 (UTC)

@Ettrig: Where are you getting the idea that only "important" tags go on top. According to MOS:ORDER, maintenance tags go on top. ((Expand language)) templates are all categorized as maintenance templates. The fact that stub templates go to the bottom has nothing to do with importance either. They go to the bottom because the MOS says they do. – Finnusertop (talk ⋅ contribs) 04:09, 7 June 2017 (UTC)

Thank you Finnusertop, for this very clarifying argument. To paraphrase, you are saying that this is a rule and that the rules cannot be changed and therefore there is no need to discuss whether they are good or bad. This is probably how the other opponents think too. So now I feel I understand this discussion much better. Before, it felt very peculiar. Why did almost no-one touch on the substantive question: What is the best way to arrange the article? Your view is probably so common that I will have to give up soon. But this is so important (for the reasons that I have given) and wrong, that I will have to try a little bit more. Of course the rules can be changed!

There are also some minor weaknesses in your argument. (But this is much less important.) You refer to MOS:ORDER. It says that maintenance tags typically appear in the following order. This is not formulated as a directive to be slavishly followed. This suggestion links to WP:TMAIN, which can be interpreted as a way of indicating what is meant by maintenance tag in this context. That list is limited and does not include the templates that we are discussing. In that list of about a hundred templates there are only two that I would not also put at the top. To summarize: The "rule" that you refer to is not a rule and it does not point at this template. --Ettrig (talk) 06:16, 7 June 2017 (UTC)

Your paraphrase is incorrect, do not put words in their mouth. You are right that the rules can be changed—and regarding this question, this is the place to do it—but you cannot do it by yourself. Your behavior, discussed elsewhere, makes a mockery of any attempt to discuss content issues with you here. Mathglot (talk) 06:42, 15 June 2017 (UTC)

• I note that this issue has now reached ANI. PamD 08:01, 15 June 2017 (UTC)

• I'm not sure if this is the right place to comment or not, since this seems to be happening in a few venues. At any rate, I've pretty much always placed them at the bottom of articles, usually just above the navboxes because it looks very odd to have them below the nav boxes. The current language in the guidance seems to support this. If you don't place it at the top, where are you going to place it? In the middle? No, you would place it at the bottom. And anyway, I always kindof thought about expand templates as usually a companion to a stub template.

Overall, if, for example, an article is under-sourced, or contains original research etc, then readers should be warned of this before reading the article. These serve both as a notice to the reader about what they're about to read, as well as a notice to editors at WP:BACKLOG, of things that need to be fixed.

The expand template is basically just for editors, and not really for readers at all. Besides, it's an ugly template wherever it's placed, so why place it in the most prominent place? And if you have a slow connection/computer, it often first loads as expanded for a short while, and... it's a pretty big template when it's expanded. TimothyJosephWood 20:35, 15 June 2017 (UTC)

Without commenting on your arguments about correct placement of the template, I would merely like to point out that the reason that "The current language in the guidance seems to support this" is because the language was recently altered by an edit-warring user against consensus, who has now gone on to alter 2,500 articles to match "the language in the guidance" according to their own point of view. The user who first discovered this and called out this behavior has recently retired from Wikipedia. Mathglot (talk) 23:12, 15 June 2017 (UTC)

1) The bit you're not commenting on seems to be the important bit. 2) It looks an awfully lot like the language was there in 2009. TimothyJosephWood 10:01, 16 June 2017 (UTC)

The language was not there since 2009; you are displaying a 2009 page which is transcluding a 2017 subpage, so you are misinterpreting the facts.

Summary of some disputed template instructions.

The instructions from creation through August 2016 merely said, "Tag it with [the template]..." and everyone interpreted that as meaning tag it at the top, in accordance with long-standing practice. (For a short while, some interpreted it to mean tag the article talk page instead, resulting in nonsensical categorization of talk pages, but this was cleared up with a simple instruction change.)

Two elements of the template instructions were altered by User Ettrig on Aug 30 2016 against long-standing practice. They are:

1. Placement:
   1. "Tag it with the template..." (2009-Aug 2016)
   2. "Tag it near the end (bottom).." Ettrig Aug 30 2016 et seq.
2. Importance:
   1. (no statement about importance) 2009-Aug 2016
   2. "This template marks an opportunity, not a fault. It is less important than a stub mark." (Aug 30 2016)

These were subject to reverts and edits which either placed both of them back in the instructions or reverted both of them together, until May 5 2017 when an attempted revert by Mathglot reverted #1 but left #2 in place, and that is how it stands now.

• Original version placement: "Tag it with..." in 2009
• Still the same in 2014 ("tag it with...")
• still the same in 2015
• Ettrig first change Aug 30 2016
• reverted Sept 9 by Abrahamic Faiths
• reverted Sept 9 by Ettrig
• Another revert by AF on Sep 8
• Another revert by Ettrig on Sep 8
• Another revert by AF on Sep 8
• Another revert by Ettrig on Sep 8
• Bolding by U:Daylen on May 2 2017
• "half-revert" by Mathglot (of the "near the end" language only)
• revert by Ettrig to restore "near the end" language
• self-revert by Ettrig leaving "Opportunity not a fault" and "stub" language in place.

So, as was said elsewhere, Ettrig first changed the instructions, began a massive change to articles, and edit-warred on the instructions when challenged. His preferred language remains in the template doc now in part (the "stub" and "importance" language) and that language as well as the "near the bottom" language is all recent, and is all due exclusively to his edits. Mathglot (talk) 02:05, 17 June 2017 (UTC)

(With an "assist" by a failed revert by the scurrilous Mathglot.) Mathglot (talk) 04:40, 17 June 2017 (UTC)

Another note: The scale of changes currently being made by Ettrig illustrates how these templates have historically been used almost exclusively at the top of article pages (setting aside what the template instructions themselves say). That is, there has been essentially a consensus in practice. Calliopejen1 (talk) 04:51, 17 June 2017 (UTC)

Well, I'm just going to do this here. Thank you for pointing out the translcusion issue. I was very confused. So you do seem to be missing a bit where for two years there were instructions to place in the references section. Other than that, the so called consensus linked to doesn't look very much like a consensus at all. It looks a lot like either a lack of consensus, a bold change that was never followed, and/or a consensus for talk page placement that makes no sense for the obvious categorization problem.

This discussion probably should have happened in September, and doesn't seem to have. Both editors are probably at fault for that (like most edit wars), and if it had, it would have prevented a lot of problems. But no discussion happened, and the language sat without substantial opposition for ten months, and even with a short lived edit war, there's probably a WP:SILENCE argument to be had after nearly a year.

So... again, the obvious solution seems to be to open an RfC. It looks like there have been four options proposed total: top, bottom, talk, references. We can probably cut out the last two. I'll open it myself, since no one can apparently be bothered to, and "block this editor because I can't be bothered to open an RfC" doesn't... you know... really help the encyclopedia. TimothyJosephWood 12:31, 17 June 2017 (UTC)

Your last sentence above is an astonishing misunderstanding or misrepresentation of the current ANI at multiple levels.

• For starters, no one has called for a block on any user that I am aware of.
• Secondly, there is no connection between opening an Rfc on the content issue of proper placement of a template, and the opening of an ANI about a single user's remarkable one-man effort to change thousands of articles to conform to his PoV with no demonstrated support for his position. Each can be resolved separately, they are entirely independent of each other.

For example, it would be perfectly consistent for an editor to strongly support Ettrig's preferred template positioning, and at the same time strongly deplore his actions that sparked the ANI. The ANI is not about his template position preference at all, and acting as if it were will only muddy the waters there.

This is at least the third time you have conflated the two topics, and I admit I'm flummoxed about how to explain this more clearly; perhaps PamD or someone can help out.

Finally, your "can't be bothered to open an Rfc" sounds like an accusation of sin by omission against somebody. Who exactly are you accusing? Why would a member of a near-unanimous majority open an Rfc to confirm their near-unanimous majority? Seems like a pointless exercise to challenge their own position on behalf of a lone wolf in opposition. Isn't the burden of creating an Rfc rather on the person who wishes to cause change?

In any event, you have opened the Rfc that you have been castigating others for failing to do, and that is just fine, and the way it is supposed to work. I hope the exercise will be both illuminating and fruitful. Mathglot (talk) 17:18, 17 June 2017 (UTC)

The following thread is an RfC. WP:RFC says (in the beginning of the first paragraph):

Before using the RfC process to get opinions from outside editors, it's often faster and more effective to thoroughly discuss the matter with any other parties on the related talk page. Editors are normally expected to make a reasonable attempt at working out their disputes before seeking help from others. If you are able to come to a consensus or have your questions answered through discussion with other editors, then there is no need to start an RfC.

I urge you to start discussing in earnest. What is the best placement of the Expand French tag? There has been a lot of text about my moving of it to the bottom. But nearly all of it is about my actions and whether there is a consensus. We need a discussion that clearly spells out the arguments for placing it at the top and at the bottom, respectively. This is so we can weigh the arguments against each other. --Ettrig (talk) 20:25, 17 June 2017 (UTC)

I suggest changing the following:

This section is not intended as a repository for general references that were used to create the article content.

to

This section is not intended as a repository for general references or full citations that were used to create the article content.

Basically, the section tries to instruct how to ensure that works that verify article content and works that don't are listed separately. This is, however, not the case (neither in the guideline or even always in articles).

In the following example, the book on the heat of the Sun was consulted (it is a "general reference"). The guideline tells you not to group it with the further reading entry:

N

The sun is pretty hot.

Further reading

---

• Miller, Edward. The Sun's Size. Celestial Books, 2013.
• Smith, John. The Sun's Heat. Academic Press, 2005.

However, the definition of "general references" does not include full citations of works that are cited through short citations. Thus the current guideline does not forbid the following, which confuses works that are cited and works that are not:

?

The sun is pretty hot.^[1]

References

---

1. ^ Smith, 2005, p. 2.

Further reading

---

• Miller, Edward. The Sun's Size. Celestial Books, 2013.
• Smith, John. The Sun's Heat. Academic Press, 2005.

Should the suggested wording be adopted, editors could place full citations under any title they choose except for the confusing "Further reading":

Y

The sun is pretty hot.^[1]

References

---

1. ^ Smith, 2005, p. 2.

• Smith, John. The Sun's Heat. Academic Press, 2005.

Further reading

---

• Miller, Edward. The Sun's Size. Celestial Books, 2013.

– Finnusertop (talk ⋅ contribs) 23:53, 2 May 2017 (UTC)

Comments

• Support. Full citation information should go to the "Bibliography" section. —Codename Lisa (talk) 06:02, 3 May 2017 (UTC)
• Support. I suggest you add "; these are usually listed in the References section" to the end of the sentence. — Preceding unsigned comment added by Butwhatdoiknow (talk • contribs) 15:08, 3 May 2017 (UTC)
  • @Codename Lisa: are you happy with the above addition by Butwhatdoiknow? – Finnusertop (talk ⋅ contribs) 23:02, 13 May 2017 (UTC)
    • To be honest, I assumed this discussion entails adding a lot more elaboration than this. It is feeble addition, I don't disagree with it because I support adding more instructions. —Codename Lisa (talk) 03:45, 14 May 2017 (UTC)
• mildly support I would prefer two sentences since they are saying two different things. When the full citations are separated out and only brief citations given in the 'Reference' section, then I agree with Codename Lisa. When there is no separate "full citation" section, they belong where first cited in the 'Reference' section, as at least partially indicated by Butwhatdoiknow. A better solution would be something like: This section is not intended as a repository for general references that were used to create the article content; nor should it replace a "Bibliography" section as the repository for full citations where brief citati"ns are used in footnotes.' --Bejnar (talk) 16:12, 14 May 2017 (UTC)
  • I'd make that "... nor should it replace a "Bibliography" section as the ..." Butwhatdoiknow (talk) 00:14, 15 May 2017 (UTC)
• If this is a problem that we're seeing, then I support adding a short clarification. Note that WP:Further reading#Relation to reference sections could contain much more detail, if that were needed. WhatamIdoing (talk) 18:19, 15 May 2017 (UTC)
• Broadly agree with WAID. --Izno (talk) 21:40, 30 July 2017 (UTC)

I propose changing one sentence in the MOS:BODY section titled "Headings and Sections" from this:

"Short paragraphs and single sentences generally do not warrant their own subheading."

to this:

"Short paragraphs generally do not warrant their own subheading; single sentences very rarely do absent a compelling reason."

There are three reasons for the proposed change. The first is simply logic: if single-paragraph sections are generally unwarranted because they are too short, then single-sentence sections should be even more disfavored. The second is that the current guidance stating that single-sentence sections are generally unwarranted seems rather weak; an editor could claim that a ten-section article in which three sections are composed of a single sentence each follows MOS:BODY because the sections generally (i.e., a majority of the sections) are composed of more than one sentence. The third is based in practice: a number of WikiProjects give helpful guidance as to how their more meaty articles should be structured, but relatively short articles probably shouldn't be divided into sections in an attempt to follow these structures. CUA 27 (talk) 14:05, 4 August 2017 (UTC)

• Oppose: A single sentence may well be the best way to express the content currently available for a topic, under a commonly-used section heading. This proposed guideline would incentivise editors to split a single flowing sentence into a couple of clunky ones, to avoid coming under the "very rare" category and being changed by a policy geek. I don't see a problem with the current wording. PamD 14:37, 4 August 2017 (UTC)

PamD: Your point about editors evading the proposed guidance by splitting a single sentence into two could be remedied with some modest wording tweaks. For example, we could say something like the following (tweaks in italics): "Paragraphs composed of a single sentence or two short sentences very rarely warrant their own subheading absent a compelling reason" or "Single sentences very rarely warrant their own subheading absent a compelling reason; editors should not break a single sentence into two to circumvent this guidance" CUA 27 (talk) 15:31, 5 August 2017 (UTC)

• Oppose: CUA 27, your reasoning actually supports the reverse of your proposal. In addition, every single imperative sentence in MOS is automatically eligible to be read with an invisible "unless there is a good reason not to do so." Wikipedia laws are not etched on stone. Finally, I do not follow the reason of the ephemeral editor in your example. —Best regards, Codename Lisa (talk) 15:23, 4 August 2017 (UTC)

Codename Lisa: I'm afraid I don't understand the first sentence in your post. Can you explain your view as to how my reasoning supports the reverse of my proposal? CUA 27 (talk) 15:31, 5 August 2017 (UTC)

The proposal text makes the requirements looser. Your argument, on the other hand, is for a more stringent version.

Fortunately, TJRC's comment below makes me understand the perspective of that hypothetical editor of your example better. Still I think the editor might or might not have a point, depending on the situation. For example, it is wrong to subdivide a "history" section into three "inception", "development" and "end of life" if the "inception" and "end of life" each have one sentence only (regardless of how many sentences or paragraph "development" has). But subdividing a "Geographical presence" section into three "United States", "Europe" and "Japan", where the first two have significant contents and the latter has one sentence, is probably correct.

Best regards,
Codename Lisa (talk) 05:38, 6 August 2017 (UTC)

Codename Lisa: I still don't follow how changing the guidance from "generally unwarranted" to "very rarely warranted" is a loosening of the requirements. In any case, I agree that dividing a history section into three as you have done is not ideal where two of the three sections are one sentence only. Regarding your example above re geography, (1) if we were to change your hypothetical so that one section had significant content and two sections had only one sentence, I think we'd both agree that three sections is probably not the best way to organize an article, and (2) if we take your hypothetical as is, if the Japan sentence were folded into the Geography section (not into the US or EU subsection), that would probably be a preferable organization. CUA 27 (talk) 11:29, 8 August 2017 (UTC)

• Oppose. For example, sometimes, not at all rarely, there is a section logically divided into subsections; and while several of the subsections may have a substantial amount of text, one of them (often the last) rates only a single sentence. Despite that, it should clearly be set off into its own subsection, rather than shoehorned into the prior subsection to which it does not belong. TJRC (talk) 21:47, 4 August 2017 (UTC)
• Comment: I don't see the need for the change. I dislike single-sentence paragraphs and I especially dislike sections for single-sentence paragraphs. So I often point to the MOS:PARAGRAPHS section of the guideline. The guideline already states, "Short paragraphs and single sentences generally do not warrant their own subheading; in such circumstances, it may be preferable to use bullet points." The "generally" portion leaves leeway for exceptions. Flyer22 Reborn (talk) 17:52, 8 August 2017 (UTC)
• Oppose. Writing a good article is an immensely complex affairs. One must be able to read the wind and do what is needed. The proposal here is only wordy; it does not alter meaning. One's time is better spent learning the complexities that I mentioned. FleetCommand (Speak your mind!) 05:40, 9 August 2017 (UTC)

This may be substantial enough for a discussion, so I reverted a change I'd made removing the words 'or navigation boxes' from the sentence "As a general rule, the "See also" section should not repeat links that appear in the article's body or its navigation boxes". The language is outdated, as now half of Wikipedia's readers don't see templates. Half of the readers, those who access Wikipedia on (many? most? all?) mobile devices, can't see navbox links. So they don't get the choice to read and click on those links. My reasoning is that Wikipedia's mobile readers should also be given the chance to see pertinent links, and the 'See also' section is a common way of doing that. Randy Kryn (talk) 19:32, 27 July 2017 (UTC)

In that case, just removing the mention of navigation boxes is not enough; the guideline should be reversed from its current intent: links in the "See also" section to items already mentioned in navigation boxes should be encouraged. -- Michael Bednarek (talk) 05:21, 28 July 2017 (UTC)

On navboxes

Navboxes were an interesting but failed project so it is best that they are ignored when editing articles. Thincat (talk) 06:13, 28 July 2017 (UTC)

Hello, guys. It is said that madness is defined as repeating a mistake over and over and expecting different result each time. Therefore, if we accept that "Navboxes were an interesting but failed project", the current wording can be paraphrased as: "As a general rule, the 'See also' section should not repeat links that appear in the article's body or in the miserable failure euphemistically known as 'navigation boxes'". That seems correct to me. If the "See also" section repeat the links in the failure, it becomes failure #2.

Best regards,
Codename Lisa (talk) 13:57, 28 July 2017 (UTC)

Um, I think the problem is that navboxes can't be seen on mobile devices. The See also section doesn't have this problem. Putting the links where they can be seen is not repeating the "failure' of putting them where they cannot be seen. Butwhatdoiknow (talk) 01:31, 29 July 2017 (UTC)

Yes and no. Navboxes not appearing on Minerva isn't a glitch. The exclusion of navboxes from the mobile version must have been a conscious decision, which needed additional coding. Put their links into the "See also" section, and guess what? It gets excluded too.

Best regards,
Codename Lisa (talk) 13:42, 29 July 2017 (UTC)

Codename Lisa, seriously?, I thought it was a coding hurdle. To exclude these templates from mobile must have been decided somewhere, was it taken to the navbox page? I'm going to call the fine and prolific navbox editor Woodensuperman in on this, and ask if he knows where this was decided. I didn't answer the criticism of templates above (failed project? On the contrary, they are some of Wikipedia's finest art forms, often detailed and extraordinarily useful maps of the site as related to the central subject), but this attitude is too prevalent on Wikipedia and has resulted in the backlash of hiding as little as three or four collapsed templates in navbox cages. In any case, if leaving them off of mobile was a decision, let's see if we can reverse it. Does anyone have more information of how and why this was decided? Thanks. Randy Kryn (talk) 15:25, 29 July 2017 (UTC)

Implementing it is easy. CSS alone could do it. Also Minerva is already displaying its own automatically generated and more prominent "Related articles" section. Give Minerva developers an excuse and they'll throw out the "See also" section as well. You know, in Wikipedia, editing disputes are resolved using consensus but development matters are not.

Best regards,
Codename Lisa (talk) 17:29, 29 July 2017 (UTC)

As for Minerva, the skin has been split out from many of the customizations made for the mobile use case (aka the MobileFrontend extension), so we'll soon have that as an option for normal desktop reading. Not sure when that hits the production servers. --Izno (talk) 19:13, 29 July 2017 (UTC)

Izno, if I understand that correctly the Minerva skin, if selected for desktops, will also block navbox templates? Could this be changed on the desktop version so templates are shown? If so, then desktopping this skin may take the 50 percent who no longer see templates to an even higher percentage. Please correct me if I'm wrong, and removing templates from a non-mobile skin version is not being considered. Thanks. Randy Kryn (talk) 20:56, 29 July 2017 (UTC)

Right now, Minerva on desktop does not appear to show navboxes, which is probably a bug (given its alpha/beta status there). I've filed phab:T172078. --Izno (talk) 20:43, 30 July 2017 (UTC)

Good catch, hopefully the Minerva team can pop the navboxes back in there for desktop. Thanks. Randy Kryn (talk) 22:18, 30 July 2017 (UTC)

Navboxes not being displayed was due to the MediaWiki developers making the decision (correctly in my own opinion) that navboxes will be difficult, at best, to display sensibly in mobile. They can also be quite bloated (meaning additional downloaded data, which can be monetarily costly for the reader), and the use case for mobile is to look up relevant facts on the go, rather than deep research on a topic--a use case also unsuited for navboxes. --Izno (talk) 19:10, 29 July 2017 (UTC)

That makes sense. I'm wondering if it would be possible to add a boxed-note to the bottom of all mobile Wikipedia pages, something like "Non-mobile viewers may find one or more navboxes - organized maps to related Wikipedia articles - in this space." Such an addition would educate more readers to the existence of these templates as well as provide written direction about how to find them. Thanks again, Randy Kryn (talk) 02:42, 30 July 2017 (UTC)

Has it ever been considered to put navboxes in their own subpage or namespace, and then viewable according to a user preference? Thincat (talk) 14:08, 30 July 2017 (UTC)

User preference can already control it via CSS. --Izno (talk) 20:43, 30 July 2017 (UTC)

I don't see a reason to and it is self-referential. --Izno (talk) 20:43, 30 July 2017 (UTC)

Please do not spam the reader. Not with links. Not with notices that linkspam does not show. Not with anything else. FleetCommand (Speak your mind!) 05:00, 30 July 2017 (UTC)

• There seems no disagreement to the proposal to remove the language, and if nobody can discuss one in the next day or so I'll remove the words. And of course I don't mean to imply that all of the template links should also be on 'See also'. This started on my talk page when an editor removed 'See also' links on the pages of the sculptures contained within the Dr. Seuss Memorial by using the Dr. Seuss Memorial entry on the template as their reasoning. Randy Kryn (talk) 15:24, 15 August 2017 (UTC)

The discussion here immediately turned to the side issue of the appearance & usefulness of navigation boxes. There was no discussion about your proposed relaxation of the restriction on entries in the "See also" section, so citing "no disagreement" doesn't properly summarise this thread. One could argue that there was no agreement for your proposal, so it should not be implemented. -- Michael Bednarek (talk) 05:13, 16 August 2017 (UTC)

On relaxing the guideline

Under the circumstances, I think the proposed change is reasonable. Hawkeye7 (talk) 06:11, 16 August 2017 (UTC)

{EDIT: This comment was not directed at Hawkeye7, who defined the situation well and directly, but to the comment above theirs which was there before the section switcharounds) So please discuss it. I'm assuming there is no discussion or disagreement because there is little to defend or a reason to keep the guideline in place. It was likely written when navboxes appeared on the screens of everyone who looked at a page. Now they have been removed from mobile users, and only half the readers see them, due to a decision not approved by editors. That off-site decision seems to invalidate the language used on the on-site 'See also' guideline, and this proposal just updates it. Randy Kryn (talk) 11:34, 16 August 2017 (UTC)

I would object to this change as making it harder to police articles where the see also section has ballooned in size and where those are still indeed included in articles through their navboxes. That 50% of readers (mobile only) don't see navboxes seems not unreasonable, because the use case on mobile is not "read through until the end or until the see also or until one sees any link of interest" but instead "get to a specific factoid from Google and then get back out again". --Izno (talk) 12:01, 16 August 2017 (UTC)

I object to the proposal. The "See also" section occasionally attracts some tangential entries, and some editors feel that "important" subjects deserve to be listed there, although they have appeared in the article already. Giving licence to list a selection of entries from the navbox(es) would make it even harder keep "See also" in check and raises further questions and problems: which items from a navbox can be listed? All? There are navboxes with hundreds of entries. Some? Who decides? As to the deprivation of mobile users: they miss several other aspects of the Wikipedia ecology: reduced in-page search (because a lot of content is collapsed), no categories (in the app), no WikiMiniAtlas, no mouse hover, no article history; they must be other benefits, so missing out on navboxes may not be a big deal. -- Michael Bednarek (talk) 13:50, 16 August 2017 (UTC)

They don't get categories or discussion pages either? Shouldn't there be a mention somewhere on mobile pages that "There is much more to Wikipedia pages on laptop viewing" or "View all of this article's content on laptop screens" (or whatever it is that computer screens are commonly called these days)? Randy Kryn (talk) 14:20, 16 August 2017 (UTC)

• There seems to be more of a WP:IDONTLIKEIT reasoning here. The justification for keeping the language, even though half of Wikipedia's readers don't look at a skin which includes templates (nor discussion or categories), is that 'See also' sections may get bloated. If that is the problem we should address that, and give a maximum-number guideline, but not continue to hold onto restricting language which is clearly outdated. Randy Kryn (talk) 14:32, 17 August 2017 (UTC)

I suggest adding something to the following effect to MOS:SEEALSO:

"Links to specific sections in other articles should use the ((Section link)) template, if a piped link is not being used."

It looks neater, and I see most see also sections linking to a section, don't use it yet, so it is worth promoting as style. Take the example:

• Wikipedia talk:Manual of Style/Layout#Example section anchor

Versus:

• Wikipedia talk:Manual of Style/Layout § Example section anchor

The "§" style is already in general use as part of ((see also)), and more see also sections are using it over time. ^edit:I think we should use the § sign for the same reason we don't use underscores in links. It looks neater, looks less technical, and also has more common usage in printed written texts than "#".^{16:44, 26 May 2017 (UTC)} --BurritoBazooka ^Talk Contribs 17:05, 25 May 2017 (UTC)

• Support. However, I must confess that I am a bit of involved supporter. I was the motivator behind both ((section link)) and what happened to ((See also)), ((Main)) and others. But again, I must say I did all those things slowly and carefully, after seeing how community was welcoming to the use of § sign. —Codename Lisa (talk) 09:51, 26 May 2017 (UTC)
• I don't think this is necessary. The proposing user has not shown that conflict has been generated because of the insertion, or removal, of such templates in the see also section. --Izno (talk) 21:46, 30 July 2017 (UTC)
• Support, although I would prefer Article#section links themselves be modified to use the § symbol as proposed at T160837. Sondra.kinsey (talk) 20:32, 27 August 2017 (UTC)

Regarding MOS:SECTIONORDER—is the feeling that cleanup and dispute templates should go before or after ((Use [date style])) and ((Use [language dialect]))? I'm inclined to favor putting the "Use __" templates first so that they can be seen by editors, rather than be lost in the clutter.—DocWatson42 (talk) 09:30, 10 August 2017 (UTC)

And ((italic title)) is another odd one - where should it be placed? PamD 17:07, 10 August 2017 (UTC)

Typically I place ((italic title)), ((use dmy dates)) and similar down at the bottom, in the same place that ((coord)) goes - between navboxes and defaultsort. But then somebody comes along and moves it to the top, probably ignoring WP:HNP whilst so doing. --Redrose64 🌹 (talk) 05:51, 11 August 2017 (UTC)

Yes, we need an agreed place, to save editors from wasting time undoing other people's work like that. Until there's an entry in the WP:ORDER listing there's scope for silly edit wars. Have just noticed that the template documentation for ((Italic title)) says "place this template in the article, normally at the very top" which, taken literally, contradicts WP:HNP. It's also a special case of ((display title)) or the preferred magic word "DISPLAYTITLE", which are also not listed in WP:ORDER. The notes on DISPLAYTITLE say "The title (the fullpagename) is changed using ((DISPLAYTITLE:namespace:pagename)) anywhere in the wikitext." PamD 07:16, 11 August 2017 (UTC)

Let me modify/clarify my stance—I agree with MOS:SECTIONORDER, and would place ((Italic title)) with ((Use dmy dates)) etc. at the top. Putting them at the bottom/end matter of the article (and I'm including ((Coord)) in this) means that they tend to get missed, and since they affect the entire article I feel that they should be where they can be easily found and so that editors can be informed of the expected "style". Specifically, in my opinion since ((Coord)) using the "title" parameter is displayed at the top of the article, unless there is a technical issue (e.g., in screen reading browsers for the blind) it should join the the other items at the top. But I realize that's (probably) another can of worms that I'm opening.—DocWatson42 (talk) 05:26, 12 August 2017 (UTC)

The documentation for ((use dmy dates)) says Place this template near the top of articles that use the dd mmm yyyy date format. MOS:ORDER should be updated to incorporate this. Same for ((Italic title)) and ((display title)). Hawkeye7 (talk) 22:56, 12 August 2017 (UTC)

Besides the already mentioned templates, are there any others that it would be appropriate to include/discuss? (If we're making the placement of ((use dmy dates)) MOS-official, all of the templates listed as ((EngvarA#See_also)) should also be included.)—DocWatson42 (talk) 07:28, 13 August 2017 (UTC)

Since you've asked, MOS:LAYOUT places the ((featured list)), ((featured article)) and ((good article)) template with the bottom matter after the ((authority control)). This is anomalous, because, like the ((coord)) template, they add visual elements to the top of the article. Moreover, the LegoBot and FACBot have a tough time locating the correct place since the Appendices and other bottom matter elements are all optional, and in some cases may have different names. So they are putting them at the top, as are the humans in many cases. I suggest MOS:LAYOUT be modified to move them to the top as well. Hawkeye7 (talk) 06:27, 16 August 2017 (UTC)

I always place the italic title code at the top, as it is applied to the title and that's where editors would expect to find it. Putting too much other coding at the top would, in many cases, cause spacing problems at the top and would add to the clutter of tags, multiple tags, hatnotes, and other things which find their way up there. Randy Kryn (talk) 14:41, 17 August 2017 (UTC)

It can get pretty cluttered at the bottom, too, and placing the ((coord)) template at the bottom with an ((Authority control)) template can also result in the appearance of an extra carriage return, so I wouldn't let that be the sole determining factor. —DocWatson42 (talk) 17:52, 22 August 2017 (UTC)

Authority control should really be directly after the navboxes, since it draws a visible full-width box itself. --Redrose64 🌹 (talk) 20:41, 22 August 2017 (UTC)

Agreed. Hawkeye7 (talk) 22:28, 22 August 2017 (UTC)

I've seen a fair number of articles with Coord placed between the navboxes and Authority control (e.g., Austria-Hungary#External_links). :-/ I've left that placement alone because I was uncertain if it was proper. Also, we might want to add the ((Taxonbar)) placement instructions to the MoS. —DocWatson42 (talk) 03:05, 23 August 2017 (UTC); edited 05:03, 23 August 2017 (UTC).

Hello? Do we have any sort of consensus? —DocWatson42 (talk) 13:00, 30 August 2017 (UTC)

I was editing the King of the Gypsies article, changing the sub-headings size but I noticed that there is no visible difference between sub-headings 2,3 and 4, so the sub-heading 4 seems to be in the same category as the sub-heading 2 instead of making the reader know that sub-heading 4 is a subset of sub-heading 3 and not directly of sub-heading 1. Compare the changes in my edit with the previous version of the section of the article modified to have a more clear idea. I think sub-headings size should be discernible different to let know the reader that it is a subsection of a higher subheading/heading. Thinker78 (talk) 17:45, 28 September 2017 (UTC)

According to the MOS:ORDER, every categories are placed at the bottom of an article before the stub template comes. However, the explanation does not seem to apply to the Category:Kvng RTH. Should I follow the guideline of Wikipedia:Manual of Style/Layout, or conform to the category usage? --Ykhwong (talk) 00:18, 29 December 2017 (UTC)

@Ykhwong: Looking at the first article in that category, 44,100 Hz, I see that the code [[Category:Kvng RTH]] is placed after the text in the History section, and not at the bottom of the page with the other categories. The category seems to exist purely to show which articles Kvng (talk · contribs) has worked on. It is clear that the category is being misused in more ways than one. --Redrose64 🌹 (talk) 09:45, 29 December 2017 (UTC)

Thanks for your answer. I just wonder if it is normal to place a user's own category to articles in the main namespace for a personal purpose. What is the difference bettween the category and Special:Log/review? --Ykhwong (talk) 10:41, 29 December 2017 (UTC)

(after edit conflict) I have proposed the category for deletion. PamD 10:44, 29 December 2017 (UTC)

From my talk page, based on a recent bold edit (and my revert) to the guideline:

Hi Izno,

I'm not sure what you meant by "Based on?" in your revert [1]. It should not normally be necessary to state that redirects are allowed in See Also section, because they always were.

However, occasionally I see people replacing redirects by piped or direct links (which is not only against WP:NOTBROKEN and WP:NOPIPE, but makes article maintenance much more difficult). Sometimes, redirects happen to point to different sections in the same target article, which is, of course, perfectly fine. However, if such redirects happen to be listed in a See also section, some editors seem to believe it would be okay to remove them simply because they are pointing to the same target article not realizing that by doing so they are destroying infrastructure (unless there are other reasons to remove such links as well). For as long as the listed terms in a See also section are relevant in the context of the source article (and therefore should be included in a See also list), the organization of the contents in the target article(s) is irrelevant, because redirects may become articles, contents may be moved around, articles may become merged etc. over time and it would be impractical to try and keep all the links in source articles in sync with such changes - after all, one of the purposes for redirects is to "abstract" contents from organization. Of course, this should be obvious to any experienced editor. Unfortunately, it still happens from time to time, and that's why I added that sentence.

--Matthiaspaul (talk) 00:52, 23 January 2018 (UTC)

Matthiaspaul, if you can defend a link on a NOTBROKEN basis, then you should do so. (NOTBROKEN has limits, of course.)

I don't honestly agree with you about the rest of your concern--while it's true that redirects may become articles and that articles may get moved or merged or what not, I don't find that alone an overwhelming reason to let redirects to an article remain in the article's see also. If you have reasonable belief that a redirect to the self-same article will be expanded from its redirect state, then you should keep it and leave a note on the talk page (and possibly in the wiki text pointing to the talk page).

(On a somewhat converse point, WP:SEEALSO doesn't, and shouldn't, forbid redirects here.)

In the general though, we don't insert policy or guideline advice just to head off the dispute that you (specific) happen to have at any given time (and with guidance that is positive for your side of the dispute), but which we (general) happen to have at any given time. Is this a continuing point of contention that you are having with an editor? Multiple other editors? Are you the only one with this apparent issue? Are you sure your suggested change has a consensus, or might it be the case that you are the only one who thinks that this solution is the correct one? --Izno (talk) 01:40, 23 January 2018 (UTC)

You are implying quite a bit. Our MOS is the result of ongoing factual and linguistical refinements reflecting "common sense" and community consensus. I don't think my edit changed anything deviating from the way we (the majority of experienced editors) are already doing it, it just clarified one aspect.

"while it's true that redirects may become articles and that articles may get moved or merged or what not, I don't find that alone an overwhelming reason to let redirects to an article remain in the article's see also."

It seems you got me wrong here, as I didn't say (nor did I want to imply) this, quite the opposite: The links in See Also must, of course, fulfill the criteria already outlined in WP:SEEALSO. We shouldn't add links, including redirects, if they do not. My two points, however, are:

a) The fact that a link points to a redirect is not a reason to remove the link or replace it by a piped or direct link, either - it occasionally happens, but, as you pointed out correctly, it can be corrected through WP:NOTBROKEN and WP:NOPIPE (within the limits of these guidelines, of course). No issue here, except for that mentioning redirects explicitly in WP:SEEALSO might help to prevent this from happening in the first place (and any time that can be spent on improving contents rather than on unnecessary discussions or fixing avoidable issues is a win for the project).

b) This one is more important: Per the criteria detailed at WP:SEEALSO, the link list typically contains keywords that should ideally be covered in a future version of the article, but aren't yet - someone visits the article, scans for the desired keyword and either s/he finds it discussed in the article or at least finds it mentioned in the See also list pointing to related information elsewhere. Occasionally, several such links happen to point to the same target article as an artifact of how the contents is currently organized (which might change anytime in the future). If the title of the target article somehow nicefully combines the relevant keywords of the source article, the links can be combined, however, if they do not, they should not. However, some editors blindly combine such links on the grounds of that they are pointing into the same target article. This not only removes relevant keywords from the source article (which are there to help further develop the article), but also leds to the situation that a See also link may point to an article containing related information, but the name of the link is no longer telling what can be expected. Mind that different vocabularies might be used in different articles, and the link names in a See also section should be seen in the context of the source article, not the target article. Readers cannot know in advance and would have to first click a seemlingly unrelated link and scan over other articles to find out - this is not only inconvenient, but it also hinders the further development of infrastructure.

--Matthiaspaul (talk) 10:17, 23 January 2018 (UTC)

Is there any general consensus about how many subsections a section should have? I've read elsewhere that one subsection under a section is considered a bad practice. I bring this up because Black Panther (film) has a "Release" section with the first paragraph (before the "Marketing" subsection) having over 200 words and the "Marketing" subsection itself having over 1,200 words. It seems to be huge over-emphasis on a sub-topic that is technically more pre-release than release. Erik (talk | contrib) ^{(ping me)} 13:18, 19 February 2018 (UTC)

@Erik: If a level 2 section heading is immediately followed by a level 3 subsection heading, I would say that there should be at least one further level 3 subsection heading within that section. However, when subsectioning is used, it is not necessary for there to be a level 3 subsection heading immediately after a level 2 section heading - the block of text between the level 2 section heading and the first level 3 subsection heading can be considered to be a subsection itself. This is the section as it stood at the time of your post. Within that section, there is only one level 3 subsection heading, but two subsections. --Redrose64 🌹 (talk) 22:06, 19 February 2018 (UTC)

Short descriptions will be needed on all articles in main space. The history of this development can be followed by the truly masochistic in a series of discussions linked from Wikipedia:WikiProject Short descriptions. The short description is effectively an extension or annotation to the title intended to clarify the scope of the article and is considered essential by WMF as an aid to the reader. It will be displayed on mobile view as default and will probably be the first content from the article encountered by the mobile user. It may be displayed on desktop view by using a script, possibly later an integral gadget. It will be visible in source edit mode where it is placed in the code, and should be the first text below the title, before any hatnotes, as it an extension of the title.

I propose that the MOS/Layout be amended as follows to specify this position.

In "Order of article elements", change item

1. Before the lead section

1. Hatnotes

etc

to read:

1. Before the lead section

1. Short description (in template) - required

2. Hatnotes

etc

Cheers, · · · Peter (Southwood) ^(talk): 14:04, 17 February 2018 (UTC)

• WP:HNP says that navigational hatnotes are placed at the very top not least because screen readers and text-only browsers will thus deliver them to the reader first so they know whether they are on the right page. Have any specialists in accessibility issues been asked whether users of such devices will suffer if they get the short description first, instead of the navigational hatnote? In some cases the short description will not distinguish between several people of the same name (eg "American actor" or "English cricketer"), so won't indicate whether it's the right article. PamD 15:51, 17 February 2018 (UTC)

  I've dropped notes at Wikipedia talk:WikiProject Accessibility and Wikipedia talk:Manual of Style/Accessibility. --Redrose64 🌹 (talk) 20:57, 17 February 2018 (UTC)

  I don't know of any readers who use a screen reader on their phone. The short descriptions are currently visible immediately below the title on articles viewed with the Wikipedia app. The intention is that they will be re-enabled in the same way for the mobile view. As far as I know there is no suggestion that they should be normally visible in desktop view, so I can't see where the problem with screen readers is likely to arise. Incidentally, short descriptions are primarily intended to provide exactly the unique identification of an article that Pam is worried that they won't. If they don't do that in a given case, then they certainly will have to be changed to ensure that they do. --RexxS (talk) 01:04, 18 February 2018 (UTC)

  @RexxS: If they are added into the wikitext of the page, above the lead as Peter suggests, will they be read out by screenreaders on desktop? Nikkimaria (talk) 01:50, 18 February 2018 (UTC)

  @Nikkimaria: The idea is that the desktop CSS will apply a style display:none to the short description (whereas mobile view and app CSS will enable display). Because screen readers ignore text that has display:none set, the short descriptions won't be heard via screen readers on the desktop version. --RexxS (talk) 02:37, 18 February 2018 (UTC)

Position of short description in article

A Wikipedia:Short description is now required in all articles. See also Wikipedia:WikiProject Short descriptions for background and previous discussions. The related magic word has been partially implemented by WMF, and we now have a rather large job ahead to add short descriptions to articles. The short description, when made visible by opt-in gadget or user css, serves as an annotation to the title, and this is its intended purpose, and the purpose for which WMF Reading team intend to use it. To function as an annotation to the title, it should display immediately after the title, or as close as reasonably practicable to immediately after the title. To achieve this, we have been adding the template as the first line of the article. AWB currently automatically moves the ((short description)) to below the hatnotes, where it is no longer obviously an annotation to the title.

Currently the default is that the short description is not visible in desktop read view, so will not inluence screen readers at all unless the user is logged in and has elected to make it visible. Disambiguation hatnotes and short descriptions should normally be complementary, or at worst repetitive, and then only if visible.

I propose a change to the standard order of an article, putting short description as the first item in the file, so that the AWB developers can amend the instructions to leave it there, and move it there when found somewhere else. as described above.

Is local consensus sufficient, or should I open an RfC at Wikipedia:Village pump (proposals) for this? · · · Peter (Southwood) ^(talk): 09:45, 9 April 2018 (UTC)

I suspect the link above in "See also WikiProject Short descriptions" is meant to link to Wikipedia:WikiProject Short descriptions. -- Michael Bednarek (talk) 10:26, 9 April 2018 (UTC)

PS: ... and the 1st link should probably go to WP:Short description. -- Michael Bednarek (talk) 10:33, 9 April 2018 (UTC)

Of course you are right. Poor eyesight and in a hurry are not a good combination for accuracy. Cheers, · · · Peter (Southwood) ^(talk): 19:52, 9 April 2018 (UTC)

"A Short description is now required in all articles." Where can I find this requirement? Butwhatdoiknow (talk) 11:51, 9 April 2018 (UTC)

@Butwhatdoiknow: I think it's Wikipedia:Village pump (proposals)/Archive 145#RfC: Populating article descriptions magic word but I couldn't be certain. --Redrose64 🌹 (talk) 18:17, 9 April 2018 (UTC)

Butwhatdoiknow, That link is part of the story. Most of the history is in or linked from the project page. 19:52, 9 April 2018 (UTC)

Are we actually expecting the template to be displayed as a static block element? If I understand correctly, the normal use of the template will be only to call the SHORTDESC magic word. For this, the placement shouldn't matter, and it might actually be preferable to place it near the bottom (along with COORD and FA star templates and DEFAULTSORT declarations) to avoid being inadvertently overridden by later magic word calls. It has also been raised that placement at the top might make it more prone to vandalism (though I'm not quite sure about this). The only reason for placing the template at the top of the article appears to be so that users may tweak the CSS to have it show on the desktop. But for this, wouldn't it be better to use CSS to automatically position the description at the top of the page (similarly to coordinates) rather than relying on manual placement in the source? --Paul_012 (talk) 14:31, 9 April 2018 (UTC)

Paul 012, I don't know. How do you do that? It could solve the problem. Also, what is a static block element? · · · Peter (Southwood) ^(talk): 19:52, 9 April 2018 (UTC)

Pbsouthwood, what I meant was that it (currently) appears according to its position in the page's source. It can certainly be done using CSS (see the coordinates example), but I'm not an expert. We'll need to first iron out consensus on where there short description should be displayed. This could probably use wider community input, as modifying the article header, even if only for opting-in users, seems rather significant. --Paul_012 (talk) 05:06, 10 April 2018 (UTC)

Paul 012, Fair enough. Do you have any suggestions for alternative places where the short description might logically and usefully be displayed (assuming opt-in)? We may as well consider any reasonable options while we are at it. To me, the ideal place would be in the same line as the title, but smaller, after an n-dash or in parentheses, or directly below, also smaller. In both cases it would be an obvious annotation to the title, and its function would be obvious and unsurprising. Anywhere else seems inappropriate, but that is just my opinion. Cheers, · · · Peter (Southwood) ^(talk): 06:01, 10 April 2018 (UTC)

Pbsouthwood, I don't have specific suggestions, though I mostly agree with what you've said. I don't really know about the technical details though (e.g. how feasible it is to insert space directly beneath the title); you'll have to ask someone else. --Paul_012 (talk) 10:20, 10 April 2018 (UTC)

Thanks Paul 012. Maybe someone who can make a concrete suggestion will see this and chip in. Until then, My suggestion for the amendment to the MOS remains open for comment. Cheers. · · · Peter (Southwood) ^(talk): 11:19, 10 April 2018 (UTC)

A typical Wikipedia article includes HTML like this near the start:

<h1 id="firstHeading" class="firstHeading" lang="en">Example</h1>
<div id="bodyContent" class="mw-body-content">
  <div id="siteSub">From Wikipedia, the free encyclopedia</div>
  <div id="contentSub"></div>
  <div id="jump-to-nav" class="mw-jump">Jump to: <a href="#column-one">navigation</a>, <a href="#searchInput">search</a></div>
  <!-- start content -->

What happens after here is entirely dependent upon the page source, and may follow MOS:LAYOUT (but might not). In my opinion, the short description needs to come fairly soon after the <h1>...</h1> element. However, we have no means for injecting content at any point above the <!--start content--> comment - we would need a MediaWiki change for that, hence phab: (this is not the end of the world, we got a MediaWiki change made for topicons, but it took some time).

Since as things stand the ((Short description)) template displays its output at whatever point in the page the template is placed, we must consider accessibility. In my opinion, it is confirmation that the reader has reached the desired page, rather like hatnotes - WP:HNP says "Text-only browsers and screen readers present the page sequentially. If a reader has reached the wrong page, they typically want to know that first." So the short desc and the hatnotes must be together; the only question is which goes first? I would say the short desc should be first of all. --Redrose64 🌹 (talk) 14:41, 10 April 2018 (UTC)

I agree with User:Redrose64's reasoning and conclusions here. Having the code in the equivalent place to the display makes editing easier. You will find the code where you expect it. · · · Peter (Southwood) ^(talk): 08:24, 11 April 2018 (UTC)

How will having it at the top it work with overriding automatically generated descriptions, from infoboxes? - you'd need to put it below the infobox. May be better to get the WMF to put short descriptions visible in the html automatically at the top irregardless of where the template is positioned, and then position the template above the lead instead - since only editors will care about the position then, for them it is best there IMO as if the lead is changed, the short description needs changing too, and so that they don't have to think where to position it depending on whether there are auto-descriptions. Galobtter (pingó mió) 07:25, 14 April 2018 (UTC)

What automatically generated descriptions? Please give examples where this happens. --Redrose64 🌹 (talk) 09:19, 14 April 2018 (UTC)

See Template:Infobox settlement/sandbox & Template:Infobox settlement/testcases. -- Michael Bednarek (talk) 09:29, 14 April 2018 (UTC)

At Talk:Lesbian literature#See also, opinions are needed on whether or not the gay literature and bisexual literature links should be in the See also section of the Lesbian literature article. A permalink for the discussion is here. Flyer22 Reborn (talk) 10:42, 19 April 2018 (UTC)

I have always seen it near the top of the page, but this guide says to put it at the bottom of the page. Where should it specifically go in the top of the page, and can we correct the MoS to reflect that? Kees08 (Talk) 08:14, 6 February 2018 (UTC)

@Kees08: What kind of "status"? Do you mean Featured Article etc, or what? Thanks. PamD 08:30, 6 February 2018 (UTC)

If it's ((featured article)) etc that you mean, Wikipedia:Manual_of_Style/Layout#Order_of_article_elements shows it as going at the bottom just ahead of DEFAULTSORT and categories. PamD 08:33, 6 February 2018 (UTC)

If it is ((featured article)) or indeed ((good article)), those are normally placed by Legobot (talk · contribs) at the very top (example) so getting them repositioned to the bottom would mean a bot coding amendment. If you have been following User talk:Legobot and User talk:Legoktm (as I have for over two years), you'll realise that it's not going to happen. Note that the position of ((featured article)) and ((good article)) are only relevant when editing the page: in the served HTML, the icons always end up in the same place, so their placement in the source is immaterial. --Redrose64 🌹 (talk) 11:22, 6 February 2018 (UTC)

Perhaps we remove it from here then? If the rendering is always the same, it does not matter. Maybe it is here for some reason that no longer exists. Also yes, that is what I meant. Kees08 (Talk) 15:42, 6 February 2018 (UTC)

@Redrose64 and PamD: Do either of you have issues if I reword the section to reflect what Legobot actually does? Kees08 (Talk) 19:47, 22 April 2018 (UTC)

I wonder whether the Featured/Good article enthusiasts should be consulted first at Wikipedia talk:Featured articles and Wikipedia talk:Good articles, before changing the MOS? It does matter, because it makes it easier for human editors to find the status tag if they want to check or edit it. Near the top seems fine to me, so I'd be happy to see WP:ORDER amended. But to what, exactly? There are several claimants to "at the top": hatnotes, short description as discussed above, and now FA/GA, as well as the items with no defined location such as "Use British English" or "Use DMY dates", and ((Italic title)). A defined order for all of these would be helpful. PamD 21:10, 22 April 2018 (UTC)