Hello all, theMOS Taskforce is conducting an audit of all style guidelines in an attempt to rationalize and improve the styleguides, which have grown in an uncoordinated, often illogical and overlapping way. Many of the guidelines under the "lists" category seem to be unused, lacking in substance or tone, or simply redundant. What does everyone here think about merging some or all of the following guidelines into this page?
WP:STAND is often referenced and debated-on in AfDs and I would object to that being merged into here, or changed drastically without a wide consensus to do so. The MOS page probably also should stay split out due to its length and detail. I have hardly seen the pages on embedded lists and pro and con lists referenced and agree that they could be consolidated into this guideline.ThemFromSpace18:24, 12 April 2010 (UTC)
I complete agree with Themfromspace's comments.
Addendum to which: MOS (Lists of works) covers 3 specific types in a central location (bibliographies, discographies, filmographies), rather than splitting them apart to their parent Wikiproject styleguides. So I think that is already consolidated. --Quiddity (talk)19:04, 12 April 2010 (UTC)
I understand what Themfromspace is saying; however, there is a plethora of list MoSes. How much of what they say is in common? Are there dissonances between any of them? Are they properly coordinated in their far-flung state? Is that state the easiest for editors to consult and find what they need? Why is there some limit on the size of a MoS? (MoS main and MOSNUM are pretty large, and it is settled there that the size is OK.) And finally, is there not an advantage in creating a critical mass of regular editors and a simpler, more orderly relationship with the FLC process?
I believe already Matthewedwards and Dabomb87 have volunteered to conduct the audit. I ask users to support them, or even tojoin them.Tony(talk)01:28, 13 April 2010 (UTC)
I support Dabomb87's proposal and I agree that this should includewp:lists. I think that there are too many list guidelines, and when it comes to the notability/inclusion criteria for lists, I think the sum of these guidelines provides misleading/defective/conflicting guidance. I second a merger. --Gavin Collins (talk|contribs)14:18, 19 April 2010 (UTC)
Active Banana - Actually this is not a badly concieved list as lists go. Inclusion criteria is good (the lead could be improved a bit), the entries appear valid, and the overall organization is better than many lists (not sure that the tables in the 3rd grouping go well with the rest of the list though). What I am saying however, is that absent a specificWhy this is a complete mess from you, it is difficult to know what you asking. If you want to take the time to improve this list, I would suggest making two specific improvements: 1) Alphabetize the section headings (right now they are listed in what appears to be a random order). 2) For each linked entry, expand the description of the entry using the lead text (modified as necessary) from each individual article. This will give the reader a better idea of what the list entry is about. If there are sources from the article lead, carry them over to this article.List of management consulting firms shows a good example of this. 3)Think about strengthening the lead to make inclusion criteria clearer than it already is. If you have any additional questions, let me know. Thanks--Mike Cline (talk)16:52, 24 May 2010 (UTC)
Move
The following discussion is an archived discussion of arequested move.Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.
The above discussion is preserved as an archive of arequested move.Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.
A LIST is...?
What is a list? A list of anything anybody can think of under a definition (with no links)? A list of Wikipedia article linksonly? Something in between? Thenutshell and thelead of this guideline seem to totally miss answering this basic question. And the article does not seem to state this succinctly, unless I am missing something. Reading between the lines of most of this guideline the answer seems to be "Lists are lists ofWikipedia articles used to aid navigation". Some articles under Glossary, Bibliography, Discography, and Etymology have links only, some are dictionaries, some are in between. And I see lists that are big linkfarms. So what is the definition? I ran into this question here[1] with the other editor said "What guideline says that?". It would really help if this guideline had aWP:MOSBEGIN.Ohioartdude2 (talk)17:02, 4 June 2010 (UTC)
Columns
If, for example, you have a list of 200 or so names, is there any convention for using thecolumn templates? I see quite a few of extremely long lists, but not many utilize columns (granted, some do). Do most users discourage columns for some technical reason or something, or has it just not become a habit for most users?64.85.221.140 (talk)12:57, 20 June 2010 (UTC)
Afaik, columns don't work in Internet Explorer, Opera, or Safari, but do work in Firefox. (Based onTemplate:Reflist#Browser support for columns). So they can be used anywhere, but we have to structure layouts based on the assumption that they won't work for the majority of readers. HTH. --Quiddity (talk)18:51, 20 June 2010 (UTC)
You can useTemplate:multicol orTemplate:col-begin to get a cross browser solution. You can also useTemplate:div col which is easier, because you don't have to specify a column break, butdoesn't work in IE or Opera.
The result is that I've seen editors replacing perfectly functional cross browser code withTemplate:div col and breaking the columns for IE users.
I've also seen editors addingTemplate:div col to "See Also" sections in dozens of articles at a time, when almost the same amount of effort with the other alternatives would give a solution that works for all readers instead of half of them.
I am a web developer, and if I release websites that don't work in IE then I am not doing my job correctly. Yes, it's a pain, yes, I wish IE would adopt proper standards...etc...etc...
But I do wonder why we allow the use of templates that in reality will only work for half our readers - it just feels wrong to me.
AtTalk:List of Lew Carpenter cites a discusion is pending regarding the proposed deletion of a list. The user who is proposing the deletion cites, "... list of cites from a single book on a single person [does not]constitutes an encyclopedic entry. I was unable to locate similar articles on Wikipedia. I fail to see the notability of such a list. Even [if] within the article itself, it seems unusual." That user proposes adding each page element as a reference cite. That would be rather cumbersome. Please provide input on the best way to handle this. Thank you.Jrcrin001 (talk)22:26, 19 November 2010 (UTC)
Page 66 …for Bill Quinlan, a starting defensive end, and Lew Carpenter, a vete…
Page 114 …off right guard for sixteen yards, then found Lew Carpenter …
Page 128 …got the offense moving again. Taylor and Lew Carpenter ran f…
In order to learn anything from this list, one would have to have a copy of the bookThat First Season by John Eisenberg in hand. And if one did have the book in hand, one would also have the book's index at hand, and one could look up all the references to Lew Carpenter oneself, without needing this Wikipedia list. --Metropolitan90(talk)03:17, 20 November 2010 (UTC)
Help: auto-sort lists?
Is there a template or some kind of list that just sorts itself? Simple example, say the list of members on Wikipedia Project Gymnastics. People will come and add there name and the list will become randomized. Is there a field that just makes the list autosort? Or do I have to put a table in?TCO (talk)05:49, 27 November 2010 (UTC)
I was about to but upon searching the archives it seems that at the very bottom ofArchive 5 Quiddity stated that there is an exception for 'navigational' pages in which he included timelines. I however disagree that timelines should be considered navigational pages, although some are strictly navigational I believe the majority are encyclopedic lists, and many are classed as such by their respective WikiProjects' templates. --Ϫ23:49, 27 November 2010 (UTC)
Hmm yes, although 'graphical' can also represent tabled, but not sure how else to word it. --Ϫ12:11, 28 November 2010 (UTC)
MOS: prose vs bulleted lists (notable residents)
A discussion is currently taking place about the MOSrecommendation that bulleted lists should be rewritten as prose. It specifically concerns making a possible exception for sections on 'Notable residents' in articles about towns and cities. Your comments are welcome at:Wikipedia talk:Manual of Style (embedded lists). Thanks. --Kudpung (talk)02:41, 8 January 2011 (UTC)
Guidance on list
Hi, a couple of editors are currently working onList of caves which is broken down by continent/country. Gradually the country sub-lists are getting long enough (and don't contain too many red links) to warrant their own article with a {{main|Example Country}} redirect. The question is whether the original content in the List of caves article should be deleted. I read somewhere that it should be left where it is but any new item should only be added to the sub-article. The problem with this is that after decades the information may be vastly out sync. Is there a WP policy for this? If not I would propose that once a sub-article (with content) is created, the original content on the main List of caves page is deleted. However, that could lead to a situation where the main list has no content other than a series of redirects to subarticles. What do other editors think?► Philg88 ◄talk 23:48, Saturday February 26, 2011 (UTC)
Uppercase or lowercase?
I can't find any guidance on the use of uppercase or lowercase in the first letter of list items ... are there any Wikipedia principles on this? If so, perhaps this should be included in theManual of Style (lists) article.--Andersneld (talk)08:08, 24 March 2011 (UTC)
I looked for the same question, and found guidancehere: "As a matter of style, list items should start with a capital letter." Personally, I don't think that's logical in all situations (you'd write "The interior of the earth has three layers: crust, mantle and core." and I don't see why inserting bullets into that list suddenly means capitals are necessary), but that's what the guidelines say.Dave.Dunford (talk)13:06, 10 October 2011 (UTC)
Complex list formatting
AtWP:DEADREF, I need a numbered list of steps. One step (#2) needs a sub-list of (currently) two bullet pointsin the middle of the instructions.
So I have done this:
Step one, which is easy enough.
Step two, which requires you to look at
This sub-item and
That sub-item followed by cautions about how you implement this step.
Step three, which is simple enough.
The problem is that the "cautions" appear to be part of "That sub-item", when they are actually a critical part of "Step two". Is there a way to return the "cautions" to "Step two", with the correct level of indentation, without screwing up the numbering?WhatamIdoing (talk)19:39, 28 March 2011 (UTC)
Instead of using a 'br' tag, use a 'div' and set its style to have a negative margin so that the caution text lines up with the level of indenting you want:
Step one, which is easy enough.
Step two, which requires you to look at
This sub-item and
That sub-item
followed by cautions about how you implement this step.
Using updated HTML terminology for "definition lists"
What used to be called a "definition list" in HTML4, was renamed "association list" several years ago in HTML5 to reflect the fact that these lists may be (and are) used for many purposes other than just definitions. For example, they may contain "terms and definitions, metadata topics and values, questions and answers, or any other groups of name-value data."[2]. Therefore, I propose to change the text to reflect the new html terminology, and suggest these other uses for association lists.COGDEN20:11, 11 May 2011 (UTC)
I don't mind adding the new term, but I think we want to keep the old one, since some editors are already familiar with it. One approach is to use the new name everywhere, but add "(old name)" after its first appearance on a page or section.WhatamIdoing (talk)15:51, 12 May 2011 (UTC)
I was expecting to see Roman numerals (I, II, III, IV, V) as an option for a numbered list, but apparently that is not the case. Varlaam (talk)21:54, 17 August 2011 (UTC)
Some who follow this page may be interested in the recent effort to delete -- whether by PROD or AfD -- lists reflecting certain national poll results. The results reflected those people the polled public viewed as the "greatest" in various countries. The polls are reflectedhere; many of the indicated poll results have been PRODed and/or AfD'd in the past day.--Epeefleche (talk)15:24, 4 October 2011 (UTC)
reliable sources and list entries
An editor who has done some excellent research in creating thelist of Christian hardcore bands seems to be of the opinion that a phrase in a single album review that loosely associates a band with a related genre is sufficient to adding that band or artist to this list. Some other editors feel that the music should be representative of the style at the time and that several articles, particularly of contested artists, should be provided.
Granted, most lists don't even have a single reference for the entries, so this article is outstanding. Could we have a few people step in on the article to discuss? --Walter Görlitz (talk)04:06, 27 October 2011 (UTC)
Is there any particular reason why they shouldn't? Is there any guideline on how countries should be arranged (e.g. into sections, or into rows in a table) on Wikipedia lists?1.65.193.107 (talk)13:17, 13 January 2012 (UTC)
Should every single item on a list have a reference?
This has come up time and again. I would like the wording on this page to specifically answer this question to avoid problems. If no one actually sincerely doubts the entries on a list are accurate, should you be required to have a reference for it anyway? Most list articles don't have references for every entry in them, especially if the information on them can be easily verified in the Wikipedia articles they link to. I suggest the following change:
The verifiability policy states that if material is challenged or likely to be challenged, it is the responsibility of the editor who adds or restores the material to an article to cite sources for that material.
Obviously we don't have a reference to every single sentence and every single statement in every article there is. So no sense doing that to list articles either. I suggest we change this to:
If any information is sincerely doubted, then it can be challenged and removed. Consensus can be formed on the talk page of an article if something needs a reference to remain. Editors should never just remove something, simply because it doesn't have a reference.
I suspect some rewording would be useful, but along a different tack than you've taken. A list entry is essentially the child of the inclusion or selection criteria laid out in the lead. That inclusion criteria defines the group or set that comprises the list. Individual entries should be verifiable as members of that set or group. Sometimes that membership is obvious, other times its not, but membership in the group or set is what must be verifiable. Just by way of examples: If one looks atCharles Dickens bibliography, membership in the group is clear, an entry must have been authored by Charles Dickens. Sourcing each entry to validate the fact that Dickens was indeed the author serves little purpose unless there is controversy over the authorship of a particular work. On the other hand, if one looks atBibliography of the Lewis and Clark Expedition they will see that most entries are sourced to references that indeed verify the work is about Lewis and Clark. Unfortunately, we've don't talk about inclusion criteria in this MOS. Whatever wording is changed, it should be that entries in a list should be verifiable members of the group or set that the list is about. --Mike Cline (talk)21:24, 13 January 2012 (UTC)
Please seethis discussion that recently concluded. Basically: it's up to editors to determine if the material is contentious enough per WP:V to include cites , or if just linking to the respective pages is sufficient. --MASEM (t)21:38, 13 January 2012 (UTC)
This page is probably the wrong place to address it, since its focus is on how to write and format a decent list as part of an article. I suppose we ought to get back to the brief section on sourcing that we started talking about adding toWP:STANDALONE a while ago.WhatamIdoing (talk)22:07, 13 January 2012 (UTC)
BTW, I've just boldly drafted such a section for STANDALONE. Please read it and either make your own bold attempt to improve it, or leave a note on the talk page with suggestions.WhatamIdoing (talk)22:26, 13 January 2012 (UTC)
[[4]] Good start, better than nothing. But not really going to be effective. My way isbetter, it specific, leaving no room to argue. And if I boldly change something, I'm certain someone seeing my name will automatically revert it.DreamFocus00:00, 14 January 2012 (UTC)
*Comment It's pretty clear that our verifiability policy requires that every single item on a list have a reference, if challenged or likely to be challenged.Dlabtot (talk)19:20, 16 January 2012 (UTC)
Sure, but it's also pretty clear that many lists have items that aren't the least bitWP:LIKELY to be challenged. (I doubt that any of us could imagine a good-faith question about whetherApple should be included in theList of fruits, for example.) Some lists will have no items at all that are likely to be challenged.WhatamIdoing (talk)22:45, 16 January 2012 (UTC)
Exactly so. Any Wikipedia content challenged or likely to be challenged needs a reference. Content not likely to be challenged does not - till it is challenged.
I would further add that a list item that consists of a link to a Wikipedia article relies on the verifibility of that linked article.Dlabtot (talk)17:33, 17 January 2012 (UTC)
Just for reference, look at thesourcing bibliographic entries section[5]] in WikiProject Bibliographies to see how that project approaches individual list entry sourcing. Its too verbose for a guideline, but does convey a comprehensive approach consistent withWP:V. --Mike Cline (talk) 10:54 pm, Yesterday (UTC+0)
I agree withDlabtot Also, WhatamIdoing is not a reliable editor and it is a waste of time assuming good faith in that individual. Her reference list[6] about Da Costa's syndrome included number 7 by Oglesby Paul who described it as common in the first paragraph[7], and number 7, the Rare Diseases Database, which includes it on one of it's many lists[8]. Those two items are still on the current reference list for that topic three years later.
Another example of her abuse of lists can be seen where she places the ailment in the category of "Somatoform disorders" and yet number 5 from her reference list is a lecture by Paul Wood. The category of somatoform refers to imaginary symptoms and the link page includes Da Costa's syndrome in it's list[9], whereas Wood mentions the difficulty of distinguishing visceral from somatic symptoms and describes three good reasons why the left inframammary pain is not imaginary[10]
WhatamIdoing responds to challenges by arrogantly ignoring them or changing the subject so there needs to be an improvement in the means of ensuring the reliability of list entries.— Precedingunsigned comment added by27.33.141.67 (talk)07:57, 17 January 2012 (UTC)
This is justPosturewriter (talk·contribs) engaging inWP:Block evasion; I suppose that someone ought to report it. His comments here are no worse than the extensive complaints about Wikipedia not permitting his POV pushing and original research that he's posted at his personal website. He is correct that I do not assume good faith when dealing with users who have been indefinitely blocked because of their bad behavior (documented, in this case, in an RFC and a request to ArbCom).WhatamIdoing (talk)22:16, 17 January 2012 (UTC)
WhatamIdoing: I am old enough to be your father and would like you to take responsibility for your actions, instead of acting like a child by changing the subject and rushing off to add comments to 20 other discussions in the hope that this one will be lost in the history of edits. You need to explain the irreconcilable contradictions in your references. You could start by telling this group of editors that you are too busy on other discussions to be able to actually read them. You might also like to explain who, outside of Wikipedia, is giving them to you, and telling you that they are relevant to your POV. If they are not 'giving them to you' then why haven't you read them, and why are you using them.— Precedingunsigned comment added by27.33.141.67 (talk)02:37, 18 January 2012 (UTC)
WhatamIdoing is behaving in her typical devious way by ignoring this discussion, and contributing to many other talk pages. In one case she is even trying to give the false impression that she has the moral authority to give a 'big' thankyou to an editor for improving articles by providing reliable references, and adding that Wikipedia needs more people like that[11]— Precedingunsigned comment added by27.33.141.67 (talk)08:34, 20 January 2012 (UTC)
WhatamIdoing is still evading her responsiblity to account for the unreliable and contradictory nature of her choice of references, and yet is trying to give other groups the impression that her standards are good enough to give these instructions on 21-1-2012 . . . "Appropriate sources for encyclopedia articles are primarily on the subject in question and are authored or published in a way that gives you confidence that the material is accurate."[12]. It is a pity that she doesn't take her own advice.— Precedingunsigned comment added by27.33.141.67 (talk)06:49, 22 January 2012 (UTC)
Should every single item on a list have a reference? Yes and no. Like material in other articles, if a bit is contested it should be sourced and if sourcing is impossible the contested bit should be removed. Ideally every contestable bit of information should be sourced but we are a work in progress so material widely-understood to besourceable would be acceptable to most editors. FL class articles are a bit different; I would expect every bit of information except the most obvious to be tied back somewhere to a source (although it may not need to be sourced in-line if the bulk of a list is derived from a single source).ThemFromSpace19:28, 17 January 2012 (UTC)
Roman numeral numbering (again)
Apparently I enquired about this back in August (Archive 7), but I have no recollection of doing so, or the context. (That's what a brain haemorrhage can do for you.) Here is an existing example,Symphony No. 8 (Kabeláč), where you have 9 Parts which, I assume, come verbatim from a musical score with Roman numbering. So it is not purely a hypothetical. The recommendation back in August was to take a look atHelp:List#Changing_the_list_type for an example of doing it the hard way. Varlaam (talk)05:35, 13 February 2012 (UTC)
Inline HTML
I've just reverted two edits which suggested that inline HTML should be used, in articles (in some cases) in preference to templates. It's my understanding that the MoS does not recommend this.Andy Mabbett (Pigsonthewing);Talk to Andy;Andy's edits23:47, 29 February 2012 (UTC)
Yes, but the currentWikipedia:Manual of Style/Lists#Streamlined style or horizontal style already suggested the exact same construction for hlist as I added and you reverted for plainlist on my edit. If that is not recommended I do not have an issue with that but please correct that section as well. Part of the issue is that there is a large promotion of using classes to style lists in alternative ways and a push away from heavy use of templating for such things. You can plainly see this movement within navboxes, infoboxes, sidebars, and even directly in wiki table markup.50.53.15.51 (talk)23:54, 29 February 2012 (UTC)
Also on that note I am trying to remove references to{{unbulleted list}} and its alias{{ubl}} as they give nothing over{{plainlist}} and its associated class, limit list length, and promote a more templating approach to lists rather than existing wiki list markup.50.53.15.51 (talk)23:56, 29 February 2012 (UTC)
Please include suggestions to do things along the following lines:
There is no consensus to remove thousands of other templates either but that hardly means they are recommended (and certainly not in MoS).50.53.15.51 (talk)00:27, 1 March 2012 (UTC)
{{plainlist}} should be preferred over{{ubl}} as the former has less parsing overhead and uses familiar list markup, but {ubl} will still have some appropriate uses, which is, I believe, what Frietjes is referring to. {plainlist} should also be preferred over a div w/class=hlist in most cases. Explicit use of hlist is best used in template class parameters and places such as between pipes in wiki-table markup, although for a one-off a {plainlist} in the data cell would be clearer (template invocations being more-wiki than html class attributes).Alarbus (talk)04:19, 1 March 2012 (UTC)
I agree and was not considering discouraging the usage of{{flatlist}} or{{plainlist}} but I was thinking{{ubl}} should not be recommended except in a few rare circumstances and even then it is not necessary. The problem with lists in image captions is not{{plainlist}} and{{ubl}} is not the solution—{{ubl}} is one (less than optimal) work-around because it happens to use HTML markup lists and not wiki lists. The real issue is the parser and the convoluted image/media syntax that makes wiki lists not work withing image captions.{{ubl}} is now implemented with classplainlist and HTML list markup. I can use{{plainlist}} just fine within an image caption (so long as I do not use wiki lists and instead use use HTML markup lists like{{ubl}} does).{{plainlist}} (and{{flatlist}}) does not even create a list—it just wraps theplainlist (orhlist) style class around any potential lists within it which causes any such lists to be rendered differently; it works fine and it not at issue. For these same reasons{{collapsible list}} will work within an image caption but a standard wiki list within{{hidden}} will not. This is the same sort of comparison between{{plainlist}} and{{ubl}} (both either make collapsible lists of render unbulleted lists and the latter items do not even make lists but rather just make a list render differently).50.53.15.51 (talk)05:36, 1 March 2012 (UTC)
Your examples are using raw html for the ul/li which is poor form; I guess that means that {plainlist} can work in image captions, but that markup should be fixed on sight.Alarbus (talk)06:32, 1 March 2012 (UTC)
Poor form? So the poor form goes away if I wrap it in a template? Even if I buy that argument, my point is that{{ubl}} is not the optimal way to create lists with HTML markup even within a template.50.53.15.51 (talk)06:48, 1 March 2012 (UTC)
Yup, it goes to the template, which at least removes it from the view of most editors. All sorts of raw html appears in templates. It's good to encapsulate complexity. And it's good to keep template implementations clean if possible. But no raw ul/li in image captions, please; you might scare a n00b.
I see you're doing hlist in navbox; please keep that up. And most {ubl} out there can and should be changed to {plainlist}. It has a much longer history, which is why there are thousands underfoot.Alarbus (talk)07:22, 1 March 2012 (UTC)
&& other appropriate place, too, of course. The tracking was added by WOSlinker; he'll be adding tracking elsewhere once it's not so easy to find things that need work (I already asked). It might be time. SeeUser:WOSlinker/wrapping.Alarbus (talk)09:55, 1 March 2012 (UTC)
I personally feel recommending{{plainlist}} and{{flatlist}} was the right thing but I was just following what had been there (the HTML div) and addressingAndy Mabbett's issue of having direct HTML markup in MoS. I do feel part of the recommendations should include the class usage as well as in terms of lists such cases are highly common over the rare solitary list. I believe MoS Accessibility has some on that angle now.50.53.15.51 (talk)14:30, 1 March 2012 (UTC)
Need for repeated wikilinking of same target
Looking throughBritish Academy Television Awards 2011 I realized that the unlinking of target articles that have already been linked is counterproductive in a list of this kind. This being a list of awards sees the same articles listed many times in different categories where the shows or people have been nominated or won the award. I find it very cumbersome having to scroll back in order to find any given item wikilinked and find myself instead copying the title and pasting it directly into the search box. The MoS should address this problem in a constructive manner. __meco (talk)12:47, 26 November 2011 (UTC)
I'm not sure where to ask, as I don't think it needs anything as advanced as a peer review or something like that, but discussionhere seems to have stalled, and I pretty much ran out of ideas a few weeks ago on how to improve the (list) article, if anyone can take a quick glance and give me a list of homework or ideas that would be a big help.Penyulap ☏09:53, 3 May 2012 (UTC)
Numbering lists which aren't numbered by an outside source is consideredWP:Original Research. For your dilemma, I suggest adding a sentence or two to the beginning describing how many their are and why there might be different counts. But stating such and such a flight is the 85th flight, if the Russians didn't label it as such, isn't a good idea.Dkriegls (talk)11:33, 3 May 2012 (UTC)
Lead sentence of List
If I understand correctly, these three openings are all self-references but none areWP:SELF.
Depends on the context.WP:Self allows for "References that exist in a way that assumes the reader is using an encyclopedia" as inWP:Splitting. If the list is stand alone then self referencing the point of the list is a widely practices consensus. However, if the list is embedded, there might be a better way to intro, that flows from the article, but not always. If you have a specific issue, feel free to bring it up here.Dkriegls (talk)21:39, 21 May 2012 (UTC)
Thanks. "complete" and "list of books" were poor examples in a short note. My present inquiries concern standalone lists and lead paragraphs(?) that do not, or perhaps should not, repeat the article name so closely to bold it. (Some issues are more broadly pertinent. I'll continue here although today I discovered and read both the Embedded and Standalone Talk; not their archives, of course.)
1. Do we have a standard acceptable way to make remarks about the completeness of a list relative to either (a) members of a kind or (b) wikipedia articles about members of a kind? If i understand correctly we should not compose remarks (b); they should be standard (related exhibit:Template:incomplete list).
Exhibit:List of mythologies. ?Have we any approved way to say in the lead, essentially, "This list may never be complete but it includes all [maybe-restricted]mythologies that have their own articles (2012-05-22)."?
If not in the lead, is such communication permitted in a footnote?
2. None of our articles opens "This article ..." or "The following ..." or even "This". But most lists open "Thislist of ... is"/contains/covers/includes/verbs or "This list is"; "This list of Xs verbs blah-blah" where the title is "List of blah-blah Xs"; "The following Xs verb"; "The following are Xs that ..."; or "This is a list of ...".
I am surprised to find these openings are common even among lists chosen to illustrate the Manual of Style. It appears that they are recommended.
Consider our List of winners of the National Book Awards, which I heavily revised this winter, and wrote the entire lead. Is there any reason not to open, "These books and authors have won ..."Exhibit (current version)? Is there any reason to open anything like, (no boldface; i don't know why not) "The following is a partial list of winners of the National Book Awards."Exhibit (old version)?
P.S. I'm unsure where "Style" in MOS speaks primarily to high quality, B or Good, on matters that should be ignored everywhere there is a Stub tag and may be unhealthy distractions in Start land. I know that it isn't unusual to mention Style in Talk about a Start, or in a Start edit summary without any Talk. --P64 (talk)21:16, 22 May 2012 (UTC)
Well,List of mythologies is lacking a qualityWikipedia:Lead section, as is theList of winners of the National Book Award. Though self referencing intros for lists is wide spread, it is not widely used on Featured Lists. I would recommend referring toWP:Featured lists for examples of quality lead sections. They almost always go into some depth about the subject, as apposed to simply stating "This is a list of".Ashley Tisdale discography is a good example of explaining the list by stating "The discography of Ashley Tisdale consists of two..." without any self-referencing like 'and this is here discography". I was actually hard pressed to find an example of self-referencing, but in the FLList of extreme points of India it says "Consequently, this list mentions both the disputed and undisputed eastern-most points in India." The title states the inclusion category, but self-referencing is probably best used only if qualifications to the category need to be made.
Comment, Notable people lists almost always use semicolons to deliver info about the individual in small chunks.Dkriegls (talk)21:23, 27 May 2012 (UTC)
I couldn't confirm that. Here are some lists I found in articles on notable people that end with no punctuationhere,here,here,here,here,here,here,here,here, andhere. While compiling those lists, I also found some lists that ended in periods, but the only lists I found ending in semicolons are atGarry Kasparov. So perhaps you meant some other kind of "notable people lists".Art LaPella (talk)23:36, 27 May 2012 (UTC)
Sorry, I definitely did not mean they end in semi-colons. I read your first post wrong. I support ending such non-sentence prose without punctuation. Semi-colons should only be used within the prose of a single subject to separate ideas.Dkriegls (talk)04:59, 28 May 2012 (UTC)
I've made a stab at improving it. The actual rule is that your punctuation practices don't change just because you've added list structure, except to introduce a mid-sentence list with a colon a colon. So here's a simple example:
I'm going to the store to buy milk, eggs, and green beans.
I'm going to the store to buy:* milk,* eggs, and* green beans.
Right, and in those cases (when the list isn't a sentence), you still use the same capitalization that you would if there were no list formatting. Here's a list that could be a paragraph just as easily:
Many people are doing things today. I am editing Wikipedia. You are improving Wikipedia. Someone else is reading Wikipedia.
which, with list formatting, becomes this:
Many people are doing things today.
* I am editing Wikipedia.* You are improving Wikipedia.* Someone else is reading Wikipedia.
I don't disagree with you for sentence format lists, nor doWP:LIST#Bulleted lists orWP:LIST#Bulleted and numbered lists. I think the issue brought up here by Art LaPella was for sentence fragment lists, like a list of mayors or historic buildings. Do they need to end with a punctuation? I think no.
(outdent) ? That one, like section "See also" that immediately follows it, is not introduced by any prose at all. This issue should concern thoselists introduced by sentence fragments --which correctly in those cases terminate in colons. --P64 (talk)14:59, 4 June 2012 (UTC)
Chronological lists
In the case of lists of things in chronological order (Presidents of a country, CEOs of a company, World champions in a sport, etc) is it best to list them in normal or reverse chronological order - should the current occupant of the position be at the top or the bottom of the list?Roger (talk)07:05, 5 July 2012 (UTC)
I favor coverage of the "current occupant of the position", if applicable, or the current or latest rendition of the event, in advance of the list of past occupants or renditions, typically in section 1. Exhibit:Bermuda Bowl, where it's strictly section 2, but not really (to be addressed next year).
The complete list should be in chronological order with the current/latest at its foot, which may be strictly redundant in my favored design.
Both for periodic competitions as in the exhibit, and for annual book awards, I usually find in place a nearly raw list or a wikitable comprising winners or winners and/or other contenders such as "shortlists". It's sorted chronologically one way or the other. My approach is don't the rock boat --or don't begin that way. First cover the current/latest rendition adequately.
In many cases, I believe, adequate early coverage of both current and latest --or underway and current, such as US President-elect and President-- will preempt the concern of many editors to put the most important or interesting at the top of the list. That is sometimes, commonly, or almost always the argument for reverse chron order, I suppose.
I just made a change to the requirement for citations for material in lists. However, I'm aware that there has been plenty of discussion here about when these are and are not required, so I wanted to draw some extra attention to it here to make sure I'm not way off base. I'm sure someone here will let me know if it looks good (or bad). Thanks. —Bdb484(talk)18:38, 1 August 2012 (UTC)
That was fast. I've already been reverted.
My understanding ofWP:V is that inline citations are required for any material that has been challenged or that is likely to be challenged. My edit was intended to reflect that this requirement applies also to material lists. I'm not exactly sure whether my interpretation of WP:V is off, my application of it to lists is off, or my wording of that application is off. Or maybe all three.
My concern here is the risk of unintended consequences, weighed against the benefit of stating the obvious. Requiring contentious content to be covered by an inline citation is a firm principle of the project: it is enshrined atWP:V, which is concerned with the content of articles/lists. The Manual of Style on the other hand is concerned with the layout, formatting and structure of articles/lists. Thus, the implication of making that point in the Manual of Style is thatevery entry in a list, contentious or not, requires an inline citation, even if that is not the original intention. I am confident there is not consensus for this, in cases where a general reference covers the listed content. —WFC—18:51, 1 August 2012 (UTC)
If membership in a list is contentious (eg say a list of people or organizations that support LGBT rights), there should be a cited reference for each member. If the membership in the list isn't contentious (list of people from a given country, for example) where the verification of the fact can be found by following the link, its better not to weigh down the list with those references. --MASEM (t)18:58, 1 August 2012 (UTC)
I agree with both of the above points. I don't understand, though, how the proposed change would imply the requirement of a citation for material that is not likely to be challenged when it is explicitly talking about material that is likely to be challenged.
Either way, could this issue be addressed with an equally explicit notice that noncontroversial material in lists does not necessarily require an inline citation? For instance, "The verifiability policy states that material challenged or likely to be challenged must be attributed to a reliable published source using an inline citation; inline citations are not required for material that has not been and is not likely to be challenged." —Bdb484(talk)19:08, 1 August 2012 (UTC)
Well, actually thinking about it, there's another way of sourcing without inlines for contentious inclusions, and that is if the list itself, as a whole, is sourced within a single work (or sourced repeatedly in multiple works), such that one general reference applies to all the elements of the list. Mind you, I'm having a hard time coming up with a possible list example where inclusion is contentious and would be sufficiently notable. (EG: A list of a critic's worst films of all time would certainly be contentious, but why would we have a singular list about one critic's films? On the other hand, the worst films in financial terms would not be a contentious list). There's still some common sense here that requiring inline cites for contentious entries may not always be required. --MASEM (t)19:18, 1 August 2012 (UTC)
I think the concerns above are about how the true statement could be misunderstood and abused, not about whether WP:V applies to lists. (For example, if an editor has trouble understanding that the list items are honestly notWP:LIKELY to be challenged.)
Masem,Hollywood Ten might be what you're looking for.
And now that you mention it, it also seems like it might be good to explicitly mention that possibility in the MOS. Most lists -- to the extent they're cited at all -- seem to use citations for each item, which is admittedly a bit more cluttered.
What about something saying that when material has been or is likely to be challenged, inline citations must be attached to either the entries or to an introduction that covers all of them? —Bdb484(talk)19:47, 1 August 2012 (UTC)
I would just like to comment that if the list item is a link to a Wikipedia article, and that article satisfies WP's notability requirements (multiple independent citations to reliable sources), the list item itself doesn't really need citations because they are present in the underlying article.Dlabtot (talk)01:53, 2 August 2012 (UTC)
That makes a few assumptions that often don't apply, but is incorrect anyway, I think. If the material is contentious or likely to be contested,WP:V requires the addition of an inline citation. —Bdb484(talk)11:46, 2 August 2012 (UTC)
That's in little doubt (from me at least). But if WP:V requires clarification, the most effective way of doing so is WP:V. —WFC—14:32, 2 August 2012 (UTC)
I was reading over the page trying to look for proper formatting of a character list (e.g. video game characters) and I couldn't find a proper format. My question is what would be the proper way to format a list of characters? I've been working on a character list page and what I have done is a bulleted list, bolded the name of the character, put an endash, and then a summary of the character. Here's an example:
Kratos – The protagonist of theGod of War series. The character is a power-hungry Spartan who, to save his life, is eventually forced to serve theOlympian godAres. During one murderous rampage, Kratos accidentally kills his wife and child. Renouncing Ares and becoming a tormented soul, Kratos serves the gods for ten years (eventually becoming the God of War and revealed to be ademigod) until betrayed by his fatherZeus. A convuluted series of attempts to free himself from the influence of the gods (and eventually theTitans) and exact vengeance follow, culminating with a final confrontation with Zeus. The character is voiced byTerrence C. Carson, withAntony Del Rio voicing the character as a child inGod of War: Ghost of Sparta.
Would this be considered acceptable for a character list? I have seen other character pages where they have sub-sections for the characters. The problem with doing that with the page I've been editing is that there are 60+ characters.JDC808 (talk)04:54, 6 August 2012 (UTC)
The section "Comma-separated lists" doesn't make any sense to me. 1) It does not actually show the rendered output of the code example; instead, it shows a rendering of completely different code. 2) I don't see how such a list (either one: the code example or the shown rendering) could possibly be useful in an infobox. 3) It refers to two examples; I see only one. 4) It misspells "info box". I suggest to remove the whole section. --Michael Bednarek (talk)02:46, 30 December 2012 (UTC)
Suggestion for adding bit to clear things up about list
There are a rather large number of lists on Wikipedia that go to AFD and usually get kept. It would save a lot of time if things were clearer here. Can we eliminate the part about meeting the "notability guidelines" at the top? Or create a notability guideline for List? Or simply state "if the list includes multiple items that have their own Wikipedia article, and these are related enough to be listed together, then the list article is fine". I believe there was once something about a list aiding in navigation, then it was fine. List articles such asList of lists of lists are useful, but would you find a single reliable source to prove they have a reason to be here? There are hordes more list articles like that. Character list usually are saved, if at least a few characters have their own articles. It does of course depend on whatever small number of people randomly notice and show up at the AFD to comment, sometimes you just having people who hate all fictional articles and want them deleted, but most times the list is saved.DreamFocus15:59, 13 January 2013 (UTC)
The problem here is that based on when we tried to defineWP:LISTN at WP:N, there'sso many different types of lists out there that no single piece of advice can work for them all in terms of its worthy for inclusion, whether that's based on notability, usefulness, etc. LISTN is purposely written to highlight the only documentable case where we're sure lists are kept (when the list itself is shown notable via the GNG), but that doesn't mean no other list is inappropriate, and in fact we point back to LISTPURP to show that several types of lists are kept often. I don't think removing the advice about notability is right, as we do want editors to consider notability of the list topic particularly if it is informational, but we can't enforce rules on what is notable or not when it comes to lists. --MASEM (t)16:09, 13 January 2013 (UTC)
You can't say that "notability guidelines apply", and then say in the next paragraph "There is no present consensus for how to assess the notability ". That doesn't make any sense at all. People arguing to delete a list simply because they don't see any reliable sources specifically mentioning the item, is just a constant thing. As long as it says they have to meet the notability guidelines, we have a problem, unless there is a subject specific guideline for list. Or just say: "A list is notable if there are reliable sources for its content, such asCategory:International reactions. The list is also notable if the items are related and there are at least three of them with their own Wikipedia articles. Wouldn't that include all notable list? Can you think of one that wouldn't fall into one of those two things?DreamFocus16:22, 13 January 2013 (UTC)
I think it's more the case that notability guidelines do apply, but how they are supposed to be worked into a list article is in question. For example, I fully support the idea of things like lists of characters as spinouts of the main work they are part of (as long as article size issue is a problem). Here, notability should be show at the work level - not the character level - and thus outside of re-establishing what the work is on the list, we don't need to show any GNG-type notability there, since we're assuming its established in the work article. This implies that we should only have lists of characters for notable works, and perhaps this also sets a level of detail that's appropriate for these - eg we can justify the half-dozen Simpsons character lists due to the length and popularity of the show , but we wouldn't be able to support the same for a show with all of 13 episodes that was cancelled mid-season. (Note that I know others support this view, but there's several that don't so we couldn't document that advice). So what this leaves is that notability should be considered - whether in the list, the parent article of the list, or the elements of the list - but how to access it for purposes of AFD is extremely fuzzy and impossible to document. If your list shows no aspect anywhere of notability, it will likely be deleted, but that's the best piece of consistent advice we can give. --MASEM (t)16:31, 13 January 2013 (UTC)
We need to have an example that says you can have list articles for characters/villains for notable shows then. An AFD just closed where more people said keep than delete, but it was deleted anyway, despite being a character list for a massively popular show that has lasted for many years, made billions of dollars in merchandising, and spawned various other notable shows from it.[13] The closing rational was that all articles, even list, must prove they meet the notability guidelines on their own. So a rather massive number of list articles like this will now be nominated, and eliminated.DreamFocus12:13, 15 January 2013 (UTC)
I'm working on a subject specific guideline for List articles atUser:Dream Focus/Wikipedia:Notability (lists). Please join in a discussion on the talk page about it, what should be added, removed, or changed, and also a list of any list article you believe belongs in Wikipedia but doesn't pass the GNG right now.DreamFocus12:38, 15 January 2013 (UTC)
Trust me, you are wasting your time trying to get anything more exact. Wetried to suggest similar rules in considering the wording for LISTN but simply couldn't get consensus to support anything. The AFD you mentioned above is an example of where the pattern where characters articles are usually kept - and indicative of why we couldn't get consistence advice. --MASEM (t)14:38, 15 January 2013 (UTC)
And "Every item listed has its own reference to prove it belongs there, or the information is not challenged." will not fly. That's just showing WP:V, which of course is necessary, but nothing about being indiscriminate; it's a necessary but not sufficient condition for a stand-alone list. I could use this to make a list of businesses in a certain city (using a yellow pages to do so), or a list of people living on my street. Notability is about keeping WP free of indiscriminate information, hence why lists should be built with that consideration even if we can't exactly define how to show it. --MASEM (t)14:51, 15 January 2013 (UTC)
Non-numbered ordered lists and other html quirks
I think that the ability to create non-numbered ordered lists should be mentioned, since it's not trivial to retrieve how to do so if an editor isn't an experienced with html. I mean,
I would like to bring up a topic of discussion concerning some work that I have been doing recently, and the issue I ran across. All throughout Wikipedia, there are several different looks forindexes of articles. I have looked at a few of these lists; some have every single article listed on one "index" article, and others have the index split up into several subarticles based on what letter, number, or symbol at the start of the name of the articles in that index. The fact that there is no streamlinedmanual of style seems to be a bit of an issue when trying to determine how to write these articles (and in the case ofIndex of mathematics articles, what namespace to place the articles). I propose that there can be a consensus reached about creating manual of style guidelines specifically for this type of list. At this point, I have found some other manual of styles that could assist in a consensus for this decision:WP:ARTICLESIZE,WP:SPLITLIST. Besides mentioning the existence of indexes of articles in this manual of style, there is very little information about this topic anywhere in the Wikipedia namespace.Steel1943 (talk)20:42, 7 February 2013 (UTC)
An index is an alphabetical listing of a certain topic, whereas a list of lists is exactly that: a list of other lists. These two topics are not one in the same. I'm referring specifically to the articles that are usually found inCategory:Indexes of topics, or can be properly tagged in that category.Steel1943 (talk)02:05, 8 February 2013 (UTC)
I'm not too clear on how this discussion has went off topic and became a discussion aboutMusdan77's question, which does not relate at all to the question I am asking. Would anyone have input on the topic I brought up about possibly needing amanual of style for index-style list articles?Steel1943 (talk)07:47, 8 February 2013 (UTC)
Looking atList of current heads of state and government, I see that some entries on the list are in small font and some in regular font. No explanation is provided as to why this is so. Looking at the infoboxes at the articles of the relevant nations, all names and titles are in the regular size there, so this seems to be some local peculiarity of the list. I have asked on the talk page for some short explanation so that we can make it clear to readers why there is a distinction, rather than letting them guess, but so far no comprehensible response.
I can find no formatting help in the various relevant sections of the MoS, but I feel that if there is a reason beyond the personal taste of one or two editors, then it should be made plain as a guide for the reader and as a help to new contributors to the list, as there are often people who update the list after elections or other changes and may be unaware of whatever local methodology applies. --Pete (talk)20:32, 10 May 2013 (UTC)
There are a lot of comparison tables in Wikipedia. Just forCategory:Software_comparisons, there are about 200 pages, and that's not counting sub-categories. For every comparison page, wikipedians need to painstakingly edit huge tables with multiple components, and very often duplicate information that shows up in the individual page anyways. This seems like an awful waste of time.
Is there a way to collect that data from the individual pages instead of having to copy-paste it? This would reduce data duplication and make the table much easier to manage in a larger scale. --TheAnarcat (talk)18:01, 18 July 2013 (UTC)
You can transclude pages into others (and use tags like noinclude or include-only to prevent or add stuff). TV shows with episode guides have detailed templates that do this - brief table entries for full episode lists and longer summaries for season lists.
The caution here is that all the data from the original entries must be in the same format for the comparison, which may or may not work. It's possible, but doubtful a uniform solution for all. --MASEM (t)18:34, 18 July 2013 (UTC)
I would assume that same rules or guidelines about selection criteria for standalone lists apply toWikipedia:Manual of Style/Embedded lists. I am surprised that article is silent on the issue. Occasionally I've run across embedded lists where the selection criteria need clarification. For example:
If these were standalone lists we could hatnote the articles using{{List missing criteria}} while editors work on a better selection criteria. For now, I did a workaround using{{citation needed}} with an embedded comment.
As a proposal - I'd like to move the selection criteria language from the standalone list article into this article. WP:LSC, WP:CSC, and other shortcuts would also be shifted along with rewording Template:List missing criteria. --Marc Kupper|talk19:59, 18 August 2013 (UTC)
I think I agree. If I remember correctly, the issue arises with embedded lists in that an article's subject is clear, but the editors add catch-all embedded list about that subject. I don't agree with these catch-alls and some of the them are explicitly discouraged (e.g. Trivia sections), but they are there and that is the resistance I anticipate from this move. --Dkriegls(talk to me!)17:00, 19 August 2013 (UTC)
Space after bullet point?
An editor recently edited (without edit summary) a bulleted list (inSharp (surname) to systematically remove spaces between the bullet point (asterisk) and the text of the entry. I have replaced them because I find them easier on the eye for the editor, and because I cannot see justification for their removal.
I cannot find chapter and verse for the presence, or absence, of this space, although the examples atWP:BULLET all include them. Is there any documentation about this? Is the space optional, down to the discretion of the editor? (In which case he was wrong to remove them as the previous editors had chosen to use them). I've replaced the spaces but would like to be able to cite a policy somewhere. Have I missed anything? Or could we add it explicitly to this MOS?PamD07:50, 4 June 2012 (UTC)
I don't know about policy and suppose that it isn't generally needed in such a case. The editor revised with a constructive purpose. Did you try to undo the first edit and restore the constructive component (16 bytes)? I believe the first part of the auto-generated revert summary may be helpful in supporting your own point (which you abbreviated too much) in the edit summary without benefit of chapter and verse.
Presuming no past experience with this editor, I would have hoped to say, essentially,Undo[boilerplate including ID number] to restore useful whitespace (manually re-do the welcome correction). --P64 (talk)15:08, 4 June 2012 (UTC)
This editor habitually removes spaces from templates and infoboxes, although he has been asked not to do so. I would like to see a policy I can quote in asking him not to remove spaces from bulleted lists. Any thoughts?PamD09:20, 6 June 2012 (UTC)
Thanks, but no, I think that is about how to display commands in examples, rather than what should be in the actual WP articles. Any other ideas? (Also, anywhere which states that it is not good to remove the space between the "|" and the following field, in a template.)PamD06:39, 10 June 2012 (UTC)
This is not aWP:Articles question you are asking, since the code argument for bullets with/with out spaces produces no difference in the actual article. You are asking a code question. And as General guidelines for code go,Wikipedia:Manual of Style/Command-line examples is the place to look. The examples you may be referring to were only for how to use italics in-code; there were no examples provided for the spacing guidelines because it is applied to all arguments. --Dkriegls(talk to me!)06:14, 12 June 2012 (UTC)
In some templates, or many or the norm?, a space for editorial convenience must precede rather than follow the pipe --" |" rather than "| "-- because trailing spaces are ignored but leading spaces are utilized, I suppose.
To me the consensus seems to be to have a space after the bullet point/number in lists. Could the lists MOS documentation be updated to reflect this (if it is indeed the case)Jamesmcmahon0 (talk)10:15, 26 August 2013 (UTC)
User:Jamesmcmahon0 has now, despiteWP:BRD,re-inserted the phrase "Style note: Always leave a single space between the bullet point, number, letter etc and the list item." I reverted his earlier edit which had inserted it. The editor claims there's consensus here in his or her favour. I can see no such consensus. User P64 is silent on the matter, Dkriegls points to Wikipedia's automatic formatting (which uses a space) and then quotes an unrelated other guideline; they don't agree to a compulsory space. The orginal questioner, PamD, seems in favour of the separating space, as is Jamesmcmahon0. That doesn't look like the level of consensus that would justify inserting a mandate for such spaces into the guideline. In my opinion, they should be entirely optional and no edits ought to be performed simply to add or remove them. I suggestto remove the above quoted phrase from the guideline. --Michael Bednarek (talk)14:02, 15 September 2013 (UTC)
This mandate would be a time-waster. My fingers are pretty good at putting asterisks at the beginning of lines when I find a list that an earlier editor did not bother to format. If I'm using wikEd on an article, it will create bulleted lists with the spaces, but I'm not always using wikEd. I may be using a plain editing session so that my own scripts can be run, or I may be using AutoWikiBrowser when I run across an unformatted list. It's going to be more of a pain to add spaces along with the asterisks, and I sure don't want a nasty note on my talk page about not putting spaces in an article that I have beautified. All over something that is not visible on the rendered page? I have a lot of misspellings and mispunctuation on my plate. I don't need this. If I am fixing a list of five items, and one or two don't have the space, I will make them uniform, but I'm not going to work over all the lists on a page just to add spaces.Christhe spelleryack16:16, 15 September 2013 (UTC)
A few points:
It should not be "mandated", but it should be explicitly recommended. Ie. Nobody should go through articles with a bot/AWBpurely to add spaces, but itis a good additional thing for editors/bots/etc to standardize towards.
One of the tasks thatUser:Addbot does is "Fix white space", which includes removing trailing-spaces, and adding a single space after bulletpoints in list items, egthis edit.
I agree with the proposed addition, but I suggest it be placed in the sectionWikipedia:Manual of Style/Lists#Bulleted and numbered lists instead, and worded as "* List items should be preceded with a space, for visual clarity in the wikisource editor. See all the examples above, in this styleguide." or something like that.
Firstly, I would like to apologise for making the edit, in my defense I did think consensus had been achieved and I gave it another 20 days to see if there were any objections to that assessment. I agree with the above comments that I do not think it should be a mandated change but since bots and AWB are capable of doing it whilst performing other edits it should be added to the MOSsomewhere to clarify the matter.Jamesmcmahon0 (talk)09:14, 16 September 2013 (UTC)
Should lists about people require the linking biography page to mention the subject's relationship to the list?
This issue is being debated for a single articlehere. The issue resolves around violating BLP, that if a biography doesn't mention a scientist's relationship to a very political issue, why should a list label them as such. Counter points seem to include issues of using Wikipedia biographies as a primary reference for BLP violation. I think this issue should be brought to the greater Wikipedia community, since all politically charged lists of people likely face similar issues.Dkriegls (talk)21:47, 21 January 2012 (UTC)
Ithink I agree with you, if you're suggesting that we make clearer that in lists which include people, BLP principles apply. —WFC—07:01, 22 January 2012 (UTC)
Kinda; essentially should BLP be fact checked against a person's biography page. If biography editors have decided this is not a notable position of said person, should it be a violation of BLP to add them to a list that suggests it is a notable position?Dkriegls (talk)21:27, 22 January 2012 (UTC)
It depends: Is this something that the editors have properly discussed and made a conscious decision about, or just another case of the biography beingWP:NOTDONE or even suffering from POV pushing? If the latter, then you should ignore the contents of the biography. If the former, then those editors' reasons should be made known to the editors at the list. Fundamentally, it's the job of the people at the list itself to decide what theircriteria for including or excluding people are, not the job of the people at the biography.WhatamIdoing (talk)01:12, 23 January 2012 (UTC)
Shouldn't any issue of BLP be resolved at the biography page, not on some list? This is obviously most relevant to contentious issues where inclusion of said person on a list declares them in allegiance with a contentious issue. Lists are poor places to use prose to discuss the minutia of a person's position on the issue.Dkriegls (talk)04:35, 23 January 2012 (UTC)
No, like any other content dispute, any BLP issue should be resolved at the actual page where the BLP issue exists.
I dont agree that there must be a mention of X in John Doe's article for John Doe to be included in List of X , although theredoes need to be sources. While X may play a minimal role in understanding John Doe and his importance, the fact that John Doe is X may be of great importance to X. Wikipedia is not paper and so we have list articles of very trivial things. --TRPoDaka The Red Pen of Doom04:32, 9 February 2014 (UTC)
I guess we're revisiting this two years later ;) I do agree that in general a trivial X doesn't need to be mentioned in John Doe's biography to make a list about category x. Example: Celebrity John Doe is a yearly pie eating judge in the small Maine town where he keeps a summer home. Not notable enough for his biography, but notWP:Undue weight to list him as one of the town's judges (given that the event is notable about the town. However, what I was originally asking was if there is a PLB issue, shouldn't that be resolved at the Biography page where editors are more familiar with the subject?Dkriegls(talk to me!)12:40, 9 February 2014 (UTC)
For the particular list you started this discussion about they already do check the bio article talks about their relationship to the subject. I'm not too keen on your use of the word notable though, yes it should be mentioned in a reliable source and have enough weight to be put in a bio - but the person may be notable for something else and would not have been put in Wikipedia if their only contribution had been on the topic of the list. E.g. Prince Charles talks to plants and if people who talked to plants was a notable topic he would definitely be on it, but he isn't notable because he talks to plants, he is notable because he is a prince.Dmcq (talk)13:04, 9 February 2014 (UTC)
Lets say we find a source that quotes the prince from 1992 as saying "When I talk to my plants I use an American accent". Editors who want to advance the idea that plant talking is normal and even princes do it, will be happy to use that source and add him to their list of people who talk to plants. But on his biography page, it is such a minor quote and not a position he actively endorses, that it is likely not to get mentioned there. Now, there might be a BLP and WP:Undue weight issue of adding the Prince of Wales' as an endorser of that position. Or more realistically, lets say he just used homeopathy but wasn't such a big endorser of it. His use probably wouldn't be noted in his biography, but people looking to highlight celebrity use of homeopathy might be keen to add him to their list given that his use is well cited. This is the type of thing I come across on lists likeList of African-American Republicans or Lists of important people endorsing so and so. I do understand your position, but just think that if a list is going to make a claim about someone having a politicized or controversial position, it should be a position significant enough for inclusion on the biography page were editors more familiar with the person can asses BLP issues with the claim.Dkriegls(talk to me!)06:11, 12 February 2014 (UTC)
Or, I guess just informing the talkpage of said biography that a BLP discussion is happening about the subject on a list page is probably the best way to go. I just find it hard for Wikipedia to claim a scientist as "anti" climate change unless they are full-on endorsing that position in a very public way that would be included in their biography. Most scientists I know always have nuanced positions, making it hard to say they belong on a list about endorsing a position because they wrote a paper on it three years ago.Dkriegls(talk to me!)06:17, 12 February 2014 (UTC)
Alphabetical order?
I've noticed that there is a discrepancy in the way that "St." is alphabetized in the lists of U.S. counties; some put it where "Saint" would go, some put it in the St-s. I've also noticed that the Wikipedia articles oncollation andalphabetical order name no strict convention, and that the manual of style has no specific guidelines on the preferred alphabetical standard for Wikipedia. Should we adopt some sort of consistent standard, or just let each article be different?Someone the Person (talk)16:23, 25 April 2014 (UTC)
If it's consistent within each article it shouldn't pose a particular problem. The most obvious way to handle it is to not abbreviate in the first place.Gigs (talk)18:05, 25 April 2014 (UTC)
I remember looking hard for such instructions when I started at Wikipedia. I just foundHelp:Alphabetical order which describes automated alphabetization of capital letters before from lower case letters. For instance inthis exampleSchreiber's Green Lizard is sorted beforeSchreiber's bat. That's certainly different from how I've alphabetized. I think the encyclopedia would benefit from a standard way of alphabetizing. If you're up for proposing a system, I'd be interested in seeing it. I did putthis together for my own use when I was spending a lot of time on surname pages.SchreiberBiketalk22:47, 25 April 2014 (UTC)
I'm actually surprised there isn't a standard. Perhaps this question should be asked over at the manual of style main page, to see if any editors over there recall any such previous efforts to standardize and what the reason for not doing so was. If there hasn't been any previous effort, I think it makes for a respectable cause.Dkriegls(talk to me!)04:59, 27 April 2014 (UTC)
The archives are searchable atWT:MOS. Check for discussion in theWT:CFD talk page too, perhaps? Or where ever else categorization is being figured out. And, yes, this should be covered somewhere, and yes, we should advocate that the search key be for the non-abbreviated version (Saint). Other standard cases are to treat characters with diacritics as if without for search purposes (e.g. search key for a bio of "Elías Blöm" should be "Blom, Elias"), and Mac/Mc/M' names are done as if all "Mac", etc. I'm sure there are some external publications somewhere that outline how to do all of this sanely. We should find, review and synthesize them into a standard here. This become more important the larger our categories get, especially when full of things like human surnames and geographical names based on Saints and such, where spelling is hard to predict. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 12:42, 27 April 2014 (UTC)
Capitals are sorted before lower case because that's the order they are in the ASCII table. Of course, that's a little skewed here because mediawiki doesn't support case sensitive first letters by default, probably partially for that exact reason.Gigs (talk)16:29, 28 April 2014 (UTC)
Templates for lists in tables
My addition of the words "commas may be used, but{{Flatlist}} is preferred, for improved accessibility:" hasbeen reverted, with an edit summary of "no consensus for replacing comma lists with flatlists". Aside fromWP:DNRNC applying, there is widespread consensus for the use of that template; its in most infoboxes' documentation and used on hundreds of thousands of articles. The template emits proper HTML list, in accordance with HTML standards, improves accessibility, and provides betterdata granularity for parsers.User:RexxS gave agood, detailed explanation. The wording should be restored.Andy Mabbett (Pigsonthewing);Talk to Andy;Andy's edits19:31, 3 June 2013 (UTC)
There are two reasons to prefer{{Flatlist}} or{{Hlist}} to commas:
Marking up a list as such helps natural text recognition programs to correctly identify the structure. This is most useful inside infoboxes and summary tables, which are most likely to be targeted by those programs.
Using list markup can be a help to screen readers which are capable of announcing the number of items in a list. Sighted readers can quickly spot the number of items in a list and it is easy for us to look back and count them if we wish. Visually impaired readers may find that rather more difficult and the opportunity to glean extra information about a list from its markup is a worthwhile improvement to their experience of using Wikipedia. Clearly, if the list only contains two or three items, there is no great advantage for screen readers in marking that up as a list.
However, we are all accustomed to having list items separated by commas in running prose - so much so that nobody would seriously consider replacing such lists in the normal body of an article. In this case, it seems sensible to alert editors to the advantages of{{Flatlist}} and{{Hlist}}. It would certainly not be unreasonable to describe them as "preferred" wherever a summary is used, but not in running prose. --RexxS (talk)15:39, 4 June 2013 (UTC)
Has hcomma made any headway? I've had flatlists removed that I'd added, and one argument was that the dots are "ugly" (though personally I'd prefer the dots).Curly Turkey ⚞¡gobble!⚟01:29, 20 May 2014 (UTC)
Conflicting instructions
From MOS talk:
WP:BULLETLIST says "As a matter of style, list items shouldstart with a capital letter. Theyshould not have a punctuation mark such as a period, a comma or a semi-colonat the end, except if a list item is one or more full sentences, in which case there is a period at the end." ButMOS:#Bulleted and numbered lists says "When the elements are sentence fragments ... [they] are formatted consistently in either sentence caseor lower case. Each element shouldend with a semicolon, with aperiod instead for the last element. Alternatively (especially when the elements are short), no final punctuation is used at all." (emphasis added)
I compromised: consistent capitalization, no final punctuation unless required by items themselves. This reflects what we actually do, and I've not seen any objection to this format. I'm not claiming consensus, simply resolving the conflict until (or if) there is further discussion. —kwami (talk)23:18, 21 October 2012 (UTC)
Years later, this is not fixed. We still have "When the elements are sentence fragments, the list is typically introduced by a lead fragment ending with a colon. When these elements are titles of works, they retain the original capitalization of the titles. Other elements are formatted consistently in either sentence case or lower case.Each element should end with a semicolon or comma (whichever you would use if the items were not formatted as a list), with a period instead for the last element.Alternatively (especially when the elements are short), no final punctuation is used at all" (my emphasis). Earlier in the page, "They should not have final punctuation unless they consist of complete sentences". One instruction says not to use final punctuation when elements are sentence fragments, and one instruction says to use a semicolon or comma, except if you decide not to, whatever that means. Yipes, I hardly ever see lists with semicolons or commas. Periods on every element, yes, I see those, but I remove them. The same semicolon blather is found near the end ofWP:EMBED.Christhe spelleryack02:05, 14 July 2014 (UTC)
My usual practice is:
for sentences in a list to use sentence case and end in a period
for fragments in a list to use no closing punctuation
for fragments in a list to start with a capital letter or not depending on how they are being used
Eek. What were the odds?Chris the speller, here it is, almost exactly 24 hours after you made the change, and I just happened onto the scene, looking for the "official word" on the use of semicolons in lists of sentence fragments, and I encountered silence. Making matters worse, Idid encounter theprevious bullet, which looks like this:
Use numbers rather than bullets only if:
a need to refer to the elements by number may arise;
the sequence of the items is critical; or
the numbering has some independent meaning, for example in a listing of musical tracks.
Actually, that is a lie – the "or" was at the beginning of thefinal bullet, but I doubt anyone would supportthat as being correct. I saw that silence as a deficiency in the MOS, especially where the MOS itself so clearly used the semicolon. Without any knowledge of the earlier conflict, I made the change listed below. But first,SchreiberBike, Iagree with your assessment of the previous guideline as "blather", and I also agree that commas should never be used.However, Idisagree that semicolons should be altogether eliminated. I was always taught that the semicolon should be used in lists of sentence fragments, ordependent clauses, when introduced by a lead fragment. In other words, the bulleted list shown above is correct. I haven't looked, but I daresay that other style guides would agree. Without further ado, here is how I modified the guideline:
Use the same grammatical form for all elements in a list, and do not mix sentences and sentence fragments as elements.
When the elements are complete sentences, each one is formatted with sentence case (i.e. the initial letter is capitalized) and a final period.
When the elements are sentence fragments, the list is typically introduced by a lead fragment ending with a colon. Each element fragment is formatted in lower case ending with a semicolon – except for the last one, which ends in a final period. Each element fragment, when coupled in turn with the lead fragment, should form a syntactically-correct sentence if it were to stand on its own.
When the elements are titles of works, they retain the original capitalization of the titles, without final punctuation.
Other elements are formatted consistently in either sentence case or lower case. No final punctuation is used.
I thought there were twomajor styles of bulleted lists: those with whole sentences, and those with sentence fragments. The second type could be titles of works or some other sentence fragments. So there are three styles in total: sentences, fragments that are titles of works, and fragments that are not titles. Your modified guideline seems to have four styles ("Other elements" being the fourth), so now I'm confused. Before we go further, note that disambiguation pages have a style that fits with fragments that are not titles (well, mostly not titles).WP:DABSTYLE says "Entries are sentence fragments; do not end them with periods or other punctuation." Having done a lot of work with dab pages, now bulleted lists with ending punctuation, when not full sentences, look very strange to me. Don't you agree that the vast majority of the bulleted lists of sentence fragments on WP currently are without final punctuation? It might be time to have examples of properly formatted lists of all 3 types, or all 4 types.Christhe spelleryack02:51, 17 July 2014 (UTC)
@Grolltech: Oh, now I think I figured it out. You may be equating "sentence fragment" with "dependent clause", while I think of "sentence fragment" as one or more words, but less than a full sentence. Let's get that settled first.Christhe spelleryack03:00, 17 July 2014 (UTC)
I am no grammar expert; nonetheless I'll share my thoughts. I think the style described in green above works well for lists in running text, but to my eye the use of bullets ( • ) in a columnar list makes ending punctuation for each line unnecessary. I think the use of bullets also means that it is unnecessary to add the final conjunction (or/and) and the period. In restricted spaces like infoboxes, the same would apply to unbulleted columnar lists.SchreiberBiketalk03:42, 17 July 2014 (UTC)
Musdan77, I'd like to invite you to this discussion, in light of your revert, which I understand, but please take a moment to review this thread.]
SchreiberBike, I'm no grammar expert either, but I agree with the premise that you wouldnot write:
For breakfast, I had:
eggs;
ham; and
coffee.
That would be foolish, and I think the original paragraph attempted to cover that scenario by saying,"Alternatively (especially when the elements are short), no final punctuation is used at all." Ido know enough about grammar to know that the following sentence – which is achieved by simply removing the bullets –is gramatically correct:
"Use numbers rather than bullets only if: a need to refer to the elements by number may arise; the sequence of the items is critical; or the numbering has some independent meaning, for example in a listing of musical tracks"
That fits with the original paragraph's clumsily-worded,"Each element should end with a semicolon or comma (whichever you would use if the items were not formatted as a list), with a period instead for the last element."
So,Chris the speller, I think that you are correct as to the two "major" types (whole sentences and sentence fragments), but I think there arethree types of "fragment" elements:
longer sentence clauses that are dependent on an introductory or "lead fragment";
titles of works; and
everything else.
For another point of view, Section 6.125 of theChicago Manual of Style – self-proclaimed as "one of the most widely used and respected style guides in the United States" – says,
"In a numbered vertical list that completes a sentence begun in an introductory element and that consist of phrases or sentences with internal punctuation, semicolon may be used between the items, and a period should follow the final item. [...] If bullets were used instead of numbers ... the punctuation remain the same."
Interestingly, CMOS wouldnot have us place a colon after the lead fragment. The conjunction on the penultimate line is also optional, and is trending out of favor. —Grollτech(talk)01:57, 18 July 2014 (UTC)
For the record, I'm in basic agreement with all those who say that there are two (or 3) types. So, let's make sure that the MOS clearly shows the use for each one. --Musdan77 (talk)02:32, 18 July 2014 (UTC)
I would like some feedback and guidance about the placement and style of "Key/symbol" sections in list articles. I think I have complained about them in the past, but this has re-appeared due toa current FLC. Looking through lots of other sportingfeatured lists, I see that the key at the top of the list is very common. Most are only a few lines, so easier to ignore, and some use smaller font, but I see it as a giant roadblock before you get to the actual data. I'd like to move it to the side or end, do it via popups, notes or links or something clever (these are meant to be our best possible lists, remember). Here is the example in the current FLC:
Tests
Johnson fielding during a tour match against Northamptonshire during the2009 Ashes series.
I'm not sure of how to best provide the key, but I am adamant, that despite a strong resistance of "it's how we've always done it" and "it's been accepted in 100s of lists", (Discussed at the FLC linked above,WT:CRIC and by@NickGibson3900: and@The Rambling Man:) it isn't the best way to do it. Has anyone seen a better way.
Should there be some guidance in the MOS as to put the key at the beginning, side or end of the article, or replace it with something cleverer, like notes, links, popups or whatever is acceptable from a visual, usability and accessibility point of view. I was surprised to not be about to find any mention of the use of a key in any MOS page.The-Pope (talk)12:33, 25 September 2014 (UTC)
Whatever is discussed or decided, please remember that featured lists comply withWP:ACCESS, so small fonts, pop-ups etc aren't going to be used there. Also, remember that a large portion of Wikipedia readers now use mobile devices, so having the key section on its own may actually be a good thing. Thanks.The Rambling Man (talk)12:35, 25 September 2014 (UTC)
The key as-is doesn't inspire any similar motivation for change in me. I'd be interested to compare it to any alternative layouts, but none have been proposed. Seems like a working layout for me, but I'm always up to suggestions. Though, I will say I think I'm against end of page keys.Dkriegls(talk to me!)09:17, 7 November 2014 (UTC)
Deceased
I'm looking at a list article where deceased is indicated by formatting the name in italics. This violates emphasis and accessibility guidelines. What is the best way to indicate deceased here? --Gadget850talk20:47, 16 October 2014 (UTC)
† with date is often death, whereas asterisk* with date is birth. In physics, the same symbols are used mathematically for annihilation and creation operators.SBHarris04:39, 23 December 2014 (UTC)
Lists of people - notability for each subject?
I've tried reading archived discussions about redlinks in lists and notability requirements for list items, but I am still at a loss for how it applies to lists of real people. I have seen many "lists of" for musicians, groups, and singers from certain genres or geographic locales. Of those I've examined, they include almost entirely subjects which are notable, i.e. have or may soon have articles on Wikipedia. Additionally, they include either just each subject's name, or perhaps include active years and/or a short explanation of who they are. The following series of lists (List of South Korean idol groups (2010s),List of South Korean idol groups (2000s),List of South Korean idol groups (1990s)) attempts to include ALL "idol groups" that have ever existed within South Korea, including those for which notability does not and will not likely ever exist. The list also includes an extraordinary amount of extra information on each subject, all of which is already included in the notable subjects' articles. We've attempted to have discussions about these lists, but editors seem to be divided into two camps: the "keep everything because kpop fans like it" and "make these lists like other wikipedia lists" camps. I think it's hard for us to see these lists in the wider scope of Wikipedia because, like any fandom, kpop fans tend to be insular and very passionate. I've tried to do my research, but I'd really like other eyes to look at these lists and give some guidance about the appropriateness of their length and inclusiveness. *note: I know sourcing is an issue at the moment, so no need to bring that up right now. Thank you - I just want to get better ideas of Wikipedia standards so some of these arguments can stop. Actually, the list of possibly-overly-inclusive lists is an issue for many, many kpop articles, but I'll start with just this set of lists. :)Shinyang-i (talk) 04:28, 23 December 2014 (UTC)edit: Sorry if I posted this at the wrong place. I have also posted it now atWikiProject Lists.Shinyang-i (talk)04:55, 23 December 2014 (UTC)
Space after the asterisk in an item of a bulleted embedded list?
I seem to remember seeing instructions to have a space after the asterisk in an item of a bulleted embedded list. I can't find any mention of it now. Beyond making the list prettier when in edit mode, is this still a good idea, or was there a good reason to remove such instructions?Christhe spelleryack00:44, 19 October 2015 (UTC)
It might be in the Manual of Style talking about bullets somewhere. I know I prefer it and still add them; but I do know it was removed from the auto generated content. Not sure why or who's responsible. --Dkriegls(talk to me!)08:02, 27 October 2015 (UTC)
Can we include the meta-info "We have an article on this" (beyond just the bluelink) and if so how
Looking atList of statues of Queen Victoria... There are plenty of bluelinks, for the towns and even neighborhoods in which the statues are located, which IMO is fine... But for some (not most) entries there is also an article... which is probably of much more importance to the reader. My questions are:
Is it proper to communicate to the reader the meta-information "We have an article on this entity"
If so, how is this done?
What I've done placed the link to the articles (when there is one) in bolded italics. However, I haven't specified that this means anything in particular -- leaving the reader to maybe figure it or (or maybe not). We couldremove the bluelinks thatdon't link to a statue article (that is, the bluelinks to the town where it is and so forth), leaving the remaining bluelinks much more clearly pointing to the statue articles. The cost is it leaves the reader who is like "Oh, it's in Lancaster, where's that and what's it like?" with no link to follow.
Another way to go would to have a key that says something like "bolded italics = that's a link to an article on the entity" or even color the box and have a key at the top saying "This color means we have an article on this entity". I've never seen this and I'm skeptical if it's a good idea. Any thoughts?Herostratus (talk)14:09, 8 February 2015 (UTC)
Sorry for just getting to this, but you probably want to take this up withWikipedia:Manual of Style/Text formatting because your use of italics and bold violate Wikipedia formatting rules (see:MOS:NOITALIC). I will likely clean this up myself on the list. I would suggest using list structure to communicate your desired outcome. One column for "Location" and another for "Statue" or "Title" or something. That new column then would only have blue links for statues that have Wikipedia articles specific to the article. If you need me to create the new column, feel free to ask. Otherwise I will leave it to you and only do the font emphasis clean up --Dkriegls(talk to me!)07:55, 27 October 2015 (UTC)
There is only one mention of pictures in lists, and before that it doesn't discuss their relevance to a list articles, or lack thereof. Pictures seems counter intuitive to what lists are trying to accomplish. What is the consensus?Leitmotiv (talk)15:24, 15 September 2015 (UTC)
Editing consensus? Editing consensus is for inclusion. I'm don't know of any other consensus on this subject. I'm also not really sure what you mean by "counter intuitive". How so? I think including pictures in theList of people from Park Ridge, Illinois seems very intutive and serves what we are trying to accomplish with this list by showing pictures of the people on this list. --Dkriegls(talk to me!)07:43, 27 October 2015 (UTC)
On theList of caves page, there are basically floating pictures to the right of the list. They feel disconnected from whatever is happening on the left side of the page. As for "counter-intuitive", I meant that a list article is meant to be a bare bones list, right? You're not trying to inform the reader more about any given listing if it doesn't help with navigating the list. Why would you want to flesh out a list article by adding photos? Isn't that what a main article is for?Leitmotiv (talk)21:04, 8 November 2015 (UTC)
No, list pages are not meant to be bare bones. That would make them indistinguishable from categories. List pages are treated the same as articles and require prose.List of caves is a poorly developed list as it doesn't even have prose discussing a rational inclusion criterion. There is no way we're simply listing all caves ever no matter how small and obscure. "Parking" some images on the right hand column is fairly common for under developed lists. The ideal would be to create a sortable list with a picture column likeList of people from Park Ridge, Illinois. For caves, I think pictures add to the informative nature of this list.Dkriegls(talk to me!)05:18, 9 November 2015 (UTC)
Since this the "Further information" linked in two sections covering Stand-alone listsand Embedded lists, it implies this should be looked on as overall guideline for both types of lists (seems obvious to me). If so shouldn't that guideline section be move to this MOS?Wikipedia talk:Manual of Style/Lists has no specific wording explaining obviousselection criteria/inclusion criteria/membership criteria andManual of Style/Embedded lists gives no guidance at all on selection criteria, not even a link toWikipedia:Manual of Style/Stand-alone lists#Selection criteria.Fountains of Bryn Mawr (talk)19:04, 24 August 2016 (UTC)
Can a list contain elements that do not deserve to have articles about them? If yes, what lists would make good examples for this kind of situation? — Ark25 (talk)15:06, 23 October 2016 (UTC)
Use of semicolons
Use of semicolons is pretty poor formatting, primarily because the bold markup is adequate and also because it is not good for screenreader users. One editor told me it isn't as straightforward as bold markup and that the semicolon is basically the last markup that should be done. Can this be changed? --Jennica✿ / talk11:53, 26 January 2017 (UTC)
Should linking the DLIST item names be avoided? It results in unsightly blue or red links in the bold list items. This is discouraged for normal bold text in the lead, but what about in association lists? Working the linked name into the description text might not always read smoothly, and can appear redundant. --Paul_012 (talk)08:37, 8 November 2017 (UTC)
Hmm. I'm still having trouble locating the exact statement (though now that you mention it, I'm quite positive that I did see it there before). --Paul_012 (talk)14:13, 8 November 2017 (UTC)
Weird. It used to be in there, and should be in there, since the same rationales apply. They basically are low-level headings that are also acting as terms in term/definition structures. Could also be mentioned atWP:MOS#Section headings, in "Several of the above provisions are also applicable to headers of tables and of table columns and rows" (e.g. by changing to "headers of tables, headers of table columns and rows, and term entries in description lists". And/or atMOS:DLIST. Not sure it matters where it lives, I just know it was in there and should not have been removed. — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 14:26, 8 November 2017 (UTC); rev'd: 14:48, 8 November 2017 (UTC)
I've reorganized the material a bit, so that the "Bulleted and unbulleted lists" summary at the bottom of the page is now closer to the top (as "Bulleted and unbulleted list basics", with a newMOS:LISTBASICS shortcut). It now summarizes everything in common between the two list types, and the redundant material in the sections "Bulleted lists" and "Numbered lists" has been merged here, leaving behindWP:SUMMARY abstracts and cross-references to the new section for further detail. The scattered material on sentence case and lowercase, and on full sentences and fragments has been consolidated and put into a logical order; new shortcut:MOS:LISTCASE. The material about images and lists has been moved out of "Bulleted lists" and put into a new "Images and lists" section in "List layout", since it has nothing to do with bullet lists in particular. Also fixed a misnamed section about introductory material for lists that was calling it "list leads", which is confusing;lead has a special meaning here, which is also heavily discussed in the page already (atWikipedia:Manual of Style/Lists#Lead section or paragraph). The deprecated "Line breaks" section, on creating pseudo-lists, has been moved to the bottom instead of the top, perWP:BEANS andWP:Common sense. The new merged material has been given a good copyediting for concision and clarity, and some markup has been improved.
The only potentially controversial bit I can think of in this editing run is that the merged material also includes a few pointers that were missing (e.g., it is actually common practice to use semicolons and lowercase in a short list which in total forms a complete sentence, so this is now accounted for – and should avoid future editwarring by anyone who thought this format was "against the rules").
Some further cleanup needs to be done. E.g., the big "bad example" table in bulleted lists isn't really about bullet lists but all lists, and belongs inMOS:LISTGAPS. The extensive custom-coding examples under "Numbered lists" is probably copy-paste of material inHelp:List. Even if not, it should merge there. That page actually needs work; it's ToC is not very helpful. And the advice under "Organization" should also be adapted forMOS:TABLES (or cross-referenced from there as applicable to tables).
Our examples all show a blank after the asterisk and before the text in a list item, but is that required? Bots are going around inserting them, and it seems like unnecessary churn to me.
It presently does affect display in some limited cases relative to Parsoid, but these are cases for the MediaWiki programmers to worry about (since I apparently convinced them on the point); refphab:T157418. --Izno (talk)12:46, 1 November 2017 (UTC)
Thank you, COSMETICBOT is the answer I was looking for. (I have put a blank at the beginning of this line for compliance with Wikipedia standards.)Kendall-K1 (talk)13:40, 1 November 2017 (UTC)
I don't find anything about this aten:Help:List (which doesn't mean it wasn't in there when that was written). No idea about .de and .fr help pages. The MoS pages about lists do not address it, but they wouldn't, since MoS isn't about code formatting. Just the fact that it's a readability improvement is surely sufficient, and there's certainly no rule against using* Foo instead of*Foo. So, I don't really see any point in opposing what the bot is doing, as long as it's not triggering watchlists to donothing but that change. Personally, I thinkWP:COSMETICBOT is stupid and petty bullshit, and should just be deleted. It impedes a tremendous amount of useful cleanup work. So, I'm automatically opposed to overextending interpretation of it beyondexactly and only what it constrains. It should be replaced with a narrower rule against bots making trivial changesthat do not actually improve Wikipedia, with out regard to whether the improvement is user-facing or editor-facing. I.e., it should be an extension ofMOS:STYLEVAR in effect: if there's not a good reason to change something about code style, then do not do it; if there is a good reason to change it, then do it, and whether it's done manually or with tools should be irrelevant. The central problem to me is that no human editors should be forced into having to manually make any maintenance changes that are better done by tools, since our human judgement and time is better spent on adding and soucing content (and, for those of us with the stomach for it, resolving disputes between editors). — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 11:30, 2 November 2017 (UTC)
This particular case was brought up by me (and at least 1 other person independently on the same talk page )User talk:Basilicofresco. In this case I highlighted there was a list of bullet points consistently formatted without a space between the "*" and the first text character. The bot inserted one. I do not think that bots should be inserting or deleting spaces after the "*" if they are consistently formatted. Presumably if the usage is consistent in a list of bullet points someone made that decision. It is not up to a bot to change it. This is similar to bots deleting empty lines after a title or removing spaces at the start and end of a section header. There is no need for it and it can make it more difficult to see changes in diffs that have a substantial affect on the article --PBS (talk)12:03, 2 November 2017 (UTC)
I don't mean to beat up on Basilicofresco here. He has already said he would disable this feature. But apparently this is a standard module that any bot can use. Agreed it doesn't quite violate any policies. But combining one non-cosmetic change with hundreds of cosmetic ones hides the one non-cosmetic change and makes it difficult for those of us who like to see these things. And I agree that if a list is consistently formatted one way, changing it to the other way is disruptive.Kendall-K1 (talk)15:17, 2 November 2017 (UTC)
One of the original selling points of Wiki markup was that is was more clean and human readable than other markup languages. To omit the space in a list goes against that fundamental feature of Wiki markup, it is almost as bad as failing to use punctuation. Failingtousepunctuationisobviouslynotgoodforreaderssameasnotusingspacesisbadforeditorsmakingithardertoseeotherproblems. Would you strip all the spaces out of the Infobox too? It seems odd that to me that so many editors accept a nice tidy infobox but reject tidy markup elsewhere. I fully understand that cosmetic changes (such as line breaks) can sometimes unfortunately hide other changes but fundamentally that is a reason to request the programmers to develop a smarter diff tool, not a good reason to avoid clear markup. --109.76.186.141 (talk)21:13, 21 July 2018 (UTC)
Chronological order, for lists within articles
I looked for guidance on this after seeing today's DYK link to the articleJosette Frank Award, which includes a list with the latest year at the top.
However, the linked page is specifically for stand-alone lists; that is also indicated in the name of the section shortcutWP:SALORDER. The words "such as timelines" could be interpreted as limiting the rule to stand-alone lists.
It would be helpful for this MOS page either to state this latitude for lists within articles, or to rule it out more clearly if reverse-chronological order is no longer acceptable. –FayenaticLondon09:50, 6 November 2018 (UTC)
They are. But they're much more readable in camelcase, e.g. LightGrey. The notion that they're proper names, however, is way off base. Regardless, we have no rationale for presenting them with just an upper-case initial letter, e.g. as Lightgrey. That's neither a style improvement (from any kind of subjective "correctness" perspective with a hint of a logical basis) nor a readability improvement. — SMcCandlish☏¢ 😼 23:16, 20 November 2018 (UTC)
That's looking at the issue the wrong way round. If we have a reliable, uncontested source that says a list is complete, then we can state that fact on Wikipedia. In any other case, there's no justification for assuming a particular list should be complete. --RexxS (talk)01:11, 18 January 2018 (UTC)
Many lists are unsourced, some of them repeat information available in some Category, but a Category isn't a source.Xx236 (talk)08:12, 31 January 2018 (UTC)
The central premise is wrong. We only list places that are notable or at least withinWP:DUE andWP:NOT#INDISCRIMINATE. That's a whole lot of places (basically everything the size of an incorporated village), but it is not every place, and "place" itself is ambiguous and not really a defined concept. Is Jim-Bob's farm up the road a "place"? He sure thinks so. — SMcCandlish☏¢ 😼 17:34, 21 November 2018 (UTC)
RfC on permitting "List of foo" mainspace titles to redirect to categories instead
While list entry size varies by list and by individual entry, any given entry should not be of an excessive length, out of proportion to the rest of the list. A large entry can often be pared ofindiscriminate information (trivia, material that isn't on-topic for the list, and otherexcessive detail). In other cases, a list entry's well-sourced development indicates that much of the item's content should bemerged into the main article on that topic, orsplit into a new article, leaving behind only asummary-style list entry.
Support - I think the key phrase here is “out of proportion to the rest of the list“. An “out of proportion” list entry is a red flag that the list hasWP:UNDUE issues.Blueboar (talk)23:48, 20 November 2018 (UTC)
Yes, that's what brought this up. Too often I see something like an "In popular culture" section with an entry for one item that has been fan-gushed all over it, or a list of works with a tremendous amount of detail for one particular book/film, or an episode list with one entry that three times longer than all other, poring over every detail of who said what and played what part. — SMcCandlish☏¢ 😼 17:27, 21 November 2018 (UTC)
Please actually read the decision:The "MOS:" pseudo-namespace (for the Manual of Style) seems to have quite wide support, and is widely used. See also recent (within the last year)WP:RFDs to delete "MOS:FOO" shortcuts that even have nearly zero actual use; they failed, except for a couple of cases of truly improbable combinations. (I would know; I was the one trying to delete them.) — SMcCandlish☏¢ 😼 17:27, 21 November 2018 (UTC)
Oppose I can't tell you how many times I have seen suggestions that a sub-stub or marginally notable item be included in some list until it can be expanded/referenced sufficiently to be split into an article. This suggestion would eliminate this useful process for preserving information and creating articles.Jack N. Stock (talk)01:28, 21 November 2018 (UTC)
Merging a non-notable thing to a list doesn't mean merging enormous amounts of detail about it to a list, or we no longer have a list, we have aWP:COATRACK with a bunch of heavy coats on it. — SMcCandlish☏¢ 😼 17:27, 21 November 2018 (UTC)
Not for a single list, for a frequent problem (see above). Running into it again reminded me we lacked a cleanup template for it. "Really went through the effort" doesn't logically apply to creating a template and necessarily creating the hidden category it uses; it's routine and just takes a few moments of mostly copy-paste work. I only applied it to one article at the time, because I only one article in front of me at that moment exhibited the problem. We're all volunteers here. We would have no cleanup/dispute templates at all if SOFIXIT required us to fix every problem we identify, on the spot. Not every flagged problem is agreed by everyone to be a problem (or to be that problem), and not every editor who sees a problem is in a good position to fix it (e.g., due to lack of subject-specific knowledge). Discussions happen for good reasons, and templates to trigger them exist for good reasons, too.
To return to the actual topic: whether you like the template or not has nothing to do with the proposal, which is a simple two-sentence line-item that points to relevantpre-existing policies, guidelines, and procedures and explains how they pertain to list entries. It's basically a very compact way to cross-reference five relevant things at once without a bunch of "please see also" blather or a thick stack of hatnotes. — SMcCandlish☏¢ 😼 17:27, 21 November 2018 (UTC)
Oppose perWP:CREEP unless anyone can show a recent GA or FA or FL in which a stand alone or embedded list was promoted due to the lack of specificity in this MOS instruction. I scrolled up looking for the examples and I didn't see any article or list names. Where is this a frequent problem? Certainly lists below GA-class exist which have this and many other flaws, but that is not a problem that requires action. Under current rules, those flawed lists are all maturing at some speed, becoming more like the MOS-compliant examples. --Dennis Bratland (talk)00:26, 29 November 2018 (UTC)
The reason you don't find many examples of it on perusing through lists (especially FLs which have already been worked over very hard by multiple people) is that we don't actually tolerate it. We remove trivia, we split and merge articles as needed, and we move contextually off-topic material to the page where it actually belongs. The purpose of a guideline is to codify best practice, not change it. Where we have best practices that are clearly in use but are not codified, we are not writing the guidelines properly. This can be problematic, because a lot of semi-productive editors are apt to wikilawyer other people to death along "there is no rule against it so you can't stop me" lines. We all see it all the time and it's a waste of that time. — SMcCandlish☏¢ 😼 02:24, 4 December 2018 (UTC)
Oppose perWP:CREEP. I don't see a list specific reason for uniform list item size. If a list item is obtuse in size and unencyclopedic, then unencyclopedic is all the argument needed to make it fit the flow of the list. If it's obtuse size wise and encyclopedic, then I don't see a reason to remove any encyclopedic text in order to make the list look uniform in list entry size. --Dkriegls(talk to me!)03:39, 17 January 2019 (UTC)
Horizontal lists
Now thatTemplateStyles has been implemented, an inline list using comma separators is now available:
{{cslist |First |second |third item}} →
First
second
third item
That looks like a prose list but is marked up as a horizontal unbulleted list so that a screen reader will treat it as it does any other list.
Given the accessibility (and semantic) benefits of marking up lists as html lists, can we offer guidance to use{{cslist|Entry 1|entry 2|entry 3}} as an optional alternative to "Just plain text" for the 'List with commas' approach in the table in theWP:FLATLIST section? --RexxS (talk)22:36, 15 January 2019 (UTC)
The HTML specification excludes lists from paragraphs i.e.<p>Pre-list thing <ul><li>list thing</li></ul> post-list thing</p> is non-conformant markup. I expect MediaWiki would accordingly output that as<p>Pre-list thing </p><ul><li>list thing</li></ul> <p>post-list thing</p> --Izno (talk)01:10, 16 January 2019 (UTC)
Indeed, and the same would presumably apply to{{hlist}} and{{plainlist}}, although because they are wrapped in a div, they are block-level elements anyway. However, I wasn't suggesting that we use{{cslist}} in running prose – if you look at the guidance I'm referring to, it states"In situations such as infoboxes, horizontal lists may be useful. Examples:" You'll find that{{cslist}} behaves like a normal inline element inside a table cell and inside a list (as above):
Wikitable demo of horizontal lists inline
{{cslist |First |second |third item}} →
First
second
third item
{{hlist |First |second |third item}} →
First
second
third item
so I'm hoping that it would represent a viable alternative for use in infoboxes by those who dislike mid-dots. --RexxS (talk)17:00, 16 January 2019 (UTC)
There is a reason one might not want to use cslist or similar and that's compatibility with the mobile site, which I believe does something funky with hlist. --Izno (talk)17:40, 18 January 2019 (UTC)
@Izno: I'm looking at this page in mobile view now, and the word I'd use for the mess it makes of hlist is not "funky". However, cslist looks fine – the mobile devs haven't found a way to screw up commas yet. --RexxS (talk)00:49, 19 January 2019 (UTC)
If it is more than just a list, or there is a active and clear plan to very shortly make it more than just a list, then "List of" should be dropped, since page titles should be accurate as to content. — SMcCandlish☏¢ 😼 23:20, 11 May 2019 (UTC)
To me, if the set on the list is clearly finite, so that if its "List of X" that "X" alone makes sense to exactly the extent of the list, then then "List of" can be dropped. From my interest area of video games, we'd wantList of best-selling video games, (as "best-selling video games is vague), whereasCharacters of Overwatch is a pretty fixed and defined list so no need for "list of". And I do agree with SmC that this is also where the content is more than list a listing, but includes brief descriptions or other details. --Masem (t)23:27, 11 May 2019 (UTC)
Is there any guidance/advice anywhere on how to craft good short descriptions for "List of..." articles? It seems like a common default is{{short description|Wikipedia list article}} but that's not a particularly useful short description. —Joeyconnick (talk)18:18, 6 June 2019 (UTC)
Proper sorting of list of (academic journals)
What is the correct way to sort a wikipedia list of journals? The confusion for me is when the official title starts with "The Journal of X" or "Journal of X". Do we sort by T for The, J for Journal or X? There are some categories where there is a mixture, depending what is in the DEFAULTSORT field on the page. But lists also seem to have variable rules. Is there an style guide for this?Notgain (talk)11:34, 18 July 2019 (UTC)
For most works (not just journals), I typically use a mix. If it's a category about journals, I would sort by the most interesting words in the journal name (which is none of The, Journal, or of). If it's a work about Batman, and a category called "Batman", I'm not going to use Batman as the keyword (or words). --Izno (talk)13:22, 18 July 2019 (UTC)
@Izno: What you just said makes sense to me for what might be a good guideline/policy for wikipedia lists and categories sorting. Or at worst each list should specify some sort of decision rule at the top of page for how to sort so there is some consistency. There are some lists of journals in alphabetical order which have a bunch of journals in "J" for journal and some in "T" for The. I have not seen anyone sort one under "o" for "of" yet.Notgain (talk)00:52, 19 July 2019 (UTC)
Classes of lists
I would like to clarify the introductory second sentence of the MOS/Lists page to add a third category of list: sections such as "Publications (or Bibliography)", which are explicitly defined in theMOS as Appendices which are *not* part of the textual body of the article (seeWP:Manual_of_Style/Layout). The relevance of this is that that many editors seem to think that the prohibition against External Links in the body of an article applies to a list of Publications, which is not correct (seeMOS:WORKS#Online books). This seems like a straightforward factual addition; any objections?Finney1234 (talk)22:07, 16 August 2019 (UTC)
HiRedrose64 : My only intent here is to clarify in this part of theMOS that there is a third category of list not covered in the existing sentence (theMOS clearly distinguishes article "body" from "Appendices" such as Publications; seeWikipedia:Manual_of_Style/Layout). Doing that is simply collating information stated elsewhere in theMOS (my change would *not* involve the other issues, I was just stating that as a rationale). I feel as if the link you provided (MOS:WORKS#Online books) clearly resolves the contentious issue raised inWikipedia:Village pump (idea lab)/Archive 29#External Links in a Publications Section, and indicates that this view was reached by prior consensus, so I don't need to ForumShop, and I believe the other folks there are rather tired of the issue :-).
Let me know if you disagree and I'll put a link in VP. However, since you've been very helpful, I'm interested in another related question raised earlier in the contentious discussion. When I pointed out (based onMOS text) that nothing in theMOS prohibited links in a "Publications" section (that was before you provided the useful link), I was told that I still ought to seek consensus before doing it. It seems to me, however, that the only reasonable way to interpret theMOS is to assume that anything not prohibited in theMOS is allowed. Can you point to anything in Wikipedia documentation that addresses this question, one way or the other? Thanks again.Finney1234 (talk)00:10, 17 August 2019 (UTC)
Specifically, my proposed change would simply be to alter "Lists may be found within the body of a prose article or as a stand-alone article" to "Lists may be found within the body of a prose article, in appendices such as a "Publications" or "Works" section, or as a stand-alone article". This strikes me as non-contentious.Finney1234 (talk)00:10, 17 August 2019 (UTC)
Is there something in this guideline that prevents use of a clear concise list of features when talking about update to a operating system?
Is there something in this guideline that prevents use of a clear concise list of features when talking about update to an operating system? For details see:here Thanks, Daniel
I think the guideline is basically will prose work better. I would say definitely not. All I want to see, and I suggest most users also, is the new feature set. Having to dredge through a bunch of prose for that is a waste of time.Daniel.Cardenas (talk)
It isWP:NOTCHANGELOG. Every detail of a change in an OS is not appropriate, but you can go by major features and updates given by third-party reliable sources. You can also link to a site that contained the detailed change long. --Masem (t)21:46, 4 September 2019 (UTC)
Thanks, it is not a detailed change log. The detailed change log is composed of thousands of changes. This is just a handful of the most important new features, which themselves are composed of many changes. Daniel.Cardenas (talk)22:01, 4 September 2019 (UTC)
More than a handful? Fine lets change that to 12 new features. Tiny compared to the thousands of changes. Overly detailed? What would you consider appropriately detailed? And what would make it pretty versus ugly? I suppose I have no style, because the list looks very beautiful to me and super helpful. :) Daniel.Cardenas (talk)00:45, 5 September 2019 (UTC)
As I noted on the talk page, you have been persistent to add this bulletlist four other times.1,2,3, and4. It's disruptive editing at this point. –The Grid (talk)19:01, 5 September 2019 (UTC)
How many times should an excellent addition be added to conteract those who are confused and claim it is a violation of this policy when it isn't?Daniel.Cardenas (talk)19:41, 5 September 2019 (UTC)
NOTCHANGELOG is not only talking the level of detail, but thecoverage of changes by secondary, third-party sources; the addition was using a first party source. We want changes that are deemed important through the eyes of third-party experts. --Masem (t)19:49, 5 September 2019 (UTC)
That is easily fixed. Has received wide coverage from many media outlets. Seems just about every technical and generic site has a related article. Here are a couple of examples:[15][16]Daniel.Cardenas (talk)21:35, 5 September 2019 (UTC)
I see a bit ofWP:FORUMSHOPPING going on here. To answer your question, "How many times should an excellent addition be added", the answer is once, and then if it is removed, you discuss it perWP:BRD. The real problem is your addition was not excellent, it was entirely problematic and a bulleted list is unnecessary in the lede, and a change-log isn't needed there either. Summarize the article in the lede; nothing more and nothing less.Walter Görlitz (talk)22:39, 7 September 2019 (UTC)
Another factor to keep in mind is that we are not writing these articles for people that might be using Android, but for a general reader who we can presume has a minimum amount of understanding of mobile devices. "Android 10 introduces new user interface and security features" is a reasonable statement, where as "Android 10 prevents background apps from jumping into the foreground" is going to be nonsense for such readers. The articles you linked are aimed at that level, and that's why the descriptions in prose are better. --Masem (t)22:43, 7 September 2019 (UTC)
What if the short description is linked to a longer description below in the article? The issue with prose, is how low do you go? Do you write a page for each feature with pictures so that a non computer user can understand it?
>"Android 10 introduces new user interface and security features" is a reasonable statement
The problem with that statement is that it is practically true for every operating system major release, so doesn't really convey any useful information.
If it doesn't convey useful information, and I can't stress this enough,do not write it. Pretty simple really. In fact most of what ive read written to you has been simple advice that you take exception to and look for a loophole and continue to argue about. If a summary is needed, write it, but do so in prose. Know your audience and write for them.Walter Görlitz (talk)00:49, 8 September 2019 (UTC)
Also, one final point I'm going to put as a final nail. Note the first thing you stated for reasoning:AllI want to see, andI suggest most users also, is the new feature set. What makes this any different from any previous Android release?MOS:USEPROSE would be the better suggestion as you want to highlightkey points of every Android release without going too technical about it. This isn't a technical manual. –The Grid (talk)21:21, 11 September 2019 (UTC)
There is no difference from any previous android release. What people want to see is the list of features. This is evident by what is shows inAndroid_version_history#Version_history_by_API_level. As far as the claim of forum shopping, the android 10 talk page was started first which is the correct and only place to discuss Android 10 content. The claim was made that a list in thewp:lead violates the guidelines on this talk page. To discuss if that is true, I felt, this talk page was most applicable. So in summary, this talk about list in lead and Android 10 article about not meeting wikipedia guidelines for most important content in the lead section. Daniel.Cardenas (talk)13:02, 14 September 2019 (UTC)
That page is also violating NOT#CHANGELOG. Readers that want to know the detailed changes in versions can find that elsewhere, we need to summarize these for readers that have no idea about Android features as 90% is just a mess. A proper approach to update versions is something likePlayStation 4 system software. --Masem (t)13:17, 14 September 2019 (UTC)
It is far from a change log. The change log for Android 10 would have thousands of entries. Not sure what you mean by 90% is just a mess. ThePlayStation 4 system software article is missing a proper lead. A proper lead would entice the user to read more.A list of improvements, significant changes, or new features in the lead would improve the article, by doing what the lead is suppose to do, which is entice the user to read more.Daniel.Cardenas (talk)19:34, 15 September 2019 (UTC)
Sorry I read that playstation article if was an update, which it is not. The point stands that the lead is missing what makes the article interesting and a summary.Daniel.Cardenas (talk)23:44, 15 September 2019 (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 smallWP:Manual of Style/Embedded lists page serves no purpose, and is actually counter-productive, since much of the advice in it pertains to lists generally. It should just merge into the mainMOS:LISTS page, probably with pared down examples (some of them are really huge, for no real reason). — SMcCandlish☏¢ 😼 23:03, 20 November 2018 (UTC)
Both of them should probably have their examples pared down with some sort of "how to list" page separate from the "when to list/why to list" page. The merge target is rather lengthy as well. Otherwise an agreeable merge. --Izno (talk)00:50, 21 November 2018 (UTC)
Yeah, any material that's how-to oriented can probably be merged toHelp:List (the "how to list" page we already have), or at least get highly compressed if it's necessary for context. — SMcCandlish☏¢ 😼 17:29, 21 November 2018 (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.
Performing merge
Going to set aside this section for any questions that might pop up for me or my own questions for others. The content remaining to merge can be seen atUser:Izno/Sandbox#MOS:Embedded Lists.
@SMcCandlish: You createdMOS:LISTFORMAT pointing to Embedded lists#Size. In the framing of this page, the format tends more toward actual formatting or styling, whereas I think the intent of LISTFORMAT is more framed at the the part of this page talking about an embedded vs. a stand-alone list, which this page calls the LISTTYPE give or take. Would you object to retargeting that redirect? It seems to be used very little. --Izno (talk)21:32, 11 May 2019 (UTC)
I merged this then got tired of trying to find the best spots for the remaining content. I will likely return. --Izno (talk)14:47, 15 May 2019 (UTC)
Izno, I saw this when it happened, but, after I madethis revert (with a followup note that prose is preferred and a comment on the editor's talk page about prose), I realized that the newWP:Prose section didn't explain why prose is preferred for articles, which contraststhe previous version. I know that part of the text was moved to the top ofWikipedia:Manual of Style/Lists#Types of lists. But the rest of the text was lost; so I re-added most of it withthis edit (followup notehere). But the following is probably not needed in the section or is redundant to something else on the page: "Lists oflinks, which are most useful for browsing subject areas, should usually have their own entries: seeWikipedia:Stand-alone lists for detail. In an article, significant items should normally be mentioned naturally within the text rather than merely listed."Flyer22 Reborn (talk)05:56, 12 October 2019 (UTC)
Okay, looking again, you did retain the important detail. But I feel that it's best to explicitly state "Prose is preferred in articles." So that's back. Iremoved the "Lists of links" paragraph I just added.Flyer22 Reborn (talk)06:06, 12 October 2019 (UTC)
New Zealand
