Jump to content

Wikipedia talk:Manual of Style/Lists/Archive 8

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 5Archive 6Archive 7Archive 8

Number of elements in a prose list

Seeking guidance on how many elements in a prose list would result in a bulleted list as the preferred presentation format. The case at hand is mentioning the settlements in Slovenian municipalities, which range from minimal (e.g., Dobrovnik) to extensive (e.g., Novo Mesto). Thanks. Doremo (talk) 19:50, 25 March 2020 (UTC)

Do we really need a hard rule for everything? It would be fairly arbitrary trying to set one anyway, so just use common sense. -- P 1 9 9   20:37, 25 March 2020 (UTC)
Perhaps when the vertical dimension of the prose list exceeds the horizontal dimension? Doremo (talk) 03:56, 26 March 2020 (UTC)
That is sooo subjective. How wide is my screen? You don't know. So you cannot know how tall a given piece of prose is either. --Redrose64 🌹 (talk) 00:08, 27 March 2020 (UTC)
Its not a screenwidth issue, its a WP:SEAOFBLUE issue. A list of links that have only commas (no other words) between them longer than three or four terms can become quickly hard to read in prose, and at which a bulleted list or similar structure would be easier to read through. --Masem (t) 01:28, 27 March 2020 (UTC)

SOURCELIST clarification

I've had a few editors argue that WP:SOURCELIST and WP:V do not require sourcing in lists if the items are linked and sourced on their individual pages. Is it ok to edit the guide to clarify this? buidhe 00:08, 22 April 2020 (UTC)

They are wrong pls see WP:LISTVERIFY.--Moxy 🍁 06:13, 22 April 2020 (UTC)
Though also see WP:V policy on the requirement that things be verifiable does not equate to a requirement that they be already verified. It'll be interpreted as disruptive to delete valid list entries that have sufficient sourcing in their own main articles, just to try to force someone else to do the work of porting over one or more of those citations. It would also be disruptive, though, to go around removing citations from a list on the excuse that the list items in question are already sourced in other articles. Basically, WP:Common sense applies: don't do anything that damages the content just to be WP:POINTy.  — SMcCandlish ¢ 😼  05:52, 20 October 2020 (UTC)

Do text walls really read better?..

Use prose where understood easily

Prefer prose where a passage is understood easily as regular text. Prose is preferred in articles because it allows the presentation of detail and clarification of context in a way that a simple list may not. It is best suited to articles because their purpose is to explain.

{{prose}} can be used to indicate a list which may be better-written as prose. Many stub articles can be improved by converting unnecessary lists into encyclopedic prose. See also: WP:Manual of Style/Trivia sections.

Example of the difference between prose and a list
Prose List with no content
The 20th-century architecture of New York City includes numerous icons of architecture, most notably its striking skyscrapers. In the first few decades of the century, the city became a center for the Beaux-Arts movement, represented by architects Stanford White and Carrère and Hastings. New York's new skyscrapers included the Flatiron Building (1902), where Fifth Avenue crosses Broadway at Madison Square; Cass Gilbert's Woolworth Building (1913), a neo-Gothic "Cathedral of Commerce" overlooking City Hall; the Chrysler Building (1929), a pure expression of Art Deco; and the Empire State Building (1931). Modernist architect Raymond Hood, and Lever House after World War II, began the clusters of "glass boxes" that transformed the classic skyline of the 1930s, culminating in the World Trade Center towers (1973). 20th-century architecture of New York City


— Wikipedia:Manual of Style/Lists

What do you think?

Hierarchic (index optimized)
The 20th-century architecture of New York City includes numerous icons of architecture, most notably its striking skyscrapers.

In the first few decades of the century, the city became a center for the Beaux-Arts movement, represented by architects Stanford White and Carrère and Hastings.


New York's new skyscrapers included:

Related

Wikipedian Right (talk) 23:45, 9 March 2020 (UTC)

@Wikipedian Right: The point of the MoS section isn't that it's impossible to encapsulate the same information in a list with long items; it's that WP is primarily a prose work, and lists should mostly be used for information that doesn't work well as a paragraph and works better as a list. (Actually, the bare-list example given would be better as an inline list.) Your version is how a lot of lists are already done. But in this case it's a poor choice, because it's not a format that's very good for lists of a few examples. It implies that it's a complete list (or at least a complete list of notable instances of whatever the subject it is, or all the instances we are going to be treating in the article − e.g., we often use it for cast lists for films and TV shows). It looks like an index or glossary of some sort, and we also frequently use it for that purpose (with entries often corresponding to sections that follow).

When list style is used in cases like the five-building material above, it mimics a PowerPoint presentation, drawing the eye to the examples rather than the narrative flow and overall meaning of the section, which the examples were intended to illustrate not overwhelm. It makes it look like a section-stub, in which we have nothing to say yet, other than "go to these pages instead". Another sort of place where lists of this sort do make sense is in overview articles in summary style which branch out to more specific subtopics (e.g., a general scientific field to several disciplines within it – while as an encyclopedia we do need an article at Chemistry, the vast majority of readers already know what that is and are looking for something more specific). The list format encourages clicking away to one of the list items more than prose paragraphs do. Most of our list articles exist as a form of navigation and have little or no stand-alone content of their own beyond an explanatory lead.

Observations like these, along with illustrative examples of more list uses (pro and con), aren't really the kind of material an MoS page needs; MoS is already over-long. It's really more of an essay topic.
 — SMcCandlish ¢ 😼  12:46, 20 October 2020 (UTC)

@Wikipedian Right: The example prose section suffers from extreme overlinking. Although this is a different issue, it is one that decreases readability. Senator2029 ❮talk❯ 21:32, 10 November 2020 (UTC)
  • The MOS isn't really using an apples-to-apples comparison: the prose passage has far more detail than the plain list beside it (the more detailed list below is a little more direct of a comparison; I'm not sure where that's from/proposed to go). I agree with SMcCandlish's points above, and that prose would be the right way to go for that content. {{u|Sdkb}}talk 21:57, 10 November 2020 (UTC)

RfC: Standardizing shortened reference column titles

It is common practice to abbreviate reference column titles to keep their width narrow. However, even among featured lists, I've noticed considerable variation in format, e.g. 1 2 3 4 5. This RfC seeks to find agreement on the best format for these titles, which could then be added to this guideline or encoded in a template. Here are a bunch of options:

  1. Ref
  2. Ref.
  3. Refs
  4. Refs.
  5. Ref(s)
  6. Ref(s).
  7. Ref [Tooltip: Reference]
  8. Ref [Tooltip: References]
  9. Ref [Tooltip: Reference(s)]
  10. Ref. [Tooltip: Reference]
  11. Ref. [Tooltip: References]
  12. Ref. [Tooltip: Reference(s)]
  13. Refs [Tooltip: References]
  14. Refs [Tooltip: Reference(s)]
  15. Refs. [Tooltip: References]
  16. Refs. [Tooltip: Reference(s)]
  17. Ref(s) [Tooltip: Reference(s)]
  18. Ref(s). [Tooltip: Reference(s)]
  19. Have no standard.
  20. Don't allow abbreviations; always use Reference, References, or Reference(s).

Cheers, {{u|Sdkb}}talk 08:10, 11 October 2020 (UTC)

  • 10 or 12, based on how many references there are per row. "Ref." is nice and short, but keeps the period to make it clear it's an abbreviation. I think the tooltips are helpful, just in case there's any confusion ("ref" is pretty widespread, but it's not guaranteed universally understood). Regarding the plurality, if all rows only have a single reference, it should be singular, just like we'd have singular "County" as the title in a country list with one country per row. And if at least one row has multiple references, it should use (s) to indicate an optional plural. Even if all rows have multiple references, I don't really like 11 as much, since it sends the false signal that multiple references are required, and for dynamic lists, someone adding a new row with only a single reference would be unlikely to know/remember to change it to 12.
Overall, yes, this is a pretty finicky thing that's likely going to be relevant mainly at WP:FLC, but given how many lists use this, I do think it's worth putting a bit of thought into what the best format is, and trying to unify around it for consistency. {{u|Sdkb}}talk 08:10, 11 October 2020 (UTC)
  • Does this need to be an RFC? Are there multiple pages with some intractable conflict? Is this guideline one of them, such that the MOS regulars could not figure it out after some protracted or contentious discussion? --Izno (talk) 13:33, 11 October 2020 (UTC)
    @Izno: There hasn't been prior discussion (that I could find), but my gut says that, without the tag, this would be likely to draw low participation that would lead to complaints about insufficient consensus when the result is implemented. {{u|Sdkb}}talk 16:25, 11 October 2020 (UTC)
  • 15. The full-length word is too long. A period correctly indicates it is an abbreviation. Plural is correct because there should be a whole column of references. A tooltip is good for those who don't recognize the abbreviation. Normal Op (talk) 16:32, 11 October 2020 (UTC)
  • 12—but it's not a super strong preference. --‿Ꞅtruthious 𝔹andersnatch ͡ |℡| 07:09, 16 October 2020 (UTC)
  • Comment – Isn't the difference between "Refs" and "Refs." a MOS:ENGVAR issue? MOS:POINTS provides:

    Contractions that do not contain an apostrophe almost always take a period in North American English, but the point is optional in British English: Doctor can be abbreviated Dr. in American and Canadian English, but Dr. or Dr in British English. If in doubt, or if the dot-less usage could be confusing in the context, use the point.

    207.161.86.162 (talk) 00:37, 20 October 2020 (UTC)
    No, because it's optional in BrEng, not forbidden, so it is not wrong and we do not need to care. I suppose someone with too much time on their hands can make a template for exuding different output (even singular/plural text and tooltip) in response to parameter switches, but this is bikeshedding.  — SMcCandlish ¢ 😼  05:47, 20 October 2020 (UTC)
    @SMcCandlish: Because internal consistency in articles is required, if we were to decide on, e.g., option 15 (Refs.), does that not mean that, in all articles in British English that include a table with a references column, the use of periods after contractions will become mandatory? 207.161.86.162 (talk) 20:23, 21 October 2020 (UTC)
    SMcCandlish? 207.161.86.162 (talk) 05:39, 5 November 2020 (UTC)
    No, per MOS:ENGVAR. Lack of points at the end of contraction abbreviations (Dr, St) is effectively standard in British and some other dialects, while the presence of them is effectively standard in American and probably a few other dialects. Dropping the points after truncation abbreviations (Prof., Hon.) isn't an effective standard in any, and the major British style guides deprecate the practice (which is primarily found in news journalism, e.g. the stylebook of The Guardian). People who read little but British news get the mistaken impression that dropping all points from all abbreviations is "British style", but it's simply what their preferred newspapers do for expediency, and they have not looked at New Hart's Rules or anything from the British academic press.  — SMcCandlish ¢ 😼  06:41, 7 November 2020 (UTC)
    @SMcCandlish: I'm only referring to contraction abbreviations (and I'm under no delusions that the stylistic practices of the British press around abbreviations are universal – of course the academic style used in encyclopedias is different). Would "Refs." not be a contraction (rather than a truncation)?
    If so, my worry is that using it would either (1) create inconsistencies in articles where periods aren't used after contractions or (2) result in the imposition of an American style. 207.161.86.162 (talk) 02:06, 10 November 2020 (UTC)
    It's a definitional point people could argue over until the end of time. I would argue no, because the original, "root" abbreviation is ref. (which can in fact stand for reference or references), while refs. is simply a rather unnecessary pluralization of it. That it can be argued to accidentally also coincide, after the fact, with a contraction of references (only) is probably immaterial, since that's not how it was derived. It's exactly parallel to Prof. Jones and Profs. Jones and Hidalgo. I'm not aware of any British/Commonwealth-English publication that would use Prof. but which would then switch to Profs arguing that it's a contraction rather than a pluralization of an already established truncation. That is, we already know that publications following Oxford/Cambridge style do not engage in the "cross-inconsistency" that worries you, so it is not in fact an established BrEng practice, ergo nothing for WP to use, especially not on ENGVAR grounds.  — SMcCandlish ¢ 😼  03:12, 10 November 2020 (UTC)
  • 11, or (in descending order of preference) 12, 15, or 16 as second to fourth choices. See my comment above about bikeshedding. We have better things to do than templatize a bunch of nit-picking options few people will ever care about or use, like plurality or punctuation changes. I initially favored 15 and 16 over 11 and 12 because more sources are never forbidden, and we are not doing any kind "References" to "Reference" conversion in actual article headings if only one reference happens to be present. And "Reference" sounds like an instruction. However, it later occurred to me that "ref." is equally an abbreviation of "references" as of "reference"; it is not mandatory to stick an s on the end of an abbreviation of a plural. Frankly, this stuff just does not matter. We need not have RfCs about stuff like this until attempts to WP:BOLDly normalize things turn into otherwise unresolvable disputes.  — SMcCandlish ¢ 😼  05:47, 20 October 2020 (UTC); rev'd 13:36, 14 November 2020 (UTC)
    Out of curiosity, why would you favour the s in parentheses in your second choice but not your first? 207.161.86.162 (talk) 05:41, 5 November 2020 (UTC)
    Wasn't intentional. I've revised.  — SMcCandlish ¢ 😼  03:03, 10 November 2020 (UTC)
  • 10, 11, or 15 are all acceptable. They're nice and short and the period makes clear it's an abbreviation. Make it a template called {{ref heading}} or something to ensure consistency. – Anne drew 15:19, 22 October 2020 (UTC)

Outcome

Hmm, well this wasn't quite as definitive as I'd hoped. However, I do find 207.161.86.162's point about some British English articles not using periods persuasive, so I built that into the template as a non-default option but otherwise took the coder's prerogative and designed it as I believe it should be. Feel free to check out the result at {{refh}}. I'll start introducing it to a few pages (conservatively for now, meaning not changing any pages that don't already use the template's exact format). The nice thing about it being template-ified is that if wiser minds than us come along at some point and decide we did this wrong, changing it will be as simple as changing the template, whereas right now it's not an option. {{u|Sdkb}}talk 03:08, 12 November 2020 (UTC)

@Sdkb: Perhaps I wasn't sufficiently clear. My concerns about periods in British English only applied in the event we picked "Refs", not "Ref". Without the "s", a period would still be used in British English (outside of journalistic and less formal writing, as pointed out by SMcCandlish) and would still be necessary to conform to MOS:POINTS. 207.161.86.162 (talk) 04:49, 12 November 2020 (UTC)
Oh oops, I didn't read closely enough. I'll modify to remove that option. {{u|Sdkb}}talk 05:01, 12 November 2020 (UTC)

List layout prose example

Just reading this stuff to get myself ready for working on featured articles, so good work! However, I have a problem with an provided example, specifically in this section. The argument is that prose makes clearer certain information whereas a list can not, and the example is a list that starts with the intro text: "20th-century architecture of New York City." But what if only the intro text needed to be clearer and the list would work? What if instead of "20th-century architecture of NEW YORK CITY?!!!!" (sorry, had do that Pace Foods commercial reference here), it was "The 20th-century architecture of New York City includes numerous icons of architecture, such as." Furthermore, what if each item listed included a description of it on the same line (as there are those descriptors in the prose example)? I agree with the message, but I think another editor would have similar questions, so clarification may be needed here. Any thoughts? HumanxAnthro (talk) 16:34, 28 February 2021 (UTC)

Guideline for lists of people

Is there a guideline for what should be included (apart from the person's page link obviously) in each entry of a list of people? Is there a limit to what can be included, for example, in a list of alumni of a college, for a person's entry, can we add birth year, death year, profession, birth place, nationality, nick names, etc.? Jay (Talk) 12:18, 4 July 2021 (UTC)

  • I think it's going to be hard to give a universal answer here. It really depends on the individual circumstances. If the list is something like List of people born in international waters, then year of birth is a highly salient piece of information. OTOH year of birth is not very salient for a list like List of Nobel laureates in Physics. Another consideration is whether the people in the list are all going to be notable - if so, then you can probably be a bit more conservative in what information you include, since readers will be able to click through to a person's article to get more details. Colin M (talk) 18:35, 4 July 2021 (UTC)
Years ago several editors worked hard to come up with guidelines on how best to write these sections/articles. Not all are in agreement and there never was a complete consensus. Those of us in agreement wrote the following guidelines: Notable people section of the WikiProject Cities/US Guideline For the best example of a top quality list, see the List of people from Park Ridge, Illinois. Dkriegls (talk to me!) 22:36, 1 December 2021 (UTC)

Tables vs. Lists

​I'm writing a new article about someone who has published 20+ books and articles. Should I do it as a table as shown in this article​: Bernard_Lewis_bibliography​ or as a bullet point list, as I see in many places. Thank you. Steal the Kosher Bacon (talk) 05:32, 28 November 2021 (UTC)

When it comes to how we present lists of items, my oppion is to always default towards tables. There is almost always more information than just the items and their descriptions (bullet list style). Creating tables allows the reader to quickly assess that additional information in a structured way. Be it finding publication dates, publisher information, or ISBN#. Dkriegls (talk to me!) 22:40, 1 December 2021 (UTC)
With all due respect to Dkriegls, I tend to default to "lists", as we seem to overuse (and misuse) tables in Wikipedia. Specifically, if we have a bunch of items but not much to say about them, then a bullet (or maybe numbered) list is the right choice. Too often we have a one-column table, but that's really just a list with rectangular borders. However, when we have a lot of cross-referenced info, like engine ratings, distance from the Sun, volume in both gallons and litres, political parties of the candidates and the votes they received, etc., then a table is surely the way to go.
For just a bibliography, I would lean to the basic list of books, as in the main examples at MOS:LISTSOFWORKS. No need for separate columns like publisher or year of publication.
Sorry if this is unhelpful, as you now have two editors pointing you in opposite directions. It's not our intention to confuse you! — JohnFromPinckney (talk / edits) 02:43, 5 December 2021 (UTC)
And for a bibliography, if you do want publisher, date etc. you can always cite templates, see for example Steve Jones (biologist)#Publications (although personally I would use |author-mask=2 on the third entry and all subsequent). --Redrose64 🌹 (talk) 08:48, 5 December 2021 (UTC)

Thank you all! Steal the Kosher Bacon (talk) 08:44, 7 December 2021 (UTC)

Request for comment on line breaks between term and definition in description lists

Are line breaks between term and definition in description lists mandatory or optional? fgnievinski (talk) 03:30, 17 January 2022 (UTC)

The previous discussion is linked from my vote above. fgnievinski (talk) 01:04, 23 January 2022 (UTC)
Thank you for your clarification about line breaks in the common ": term; definition" ”; term: definition" source code markup. The request for comment is concerned with an alternative way of defining a description list, such that a line break wouldn't be produced between term and description in the output HTML rendering. Namely: "* term: description", as used in, for example, Wikipedia#Methods of access. fgnievinski (talk) 01:04, 23 January 2022 (UTC)
It's the other way around: ; term : definition. --Redrose64 🌹 (talk) 22:33, 23 January 2022 (UTC)
Thank you, I've corrected the typo. Please let me know in case you have any objections to the absence of line breaks between term and description, as used in Wikipedia#Methods of access. Thanks! fgnievinski (talk) 23:01, 23 January 2022 (UTC)

This RFC is poorly named/worded. Opener is requesting comments about the style of bullet lists with bolded terms at the beginning at the each item, that would display/render as such (perhaps without the bullets in front):

Displayed Wikitext
  • Term 1: a description of 'term 1'.
  • Term 2: a description of 'term 2'.
* '''Term 1''': a description of 'term 1'.
* '''Term 2''': a description of 'term 2'.

Logically, this is a definition list. But it uses manual bold-face on the "terms", and doesn't semantically mark up the parts with <dt> and <dd>. It's possible to create a template with CSS TemplateStyles to create a sort of "inline deflist" (for lack of a better name), and using such a template it's even possible to use the wikitext (;/:) definition list markup. But it's probably better to extend {{glossary}} with TemplateStyles and an optional |inline-terms=yes parameter to achieve it. Personally, I'd like to have an "inline deflist" template (or option to {{glossary}}) (with default hanging indent for the first line).  — sbb (talk) 19:05, 24 January 2022 (UTC)

@Sbb: a suboptimal solution is described here: Wikipedia:Manual_of_Style/Glossaries#Bullet-style. I agree the ideal solution would involve HTML's dl/dt/dd. Unfortunately, the CSS styling doesn't seem trivial to achieve: [1]. Plus, I'm not sure if the mobile app would support well arbitrary styles? fgnievinski (talk) 23:38, 26 January 2022 (UTC)

Sentence case is used for around 99% of lists on Wikipedia.

What's the other 1% using? Lalaithan (talk) 17:57, 31 May 2022 (UTC)

List refs

I'm planning to add some additional text at WP:LISTVERIFY regarding the use of references in navigational lists. I've seen several cases where experienced editors are confused about this, instead expecting unnecessary inline citations. I feel it would be very useful for it to be written down, clarifying that WP:MINREF is beneficial and standard practice in these situations.

  • Proposed clarification
"In navigational lists, where a valid reason for inclusion can be easily verified from the sources contained in the linked article, inline citations are not a requirement. This prevents duplication of referencing effort and keeps navigational lists clear of additional clutter"

Thoughts? Zindor (talk) 12:18, 4 June 2022 (UTC)

Approve - We have been doing this in the "List of xxxx albums" series for a few years now to keep list size down. What I like best about the statement is that instead of just stating that no citation is required if there is a linked article, it states that verification from sources in the linked article is part of the process. Mburrell (talk) 18:37, 4 June 2022 (UTC)

Numbering offices

Is an editor suppose to be consistent, if an editor adds or removes numberings from politicians' bios, that are within the same group? For example: If one removes "fifth" & "5th" from the bio body & infobox of a prime minister of Andorra. Shouldn't that editor make the same deletions for all the prime ministers of Andorra? GoodDay (talk) 22:12, 24 July 2022 (UTC)

Yeah I suppose so, ideally, but it's unlikely to happen. You're talking about, an editor comes across an article about a particular Prime Minister of Andorra, and (say) changes the infobox image caption from "Prime Minister of Andorra" to "Fifth Prime Minister of Andorra" or vice versa, thus making it different from all the others?
The editor in question may have only been interested in that particular Prime Minister, saw "Fifth Prime Minister of Andorra" and thought that was silly and wanted truncating, and did so -- or vice versa. You can't necessarily expect her to then go to all the the Prime Ministers of Andorra (or indeed of world history) and make the same change.
So it's just an unhelpful edit. Just roll it back would be my advice. Cheerfully pointing out to the editor the loss of consistency her edit caused and that it had to be fixed might help her to learn and grow, if you like. Herostratus (talk) 07:06, 26 July 2022 (UTC)
Well @Mewulwe: has a habit of doing this, usually without an edit-summary. I'm not saying Mewulwe's deletions are incorrect. Mew, just chooses (and I've pointed it out to Mew, many times) to ignore the predecessors & successors bios, when Mew does it. Thus throwing the list of bios 'out-of-sync'. GoodDay (talk) 07:44, 26 July 2022 (UTC)

Correcting one error does not oblige one to correct all similar errors elsewhere. It's absurd to say consistency is a higher value than accuracy to the point that one should rather be consistently wrong than partially wrong. Unfortunately GoodDay has a habit of doing this, adding bogus numbers without any knowledge of their validity, just mindlessly extrapolating stuff from one Wikipedia article to the next. Mewulwe (talk) 08:27, 26 July 2022 (UTC)

If you had deleted the numberings from all the Andorran prime ministers bios, in the first place? I wouldn't have added the numberings afterward. That's why, when I have to clean up bios because of your 'one' delete style. I always give you credit with an edit-summary that says "per Mewulwe" That way if anybody tries to restore the numberings? they'll know who to see about it, first. Same thing with the Leaders of the Islamic Emirates of Afghanistan bios. Thus my advice to @Tartan357:, not to reverse your deletions. GoodDay (talk) 08:31, 26 July 2022 (UTC)

Embedded lists & notability

As far as I know, it is correct to remove unlinked or red-linked items out of an embedded list, as those items are deemed non-notable. But is that the case, or can every item related to the subject of the article be added, sourced or unsourced, with or without article? The Banner talk 09:06, 8 September 2022 (UTC)

Whether they should be removed or not from embedded lists depends on how the list was set up. Some lists like lists of school alumni likely should remove non-bluelinks. But there's definitely room in P&G for lists that include non-blue linked items, as long as the item's inclusion in the list is sourced. However, that needs to be established by consensus for that list. Lists where that type of approach can draw self-promotion should likely be avoided (eg like lists of alumni). --Masem (t) 12:26, 8 September 2022 (UTC)
In this case, it is in relation to artists of a record label. The Banner talk 12:37, 8 September 2022 (UTC)

What is the "proper" way to annotate a list?

I was looking at WP:BIB about how to annotate a bibliography, and it reads Annotations should be indented (by adding a colon in front) and cited with a reliable source. An article making use of this is List of important publications in geology which has the following:

*{{cite book|last1=Goldschmidt|first1=Victor|author-link=Victor Goldschmidt |title=Geochemische Verteilungsgesetze der elemente|year=1923–1938 }}
::Laid the foundations of [[geochemistry]], including the [[Goldschmidt classification]] elements.
*{{cite book|last1=Faure|first1=Gunter|author-link=Gunter Faure |title=Principles of Isotope Geology|year=1977|publisher=Wiley|location=New York|isbn=9780471256656}}
::A highly cited guide to the use of isotope geochemistry in solving geological problems, and the methods involved. Has been cited more than 3200 times. A second edition was published in 1986. A third edition, with Teresa M. Mensing, was published in 2005, under the title ''Isotopes: Principles and Applications''.

  • Goldschmidt, Victor (1923–1938). Geochemische Verteilungsgesetze der elemente.
Laid the foundations of geochemistry, including the Goldschmidt classification elements.
A highly cited guide to the use of isotope geochemistry in solving geological problems, and the methods involved. Has been cited more than 3200 times. A second edition was published in 1986. A third edition, with Teresa M. Mensing, was published in 2005, under the title Isotopes: Principles and Applications.

However MOS:INDENTMIX says But ☒N don't do this (switch type from bullet list to description list). I like the look of one bullet point for item, with the annotation being indented and without a bullet point; compare the "right" way:

  • Goldschmidt, Victor (1923–1938). Geochemische Verteilungsgesetze der elemente.
  • Faure, Gunter (1977). Principles of Isotope Geology. New York: Wiley. ISBN 9780471256656.
    • A highly cited guide to the use of isotope geochemistry in solving geological problems, and the methods involved. Has been cited more than 3200 times. A second edition was published in 1986. A third edition, with Teresa M. Mensing, was published in 2005, under the title Isotopes: Principles and Applications.

To me this seems messy as now there is no longer a one-to-one correspondence between bullet point and list item. Is there a way to recreate the look of the indended, bullet-less annotations in a way that still adheres to MOS:LIST? Thanks. Umimmak (talk) 04:51, 4 November 2022 (UTC)

@Umimmak: You should be doing this:
*{{cite book|last1=Goldschmidt|first1=Victor|author-link=Victor Goldschmidt |title=Geochemische Verteilungsgesetze der elemente|year=1923–1938 }}
*:Laid the foundations of [[geochemistry]], including the [[Goldschmidt classification]] elements.
*{{cite book|last1=Faure|first1=Gunter|author-link=Gunter Faure |title=Principles of Isotope Geology|year=1977|publisher=Wiley|location=New York|isbn=9780471256656}}
*:A highly cited guide to the use of isotope geochemistry in solving geological problems, and the methods involved. Has been cited more than 3200 times. A second edition was published in 1986. A third edition, with Teresa M. Mensing, was published in 2005, under the title ''Isotopes: Principles and Applications''.
In this way, you still have one bulleted list, but each entry contains a sub-list. --Redrose64 🌹 (talk) 20:42, 4 November 2022 (UTC)

Prose vs. List

I was surprised by the lack of direction in assessing lists vs. prose. I recently had someone revert an edit where I had changed a paragraph to list, while maintaining most of the prose. The paragraph was simply 4 examples in a row, each a sentence of almost identical form. The reverter was puritanically against embedded lists.

I am particularly confused by the comparison made in MOS:PROSE, which contrasts two completely different ideas (list for emphasis):

  • condensing content to only the objective, uniform info (names and dates)
  • formatting list content to be more easily read.

These are independent considerations! The prosaic example could easily be reformatted to both be read as prose (uncondensed) and also allow the elements to be easily identifiable and readable and avoid a WP:SEAOFBLUE (plain/bullet list), which makes the prose quite impossible to separate into the individual elements. A list does not require that the context of the elements be removed, as was shown in the example. The prosaic paragraph of buildings is a list forced into prose by stating random facts about some of the buildings, and ignoring completely others. It could be expanded into better prose that references some of the buildings, but that would take more work. Listifying the paragraph, either with or without some supporting facts like architect, style, etc. for each of the buildings, and while maintaining or rejecting an overall sentence structure seems like the obvious move, depending on what the parent article is (i.e. historical vs. architectural context). For scientific articles, where prose does not connect the individual list elements, a conversion to list formatting is even more obvious.

So why are the two 'list' concepts conflated? Any why do people hate lists? Curran919 (talk) 14:49, 30 November 2022 (UTC)

Clarification needed

If an editor is able to give clarification at Talk:Fort Albany First Nation#Notability of council list it would be appreciated. There is a dispute about whether three lengthy lists of mostly non-notable names should be added to the article. Thank you. Magnolia677 (talk) 15:36, 6 December 2022 (UTC)

Anchor called 'Comma-separated lists'

Just below section Horizontal lists there is an Anchor called 'Comma-separated lists'. I can think of a good reason why the Anchor is in the section. I cannot think of a good reason why the Anchor is there in the section.

The 1st visible object in the section is a short sentence. The 2nd visible object in the section is a table of examples. The 1st row of the table is an example of a Comma-Separated List. Which seems to me like a good place for an Anchor called 'Comma-separated lists'.

Just above the section seems like a good place for an Anchor too. But not an Anchor called 'Comma-separated lists'. An Anchor called 'Horizontal_lists'. The same name as the Anchor that the Wikitext Renderer automatically generates from the section title.

Probably there would forever be 2 identical Anchors marking the same place in the Wikipedia:Manual of Style/Lists. But in case somebody changed the section title, links to the section would still work.

I propose 2 changes

  1. Move Anchor called 'Comma-separated lists' to just above 1st row in example table (not counting header row)
  2. Insert Anchor called 'Horizontal_lists' just above section title


Objections? 108.36.229.19 (talk) 21:05, 26 February 2023 (UTC)

Or do they have to have an article showing notability here? Doug Weller talk 16:57, 17 March 2023 (UTC)

While I always thought we should stick to linking only to English language Wiki if working in the English language, there is a mechanism for linking to other language Wikis. Per H:FOREIGNLINK, the best practice is to use the template the best practice is to use the template {{interlanguage link}} which gives both a redlinked English link and a foreign language blue link, but hides the foreign language link if the English redlink turns blue when the article is created. See Template:Interlanguage link for the template documentation. Mburrell (talk) 20:56, 17 March 2023 (UTC)
Thanks, looks good. Doug Weller talk 21:18, 17 March 2023 (UTC)
The inclusion criteria for nearly all embedded lists, and many stand-alone lists, is that links must be to notable topics or sister projects. Many editors--myself included--remove non-notable links from lists (which would include links to foreign language Wikis). Magnolia677 (talk) 22:23, 17 March 2023 (UTC)
I agree that for stand-alone lists that I work with, the notability clause would have me remove foreign language Wiki links. I am opposed to foreign language links in general. I was just reporting that Wikipedia does have a mechanism for including them, but I would not want to encourage its use. Mburrell (talk) 01:19, 18 March 2023 (UTC)
@Magnolia677, per Many editors--myself included--remove non-notable links from lists (which would include links to foreign language Wikis). Am I to understand that "many editors" automatically consider links to foreign language Wikis to be "non-notable" in spite of what is said at Wikipedia:Wikimedia_sister_projects#When_to_link and also in spite of the fact that notability is not mentioned even one time at Help:Interwiki linking or Help:Interlanguage links? So, I'm wondering where you and these many editors are getting the idea those aren't notable if it isn't mentioned in any documentation that I can easily find? Huggums537 (talk) 01:29, 23 March 2023 (UTC)
I'm only asking because you insisted links must be notable or sister projects. So, I'm also wondering why these links would not still qualify to be in a list under the sister project provision even if they were not notable since you were quoted as saying they must be one or the other. It seems to me that removing them under one provision while ignoring the other is nothing but an excuse to remove them simply because you don't like them for some reason or another. The template Mburrel describes seems like a reasonable way to encourage turning undesirable pages into good pages... Huggums537 (talk) 01:37, 23 March 2023 (UTC)
Some guidelines, such as WP:CCSG, specifically state that additions to notable people lists "Include only people with a Wikipedia article". This criteria would therefore exclude interlanguage links, because sister projects are external links, per WP:ELMAYBE. This may need more clarification. Magnolia677 (talk) 11:31, 23 March 2023 (UTC)
Ok thanks. I've looked into this deeper and found some rules governing what you are talking about at: WP:MOSSIS. However, I still have an extremely grave concern about "many editors" removing every single foreign language link on the basis that they are "not notable". According to the information you just provided to me, only some list articles use the "Wikipedia articles only" standard. So, by that logic these links should only be removed per WP:ELMAYBE or only if the list happens to use the standard that restricts the list to Wikipedia articles only because there is an actual difference between a non-notable entry and one that doesn't have an article. A red link, text link, disambig, or redirect could be notable, and even have references attached, but not yet have the article. It is technically incorrect to remove all of these links on the basis of "non-notable" when what you really mean is that they don't have a Wikipedia article. It seems like "many editors" are just using the "non-notable" moniker as an excuse to remove items to get around lists that don't use the "Wikipedia articles only" standard, but it should be obvious how this is a harmful practice to Wikipedia. I don't understand how good editors resort to these kind of harmful ways when WP:ELMAYBE and WP:MOSSIS are good enough to quote for removing all of them without being harmful. Huggums537 (talk) 05:51, 24 March 2023 (UTC)
I mostly work on articles about Canadian and US cities, and typically, notable people are removed if their name does not point directly to an English Wikipedia article. This would include redlinks, dablinks, links to a band or to a list of Survivor contestants, and so forth. Experienced editors often overlook a name without an article, if accompanied by a reference demonstrating obvious presumed notability (eg. a state senator). Inclusion on embedded lists frequently ends in disputes. I would support inclusion criteria for embedded lists. Magnolia677 (talk) 08:43, 24 March 2023 (UTC)

Article in bad need of MOS:DLIST cleanup

 – Pointer to relevant discussion elsewhere.

Please see Talk:Singular they#MOS:DLIST. The short version is that the article is abusing : (= HTML <dd>) description/definition/association list markup dozens of times as a visual indentation mechanism, and needs cleanup to use {{block indent}} or (where actual quotations are used) {{blockquote}}. And, where DLISTs are appropriate, it should be using proper ; with : lists, not mangled * with : markup. But I'm not finding I have the time and patience to do it all.  — SMcCandlish ¢ 😼  11:09, 28 October 2023 (UTC)

Fixed the lion's share of it. Remsense 19:52, 28 October 2023 (UTC)

WikiProject list discussion

There is a discussion at the WP:FRAT talk page about list creation/inclusion which could use outside input. Please join in the conversation here. Primefac (talk) 10:45, 9 May 2023 (UTC)

This seems to have pretty quickly archived to Wikipedia talk:WikiProject Fraternities and Sororities/Archive 9#Including list of fraternity/sorority founders., without a clear resolution. But there have been later follow-up discussions about lists there.  — SMcCandlish ¢ 😼  03:15, 14 November 2023 (UTC)

Single reference for every list item

Here is a humdrum example of a common phenomenon: A list ("Festivals") with a single reference ("[4]") atop, and presumably for, all the items. Let's avoid what's irrelevant to the question I'm about to pose, and instead assume that the referenced source is reliable, and that it does indeed back up the appropriateness of each list item. A reference index floating by itself looks wrong (to me). An obvious alternative is to repeat the (named) reference for every list item; easily done, of course but the result would look lame-brained (to me). Another obvious (but worse) alternative would be to append the reference to the last item; but then it would be unclear whether this reference was supplied for the list as a whole or merely for its last item. And one could supply an introductory sentence ("According to Taiwan Docs,[4] the film has been shown in the following festivals:"), but this adds flab. Is there a better way of referencing an entire list? -- Hoary (talk) 01:23, 14 November 2023 (UTC)

For most lists (any that could be subject to changes in entries), repeat the ref for every list item, no matter how "lame-brained" you think it looks; this isn't VisualDesignPedia. Use shorthand <ref name="foo" /> format or {{sfn}} or some other shorthand for entries after the first one; obviously don't repeat the entire citation over and over again. Every list item should be sourceable, various of them will accrete additional citations over time, and more people will add new entries with (we certainly hope) other citations to back them up. The exception would be when it's a list of a permanently fixed number of things that do not change (e.g. already-complete list of presidents of a company that no longer exists). In such a case, have an intro sentence/phrase above the list with a single citation at the end of that sentence/phrase.  — SMcCandlish ¢ 😼  01:44, 14 November 2023 (UTC)
Thank you, SMcCandlish. Well, even aside from its commendable adaptability, that's clearly preferable to this approach. -- Hoary (talk) 02:00, 14 November 2023 (UTC)
Yeah, that's no bueno, since we don't put templates and other complex code inside headings.  — SMcCandlish ¢ 😼  02:59, 14 November 2023 (UTC)
You name the atrocity, I've probably perpetrated it in my time. -- Hoary (talk) 04:37, 14 November 2023 (UTC)
Oh, sure. Been here since something like 2005, and probably broken everything at some point. I even had templates in my sig at first, despite that being a big no-no I hadn't read about yet. Heh.  — SMcCandlish ¢ 😼  06:17, 14 November 2023 (UTC)

 You are invited to join the discussion at Wikipedia talk:WikiProject Lists § Should Template:Dynamic list be used in sections that also have Template:Main?. {{u|Sdkb}}talk 21:32, 2 January 2024 (UTC)

Bullet-space, or not bullet-space, that is the question

I work on a lot of disambiguation pages and name lists and alumni lists, which sometimes involves copying lines from, for example, a given name page to a surname page, or from a name page to an alumni list. These are typically bulleted lists, which may either be formatted as:

*Foo
*Bar
*Foobar

or:

* Foo
* Bar
* Foobar

The outcome is the same, so I am wondering if there is any technical reason who one should be preferred over the other. Frankly, I would prefer to have a set house style and conform pages to it generally. It is annoying to copy lines to multiple relevant lists and to have to edit that space every time to conform to the variations of individual pages. BD2412 T 21:54, 7 July 2023 (UTC)

Every time you use a bulleted list without the space, a fairy dies. Your choice of course — GhostInTheMachine talk to me 22:42, 7 July 2023 (UTC)
@GhostInTheMachine: I'm fine with having the space if someone can explain to me what purpose it serves. Is it just to make it easier to parse the wikitext? Should we have a preference expressed in the MOS? BD2412 T 00:40, 8 July 2023 (UTC)
The parser does not care about the space – you could have no space or five spaces and the HTML created by the parser is exactly the same. It is just an aesthetic thing and a kindness to the next editor – having a space after the asterisk helps visually when you are editing the source. Maybe the MOS could say something about that, but I don't see it as being important enough to be stated as policy — GhostInTheMachine talk to me 08:40, 8 July 2023 (UTC)
There is no technical reason to prefer one over the other. The difference is only when editing using the source editor, and even then it is purely aesthetic. If you are coming across people who are routinely adding spaces where there were none before (or removing them), that is the sort of thing that WP:COSMETICBOT and WP:AWBRULES rule 4 both discourage. --Redrose64 🌹 (talk) 09:53, 8 July 2023 (UTC)
Maybe we could compromise and use halfspaces? Eg
*&thinsp;Foo
*&thinsp;Bar
*&thinsp;Foobar
--Herostratus (talk) 11:32, 8 July 2023 (UTC)
Now that certainly would make a difference to the rendered output. But why would we want to do it anyway? --Redrose64 🌹 (talk) 12:20, 8 July 2023 (UTC)
I just want consistency. If there is no reason to have the spaces, then eliminate them (they do affect the page size, which theoretically affects loading time). If there is a reason to have them, such as improved readability while editing, then require them. BD2412 T 20:27, 14 July 2023 (UTC)
You won't get consistency. First, there is no reason to either eliminate or to require them; second, most people simply won't care; and third, the sheer number of pages presently using (i) spaces; (ii) no spaces; (iii) either one indiscriminately means that the amount of work necessary to harmonise two-thirds of pages to match the other third would simply not be worth the bother. Remember that every edit creates a new version of a page and all old versions are preserved, so editing a 10,000-byte page to remove ten spaces doesn't decrease the database size by 10 bytes, it increases it by 9990 bytes for the page text, plus all the entries in the revision and link tables. Any intended net saving of space is always a net loss of space.
The spaces after the asterisks only affect the page size when opening the page or section for editing, and the contents of the edit window form a surprisingly small amount of the data that is served to your browser when you do that. So the addition or removal of a few spaces won't make any measurable difference. When you save the edit, as GhostInTheMachine pointed out, the HTML created by the parser is exactly the same - here is the HTML from your original two examples:
<ul><li>Foo</li>
<li>Bar</li>
<li>Foobar</li></ul>
and
<ul><li>Foo</li>
<li>Bar</li>
<li>Foobar</li></ul>
the spaces simply do not appear. --Redrose64 🌹 (talk) 14:20, 15 July 2023 (UTC)
"Is it just to make it easier to parse the wikitext?" Yes. Some editors prefer it, and that's the only reason, but it's not a compelling reason to change the style. "Should we have a preference expressed in the MOS?" No, for WP:MOSBLOAT reasons, and more in particular because people have repeatedly proposed this and several other forms of "coding standards" (like ==Foo== versus == Foo ==) be worked into MoS, and the result is always a consensus against the idea, because MoS exists for ensuring quality and consistent and understandable content for the readers (and secondarily for reducing editorial conflicts about styling that content), but this sort of thing isn't styling the content, having no effect on what editors see, or any accessibility effect on editors or readers, possibly the only other reason we'd care about a code-formatting matter. There's just not a consensus to prefer one style over the other. To the extent anything in MoS would apply to this stuff, it would be MOS:STYLEVAR: if there are two acceptable styles, don't arbitrarily change from one to the other. For my part, when I encounter messy lists, I normalize to which ever style already dominates in the page. If there is no clear "winner", and just a really random mess, I usually normalize to the spaced style as marginally more readable for editors. But only if making a more substantial improvement in the same edit.  — SMcCandlish ¢ 😼  03:12, 14 November 2023 (UTC)
It's to make the wikitext more human-readable. The software parser doesn't care.
Eventually, it will get mostly standardized as whatever the visual editor is doing, which is (presently, but, if memory serves, not originally) adding a space. WhatamIdoing (talk) 07:14, 9 January 2024 (UTC)