Wikipedia talk:Manual of Style/Layout/Archive 15

Changing placement of Template:Subject bar, Template:Portal bar, and Template:Sister bar

I propose making the following change to MOS:ORDER:

---

4. End matter

1. Succession boxes and geography boxes
2. {{Sister bar}}
3. {{Portal bar}} or {{Subject bar}}
4. Other navigation footer templates (navboxes)
5. {{Taxonbar}}
6. Authority control templates
7. Geographical coordinates (if not in the infobox) or {{coord missing}}
8. Defaultsort
9. Categories
10. {{Improve categories}} or {{Uncategorized}} (These can alternatively be placed with other maintenance templates before the article content)
11. Stub templates

---

Background

• {{Portal bar}} is designed to show a horizontal list of portals when {{Portal}} causes layout problems in the "See also" section. It is transcluded on ~123,000 pages.
• {{Sister bar}} is designed to show a horizontal list of sister project links when {{Sister project links}} causes layout problems in the "External links" section. It is transcluded on ~3,000 pages.
• {{Subject bar}} is a wrapper around {{Sister bar}} and/or {{Portal bar}}. It is transcluded on ~18,000 pages.

Problems caused by current MOS:ORDER

Looks strange

As discussed last year, placing {{Portal bar}} in between navboxes looks strange. For example, Javascript currently looks like:

Reader confusion

As discussed at Template talk:Portal bar, users may be confused by having {{Portal bar}} abut against navboxes. They may think that the portal bar is an open subbox of the previous navbox, and not understand the "Show" button. The following example from Charles III was discussed:

In this case, some editors were concerned that readers would think that the Portal bar was the content of the "Links to Related Articles". There was no visual fix to {{Portal bar}} that both fixed the problem and was found to be acceptable by a large fraction of editors.

Buried interwiki links

{{Subject bar}} currently follows the placement for {{Portal bar}} (although it is not explicit in the MOS). This produces a strange ordering when {{Subject bar}} contains both {{Portal bar}} and {{Sister bar}}: a list of external interwiki links is buried in the navboxes. For example, the External links section of Polar Bear currently has a navbox in the middle of the ELs and interwiki links:

• Photos, facts, videos from Polar Bears International that funds population, preservation, and DNA studies of the polar bear
• Map: Here's where the polar bears are vanishing
• Photos of Manual of Style/Layout/Archive 15 on Sealife Collection

No guidance for Template:Sister bar

Currently, editors do not have guidance of where to place {{Sister bar}}.

Proposed solution

Let's place {{Sister bar}}, {{Portal bar}}, and {{Subject bar}} before all of the Navboxes. This will eliminate the odd layout of putting the portal box inside a stack of navboxes, will eliminate any confusion about the portal bar being a subbox, and will place {{Sister bar}} immediately at the bottom of the External Links section (if there are no succession boxes). After changing MOS:ORDER, the examples above would look like:

Polar bear

• Photos, facts, videos from Polar Bears International that funds population, preservation, and DNA studies of the polar bear
• Map: Here's where the polar bears are vanishing
• Photos of Manual of Style/Layout/Archive 15 on Sealife Collection

Discussion regarding template placement

What do other editors think? Pinging previous discussants (Lord Belbury—Michael Bednarek—Krisgabwoosh—DocWatson42—Bahnfrend—Trialpears—Nikkimaria—Redrose64—Kvng) — hike395 (talk) 19:34, 18 September 2022 (UTC)

I feel the best solution here is moving Portal bar and similar to after Taxonbar and authority control which would resolve the problems with it looking strange and interwikis being buried. The big difference though is that putting portal bar last keeps everything (roughly) ordered by importance to our readers. More readers are looking for other articles than portals and that should be reflected in the order. The possible reader confusion with the show button is a potential problem, but I have no idea how widespread it is and feel it is a lower priority than ordering them by importance. Also noting that this is what I suggested doing in 2021 with lukewarm reception. --Trialpears (talk) 22:33, 18 September 2022 (UTC)

I saw you suggested this --- my concern with that solution is that it will drag {{Subject bar}} even further away from the EL section, so we are putting sister project links in a very surprising place (at the very bottom of the page) for ~2000 articles. Sister project links are more important than navboxes, I think. (It's unfortunate that {{Subject bar}} mashes together portal and sister project links). — hike395 (talk) 22:42, 18 September 2022 (UTC)

That's another concern I hadn't considered. I don't see it as huge one since it should in the vast majority of cases still be on screen at the same time regardless. The exception being if you have something monstrously large like the succession boxes at Charles III or too many navboxes that should be collapsed. Using {{Sisterlinks}} is also a solution and then you get a box floating to the right of the external links both making the grouping more logical and in many cases making the space usage more efficient, but that isn't that relevant to the main discussion. --Trialpears (talk) 23:07, 18 September 2022 (UTC)

No, portals should be before authority control, as internal links come before external links. The theory that order should be based on likely importance to readers is interesting but not what we're currently doing more broadly. Nikkimaria (talk) 02:11, 19 September 2022 (UTC)

@Nikkimaria: what do you think of the original proposal? — hike395 (talk) 02:23, 19 September 2022 (UTC)

I think the placement you've proposed for {{portal bar}}/{{subject bar}} makes sense. I'm less sure about {{sister bar}}. Nikkimaria (talk) 02:30, 19 September 2022 (UTC)

Support I completely agree with the proposal. It appears that @Nikkimaria: misunderstands the reason for it. The proposed arrangement has nothing to do with likely importance to readers, but is intended mainly to prevent "Looks strange" (see above) and "Reader confusion" (again, see above). Bahnfrend (talk) 08:30, 20 September 2022 (UTC)

I think Nikkimaria was reacting to Trialpears' comments, not the proposal — hike395 (talk) 09:04, 20 September 2022 (UTC)

Correct. Nikkimaria (talk) 01:51, 21 September 2022 (UTC)

Oppose change As stated, above, internal links come before external links, so the portal bar should be above authority control. As for the issue of readers confusing the portal bar with an open navbox, I've still yet to see proof that this is a widespread issue and so oppose a change to order or portal bar size/layout/etc. until that's demonstrated. As of now, I'm satisfied with the status quo. Krisgabwoosh (talk) 04:48, 21 September 2022 (UTC)

Oppose change as stated by Krisgabwoosh. Also, I feel that the order should give priority to the subject of the article—{{Medical resources}} where appropriate, followed by the navbar(s) on subject of the article in descending order of specificity, Portal bar, Sister links bar, Taxon bar, and Authority control bar. As side notes,

1). I favor adding back Interlanguage links to the Appendices list (with a note that they are to be phased out wherever possible, with the links added to Wikidata), as I have run across two of them recently, one in the last few days.

2). I'm wondering why {{Coord}} templates are at the bottom of the page, instead of at the top, where they display.

—DocWatson42 (talk) 07:18, 21 September 2022 (UTC)

• I suggest that {{Medical resources}} should be included in this discussion: there is an ongoing discussion at Template talk:Medical resources#Revisiting template positioning, following a 2017 RfC at Template talk:Medical resources/Archive 2#RfC on placement of Medical condition classification and resources template, in which the location of that template is being discussed. It seems to me that there is a group of templates which could be call "Metadata templates" (the term is used in Template:Taxonbar#Position but does not appear in WP:GLOSSARY), including at least {{taxonbar}} and {{Medical resources}}, perhaps others, and which ought to have a location specified in WP:ORDER. Or just place this one on the same line, or immediately below, {{taxonbar}}. PamD 07:24, 21 September 2022 (UTC)

I stand by my [edit: opinion about the placement of that template] in the current Medical resources discussion. —DocWatson42 (talk) 04:00, 22 September 2022 (UTC)

Let me clarify, since PamD has expressed confusion. I would prefer:

1. Before the article content

1. Short description
2. {{DISPLAYTITLE}}, {{Lowercase title}}, {{Italic title}} (some of these may also be placed before the infobox or after the infobox)
3. Geographical coordinates (if not in the infobox) or {{coord missing}}
4. Hatnotes
5. {{Featured list}}, {{Featured article}} and {{Good article}} (where appropriate for article status)
6. Deletion / protection tags (CSD, PROD, AFD, PP notices)
7. Maintenance / dispute tags including {{Improve categories}} or {{Uncategorized}}
8. English variety and date style
9. Infoboxes
10. Language maintenance templates
11. Images
12. Navigation header templates (sidebar templates)

4. End matter

1. {{Medical resources}}
2. Succession boxes and geography boxes
3. {{Portal bar}} or {{Subject bar}}
4. {{Sister bar}}
5. Other navigation footer templates (navboxes)
6. {{Taxonbar}}
7. Authority control templates
8. Defaultsort
9. Categories
10. Stub templates
11. Interlanguage links (for the few legacy links that do not match the Wikidata links in the left sidebar)

My proposed changes are bolded.

• Place the {{Coord}} and {{Coord missing}} templates where the "Coord" template is actually displayed, so that it can be found, rather than buried out of sight at the bottom of the article.
• Place the {{Improve categories}} or {{Uncategorized}} with the rest of the maintenance templates, in part so that they can be found, rather than buried out of sight at the bottom of the article.
• The standalone "Portal bar" is actually a little shorter than the one in the "Subject bar", and placing it there follows the internal links/external links standard (which I admit I differ with in the case of the "Medical resources" template—it should be easy to find for novice users).

— DocWatson42 (talk) 08:21, 22 September 2022 (UTC)

 Question: How are the external links in {{Medical resources}} different than the ones in {{Taxonbar}} or {{Authority control}}? These all seem to be links to external databases, but I don't understand the links in {{Medical resources}}, so maybe they are different in kind or importance in some way?

 Question: Does having full-width boxes before the succession boxes look good to you? If that is considered acceptable by multiple editors, I would suggest also putting {{Sister bar}} before the succession boxes, because that would make them appear as part of the EL section (where they truly belong). — hike395 (talk) 13:30, 22 September 2022 (UTC)

1. The external links in {{Medical resources}} are the same type as in {{Taxonbar}} and {{Authority control}}.
2. They do not. And I'm generally in favor of using {{Sister project links}} whenever possible.

DocWatson42 (talk) 11:10, 23 September 2022 (UTC)

Common Section names

I am considering doing some Wikipedia editing. I normally confine my work to talk pages at present. I would find a list of common section headings with brief usage comments useful in a page like this. E.g. “See Also” with notes on why it is good to use and dangers in using it.

Perhaps an easy way to find projects recommended headings as well. CuriousMarkE (talk) 05:42, 22 March 2023 (UTC)

• "See Also" is not an acceptable heading. We use sentence case, not title case, for headings, so "See also". Other conventions are highly variable; maybe some wikiprojects have guidelines And MOS:SECTIONSTYLE has some general info. Dicklyon (talk) 06:58, 23 March 2023 (UTC)
• For the list of common section headings, see Wikipedia:Manual of Style/Layout#Order of article elements.

For recommended project headings, see Wikipedia:Manual of Style/Layout#Specialized layout. I'm adding a link to that in the Order of article elements section.

With respect to usage comments, that may be a subject for an essay, but seems like wp:KUDZU for a guideline. I may be reading too much into your post, but I think it may be helpful for you to worry less about making a mistake and concentrate more on being wp:BOLD, leaving it to other editors to fix any technical issues. - Butwhatdoiknow (talk) 15:36, 23 March 2023 (UTC)

Adding a line/space between top templates and Infobox template or article beginning

I think with the added amount of hidden templates, article information notices, maintenance tags and other notices that precede the article, that a space/line break should be made standard separating all the normal and accessory notices from the Infobox, to better differentiate between what the reader/editor sees as the article and the numerous templates placed above the article beginning. I believe his helps in editing, especially in vector, and makes it easier to add other, less used templates such as Merge, Split, Copyedit, Cleanup, etc. While editing, this area can then be pretty much ingnored and you can get right into the article. In other words, this would put a line break between position #7 and #8 in the Wikipedia:Manual of Style/Layout#Order of article elements on the project page. I appreciate any comments or suggestions. Thanks, GenQuest ^"scribble" 02:01, 9 March 2023 (UTC)

I'm slightly concerned that we will get more unwanted blank lines if a template on either side of this newline doesn't generate any content. I don't believe there are any high use templates susceptible to this issue, but I know it's a risk from when I messed up with {{Short description|none}} generating thousands of excess newlines a couple years ago. If this occurs it would be very difficult for most editors to diagnose and would likely be reintroduced later by well meaning editors trying to follow the guideline. --Trialpears (talk) 02:16, 9 March 2023 (UTC)

I'm really talking about a break between the top-templates, and the Infobox/article beginning, such as:

{{Short description|American phlebotomist (1951–2020)}}
{{Use American English|date=March 2023}}
{{Use mdy dates|date=March 2023}}

{{Infobox person
| image = {Placeholder}.png
| caption = joe performing in 2011
etc...

GenQuest ^"scribble" 02:34, 9 March 2023 (UTC)

I sometimes insert linebreaks in this frontmatter stuff to improve source code readability. I haven't seen this affect layout. Some editors undo it anyway. I do not fight them. Not a big deal. Why do you think it is necessary to create a layout policy for this? ~Kvng (talk) 22:33, 21 March 2023 (UTC)

Because it makes it easier to edit the mark-up/source code in the header (hidden template) area with the inserted line break. (They don't affect the readability at all.) I add them also, but they are constantly removed or reverted. Since they don't affect what the reader sees, why not make it easier on us gnomes and article editors, and just leave the break? . GenQuest ^"scribble" 00:03, 22 March 2023 (UTC)

Blank lines above the infobox can cause an extra-tall gap to appear above the lead section text. This is because {{Short description}}, {{Use American English}} and {{Use mdy dates}} are themselves treated as a blank line. --Redrose64 🌹 (talk) 00:18, 22 March 2023 (UTC)

Redrose64 A single line break/separator has zero-effect on top-space or where the article begins on any of my devices. Try it out. GenQuest ^"scribble" 00:32, 22 March 2023 (UTC)

@GenQuest:I notice you've removed some line breaks between infobox and lead. Why not leave a break there to help editors find the lead? Dicklyon (talk) 06:45, 23 March 2023 (UTC)

It has been pointed out to me on my talk page that sometimes when I put a blank line between an infobox or such template and the lead, extra space appears in the rendered article, and that that's because the template source has a "noinclude" section at its end, with a newline before the noinclude tag. If those templates were fixed to not have that newline (as many templates are already), the problem goes away. So, is it OK if I fix a bunch of templates? I find 6900 college football templates that transclude Template:CFB Standings End and follow that by a noinclude; I haven't yet checked how many have a newline between; looks like most or all do. Example fixes: [1], [2]. Not pretty in the template source, but allows prettier article source without creating a visible problem in rendered articles. Dicklyon (talk) 09:48, 27 March 2023 (UTC)

Of those 6900 templates I mentioned, about 230 don't need to have a newline removed. So about 6570 to fix... Dicklyon (talk) 11:24, 27 March 2023 (UTC)

@Dicklyon: I agree that removing the newline in the template source code is not pretty. A large portion of relevant edits on those 6000+ templates are mine. I put the newline in there for readability. Is there an elegant way to make it so the newline doesn't get transcluded into article? I suspect this may require some sort of change to the fundamental coding of Wikipedia? If we have to go the brute force route, should we get a bot to run though these and remove all those newlines? We may want to consider doing the same for sports other than football; cf. Category:American college sports standings templates. Jweiss11 (talk) 17:37, 27 March 2023 (UTC)

Yes, I'd be happier to see it done in a better and more automated way. I've just done a bunch of football edits where I was putting a blank line before the lead, which is something I had done in lots of other areas before, when a couple of editors noticed this unusual side effect. I've stopped adding such spaces, but for fixing the existing problems, taking blank lines out of the article source seems like the hardest and most unsatifying approach. It would be nice if the this kind of noinclude placement wouldn't bring in the extra newline, but I bet it's hard to change that in the underlying code, too. I can do this football batch with JWB in a few hours. Dicklyon (talk) 20:40, 27 March 2023 (UTC)

When a template is transcluded, the whole of the template code is copied. Only then are the <noinclude>...</noinclude>, <onlyinclude>...</onlyinclude> and <includeonly>...</includeonly> tags processed. So if a template has newlines before a <noinclude>, those newlines will be included in the transcluding page, see WP:NOINCLUDE (the part just after the table). To suppress them will require a fundamental change to the MediaWiki template parser, and you would need to file a feature request at phab:. --Redrose64 🌹 (talk) 21:19, 27 March 2023 (UTC)

Yeah, I figured it would be too hard to fix something so deeply ingrained. I just checked, and found that the pattern }}<noinclude> followed by newline is quite common (JWB stops enumerating at 10000). So this approach of not putting a newline before the noinclude tag seems to be a pretty standard way to avoid the problem. Dicklyon (talk) 09:12, 28 March 2023 (UTC)

So, for clarity, where are the hidden "noinclude" tags? GenQuest ^"scribble" 17:09, 28 March 2023 (UTC)

Who mentioned hidden "noinclude" tags? --Redrose64 🌹 (talk) 19:08, 28 March 2023 (UTC)

Not hidden exactly, but at the end of the source code for the templates, such that putting a blank line after the template invocation turns into two blank lines. See my recent contribs. Dicklyon (talk) 08:31, 29 March 2023 (UTC)

@GenQuest: In which case, tags like these. --Redrose64 🌹 (talk) 20:15, 29 March 2023 (UTC)

I made a test-case example to illustrate the problem, using a pair of adjacent templates that I have not modified, one of which has the problem (due to this edit that put a newline before the noinclude tag): User:Dicklyon/Template_test. I also did a search through 10,000 templates with the noinclude tag at the end of a line, and found only 12% of them had a newline before the tag. So it seems to be a widespread practice, though not universally appreciated, to not put a newline before a noinclude tag (at least at the end of a template's source). I've done ahead and removed the extra newlines from the 6900 college football templates I mentioned, so that particular corner of wiki template space won't cause us more trouble. Dicklyon (talk) 08:03, 30 March 2023 (UTC)

Request update to Wikipedia:Manual of Style/Layout#Links to sister projects

After a discussion on my talk page, I realized that Wikipedia:Manual of Style/Layout#Links to sister projects should be updated slightly. The current wording states:

Links to Wikimedia sister projects and {{Spoken Wikipedia}} should generally appear in "External links", not under "See also". If the article has no "External links" section, then place sister links at the top of the last section in the article. Two exceptions: Wiktionary and Wikisource links may be linked inline (e.g. to an unusual word or the text of a document being discussed).

More precisely, box-type templates (such as {{Commons category}}, shown at right) have to be put at the beginning of the last section of the article (which is not necessarily the "External links" section) so that boxes will appear next to, rather than below, the list items. Do not make a section whose sole content is box-type templates.

If box-type templates are not good, either because they result in a long sequence of right-aligned boxes hanging off the bottom of the article, or because there are no external links except sister project ones, then consider using "inline" templates, such as {{Commons category-inline}} in the "External links" section, so that links to sister projects appear as list items, like this:

• Media related to Wikimedia Foundation at Wikimedia Commons

...and I propose that this section should be replaced with (main points/changes in bold):

Links to Wikimedia sister projects and {{Spoken Wikipedia}} should generally appear in "External links", not under "See also". If the article has no "External links" section, then place the sister link(s) in a new "External links" section using inline templates. If there is more than one sister link, a combination of box-type and "inline" templates can be used, as long as the section contains at least one "inline" template.

• Box-type templates (such as {{Commons category}}, shown at right) have to be put at the beginning of the "External links" section of the article so that boxes will appear next to, rather than below, the list items. (Do not make a section whose sole content is box-type templates.)
• "Inline" templates are used when box-type templates are not good, either because they result in a long sequence of right-aligned boxes hanging off the bottom of the article, or because there are no external links except sister project ones. "Inline" templates, such as {{Commons category-inline}}, create links to sister projects that appear as list items, like this:
  • Media related to Wikimedia Foundation at Wikimedia Commons

If an external link is added and/or exists in the "External links" section, the "inline" templates linking to sister projects can be replaced with their respective box-type templates.

These wording changes remedy a few issues:

• Placing a box-type template in the "References" section (which could be the last section of the article) causes the reference list to be formatted improperly if width customization options are used in the {{Reflist}} template. With the new wording, there's instruction that box-type templates are only placed in an "External links" section where there is a very low chance of there being such issues.
• This ensures clearer instruction about how and when to add sister link templates to the article by always having the templates in an "External links" section, preventing the need for moving links to an "External links" section in the event the section is created later (which is the case with the current instruction, even if it is not stated specifically.)
• The new instruction reduces WP:INSTRUCTIONCREEP by not specifying which sister projects are allowed to be linked "inline" by themselves. (Currently, the passage states that only links to Wiktionary and Wikivoyage can be by themselves as inline templates in an "External links" section).
• The new formatting and wording more clearly defines what "box-type" and "inline" templates are by making their descriptions list items with definitions.
• Instruction has been added stating the circumstances when "inline" templates can be replaced with "box-type" templates, which currently is not present in the section.

...Thoughts? Steel1943 (talk) 21:03, 13 July 2023 (UTC)

Took a nice large dose of fukitol after this edit/revert. Good luck, ya red tape-wrapping bummers. Steel1943 (talk) 21:36, 22 July 2023 (UTC)

TL;DR. Maybe make these changes, one a day, and include the explanation for each in your edit summaries. - Butwhatdoiknow (talk) 16:17, 17 July 2023 (UTC)

The "TLDR" can disappear if the first passage is ignored; it's just the current state of the text for reference. Steel1943 (talk) 19:40, 17 July 2023 (UTC)

Okay, it's been over a week with no "support/oppose"-style feedback, so I'm going to assume this is uncontroversial per WP:SILENCE and make the changes. Steel1943 (talk) 15:45, 21 July 2023 (UTC)

I'm late to the party, but I support the change, as I prefer consistency in article order, and would also welcome a similar change for Portal templates/See also sections. I also don't mind sections whose sole content is box-type templates, but I avoid making them since others object. —DocWatson42 (talk) 11:02, 22 July 2023 (UTC)

Maybe there was no feedback for a week because your post is TL;DR. As I suggested above, I'm okay with you making bold edits to find out what folks think of your changes. - Butwhatdoiknow (talk) 14:30, 22 July 2023 (UTC)

Well, they found out, but couldn't handle the revert of their work. Too bad, but if that's how they react when someone disagrees with them, then it's probably a good thing they've decided to leave. It saved themself from warning for incivility. BilCat (talk) 22:22, 22 July 2023 (UTC)

Well, I'm not at all happy at how that played out – I had just no idea that the user felt so strongly about this rather trivial matter, and greatly regret having contributed, even unwittingly, to the departure of a valued long-term editor. That said, I oppose the proposed changes, both on the grounds of instruction creep and because creating a whole extra section for one sister-project link is quite excessive. Unfortunately, EL sections have a tendency to attract spam, so are probably best avoided unless actually necessary. If we absolutely have to have yet more rules, I'd suggest something along the lines of "Do not create an external links section just for sister-project links". Oh, I see that my revert was undone by Butwhatdoiknow on the grounds that consensus was not required; I disagree – once a bold edit has been challenged, consensus is indeed required to re-instate it. Justlettersandnumbers (talk) 13:13, 28 July 2023 (UTC)

@Justlettersandnumbers - You and I agree that when an edit is reverted for a substantive reason, such as you have provided above, the editors should resolve the challenge before the change is reinstated. WP:QUO. Where we diverge is whether it is appropriate for an editor to revert without giving a substantive reason. I believe it isn't. WP:DRNC.

In this case, User:Steel1943 first provided a lengthy explanation of their proposal on talk. They then waited a significant period of time and received two responses. One neutral and one positive. Finally, they make their non-bold edit, only to see their thorough and patient work undone by a substance-free hit-and-run revert. I can see how frustrating the experience must have been for them. - Butwhatdoiknow (talk) 16:35, 28 July 2023 (UTC)

• Comment: This discussion was brought to my attention following a revert. While some of WP:MOSSIS seems pretty clear, some of it is left a bit ambiguous. That may be intentional (speculation), to allow for situations in which a hard rule would not be a good idea; instead of an exception to a hard rule, it's left a bit ambiguous. I agree that perhaps WP:MOSSIS needs a clarification update, but I wouldn't advise going at a thumbtack with a maul. Personally, I don't mind § External links containing only one sister project, provided it's the bulleted inline-type. Sister projects are external to Wikipedia as their own project, with their own set of rules and templates (though I find this annoying at times). The reasoning against the box-type in such a situation is the excessive white space it creates. I would suggest (my personal guide) that a box-type sister project template is a good idea in §El if there is at least three bulleted external links, or when it's otherwise necessary/unavoidable (taking font/zoom/platform into account). Again, I would write that as a guide, not a strict policy. — CJDOS, Sheridan, OR (talk) 19:19, 29 July 2023 (UTC)
  Note: I'm specifically mentioning Wikipedia:Wikimedia sister projects#Where to place links (WP:MOSSIS), while this discussion has called Wikipedia:Manual of Style/Layout#Links to sister projects. — CJDOS, Sheridan, OR (talk) 19:43, 29 July 2023 (UTC)

"Mos:FURTHER" listed at Redirects for discussion

The redirect Mos:FURTHER has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2023 October 11 § Mos:FURTHER until a consensus is reached. Utopes _{(talk / cont)} 23:45, 11 October 2023 (UTC)

Proposed modification to further reading sections

In 2014, we added the following line to MOS:FURTHER: "Any links to external websites included under "Further reading" are subject to the guidelines described at Wikipedia:External links."

I'd like to tighten that requirement by pointing to Wikipedia:Reliable sources instead of external links. My understanding of what differentiates further reading sections from external links is that they are intended to hold reliable sources anyway ("publications that would help interested readers learn more about the article subject", my emphasis).

This change would also allow paywalled sources in further reading sections, which seems fair given that we currently allow editors to list offline sources that may or may not require money to acquire, and WP:PAYWALL allows their use elsewhere in articles. Ed ^{[talk] [OMT]} 01:22, 9 October 2023 (UTC)

Just so it is clear in my head, your proposal would not change the criteria for publications to appear, just the criteria for when links may be placed within a listed publication entry. Do I have that right? - Butwhatdoiknow (talk) 15:51, 9 October 2023 (UTC)

@Butwhatdoiknow: The change would require "further reading" entries to be reliable sources, and remove the requirement that they meet the "external links" guideline. (I don't believe EL would add any benefit above RS, and it would maybe even conflict because EL doesn't apply to references.) Ed ^{[talk] [OMT]} 02:13, 10 October 2023 (UTC)

But the sentence you propose to change only applies to "links to external websites" (it doesn't include other entries). Maybe the RS link should appear elsewhere in the FURTHER - perhaps in a new sentence? - Butwhatdoiknow (talk) 07:08, 10 October 2023 (UTC)

• Oppose. Many articles don't require literature to be "reliable sources" because they are not "sources", just literature the reader may be interested in that is related to the topic. Let's not fix what is not broken and let's WP:NOTCENSORED be taken into account also. Regards, Thinker78 (talk) 04:12, 10 October 2023 (UTC)

  NOTCENSORED does not apply to every removal of anything; it has a specific meaning that isn't relevant to the rationale for the proposed change. Nikkimaria (talk) 04:27, 10 October 2023 (UTC)

  In your opinion but I respect that you disagree with me. Regards, Thinker78 (talk) 04:51, 10 October 2023 (UTC)

  @Thinker78: Thanks for your thoughts! Do you have examples of articles that use further reading sections for non-reliable sources? I imagine it would be for self-published sources that aren't available online? I don't believe I've seen this before. I'd be open to tweaking this proposed change to allow for what I'm thinking is an edge case. Ed ^{[talk] [OMT]} 04:31, 10 October 2023 (UTC)

  I don't have examples of articles at hand. But I would imagine one benefit of not restricting it is if someone wants to know more about a fringe theory that is not supposed to be treated extensively in the article body (specially maybe the author of it which may not be reliable source), the Further Reading section could be the appropriate place to go. Regards, Thinker78 (talk) 04:57, 10 October 2023 (UTC)

• Support. There is already an external links section that can hold external links per the external links guidelines. This clarification for this section seems quite reasonable, and as noted allows informative publications that otherwise are technically not permitted. Nikkimaria (talk) 04:27, 10 October 2023 (UTC)
• Support – Maybe "(and) reputable/scholarly" captures the spirit of help interested readers learn more about the article subject. -- Michael Bednarek (talk) 04:36, 10 October 2023 (UTC)
• Oppose - WP:RS would exclude WP:PRIMARY sources which I see as acceptable Further reading material. I do support lifting the current implied restriction on paywalled material. I suspect that was an unintentional consequence of adoption of WP:EL in 2014. ~Kvng (talk) 15:01, 15 October 2023 (UTC)
  • @Kvng: I don't see the proposal as excluding primary source material. WP:SCHOLARSHIP says that secondary sources are preferred, and not that they are barred. Perhaps, though, this proposal needs to be made wider than a link swap -- will think. Ed ^{[talk] [OMT]} 20:48, 17 October 2023 (UTC)
• Oppose. WP:PRIMARY sources may usefully go there, as Kvng points out. Another option might be partially fictionalized accounts of historical events – clearly not WP:RELIABLE, but may nevertheless be good for this section, if identified accordingly. Or even biased or otherwise problematic accounts, again provided they are clearly labelled as such and no undue weight is given to them. "Further reading" content is not actually used as sources, hence we can afford to be a bit more tolerant in what we accept there. Gawaon (talk) 16:28, 17 October 2023 (UTC)

Notes