Shortcut

Can lists of people include links to people on other language Wikis?[edit]

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

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)[reply]
Thanks, looks good. Doug Weller talk 21:18, 17 March 2023 (UTC)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

WikiProject list discussion[edit]

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)[reply]

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)[reply]

Bullet-space, or not bullet-space, that is the question[edit]

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)[reply]

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)[reply]
@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)[reply]
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)[reply]
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)[reply]
Maybe we could compromise and use halfspaces? Eg 
* Foo
* Bar
* Foobar
--Herostratus (talk) 11:32, 8 July 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
"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)[reply]
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)[reply]

Article in bad need of MOS:DLIST cleanup[edit]

FYI
 – 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)[reply]

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

Single reference for every list item[edit]

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)[reply]

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)[reply]
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)[reply]
Yeah, that's no bueno, since we don't put templates and other complex code inside headings.  — SMcCandlish ☏ ¢ 😼  02:59, 14 November 2023 (UTC)[reply]
You name the atrocity, I've probably perpetrated it in my time. -- Hoary (talk) 04:37, 14 November 2023 (UTC)[reply]
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)[reply]

single-item lists[edit]

The template ((infobox cocktail)) automatically forces a bulleted list for its main-alcohol parameters. Bulleted lists in infoboxes aren't unheard-of, though rare. However, that template forces a bullet even for single entrants, making the oxymoronic single-item list. Given there is no actual list created, should that template be invoking list markup for single variables? — Fourthords | =Λ= | 22:27, 29 December 2023 (UTC)[reply]

What do you mean specifically? Can you point to an usage of the template where this is visible? Gawaon (talk) 04:39, 30 December 2023 (UTC)[reply]
Sure, easy-peasy. In the infobox's implementation at mojito, there's a bulleted list with one item (rum). Given how the bulleted-list markup interacts with other variables like scrapers, screen readers, and more, are there any technical, grammatical, accessibility, or stylistic problems caused by a 'list' that then only has one entrant? — Fourthords | =Λ= | 06:00, 30 December 2023 (UTC)[reply]
Yeah, I agree that looks odd. I'd say it should just be a plain wikilink in such a case, not a list. But ultimately you'll have to discuss that with the template authors. Gawaon (talk) 06:18, 30 December 2023 (UTC)[reply]
Fixing that is a simple #if test to check for multiple parameter values. And it should probably use an unbulleted list, since bulleted ones are unusual in infoboxes and waste space in them. The more general ingredients list lower in the i'box might sensibly use a bullet list, but it could be CSS kerned to waste less horizontal space.  — SMcCandlish ☏ ¢ 😼  00:28, 3 January 2024 (UTC)[reply]
A "bullet" (i.e., Unordered) list with no bullet at all would be better, as the list of recipe ingredients would look like a list of recipe ingredients. Try Template:Plainlist. WhatamIdoing (talk) 07:21, 9 January 2024 (UTC)[reply]
Made that recommendation in the template documentation. We'll see if it sticks.  — SMcCandlish ☏ ¢ 😼  10:30, 9 January 2024 (UTC)[reply]

Discussion at Wikipedia talk:WikiProject Lists § Should Template:Dynamic list be used in sections that also have Template:Main?[edit]

 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)[reply]

Categories