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.

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 112 pages). But for a composer, I'd use {{Germany-composer-stub}}, which populates Category:German composer stubs (383 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:


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

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)