Wikipedia talk:Manual of Style/Lists

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search

Wikipedia:Manual of Style/Stand-alone lists#Selection criteria[edit]

Since this the "Further information" linked in two sections covering Stand-alone lists and 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 obvious selection criteria/inclusion criteria/membership criteria and Manual of Style/Embedded lists gives no guidance at all on selection criteria, not even a link to Wikipedia:Manual of Style/Stand-alone lists#Selection criteria. Fountains of Bryn Mawr (talk) 19:04, 24 August 2016 (UTC)

Wikidata lists[edit]

If you are interested in future list generation using Wikidata, please consider taking a look at d:Wikidata:List generation input and providing any comments on d:Wikidata talk:List generation input. --Izno (talk) 11:46, 1 September 2016 (UTC)

Can lists contain elements without notability?[edit]

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[edit]

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 / talk 11:53, 26 January 2017 (UTC)

@Jennica: To which section are you referring? It sounds like you may not have heard the entire story. Semicolons are appropriate for use with description (definition, association) lists. Yes, in other uses they are incorrect, but in that use they are not. --Izno (talk) 12:24, 26 January 2017 (UTC)
@Izno: - I know it's appropriate for lists. Perhaps this isn't a talked about issue, I'm not sure of the statistics of screenreaders users but we have had a conversation about it over at Wikipedia_talk:Manual_of_Style/Accessibility#Screen_readers and ever since then I've tried not to use the semicolons for bold markup. I thought I'd bring awareness to it.--Jennica / talk 12:33, 26 January 2017 (UTC)
Semicolons plus colons are appropriate for definition lists and glossaries per MOS:DEFLIST and I've never read any suggestion that it might interfere with accessability issues. -- Michael Bednarek (talk) 14:28, 26 January 2017 (UTC)
The issue is when editors use semicolons to create faux headings, not when used in definition lists. olderwiser 14:46, 26 January 2017 (UTC)
@Bkonrad: - but this still affects screenreader users, right?--Jennica / talk 07:31, 29 January 2017 (UTC)
There's nothing wrong in the rendition by screenreaders of properly constructed definition lists. -- Michael Bednarek (talk) 09:59, 29 January 2017 (UTC)
Precisely. The only issue is when a ";" is used by itself, i.e., when there is no definition list following. olderwiser 12:28, 29 January 2017 (UTC)


Should the list of CUTA members be removed as it is incomplete and the information is directly from the organization's website. Daylen (talk) 04:18, 25 July 2017 (UTC)

@Daylen: Removed from where? --Redrose64 🌹 (talk) 10:05, 25 July 2017 (UTC)
@Redrose64: Canadian Urban Transit Association#Members (linked above). Daylen (talk) 20:46, 25 July 2017 (UTC)
@Daylen: Yes, it's linked above. But this is the WP:TP for discussing improvements to the page Wikipedia:Manual of Style/Lists, so your post gave the impression that the list was also in the MoS page itself. Since you have now clarified that this is actually a question about the content of an article, the first place to ask is the talk page of that article, i.e. Talk:Canadian Urban Transit Association. You can attract more attention to that by dropping a note at the talk pages of interested WikiProjects, i.e. Wikipedia talk:WikiProject Canada, inviting them to discuss at Talk:Canadian Urban Transit Association (in accordance with WP:MULTI). --Redrose64 🌹 (talk) 07:19, 26 July 2017 (UTC)

Space in list items[edit]

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.

@Chris the speller: I see you asked this once before, but there was no answer. Kendall-K1 (talk) 21:12, 31 October 2017 (UTC)

* ABC versus *ABC? Both forms work. The former is generally helpful for readability. --Izno (talk) 21:17, 31 October 2017 (UTC)
Yep. The are equivalent. It's more readable with the space, but it has no effect on displayed output, so it is subject to WP:COSMETICBOT.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  02:34, 1 November 2017 (UTC)
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); ref phab:T157418. --Izno (talk) 12:46, 1 November 2017 (UTC)
Zoiks. Glad you're on that, Izno.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  17:10, 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)
Though do be aware that cosmetic edits are permissible if they're done along with non-cosmetic ones.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  17:10, 1 November 2017 (UTC)
The edit that got me curious about this had hundreds of cosmetic changes and maybe one non-cosmetic. [1] Kendall-K1 (talk) 19:57, 1 November 2017 (UTC)
Obviously one not cosmetic change is enough. However the point here is if that space is recommended or just a matter of personal taste. Within Pywikibot the description of the cosmetic fix that insert that spaces contains the sentence This space is recommended in the syntax help on the English, German, and French Wikipedia. Is it true? BTW I agree that the readability is improved. -- Basilicofresco (msg) 06:55, 2 November 2017 (UTC)
I don't find anything about this at en: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 do nothing but that change. Personally, I think WP: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 beyond exactly and only what it constrains. It should be replaced with a narrower rule against bots making trivial changes that 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 of MOS: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. -- (talk) 21:13, 21 July 2018 (UTC)

Dynamic lists[edit]

Is 1963 in jazz a dynamic list? There's a lot of lists in Category:Dynamic lists that are specific to a past year, which cannot possibly be considered dynamic. I just wanted to make certain before removing the template from any of them. —Xezbeth (talk) 19:11, 6 November 2017 (UTC)

Linking in DLIST item names?[edit]

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)

Yes. This is covered at MOS:GLOSSARIES. It should be avoided for the same reason we avoid it inside headings.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  13:31, 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 at WP: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 at MOS: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)
It is in Template:Term/doc#Wiki-styling and linking of the term, but people would miss that if not using the template-structured glossary format, so it really should be in one or another of the MoS pages. I'll see about adding it to MOS:GLOSSARIES.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  15:15, 8 November 2017 (UTC)
Added to WP:Manual of Style/Glossaries#Linking, along with some notes on technical limitations.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  15:41, 8 November 2017 (UTC)
Also cross-referenced all these sections.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  16:13, 8 November 2017 (UTC)

Overhauled for logical flow[edit]

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 new MOS: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 behind WP: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 (at Wikipedia: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, per WP:BEANS and WP: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 in MOS:LISTGAPS. The extensive custom-coding examples under "Numbered lists" is probably copy-paste of material in Help: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 for MOS:TABLES.

 — SMcCandlish ¢ >ʌⱷ҅ʌ<  17:37, 20 December 2017 (UTC)

Completness of a list[edit]

A list of places in a certain region should be complete and the completness should be sourced, shouldn't it? List of places in Dorset is probably complete, but unsourced.Xx236 (talk) 12:56, 16 January 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)

Need help with color lists[edit]

There seems to be no way to correct the capitalization of the entries on List of colors: A–F. What am I missing? Primergrey (talk) 16:24, 8 February 2018 (UTC)

To regain control of the capitalisation, I think you would need to remove text-transform: capitalize from line 3 of both Template:Colort/1row and Template:Colort/2row. But as the names of colours are, I believe, proper nouns, surely they should always be capitalised? --RexxS (talk) 19:15, 8 February 2018 (UTC)
I'll try that when i'm home from work. Thanks. Primergrey (talk) 20:22, 8 February 2018 (UTC)
CSS color names are case-insensitive. --Redrose64 🌹 (talk) 23:21, 8 February 2018 (UTC)