Wikipedia talk:Manual of Style/Layout

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Manual of Style
WikiProject icon This page falls within the scope of WikiProject Manual of Style, a drive to identify and address contradictions and redundancies, improve language, and coordinate the pages that form the MoS guidelines.
 

See Also section: is our guidance realistic?[edit]

Our instructions for the See Also section include this language:

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

I wonder whether this instruction is actually desirable, and also whether it describes actual practice. Perhaps it is true in situations where the redundancy is obvious, or in cases where the See Also section has grown to include items of questionable relevance. However, other than these reasonable constraints, it seems to me that this is a rule that puts form over function. Especially in long articles, the See Also section functions as a sort of tl;dr which identifies some of the best wikilinks that appeared within the article.

If the best defense of the existing language is that it interprets the word "also," one could reply that the "also" means articles other than this article.

I am not insisting that the sentence simply be deleted. But we should decide exactly what it is we want to say. Maybe that requires a bit more subtlety. Andrew Gradman talk/WP:Hornbook 17:50, 2 February 2014 (UTC)

It describes actual practice when it comes to WP:Good and WP:Featured articles, generally anyway...until someone adds a link to the See also section that is repeated higher in the article. And very experienced Wikipedia editors, such as myself, often remove a link from the See also section that is repeated higher in the article; I usually do. If WP:See also did not have this rule, the See also section could become a large WP:DIRECTORY, as it is in some articles.
This WP:See also rule is generally abiding by WP:OVERLINK, which makes a few exceptions; it states, "Generally, a link should appear only once in an article, but if helpful for readers, links may be repeated in infoboxes, tables, image captions, footnotes, and at the first occurrence after the lead." Flyer22 (talk) 18:07, 2 February 2014 (UTC)
Interesting. Thanks for your reply. So my take away is that there really has formed a conscious , deliberate consensus around this rule. I guess I assumed this language was accidental and not carefully thought out ... but by now I should have known that does not happen on Wikipedia as often as it used to!
Still, I am following up because I wonder whether you ever felt that there were individual cases where certain articles would have been more useful had you not deleted those redundant wikilinks from the See Also section -- and, significantly, whether you can articulate the distinction in a principled way -- like, "While it is important to not create a slippery slope situation where the See Also section winds up looking like a directory, some of these articles are so significant (perhaps PRECISELY because they featured so heavily in the body text!) that we should make an exception."
Speaking as a lawyer, I will volunteer that I understand why it is risky business to suggest changes to longstanding policies. The encyclopedia is working quite well. But in this case I think you would agree that some of those articles were actually enriched by having a more thorough See Also section. In a place as unruly and heterogenous as Wikipedia, policies like this should not be framed as absolutes, but rather as a balance of values (here, usefulness vs. crowdedness) . That puts a thumb in the dike of the slippery slope, and allows people to make case by case solutions to what is essentially an aesthetic problem. Andrew Gradman talk/WP:Hornbook 19:15, 2 February 2014 (UTC)
EDIT: In general, no-discretion policies are preferable where the costs of uncertainty are high, e.g. because quibbling over borderline cases leads to conflict. But I don't think this is such a case -- I don't think we have seen editors become as emotionally invested in having their favorite links in the See Also section! We are not going to see edit wars here. Andrew Gradman talk/WP:Hornbook 19:36, 2 February 2014 (UTC)
You would be awfully surprised then. --Izno (talk) 00:05, 3 February 2014 (UTC)
Andrew Gradman, yes, I oftentimes feel that a link should be repeated. As noted above, if a link is in the lead, WP:See also allows us to repeat a link once after the lead. So that is two chances that a reader has to see a link. There are other chances to repeat a link as well, noted above, which makes more than two chances in some cases. And in those cases, it can be overkill to then add the link to the See also section. The See also section is supposed to tell people to "See this also" because that matter has not yet been addressed in the article, or because it's otherwise relevantly related to the article; that's why it's (generally) not good to have a link repeated in the See also section, as if that matter has not already been addressed. So, yes, I have removed a See also link in cases where I thought that the article benefited from them, but I don't generally feel that way. Sorry for the late reply. And WP:See also and WP:Overlink are guidelines, not policies. Flyer22 (talk) 16:07, 8 February 2014 (UTC)
That sentence has bothered me for quite some time. Sometimes it's just silly not to put a highly related topic in the "See Also" section merely because it was linked earlier in the article. This becomes especially true when the article is very big and the link in the text is unlikely to be easily found by a skim reader. In the end, as far as I'm concerned, good common sense is what matters most for the "See also" links section. Jason Quinn (talk) 14:39, 17 March 2014 (UTC)
  As a short answer to the question posed: no, the guidance is not realistic.
  The common notion and supposed rule that a "See also" section should not duplicate any wiki-links inside an article is being interpreted strictly by some editors who use it as authority for removing duplicate links, without any allowance for editorial discretion. (E.g.: here and here.)
  This notion appears to be derived from an implication that if "See also" is for wiki-links not used in an article, then it is not for links that are used. However, this is syllogistically invalid. That certain items are permitted is not the same thing as permitting only those items.
  It has also been stated "as a general rule" (also at Wikipedia talk:Manual of Style/Layout/Archive_9#.27See_Also.27) that see-also links should not repeat links in the text. This is the application of a more general rule, that links should not be duplicated. However, it is unreasonable that if some other topic is important to more than one section of an article that it cannot be linked in each such section, or that the reader should have to dig for links buried in the text of other sections. It seems more reasonable that links should not be duplicated within any given section, and that in any section where another topic is sufficiently important or relevant to be linked it may be linked on first mention, regardless of any links in other sections.
  In support of restricting "See also" links it has been said that the purpose of this supposed rule "is to stop large, double columned see also listings [and duplication of obvious material]" (Shadowjams, at Wikipedia talk:Manual of Style/Layout/Archive_9#Repeating links in See also section). I agree that is a reasonable purpose; we certainly do not want long lists of links of marginal interest. But this rule is much more restrictive than necessary for such a purpose. As some editors are interpreting it strictly, without allowing for exceptions, some clarification is needed.
  Probably we should discuss the purpose of "See also" and suitable inclusion and exclusion criteria. However, until that is resolved I think we should add some language to the effect that links in "See also" are not precluded, and should not be removed, on the sole basis of being duplicated elsewhere in the article. ~ J. Johnson (JJ) (talk) 21:40, 6 May 2014 (UTC)

As this issue came to a matter of WP:OVERLINK and its "only once" rule I have proposed here that links be allowed once per section. ~ J. Johnson (JJ) (talk) 20:59, 18 May 2014 (UTC)

The current guidelines work very well because they dramatically limit the number of articles that can appear in "See also" to just articles that are highly related but not mentioned in the text. That is often just a handful of links. Changing this logic to just "highly related terms" will quickly expand the candidate links to many dozen. Just think of how many you could come up with for an article like 2014 Crimean crisis (which already has over 20). There is clearly some benefit to this guideline as it (a) promotes articles not linked in the text (additional detail) over already linked articles (repeated detail), and (b) makes sure editors do not spend hours debating which links deserve a second link at the end of an article. SFB 09:24, 15 June 2014 (UTC)

Another further reading issue - do we mean 'anything an editor thinks should be there'?[edit]

I'm having 'editor-recommended' quoted at me to argue that any book recommended by an editor can be in the list. I don't think this was ever intended - surely if a book is added it should be one that is clearly significant in some obvious way, eg mentioned by other authors in the field, etc? Dougweller (talk) 07:41, 10 April 2014 (UTC)

Yeah, good question. Does anyone know what the phrase "editor recommended" is designed to accomplish in Further reading? Maybe we can just delete it. Butwhatdoiknow (talk) 11:40, 10 April 2014 (UTC)
I think that's more a consensus issue, but if it's causing that sort of problem, removing it doesn't seem out of line. Thargor Orlando (talk) 12:57, 10 April 2014 (UTC)
Linking to and phrasing it in line with WP:CON might be a good idea instead. --Izno (talk) 04:05, 24 May 2014 (UTC)

Name of the section which includes the citations[edit]

Should it be called "References" or "Reference list" or something else. all input is welcome at Talk:Albert Anae. thank you. Frietjes (talk) 22:56, 12 June 2014 (UTC)

According to WP:FNNR:

Editors may use any section title that they choose.[1] The most frequent choice is "References"...

  1. ^ One reason this guide does not standardize section headings for citations and explanatory notes is that Wikipedia draws editors from many disciplines (history, English, science, etc.), each with its own note and reference section naming convention (or conventions). For more, see Wikipedia:Perennial proposals#Changes to standard appendices, Wikipedia:Perennial proposals#Establish a house citation style and Template:Cnote2/example.
Mitch Ames (talk) 05:30, 14 June 2014 (UTC)

Proposal: Only one stub template per article[edit]

There is no consensus to limit articles to a maximum of one stub tag. That said, there is enough support to modify the way multiple stub templates appear in an article, but the discussion on how to implement that is still in the brainstorming stage, and might be better suited to a venue with a more technical audience (e.g. WP:VPT). Titoxd(?!? - cool stuff) 01:29, 21 July 2014 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The custom over the past several years is to put several stub templates on an article as a means of categorization. The reason for doing this made sense—people wanting to work on stubs having to do with Subject Matter X can look at the category for stubs in Subject Matter X, while said article would also be appealing to those working on articles in Subject Matter Y. But from the user experience point of view, it's a problematic proposition. Imagine going to an article and seeing:

This article is an X stub.
This article is a Y stub.
This article is a Z stub.

Why does it say the same thing three times? I already knew it was a stub when I read it was one the first time! I thus propose that articles are limited to one stub template per article. Using WikiProject templates on the talk page, we can sort articles into as many stub categories as we like. For the purposes of presentation, however, I think one template would suffice. (I would support further changes to the way we handle stubs on Wikipedia but let's just do one thing at a time.) Harej (talk) 01:16, 14 June 2014 (UTC)

What about something akin to {{multiple issues}} (but less obtrusive), where the different stub tags are grouped together? Nikkimaria (talk) 01:34, 14 June 2014 (UTC)
Is it possible to make the {{stub}} template clever enough to make it only display the first instance on page? (The editors would then be responsible for putting the most significant one first.) Mitch Ames (talk) 08:44, 14 June 2014 (UTC)
This would require massive amounts of editing, but we could go back to just using {{stub}}, using parameters for different categories, e.g. {{stub|Australia|politics}}. The parameters would sort the article into stub categories accordingly. My assumption is that the purpose of stub sorting is categorization. This means that we don't necessarily need to broadcast the stub type on the article; if you're reading an article on Australian politics, you don't need to be informed that it is an Australian politics stub because you already know it's Australian politics. This is a good opportunity to just have one message that is broadcast on each stub. Consistency makes the user experience better. I propose something like this. Note that the demonstration linked to is just the styling with no practical functions. Harej (talk) 19:40, 14 June 2014 (UTC)
I agree with going back to {{stub}} with parameters. A stub should have "enough information ... to provide adequate context", else it risks speedy deletion. (And I fairly sure that the specific stub template doesn't count as "context" for this purpose.) And if there is enough context, the reader doesn't need a stub template to tell them what the article is about.Mitch Ames (talk) 01:52, 15 June 2014 (UTC)
I think concatenating them or grouping them, as proposed immediately above, would be an improvement. It is possible a bot could do this, but it would be quite an intensive effort. I also separately agree that the community could consider a change to the layout of the stub template. --LT910001 (talk) 22:44, 14 June 2014 (UTC)
Grouping the stub templates does sound like a good idea. Failing that, putting them on the talk page would work. NinjaRobotPirate (talk) 01:54, 15 June 2014 (UTC)
There are 2 problems with grouping stubs:
  1. This would make the creation of stub types be a task that only admins and template-editors can do.
  2. It would break the use of normal automated tools (such as AWB) for stub sorting - we would need special ones.
I think the best solution would be if we could have some means of "disappearing" the stub tag if there are others, while maintaining the tag in the wiki-code and the category/categories at the bottom. עוד מישהו Od Mishehu 03:13, 15 June 2014 (UTC)
Od Mishehu, I appreciate the issues you bring up, but I think they can be mitigated. First, the way I would re-design the stub template would have template parameters serve to define categories, in the manner {{{1}}} ---> [[Category:{{{1}}} stubs]]. The template itself would not contain any stub types except it would set off a red flag if a stub is sorted into a category that doesn't exist. This means that to create a stub type, all you would have to do is create a category, which you already have to do when establishing a stub type. Regarding the automated tools, we could ensure a smooth transition by making the old templates still work. We would deprecate the specific stub templates, but they would still technically work. To prevent stub sorting scripts from going nuts, thinking all sorts of articles are unsorted, we could create the template under a new name like {{sorted stub}} or something. What are your thoughts on this? Harej (talk) 04:38, 15 June 2014 (UTC)
Currently, I can go down a list of stubs which would get a new stub tag, and have AWB both add the stub tag in question and remove stub tags which are redundant to it. I doubt that you could create some sort of {{multiple stub}} tag which would allow this functionality easily. A good example of this would be the US state bridge stub tags - the redundant stub tags I was looking for were the state's own top-level and struct stub tags, and the top-level and US bridge-struct tags - a total of 4, easily groupable into 2 groups. And frequently we have upmerged stub tags - that is, stub tags which may eventually have their own category, but don't yet - I have, relatively recently, added a pre-existing {{Maryland-railstation-stub}} tag to many categories, and subsequently creating a Category:Maryland railway station stubs category. This was noticed because the tag existed, even though the category didn't yet - and in the meantime, the tag placed the stubs in the natural parent categories. Close to half of the stub tags are currently upmerged - Category:Stub message templates has about 23,300 tags, but Category:Stub categories has only about 12,600 stub categories. עוד מישהו Od Mishehu 08:50, 15 June 2014 (UTC)
Fascinating how Wikipedia's processes look once you open them up to scrutiny. Is there a reason why one stub category will have two stub templates? Shouldn't it be 1:1 templates to categories? Further, what causes this: are people lazily merging stub categories together without merging the corresponding templates, or are people creating templates but preferring to use pre-existing categories? I'm happy to help create 10,700 categories, or merge 10,700 templates, assuming that it would not conflict with policy. Harej (talk) 20:08, 15 June 2014 (UTC)
It is an artifact of stub sorting, so that trial stubs could be floated that dumped into the broader category, but when there were enough members of the trial set, it would be easy to dump them in a newly created subcategory. --Bejnar (talk) 02:01, 16 June 2014 (UTC)
Dear Everyone, If there is one stub template but embedded categories or conditions then that would improve Wikimedia because it would make the presentation of the content look cleaner but keep the interest of the various project to patrol the stubs. So, I vote to Adopt the new clean stub format. Geraldshields11 (talk) 00:05, 16 June 2014 (UTC)
Programming note: I've started a separate conversation on the number of stub types here. Let's keep this discussion focused on the proposal of having only one stub template per page. Harej (talk) 03:31, 16 June 2014 (UTC)
I am not entirely sure that the user issue that prompted this is that large or pressing; but why not just make stubs invisible on the page and only display in hidden categories? I don't think that we need to tell people that a particular article is a stub, they can see that. What we want is the ability of editors to focus on the stubs where their interest lies. --Bejnar (talk) 02:01, 16 June 2014 (UTC)
They can see that it is a stub, yes, but the template also invites people to edit. My proposed change (latest revision as of this post) adds a nice prominent "Edit Article" button and invitation to edit that is not as necessary on more established edits, plus a link to the Teahouse for those that need help. So more than just stating the obvious, it is an active invitation to improve Wikipedia. Harej (talk) 02:50, 16 June 2014 (UTC)

Oppose as a longtime stub-sorter who is all too familiar with the current complexity of stub templates and their interaction with multiple categories. Even a fairly specific stub like {{Europe-radio-station-stub}} requires either a second stub tag to sort it with the specific country or creation of a new stub template for each country in Europe. Currently, only the UK and Turkey have enough such stub radio station articles to justify a unique template (and {{Turkey-radio-station-stub}} sorts out to Category:European radio station stubs, Category:Turkish media stubs, and Category:Turkish company stubs until there enough stubs to justify Category:Turkish radio station stubs being created. The best way to stop a stub tag from being displayed is to improve the article. - Dravecky (talk) 05:12, 16 June 2014 (UTC)

I Oppose making a rule about editing procedure because I believe this issue can only be solved agreeably with the help of new programming. Until such a thing is implemented, we should leave the style guides alone. I don't think it's yet been proposed to redo the template to allow multiple categories: For example, if the article Ludwig van Beethoven were a stub, adding three tags would result in redundancy: "This is a stub article about a musician... This is a stub article about a German person... This is a stub article about a deaf person." A multi-category tag however, something like (brackets)stub|musician,German,deaf(brackets), could be engineered to create the message "This is a stub article about a musician, a German person, and a deaf person." Muffinator (talk) 00:28, 7 July 2014 (UTC)

@Muffinator: Well, we already have {{Germany-musician-stub}} which covers two of the three... it populates Category:German musician stubs (which contains 199 pages). Intersecting that with deaf people too would not have the potential for the 60+ articles required at WP:WSS/P#Proposing new stub types – procedure. That doesn't mean that we can't further subdivide - there is {{Germany-classical-musician-stub}} after all, which populates Category:German classical musician stubs (containing 113 pages). But for a composer, I'd use {{Germany-composer-stub}}, which populates Category:German composer stubs (373 pages). --Redrose64 (talk) 07:57, 7 July 2014 (UTC)

Let's take a different tack[edit]

So there may be logistical complications with changing the fundamental categorization system or consolidating everything into the same stub template. Would everyone support a MoS change endorsing one stub message per article if there was a way you could still use multiple stub templates, just have only one visible? I think the easiest way to implement this would be a "hide" parameter such that you have:

{{x-stub}}
{{y-stub|hide}}
{{z-stub|hide}}

This would be trivial to implement in {{asbox}}. Let me know what you think. Harej (talk) 11:57, 17 June 2014 (UTC)

That requires every single page with two or more stub templates to be edited (bot job). It also relies on the person making a future edit which adds a second (or subsequent) stub template to remember to include the |hide, and if they are removing the first stub template, they need to remember to remove the |hide from the stub template that becomes the first one. A better way would be to automatically hide all except the first instance of a stub template; it should be possible to do this in one line of CSS:
table.stub:not(:first-of-type) { display: none; }
but although this works on my home intranet, I've found that it works on a Wikipedia page only if there are no previous tables on the page. If the stubs are correctly placed at the bottom, and there is a table of any kind (remember that infoboxes and navboxes are also tables), all the stub templates get hidden, instead of all bar the first one. It's as if the .stub selector was being ignored. If this can be made to work, it would not need any special coding on the individual uses, it also wouldn't need any change to {{asbox}} - the code would go in MediaWiki:Common.css --Redrose64 (talk) 14:55, 17 June 2014 (UTC)
What if you changed that code so that it relied solely on the "stub" class being activated, rather than it being particular to tables that are part of the stub class? Also, is the "not first of type" part standard CSS that can be expected to work across browsers? Harej (talk) 16:47, 17 June 2014 (UTC)
If I remove the table specificity, i.e.
.stub:not(:first-of-type) { display: none; }
the effect is the same. The negation pseudo-class :not() and the :first-of-type pseudo-class are both part of CSS Selectors Level 3, which most browsers have supported for a few years now (includes Firefox 30, Chrome 35, Opera 12, Safari 5). It fails gracefully: if the browser doesn't handle Selectors Level 3 (such as Internet Explorer 8), it will reject the whole rule, so all stub templates will be visible. --Redrose64 (talk) 18:47, 17 June 2014 (UTC)
I would definitely support it, if this works as easily and simply as this - editors don't need to think about it, stub tag creators don't need to think about it, and articles can get multiple stub tag templates freely. עוד מישהו Od Mishehu 07:05, 18 June 2014 (UTC)
I would like some advice please from e.g. Edokter or Gadget850 as to why the selector table.stub:not(:first-of-type) is behaving as if it were table.stub or table:not(:first-of-type) when there are earlier tables on the page. A good page to test on is Dastarkhān because that is a short page with seven stub templates and only one other table (the {{refimprove}} at the top). The CSS rule should hide the second one onwards, leaving the first visible; instead, it hides all of them. --Redrose64 (talk) 12:28, 18 June 2014 (UTC)
:first-of-type aplies to element types only; it does not consider classes. So I'm afraid this method is not a viable option. A possible solution is to use the sibling selector "~" instead, but that does require the stubs to be wrapped in a parent. -- [[User:Edokter]] {{talk}} 17:04, 18 June 2014 (UTC)
Bingo.
table.stub + table.stub { display: none; }
works. What this does is it looks for any two consecutive stub templates, and hides the second of the pair. --Redrose64 (talk) 18:39, 18 June 2014 (UTC)
On a side note, if all-but-the-first stubs are hidden, I think we'll get a load of complaints and question as to why they don't show. -- [[User:Edokter]] {{talk}} 19:12, 18 June 2014 (UTC)
At first. Eventually, users will get used to it. עוד מישהו Od Mishehu 19:51, 18 June 2014 (UTC)
We'll need to update the documentation and make it incredibly obvious that this change has happened. Incidentally, is there anything we need to do to get additional input? Harej (talk) 20:22, 18 June 2014 (UTC)

What if we created a container template where parameters defined template names? The first parameter would be the stub template that's rendered visible; the others would be hidden. The stub templates as-is would continue existing. Harej (talk) 18:15, 18 June 2014 (UTC)

I've raised my objection in the first section of this discussion - makes semi-automated stub sorting (such as with AWB) much more difficult. עוד מישהו Od Mishehu 19:51, 18 June 2014 (UTC)
Ah, true. Plus I think we solved the CSS problem above. Harej (talk) 20:22, 18 June 2014 (UTC)

As a regular stub-sorter, I oppose the idea of hiding second and subsequent stub tags - this will confuse editors who see an article and realise that there are more appropriate stub tags which could be added, and will upset readers in cases where two tags have equal importance but one is made visible and not the other (an example coming to mind is a border crossing: it is a "Country-X stub" and also a "Country-Y stub"). I can appreciate that some articles are outbalanced by, perhaps, three stub tags appearing on a one-sentence article: the answer is to expand the article, not to hide the stub tags. PamD 22:50, 18 June 2014 (UTC)

I would support many of the ideas proposed here. Hiding all but the first (or even all) of the stub templates sounds reasonable. These could be made visible to those who wanted to see them (via personal CSS). Combining all into one template is probably the neatest solution, but incredibly labour intensive. — Martin (MSGJ · talk) 14:00, 23 June 2014 (UTC)


The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Horizontal line[edit]

In accordance with the guideline, I have been systematically removing instances of the horizontal line from articles. I met with objection when doing so at some hockey articles. In defending its use, User:Aleenf1 stated that it is used legitimately as separators between match results, also in use in many football articles. The guideline is categorical and makes no mention of exceptions, and the table appears perfectly clear and acceptable without the lines. Can anyone recall the reason why the horizontal line is deprecated, and why these can/should not be removed throughout the encyclopaedia? Thanks, -- Ohc ¡digame! 03:48, 17 June 2014 (UTC)

I can't answer your question, but I can point out that guidelines are not rules. Butwhatdoiknow (talk) 11:53, 17 June 2014 (UTC)
  • "Although previous versions of HTML defined the hr element only in presentational terms, the element has now been given the specific semantic purpose of representing a 'paragraph-level thematic break'."[1]
  • "Some examples of thematic breaks that can be marked up using the hr element include a scene change in a story, or a transition to another topic within a section of a reference book."
It appears to me that the various sections in question are changes in topic, thus hr is valid. We normally use section headings and subheadings, but the horizontal rule is more appropriate in this instance. I recommend that it be moved to the template so it can be applied consistently, perhaps with a switch to disable it as needed. I have noted that the MoS really does not address the semantics involved in HTML elements. --  Gadget850 talk 17:14, 17 June 2014 (UTC)
The guideline does list several exceptions: "Rules can be used to provide separation inside certain templates (for example, sidebar derivatives), within discussions, or when needed in some other formats." - Dravecky (talk) 03:36, 18 June 2014 (UTC)
I have the impression (the rule is before my time) that it's really about the old, pre-dab-page style of writing articles. Horizontal lines were used to separate content that we'd now put on separate pages.
I kind of like the look of the hockey article you linked. It's basically an airy-looking table built with a template (for the columns) and horizontal lines (to delineate rows). It could actually be turned into a table, while still keeping that format, if wanted, but this system is probably simpler to edit. WhatamIdoing (talk) 15:00, 18 June 2014 (UTC)
I have to agree, <hr />s work very well there. Based on the W3C guidance that Gadget850 quotes, I think that WP:LINE is overdue for an update. — Scott talk 23:11, 18 June 2014 (UTC)

Dispute over "see also" link[edit]

Should the Casey Kasem article contain a link to "List of vegans" in the see also section, despite his veganism not being the most notable part of his public life? Should that list (and others) be more widely linked in see also sections? There's a dispute about this at the Casey Kasem talk page; please direct any responses there. Graham87 01:57, 27 June 2014 (UTC)

Improve categories tag[edit]

Template:Improve categories says "It is recommended that this template be placed at the bottom of the page, where readers will look for the categories." Just wondering if there's a WP:ORDER standard for where exactly? E.g, after categories, or before defaultsort?

Msmarmalade (talk) 23:30, 3 July 2014 (UTC)

Since its exact positioning in the defaultsort/categories cluster does not affect how or where it is displayed on the page, on the rare occasions I've used the tag I've put it at the very bottom of the categories for easiest editing. - Dravecky (talk) 12:39, 6 August 2014 (UTC)

Another dispute over "see also" link[edit]

Here is a good question: Is having a see-also link between two articles a coat rack? Greg Mortenson and Somaly Mam both are accused of fabricating portions of their biographies to enhance their charities. Is having a see-also link between the two a coat rack? Would your average reader want to jump between the two articles based on that connection? While I was reading about the Somaly Mam controversy, I asked myself who was that other guy that had the same thing happen ... Please join the lively discussion at Talk:Greg Mortenson --Richard Arthur Norton (1958- ) (talk) 16:50, 24 July 2014 (UTC)

Further reading is not external links[edit]

I am going to revert this edit made at 12:22, 26 March 2014. The edit added the following sentence to the "Further reading" section:

Any links to external websites included under Further reading are subject to the guidelines described at Wikipedia:External links.

As far as I can tell above this change was not discussed and if it had been I hope that others would not support it as I do not think it helps the project. There are many quirks in external links that do not apply to citations, and Further reading tends to be seen as a repository for general references that go beyond what is currently cited in the article. This means it is not uncommon for jstor and ODNB articles to be included in further reading both of which according to those who worry about such things in "External links" are forbidden (from Wikipedia:External links "one should generally avoid providing external links to: ... Sites that require payment or registration").

It is not uncommon for an article to have in its "Further reading" section links to books in other languages, particularly if for example article is about a long dead French person where the detailed biographies about the person are in French yet there is a ban in Wikipedia:External links against "Non-English-language content".

What is acceptable for a Further reading section tends to follow reliable sources usage rather than external links usage, and WP:V specifically says:

  • WP:NONENG: "Citations to non-English sources are allowed...English-language sources are preferred over non-English ones, whenever English sources of equal quality and relevance are available." -- This content policy advise seems to me far better advise for further reading than the advise in external links guidleine.
  • WP:SOURCEACCESS "Do not reject sources just because they are hard or costly to access." I suggest that better advise is to paraphrase the WP:NONENG: "Citations to pay sources are allowed, however free to access sources are preferred over pay to access ones, whenever free to access sources of equal quality and relevance are available."

So I think that the addition was inappropriate because if the sentence I am removing is taken at face value introduces silly inconsistencies:

  • It means that it is OK add a reliable sources as a {{citation}} in further reading, but if it is to an ODNB article, you can mention its doi but can not provide a link to the doi because that is an external link and there are different rules for external links placed within a "Further reading" section.
  • Likewise if one includes in further reading a mention of an article in the Allgemeine Deutsche Biographie, if that article is available on Wikisource (see s:de:ADB:Register/A), one may not link to it.

-- PBS (talk) 16:53, 5 August 2014 (UTC)

It was discussed, see Wikipedia talk:Manual of Style/Layout/Archive 10#Change to further reading guideline. --Redrose64 (talk) 18:12, 5 August 2014 (UTC)
Thank you for the information, and having read the section I think it need further discussion. For example there seems to be a misunderstanding of the phrase "The Further reading section should not duplicate the content of the External links section," -- the assumption by some seemed to be that duplicated entries should be removed from the "Further reading" section (it ain't necessarily so) -- the phrase can just as equally well be rephrased "External links section should not duplicate the content of the "Further reading section", because if there is duplication one can remove the duplicated entries from either unless an entry clear belonged in one rather than the other.
But leaving that issue to one side, before the sentence I have removed is put back, I think there needs to be a discussion about the anomalies I have pointed out exist when it is in place and why such a sentence ought to be in there given those anomalies. -- PBS (talk) 22:32, 5 August 2014 (UTC)
We could simplify the statement: All URLs, anywhere in the mainspace except as part of citations to reliable sources that directly support material in the article, are subject to WP:EL. That would include URLs present in the ==Further reading== section.
Your conflation of "generally avoid" and "forbidden" is very strange. There's a reason that the "generally avoid" language appears under the shortcut ELNO rather than ELNEVER: these kinds of links should only be generally, i.e., not always, avoided. WhatamIdoing (talk) 03:49, 6 August 2014 (UTC)
(1) For those who do not know WhatamIdoing I disagree whether general references are suitable as citations that support content (I take the position that they are not). But for this discussion let us assume that they are. General references do not "directly support material in the article" so are they subject to WP:EL?
(2) But does not "generally avoid" links cover links to most jstor articles in further reading? Are you suggesting that jstor articles may be listed in further reading, but generally not with convenience links to the jstor location? -- PBS (talk) 07:34, 6 August 2014 (UTC)
(3) What about links to foreign sources in "Further reading", are you supporting the idea that on can place a citation to a foreign source in further reading but not if the include a link to a website such as Wikisource, the Internet Archive, or Google books?
EL makes no distinction between WP:V's reliable sources and non reliable sources, so in my experience the External links section is often a repository for all those sources that editors like and to place in the article but fail WP:V while "Further reading" tends to contain reliable sources.
WP:EL is in the main drafted for the content of the "External links" section and I think expanding EL coverage is not desirable, because it causes complications and is instruction creep. -- PBS (talk) 07:34, 6 August 2014 (UTC)
About (1), WP:General references do "directly support material in the article". The problem with them is that the reader has no idea which specific material is being supported by which general reference.
About (2) "generally avoid" does not cover JSTOR, doi, PMID, etc. links to publications with full bibliographic citations in ==Further reading==, as is obvious from looking at the actual practice. Also,
About (3), I have said no such thing. Also, Wikisource links are normally placed under ==External links==.
"Generally avoid" does not mean "forbidden". There are some fairly common exceptions, and you have identified most of them here.
The problem with your attempt to make WP:V apply is that ==Further reading== entries, by definition, are not used to verify anything on the page. The concept of verification is irrelevant. WhatamIdoing (talk) 18:31, 6 August 2014 (UTC)
(1) General references do not "directly support material in the article" as defined by WP:V which demands inline citations (WP:PROVEIT). If the reader has no idea "which specific material is being supported by which general reference" then a general reference is not "directly support material in the article".
(2) "generally avoid" does not cover JSTOR ... who says? Yes it is practice in further reading sections to include jstor links but it could be read as a violation of WP:EL hence one of my reasons for removing the recently added sentence.
(3) you may not have said it but WP:EL says so in WP:NONENGEL, and you seem to be supporting the idea that EL applies to more than the External links section.
(3a) I think you are confusing Wikisource in English, for which there is no prohibition and for example those in German as in the example I gave (s:de:ADB:Register/A) which WP:NONENGEL make problematic for inclusion in the external links section.
My mention of WP:V is for its definition of reliable sources, those sources do not have to verify anything on the page to be reliable sources. For example reliable sources are used by WP:AT without their being used to directly verify anything on the page. EL has been organically grown to cover problems that have arisen in the external links section and I think to try to extend its reach causes problems and is instruction creep.
-- PBS (talk) 20:03, 6 August 2014 (UTC)
There's no such thing as a reliable source that does not verify anything. The only way to know whether a source is reliable is to consider whether the material that the source supports. Even the most gold-plated, independent, academic, secondary source is not "reliable" unless the material that it supports is present in that source—and a truly lousy self-published blog can be entirely reliable for other material.
NONENGEL specifically gives "when the link is to the subject's text in its original language", which should cover all links to non-English Wikisource texts, as well as the other examples you've given.
And, yes, "generally avoid" does cover JSTOR, and we know that it covers JSTOR because no non-POINTy efforts to remove such links have ever stood. WhatamIdoing (talk) 19:25, 7 August 2014 (UTC)
WP:SOURCES does not support your assertion that "There's no such thing as a reliable source that does not verify anything". The definition is separate from usage with the exception of the sentence "Use sources..." which (is obviously linked to WP:PROVEIT and probably needs to be moved from this section -- particularly if one support the use of general references. The more useful sentence for Further reading (and general references) is "The appropriateness of any source depends on the context." -- and it needs to be because the definition is used also by WP:AT. I still stand by my assertion (that in the subject areas I am interested in -- I have not read millions of articles), most entries in further reading section tend to be governed by SOURCES and whether or not they have links to a web page is incidental to their inclusion. Extending EL to cover Further reading is detrimental to the project because in introduces needless complexities and is instruction creep.
Not every subject has an "its [own] original language" (as many are inanimate) and for other reasons. For example places now in Poland may have details of their German history only available in German. An example with humans: many Irish soldiers volunteered for French service after the Flight of the Wild Geese, a detailed biography on one of them or a notable action in which they were involved may only be available in French and not in Irish or English.
As to your last point, then why is the wording in EL if it is continually being breached? Why bring that FUD into Further reading?
-- PBS (talk) 08:10, 8 August 2014 (UTC)
It appears WhatamIdoing has mixed two questions: 1) whether a source is reliable, and 2) the use of a source for verification (support) of content in an article. By her definition any source used in an article's text cannot be used in a further reading, which, inverted, implies that nothing in a "Further reading" section will be present in the text. Having arrived at this mutual exclusion, she then imputes that verification is entirely a matter for one area, and not the other. After this I don't quite follow her logic. She seems to be saying that as verification requires reliable sources, sources are reliable only the extent they verify something. ~ J. Johnson (JJ) (talk) 19:35, 9 August 2014 (UTC)