Jump to content

Wikipedia talk:Manual of Style/Layout/Archive 12

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 5←Archive 10Archive 11Archive 12Archive 13Archive 14Archive 15

A needless and silly rule

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)

RfC: remove the proscription against previously-linked terms in the "See also" section?

OPPOSED
*Summary: There is strong consensus against the proposed change.
  • Reason: As one editor has brilliantly put forth, it's a "see also" section, not a "see again" section. Presumably readers who arrive at "See also" have summarily read the article and maybe be assumed to already have the chance to follow any wikilinks that they thought might be useful for their particular interest.The see-also section just give a short listing of tangentially related topics. Also, there are reasonable objections to have a long re-list of all articles hat have already appeared in the prose.
Winged Blades Godric 06:36, 9 April 2017 (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.

In the section "Standard appendices and footers", in the subsection "'See also' section" (MOS:SEEALSO or WP:ALSO), the fourth paragraph has

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

This proposal is to remove the reference to article body (and FWIW also the bolding), leaving only the proscription regarding navigation boxes, thus:

As a general rule, the "See also" section should not repeat links that appear in the article's navigation boxes.
Herostratus (talk) 17:40, 27 February 2017 (UTC)

Survey: remove the proscription against previously-linked terms in the "See also" section?

  • Support as proposer, my reasoning being given in detail below in the "Threaded discussion" section. In summary, I don't see how this rule enhances the reader's experience. Let them access information from different places -- article body and "See also" section. If a "See also" section needs trimming, "has been linked in the article body" seems a poor criteria. Seems more like a "gotcha" rule than something designed to make it easier for the reader to access knowledge. Herostratus (talk) 17:47, 27 February 2017 (UTC)
  • Oppose The goal of the See also chapter, as I see it, is a To-do list for editors. All the links there are supposed to be related to the article, so they should be somewhere in the text of the article. Those that are already in the text somewhere are not needed in the To-do list anymore. It does not make sense that an article contains a link to a second article in the See-also section without explaining why the link is there and what the connection between the two articles is. --Hob Gadling (talk) 18:07, 27 February 2017 (UTC)
Hmm, that the "See also" sections are a to-do list for editors rather than a resource for readers is something I've never heard of before, and it isn't mentioned in the documentation. Shouldn't a to-do list for editors be on the talk page or something, rather than in the body of the article? Herostratus (talk) 19:42, 27 February 2017 (UTC)
See also sections are definitely not to-do lists as they aren't supposed to contain Redlinks but only links to other wikipedia articles. So what is there to do?...William, is the complaint department really on the roof? 20:24, 27 February 2017 (UTC)
I'm confused. Did you mean to say "See also sections are definitely not to-do lists..."? Herostratus (talk) 20:35, 27 February 2017 (UTC)
I fixed it....William, is the complaint department really on the roof? 21:15, 27 February 2017 (UTC)
  • Support many users are not quite sure which article is of most use, and will get an idea of where to keep looking. The see also says "these are good places to look" which is not usually conveyed in the text. Rjensen (talk) 20:22, 27 February 2017 (UTC)
  • Support. It is handy, and quite reasonable, to list all of the "see also" links in one place, and not have to be scrounging through the article for them. ~ J. Johnson (JJ) (talk) 21:58, 27 February 2017 (UTC)
  • Oppose. The guideline says "As a general rule", so if a link is particularly important and helpful to the reader, it can be repeated in See also. But if this is removed entirely, people will add whatever links they want to draw attention to. SarahSV (talk) 22:12, 27 February 2017 (UTC)
OK. But um isn't adding "whatever links they want to draw attention to" kind of the point of a See also section...? I mean if they're not good links, not helpful to the reader, that's different. But isn't being like "Excellent link for a See also, but damn, it's linked somewhere in the article text, so we can't use it; sucks for the reader, but it is what it is" kind of... random? Herostratus (talk) 22:27, 27 February 2017 (UTC)
The point of the guideline is to make sure the See also section doesn't get too long, so we're supposed to use it sparingly. If something really is an excellent link to repeat, then you can do it. Note that editors may differ in their interpretion of "excellent", of course. We used to have an editor who would go around removing See alsos, no matter how helpful. He would either incorporate them into the text or remove them. That was a nuisance, but I've not seen anyone do that in a systematic way for years. SarahSV (talk) 00:31, 28 February 2017 (UTC)
"If something really is an excellent link to repeat, then you can do it"... not so easy. Sure it says ""As a general rule", but in fact if you're going against another other editor who doesn't agree with you, the person citing the rule has the whip hand. You need to make a case and gather a consensus that we have an extraordinary situation at hand. Difficult.
I mean, if our concern is to "See also section doesn't get too long", then it would literally be better to have a rule that says to remove See also links at random if the See also section is too long. As I said below, the converse of this rule -- "See also sections should only contain terms that are also linked in the article text" -- would likely be better.
I'm fine with a rule "See also sections should generally have no more than one entry per X paragraphs of text in the article" or "Should generally not have more than ten entries, period" or something. That's fine. But this rule is IMO possibly the worst way to approach trimming of See also's. Herostratus (talk) 01:47, 28 February 2017 (UTC)
  • Support For reasons set forth above. Butwhatdoiknow (talk) 01:35, 28 February 2017 (UTC)
  • Oppose. The nominator's discussion is very abstract. He says it is a poor rule but what does this poor rule obstruct? What is the benefit of lifting it? Please give me tangible example! On the other hand, I can argue what benefits this rule has. The way I see it, the links in the article body are most often associated with some sort of context or description. The links in the "See also" section are most often not. (Yes, it is encouraged, but who are you kidding? No one's doing it.) So, the rule prevents the section from becoming a list of indiscriminate items. Consider the Virtualization article as an example. It would be a very sad state of affair if we allow links for the different kinds of virtualization to re-appear in the "See also" section again. Or consider Albert Einstein article: How horrible would it be re-list all list that already appear in {{Main}} templates? (And this one is actually a large article, one that the OP claims is actually in a disadvantage from the rule.) —Best regards, Codename Lisa (talk) 06:39, 28 February 2017 (UTC)
P.S. Even if this rule is lifted, I will continue removing those "See also" links that I had removed in the past, only this time I will cite WP:REPEATLINK. And there is a reason to it too: I have never removed a link from "See also" whose existence improved the article despite this "rule". MOS is a guideline and I treat it that way. —Codename Lisa (talk) 06:43, 28 February 2017 (UTC)
Sure, User:Codename Lisa. What brought this over my attention was over at Pathological science. There're eleven links in "See also" (I don't have an opinion on whether that's too many or not). An editor came along and deleted some of them citing the rule. One of the links he kept was Paradigm shift. He kept it because it wasn't linked in the article -- and why should it be? It didn't appear in the article because it has literally nothing to do with the subject of the article. Another one kept was Science. The word "science" does appear in the article, but it's not linked. I presume it's not linked because it's a basic term, and it'd be overlinking to link it.
Other links, such as Junk science, were linked in the article (makes sense -- that term is somewhat related to the subject of the article!), and consequently became ineligible for the "See also" section and were deleted.
So OK. The reader reaches the end of the article, but maybe she wants more. Well, where can he go? What are we going to offer him? Well, we have Paradigm shift (I suggest we also add Battle of Okinawa. Why not? It's an important and interesting subject, and has just as much to do with the subject of the article.) The reader can also access Science (and since we're going for the big-picture here, let's also add Matter, Time, and The Universe -- those are scientific subjects, and the reader might well enjoy those articles too.) What she can't do -- we're not going to let her! -- is easily access Junk science or Pseudoscience. And we're not going to offer those links precisely because they are reasonably closely related to the subject of the article she's reading, demonstrated by the fact that they appear in the article text.
Silly way to run a business IMO. Poor way to treat the reader.
And no, I'm not going to and curate that article and fuss any more over its "See also' section. I can't really argue the point, because the other editor -- who believes that "See also" is a to-do list for editors -- has the rule behind him, and thus the whip hand. That's not the point, and I've other things on my plate. I have that article on my watchlist, like a lot of others, to notice and defend it against nonsense edits. But I guess this is one type of nonsense edit that people want, so OK. Herostratus (talk) 02:04, 2 March 2017 (UTC)
If your problem is that I did not remove the paradigm shift link and the science link, then you should not revert the deletions I did. Instead you should delete the paradigm shift link and the science link. What is this, a displacement activity? I just missed those links, otherwise I would have deleted them too.
Also, you are arguing against introducing links nobody wants, such as "The Universe". Why are you doing this? People who have good reasons for their opinions should use those. Bad reasons should be left to those people who don't have any good ones. --Hob Gadling (talk) 10:14, 2 March 2017 (UTC)
  • Oppose – I agree with SlimVirgin's and Codename Lisa's reasoning above, and in my experience, contrary to the assertion below, it's not observed only sporadically but widely. -- Michael Bednarek (talk) 12:04, 28 February 2017 (UTC)
  • Oppose It is the very nature of wikis, by virtue of their wikilinks, that their articles are "see also" sections for their topics. The only reason to have a "see also" section at all is to have a place for links that are tangentially related but don't figure into the narrative of the article, or haven't been fitted into it yet. If the restriction is lifted, then I don't see a natural limitation. In a biographical article that describes a person's associations with many other people over decades, all of them wikilinked, what would keep others from thinking "Hey, he worked with X, we should suggest to readers that they also see X", with the "see also" section ultimately containing dozens of links and thereby rendering the section fairly useless as a means of focus on especially related topics. Largoplazo (talk) 12:37, 1 March 2017 (UTC)
  • Oppose. It's a "see also" section, not a "see again" section; the implication to the reader is that we're presenting some further topics in addition to the ones that have already been discussed in the article. Herostratus's understanding below of see-also sections as "here is list of related articles which we have curated which bear closely on the subject" seems mistaken, and not, I think, how see-also sections are composed in practice - this sounds like it's more closely describing navboxes, or the links we might expect to see in an article's lede section. --McGeddon (talk) 13:11, 1 March 2017 (UTC)
  • Oppose Presumably readers who arrive at "See also" have read the article, or those parts of it that interest them, and already had the chance to follow any wikilinks that they thought might be useful for their particular interest. "To-do list": it's both: for the reader, "this article doesn't (yet) give a comprehensive account of its topic, but these links may help to cover further angles"; for the editor, "this article would benefit from expansion so as to show the connections with these further topics". If "See also" contains irrelevant or over-general links, that's the fault of the "tangentially related" clause, which I think needs review: Noyster (talk), 09:41, 2 March 2017 (UTC)
  • Oppose per SlimVirgin/Codename Lisa/Largoplazo. I can't improve on their reasoning. I sympathize with the proposer in that perhaps the guidelines could do more to explain scenarios where a link in the article prose could reasonably be repeated in the See also section. Stevie is the man! Talk • Work 22:42, 22 March 2017 (UTC)
  • Oppose User:McGeddon sums it up excellently. Primergrey (talk) 04:35, 23 March 2017 (UTC)
  • Oppose I agree with User:McGeddon and User:Primergrey, "see also" is not "see again" Seraphim System (talk) 13:22, 9 April 2017 (UTC)

Threaded discussion: remove the proscription against previously-linked terms in the "See also" section?

Another editor has invoked this, and looking at it, it seems a poor rule.

For long articles, there's no real reason to it. The original introduction of a term, with its link, may be many paragraphs above and kind of lost among the text. Gathering links to a few of the most cogent articles together into a special section where we can say "Hey, if you're interested in the material in this article, here is list of related articles which we have curated which bear closely on the subject, and which we suggest might broaden or deepen your understanding of the general subject". That's what a "See also" section is for, I guess. Whether the term was introduced somewhere in the article does not bear terribly strongly on that, either way.

In fact, thinking about it... if you've got some terms in the "See also" section, and some of them have been introduced in the the text and some haven't, isn't it kind of backwards to proscribe the ones that have been introduced in the text? Aren't those more likely to bear on the subject? Maybe not in particular cases, but statistically speaking if you analyzed a bunch of articles? Maybe a better rule would be "As a general rule, the "See also" section should not introduce links that do not appear in the article's body, because if the text hasn't seen fit to mention them before maybe they are not that germane". I'm not suggesting that, but if you have an existing rule, and a good case can be made that its exact opposite might be a better rule, you just might have a not-so-great rule on your hands.

Anyway... presenting different ways for the reader to access information is, mostly, a good thing. Not always -- we don't want to overwhelm or confuse the reader. But generally, because people are approaching the article from different perspectives, and because people think differently, it's OK to be of the mind "Let's let them access the information from Location X or from Location Y". IMO this is good interface design.

This rule might apply to short or very short articles, I guess. If you have a two-paragraph article maybe you don't want have two links to the same article, since they would be pretty close to each other, and thus WP:OVERLINK could come in. I don't think it's worth having the rule just for that.

Also FWIW -- and it's worth quite a bit IMO -- is this rule even followed that much? I've been around an while and it never came across my radar before. Rules are supposed to codify general/best practice, and if this rule is only followed sporadically -- not sure, but could well be -- that's another reason for sending it to the bit bucket. Herostratus (talk) 18:01, 27 February 2017 (UTC)

Another thought is, that if you're called on this -- and maybe you can invoke the "As a general rule..." clause and the "Whether a link belongs in the 'See also' section is ultimately a matter of editorial judgment and common sense" sentence, and win the argument for an exception, but if you have a rule the assumption is that in most cases it's going to be applied and enforced -- you're then left with the conundrum "should I delink the occurrence in the article body, even though it's appropriate and useful there, so that I can link to the article in the See also section, where it might be even more useful?". I'm not see how presenting editors with this choice is helpful to the reader. Herostratus (talk) 22:57, 27 February 2017 (UTC)

Re: "only followed sporadically"—often a "See also" section is created at an early stage in the article's history, and later on items in that list are added to the body of the article without deleting them from the list. They're not necessarily in both the "See also" section and body deliberately. Curly "JFC" Turkey 🍁 ¡gobble! 23:07, 27 February 2017 (UTC)
Yeah OK, but are you saying it matters? If it was was first in "See also" keep it there and delink the article text, and if the converse, delete the "See also" link? Besides being very random, it'd be a huge pain to paw through an article history to determine this.
The rule doesn't (and can't really) allow for this, just says "should not repeat links". Under this rule, a person could certainly go on a campaign (even write a bot) to go through articles and either trim out all the offending links or delink them from the article text. That's what brought me to make this RfC, an editor doing this and citing the rule (might have been just that article rather than a campaign, but soon or later a campaign (or bot) is certainly possible).
If for some reason we want to keep this rule, I guess we need to go to Wikipedia:Manual of Style/Linking and add the admonition "As a general rule, links that exist in the an article's "See also" section should not be linked to in the article body". Right? Or something. I guess we would need to have a debate over what to do when duplicate links in both places are found or desired: 1) generally, remove it from "See also" or 2) generally, delink it in the article text, or 3) provide no guidance and let editors argue over each case. Such a debate would be Alice-In-Wonderland-level nonsense IMO but I guess we'll need to have it. Herostratus (talk) 00:07, 28 February 2017 (UTC)
"are you saying it matters"—I wasn't saying any more than that such duplication is (most?) often just cruft. You'll notice I haven't !voted—I really don't have a strong position, other than that it may open the floodgates to people endlessly appending everything they can think of into the "See also" section. Curly "JFC" Turkey 🍁 ¡gobble! 01:27, 28 February 2017 (UTC)
"If it was was first in "See also" keep it there and delink the article text"—I didn't notice this. That's a terrible idea. Curly "JFC" Turkey 🍁 ¡gobble! 01:28, 28 February 2017 (UTC)
Yes, it is. They're all terrible ideas except "get rid of this furshlugginer rule". Herostratus (talk) 01:34, 28 February 2017 (UTC)
A "see also" section provides links that one can also see. It's no more a "rule" than saying that an "infobox" needs "info". These aren't Wiki terms of art. If you think that there is a desire for a "see again" section, propose it. Primergrey (talk) 04:46, 23 March 2017 (UTC)

Maybe the problem is "As a general rule," What about removing that and replacing it with "Except when the link has a strong connection to the article," (or something similar). That would give more guidance regarding when there is an exception to the rule. Butwhatdoiknow (talk) 12:24, 1 March 2017 (UTC)

Doing this defeats the purpose of the rule. Links that appear in the prose have a strong connection with the article and that's why they are there. —Codename Lisa (talk) 12:57, 1 March 2017 (UTC)
Notice I said "or something similar." What standard would you propose? Butwhatdoiknow (talk) 01:09, 2 March 2017 (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.

RFC on bottom matter

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)

Position of {{Expand French}} etc

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'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.

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)

Placement of expand language templates

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.
As has been pointed out elsewhere, assessing an RfC is not merely a matter of counting noses. There is a reason we refer to arguments made by editors in discussions as "!votes", after all. When a template is used in a relatively consistent manner by a large number of editors across a wide number of articles, such usage is a "silent" consensus. It is argued here and in related discussions that consensus can change and that is 100% correct. For consensus to change, however, proponents of the new position must gain the agreement of their fellow editors and that has clearly not happened here. Furthermore, there are no policy-based or source-based reasons expressed below that would require "discarding irrelevant arguments." As such, the discussion is best summarized as supporting the previous consensus, and the templates should be placed at the top of the relevant articles. This "early" close is in conformity with WP:RFCEND and explicit request on WP:ANRFC. Please also see WP:CLOSECHALLENGE. (non-admin closure) Eggishorn (talk) (contrib) 16:15, 30 June 2017 (UTC)

Should the expand language templates be placed at the top of the article or toward the bottom?

Context:

  • A previous RfC was held in 2012 here and failed to reach consensus based on lack of participation.
  • A brief discussion was had in 2012 here, and resulted in an editor boldly adding guidance to add them to the reference section, which was never really followed and eventually removed in 2014.
  • The guidance was again changed in August 2016, which resulted in a short edit war, and the language remaining until last month, which started the current discussion (see above) and lots of ANI drama. TimothyJosephWood 12:54, 17 June 2017 (UTC)
  • Please note: "Toward the bottom" is not an allusion to the suggestion it be put in the reference section (as in the abandoned 2012 proposal), but rather that it be treated similarly to a stub template, as in the current placement at Soyons and Parchin. TimothyJosephWood 12:01, 18 June 2017 (UTC)

Survey: Placement of expand language templates

  • Top As with other cleanup/maintenance/"you should be aware of this"/"you can help with this" templates. It's not even remotely realted to the References section, unlike {{refimprove}} which is sometimes placed in the References section and has the (debatable) merit that it relates directly to that section. --Redrose64 🌹 (talk) 20:27, 17 June 2017 (UTC)
    The bottom alternative is unrelated to References. It is just at the bottom, as the stub template is. This is a "you can help with this" template. Symmetry is good. Still, symmetry should not be applied when it is bad for the readers, as is this case. --Ettrig (talk) 13:47, 21 June 2017 (UTC)
  • Top For reasons stated above on this page and at Wikipedia talk:Translation. Calliopejen1 (talk) 00:46, 18 June 2017 (UTC)
  • Top Because I can't think of any reason why they should move to the bottom. The stub templates, at least, are by definition posted to short articles, so they can generally be seen as soon as an article is displayed even though they're at the bottom. Frankly, I'd be in favor of moving the {{uncategorized}} template to the top. Largoplazo (talk) 13:10, 18 June 2017 (UTC)
    I have given a reason below. --Ettrig (talk) 13:47, 21 June 2017 (UTC)
    Actually, you've given a reason for deletion or making the template invisible, not for changing the placement. — Arthur Rubin (talk) 22:15, 26 June 2017 (UTC)
  • Top, no reason to change our standard practice here, or to treat these differently from other maintenance templates. But let's modify the documentation to make clear that these should only be deployed when there is verifiable real value in translating – i.e; when there's well-written and adequately sourced content in the other-language page. Justlettersandnumbers (talk) 08:11, 19 June 2017 (UTC)
    I have given a reason below. Sadly, a large majority of the usages of the Expand French template point to articles marked as stubs. --Ettrig (talk) 13:47, 21 June 2017 (UTC)
  • Top of the article, the current predominant practice, per WP:EDITCONSENSUS. —Best regards, Codename Lisa (talk) 08:32, 19 June 2017 (UTC)
  • Top: they go with the group of templates which are displayed there. PamD 11:10, 19 June 2017 (UTC)
  • Top: No reason to change, in spite of the August 2016 change in the instructions. (They were also, among other arbitrary edits, added by the banned "Michigan Kid".) One could make a case for the talk page (although that screws up categorization), or a new "Resources" section toward the bottom. Placing them at the bottom along with stub templates would be completely worthless, and placing them in one of the current bottom sections would likely be counterproductive. — Arthur Rubin (talk) 02:18, 20 June 2017 (UTC)
    I have given a reason below. --Ettrig (talk) 13:47, 21 June 2017 (UTC)
    For those who claim there is no consensus for placement at the top, they have almost always been there since the templates were created. The status quo is clearly "top". — Arthur Rubin (talk) 02:30, 20 June 2017 (UTC)
    Arthur Rubin I took the liberty of correcting the typo (?) temolates to templates in your above statement. Hope you don't mind, d.g. L3X1 (distænt write) )evidence( 01:30, 21 June 2017 (UTC)
  • Top Per RedRose64 and others. d.g. L3X1 (distænt write) )evidence( 01:30, 21 June 2017 (UTC)
  • Bottom The maintenance tags are deliberately designed to disturb the flow of reading. This causes a cost to the reader. This is a small cost that occurs a large number of times. Placement at the bottom would reduce this cost substantially. The possible gain that this price may buy is that it inspires a translator to translate. This would be very valuable if it occurred. It is very doubtful that it does occur. The vast majority of these tags have been in place more than six years. The editors who are capable of and willing to translate have no difficulties finding such material. A tag like this is not inspiring and has not inspired. --Ettrig (talk) 06:25, 21 June 2017 (UTC)
    Hi. That analysis is at best narrow-sighted. This tag is useful for the reader. I've seen them many times, and in almost all of those cases, I went and read the other language's article. Google Translate helped too. Not only did I not find it an obstruction, I found it what mattered most to me. Make no mistake, translation is mind-numbing job, especially when it is from or to Japanese. —Codename Lisa (talk) 06:56, 21 June 2017 (UTC)
    narrow-sighted is void of factual content. Did you really need this banner to find the french article? I have seen thousands. About 98% are about material that is obviously french in nature, and the inter-wiki link is always there. I would suggest that you are very unrepresentative if you do need this banner to find the french article. Yes, translation is hard work. That is one of the reasons this banner very seldom has the intended effect. Why did you mention this? Maybe it is a good idea to provide an easy link to google translate. In that case it should be handled as other good tools. Provided in the tools list and made available on all articles. It should not be where the reader expects the content to begin and it should not be restricted to a small subset of the articles where the user may need it. --Ettrig (talk) 10:44, 21 June 2017 (UTC)
    When there are 26 other languages of one given article, it is useful to know when one has a lot of appropriate contents. Otherwise, you have to click on 25 other links. —Codename Lisa (talk) 13:13, 21 June 2017 (UTC)
    I have already answered this argument. This conflict arose about Expand French. In the thousands of articles with this template that I have seen, in the vast majority, say 98%, the content was obviously French in nature, typically a French commune, so going to the French article was obvious. This template is addressed to people who are able to translate from French to English, so again, clicking on that link would be natural. It is a bit dis-orienting that the argument for handling this message as a maintenance tag is that it is a convenient way to activate automatic translation. --Ettrig (talk) 13:47, 21 June 2017 (UTC)
    Be that as it may, this discussion is no longer about {{Expand French}} alone and whatever case in which you were involved. As such, "what it was about" has no bearing on my decision. In my case, the articles that I visited most led me to the Japanese Wikipedia. —Codename Lisa (talk) 07:31, 22 June 2017 (UTC)
  • Top per Codename Lisa and others. Lepricavark (talk) 03:15, 22 June 2017 (UTC)
  • Bottom If there were any evidence at all that these tags are a catalyst for article-improvement, then sure, top. There is not. I understand the position that tags go at the top and there's no pressing reason to make an exception in this case. I suppose it's a valid argument, but it still seems like process-for-the-sake-of-process. These tags do next to nothing in the way of a better article, rendering them little more than an eyesore and a distraction. Joefromrandb (talk) 19:45, 24 June 2017 (UTC)
    Hi. The first step in solving any problem is giving due notice. If it is useless, nominate it for deletion. Otherwise, putting it at the bottom is a dishonorable way of circumventing a deletion discussion, because something that is admittedly useless at the top is definitely even more useless at the bottom. Our mobile readers do not see these tags anyway. —Codename Lisa (talk) 07:07, 25 June 2017 (UTC)
    This response is not relevant for this discussion, because Expand Language does not point out a problem. The word dishonorable is totally out of place in this discussion. Placement at bottom is used for stub tags. It is seeable and adds categorization. This is a solution that the community has adopted to a very high degree for articles that are very short (stubs), which is a problem, albeit not grave. This response seems to assume that items at the top get more attention. This is true. That is why we should place the most important items there. It also seems to assume that this marking at the top can cause a translation. It is very doubtful that this happens with a sufficiently high frequence for the tag to be important. For it to be important it is also necessary that the translation be more valuable than what that editor would have done otherwise. This is also in doubt. There is extremely little activity on the 1500 or so that I have on my watchlist, so editors in general seem to think that these articles are not important. --Ettrig (talk) 20:48, 25 June 2017 (UTC)
    My compliments. I'm used to users attempting to disguise the straw man when they bring him out, but that's Ray Bolger dancing on the Yellow Brick Road right there. Here I was, thinking I was responding to a request for comment by adding my 2 cents to the discussion. Turns out I'm actually "circumventing a deletion discussion", compounding the felony, no less, by doing so "dishonorably". If you could kindly point me to this deletion discussion, I'll be happy to add my 2 cents there as well. "Something that is admittedly useless at the top is definitely even more useless at the bottom." Say what, now? First of all, that is utterly impossible. If something is "useless" it cannot ever become "more useless". Ever. In any case, I do not think the template is "useless". I think it is a low-value template, and as such, should not be placed in a high-value area of the article. Unlike other tags that (in theory, at least) point out problems with the article that need to be fixed, this one simply offers a suggestion as far as one way in which the article may be expanded. Tags that point out problems (when used correctly) alert the reader to keep certain caveats in mind while gathering the facts he or she is seeking. The "Expand: 'X'" tag does not. These are internal housekeeping memos, through which we editors offer suggestions to each other. 99% of our readers are not editors. "Our mobile readers do not see these tags anyway." Say what-a-what, now? Mobile readers who choose to view in desktop mode, as I do, do, in fact, see these tags. Our non-mobile readers do as well. I don't follow the logic in arguing to keep it at the top because some readers won't see it. Joefromrandb (talk) 07:17, 26 June 2017 (UTC)
    I don't agree with Lisa's wording, but these templates serve NO purpose at the bottom, other than categorization. If placed at the bottom, a rational argument could be made for deletion. I'm not saying that's your intent, but it could very well be the effect of the change in placement. — Arthur Rubin (talk) 14:47, 26 June 2017 (UTC)
  • Top per the template being categorised as a maintenance template, through Category:Language maintenance templates → Category:Wikipedia translation templates → Category:Expand by language Wikipedia templates. MOS:ORDER clearly states that maintenance tags go before the lead section. EP111 (talk) 17:32, 26 June 2017 (UTC)
    We cannot expect the writers of that guideline to have considered all the low importance messages that editors would write using this template. So the question still remains: Is it good for the reader to find this at the top of the article? I have explained above why it is not. --Ettrig (talk) 18:43, 26 June 2017 (UTC)
    Describing the template as low importance is a matter of opinion. A more worthwhile discussion might involve limiting the use, of {{expand language}}, to those articles which have more than perhaps 20k of untranslated content in the foreign language wiki (i.e. en.wiki has an article size of perhaps 15k, and fr.wiki has a parallel article of perhaps 40k). EP111 (talk) 13:51, 27 June 2017 (UTC)
    Of course importance can be discussed, for example in terms of what good is provided to the reade. I did that in brevity in my entry above. And the guideline guideline says that conflicts are to be solved primarily by discussion. --Ettrig (talk) 18:05, 27 June 2017 (UTC)
  • Top. This is a maintenance template; it helps both the readers and editors by leading them to where more information can be found, both for learning and expansion of the article. Just because very few people can act upon it is not valid ground for furtively suppressing its effect. Wikipedia is a work in progress and will always be. Make peace with that fact. Also, neither {{Expand French}} is the only template in Category:Expand by language Wikipedia templates nor is French Wikipedia the only point for importing additional material. FleetCommand (Speak your mind!) 14:56, 30 June 2017 (UTC)

Threaded discussion: Placement of expand language templates

  • Comment Can you please reword the Rfc so that all the standard votes like support, strongly support, weakly support and all the parallel oppose votes make sense? Why not formulate it per Ettrig's request, and say something like, Should Expand language templates be placed with the bottom matter? This allows the full panoply of support/oppose votes that the current wording does not. Mathglot (talk) 14:59, 17 June 2017 (UTC)
  • I'm just going to reping User:Redrose64 after adding a clarifying note. Apologies for being unclear in my word choice. The main factions here seem to be whether it should be treated similarly to the suite of {{Multiple issues}} templates, or whether it should be treated more-or-less as a companion to a stub template. Compare placement on Soyons and Parchin. TimothyJosephWood 12:06, 18 June 2017 (UTC)
  • Above, Ettrig says: "Sadly, a large majority of the usages of the Expand French template point to articles marked as stubs." This is a reason to remove the template and/or change the instructions about when it should be applied, not to reposition all of the translation templates. Calliopejen1 (talk) 18:34, 21 June 2017 (UTC)
    Agreed. Although it is better if it is at the bottom than at the top, in this situation, this was not meant as an important argument. It is just a comment to a comment. --Ettrig (talk) 20:23, 21 June 2017 (UTC)

WP:CON says: When agreement cannot be reached through editing alone, the consensus-forming process becomes more explicit: editors open a section on the talk page and try to work out the dispute through discussion. Here editors try to persuade others, using reasons based in policy, sources, and common sense; they can also suggest alternative solutions or compromises that may satisfy all concerns. The normal process is that differences are solved through editing. When there is difficulty in reaching an agreement, the next step is discussion. This issue was in a quasi-consensus state. The edits were overwhelmingly top. This placement was sometimes challenged, but the discussions died out without reaching any conclusion. Note that even if there is an edit consensus, it is always up for challenge, and then there is to be a discussion. Most of the statements for TOP claim that status quo holds because it is status quo and that no other motivation is needed. This view is not in line with the guideline. --Ettrig (talk) 09:29, 26 June 2017 (UTC)

  1. Most of the discussion in other fora relates to your editing against consensus. The fact that consensus has been established is more relevant there.
  2. The template serves no purpose at the bottom other than to add the maintenance category; if placed there, it might as well be invisible, in which case, it might as well be at the top. The only reason the template might need to be visible is that if the foreign language article is not matched in Wikidata, which could happen if the en.Wikipedia article is more specific or more general than the foreign language article.
  3. The only templates placed at the bottom are some horizontal navigation templates and stub templates, and perhaps {{uncategorized}}. A reason why it doesn't hurt to have stub templates at the bottom is that stubs are short, so the template should still be visible at first glance. Expand language templates seem (to me) more similar to other maintenance templates than to "stub" or {{uncategorized}}.
— Arthur Rubin (talk) 14:19, 26 June 2017 (UTC)
No 2 is the important aspect. There is no purpose for this tag that is nearly important enough to motivate that it be placed at the most prominent place in the article. If you think there is, then tell us about it. --Ettrig (talk) 18:31, 26 June 2017 (UTC)
When consensus is broken there is to be discussion. I have discussed whenever anyone has wanted to. There has been very little of that until recently. Even lately, there has been extremely little of trials to explain why it would be good to place this tag at the top. When the discussion has waned away, I have continued editing. This is the normal process. Your view that there is a consensus and that therefore no discussion is needed is not in agreement with the guideline. --Ettrig (talk) 18:43, 26 June 2017 (UTC)
There is a present consensus that the templates should be at the top. Whether they should be made less visible (or entirely invisible, serving only to put the article into the maintenance category) is a matter for another forum. You seem to be saying the template is normally useless. Fine. Propose deletion, then, rather than proposing a change which we all agree makes it completely useless. — Arthur Rubin (talk) 21:59, 26 June 2017 (UTC)
Consensus can change, but your arguments support deleting the template, rather than changing placement. — Arthur Rubin (talk) 22:11, 26 June 2017 (UTC)
There are some words here, but no motivation why it would be good to place this tag at the top.--Ettrig (talk) 04:59, 27 June 2017 (UTC)
Because the template highlights a problem and the first step in solving any problem is revealing it.
Consensus can change but your reason for changing it is despair on your part. I don't share it. Wikipedia is a work in progress. It will always be.
—Codename Lisa (talk) 08:47, 27 June 2017 (UTC)
No, it does not point at a problem. If you think it does, tell us what problem that is. My feelings are not to be discussed here. I have stated my motivation for change. I see no refutal of that motivation. --Ettrig (talk) 09:39, 27 June 2017 (UTC)
That the article is incomplete, evidenced by its peer written in another language. Seriously, you don't think people put this tag over Featured Articles, do you? —Codename Lisa (talk) 09:52, 27 June 2017 (UTC)
That the article is incomplete is not a problem, it is just the normal state of affairs in Wikipedia. The number of GAs and FAs is growing much, much slower than the total number of articles. And even if this was seen as a problem, the non-completeness (in this sense) can be readily detected by the absence of GA and FA tag. As I have answered you before, the large majority of the tags I have seen (and I have seen a lot of them) have pointed to articles about material that is obviously of more interest to the speakers of the other language. Again, that the French write more about most French communes than the English do, is not a problem, it is just natural. Your are repeatedly contemptuous and confrontative. Try to consentrate on the factual argument. --Ettrig (talk) 11:02, 27 June 2017 (UTC)
And the discussion on the content turned into direct personal attacks, complete with the pot calling the kettle black. We're done. Going into WP:DFTT mode. If anyone else also thinks the best way the persuade me to change my verdict from "Top" to "Bottom" is calling me "contemptuous and confrontative [sic]", please be my guest. —Codename Lisa (talk) 06:10, 28 June 2017 (UTC)
The comments on you refer to what you have written in this discussion.--Ettrig (talk) 07:46, 28 June 2017 (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.

WP:FURTHER

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:

Question?

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":

checkY

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

MOS:BODY

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)

A suggested edit in the "See also" guideline

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)

Use of {{section link}} in See Also sections

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:

Versus:

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)

Q: Specifics on "1. Before the lead section" #3: "Maintenance / dispute tags" order?

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)

Sub-headings size is the same

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)

Conflict with Category:Kvng RTH

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)

See also and redirects

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)

"See also" section and navigation boxes

Closing this discussion as per the request at Wikipedia:Requests for closure. The consensus here is in opposition to the change suggested. Fish+Karate 09:25, 13 February 2018 (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.

Noticed we had a few editwars over links removed from "See also" sections because the links were in the footer template (pointing here for validations). I think our rule on this needs updating as 50% plus of our readers dont see footers because of mobile view limitations. Think its best we remove the bold text as outdated that makes navigation harder for our mobile readers.--Moxy (talk) 15:23, 26 December 2017 (UTC)

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

Link updated above. DexDor (talk) 18:32, 11 January 2018 (UTC)
No need as most oldtime editors are doing this anyways since the 2 editors got banned.--Moxy (talk) 22:32, 19 January 2018 (UTC)
  • Oppose See also sections will become dumping grounds. As is, some editors put in links when no article exists. I know because I clean these sections up....William, is the complaint department really on the roof? 15:03, 19 January 2018 (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.

Sections and subsections

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

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)

Talk:Lesbian literature#See also

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)

Article status tag placement

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)
Retrieved from "http://en.wiki.x.io/w/index.php?title=Wikipedia_talk:Manual_of_Style/Layout/Archive_12&oldid=1137421820"