Wikipedia talk:Short description/Archive 8

Archive 5

Archive 6

Archive 7

Archive 8

Archive 9

Archive 10

→

Archive 15

Adding tracking categories

@RexxS: would it be possible to add something like the following tracking categories, please?:

• Category:Short description matches Wikidata (ideally case-insensitive)
• Category:Short description is different from Wikidata
• Category:Short description with empty Wikidata description

This would help a bit with resolving some of the discrepancies that this forking off from using Wikidata descriptions directly has caused. Thanks. Mike Peel (talk) 17:47, 3 August 2020 (UTC)

@Mike Peel: I've created a module Module:SDcat that takes the local short description and returns one of the three categories you requested. I've added some documentation, and there are a few test cases at Module talk:SDcat. It can be called from within the Template:Short description where the local short description is available as a parameter, or from within another module which autogenerates a short description. It probably wants a bit of testing before deployment, but I'm sure I can leave that to some of our keen coders. Cheers --RexxS (talk) 22:25, 3 August 2020 (UTC)

@Mike Peel: To start the ball rolling, I've added the tracker to Template:Short description and created the category pages

• Category:Short description matches Wikidata (2,035,147)
• Category:Short description is different from Wikidata (4,072,821)
• Category:Short description with empty Wikidata description (158,205)

We should start to get some idea of what we have as the categories populate. Obviously, the modules that autogenerate the short description will need to be patched at some point, but I've written Module:SDcat to allow itself to be incorporated onto other modules quite simply. --RexxS (talk) 23:32, 6 August 2020 (UTC)

@RexxS: Thanks, that's very helpful! Mike Peel (talk) 23:33, 6 August 2020 (UTC)

@RexxS: without having looked at the module code, the categorization is currently case-sensitive, right? Can this be changed to complete case-insensitivity? ---MisterSynergy (talk) 08:34, 7 August 2020 (UTC)

Okay, turns out that the module is case-insensitive, but I was distracted by this bug (articles being categorized in both Category:Short description matches Wikidata and Category:Short description is different from Wikidata). ---MisterSynergy (talk) 08:53, 7 August 2020 (UTC)

I think that "bug" is more a feature, as it appears to identify articles with an automatically generated short description from the infobox which have had manually added a short description from Wikidata, and potentially other combinations where one is from Wikidata. The ones I checked are legitimate situations, where only the manually selected SD should be available to the API, and were arguably better for purpose in the opinion of the editors who added them. Cheers, · · · Peter Southwood ^(talk): 10:21, 7 August 2020 (UTC)

How are we supposed to get an overview of the differences when articles can have both different and matching descriptions at the same time? This does not make sense to me. ---MisterSynergy (talk) 10:47, 7 August 2020 (UTC)

What overview of differences are you looking for? · · · Peter Southwood ^(talk): 12:13, 7 August 2020 (UTC)

What Mike wrote above: discrepancies between the local descriptions and the central Wikidata descriptions. A short description can either differ from the central Wikidata value, or be case-insensitively identical. But not both at the same time, right? ---MisterSynergy (talk) 12:34, 7 August 2020 (UTC)

Two ways of looking at this.

1. The SD that is not visible to the API does not exist for your purposes
2. The SD that is not visible to the API does exist (which is why there are intersections between the categories - the "bug")

Which is more useful for your analysis? It may be possible for RexxS to apply his skills to filter for these cases. Cheers · · · Peter Southwood ^(talk): 15:36, 7 August 2020 (UTC)

@MisterSynergy: The problem with cases like Alberta is that the short description template is being called twice: once by the explicit short description which has the value "Province of Canada"; and once by {{Infobox province or territory of Canada}} which generates the value "Province in Canada". The Wikidata value is "province of Canada". As you can work out, when the first template call is made, it adds the category Category:Short description matches Wikidata. Then when the infobox calls the template with a different value, it adds the category Category:Short description is different from Wikidata as expected. What sort of behaviour would you suggest for these sort of situations when the template is called twice with different values, one matching and the other not matching? --RexxS (talk) 16:08, 7 August 2020 (UTC)

Well, effectively there is only one short description for this article, which per the page_props table is "Province of Canada" for Alberta (i.e. the explicit template call wins in this case). I assume that this value will be used whereever the enwiki short description is being put to use, and thus the categorization should be based on this value only. Problem is that this is probably pretty difficult to analyze with Lua; in general it also poses the question how the actual short description of an article is determined in case there are multiple explicit or implicit calls of the short description template. Particularly implicit calls can be pretty difficult to spot for unexperienced editors. —MisterSynergy (talk) 16:38, 7 August 2020 (UTC)

The last description found is used. This is not always ideal, as a specific hand-crafted description on line 1 can be overwritten by a generic template-generated version unless |noreplace= is used. Certes (talk) 16:49, 7 August 2020 (UTC)

noreplace should always be used in templates. If you have any examples of a template that doesn't that could be fixed very quickly. --Trialpears (talk) 16:51, 7 August 2020 (UTC)

One example is {{Year article header}} (so the description for 1984 is set to "1984", which might be mistaken for the book or the integer). Other such templates include {{Infobox dam}} and (perhaps correctly) several widely used index and list templates such as {{Plant common name}}, {{Ship index}} and {{Surname}}. Certes (talk) 00:56, 9 August 2020 (UTC)

@MisterSynergy: Unfortunately, Lua has no direct access to the Wikipedia API, so it can't read what is shown in page_props. I used the call to the short description template as a simple means of determining the value of the short description, but that obviously will lead to inconsistencies when the template is called multiple times with different values. Using noreplace solves issues surrounding which one of multiple short descriptions is stored as "Local description" in the page info, but doesn't help this issue because Lua can't read it. In one sense, there might be some value in having two categories on the same page as it alerts us that a generated short description has been manually overwritten - perhaps that's worth examining to see if we can improve the generator (e.g. "Province in" → "Province of" would be more idiomatic), --RexxS (talk) 17:23, 7 August 2020 (UTC)

Automated descriptions gone

As promised, it seems that short descriptions from Wikidata are no longer being displayed automatically. Certes (talk) 11:39, 7 August 2020 (UTC)

Good to know that some promises are kept. Cheers, · · · Peter Southwood ^(talk): 15:47, 7 August 2020 (UTC)

What is your evidence for this? I haven't seen any action on T248457. I'm still seeing a Wikidata-based short description at The Phantom Tollbooth. I have the short description helper gadget enabled, which might make a difference, but I also see the Wikidata short description for that article when I switch to the mobile view and type "The Phantom Tollbooth" in my search box. – Jonesey95 (talk) 15:48, 7 August 2020 (UTC)

Looking at that article on my iPhone, I don't see any SD. MichaelMaggs (talk) 16:07, 7 August 2020 (UTC)

I'm not seeing a short description on The Phantom Tollbooth with either gadget or mobile view (Firefox; Ubuntu desktop), although Wikidata holds one. Similarly for a few other random pages I checked. I'm hoping that this is because they've been turned off, though I also have seen no notification. Certes (talk) 16:16, 7 August 2020 (UTC)

I am definitely still seeing them on multiple articles and in search results. This could be a Friday software update change, where some of the servers have received the update and some have not. Let's give it a day to see if it settles out one way or the other. – Jonesey95 (talk) 16:27, 7 August 2020 (UTC)

I've seen them missing in some contexts today but not others. Strange. --Trialpears (talk) 16:40, 7 August 2020 (UTC)

How about now, when any change will have had a chance to percolate through all servers? I'm seeing descriptions on a mobile search but not via the gadget on desktop, for The Phantom Tollbooth and other test cases such as Abdomen. I'm not sure whether that is a change to the gadget, a difference between mobile and desktop, my requests using different servers or just pot luck. Are other editors' experiences similar? Certes (talk) 15:59, 10 August 2020 (UTC)

I'm still seeing them in Desktop with the gadget and in mobile search. – Jonesey95 (talk) 16:29, 10 August 2020 (UTC)

Article's main category as a suggested short description?

Our SD guideline currently discourages attempting to define a subject in a short description, as this almost always too long to be a useful on mobile devices. We instead encourage SDs that distinguish the subject, as often more helpful to readers unfamiliar with the subject (our target audience for SDs) and much more likely to be an SD that's actually short enough to be useful. I agree with all this.

I've encountered a lot of descriptions that only categorize the subject, such as "Chemical", "Type of warfare", "Computer language". At first, I considered these as placeholders until something better is found.

At the same time, I've seen many long and often heated discussions where editors don't seem to understand what "distinguish" means, and end up with defaulting back to attempting to define the subject, even if that means ending up with most of the article's whole first paragraph into the SD.

I now consider SDs that just state the subject's main category as much more viable and helpful in these cases. I also see these cases are pretty common.

So, my question is, should we expressly encourage this in our guideline? That is, suggest using the subject's main category as a reasonable default short description where alternatives are difficult? --A D Monroe III^(talk) 21:49, 15 August 2020 (UTC)

Sure, the article category can be an inspiration for choosing the SD, but most often the article lead is the source of a good SD. — GhostInTheMachine ^{talk to me} 22:32, 15 August 2020 (UTC)

As hinted at above, one purpose of the short description is to distinguish the article from those with similar titles. There may be synergies with the descriptions used on disambiguation pages. Although their rules don't apply to SDs, there may be useful hints in MOS:DABENTRY, WP:D and related pages. Certes (talk) 22:47, 15 August 2020 (UTC)

"Type of warfare" is perfect if similarly titled articles would have short descriptions like "Rock band", "Type of dessert", and "Card game based on American football". The person searching just needs enough to know they have found the right article, and not one with a similar title about something entirely different. Keep it short enough to disambiguate it. – Jonesey95 (talk) 05:04, 16 August 2020 (UTC)

Do we need to take into account other titles with a similar prefix? So Alice Washington and Bob Washington can both be "American politician", but Herba similarii and Herba confusii would need more than just "Species of grass" because there is another article with both a similar prefix and a related topic? I am aware that I am concentrating on just one usage of short description here. Certes (talk) 11:14, 16 August 2020 (UTC)

That's a valid question, but I think that people typing "Herba" and looking for Herba similarii or Herba confusii would be happy to know that they are both species of grass and that they need to look at both, but that they do not need to look at "Herba Milenovic" ("Fake Serbian actress"). Where you need more text is for two English politicians named William Johnson. Birth and death dates are helpful in those cases. – Jonesey95 (talk) 13:30, 16 August 2020 (UTC)

Markup

What formatting is allowed in short descriptions?:

• Italics, e.g., for a title ("Author of the Harry Potter books")?
• Superscripts, e.g., for 10⁷ ("10⁷ in the Indian number system")? If not, is "10^7" acceptable?
• Emojis? (The emoji for a smile: :-) or ☺)
• Math? (The mathematical identity e^iπ=-1)
• IPA (The sound /ɜ/ (IPA))
• Other languages? (The Arabic phrase بسم الله 'in the name of God')

I will guess that short descriptions are supposed to be plain text with none of these things, but that doesn't seem to stated explicitly. --Macrakis (talk) 22:44, 12 September 2020 (UTC)

Just plain text. No HTML or wiki markup. Just updated the article... — GhostInTheMachine ^{talk to me} 23:09, 12 September 2020 (UTC)

Copying short descriptions to Wikidata

Hi all. Related to the above post, and as a result of discussions with @RexxS:, I've proposed a bot to synchronize enwp's short descriptions with the English descriptions on Wikidata, see d:Wikidata:Requests for permissions/Bot/Pi bot 14. The bot has two options, either only importing descriptions where Wikidata doesn't already have one, or completely synchronising enwp and wikidata English descriptions. Technically, this is possible, and I contend that the descriptions are short enough to be ineligible for copyright. If you have thoughts on this, please post them here or on Wikidata at the bot discussion or the d:Wikidata:Project_chat#Importing_short_descriptions_from_enwp. Thanks. Mike Peel (talk) 19:34, 3 August 2020 (UTC)

For the local equivalent, see Wikipedia:Bots/Requests for approval/Pi bot 5. Thanks. Mike Peel (talk) 21:14, 3 August 2020 (UTC)

Even allowing for some specific issues that have been mentioned on Wikidata, in the vast majority of cases a single well-written text will work both for Wikidata and here, and can be released to Wikidata under CC0. So, at the very least I'd like to see a one-click or semi-manual feature so that editors working to improve SDs here can push their edits through to Wikidata without having to go there and duplicate the work; likewise, so that editors improving Wikidata descriptions can copy their improvements here, without having to come here and duplicate the work. In both cases, of course, under user control. Both enWP and WD communities should be striving to avoid a them-and-us culture, and should be working together to improve interoperability. MichaelMaggs (talk) 12:15, 4 August 2020 (UTC)

@MichaelMaggs: For anybody who wants to help with that, a good starting point is Wikipedia:Shortdesc helper. Once that is installed, you can go to any page with a short description, click Edit and then the gear-wheel is visible to access settings for the helper. In the 'General' pane, tick the box for Add a button, "export", to update the Wikidata description to match the local description. You can also use the 'Appearance' pane to widen the edit box (I use 55em) and font size to suit yourself. Once you have saved the settings (top-right button), you will thereafter have an Export link available next to the Edit link on every page, which will update the Wikidata description from the enwiki short description. Please remember you are responsible for the edits you make to Wikidata when you use this feature. Hope that helps those interested. --RexxS (talk) 21:06, 4 August 2020 (UTC)

@Mike Peel: If we are going to export enwiki short descriptions to Wikidata, we should either reverse our advice to use sentence case for short descriptions, or simply lower-case the first letter of each short description that is exported, which would lessen the inaccuracies in capitalisation required at Wikidata. --RexxS (talk) 21:11, 4 August 2020 (UTC)

@RexxS:@Mike Peel: Unfortunately the Edit link in Wikipedia:Shortdesc helper mostly can't be used to transfer error-free text to Wikidata since it only becomes active after the upper-casing of the initial letter has been enforced. It works only in those cases where Wikidata expects an initial capital, such as "British footballer.." or where the text starts with a numeral such as "2015 film ...". It would help if the link could be available for use immediately after an initial lower case text has been typed/edited, and before it is upper-cased and committed to Wikipedia. MichaelMaggs (talk) 22:02, 4 August 2020 (UTC)

@MichaelMaggs: I think the simplest solution would be to offer two 'Export' links, perhaps something like Export | Export (lc) where the second link lower-cased the first character before writing it to Wikidata. --RexxS (talk) 22:12, 4 August 2020 (UTC)

That would work. MichaelMaggs (talk) 22:20, 4 August 2020 (UTC)

@MichaelMaggs and RexxS: Just to let you know that I've followed this proposal up at Wikipedia:Village_pump_(proposals)#Synchronising_short_descriptions_and_Wikidata_descriptions. Thanks. Mike Peel (talk) 21:46, 6 August 2020 (UTC)

• Bot request Denied 15 September 2020 — GhostInTheMachine ^{talk to me} 08:32, 15 September 2020 (UTC)

Familiar vs. precise wording

The short description for Newton (unit) formerly read "SI unit of force". Since short descriptions are supposed to help non-specialist readers, I changed it to "Metric (SI) unit of force", since "metric" is far more familiar than "SI". I am tempted, in fact, to write "Metric (SI) unit of force in physics", since the non-specialist reader may have no idea what is intended by "force". Comments? --Macrakis (talk) 22:44, 12 September 2020 (UTC)

What's wrong with just "Unit of force in physics"? Neither "metric" nor "SI" is needed in the short description. Mathglot (talk) 10:06, 15 September 2020 (UTC)

None of those are wrong. If you can make the description more widely useful while remaining short, go ahead. For discussions on the finer details of what is more useful for a given article, the article talk page is usually going to be the best place to get interested, and hopefully knowledgeable, people to join the discussion. · · · Peter Southwood ^(talk): 14:32, 17 September 2020 (UTC)

shortdescs-in-category gadget proposal

I have proposed that user:SD0001/shortdescs-in-category be made a gadget so that it can be found easily by more users. See Wikipedia:Village pump (technical)#New gadget_proposal: view short descriptions in categories. Please comment there if you find this script useful. Thanks, – SD0001 (talk) 05:07, 20 September 2020 (UTC)

Article in both Category:Short description matches Wikidata and Category:Short description is different from Wikidata

Why is ! (Cláudia Pascoal album) in both Category:Short description matches Wikidata and Category:Short description is different from Wikidata? I can't figure it out. Steel1943 (talk) 17:07, 4 September 2020 (UTC)

@Steel1943: See comment above by RexxS dated 16:08, 7 August 2020 (UTC). – SD0001 (talk) 17:13, 4 September 2020 (UTC)

Yep, I guessed it may have had something to do with the infobox templates ... well that proves it I suppose. Steel1943 (talk) 17:16, 4 September 2020 (UTC)

I know this comes about three weeks late, but {{infobox album}} now uses noreplace in its {{short description}} call, so the above issue should be fixed. Primefac (talk) 18:46, 23 September 2020 (UTC)

Categories 2 - Length

Would there be any interest in adding some sort of tracking category/categories for the length of a shortdesc? I know they're supposed to be "around 40 chars" but I just trimmed a rather lengthy and unnecessary one; seems like that sort of thing should be tracked. I know there are a number that will likely be totally acceptable but still >40 chars, so maybe 80+ or 100+? Primefac (talk) 18:48, 23 September 2020 (UTC) (please ping on reply)

Category:Articles with long short description is applied to shortdescs of more than 100 chars. – SD0001 (talk) 18:51, 23 September 2020 (UTC)

Huh. Don't know how I missed that. Primefac (talk) 15:23, 29 September 2020 (UTC)

Mobile version

According to Wikipedia:Short description#Using short descriptions in Wikipedia on the mobile site "Whenever a mobile user searches on a browser for an item using the search function from within Wikipedia, they see a list of suggested articles with their short description beneath." However, when I tried that on my phone it didn't work and I got something similar to the search function on the desktop. I thought at first I was on the desktop site but I checked and was on the mobile version. I realised I wasn't logged in and did so but that still didn't work. Eventually I went to settings and turned on advanced mode. That works but it isn't stated here. It was the same in Firefox, Chrome, Edge and Bing. CambridgeBayWeather, Uqaqtuq (talk), Huliva 04:35, 9 October 2020 (UTC)

No short descriptions

Since October 13, there are no Wikidata short descriptions in mobile mode in the English Wikipedia version anymore. In other Language versions however, they are shown. I can only see those short descriptions created in Wikipedia articles.-- Maxeto0910 (talk) 00:10, 14 October 2020 (UTC)

Finally. I haven't received any updates on the various phab tasks that I am following, but this appears to be accurate. Looking at Yoko Ono, for example, there is a Wikidata short description but not a local one, as far as I can see, and no short description is displayed. When I go to the mobile search box and type "Yoko", I see no SD for Yoko Ono, but I see one for Yokohama, which has a local SD. It looks like the RFC result has finally been implemented (at least as far as I can tell; there may be edge cases left). – Jonesey95 (talk) 00:34, 14 October 2020 (UTC)

See Wikipedia talk:Shortdesc helper#Shortdesc helper no longer showing Wikidata SD — GhostInTheMachine ^{talk to me} 17:25, 14 October 2020 (UTC)

Detecting problems in short descriptions

See this thread for some examples of short descriptions with invalid text or other errors.

Should we try using {{KillMarkers}} to remove references from short descriptions? Should we use {{Plain text}} to strip wikicode from short descriptions? I am sure that those would both require significant testing, but they could be beneficial.

Whether we use or do not use string-processing templates on |1=, it seems like we should be able to use some string processing to detect emojis, wikicode, reference tags, and other errors that corrupt short descriptions, and assign pages to a tracking category if they have erroneous text in the SD. Has anyone tried this yet? – Jonesey95 (talk) 17:12, 21 October 2020 (UTC)

Article erroneously placed in "long short description" category

Byron Bay High School is erroneously appearing in Category:Articles with long short description. Its short description is 40 characters. I'm guessing that the problem lies in the auto short description that is generated by {{Infobox school}} but is not used. – Jonesey95 (talk) 17:35, 21 October 2020 (UTC)

Yes. The infobox has a whole list for the |type= value: Government-funded co-educational comprehensive secondary day school?'"`uniq--ref-00000010-qinu`"'? school which is 105 characters long. It also includes a reference which would make for an evil short description. The local short description Secondary school in Byron Bay, Australia overrides this, which is fine. — GhostInTheMachine ^{talk to me} 17:56, 21 October 2020 (UTC)

Adding new descriptions to 26,000 moth articles

I've put up a proposal at Wikipedia_talk:WikiProject_Short_descriptions#ShortDescBot_task_1_-_moths to start a bot to add short descriptions to all the moth article that currently lack one. I'll need community consensus do do that, though, and support or comments are welcome there. MichaelMaggs (talk) 19:10, 7 December 2020 (UTC)

Dates in short description

Recently both here and on Wikidata I've noticed that a large number of descriptions of persons have been edited to add the person's lifespan (eg [1]). Has there been a discussion about this somewhere? Nikkimaria (talk) 14:47, 22 August 2020 (UTC)

I too don't think adding dates is a good idea. SD0001 (talk) 15:19, 22 August 2020 (UTC)

@Nikkimaria: for common names, it is a functional disambiguator. So if I'm looking for the article on a particular John Smith, a date of birth (or lifespan) would be useful to distinguish between John Smith (Cambridge, 1766) and John D. Smith, for example.

For Swami Vivekananda, probably not so much (although useful for the two films about him: 1955 and 1998) --RexxS (talk) 16:06, 22 August 2020 (UTC)

Absolutely I'd agree, sometimes it's useful and sometimes not. I'm wondering though given how many edits of this kind I'm seeing whether there's been a discussion somewhere that concluded it should always be done. Nikkimaria (talk) 16:09, 22 August 2020 (UTC)

@Nikkimaria: I'm not aware of any discussion that concluded it should always be done. I guess somebody has realised that dates might be useful, so is adding them. There's no real downside, other than making the SD a bit longer. --RexxS (talk) 16:12, 22 August 2020 (UTC)

Dates are very useful for biographies, since many people have similar names, and the dates can help readers figure out which person they are looking for. In a similar manner, dates can be useful for films, video games, and other types of media. – Jonesey95 (talk) 16:50, 22 August 2020 (UTC)

Given the limited space, I think there are usually much better clarifyers than a date or date range: Nationality/occupation for people; author/artist for creative works like songs, albums or films; nationality/industry for companies; etc. I would avoid using the dates when such better options are out there and both won't fit in 40 characters. UnitedStatesian (talk) 19:24, 22 August 2020 (UTC)

Dates are extremely useful in the majority of the situations mentioned above, as they provide useful contextual information even when not absolutely necessary for disambiguation. (And disambiguation is not the sole purpose of SDs). So for example there is only one English composer on Wikipedia called John Eccles, but "English composer (1668–1735)" provides far more information than "English composer", and in only 28 characters. Except where it would make the text too long, adding dates nearly always helps. MichaelMaggs (talk) 19:29, 22 August 2020 (UTC)

I was also going to respond with something like this. In the case of biographies and description of media works, adding a date typically does not make the SD excessively long. Most media works can be described in the form "[year] [video game/novel/film] by [person/company]", and most biographies can take the form "[Nationality] [occupation] ([year–year])". Nice and short. – Jonesey95 (talk) 19:37, 22 August 2020 (UTC)

I think MichaelMaggs said it perfectly. If they fit in a biography article SD, add them. MB 22:24, 22 August 2020 (UTC)

I may be alone here but my view on this is that we shouldn't add birth years or death years, barring exceptional cases where the name is exceedingly common, or where nationality + occupation isn't a sufficient disambiguator. These descriptions are used in various ways, so just because there is space doesn't mean it would be helpful. See for example User:SDZeroBot/NPP_sorting/Culture/Biography/Women and think of how much pointless clutter it would have been had there been dates everywhere in the shortdescs. SD0001 (talk) 05:02, 24 August 2020 (UTC)

Disambiguation is only a small portion of the value proposition of short descriptions. When I look up a person one of the first things I want to know is if the person is still alive and what time period they lived in. Having (birth-death) in the short description answers those questions in just 11 characters. It is also hard to know if a name is ambiguous or not, just because Wikipedia may only have a single person with that name doesn't mean people are searching for that person, they could be searching for someone without an entry at all.

I agree fully with what MichaelMaggs wrote above, I have been adding birth and death dates to short descriptions for non-living persons if that information is available in the article. I'm adding my comments in the hopes that it generates more discussion, having a consistent format for biography short descriptions is useful. I'd like to see the consensus documented on the project page with a specific item for biographies. Lorax (talk) 23:15, 12 November 2020 (UTC)

I would also like this consensus documented. I have seen dates removed, such as this case when a SD was imported from WD. MB 23:23, 12 November 2020 (UTC)

Short descriptions are most effective when they are, in fact, short. To that end I do not favor the inclusion of years as a default. As Lorax posits, living-or-not is a significant differentiation, but the range of years lived, even at 11 characters, doesn’t strike me as a good bargain. One example I mentioned to him during a recent conversation was ‘Michael Jackson’: is the reader seeking the American singer, songwriter, and dancer or the beer and whisky expert? Both are deceased, and that may well be worth signifying, but adding to the former ‘(1958–2009)’ and to the latter ‘(1942–2007)’ primarily distracts the user who is trying to quickly distinguish two search results.

I wonder if a desire for immediate chronological context might be better served with centuries. Presently John Ruskin is a “19th-century English writer and art critic”, and that seems about right. Immediately I know that he might have been a Victorian or perhaps a generation older. I am not presented with a math problem; I do not start adding 20 years to the first figure to calculate when he might have started being influential, and I do not attempt calculating a difference to determine how old he was when he died. I am left to focus on the most relevant details, and I infer that he was a person who influenced art through his writing. That’s distillation at its best. The style guidelines should encourage short descriptions of such clarity and immediacy. —jameslucas ^{▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄} 04:12, 13 November 2020 (UTC)

I strongly disagree with that analysis. To the contrary, if the guidelines are to be changed they should generally encourage the use of dates for biographies. The arguments presented immediately above are, in my view, flawed.

Current consensus, at WP:HOWTOSD, is that "Short descriptions serve several purposes including a very brief indication of the field covered by the article; a short descriptive annotation; and a disambiguation in searches, especially to distinguish the subject from similarly-titled subjects in different fields." Also, editors should "be brief: aim for no more than about 40 characters (but this can be exceeded when necessary)."

Suggesting that dates should not be used "by default", and that SDs are best "when they are, in fact, short", invites editors to unhelpfully remove useful dating information from already-short (less than 40 character) SDs. The guidelines don't say that SDs should always be as short as can possibly be achieved, only that they should not be too long. Where information useful to a reader can be included within around 40 characters, it generally should be. That helps ensure that the SD is good "short descriptive annotation".

Of course, dates shouldn't be required, only encouraged, and in the 'two Michael Jacksons' example there are no doubt better ways to usefully fill around 40 characters than with closely-overlapping date ranges. There are many examples where editors should use their discretion, one being when the addition of dates would in itself make the SD too long. But excluding date ranges "by default" is an entirely different proposition.

Using century ranges to provide chronological context is highly problematic, as it is impossible to be both precise and concise. Purely statistically, a large proportion of historical figures span century-ranges. For example, a person living 1680–1760 can be denoted easily as "(1680–1760)" (11 characters, accurate, and provides useful information), but using centuries requires "17th C." (7 characters, but factually incorrect), "17th–18th C." (11 characters, and hopelessly vague) or "Late 17th–early 18th C." (OK, but 23 characters). And, no, it's not clear that "18th C." without more, is to be read as meaning "active during the 18th-century". Another issue is that century numberings are not universally understood: many readers will take "17th-century" to mean 1700–1800 rather than 1600–1700.

As several editors have suggested above, we should update the guidelines to match the current majority view, as I understand it, that generally dates are useful for biographical articles. MichaelMaggs (talk) 12:20, 13 November 2020 (UTC)

A point I forgot to mention last night: Date ranges, when they follow a job description are ambiguous because they can seem like lifespans or a duration of reign, appointment, or activity in a field. If the short description of James V of Scotland were “King of Scotland (1512–1542)”, should reader take that as his lifespan or his reign? That is often a highly significant difference, and such formatting will mislead as often as it informs. On the other hand, “King of Scotland (16th c.)” works fine because of its fuzziness. MichaelMaggs would rightly point out that this is a convenient example because it doesn’t span centuries. My current thinking on that matter is that the period of notability should dictate the century. Let’s look at two other kings whose lifespans crossed century demarcations:

1. Edward II of England would reasonably be “King of England (14th c.)” despite his being born in the previous century because his reign (1307–1327) was limited to one century.
2. James IV of Scotland would reasonably be “King of Scotland (15/16th c.)” because his reign (1488–1513) spans those centuries.

Consider me far from certain that this formula is the ideal one, but I do believe that the confusion created by the 11-character date range is a failing that need be addressed. —jameslucas ^{▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄} 14:36, 13 November 2020 (UTC)

Dates are nearly always useful, but birth and death figures are not invariably best and editors should always consider the context. I've seen this a few times, and my solution is to use "King of Scotland from 1488 to 1513". MichaelMaggs (talk) 18:26, 13 November 2020 (UTC)

This example is why I think we should have consensus guidelines, if date ranges are always birth-death then there is no confusion, if sometimes they mean when a person lived, and sometimes they mean when a person held a position, then it can be confusing. Lorax (talk) 22:31, 13 November 2020 (UTC)

For those of us who pay enough attention to the MOS to debate its nuances, a convention would override potential confusion. Certainly many editors and a few especially observant non-editors will latch on. To the other 98% of Wikipedia users, however, the rule won’t be self-evident, and the James V of Scotland example above will remain ambiguous, confusing, or misleading. —jameslucas ^{▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄} 03:11, 14 November 2020 (UTC)

Your example makes a good point, the James V of Scotland (15/16 c.) is confusing to someone who isn't fully aware of the nuances of your argument. What does "c." even mean? Circa? Circumcision? The speed of light? What about fifteen sixteenths? Fortunately, even the most casual reader of Wikipedia biographies will be familiar with the (birth-death) convention. I think you are overestimating the potential for confusion. Lorax (talk) 04:32, 14 November 2020 (UTC)

On a related topic, most disambiguation page entries briefly describe the topic. There, the positioning is different: Neil Downe (1234–1299), bishop of Narnia associates the lifespan with the person rather than the role. If the birth and death dates were lost in the mists of time, we might instead write Neil Downe, bishop of Narnia 1283–1293, with the dates there reflecting the time in office. Readers used to this convention might find birth and death dates appearing after a role confusing. Certes (talk) 10:30, 14 November 2020 (UTC)

Lorax, I hear you on the risk of introducing c as an abbreviation. It has a long history, but it's on the crusty, bookish side and may be unfamiliar to many. This and Certes's comparison above both reinforce my general sense that dates should be included only when necessary for disambiguation. —jameslucas ^{▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄} 15:12, 14 November 2020 (UTC)

P.S. Is anyone else finding the number of editors involved in this discussion strangely low for something affecting such a prominent aspect of Wikipedia? Is this the wrong venue? Do we need to round up folks somehow? —jameslucas ^{▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄}

Can I urge the participants in this thread to read MOS:LISTGAP and comply with it, please?

For the James V of Scotland article, what would be the problem with a short description like King from 1513 to 1542? For Henry VIII, why not something like King of England from 1509 until 1547? I don't see where there's any room for confusion if those dates are presented in that sort of manner. For Pope Urban VIII we currently have "17th-century Catholic pope"; how is that better than Pope from 1623 to 1644? Were there any non-Catholic popes? --RexxS (talk) 19:45, 14 November 2020 (UTC)

RexxS are you suggesting that we put the birth and death dates at the beginning of the short description instead of at the end? I like the idea of consistency across projects and it seems like it would allay the concern that Certes had as well. I'd also be happy with GhostInTheMachine's suggestion below. (and Coptic Popes are non-Catholic) Lorax (talk) 03:42, 17 November 2020 (UTC)

A quick aside for myself as much as anyone: I didn't immediately understand RexxS's above request that we consult MOS:LISTGAP since talk pages are far less regulated than articles and the MOS doesn't typically apply. What MOS:LISTGAP doesn't say but Help:Talk pages § Indentation does is that double line breaks within indented lists create navigation issues for screen readers and other accessibility devices—an issue worth taking seriously in both Article and Talk spaces. I learned a lot. Thanks for sending me off on that path, RexxS. —jameslucas ^{▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄} 14:34, 17 November 2020 (UTC)

@Lorax: I don't think I was addressing the question of birth/death dates for office holders. I was merely observing that the formula "Position from year to year" – where the years refer to the start and finish dates of the tenure – was likely to be more useful in identifying the article than "Position" alone. I wouldn't have a problem with recommending a convention that if we state lifetimes, then we use "(year–year)", and if we state tenure for office holders, we use "Position from year to year". You make a good point about Coptic popes, although it seems our audience is far more likely to be looking for the Bishops of Rome than the Patriarchs of Alexandria – compare the article titles List of popes (not "List of Catholic popes") and List of Coptic Orthodox popes of Alexandria, Pope John XIII and Pope John XIII of Alexandria. I can see a point in short descriptions like Pope from 965 to 972 and Coptic pope from 1484 to 1524, but I don't think we need a "Catholic" qualifier for the former (although it wouldn't be a problem). --RexxS (talk) 10:53, 17 November 2020 (UTC)

Sorry RexxS, I actually meant that comment for Certes, they posted a different manual of style link (for disambiguation pages) that covers guidelines on people that may be useful for this project too Lorax (talk) 23:36, 17 November 2020 (UTC)

To the point that "c." may be confusing, take a look at Andrew Roe, which has a SD of British Army officer (fl. 1992- ). I would bet that "fl." is much less understood than "c." I think this is another reason why we should have a documented consensus of guidelines on the use of dates in biography SDs. This would also help prevent the kind of SD thrashing that has gone on at Ravi Belagere where dates were added/removed several times. MB 03:00, 16 November 2020 (UTC)

Ouch. To save others wasting time on the search engine of their choice (as I had to) — fl. is short for latin "floruit" meaning something like flourished (as in active) and sometimes used to mean alive at this time. So ... (fl. 1992- ) just says that we don't know when he was born. I am really struggling not to change it before people "here" get to see it — GhostInTheMachine ^{talk to me} 15:56, 16 November 2020 (UTC)

Thanks for saving us the trouble of looking up ‘fl.’—definitely a new one to me! —jameslucas ^{▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄}

Floruit is handy as a disambiguator of last resort, so if I'm seeking a modern person on a dab I can rapidly skip Anne Example (fl. 1650), actor. For short descriptions, I'd prefer something like 17th-century actor. Certes (talk) 16:09, 16 November 2020 (UTC)

Ouch again. It really is not friendly to use an abbreviation like fl. on an encyclopedia that it intended to be read by a large number of people who have English as their second or third language and no latin at all. If a date seems wise, it would be much kinder to use something like British Army officer from 1992 — GhostInTheMachine ^{talk to me} 16:53, 16 November 2020 (UTC)

Addressing the main point — dates generally help. They should not be mandated as context is important, but for people or historic events they really are A Good Thing. Where there might be confusion about a year range being a person's lifetime or their time in office we should probably advise the convention that lifetime will always be with a dash in brackets ... (1234-1278) and time in office would be ... from 1234 to 1245 — GhostInTheMachine ^{talk to me} 16:53, 16 November 2020 (UTC)

No matter how consistent we are with our formatting within SDs, a lifespan that follows a profession or title will always be liable to mislead. There is simply no established convention, on Wikipedia or elsewhere, that a date range in parentheses represents a lifespan except in the one case when it immediately follows a name. Yeah, a few suffixes can get wedged in between without risk of confusion, but that’s not what we're talking about here. The lifespan parenthetical being suggested would not only follow a wide-range of reasons for notability, it’d be on a completely different line of text from the name. I know this component feels safe because it’s so common, but its established meaning is highly context dependent. —jameslucas ^{▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄} 19:43, 16 November 2020 (UTC)

Notes

Proposal to add dating recommendations to the guidelines

There seems to be consensus to add dating recommendations to the guidelines at WP:HOWTOSD to improve consistency in short descriptions. Here is my proposal, based on the discussions above and elsewhere. Comments are welcome. To avoid us all getting bogged down in minutiae, I'd suggest focussing initially on the overall acceptability of my general approach rather than on specific detailed drafting issues.

The inclusion of a date or date range is encouraged where it would improve the short description as a disambiguation, or enhance it as a descriptive annotation. Generally that is the case at least for biographies and for articles on specific publications and dated historical events. Editor discretion is always needed, and in some cases there will be more important information than dating to be included within the available 40 or so characters, but if space is available such dates are encouraged.

The following date formats are recommended for consistency but can be varied if there is consensus that in some particular case an alternative date format would be better. In the table below, the examples illustrate the recommended date format only; they are not intended to recommend any particular descriptive wording.

In biographies, care should be taken to distinguish between dates which define a lifespan and those which define a period in office: lifespans should normally be specified by "(birthyear–deathyear)", and periods in office by "from startyear to endyear". For historical biographies, specific dates such as "1750–1810", where known, are preferred to "18th-century", as it is not clear whether that means "born and died during the century", "in office during the century" or "mostly active during the century".

Type		Recommended date format	Examples
Biography	Lifetime most important	[Person description] (birthyear–deathyear) Year of death unknown (or BLP): [Person desc] (born birthyear) Year of birth unknown: [Person desc] (died deathyear)	English composer (1668–1735) English composer (born 1668) English composer (died 1735)
	Period in office most important	[Office description] from startyear to endyear	King of Scotland from 1488 to 1513 Pope from 965 to 972
Publication	Publication in a specific year	Publicationyear [Description]	1964 musical film 1988 novel by Penelope Fitzgerald 1981 arcade game
Historical	Event in a specific year	Eventyear [Description]	1861 American Civil War battle
	Period or range	[Description] from startyear to endyear	Epidemic of bubonic plague from 1665 to 1666

Where a date is not known exactly, "c. " may be used for "circa". Other examples are given at WP:APPROXDATE, although "fl. " for "floreat" should be avoided as it is not universally understood. Centuries should not be abbreviated "c. " due to the potential for confusion with "circa".

MichaelMaggs (talk) 16:09, 30 November 2020 (UTC)

Discussion

I support the majority of this proposal. My concerns are three:

1. As I have argued extensively above, the average reader is not going to be able to make a reasonable guess that (1668–1735) applies to John Eccles’s lifespan as opposed to the span of his career (and the problem is greater for a person like Franz Schubert, whose lifespan was shorter than many careers). There is simply no convention on Wikipedia or elsewhere that a date range formatted thus represents a lifespan except when it immediately follows a name. Consistently deployed or not, it will not be unambiguous to anyone except those who have read this Manual of Style entry.
2. The language suggested for World War I is neither conventional shorthand nor natural English. A native English speaker would be unlikely to say “World War I was a 1914 to 1918 conflict”, and such phrasing is routinely corrected when it appears in articles. I don’t have a satisfactory alternative that includes the same degree of date precision, but something like ‘Global conflict originating in Europe in 1914’, strikes me as acceptably informative and far more natural. ✓ Resolved
3. The table formatting has some inconsistencies in the use of paragraphs versus manual line breaks and some confusing use of rowspan, and the use of semicolons in the rightmost column is more confusing than helpful. (MichaelMaggs, I didn’t want to touch this without your blessing, but if you want help with the row issues, just give a shout.) ✓ Resolved

—jameslucas ^{▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄} 16:46, 30 November 2020 (UTC)

Feel free to tweak the table. Thanks. MichaelMaggs (talk) 16:49, 30 November 2020 (UTC)

On reconsideration I agree that having a date range at the front will often sound a bit clunky, so I've removed the World War I example. MichaelMaggs (talk) 17:16, 30 November 2020 (UTC)

I have tidied up the table a bit. – Jonesey95 (talk) 16:54, 30 November 2020 (UTC)

@JamesLucas: On point no. 1, it's important to keep in mind that these are not mini-articles, and perfect understanding of every nuance is not necessary on the part of everyone. The only point of any of the dates is helping people disambiguate (e.g. between the Engelbert Humperdinck who was popular in my parent's era, versus the one from back in the days of tophats and cravats). So we need not overthink this stuff too hard.  — SMcCandlish ☏ ¢ 😼  05:00, 1 December 2020 (UTC)

• I support this proposal. I do not have the same worries as JamesLucas about the year ranges being confusing. Having a year range for a given John Eccles will tell me right away whether I have found the 17th/18th-century composer or the 20th-century Royal Navy officer. – Jonesey95 (talk) 16:54, 30 November 2020 (UTC)
• I support this proposal in general. Where a date range can have only one meaning, as with a war, we can be flexible about writing the dates in whatever format reads naturally. Certes (talk) 17:25, 30 November 2020 (UTC)
• Support - Dates are a Really Good Thing and generally help. — GhostInTheMachine ^{talk to me} 19:59, 30 November 2020 (UTC)

  In case I remain in the minority in deprecating the introduction of lifespan ranges, I’d like to visit some resulting complications to see if we can coalesce on recommendations:

  1. The current proposal recommends the same formatting for those with death-date-unknown and those still alive. This will likely look like positive confirmation of living status for a certain range of birth years. Gene Hackman, born in 1930, is old and long out-of-sight but almost certainly alive. Ilse Albert, born in 1929, is probably not alive. Should they be treated the same? How about Anne Huré, born 1918 and almost certainly dead? (I note that this isn’t a rare case. End-of-life documentation is often spotty for people whose famed peaked when they were young, so hundreds or thousands mid-century athletes are currently in the possibly living category.)
  2. In the above conversation, I raised a concern about similar lifespans. If a user searches for ‘Michael Jackson’, the results will include the American singer, songwriter, and dancer and the beer and whisky expert. The former lived 1958–2009; the latter lived 1942–2007. MichaelMaggs and I agreed that the the inclusion of those ranges does more to distract from the relevant info than to help distinguish two search results. Should such inclusion be explicitly discouraged in the MOS? (And is there any hope that the pop artist’s SD won’t be repeatedly appended with ‘(1958–2009)’—no matter what is recommended—if the inclusion of lifespans starts seeming to well intentioned casual editor to be an unvarying default?)

  —jameslucas ^{▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄} 21:17, 30 November 2020 (UTC)

  Some thoughts ...

... on both of the numbered points above...

On the first one: WP isn't in the business of implying statistically likely deaths. I.e., it is better to imply someone is presumably still alive than the opposite (well, up to a point, like older than 120 or whatever the record is these days). In cases where someone is known dead or has legally been determined "presumed dead", we could do something like "1969–2001(?)" or "1969–?", or otherwise come up with a notation for "surely dead but date uncertain" (whether we have an approximation or not). Given the special meta-data nature of these things, and their tight space limits, we need not necessarily reject conventions that would not be appropriate in main article text (e.g. WP doesn't use the –? style normally; I think this is covered at MOS:DATE). On the second point, I don't think we need any explicit discouragement stuff, because this is just too subjective. (And in this pair, the 1942/1958 split is hardly insignificant.) Except for highly unusual names, it's pretty likely that other people will need to be disambiguated over time, and even for this case there are lots of other Michael Jackson (disambiguation) subjects, so the dates will still help disambiguate the two above-named individuals from the rest of them, even if not as well as a century gap would. For a lot of sports figures it's genuinely helpful because sports fans often have various stats at hand already. I do get your concern, but I don't think it would be "enforceable", because people adding an SD to an article are unlikely to trawl through every possible DAB confusion target and check all the dates in them to determine whether they are sufficiently far part in time to comply with some arbitrary cut-off we put in there. It would be a lot of work for no practical gain. It's been my long and dreary MoS-steering experience that the simpler the rule is, the more people will follow it with the least drama (e.g. no one fights about MOS:LQ any more, despite it seeming arbitrary to various people and against their usual (nationalistic) preference; but people fight half to death over MOS:DASH stuff, because the complexity of it confuses a lot of them.

 — SMcCandlish ☏ ¢ 😼  05:00, 1 December 2020 (UTC)

• Support as written as a recommendation, not a requirement. MB 00:15, 1 December 2020 (UTC)

  @MB: It's not necessary to engage in keep-your-rules-off-muh-freedom grandstanding. >;-) Given that this is an {{information page}} (a form of WP:Essay), and not even a guideline, it isn't possible for anything it says to be "a requirement" (it wouldn't be unless it were in a policy, and even then WP:IAR would still apply).  — SMcCandlish ☏ ¢ 😼  05:00, 1 December 2020 (UTC)

That didn't come across the way I meant it. I have no concerns (see below). I was just trying to note that this is not a requirement and we shouldn't be concerned people will try to force dates in every SD because of this recommendation - which can always be overridden by editorial consensus on an individual article like it says at WP:SHORTDES. MB 00:20, 2 December 2020 (UTC)

• Support-ish in principle and in most details, except we have no reason to use "Epidemic of bubonic plague from 1665 to 1666" when "Epidemic of bubonic plague, 1665–1666" or "Epidemic of bubonic plague (1665–1666)" suffices and saves space. We do need the precision in human role spans ("King of Scotland from 1488 to 1513") to distinguish from life spans ("English composer (1668–1735)"). But that rationale doesn't apply to event dates. If we're not just going to leave it entirely to editorial discretion, and will recommend something specific, the shorter the better in most case. I've noted some birth/death range discussion above, and am skeptical about some of the arguments against it (and have said so), but I'm not 100% on their inclusion, either. I'm kind of neutral with a lean toward inclusion. My initial reaction to the whole thing here was "Isn't this WP:CREEP?", but I will concede I've seem some particularly crappy SDs, so some kind of guidance seems appropriate.  — SMcCandlish ☏ ¢ 😼  05:00, 1 December 2020 (UTC)

  Thanks for the thoughts, SMcCandlish. I wonder if I can lay both my concerns to rest (and maybe MB’s too) if we can include in the table a bit more range of endorsed formats. Here are couple candidate that came to mind along with their currently deployed short descriptions:

  • George Washington: 1st president of the United States – I assume this would not be appended with a date because ‘First president of the United States’ is so much more informative than ‘President of the United States from 1789 to 1797.’ Do we agree?
  • Alexander the Great: the ancient king of Macedonia – Clearly ‘the’ should be removed, but how specific do we want to be with long ago dates? Is ‘ancient’ something we endorse? Would ‘4th century BCE’ be preferred? I can’t imagine greater precision being helpful, but I’m not always seeing this the same way as the majority.

  On the subject of long ago dates, should we make a recommendation for dates that are BCE or close enough to 1 to be ambiguous? Should the format match the specific article, or should they always be BCE/CE for consistency within the search results?

  —jameslucas ^{▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄} 23:57, 1 December 2020 (UTC)

  I'd say yes on GW, but he's a special case; it wouldn't generalize to the 23rd US president or whatever. Agreed that just a century is fine for AtG. I doubt "ancient" is sufficient, since it can mean anything from Palaeolithic to Early Medieval/Dark Age, depending on the reader. It's often a way to disambiguate historical and contemporary subjects (e.g. "ancient Rome" was an empire, while "Rome" today is a city). More-specific-than-century might sometimes be needed even for "ancient" subjects, e.g. various emperors and pharaohs and queens and etc. with similar names in the same century. We should surely compress MOS:ERA for SD purposes to something like "always use BCE or BC for dates that qualify, but use CE or AD only for years between 1 and 99", or something to this effect. I would prefer to use BCE/CE for consistency within search results, but I suspect that this would be ignored, in favor of agreeing with the rest of the article text (best practice, but lost cause?).  — SMcCandlish ☏ ¢ 😼  00:18, 2 December 2020 (UTC)

I have some sympathy with SMcCandlish's comment that "Epidemic of bubonic plague, 1665–1666" or "Epidemic of bubonic plague (1665–1666)" is as clear as "Epidemic of bubonic plague from 1665 to 1666", and saves a few characters. If editors agree I can adjust the wording to make it clear that those are fine. A downside would be that that "(year–year)" is then not being reserved for lifespans, which makes the recommendations slightly less clear-cut. But it seems to me that that's not a real worry. What do people think? MichaelMaggs (talk) 22:07, 5 December 2020 (UTC)

If (year–year) were reserved for lifespans, the limitation should apply only to people and perhaps to those rare other topics which have a lifespan distinct from the period being specified: "Oldest tree in Europe from 1920 to 1960 [but lived much longer]"? Certes (talk) 22:27, 5 December 2020 (UTC)

Thanks all. I've made some final tweaks following the last few comments, and have now added the text to the main page. MichaelMaggs (talk) 14:19, 14 December 2020 (UTC)

This was a successful discussion, and I think the resulting table is helpful. Nice work, all. – Jonesey95 (talk) 16:49, 14 December 2020 (UTC)

Automatic short description proposal for songs

 You are invited to join the discussion at Template talk:Infobox song § Automatic short descriptions. {{u|Sdkb}} ^talk 09:47, 20 December 2020 (UTC)

Automated short description proposal for "YEAR in REGION" articles

 You are invited to join the discussion at Template talk:Year in region § Automatic proposed short description. {{u|Sdkb}} ^talk 20:31, 29 December 2020 (UTC)

Lists

Hi, can anyone tell me what the current practice is for putting descriptions into lists? I could not find anything in the current guidance. Thanks. Huggums537 (talk) 00:14, 18 January 2021 (UTC)

@Huggums537: for stand-alone list articles, my personal recommendation would be either not adding a short description or using "Wikipedia list article". The most recent discussion is at Wikipedia talk:Short description/Archive 7 #Lists, but there are mentions in Archives 6, 5, 4, and 2 according to an Archive search for "lists". My reasoning is that for list articles, a short description is almost invariably redundant (the article title is bound to uniquely identify the list subject), but we had no way of turning off a short description, so using a standard, mundane description would allow us to remove all of them by bot when the Wikidata link was finally removed. Hope that helps. --RexxS (talk) 01:18, 18 January 2021 (UTC)

Ok, thanks for the link because it answers my next question, which was going to be why do we have soooo many of the same descriptions on our lists, but I see experienced editors have already covered this issue. Huggums537 (talk) 02:14, 18 January 2021 (UTC)

An Idea-- Merging this template to Template:Infobox

I have an idea to merge "Short description template" and "Infobox template" and Short description be an argument of Infobox, but possibly invisible and article writers could make it visible so. I think, this way the articles become more easier to read, because user always engage in Infobox for all of the articles.

I should note that according to proposal of Tim Berners Lee that is Semantic Web all of the articles should gradually add "Infobox" to make some Structured data available for Semantic Query, and "short description" becomes one of these Structured data.

Any one have pros and cons? Thanks, Hooman Mallahzadeh (talk) 08:30, 17 January 2021 (UTC)

Any infobox can have a short description parameter if it is properly coded, but infoboxes will not be appropriate for all articles, and short descriptions also go on pages other than articles. – Jonesey95 (talk) 15:18, 17 January 2021 (UTC)

I think that just increases complexity. At present, the SD is always at the top, and presumably that's where it will stay for the vast number of articles that don't use an infobox. Making it 'hidden' within an infobox for articles that use one just makes it more difficult to find and edit. MichaelMaggs (talk) 15:37, 17 January 2021 (UTC)

@MichaelMaggs and Jonesey95:According to the principle of "Separation of concerns": 1- Text files of articles should contain only text, 2- Template section should be in a separate part, and the good place for it is in the "Template Box". I think this separation is very helpful and extremely reduces complexity. Also for templates that "its place is fix in an article", a pointer to the TemplateBox should be used, so::: TemplateBox contains all Templates, and page only contains "text" and "pointer" to the "Template box". This way is very neater to read and its maintenance is improved. Too "Semantic Queries" are better answered. I think respecting "Separation of Concerns" has may other benefits too. But if we don't want to use "Template Box" (by any other reason), we should use the "least available Templates". Placing "Short Description" template in the "Infobox" template, also reduces total templates and makes pages neater and easier for process by machine and human . Thank again, Hooman Mallahzadeh (talk) 11:59, 18 January 2021 (UTC)

I can understand the very long-term benefits of such an approach, but we are an extremely long way from "Text files of articles should contain only text". Text is currently littered with huge quantities of embededded templates including references, formatting templates, translations, conversions, date and languages preferences, For templates and Main templates to mention just a few. Is there any general consensus for a new "Template box"? I wouldn't necessarily be opposed to the concept but it's a really fundamental change to the site that's very different from "making short description an argument of Infobox", which was what you were suggesting above. MichaelMaggs (talk) 12:34, 18 January 2021 (UTC)

@MichaelMaggs: Do you think I ask and propose "Template Box" idea in the Wikipedia:Village pump? Hooman Mallahzadeh (talk) 12:45, 18 January 2021 (UTC)

You could do that, to see what people think, but you may find that Wikipedians generally don't like making huge changes to the site without (very!) extensive discussions. MichaelMaggs (talk) 12:49, 18 January 2021 (UTC)

@MichaelMaggs: Ok, I discuss it here https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(idea_lab)#Creating_a_%22Template_Box%22

ShortDescBot task 2 - organisms

I've put up a proposal at Wikipedia_talk:WikiProject_Short_descriptions#ShortDescBot_task_2_-_organisms to extend ShortDescBot add new short descriptions to all the organism articles that currently lack one. Comments are welcome there. MichaelMaggs (talk) 13:50, 18 January 2021 (UTC)