![]() | This page is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
There's a rather lengthy ongoing thread at Wikipedia talk:Manual of Style/Film § To be or not to be a subsection
While much of it is mired in fallacious "WP must do exactly what The Chicago Manual of Style says, or else" nonsense, it may be worth discussing in more salient terms whether WP articles should ever use subsections then the section in question does not contain two or more. I'm pretty sure I know what the answer is, but the discussion should still happen, and should have broader input than the 5 or so people currently debating it, especially if a WP:POLICYFORK could possibly result, with MOS:TV diverging from MOS:LAYOUT on a topical basis for no legitimate reason. — SMcCandlish ☏ ¢ 😼 18:22, 28 June 2018 (UTC)
Just came across a good example of this, where a useful and logical See Also for the 2018 Amesbury poisonings article would be Poisoning of Sergei and Yulia Skripal. That article is linked within the lead of the 2018 Amesbury article, but only as a piped link (at time of writing, "same kind used in the poisoning of ex-Russian spy"). I would suggest that as the casual reader may not 'get' piped links, and would certainly expect to see the Skripal article referenced, and would want to perhaps go there next, it would be reasonable and user-friendly to have a See Also section that includes a link to the Skripal article. I'd like to propose a modification to WP:SEEALSO, where "As a general rule, the "See also" section should not repeat links that appear in the article's body or its navigation boxes." is expanded a little bit to note piped links don't necessarily count as 'appearing' - again, bear in mind we write for the casual reader, not editors. Not hung up on the wording, and people may not think it's a good idea, but I think it's a suggestion worth making. Fish+ Karate 12:15, 5 July 2018 (UTC)
Re [1] and the removal of Commons link boxes.
Has the easily-recognised Commons link box now been deprecated in favour of an indistinct listing in the packed LH sidebar? Presumably this is now populated by some incomprehensible bit of wikidata. Andy Dingley ( talk) 20:43, 15 July 2018 (UTC)
Hi. I would like to propose that geographic navigation boxes (with links to surrounding neighborhoods, cities, communities, etc.) be allowed within the "Geography" section of any given article. Because of the way these boxes are laid out (showing directions as on a map), they would be helpful for visualizing the general relationship of one place with another. Thank you, and I am looking forward to hearing from you. BeenAroundAWhile ( talk) 20:21, 18 August 2018 (UTC)
An issue related to single subsections, which watchers of this page may be interested in, is now up for discussion in an RfC which can be found at Wikipedia talk:Manual of Style#RfC on single subsections. Feel free to come and participate. - adamstom97 ( talk) 00:21, 26 August 2018 (UTC)
I found a flag icon farm in the "See also" section of Flag of Tuva, which I've removed per WP:ICONDECORATION. Is this something that has been discussed before, and should it be specifically allowed or disallowed? Thanks. - BilCat ( talk) 01:32, 29 August 2018 (UTC)
There is a major flaw in the consideration of "See also". This manual of style has a WP:NOTSEEALSO which states that if there is a blue wiki-link then that referred article should not be in the see also.
The end result is that a major, significant "see also" candidate is disqualified but a moderate or minor "see also" candidate appears.
It is easy to miss a wiki-link but the see also section is very prominent. This leads to many fights on Wikipedia. In the recent 2-3 weeks, I have seen fights about the Humboldt Broncos bus crash and Southwest Airlines Flight 1380. (The bus crash was where more than half of the hockey team was killed in a bus crash and a related Broncos team had a fatal bus crash years ago, which was the see also candidate. The Southwest Airlines incident was very similar to another Southwest incident where a fan blade tore through the fuselage and the plane was just a few numbers different in registration number).
In both examples, the see also entries that survived are remotely related but the single example that did not survive the see also debate (because of this MOS cited) was a very similar incident that has been cited many times in news reports.
I propose that if there is a very strongly related incident or article, the WP:NOTSEEALSO does not apply. This would help the reader. Vanguard10 ( talk) 19:15, 22 April 2018 (UTC)
As a general rule, the "See also" section should not repeat links ..." It is exactly that, a general rule that usually applies, not a rule that must be blindly followed. Use common sense. WP:IAR is always the case anyways, even if it wasn't already clear in calling it a "general rule".— Bagumba ( talk) 15:51, 2 September 2018 (UTC)
I'm looking over the layout guideline, and I don't see it explicitly mentioned, but navboxes are supposed to be positioned at the very bottom of articles, correct? Abductive ( reasoning) 18:14, 11 September 2018 (UTC)
Hello, is there a purpose for specifying at MOS:LAYOUTEL that "External links" must always be plural even if only a single link is added? Kind regards, Cavalryman V31 ( talk) 18:22, 9 September 2018 (UTC).
THis is a thing this manual mentions, but doesnt explain the reasoning behind this guidance. Might I ask why is that so and why are Wiktionary and Wikisource exceptions to this rule? (but not eg Commons) 2A02:A317:2241:7A00:9F4:3E9A:A783:B4FC ( talk) 00:31, 4 November 2018 (UTC)
Project page recommends annotating links in see also section. This can be done automatically by using the {{ annotated link}} which annotates the link using the content of the {{ short description}}. I propose to mention this as a convenient option. · · · Peter (Southwood) (talk): 07:48, 27 November 2018 (UTC)
Currently, regarding "no See also" this page reads The "See also" section should not link to pages that do not exist (red links), nor to disambiguation pages (unless used for further disambiguation in a disambiguation page). As a general rule, the "See also" section should not repeat links that appear in the article's body or its navigation boxes. I disagree fully: the beauty of Wikipedia over previous encyclopedias is that it allows super-quick cross-referencing, while the "See also" sections should serve to call out important elements for further reading – especially for people who are often "clicking through" a document and are susceptible to missing the big picture. Which is to say, I'd like to see the NOSEEALSO policy changed. Any responses? If any agreement, can fellow Wikipedians guide me as to how to recommend and get that change made? Gratefully, Aboudaqn ( talk) 16:02, 24 November 2018 (UTC)
we made the inline sister template just for this reason??
I am confused by this, I tried to add an internal link to Star Wars: Knights of the Old Republic and Star Wars Knights of the Old Republic II: The Sith Lords for see also because technically it's not on the page for specialist browsers or mobile view however ferret removed them quoting MOS:SEEALSO , but nav-boxes disregard WP:ACCESS for disability readers. So whats the best out come to help a reader get to page for the characters? Govvy ( talk) 23:56, 22 January 2019 (UTC)
Please see the discussion at Talk:Kidnapping_of_Jayme_Closs#Joseph_E._Duncan_III about whether a certain link belongs in that article's SEE ALSO question. Giving us your take would be appreciated. -- В²C ☎ 23:28, 24 January 2019 (UTC)
Help:Section § Hiding the TOC is linked from here and shows how to hide the TOC. I don't find any information here or there about when it is appropriate to hide the TOC. François Robere claims a TOC is unneeded for a short stub. Disregarding the fact that this example is not particularly short, is this a valid reason to use __NOTOC__? ~ Kvng ( talk) 14:51, 16 February 2019 (UTC)
the magic number is 4And why? Because of length - because an article with three sections or less is assumed to be short enough to navigate without a TOC. But what about an article with 4 tiny sections - a stub? It could be as short as a "regular" article with two sections.
having a consistent visual layout for articles is beneficialif that layout makes sense; the current layout is both wasteful and ugly. And it's not that inconsistent to hide the TOC: Some articles have infoboxes, some don't; some have hatnotes, some don't; some have pictures at the right, some have them at the left, and yet other have none at all; etc. etc. Hiding the TOC isn't that different.
a dense wall of content without whitespace is also not clearly an improvementThe longest paragraph in that article is 96 words in five sentences. That's not a "wall of content".
A truly short article with 4 short sections could be better improved by combining or expanding sections than removing the TOCProbably, but its length won't necessarily change; and if it doesn't need a TOC for that length, how does the number of sections change it?
maintenance issue is not to be discountedI really doubt it. It's in all caps and just after the lead; it's much easier to miss eg. a typo or an English variant switch, yet we're still fairly consistent with those. Put differently: It's much uglier and more wasteful to the reader than it is to restore when the article grows longer.
With regard to screen size, this does vary a lot more than François Robere examples indicateYes, many people use larger displays, where the text easily fits on one screen.
For one thing, not everyone uses their browser in full-screen modeWhich is even worse - how much vertical space will a TOC take then? A third of the screen? For what? Do you really need a TOC for two sections (the other two are the "see also" and "references", which no one bothers with anyway)? François Robere ( talk) 15:49, 17 February 2019 (UTC)
I assume it is because a TOC with one entry is clearly not usefulWhat about one with two? The article in question has only two readable sections.
You don't seem to appreciate the value of consistencyYou didn't really counter my point: Articles vary much more than just the TOCs, so changing those won't affect consistency that much. Alternatively, if you so care about consistency, why not switch sides and hide TOCs where they're not needed?
Getting below 4 sections automatically hides the TOCYou didn't counter my point: The "4 rule" is meant to reflect article length, not article structure. A TOC could be extremely useful in a long article with a few sections, and completely useless in a short article with many sections.
For a larger display, there's plenty of room for the TOC and the entire articleYeah, but if you're interested in accessibility you're not going check only against larger screens. But if you do have a big display then you're you don't really need the TOC, so why have it? It's bad design.
If the entire article doesn't fit in a small browser window, the TOC is usefulUnless (again) it's the TOC preventing it from fitting in one window. In that case the TOC is harmful, and as I've already shown that's the case here.
It seems that your solution to what you perceive as a design problem is to manually apply __NOTOC__ to "short articles". I believe your definition of "short article" is an article that "fits on one screen". Considering the many ways Wikipedia is published/rendered can you suggest an objective criteria for determining whether an article fits on one screen? ~ Kvng ( talk) 21:02, 17 February 2019 (UTC)
It looks like this has run its course. I'm going to suggest we we have achieved consensus on two points:
I appreciate that we don't have a consensus definition of what "fit on one screen" means but we'll have to leave that for another day. I will update Help:Section#Hiding_the_TOC to reflect these points. ~ Kvng ( talk) 13:37, 20 February 2019 (UTC)
Where could a WP:GALLERY be placed? There may be more options in the layout; if so then please indicate considerations. - DePiep ( talk) 22:04, 20 February 2019 (UTC)
Where could a WP:GALLERY be placed? There may be more options in the layout; if so then please indicate considerations. - DePiep ( talk) 00:02, 21 February 2019 (UTC)
The gallery ought to go where it is most relevant - if it's a series of illustrations appropriate to just one section of an article, it might go into that section. But in general, as Kvng says, they go just before any "See also" section - as in the example cited in WP:Image use policy where it says " See Women's suffrage in New Zealand for an example of a good use of gallery." Pam D 23:13, 21 February 2019 (UTC)
Regarding the change from -
The order of sections in the body of a Wikipedia article may be recommended by a relevant WikiProject, or may not exist at all for some topics.
to
Certain domains have advice for the layout of an article. The below are the community-wide MOS pages dedicated in part to layout:
- What does "domains" refer to? Can we add an adjective? Butwhatdoiknow ( talk) 15:48, 28 February 2019 (UTC)
A group of related items, topics, or subjects.Feel free to use another word. -- Izno ( talk) 18:36, 28 February 2019 (UTC)
RfC created at Talk:Companion (Doctor Who)#Request for comment on notes format, regarding the placing of discursive notes on pages consisting of tabulated information. MOS is not specific on this currently. U-Mos ( talk) 02:37, 16 March 2019 (UTC)
Where are the interwiki links placed? "See also" or "External links"? — Wei4Green | 唯绿远大 ( talk) 09:22, 15 April 2019 (UTC)
Is it appropriate to include relevant categories in a "See also" section? I don't think so, but would like to enquire before deleting them. Case in point: Bibliography of Donald Trump#See also, which links to Category:Books about Donald Trump and Category:Books about the 2016 United States presidential election. — JFG talk 08:15, 20 April 2019 (UTC)
{{
Portal}}
templates (while inter-wiki stuff goes in "External links"); but categories aren't among them. The practice of adding categories to "See also" is unusual, and usually redundant, since the article in question is already in the category (or a child or parent one), so the relevant category branch is already accessible, in a way the reader generally already knows well. (WP does surely get a handful of new users every day, but probably 99.99% of our readers have been here many times before and already know how the site's forms of navigation work.) Semi-relevant is that we don't redirect list articles to categories, or link in mid-sentence to categories as if they are list articles, even when a list article does/would have exactly the same elements in it as the category. This suggests a clear divide between categories as navigation and maintenance tools, and articles (of any kind) as content; I suppose portals are blend of content and navigation. I generally remove cat. links from "See also" when I run across them, and don't recall anyone ever reverting me on it. But it's not something I go around looking for. I don't feel that strongly about it, since "See also" is a navigational section, so it's not misleading to have a cat. in it, as would be putting inter-wikis in "See also", or links to WP articles in "References". If someone wanted to RfC the idea of expanding "See also" to expressly permit cat. links, I'd probably be neutral or at most weakly opposing on the matter, but the current state of the guidelines suggests nothing goes in there but articles and portal tag and maybe a few other things specified somewhere else. —
SMcCandlish
☏
¢ 😼
04:24, 8 May 2019 (UTC)I sometimes (not all that often, but repeatedly) come across broken wikilinks to sections that no longer exist. Normally, the reason for this is that the section has been renamed.
The easy fix for this is to add an anchor template. In fact I think this should be the recommended fix, as so far as I know there is no easy way to locate incoming wikilinks that have been broken or are about to be broken by the renaming of a section. There seems no downside to creating the anchor, and it neatly solves any problems.
But I think we should also be proactive in this. Such broken links are easily avoided, hard to detect once created, and both puzzling and annoying to the reader, particularly within the article namespace.
So I propose that we add something like the following to the guideline:
Whenever a section heading is deleted or its name is in any way modified, an anchor template should be added so as not to break incoming links to the old section name.
This doesn't mention what to do if the section and its content is completely deleted, but I think those can be dealt with case by case. This would handle most cases, and at least alert editors to the potential problem. Andrewa ( talk) 01:25, 30 April 2019 (UTC)
I now see that this is already covered at Wikipedia:Manual of Style/Linking#Broken section links. The advice (but not the phrasing) is identical, and this is a better place for it... we want to get the attention of people who are changing or deleting headings, while MOS/Linking is going to be instead read by people linking to these headings. Andrewa ( talk) 02:39, 2 May 2019 (UTC)
This needs to be toned down. As it now stands, an editor cleaning up a brand new article with non-standard headings (capitalisation, typos, unsuitable wording) would be told to make an anchor for each of these, so that changing "Personal Life", "Personnel life" or "Personal lif" to "Personal life" becomes a much bigger job. Pam D 05:30, 2 May 2019 (UTC)
Nobody is proposing to make more work for wikignomes. Just the opposite. I do gnomelike work too, such as adding an anchor to fix a broken section link whenever I follow one. And it happens regularly.
But it should not be necessary. The best time to fix these is when they are first broken. That's when it is the least work, and also the most productive, in that it avoids inconveniencing any readers at all. Andrewa ( talk) 23:53, 2 May 2019 (UTC)
{{anchor:Personal Life}}
" 2 + 24 keystrokes (or some copy-and-paste to cut the keystrokes down to 2 + 11 + copy-paste.It is good practice to place an anchor whenever the section is expected to be the target of an incoming wikilink", which is very different from your "always". Pam D 21:36, 3 May 2019 (UTC)
should always be created when a section heading is removed or its name is changed, however trivially.. An instruction reminding people rearranging an established article that they should make anchors for altered subject headings is quite different, and desirable. Nikkimaria's version is fine. Pam D 08:03, 8 May 2019 (UTC)
I don't remember where I saw it but I recall a long discussion somewhere in Wikipedia talk about putting {{ Anchor}} in section headings. Doing so creates a messy edit summary when a section is edited and so is not an ideal solution. My recollection is that the conversation went through a few ideas before concluding that there was really no good solution. You can use Rdcheck to find and fix broken redirect targets but I don't know of a way to find and fix broken links from normal articles. ~ Kvng ( talk) 13:39, 4 May 2019 (UTC)
==Foo bar baz<span id="Quux"></span>==
, using HTML not a template, and after the current name of the section. Given the frequency with which {{
Anchor}}
is in fact used, just below the current heading, surely a near totality of our readers are already familiar with the fact that if they click a link and are taken to mid-page that if the scroll up a tiny bit they will then see the heading. PS: Another approach sometimes used is putting the achor template just above the heading (which makes it part of the prior section, at the code level). This only works in very stable articles, since if you re-organize the sectional layout and don't look out for anchors, you'll end up moving the anchor along with the section in which is technically lives to no longer be above the heading and section to which the anchor pertains. —
SMcCandlish
☏
¢ 😼
04:35, 8 May 2019 (UTC)
Then first at least make these article's navigation boxes appear visible to readers at mobile devices in your disfunctional mobile version. SNAAAAKE!! ( talk) 06:08, 26 November 2018 (UTC)
Given the time lapse, it might make sense to start a new section on this topic, but I'll attempt to chime in here with call-outs @ SNAAAAKE!!: @ Jay D. Easy: @ BilCat: and @ Moxy: → It seems somewhat problematic that MOS:Layout guidelines make only a single mention regarding mobile. Mobile access to English WP has consistently outpaced desktop access since April 2018. (Across all Wikimedia sites, the trend begins November 2017.) I'm actually a fan of Navigation boxes and Categories, but since noting their absence on mobile, lately I've preferred See also sections and templates. I don't typically advocate for guideline changes, but I do think the current "general rule" merits reconsideration. So long as the mobile/app interfaces hide various navigation features, the current Layout guideline does not serve all readers equally. Perhaps I'm biased as a regular mobile reader, but I think it's vital to account for different UX when crafting See also sections. Specific example: I had a contribution reverted on the basis that the See also section duplicated a link in a navigation template below; when I raised my concern about mobile access, the reverting editor subsequently pointed to MOS:Layout as justification. — HipLibrarianship talk 03:04, 6 March 2019 (UTC)
I concur with pretty much everyone else here that the rule about navbox links makes no sense. Even if navboxes were visible in mobile, the rule would still be silly because barely anyone looks at navboxes way down at the bottom. And most of the time the navboxes are closed by default, with some containing dozens of links... so maybe 0.1% of the people that visit a page are going to notice a particular link in the navbox and think anything of it. Since there is a clear consensus here for making the change can I go ahead and do it or does it have to be done by an admin? I just want to change the following sentence to remove the last 4 words:As a general rule, the "See also" section should not repeat links that appear in the article's body or its navigation boxes.-- Jamesy0627144 ( talk) 04:48, 13 April 2019 (UTC)
If an article has multiple navboxes in its external links section, how should they be ordered? Alphabetically? Or grouped according to content/media (for example, navboxes pertaining to a comic are grouped together, followed by navboxes pertaining to the comic's TV or film adaptations, etc.)? – KuroMina ( talk) 04:33, 18 December 2019 (UTC)
No mention of {{short description}} in this MOS. A lot of pages is tagged with it on the first line, and AWB (and friends) seems to think it should not be the first line, but after the hatnotes. Any opinions? Christian75 ( talk) 15:37, 13 April 2019 (UTC)
{{
unreferenced}}
- they cause a slight separation of the banners, which on some setups may be visible as a gap, or as an extra-thick border between the banners (
example). --
Redrose64 🌹 (
talk)
21:00, 13 April 2019 (UTC)
Done. Butwhatdoiknow ( talk) 22:22, 15 April 2019 (UTC)
Ignoring content vs. metadata separation and/or relevance-ordering of metadata, for no sound reason will call into question our entire layout rationale, which is based on the same separation and ordering principles. ("See also" comes after content because it is navigation, i.e. a form of metadata, but it comes before "References" which are a different kind of metadata but about external resources; but that comes before "External links" which are also metadata about external resources, but with less direct relevance to the content. The order is very specific.) This is ultimately a WP:NOT#WEBHOST matter in a sense: WP doesn't exist for individuals' personal experiments in restructuring (or just breaking) the structural design of a shared information-presentation project. Stuff is in a particular order for sound information-architectural reasons, which really don't relate to what someone subjectively thinks will look best. E.g., plenty of editors would love to put topical navboxes (succession boxes, or film- or TV-related ones, or whatever) in mid-article positions (they've tried, trust me). Similarly, people have injected sister-project links into the content, or moved stub tags to topical sections of articles, and done other such things out of a personal sense of organizational logic that pertains to subject matter rather than distinguishing primary content from navigational and other metadata. We revert them. (It's a very "bloggy" approach, e.g. "I'm writing about dubstep, so I should make sure a music ad goes right here for my monetization purposes." It's an expediency- and visual-results-driven viewpoint that takes no account of other uses of the content.)
When there are genuine exceptions, they are for objectively not subjectively good reasons. E.g., when what could be (if not for
WP:N) an article on an album is merged to the article on the artist, it's permissible to inject an album infobox into the section on the album; the i-box is metadata about the section only (and remains an out-of-flow float, and would be confusing if put at top of page along with artist i-box). Another example is sectional hatnote navigation like {{
Main}}
; they're distinguished by templated classes (including unprintworthiness) and by the italic style we use for unavoidable self-references); they're an exception to the separation because, of course, they could not serve their purpose if not used in the relevant sections. Such rationales doesn't apply to the short-description case; there isn't a failure-of-purpose if short-description code goes below hatnote templates. PS: This is making me think that what we should be doing ultimately is putting short-descriptions into out-of-flow boxes with CSS classes (perhaps with specific positioning by default, which someone can fine-tune with user CSS, but which would at least prevent short-description material from visually disrupting articles if placed in mid-page; it would still need to be fixed, but it wouldn't be a big deal.
—
SMcCandlish
☏
¢ 😼
00:17, 11 February 2020 (UTC)
"Bibliography" is discouraged because it is not clear whether it is limited to the works of the subject of the article.. While some articles still use this it seems it is more commonly being replaced with "Works or publications".
Anyway, I'm also unclear on exactly what you're proposing. I would think that in either one- or two-section referencing, we should just use sections (== level). I've seen a few cases where people do things like ==Citations and references== (or ==Notes and references==), followed by ===Citations=== (or ===Notes===) then ===References=== (yeah, sometimes other exact wording like ===Works cited===, whatever.) This sub-sectioning seems pretty pointless and just makes the ToC longer for no benefit. I don't often see things like just ==Citations== followed by ===References===, and am skeptical that's useful (logically the citations are more a subset than the other way around). Finally, the "Bibliography" related stuff appears to be a duplicate of a thread just a little above this one. Short version: we have other terms to use (e.g. "References" or a two-section "Citations" and "References" pair), so we have no reason to use the ambiguous "Bibliography" (nor "Notes" which is actually often for something else).
I am concerned that "...although each is questionable in some contexts" implies that the alternative titles are deprecated in some way. "Bibliography", especially, is used in many articles, including quite a few Featured Articles. Even in a biography, it would be quite hard to mistake a list of works by named authors for a list of works by the subject. Most of the other examples are even more far-fetched. The actual contents of the section would immediately show to a reader that it is not what was assumed (and there is precious little evidence that anyone is making these incorrect assumptions). I could just as easily argue that "Notes" or "References" meant something else. References can be references to the subject of the article in other works for instance. I think we should just state that there are some alternative titles and leave it at that. Spinning Spark 10:54, 10 November 2019 (UTC)
This material (deprecating some titles) was originally inserted with this edit. The edit summary says "see talk", but the talk page discussion at this date has no discussion of actually deprecating titles or the reasons that might be necessary. The discussion is centred on the statistical proportion of titles used and the order they ought to be in. There is thus no historical consensus for this. Spinning Spark 10:51, 11 November 2019 (UTC)
{{
efn}}
and {{
notelist}}
). It's preferable to use "Notes" for that to avoid the perennial and rather stupid argument-to-the-death about whether they are "Foodnotes" or "Endnotes" (it's lame because in a non-paginated publication they are the same thing). —
SMcCandlish
☏
¢ 😼
04:40, 10 February 2020 (UTC)
Any comments?
Midland Railway War Memorial and "rv, per multiple other FAs and WP:CITEVAR" Andy Dingley ( talk) 15:18, 4 March 2020 (UTC)
Two questions:
What do we call the informational boxes that appear at the top of a page, for example:
{{
WPMOS}}
and
{{
Information page}}
Thanks.
Butwhatdoiknow (
talk)
16:19, 12 March 2020 (UTC)
Second question: Are message boxes and banners already listed in this sequence?
If so, where? If not, where should they go? Thanks. Butwhatdoiknow ( talk) 16:55, 12 March 2020 (UTC)
{{
WPMOS}}
nor {{
Information page}}
should ever be used on an article. {{
WPMOS}}
is for use on talk pages, for which
WP:TALKORDER applies; and in that list, this is a WikiProject banner, item 9 in the list. --
Redrose64 🌹 (
talk)
19:45, 12 March 2020 (UTC)
This is very bad advice:
- Succession boxes and geography boxes
- Other navigation templates (footer navboxes)[…] (navbars above {{ Portal bar}})
- Geographical coordinates (if not in Infobox) or {{ coord missing}}
- Authority control templates (taxonbar above Authority control)
- […]
Placing anything between #2 and #4 creates an annoying gap because their borders don't collapse together when they are not truly adjacent. Note that template {{coord|…|…|display=title}}
automagically floats to the top-right for rendering purposes when entered literally anywhere on the page. But today I learned (from somebody else's edit summary) that "consensus" says to put it in the one place where it causes a problem. Unfortunately I can't say I'm surprised. ―
cobaltcigs
21:45, 20 October 2019 (UTC)
<br />
s). Better yet would be totally phasing them out in favor of collapsible navboxes which would show the entire succession (or some sub-range thereof if the list is prohibitively huge) and be more practical to maintain than anything allowing freeform input.<div id="catlinks" […]>
in the mw-interface. Yes, I realize the invisible <div class="printfooter">
is right in the way, and would need to be moved lower by some software change.For a very clear example, see the article
Bill Szymczyk,
before and
after my edit. It seems some aspect of the {{
good article}} indicator/icon's "magical" leap to the top-right corner leaves behind an empty paragraph element <p class="mw-empty-elt"></p>
. That class is display: none;
by default, which is good, but insufficient. Despite being empty and invisible, this placeholder element still exists, which is enough to prevent two <div>
s of class navbox
from being recognized as adjacent (by the CSS rule .navbox + .navbox { margin-top: -1px; }
in
MediaWiki:Common.css). Verily, I can't think of any other scenario in which
only moving the GA icon causes a visible change. Hopefully this one doesn't get reverted. ―
cobaltcigs
09:32, 19 March 2020 (UTC)
{{
good article}}
template per se; boxes with collapsed borders (such as navboxes and authority control) shouldn't have other objects between them. The border-collapse effect only triggers when the two boxes are physically adjacent. --
Redrose64 🌹 (
talk)
21:18, 20 March 2020 (UTC)
- Succession boxes and geography boxes
- Other navigation templates (footer navboxes)[…] (navbars above {{ Portal bar}})
Geographical coordinates (if not in Infobox) or {{ coord missing}}- Authority control templates (taxonbar above Authority control)
- Geographical coordinates (if not in Infobox) or {{ coord missing}}
- […]
All the best:
Rich
Farmbrough (the apparently calm and reasonable)
07:54, 8 April 2020 (UTC).
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)
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)
![]() | This page is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
There's a rather lengthy ongoing thread at Wikipedia talk:Manual of Style/Film § To be or not to be a subsection
While much of it is mired in fallacious "WP must do exactly what The Chicago Manual of Style says, or else" nonsense, it may be worth discussing in more salient terms whether WP articles should ever use subsections then the section in question does not contain two or more. I'm pretty sure I know what the answer is, but the discussion should still happen, and should have broader input than the 5 or so people currently debating it, especially if a WP:POLICYFORK could possibly result, with MOS:TV diverging from MOS:LAYOUT on a topical basis for no legitimate reason. — SMcCandlish ☏ ¢ 😼 18:22, 28 June 2018 (UTC)
Just came across a good example of this, where a useful and logical See Also for the 2018 Amesbury poisonings article would be Poisoning of Sergei and Yulia Skripal. That article is linked within the lead of the 2018 Amesbury article, but only as a piped link (at time of writing, "same kind used in the poisoning of ex-Russian spy"). I would suggest that as the casual reader may not 'get' piped links, and would certainly expect to see the Skripal article referenced, and would want to perhaps go there next, it would be reasonable and user-friendly to have a See Also section that includes a link to the Skripal article. I'd like to propose a modification to WP:SEEALSO, where "As a general rule, the "See also" section should not repeat links that appear in the article's body or its navigation boxes." is expanded a little bit to note piped links don't necessarily count as 'appearing' - again, bear in mind we write for the casual reader, not editors. Not hung up on the wording, and people may not think it's a good idea, but I think it's a suggestion worth making. Fish+ Karate 12:15, 5 July 2018 (UTC)
Re [1] and the removal of Commons link boxes.
Has the easily-recognised Commons link box now been deprecated in favour of an indistinct listing in the packed LH sidebar? Presumably this is now populated by some incomprehensible bit of wikidata. Andy Dingley ( talk) 20:43, 15 July 2018 (UTC)
Hi. I would like to propose that geographic navigation boxes (with links to surrounding neighborhoods, cities, communities, etc.) be allowed within the "Geography" section of any given article. Because of the way these boxes are laid out (showing directions as on a map), they would be helpful for visualizing the general relationship of one place with another. Thank you, and I am looking forward to hearing from you. BeenAroundAWhile ( talk) 20:21, 18 August 2018 (UTC)
An issue related to single subsections, which watchers of this page may be interested in, is now up for discussion in an RfC which can be found at Wikipedia talk:Manual of Style#RfC on single subsections. Feel free to come and participate. - adamstom97 ( talk) 00:21, 26 August 2018 (UTC)
I found a flag icon farm in the "See also" section of Flag of Tuva, which I've removed per WP:ICONDECORATION. Is this something that has been discussed before, and should it be specifically allowed or disallowed? Thanks. - BilCat ( talk) 01:32, 29 August 2018 (UTC)
There is a major flaw in the consideration of "See also". This manual of style has a WP:NOTSEEALSO which states that if there is a blue wiki-link then that referred article should not be in the see also.
The end result is that a major, significant "see also" candidate is disqualified but a moderate or minor "see also" candidate appears.
It is easy to miss a wiki-link but the see also section is very prominent. This leads to many fights on Wikipedia. In the recent 2-3 weeks, I have seen fights about the Humboldt Broncos bus crash and Southwest Airlines Flight 1380. (The bus crash was where more than half of the hockey team was killed in a bus crash and a related Broncos team had a fatal bus crash years ago, which was the see also candidate. The Southwest Airlines incident was very similar to another Southwest incident where a fan blade tore through the fuselage and the plane was just a few numbers different in registration number).
In both examples, the see also entries that survived are remotely related but the single example that did not survive the see also debate (because of this MOS cited) was a very similar incident that has been cited many times in news reports.
I propose that if there is a very strongly related incident or article, the WP:NOTSEEALSO does not apply. This would help the reader. Vanguard10 ( talk) 19:15, 22 April 2018 (UTC)
As a general rule, the "See also" section should not repeat links ..." It is exactly that, a general rule that usually applies, not a rule that must be blindly followed. Use common sense. WP:IAR is always the case anyways, even if it wasn't already clear in calling it a "general rule".— Bagumba ( talk) 15:51, 2 September 2018 (UTC)
I'm looking over the layout guideline, and I don't see it explicitly mentioned, but navboxes are supposed to be positioned at the very bottom of articles, correct? Abductive ( reasoning) 18:14, 11 September 2018 (UTC)
Hello, is there a purpose for specifying at MOS:LAYOUTEL that "External links" must always be plural even if only a single link is added? Kind regards, Cavalryman V31 ( talk) 18:22, 9 September 2018 (UTC).
THis is a thing this manual mentions, but doesnt explain the reasoning behind this guidance. Might I ask why is that so and why are Wiktionary and Wikisource exceptions to this rule? (but not eg Commons) 2A02:A317:2241:7A00:9F4:3E9A:A783:B4FC ( talk) 00:31, 4 November 2018 (UTC)
Project page recommends annotating links in see also section. This can be done automatically by using the {{ annotated link}} which annotates the link using the content of the {{ short description}}. I propose to mention this as a convenient option. · · · Peter (Southwood) (talk): 07:48, 27 November 2018 (UTC)
Currently, regarding "no See also" this page reads The "See also" section should not link to pages that do not exist (red links), nor to disambiguation pages (unless used for further disambiguation in a disambiguation page). As a general rule, the "See also" section should not repeat links that appear in the article's body or its navigation boxes. I disagree fully: the beauty of Wikipedia over previous encyclopedias is that it allows super-quick cross-referencing, while the "See also" sections should serve to call out important elements for further reading – especially for people who are often "clicking through" a document and are susceptible to missing the big picture. Which is to say, I'd like to see the NOSEEALSO policy changed. Any responses? If any agreement, can fellow Wikipedians guide me as to how to recommend and get that change made? Gratefully, Aboudaqn ( talk) 16:02, 24 November 2018 (UTC)
we made the inline sister template just for this reason??
I am confused by this, I tried to add an internal link to Star Wars: Knights of the Old Republic and Star Wars Knights of the Old Republic II: The Sith Lords for see also because technically it's not on the page for specialist browsers or mobile view however ferret removed them quoting MOS:SEEALSO , but nav-boxes disregard WP:ACCESS for disability readers. So whats the best out come to help a reader get to page for the characters? Govvy ( talk) 23:56, 22 January 2019 (UTC)
Please see the discussion at Talk:Kidnapping_of_Jayme_Closs#Joseph_E._Duncan_III about whether a certain link belongs in that article's SEE ALSO question. Giving us your take would be appreciated. -- В²C ☎ 23:28, 24 January 2019 (UTC)
Help:Section § Hiding the TOC is linked from here and shows how to hide the TOC. I don't find any information here or there about when it is appropriate to hide the TOC. François Robere claims a TOC is unneeded for a short stub. Disregarding the fact that this example is not particularly short, is this a valid reason to use __NOTOC__? ~ Kvng ( talk) 14:51, 16 February 2019 (UTC)
the magic number is 4And why? Because of length - because an article with three sections or less is assumed to be short enough to navigate without a TOC. But what about an article with 4 tiny sections - a stub? It could be as short as a "regular" article with two sections.
having a consistent visual layout for articles is beneficialif that layout makes sense; the current layout is both wasteful and ugly. And it's not that inconsistent to hide the TOC: Some articles have infoboxes, some don't; some have hatnotes, some don't; some have pictures at the right, some have them at the left, and yet other have none at all; etc. etc. Hiding the TOC isn't that different.
a dense wall of content without whitespace is also not clearly an improvementThe longest paragraph in that article is 96 words in five sentences. That's not a "wall of content".
A truly short article with 4 short sections could be better improved by combining or expanding sections than removing the TOCProbably, but its length won't necessarily change; and if it doesn't need a TOC for that length, how does the number of sections change it?
maintenance issue is not to be discountedI really doubt it. It's in all caps and just after the lead; it's much easier to miss eg. a typo or an English variant switch, yet we're still fairly consistent with those. Put differently: It's much uglier and more wasteful to the reader than it is to restore when the article grows longer.
With regard to screen size, this does vary a lot more than François Robere examples indicateYes, many people use larger displays, where the text easily fits on one screen.
For one thing, not everyone uses their browser in full-screen modeWhich is even worse - how much vertical space will a TOC take then? A third of the screen? For what? Do you really need a TOC for two sections (the other two are the "see also" and "references", which no one bothers with anyway)? François Robere ( talk) 15:49, 17 February 2019 (UTC)
I assume it is because a TOC with one entry is clearly not usefulWhat about one with two? The article in question has only two readable sections.
You don't seem to appreciate the value of consistencyYou didn't really counter my point: Articles vary much more than just the TOCs, so changing those won't affect consistency that much. Alternatively, if you so care about consistency, why not switch sides and hide TOCs where they're not needed?
Getting below 4 sections automatically hides the TOCYou didn't counter my point: The "4 rule" is meant to reflect article length, not article structure. A TOC could be extremely useful in a long article with a few sections, and completely useless in a short article with many sections.
For a larger display, there's plenty of room for the TOC and the entire articleYeah, but if you're interested in accessibility you're not going check only against larger screens. But if you do have a big display then you're you don't really need the TOC, so why have it? It's bad design.
If the entire article doesn't fit in a small browser window, the TOC is usefulUnless (again) it's the TOC preventing it from fitting in one window. In that case the TOC is harmful, and as I've already shown that's the case here.
It seems that your solution to what you perceive as a design problem is to manually apply __NOTOC__ to "short articles". I believe your definition of "short article" is an article that "fits on one screen". Considering the many ways Wikipedia is published/rendered can you suggest an objective criteria for determining whether an article fits on one screen? ~ Kvng ( talk) 21:02, 17 February 2019 (UTC)
It looks like this has run its course. I'm going to suggest we we have achieved consensus on two points:
I appreciate that we don't have a consensus definition of what "fit on one screen" means but we'll have to leave that for another day. I will update Help:Section#Hiding_the_TOC to reflect these points. ~ Kvng ( talk) 13:37, 20 February 2019 (UTC)
Where could a WP:GALLERY be placed? There may be more options in the layout; if so then please indicate considerations. - DePiep ( talk) 22:04, 20 February 2019 (UTC)
Where could a WP:GALLERY be placed? There may be more options in the layout; if so then please indicate considerations. - DePiep ( talk) 00:02, 21 February 2019 (UTC)
The gallery ought to go where it is most relevant - if it's a series of illustrations appropriate to just one section of an article, it might go into that section. But in general, as Kvng says, they go just before any "See also" section - as in the example cited in WP:Image use policy where it says " See Women's suffrage in New Zealand for an example of a good use of gallery." Pam D 23:13, 21 February 2019 (UTC)
Regarding the change from -
The order of sections in the body of a Wikipedia article may be recommended by a relevant WikiProject, or may not exist at all for some topics.
to
Certain domains have advice for the layout of an article. The below are the community-wide MOS pages dedicated in part to layout:
- What does "domains" refer to? Can we add an adjective? Butwhatdoiknow ( talk) 15:48, 28 February 2019 (UTC)
A group of related items, topics, or subjects.Feel free to use another word. -- Izno ( talk) 18:36, 28 February 2019 (UTC)
RfC created at Talk:Companion (Doctor Who)#Request for comment on notes format, regarding the placing of discursive notes on pages consisting of tabulated information. MOS is not specific on this currently. U-Mos ( talk) 02:37, 16 March 2019 (UTC)
Where are the interwiki links placed? "See also" or "External links"? — Wei4Green | 唯绿远大 ( talk) 09:22, 15 April 2019 (UTC)
Is it appropriate to include relevant categories in a "See also" section? I don't think so, but would like to enquire before deleting them. Case in point: Bibliography of Donald Trump#See also, which links to Category:Books about Donald Trump and Category:Books about the 2016 United States presidential election. — JFG talk 08:15, 20 April 2019 (UTC)
{{
Portal}}
templates (while inter-wiki stuff goes in "External links"); but categories aren't among them. The practice of adding categories to "See also" is unusual, and usually redundant, since the article in question is already in the category (or a child or parent one), so the relevant category branch is already accessible, in a way the reader generally already knows well. (WP does surely get a handful of new users every day, but probably 99.99% of our readers have been here many times before and already know how the site's forms of navigation work.) Semi-relevant is that we don't redirect list articles to categories, or link in mid-sentence to categories as if they are list articles, even when a list article does/would have exactly the same elements in it as the category. This suggests a clear divide between categories as navigation and maintenance tools, and articles (of any kind) as content; I suppose portals are blend of content and navigation. I generally remove cat. links from "See also" when I run across them, and don't recall anyone ever reverting me on it. But it's not something I go around looking for. I don't feel that strongly about it, since "See also" is a navigational section, so it's not misleading to have a cat. in it, as would be putting inter-wikis in "See also", or links to WP articles in "References". If someone wanted to RfC the idea of expanding "See also" to expressly permit cat. links, I'd probably be neutral or at most weakly opposing on the matter, but the current state of the guidelines suggests nothing goes in there but articles and portal tag and maybe a few other things specified somewhere else. —
SMcCandlish
☏
¢ 😼
04:24, 8 May 2019 (UTC)I sometimes (not all that often, but repeatedly) come across broken wikilinks to sections that no longer exist. Normally, the reason for this is that the section has been renamed.
The easy fix for this is to add an anchor template. In fact I think this should be the recommended fix, as so far as I know there is no easy way to locate incoming wikilinks that have been broken or are about to be broken by the renaming of a section. There seems no downside to creating the anchor, and it neatly solves any problems.
But I think we should also be proactive in this. Such broken links are easily avoided, hard to detect once created, and both puzzling and annoying to the reader, particularly within the article namespace.
So I propose that we add something like the following to the guideline:
Whenever a section heading is deleted or its name is in any way modified, an anchor template should be added so as not to break incoming links to the old section name.
This doesn't mention what to do if the section and its content is completely deleted, but I think those can be dealt with case by case. This would handle most cases, and at least alert editors to the potential problem. Andrewa ( talk) 01:25, 30 April 2019 (UTC)
I now see that this is already covered at Wikipedia:Manual of Style/Linking#Broken section links. The advice (but not the phrasing) is identical, and this is a better place for it... we want to get the attention of people who are changing or deleting headings, while MOS/Linking is going to be instead read by people linking to these headings. Andrewa ( talk) 02:39, 2 May 2019 (UTC)
This needs to be toned down. As it now stands, an editor cleaning up a brand new article with non-standard headings (capitalisation, typos, unsuitable wording) would be told to make an anchor for each of these, so that changing "Personal Life", "Personnel life" or "Personal lif" to "Personal life" becomes a much bigger job. Pam D 05:30, 2 May 2019 (UTC)
Nobody is proposing to make more work for wikignomes. Just the opposite. I do gnomelike work too, such as adding an anchor to fix a broken section link whenever I follow one. And it happens regularly.
But it should not be necessary. The best time to fix these is when they are first broken. That's when it is the least work, and also the most productive, in that it avoids inconveniencing any readers at all. Andrewa ( talk) 23:53, 2 May 2019 (UTC)
{{anchor:Personal Life}}
" 2 + 24 keystrokes (or some copy-and-paste to cut the keystrokes down to 2 + 11 + copy-paste.It is good practice to place an anchor whenever the section is expected to be the target of an incoming wikilink", which is very different from your "always". Pam D 21:36, 3 May 2019 (UTC)
should always be created when a section heading is removed or its name is changed, however trivially.. An instruction reminding people rearranging an established article that they should make anchors for altered subject headings is quite different, and desirable. Nikkimaria's version is fine. Pam D 08:03, 8 May 2019 (UTC)
I don't remember where I saw it but I recall a long discussion somewhere in Wikipedia talk about putting {{ Anchor}} in section headings. Doing so creates a messy edit summary when a section is edited and so is not an ideal solution. My recollection is that the conversation went through a few ideas before concluding that there was really no good solution. You can use Rdcheck to find and fix broken redirect targets but I don't know of a way to find and fix broken links from normal articles. ~ Kvng ( talk) 13:39, 4 May 2019 (UTC)
==Foo bar baz<span id="Quux"></span>==
, using HTML not a template, and after the current name of the section. Given the frequency with which {{
Anchor}}
is in fact used, just below the current heading, surely a near totality of our readers are already familiar with the fact that if they click a link and are taken to mid-page that if the scroll up a tiny bit they will then see the heading. PS: Another approach sometimes used is putting the achor template just above the heading (which makes it part of the prior section, at the code level). This only works in very stable articles, since if you re-organize the sectional layout and don't look out for anchors, you'll end up moving the anchor along with the section in which is technically lives to no longer be above the heading and section to which the anchor pertains. —
SMcCandlish
☏
¢ 😼
04:35, 8 May 2019 (UTC)
Then first at least make these article's navigation boxes appear visible to readers at mobile devices in your disfunctional mobile version. SNAAAAKE!! ( talk) 06:08, 26 November 2018 (UTC)
Given the time lapse, it might make sense to start a new section on this topic, but I'll attempt to chime in here with call-outs @ SNAAAAKE!!: @ Jay D. Easy: @ BilCat: and @ Moxy: → It seems somewhat problematic that MOS:Layout guidelines make only a single mention regarding mobile. Mobile access to English WP has consistently outpaced desktop access since April 2018. (Across all Wikimedia sites, the trend begins November 2017.) I'm actually a fan of Navigation boxes and Categories, but since noting their absence on mobile, lately I've preferred See also sections and templates. I don't typically advocate for guideline changes, but I do think the current "general rule" merits reconsideration. So long as the mobile/app interfaces hide various navigation features, the current Layout guideline does not serve all readers equally. Perhaps I'm biased as a regular mobile reader, but I think it's vital to account for different UX when crafting See also sections. Specific example: I had a contribution reverted on the basis that the See also section duplicated a link in a navigation template below; when I raised my concern about mobile access, the reverting editor subsequently pointed to MOS:Layout as justification. — HipLibrarianship talk 03:04, 6 March 2019 (UTC)
I concur with pretty much everyone else here that the rule about navbox links makes no sense. Even if navboxes were visible in mobile, the rule would still be silly because barely anyone looks at navboxes way down at the bottom. And most of the time the navboxes are closed by default, with some containing dozens of links... so maybe 0.1% of the people that visit a page are going to notice a particular link in the navbox and think anything of it. Since there is a clear consensus here for making the change can I go ahead and do it or does it have to be done by an admin? I just want to change the following sentence to remove the last 4 words:As a general rule, the "See also" section should not repeat links that appear in the article's body or its navigation boxes.-- Jamesy0627144 ( talk) 04:48, 13 April 2019 (UTC)
If an article has multiple navboxes in its external links section, how should they be ordered? Alphabetically? Or grouped according to content/media (for example, navboxes pertaining to a comic are grouped together, followed by navboxes pertaining to the comic's TV or film adaptations, etc.)? – KuroMina ( talk) 04:33, 18 December 2019 (UTC)
No mention of {{short description}} in this MOS. A lot of pages is tagged with it on the first line, and AWB (and friends) seems to think it should not be the first line, but after the hatnotes. Any opinions? Christian75 ( talk) 15:37, 13 April 2019 (UTC)
{{
unreferenced}}
- they cause a slight separation of the banners, which on some setups may be visible as a gap, or as an extra-thick border between the banners (
example). --
Redrose64 🌹 (
talk)
21:00, 13 April 2019 (UTC)
Done. Butwhatdoiknow ( talk) 22:22, 15 April 2019 (UTC)
Ignoring content vs. metadata separation and/or relevance-ordering of metadata, for no sound reason will call into question our entire layout rationale, which is based on the same separation and ordering principles. ("See also" comes after content because it is navigation, i.e. a form of metadata, but it comes before "References" which are a different kind of metadata but about external resources; but that comes before "External links" which are also metadata about external resources, but with less direct relevance to the content. The order is very specific.) This is ultimately a WP:NOT#WEBHOST matter in a sense: WP doesn't exist for individuals' personal experiments in restructuring (or just breaking) the structural design of a shared information-presentation project. Stuff is in a particular order for sound information-architectural reasons, which really don't relate to what someone subjectively thinks will look best. E.g., plenty of editors would love to put topical navboxes (succession boxes, or film- or TV-related ones, or whatever) in mid-article positions (they've tried, trust me). Similarly, people have injected sister-project links into the content, or moved stub tags to topical sections of articles, and done other such things out of a personal sense of organizational logic that pertains to subject matter rather than distinguishing primary content from navigational and other metadata. We revert them. (It's a very "bloggy" approach, e.g. "I'm writing about dubstep, so I should make sure a music ad goes right here for my monetization purposes." It's an expediency- and visual-results-driven viewpoint that takes no account of other uses of the content.)
When there are genuine exceptions, they are for objectively not subjectively good reasons. E.g., when what could be (if not for
WP:N) an article on an album is merged to the article on the artist, it's permissible to inject an album infobox into the section on the album; the i-box is metadata about the section only (and remains an out-of-flow float, and would be confusing if put at top of page along with artist i-box). Another example is sectional hatnote navigation like {{
Main}}
; they're distinguished by templated classes (including unprintworthiness) and by the italic style we use for unavoidable self-references); they're an exception to the separation because, of course, they could not serve their purpose if not used in the relevant sections. Such rationales doesn't apply to the short-description case; there isn't a failure-of-purpose if short-description code goes below hatnote templates. PS: This is making me think that what we should be doing ultimately is putting short-descriptions into out-of-flow boxes with CSS classes (perhaps with specific positioning by default, which someone can fine-tune with user CSS, but which would at least prevent short-description material from visually disrupting articles if placed in mid-page; it would still need to be fixed, but it wouldn't be a big deal.
—
SMcCandlish
☏
¢ 😼
00:17, 11 February 2020 (UTC)
"Bibliography" is discouraged because it is not clear whether it is limited to the works of the subject of the article.. While some articles still use this it seems it is more commonly being replaced with "Works or publications".
Anyway, I'm also unclear on exactly what you're proposing. I would think that in either one- or two-section referencing, we should just use sections (== level). I've seen a few cases where people do things like ==Citations and references== (or ==Notes and references==), followed by ===Citations=== (or ===Notes===) then ===References=== (yeah, sometimes other exact wording like ===Works cited===, whatever.) This sub-sectioning seems pretty pointless and just makes the ToC longer for no benefit. I don't often see things like just ==Citations== followed by ===References===, and am skeptical that's useful (logically the citations are more a subset than the other way around). Finally, the "Bibliography" related stuff appears to be a duplicate of a thread just a little above this one. Short version: we have other terms to use (e.g. "References" or a two-section "Citations" and "References" pair), so we have no reason to use the ambiguous "Bibliography" (nor "Notes" which is actually often for something else).
I am concerned that "...although each is questionable in some contexts" implies that the alternative titles are deprecated in some way. "Bibliography", especially, is used in many articles, including quite a few Featured Articles. Even in a biography, it would be quite hard to mistake a list of works by named authors for a list of works by the subject. Most of the other examples are even more far-fetched. The actual contents of the section would immediately show to a reader that it is not what was assumed (and there is precious little evidence that anyone is making these incorrect assumptions). I could just as easily argue that "Notes" or "References" meant something else. References can be references to the subject of the article in other works for instance. I think we should just state that there are some alternative titles and leave it at that. Spinning Spark 10:54, 10 November 2019 (UTC)
This material (deprecating some titles) was originally inserted with this edit. The edit summary says "see talk", but the talk page discussion at this date has no discussion of actually deprecating titles or the reasons that might be necessary. The discussion is centred on the statistical proportion of titles used and the order they ought to be in. There is thus no historical consensus for this. Spinning Spark 10:51, 11 November 2019 (UTC)
{{
efn}}
and {{
notelist}}
). It's preferable to use "Notes" for that to avoid the perennial and rather stupid argument-to-the-death about whether they are "Foodnotes" or "Endnotes" (it's lame because in a non-paginated publication they are the same thing). —
SMcCandlish
☏
¢ 😼
04:40, 10 February 2020 (UTC)
Any comments?
Midland Railway War Memorial and "rv, per multiple other FAs and WP:CITEVAR" Andy Dingley ( talk) 15:18, 4 March 2020 (UTC)
Two questions:
What do we call the informational boxes that appear at the top of a page, for example:
{{
WPMOS}}
and
{{
Information page}}
Thanks.
Butwhatdoiknow (
talk)
16:19, 12 March 2020 (UTC)
Second question: Are message boxes and banners already listed in this sequence?
If so, where? If not, where should they go? Thanks. Butwhatdoiknow ( talk) 16:55, 12 March 2020 (UTC)
{{
WPMOS}}
nor {{
Information page}}
should ever be used on an article. {{
WPMOS}}
is for use on talk pages, for which
WP:TALKORDER applies; and in that list, this is a WikiProject banner, item 9 in the list. --
Redrose64 🌹 (
talk)
19:45, 12 March 2020 (UTC)
This is very bad advice:
- Succession boxes and geography boxes
- Other navigation templates (footer navboxes)[…] (navbars above {{ Portal bar}})
- Geographical coordinates (if not in Infobox) or {{ coord missing}}
- Authority control templates (taxonbar above Authority control)
- […]
Placing anything between #2 and #4 creates an annoying gap because their borders don't collapse together when they are not truly adjacent. Note that template {{coord|…|…|display=title}}
automagically floats to the top-right for rendering purposes when entered literally anywhere on the page. But today I learned (from somebody else's edit summary) that "consensus" says to put it in the one place where it causes a problem. Unfortunately I can't say I'm surprised. ―
cobaltcigs
21:45, 20 October 2019 (UTC)
<br />
s). Better yet would be totally phasing them out in favor of collapsible navboxes which would show the entire succession (or some sub-range thereof if the list is prohibitively huge) and be more practical to maintain than anything allowing freeform input.<div id="catlinks" […]>
in the mw-interface. Yes, I realize the invisible <div class="printfooter">
is right in the way, and would need to be moved lower by some software change.For a very clear example, see the article
Bill Szymczyk,
before and
after my edit. It seems some aspect of the {{
good article}} indicator/icon's "magical" leap to the top-right corner leaves behind an empty paragraph element <p class="mw-empty-elt"></p>
. That class is display: none;
by default, which is good, but insufficient. Despite being empty and invisible, this placeholder element still exists, which is enough to prevent two <div>
s of class navbox
from being recognized as adjacent (by the CSS rule .navbox + .navbox { margin-top: -1px; }
in
MediaWiki:Common.css). Verily, I can't think of any other scenario in which
only moving the GA icon causes a visible change. Hopefully this one doesn't get reverted. ―
cobaltcigs
09:32, 19 March 2020 (UTC)
{{
good article}}
template per se; boxes with collapsed borders (such as navboxes and authority control) shouldn't have other objects between them. The border-collapse effect only triggers when the two boxes are physically adjacent. --
Redrose64 🌹 (
talk)
21:18, 20 March 2020 (UTC)
- Succession boxes and geography boxes
- Other navigation templates (footer navboxes)[…] (navbars above {{ Portal bar}})
Geographical coordinates (if not in Infobox) or {{ coord missing}}- Authority control templates (taxonbar above Authority control)
- Geographical coordinates (if not in Infobox) or {{ coord missing}}
- […]
All the best:
Rich
Farmbrough (the apparently calm and reasonable)
07:54, 8 April 2020 (UTC).
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)
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)