Revision as of 16:36, 21 July 2020 editBuidhe (talk | contribs)Autopatrolled, Extended confirmed users, Page movers, File movers, Mass message senders, New page reviewers, Pending changes reviewers, Template editors136,147 edits →...or not see also...: Replying to RTG (using reply-link)← Previous edit | Revision as of 16:36, 21 July 2020 edit undoVaulter (talk | contribs)Extended confirmed users, Pending changes reviewers, Rollbackers20,662 edits →...or not see also...Next edit → | ||
Line 99: | Line 99: | ||
::And navboxes are not visible to non-mobile casual wiki-users who do not know to hit the "end" key to find the buried navboxes. They're also not as far ranging as a See also section can be. I '''support''' the proposed change. Or, alternatively, permit a statement in See also that says something along the lines of "more related links at the bottom of this page." ] (]) 16:18, 21 July 2020 (UTC) | ::And navboxes are not visible to non-mobile casual wiki-users who do not know to hit the "end" key to find the buried navboxes. They're also not as far ranging as a See also section can be. I '''support''' the proposed change. Or, alternatively, permit a statement in See also that says something along the lines of "more related links at the bottom of this page." ] (]) 16:18, 21 July 2020 (UTC) | ||
*'''Oppose''' any change. "See also"s tend to spiral out of control - Butwhatdoiknow's talk of "far ranging" is alarming. Templates & navboxes are also far too common - cruft that some people like to add everywhere, cluttering up pages. The category scheme is generally all the reader needs. ] (]) 16:27, 21 July 2020 (UTC) | *'''Oppose''' any change. "See also"s tend to spiral out of control - Butwhatdoiknow's talk of "far ranging" is alarming. Templates & navboxes are also far too common - cruft that some people like to add everywhere, cluttering up pages. The category scheme is generally all the reader needs. ] (]) 16:27, 21 July 2020 (UTC) | ||
*'''Oppose''' as Johnbod says, too much "see also" is a much bigger issue than too little. We should focus on reducing these sections, not expanding them. (] · ]) ''']''' 16:36, 21 July 2020 (UTC) | |||
*I don't see the point of this request. ] neither requires see also sections, nor does it disallow them. The matter should be decided on a case-by-case basis. '''<span style="border: 1px #8C001A solid;background:#8C001A">]</span>''' 16:36, 21 July 2020 (UTC) |
Revision as of 16:36, 21 July 2020
This is the talk page for discussing improvements to the Manual of Style/Layout page. |
|
Archives: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15Auto-archiving period: 3 months |
Format of appendicesBefore proposing a change to the standard appendices, please study Misplaced Pages:Perennial proposals § Changes to standard appendices. |
Manual of Style | ||||||||||
|
This is the talk page for discussing improvements to the Manual of Style/Layout page. |
|
Archives: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15Auto-archiving period: 3 months |
MOS:ORDER in regards to Template:Featured article, Template:Good article, and similar templates
So ... I'm looking at MOS:ORDER's target, and it says nothing about where templates such as {{Featured article}} and {{Good article}} should go. If I had to guess, they would be placed with the "Deletion/Protection tags (CSD, PROD, AFD, PP notices)" section, but that, of course, is just my thought. Either way, this information obviously needs to be added to this page; so ... where should they go? Steel1943 (talk) 19:06, 8 April 2020 (UTC)
- Steel1943, please see the sublist under item 4 "End matter":
5. {{Featured list}}, {{Featured article}} and {{Good article}} (where appropriate for article status)
. Also, there is a related ongoing discussion (albeit it slowed down) at #Nothing should go between navboxes and authority control. —andrybak (talk) 19:45, 8 April 2020 (UTC)- Yay, I can't see stuff. Disregard my silliness. Steel1943 (talk) 20:58, 8 April 2020 (UTC)
A bot to move incorrectly placed hatnotes?
I often see hatnotes placed below maintenance templates, and occasionally also below infoboxes. I'm thinking of asking for a bot to go around and move such hatnotes back up where they belong according (per MOS:ORDER and WP:HATNOTEPLACE). Does anybody think this might not be a good idea?
The main question is whether such a bot should only move a hatnote if this is going to make a visual difference, and so skip e.g. hatnotes that only have engvar templates or protection icons above them, or if it should move all "incorrectly" placed hatnotes even if this means that no changes will result in the rendered page. The former has the advantage of avoiding flooding watchlists with minor, almost cosmetic, edits, while the latter should be easier to program and would result in greater consistency in what appears in the editing interface. Thoughts? – Uanfala (talk) 23:28, 23 April 2020 (UTC)
- I am for this! comrade waddie96 (talk) 12:05, 15 May 2020 (UTC)
- @Uanfala: I fully support the creation of a bot; I spend a lot of time fixing these hatnotes when I see them! Of the two options you present, I support moving ALL incorrectly placed hatnotes, because part of the justification for WP:ORDER is stated as follows in WP:HNP:
Text-based web browsers and screen readers present the page sequentially.
Correctly placing all hatnotes would fix problems for these non-visual methods of display. — Goszei (talk) 09:07, 29 June 2020 (UTC)- Do screen readers read maintenance templates? If not, WP:COSMETICBOT ought to be observed. -- Michael Bednarek (talk) 10:53, 29 June 2020 (UTC)
- Why wouldn't they? Just in case, I've just tested with one screen reader simulator on a random page, and yes, it does read out the {{refimprove}} template; and because of all the links in there, it takes a very long time doing so. – Uanfala (talk) 15:49, 29 June 2020 (UTC)
- I meant those that you mentioned earlier: engvar, protection, and use-date-format, citevar. -- Michael Bednarek (talk) 01:50, 30 June 2020 (UTC)
- Why wouldn't they? Just in case, I've just tested with one screen reader simulator on a random page, and yes, it does read out the {{refimprove}} template; and because of all the links in there, it takes a very long time doing so. – Uanfala (talk) 15:49, 29 June 2020 (UTC)
- Do screen readers read maintenance templates? If not, WP:COSMETICBOT ought to be observed. -- Michael Bednarek (talk) 10:53, 29 June 2020 (UTC)
RfC Verifiability in See also sections
I have encountered the claim that adding a link doesn't require a citation
, even when WP:CHALLENGEd. (To be clear: I did not ask for an inline citation, merely that one be provided on the talk page.) Another editor subsequently claimed that MOS:SEEALSO's criterion of "editorial judgment and common sense" is among the things that go beyond the verifiabilty principle
.
My reasoning is that, since See also links have to be relevant, adding a link comes with the implicit claim that the linked topic is relevant to the one at hand. In this particular instance, the stronger claim was made that the linked topic is an instance of the topic linked from. Since all content must be verifiable, I don't see how See also should escape one of our pillars. That needs to be clarified here, regardless of the outcome of this RfC. Paradoctor (talk) 15:16, 23 May 2020 (UTC)
Per Nikimaria: Does "editorial judgment" override WP:V for the purpose of determining whether to keep links in See also sections challenged on the grounds of relevance?
- Hi Paradoctor, if you want to start an RfC here could you please include a brief neutral question as per WP:RFCOPEN? I could infer one from your statement but it'd be better for you to make it clear. Nikkimaria (talk) 15:28, 23 May 2020 (UTC)
- Actually, I'm going to remove the RFC tag. This does not seem ripe for an RFC at this time. The question is probably reasonable but we don't need all and everyone to comment on the topic at this time. --Izno (talk) 16:30, 23 May 2020 (UTC)
- That's not your call. If you don't wish to comment, then don't. Paradoctor (talk) 16:48, 23 May 2020 (UTC)
- Actually it is (and any one's) per WP:RFCBEFORE. Only questions which have have had previous multiple content dispute mechanisms tried, and consensus failed to be obtained, should resort to using an RFC. To boot, this is a relatively benign question. I'll remove it once more, but if you feel you must resort to an RFC on the matter, feel free to restore it. --Izno (talk) 18:03, 23 May 2020 (UTC)
- That's not your call. If you don't wish to comment, then don't. Paradoctor (talk) 16:48, 23 May 2020 (UTC)
- Actually, I'm going to remove the RFC tag. This does not seem ripe for an RFC at this time. The question is probably reasonable but we don't need all and everyone to comment on the topic at this time. --Izno (talk) 16:30, 23 May 2020 (UTC)
- Instead of asking for a "citation" consider asking for an "explanation." As Layout#"See_also"_section says: "Editors should provide a brief annotation when a link's relevance is not immediately apparent ..." That helps all readers, not just the person who asks for a citation on a talk page. (And nothing stops you from "improving rather than reverting" and adding your own explanation to clarify a See also entry.) Butwhatdoiknow (talk) 16:39, 23 May 2020 (UTC)
- Oh, an explanation exists. I disagree with it, because it is speculation not supported by the literature. This RfC is about links that have been challenged, about the standard for evidence that they are, in fact, relevant. Paradoctor (talk) 16:48, 23 May 2020 (UTC)
- Apparently this is a content dispute. Its specificity is to be related to the see also section. So this should be discussed in the talk page of one of the article, with notification to the talk page of the other articles, and to the relevant project(s). In case of a lack of consensus, the usual dispute resolution methods must be used. The manual of style cannot predict and avoid all content disputes. D.Lazard (talk) 17:35, 23 May 2020 (UTC)
"Very long" sections
The MOS says that "Very short or very long sections and subsections in an article look cluttered and inhibit the flow of the prose. Short paragraphs and single sentences generally do not warrant their own subheading." But is there an agreed definition of "very long"? Reviewing this article for A-class, I highlighted some sections that seemed to be "very long" (eg #Bolero—nine paragraphs) because they were over one screen length for me despite using small font, and likely to be several screens for mobile users. Is that a correct assessment of what is considered "very long"? Thanks! buidhe 06:45, 26 May 2020 (UTC)
- It's subjective, so no firm rule would be valid. --Redrose64 🌹 (talk) 09:35, 26 May 2020 (UTC)
Advice that needs changing
The page currently gives, as the last item (#9) in "Before the lead section", "Navigational boxes (header navboxes)". This is bad advice, more often wrong than right. It should either be removed completely (probably best) or considerably softened. For some years, these navboxes have proliferated hugely, as unfortunately we now have far too many editors who prefer writing these to actual sentences of text. Frankly, in a high proportion of articles they should just be removed, and an appropriate horizontal navbox used instead, where there is one. They should only be at the top of an article if there is no infobox or suitable lead image. In visual arts articles, my usual area, this is literally never the case. Yet drive-by fiddlers take the mention on this page, which I accept is cautiously worded, as justification to impose navboxes right at the top of the page, citing this policy as though it was a MOS obligation to have one. Johnbod (talk) 15:02, 27 June 2020 (UTC)
- Please point to an edit that you would like to have prevented, or which you did not like. --Izno (talk) 17:58, 27 June 2020 (UTC)
- Sure, this one - he is a persistent offender, always citing the policy. Or this one, from another. Johnbod (talk) 02:59, 29 June 2020 (UTC)
- I absolutely agree. in 80-90% of cases these boxes are just unnecessary clutter that adds nothing to the article, however, in a small number of cases they can be useful. buidhe 05:29, 29 June 2020 (UTC)
- In those specific cases, it seems those navboxes should be outright deleted per WP:NAVBOX:
There should be a Misplaced Pages article on the subject of the template.
—Bagumba (talk) 08:41, 29 June 2020 (UTC)- I don't actually seek to have the templates deleted, I just want this page giving the impression to careless tinkering editors that the MOS says they NEED to be at the top of the article. In this case - Template:History of Dutch and Flemish painting - Art of the Low Countries is the "main article" covering the same subject. This template isn't used on that many pages, and having removed it from the top of some (putting it near the bottom), I have left it near the top of others, especially where it occupies a central space opposite the TOC, so does not reduce the more important images. Johnbod (talk) 16:20, 29 June 2020 (UTC)
- Sure, this one - he is a persistent offender, always citing the policy. Or this one, from another. Johnbod (talk) 02:59, 29 June 2020 (UTC)
- Can we say something at WP:Layout#Navigation_templates about when to use header navboxes as opposed to footer navboxes? If so, what? Maybe "Avoid using header navboxes when there is a suitable infobox or lead image"?Butwhatdoiknow (talk) 18:19, 29 June 2020 (UTC)
- That would certainly be an improvement, though I'd also like to see changes in the list at the top. In the list, pretty much all the other items (1-8) should be at the top, where they exist. Navboxes are very different. The list:
"....the elements (such as sections and templates) that are used typically appear in the following order, although they would not all appear in the same article at the same time:
- Before the lead section
- Short description
- Hatnotes
- Deletion / protection tags (CSD, PROD, AFD, PP notices)
- Maintenance / dispute tags
- English variety and date style
- Infoboxes
- Foreign character warning boxes
- Images
- Navigation templates (header navboxes)"
- Discussed in 2018 and 2019.
- Misplaced Pages:Hatnote § Placement.
- These templates can also be placed at the end of an article. The matter was discussed in 2012, 2015 and 2014.
- Note that at the moment there isn't even a footnote as there is for Engvar & date format templates "These templates can also be placed at the end of an article". Generally, if smaller navboxes are needed at all, there may be many places in the article where they are best placed - for example in a section with no images. Maybe we should just add "(optional)" in the list, and "Avoid using header navboxes when there is a suitable infobox or lead image" to the section below, as suggested above. Is there approval for that? Johnbod (talk) 21:03, 29 June 2020 (UTC)
- Johnbod, I don't think that navboxes necessarily have to be avoided in every case where there is a sufficient lead image, see genocide for an article that currently has a navbox and a lead image below. I would support "Avoid using header navboxes when there is a suitable infobox or a lead image that is the subject of the article". (t · c) buidhe 22:15, 29 June 2020 (UTC)
- " a lead image that is the subject of the article" won't I think mean any changes in practice - "shows" the subject of the article, would be better, though likely lead to rows - how do you show genocide? Even persistent fiddlers would rarely I think put a navbox template above an image of the person in a biography. Most of the examples I see are subjects where the article subject is just an item in the navbox, not the same subject. Even so, I would have put the strong, horizontal pic at the top, leaving the navbox visible below. Johnbod (talk) 23:25, 29 June 2020 (UTC)
- Agree with above..... need to distinguish the difference between an infobox vs a navigational box. Nav aids definitely should be the last thing in the lead if there at all. We have a big problem as of late of editors trying to redirect readers to other pages before they've even seen the contents of the page they are on... this can be seen in the spaming of navigational templates, hat notes and banner templates.--Moxy 🍁 22:45, 29 June 2020 (UTC)
- Indeed - the genocide area does seem full of these. As well as Template:Genocide, there is Template:Genocide of Indigenous peoples, Template:Denial of Mass Killings, Template:Discrimination sidebar, and so on. Many of the articles coming off Template:Genocide have two of these in succession at the top. Johnbod (talk) 23:32, 29 June 2020 (UTC)
- Fortunately for the majority of reader's (60%+ mobile viewers) just see the lead image and not the look away from this article box.--Moxy 🍁 23:40, 29 June 2020 (UTC)
- I agree that two is overkill but I think one sidebar can be helpful especially on the main article. (t · c) buidhe 23:48, 29 June 2020 (UTC)
- Indeed - the genocide area does seem full of these. As well as Template:Genocide, there is Template:Genocide of Indigenous peoples, Template:Denial of Mass Killings, Template:Discrimination sidebar, and so on. Many of the articles coming off Template:Genocide have two of these in succession at the top. Johnbod (talk) 23:32, 29 June 2020 (UTC)
...or not see also...
Todays featured article is about a vaudeville performer of the 19th/20th centuries, Harry Relph. Of the links in the text appearing on the main page, 5 of them are links to featured articles.
The combined see also sections of those five articles amount to a list of five items. The reason for that trend seems to come back to the instructions on this page, which suggest a comprehensive article does not include a see also section, and avoiding any repeated use of links already used in the article.
- A see also section is not an indication of an articles quality, comprehensive, good, bad, indifferent. It is a navigation tool, only. Nothing else should be of concern regarding a see also section except its value as a navigation tool.
- A see also section is not a guide to unused links in an article. It is a navigation tool for a reader. No it should not simply repeat all of the links in an article, nor should it be dismissed in favour of forcing the reader to navigate by searching through the legnthy text of a branching topic.
- Navigation tools are a basic element of the wider encyclopaedia, not just Misplaced Pages, but a key feature of pride in encyclopaedias of yesterday such as Britannica, whose navigation indexes were renowned and covered whole volumes of the encyclopaedia itself. The reason Misplaced Pages put Britannica out of business was because Misplaced Pages is supposed to be a better encyclopaedia.
Please reword this guideline so that it is supportive of see also sections, which are a fundamental and characterising aspect of this encyclopaedia. ~ R.T.G 10:27, 21 July 2020 (UTC)
- We have navigation templates specifically intended for use as navigation tools. Nikkimaria (talk) 11:49, 21 July 2020 (UTC)
- Except they're not visible on mobile, which is what half the readers use.—Bagumba (talk) 11:55, 21 July 2020 (UTC)
- So seek to change that, rather than doubling the feature for the other half. Nikkimaria (talk) 12:02, 21 July 2020 (UTC)
- Navigation templates are rarely specific to a particular article. And regarding fixing templates for mobile devices... that's been in the request system for years. As far as I recall it is an issue with the software on the end of the mobile devices themselves. ~ R.T.G 14:49, 21 July 2020 (UTC)
- No, it was a deliberate design decision to reduce the HTML sent from the servers to your mobile device, which are most-usually in a low-bandwidth or low-data or both situation compared to your desktop computer. This, combined with the fact that the design of a navbox on mobile is a remaining design issue for wikis to figure out. They do not look good on the resolutions available to the average mobile device. --Izno (talk) 15:07, 21 July 2020 (UTC)
- Navigation templates are rarely specific to a particular article. And regarding fixing templates for mobile devices... that's been in the request system for years. As far as I recall it is an issue with the software on the end of the mobile devices themselves. ~ R.T.G 14:49, 21 July 2020 (UTC)
- So seek to change that, rather than doubling the feature for the other half. Nikkimaria (talk) 12:02, 21 July 2020 (UTC)
- And navboxes are not visible to non-mobile casual wiki-users who do not know to hit the "end" key to find the buried navboxes. They're also not as far ranging as a See also section can be. I support the proposed change. Or, alternatively, permit a statement in See also that says something along the lines of "more related links at the bottom of this page." Butwhatdoiknow (talk) 16:18, 21 July 2020 (UTC)
- Except they're not visible on mobile, which is what half the readers use.—Bagumba (talk) 11:55, 21 July 2020 (UTC)
- Oppose any change. "See also"s tend to spiral out of control - Butwhatdoiknow's talk of "far ranging" is alarming. Templates & navboxes are also far too common - cruft that some people like to add everywhere, cluttering up pages. The category scheme is generally all the reader needs. Johnbod (talk) 16:27, 21 July 2020 (UTC)
- Oppose as Johnbod says, too much "see also" is a much bigger issue than too little. We should focus on reducing these sections, not expanding them. (t · c) buidhe 16:36, 21 July 2020 (UTC)
- I don't see the point of this request. MOS:ALSO neither requires see also sections, nor does it disallow them. The matter should be decided on a case-by-case basis. Calidum 16:36, 21 July 2020 (UTC)