Wikipedia talk:Short description/Archive 2

Active discussions
Archive 1 Archive 2 Archive 3

Missing background and justification for mass change on this page

This page—which is what gets linked from edit summaries etc. and which is the appropriate place for it—lacks any link to the relevant history and justification for mass-adding {{short description}} to articles. You have to follow the link to Wikipedia:WikiProject Short descriptions#History to find that. I therefore suggest that that whole section gets added to this page, and possibly even expanded to summarise the salient points (closing comments from the RfC etc.) so I have somewhere pertinent to point those who object to the addition of yet another, to them, seemingly nonsensical and unneeded template. Even better would be an unambigious statement to the effect that "every article on enwp should have a short description and here's the RfC that decided that." --Xover (talk) 13:04, 2 October 2018 (UTC)

Thanks Xover. A key word in the text is should (IE - not MUST). I too would be curious to see an RfC that decided this to be added to all articles. Thanks. Lugnuts Fire Walk with Me 13:16, 2 October 2018 (UTC)
I'm pretty certain that Wikipedia:Village pump (proposals)/Archive 145 #RfC: Populating article descriptions magic word accepts that short descriptions will be added to all articles. You do understand that any articles where we don't add SHORTDESC (which we control here on English Wikipedia) will take their short descriptions from Wikidata descriptions (regularly vandalised and not under the auspices of en-wp)? Can you think of any advantage in having short descriptions in English taken from somewhere other than the English Wikipedia? --RexxS (talk) 15:49, 2 October 2018 (UTC)
I remember the whole mess of PERSONDATA. The solution to that was to bin it, and move the data to WikiData. Now we seem to be reversing that, to some degree, under the guise of Short Description. I guess it's a circular argument about which source has the least-vandalised dataset (WP or WD), and use that one. Personally, I'd lock down WD so only trusted editors can update it, but of course that will never happen. Lugnuts Fire Walk with Me 16:10, 2 October 2018 (UTC)
Then you don't remember very well. Persondata was an attempt made on English Wikipedia to circumvent the use of infoboxes in biographies. The biographical data in there quickly became out of date because nobody ever saw it. It was deemed too unreliable to move to Wikidata without first being vetted manually, so very little of it was ever used for anything. Biographical information on Wikidata is capable of being referenced, so may be usable on English Wikipedia. That has nothing whatsoever to do with short descriptions, and there's nothing circular about the argument. The "description" available on Wikidata has no means of being sourced, and so is both vulnerable to vandalism and unsuitable for use on English Wikipedia. Finally, no Wikimedia project is ever going to accept being locked down for editing by "trusted editors" because it would kill it stone dead  – just look at what happened to Nupedia and Citizendium. --RexxS (talk) 20:41, 2 October 2018 (UTC)
"The "description" available on Wikidata has no means of being sourced, and so is both vulnerable to vandalism " As does the short description tag on the EN WP. Lugnuts Fire Walk with Me 08:47, 3 October 2018 (UTC)
And I DO remember it very well. Someone had the bright idea to add the template to approx 1 million articles. And then it was ditched. I wouldn't be surprised if it happens with this too. Lugnuts Fire Walk with Me 17:31, 3 October 2018 (UTC)
The story was that the template only shows in the mobile version, but there is it important, for example, for choosing the article from the dropdown menue (I am not using the mobile version, so that I do not know any details). It was essentially imposed, and I have no idea whather it is good or not. Then the question was where does the content for the template come from. There was a RfC which concluded that it should not be coming from Wikidata (or, to be precise, the corresponding field of the Wikidata item can not be used as such template). Then the only option was tio fill the templates in from the project. But then the developers said that until a certain number of articles have a short description (100K? I do not remember), the template will be pulled out from Wikidata. This is when this project was created, and this is what all this rush was about.--Ymblanter (talk) 17:44, 3 October 2018 (UTC)
@Lugnuts: "As does the short description tag on the EN WP" But changes to the short description tag immediately show up on every single editor's watchlist for that article, and are easily countered by our own anti-vandalism patrollers. Changes to the description on Wikidata show up on hardly anybody's watchlist and can linger for indeterminate amounts of time without being fixed. Go work on the Wikidata vandalism dashboard for while to see the extent of the problem.
You clearly DON'T remember it well. The idea of PERSONDATA was obviously flawed from the start and many of us gave valid reasons why. See User:Pigsonthewing/Persondata for an example. Nobody has offered any reasoned argument why SHORTDESC is anything but a vital addition, and all of the criticism I've seen so far is speculative, uninformed hand-waving from the peanut gallery. --RexxS (talk) 21:20, 3 October 2018 (UTC)

I think we're in the weeds here. It's strictly speaking irrelevant what the opinions of the editors in this thread are, and what, if any, consensus we arrive at. A mass-change to all 5M+ articles requires wide community consensus both for a change and for what specifically to change.

The most immediate issue I raised above is that the community consensus processes that are the foundation of this activity are not actually linked, much less communicated clearly, on this page. That information is only available over on Wikipedia:WikiProject Short descriptions, and a WikiProject (which anyone can set up for any purpose) is not the appropriate place to document this nor the appropriate place to point people. That information belongs at Wikipedia:Short description.

The second issue raised, and which I take to be Lugnuts's main concern, is that mass-changing 5M+ articles really should be on a more solid foundation: typically an RfC that directly says "All articles should have a shortdesc." The current mess of discussions never actually adresses that directly. I, personally, agree that that is both the inevitable conclusion of those discussions and is implied in the questions and closing comments; but it requires interpretation which leaves de facto policy open for differing interpretations. That is a recipe for "Infobox wars"-style conflicts, which I'm assuming everyone involved would rather avoid.

I raised the issue here not to rehash the dicussions, but to: 1) get the relevant "History" section added here where it belongs, and 2) to get those most involved and most familiar with that history to distill out the most direct and solid justification (documentation of community consensus) from those discussions. The first is a cut&paste job, and, ideally, a summary of closing comments. The second is more fraught, but if the RfCs and community discussions leaves the mandate shaky then that is a good thing to document clearly.

Or put another way: I, personally, agree we (all things considered) should add a shortdesc to all articles, but when I meet with opposition from, for example, Lugnuts, who (I believe) disagrees that we should do that (nuance like whether they disagree with the "all" bit or "at all" don't matter here) we currently have no way to resolve the disagreement. Absent community wide consensus to lean on—that is easily findable and clear enough that all participants can agree on the terms of reference—that leaves local consensus on each individual article (all 5M+ of `em) which is both entirely unscalable, unlikely to be resolvable on most articles (who have only 2 watchers: the proponent and the opponent; aka. a deadlock), and apt to create Infobox-like conflicts. --Xover (talk) 07:45, 4 October 2018 (UTC)

Thanks Xover. I'm not opposed to the whole idea, per se, but it seems to be lacking a clear consensus and focus of what it's trying to achieve. Ymblanter sums it up in one word - rush. This tagging may be very useful, but at the moment it looks like a solution to a problem that didn't exist in the first place. Lugnuts Fire Walk with Me 09:37, 4 October 2018 (UTC)
Sorry I'm too lazy to find the links but the idea of putting descriptions in articles followed reports of bad vandalism to BLP articles. The decision to add descriptions to articles was not made at this Wikipedia. Instead, software development led to the situation where people using mobile devices could see descriptions that were added at Wikidata. The rush is merely a reaction to that de facto situation where articles have a description added at Wikidata or here. If Wikidata is used, almost no enwiki editors will notice vandalism. If this Wikipedia is used, anyone watching a page will immediately see vandalism, and someone who damages one description will have all their edits inspected. Johnuniq (talk) 10:40, 4 October 2018 (UTC)

Should shortdesc be added to category pages?

Basic question: should we add short descriptions to Category pages? Right now these, have a kind of short description from Wikimedia, for instance Category:Appias (genus). I can edit the description in Wikimedia, but as with articles, my opinion is that it would be good to have something local. --{{u|Mark viking}} {Talk} 18:08, 17 October 2018 (UTC)

It would naturally be better to have the description stored locally rather than drawn from Wikidata, as the RfCs that led to this template affirm. However, I would have thought that everything in the category tree Category:Animal taxonomy should have a fairly innocuous description on Wikidata, perhaps shortened from something like "Wikimedia category for a genus of butterflies" to something like "Category for a genus of butterflies" as it's already obvious that it's a Wikimedia category. I would expect that it's the sort of job that a bot could do easily, or maybe even AWB. Perhaps we need to start an RfC to gain consensus for that sort of task? --RexxS (talk) 18:38, 17 October 2018 (UTC)
Thanks for your input. Yes, some classes of categories, like taxonomy cats, already have fairly reasonable short descriptions that could perhaps be automatically transformed and included. I unfortunately have no experience in such endeavors. --{{u|Mark viking}} {Talk} 18:51, 17 October 2018 (UTC)
Mark viking, This is an endeavor where very few have any experience, You could try developing some by doing it. From my experience in article space, sometimes it is easy, other times not. Accept that you will not always get it right first time, but a non-optimal short description that is better than none is worth adding. Anyone with a better idea can improve it, like any other content. Cheers, · · · Peter (Southwood) (talk): 07:41, 18 October 2018 (UTC)
Semi-automation is probably better than automation here, as one needs to check if the suggested short description is valid before accepting it, and that generally takes a reasonably competent human. I also see that Galobtter's tool is not currently active in category space. It is very convenient in mainspace, (try it) for viewing, creating and editing short descriptions, and if there is a call for short descriptions for categories for any reason that improves the encyclopedia (I can think of a possibility, but it would need infrastrucure that as far as I know does not yet exist), then I recommend that gadget. I am not very active in categorisation, but recognise that it is both useful and important for navigation and management of structure, and would support anything that improves workflow and function. Cheers, · · · Peter (Southwood) (talk): 08:10, 18 October 2018 (UTC)
The script deliberately does not show the buttons for addition of a local short description in category space (but does show the wikidata description). If short descriptions are considered to have value in category space I can make it work there. Galobtter (pingó mió) 08:29, 18 October 2018 (UTC)

Auto-short description punctuation

After following the instructions "Enable MediaWiki:Gadget-Page_descriptions.js...", I see the following (for example): "1st President of the United States, From Wikipedia, the free encyclopedia". Can we either have a period or a lowercase f? I posted this at the js's talk page, but no response so far. David Brooks (talk) 22:45, 1 November 2018 (UTC)

Why? The "From Wikipedia, the free encyclopedia" is the usual strapline supplied by the MediaWiki software, not the gadget. The javascript simply enables you to see the short description. It's not meant to be running prose. In any case we don't add periods to sentence fragments.
Logged in on my desktop PC I get:
George Washington
From Wikipedia, the free encyclopedia
1st President of the United States
Logged out on my desktop PC I get:
George Washington
From Wikipedia, the free encyclopedia
On the Wikipedia app on my phone, I get
George Washington
1st President of the United States
A lowercase "f" in the second case (which 50% of readers see) would look silly. You can't seriously be asking the gadget to alter text that it doesn't supply just for the cases like yours where the strapline follows the short description? --RexxS (talk) 01:17, 2 November 2018 (UTC)
I'm aware of the other uses of the short description and the strapline. I'm just hoping that the line generated by this gadget could be tweaked so as not to hurt my eyes. I do appreciate that it's essentially a debugging tool so of secondary importance.
Just in case there's a misunderstanding, this is the line that gets generated at the very top of an article under the title heading and indicates whether the description comes from the article or Wikidata, or is absent. On my system it's a single line in smaller font, so maybe we're not looking at the same thing. Another example, Proboscis monkey (which I happen to have open) has this at the top: species of mammal (Wikidata), From Wikipedia, the free encyclopedia (the word Wikidata is linked to an editing tool). I personally have no objection to a period after a sentence fragment; it's certainly better-looking than a comma before a capital. But, of course, only if it can be fixed without disturbing the other, legitimate (customer-facing) uses. David Brooks (talk) 02:24, 2 November 2018 (UTC) ETA: I use the Vector skin, in case that matters. David Brooks (talk) 02:25, 2 November 2018 (UTC)
Update: RexxS's examples don't contain a comma, while mine definitely does. I wondered where it comes from, but now I look more closely realize it's most likely in MediaWiki:Gadget-Page descriptions.js itself in two places: $description.append( ', ' ); and another more-concatenated version. I'll take the question over to the js's talk page, although nobody replied over there last week. David Brooks (talk) 18:37, 8 November 2018 (UTC)

Place of short description in the article code

There are differences of opinion as to where this should go. I suggest that right at the top before hatnotes or banners is where it should be diplayed for anyone who wants it to be visible, which may be a large number of editors wishing to monitor the quality of short descriptions on all the articles they look at, without having to open in edit mode. Other positions further down the page would look a bit strange and unexpected, particularly if you use a highlighted display to make the short description look unlike the rest of the content. It may be possible for the template to force display at the top no matter where it is in the wikicode, but I do not know if it is possible, or how much extra work and processing time that might take. It may be trivial, or may be a huge hassle. Displaying at the top when it is at the top is trivial, it takes one line of css. There are other opinions, but the reasoning for them has not been detailed. · · · Peter (Southwood) (talk): 21:03, 23 February 2018 (UTC)

There are two possibilities: (1) At the top where every editor will see it, or (2) at the bottom where it would be hidden among the navboxes and categories. I favor the top because a description that appears at the top of the page (in mobile) would be editable in an obvious place, namely the top. Also, using the top will get most editors used to the concept quickly, whereas people might not notice it for years if it were one of the miscellaneous bits of stuff at the bottom. Johnuniq (talk) 23:03, 23 February 2018 (UTC)
I favor the bottom, where its presence seems less likely to precipitate content disputes over wording. It is the prospect of time lost to disputes over wording that gives me the most pause about the implementation of the template. Dekimasuよ! 02:55, 24 February 2018 (UTC)
Discussion about wording is one of the primary quality assurance mechanisms on Wikipedia. I don't think we should hide part of the content from view in order to avoid critical assessment and possible improvements. There will occasionally be squabbles, but until this is shown to be a globally significant problem, I don't think we should make things more complicated. I dont think this will be any more controversial than other content. Is there any evidence indicating that the cure will not be worse than the problem?
Getting editors used to the concept quickly is important if we want to get WMF to stop using Wikidata over a reasonable timespan. We need editors to start creating and improving short descriptions sooner rather than later. There is no way that I can do this on my own. I want to get back to the things I really like doing, and this is not one of them. I expect to do thousands, even tens of thousands in the long term, but there are millions to be done. · · · Peter (Southwood) (talk): 15:00, 24 February 2018 (UTC)
I also favor placing this template at the top of the articles, in part because of the reasons already expressed, and in part to put it in line with WP:ACCESSIBILITY—if the Short description template is at the top of the article, it will be quickly found by screen readers, giving the person investigating the article the information quickly. In my opinion, for that reason, it should go immediately after the disambiguation links. —DocWatson42 (talk) 06:44, 20 November 2018 (UTC)

huh?

What does this mean "The short description function is to disambiguate not only from current ambiguities, but also from reasonably probable future ambiguities."? Can we rewrite this in plain English? Or at least give an example as to what this means. --David Tornheim (talk) 06:30, 26 December 2018 (UTC)

@David Tornheim: If you look at the article Bread, you'll see that the short description is "Staple food prepared from a dough".
If you look at the article Bread (band), you'll see that the short description is "American rock band".
The short description can be displayed in various places, e.g. in a search, and the short description can be used to help resolve current ambiguities.
If you look at the article Cheese, you'll see that the short description is "generic term for a diverse group of milk-based food products".
If a notable rock group came along called "Cheese", then the short description would help resolve that reasonably probable future ambiguity.
Feel free to re-write in plainer English if you're able. --RexxS (talk) 14:18, 26 December 2018 (UTC)
@RexxS: Thanks for reply. So does it mean that if there are multiple definitions for the same word (or phrase), the wikilink and short description can be used to indicate which definition is being referred to? --David Tornheim (talk) 20:35, 26 December 2018 (UTC)
@David Tornheim: sorry, I don't understand your question. Could you give an example? --RexxS (talk) 21:19, 26 December 2018 (UTC)
David Tornheim, In a way yes, an annotated link will usually adequately disambiguate by describing the specific usage sufficiently for most purposes. In another way no, as the same word, or phrase, cannot be used on Wikipedia as a title for multiple articles. One could use annotated links on a disambiguation page to clarify what the topic is for each article, but the link is usually already disambiguated to a lesser extent by the variations in title. Not sure if this answers your question, so please ping me if you meant something else. Cheers, · · · Peter (Southwood) (talk): 05:59, 27 December 2018 (UTC)
@Pbsouthwood: Thanks. I had not thought of using the short definition for the disambiguation pages, but that seems like an excellent use.
I do see a potential problem with various uses of the same short definition: Some uses might demand shorter or longer definitions than others. I hope there is a way to figure out every page that uses the short definition, whether as an annotated link or otherwise. Perhaps, we should leave a note saying, "If you change the short definition, please check all the places where it is used to make sure it does not cause problems. Here's how: ... " --David Tornheim (talk) 06:44, 27 December 2018 (UTC)
I am not aware of a way to find all the pages that use a short description in an annotated link. Of course that does not mean there is no way. We will just have to live with short descriptions that may change without notice. All we can reasonably ask is that they get improved by a change.
We have a very large number of redirects to sections for things that do not currently have an article for whatever reason, but are still worth a short description, both as a potential annotation, or to disambiguate search results, so I tend to add them quite often, and as a by-product, also create quite a number of new redirects with potential and redirects to a section. In the end it all builds the encyclopaedia so I consider it time well spent. Cheers, · · · Peter (Southwood) (talk): 07:27, 27 December 2018 (UTC)

Question

Is it acceptable to put Wikilink in the short description as I did here? When I tried this--using a vertical bar in a wikilink--it didn't work. I'm guessing template had priority use over the vertical bar and thought the vertical bar was another parameter, right? If there is a good manual on "templates for beginners", I am all ears. Most of the template documentation seems to be written for the template creators rather than the users. --David Tornheim (talk) 06:36, 26 December 2018 (UTC)

There's no point in a wikilink in a short description used in the dropdown for a search because the reader wouldn't benefit from having a link that they couldn't return from. If it's used as a sub-heading as it is in the Wikipedia app, then perhaps it might have value, but there's usually a reluctance to have links inside heading elements. As the parser normally processes wikilinks before template parameters, I suspect that the magic word SHORTDESC, inside the template, is discarding those links. You could test that by trying {{SHORTDESC:A network of river channels separated by small, and often temporary, islands called [[braid bar|braid bars]]}}.
If you need to use a vertical bar in places where a template might confuse it with a parameter, then you can use {{!}} which will create the vertical bar after the template parameters have been resolved., so you could try that, but I'm not hopeful.
Almost all of this is of so little use to most users that the documentation remains cryptic, because there's no demand for better documentation. Maybe you can convince somebody to write that "templates for beginners" manual, if you can find somewhere to ask for it. --RexxS (talk) 14:41, 26 December 2018 (UTC)
Thanks for the response and explanation.
My particular case was the section Fluvial processes#Fluvial channel patterns, which uses "annotated links" to define each term:
show example
The following discussion has been closed. Please do not modify it.

Fluvial channel patterns

  • Channel pattern – Characteristic geometry of a channel system
  • Braided river – A network of river channels separated by small, and often temporary, islands
  • Meandering river – A sinuous bend in a series in the channel of a river
  • Anastomosis – A connection or opening between two things that are normally diverging or branching
Originally, braid bars had no wikilink. This section is for defining specialized terms and providing wikilinks to those terms. So it makes sense to wikilink the specialized term braid bar. The only way to do that is to either change the short description or copy the wikitext of the short description and change it at the article.
My first reaction is that I am impressed by the use of short description that can be transcluded to multiple articles to keep the article concise--although much more confusing to novice editors and potential for a change in the short description to unexpectedly mess things up at other articles. I believe we may see more of this in the future. If so, it is worth thinking how an increase in this particular use might mean that more editors will want wikilinks in the short descriptions. --David Tornheim (talk) 20:56, 26 December 2018 (UTC)
@David Tornheim: It's helpful for these cases that {{Annotated link}} will pass the text of the short description to the parser so that links such as [[braid bar]]s render properly when used in an article.
Unfortunately, the downside is that when you search on the Wikipedia App for braided, you get a link to Braided river as a suggestion with the following description below that: A network of river channels separated by small, and often temporary, islands called [[braid bar]]s. That is not desirable for viewing on the App, so I expect at some point there will be complaints about having links in short descriptions.
The only work-around that I can suggest for now is removing the link from the short description and altering Fluvial processes#Fluvial channel patterns to read:
  • Braided river – A network of river channels separated by small, and often temporary, islands. A braid bar is a landform in a river.
The long-term solution would be to file a phabricator ticket asking for the Wikipedia App to filter out wiki-markup from short descriptions before displaying them. --RexxS (talk) 21:52, 26 December 2018 (UTC)
@David Tornheim: Where a short description by itself is insufficient annotation, one can add additional material that will display after the short description with whatever links and other formatting best suits the application, exactly as RexxS has demonstrated above. My position is that the use of annotated links may not always be the optimum annotation in index lists, "see also" sections and other list sections, but it is usually better than no annotations, which is very common, and can usually provide a useful first approximation, which can be expanded as in RexxS' demo.
If a term in a short description is unclear, it is probable that in most cases it will be clarified in the linked article. In some cases this may be sufficient.
Sometimes it is possible to just add another annotated link to the list for the term to be clarified.
It is often useful to add a specific short description to a redirect, particularly a redirect with potential to become a full article, or a redirect to a section. Cheers, · · · Peter (Southwood) (talk): 06:26, 27 December 2018 (UTC)
There is a risk when adding an extension to an annotated link, that the short description may be changed, leaving a non-sequitur, so try to use annotation extensions that make sense when used with other possible short descriptions. · · · Peter (Southwood) (talk): 06:42, 27 December 2018 (UTC)
That long term solution of filtering out the wiki-markup may well be a good solution. · · · Peter (Southwood) (talk): 06:48, 27 December 2018 (UTC)
Thanks for the above suggestions. I do not like the solution of:
  • Braided river – A network of river channels separated by small, and often temporary, islands. A braid bar is a landform in a river.
for two reasons:
(1) The first sentence gave enough information. Concise is almost always best. We should not have to change the text of an article to deal with problems with a template.
(2) It is probably not a good idea to add sentences after short definitions, especially because short definitions might change and the text of the short description cannot be seen when editing the article. This kind of hyrid I think will lead to unnecessary problems and confusion. As an experienced editor, it was confusing enough to have the annotated link, which I had never noticed or tried to modify in an article before.
I dislike the solution of:
  • Braided river – A network of river channels separated by small, and often temporary, islands
  • Braid bar – Depositional landform in a river which splits a channel
for similar reasons, especially reason (1).
If the short description cannot or should not handle the wikilink, I prefer not using the annotated version for the above case. However, right now the wikilink appears to work.
I'm a little confused as to whether having a wikilink within the short definition of braided river is ultimately going to be a problem or not. I think this should be spelled out clearly and directly in the directions for using the template for short description as whether it is or is not okay to use wikilinks in short descriptions. If it is okay, any potential problems or limitations must be explained, such as above. Should we hold an RfC on that?
RexxS described this problem:
Unfortunately, the downside is that when you search on the Wikipedia App for braided, you get a link to Braided river as a suggestion with the following description below that: A network of river channels separated by small, and often temporary, islands called [[braid bar]]s. That is not desirable for viewing on the App, so I expect at some point there will be complaints about having links in short descriptions.
I have never used the "Wikipedia App", so I really have no idea how or why anything I add to an article that displays properly on my computer will get messed up on the App. That's somewhat concerning. Isn't this really just a bug with the Wikipedia App? I had assumed that if an article displays correctly on a browser on a computer, it is fine. Is that no longer a safe assumption for our articles?
I do know, from having recently taken a course on HTML, there are now flex designs, and it is advised to test HTML pages on laptops, cell phones and tablets, to make sure the code scales as desired. Do we have problems with that? --David Tornheim (talk) 07:27, 27 December 2018 (UTC)
David Tornheim, I agree that in most cases where an annotated link is appropriate, is will work best as a stand-alone item for the reasons you mention. Occasionally it may be otherwise.
If annotated link does not work as well as another option, use the other option. Annotated links are for where they are good enough. Usually where there is no annotation yet and where a concise description is both possible and sufficient, and where an update is unlikely to break anything. There are probably millions of places this will work, and an unknown number where it will not work.
I also don't have the Wikipedia app as I don't use data on my phone. From what I understand, Wikipedia does not work so well on mobile, as it was written for desktop, and the fixing will take some time and effort. Not my skill set. I leave testing on assorted platforms to others. In theory, you can switch between mobile and desktop view on both platforms, but that does not guarantee you will see what the other hardware will show.
The short description appears to display wiki-markup as plain text including the markup characters in the short description viewing and editing gadget. I avoid using markup in short descriptions. I do not know if in the long term it would be good or bad to have wiki-markup in short descriptions. My guess is that it would not be too difficult to filter them out, but it may be worth finding out before opening an RfC. At the moment I have no reason to oppose, but also no very strong reason to support. Cheers, · · · Peter (Southwood) (talk): 08:53, 27 December 2018 (UTC)
@Pbsouthwood: Thanks for both the most recent replies here and above. I'm about ready to leave this discussion. I think the next step is to check in with those who wrote the template as to whether they think filtering out the wikimarkup is the way to go, or even better fixing the App :), or just not using Wikilinks at all. Even though I love coding, I have not got into coding on this project yet. I'm open to it though, especially now that I just took the HTML class.
And, yes, you are correct that you can look at the various formats on the computer quite easily. With Firefox, hit CTRL-SHIFT+M, and it will show how the page would come up on a mobile device. You can also type in different device sizes in the boxes at the top. On Google Chrome, hit CTRL-Shift+I (to get to developer's tools to show HTML code window), then CTRL-SHIFT+M. I believe the other browsers use similar commands. This is all part of Responsive_web_design. The best site that explains the latest HTML5 and CSS3 codes IMHO is [w3schools]. Their page on this subject is [Responsive Design].
As for testing the Wikipedia App on my laptop, I still have no idea. --David Tornheim (talk) 22:36, 27 December 2018 (UTC)
@David Tornheim: I think you'll find that I wrote the template in question (or most of it), and I guess you already know my views on filtering out the wikimarkup where it's not useful. However, most of the functionality you're concerned with comes from the magic word SHORTDESC which writes a description to the article database. In brief, there is an extra field in the article database for "Central description" and "Local description". These are visible if you follow the [Page information] link in the tools menu of an article. They can be accessed through the Wikipedia API and are used for multiple purposes, such as helping to disambiguate search suggestions and as a sub-title for articles in the Wikipedia App. We are making further use of them in {{Annotated link}}, but as we have discussed, the latter use would benefit from inclusion of wikimarkup, while the other uses would not. The developers who implemented this feature almost certainly never anticipated a use like {{Annotated link}}, so I think there would be value in you expressing your thoughts to them. They're probably already sick of hearing it from me :) --RexxS (talk) 23:54, 27 December 2018 (UTC)
Thanks for your work on the template. Where should I express my concerns to them? --David Tornheim (talk) 05:49, 28 December 2018 (UTC)
@David Tornheim:, Phabricator would probably be the best place, you can find links at Wikipedia:WikiProject Short descriptions#History. If you wish to communicate with the person who dictated the specifications, that would be User:DannyH (WMF) Good luck, and I would appreciate feedback on any developments. Cheers, · · · Peter (Southwood) (talk): 06:31, 28 December 2018 (UTC)

Hi David Tornheim: Below are screenshots for the three major use cases we created the SHORTDESC magic word for: the article display on the Wikipedia apps, search results and suggestions in the link editor. As you can see, using a link in the short description shows up with brackets around the link in the article display. I think having a link in that display is probably not necessary, because there's a link in the article to Braid bar in the first sentence of the article. The snippets used in search results and link editing are too short for the link to show up, and you wouldn't want to click on a link in those contexts anyway. I think this is the first time I'm hearing about Annotated link, so I'm not sure what the use case is there. -- DannyH (WMF) (talk) 20:31, 1 January 2019 (UTC)

@DannyH (WMF): Thanks for the reply. I'm not seeing the square brackets in any of those screen shots. Is there a way to just filter them out, so that the annotated link shows correctly, as here:
Code: {{annotated link|Braided river}}
Result: Braided river – A network of river channels separated by small, and often temporary, islands
--David Tornheim (talk) 20:40, 1 January 2019 (UTC)
David Tornheim: If you look at the first screenshot, you'll see the short description written in gray text below the article title. It says:
A network of river channels separated by small, and often temporary, islands called [[braid bar]]s
As I said, having a link in that section of the page isn't really necessary, because there's already a link in the first sentence. -- DannyH (WMF) (talk) 20:59, 1 January 2019 (UTC)
Sorry. I didn't look at the gray text.
having a link in that section of the page isn't really necessary, because there's already a link in the first sentence. But in the other application of the short description mentioned above, the Wikilink is useful. Is it possible to fix the App so that it understands that it is a Wikilink and just filters out the square brackets? --David Tornheim (talk) 21:04, 1 January 2019 (UTC)
(edit conflict) @DannyH (WMF): Thanks for engaging here. I'm sure you'll appreciate that Wikipedia editors are a resourceful lot, and will often find uses for functionality that the WMF developers never anticipated. In most articles, there is a See also section containing links to other relevant articles. The Template:Annotated link creates a link to an article as usual, but supplements it with that article's short description, making the See also section far richer, such as at Scuba set# See also and many others. One additional, slightly different, example can be seen at Fluvial processes #Fluvial channel patterns.
Now, while the use of short descriptions was limited to the three applications you were aware of, we would all agree that having wikimarkup in the short description was unnecessary. However, once there has been found a use for the short description in normal article text (such as {{Annotated link}}), it's clear that the ability to include wikimarkup becomes useful. In that case, I suggest that you might apply a filter to remove wikimarkup from the string stored by the SHORTDESC: magic word. That would allow the API to return clean data for your three major use cases, and seems like a sensible sanitisation anyway (helps prevent nonsense or code injection vandalism from Wikipedia or from Wikidata). {{Annotated link}} doesn't rely on calling the API, so would be unaffected. --RexxS (talk) 21:09, 1 January 2019 (UTC)
Thanks for the comment. I agree 100%. --David Tornheim (talk) 00:20, 2 January 2019 (UTC)
Hi RexxS and David Tornheim: I do appreciate the amazing ingenuity of Wikipedia editors. This is a new feature request, and it's probably not something that we're going to take on right now. The team that worked on short descriptions did some extra work to create the SHORTDESC magic word specifically for English Wikipedia, and they've moved on to other projects. You can file a Phabricator ticket for this, and it may get picked up. If it doesn't, then it could be a proposal in the next Community Wishlist Survey. -- DannyH (WMF) (talk) 01:20, 2 January 2019 (UTC)
So it looks like we are stuck with the usual option of making our own hack if we can, and possibly leaving a string of consequences which will have to be sorted out later by the devs because they don't have the time or inclination to support clean fixing now. No real surprises here.
Let us consider what could happen if editors just add wikimarkup in the short description. Does it further our needs? It looks quite possible, we already have an example of a possible use. I for one, am not going to go searching for cases and remove wikimarkup, as I have no objection to it. I see advantages for article space applications. It is not my fight to argue against this use. If it messes up WMF chosen uses, that is their problem. If they want to go round changing it, they can deal with the possibility of edit wars and getting blocked for edit warring, since there is no Wikipedia policy or guidance deprecating the use of wikimarkup in short descriptions. Or they can open an RfC to try to get consensus for any such guidance or policy. Or they can try to enforce by fiat. That always turns out well – ask the guy who forced superprotection. Or they can make code changes to filter out the markup. Oh, wait, that is what we suggested in the first place. Not my circus, Not my monkeys. Cheers, · · · Peter Southwood (talk): 02:36, 5 January 2019 (UTC)
Thank you, Peter, for expressing exactly what I wanted to say. --RexxS (talk) 10:44, 5 January 2019 (UTC)

Please add a proper introduction

I just saw an editor add the short description template for the first time, and being on desktop I didn't see any function, so I visited the template, which led me here.

PLEASE add a proper introduction, since currently, this page takes short descriptions for granted. But they're not, they're some kind of meta data voodoo hoodoo, at least until properly explained.

This page currently TELLS people what to do. It does not seek acceptance, and comes off as rubbing editors the wrong way.

Here's a few starter questions this page either needs to resolve directly, or prominently send the editor elsewhere for the definitive page on the concept of short descriptions.

  • This is "only" an information page? Where's the associated policy?
  • Can I just remove short descriptions where I find them if I don't like them?
  • Who came up with this initiative? Where can see the community decision to use them on English Wikipedia?

The steps needed to even see them on desktop Wikipedia seems WAY out of line. Have we really decided to add something you can't even see without adding gadgetry or advanced coding (advanced for the average user, that is)?

The section about not finding the code suggests a horrendous case of unmanageable information. Please don't tell me you find it acceptable to have to hunt through MULTIPLE LAYERS of templates, tag codes and css. Honestly, this gives off every warning signal of a programmer's solution, with way too little common sense oversight. (Compare how the community here on en.wiki managed to stave off wikimedia's horrendous new talk page editing layout) Please tell me we are not satisfied with this technically complex solution, that is entirely inaccessible to an average user, and are assigning staff to simplify to the level of regular wiki editing.

Suggestion: display what's in the {{short description}} template right on the page, and ignore each and every other source. No template = empty description. Layered or hidden template = empty description. No exceptions. Keep it simple, sweetie. Do it right now. As today. CapnZapp (talk) 11:04, 4 January 2019 (UTC)

Short descriptions (SDs) were introduced mainly for the benefit of readers searching for articles in mobile view, where an SD appears beneath each title listed in search results. Originally they were all drawn from the Wikidata "description" field. The idea of the present project is to bring SDs seen by Wikipedia readers under the control of Wikipedia editors, on the grounds that many Wikidata descriptions are missing, many are unsuitable in various ways, and all are potentially subject to damaging edits which we might not quickly spot.
Recent discussions will be found on this talk page and Wikipedia talk:WikiProject Short descriptions. Key RfCs leading up to this project are here and here. I hope this helps to put you in the picture. (Others have expressed reservations too, but there is no need to rant): Bhunacat10 (talk), 12:49, 4 January 2019 (UTC)
Please integrate all this info in the article itself. It needs to be there, not here. CapnZapp (talk) 21:03, 4 January 2019 (UTC)
@Pbsouthwood and RexxS: Well what do you think? It seems probable that many regular editors remain unaware of this ambitious scheme to add SDs to millions of articles, and people pop up all over asking what's going on, querying the justification, wanting to know where it has been discussed and agreed and so on. Seems to me that more publicity would not only make the community better informed but would hopefully bring in some fresh participation to a project that, after a promising start, appears to have rather stalled. How about getting this WikiProject featured in the Signpost soon?: Bhunacat10 (talk), 23:48, 4 January 2019 (UTC)
Not that I was asked, but since learning about this project, I add an SD to every article I touch, unless I feel the SD would be redundant (e.g. putting a Season of NHL team on an article about the 1989-90 New York Rangers Season, or something of that ilk). Since I do quite a bit of work on NPP, it is starting to take hold there. Editors who see me adding the SD to their articles, start to do so on their own. Anything to bring more folks to this project would be a good thing. Onel5969 TT me 00:22, 5 January 2019 (UTC)
I try to also add a short description to every article I open, unless I can't come up with a good one in a reasonable time (or occasionally just forget). I am glad to hear it is slowly catching on, as there are still a lot to do. In passing, there are readers who do not know that the New York Rangers are an NHL team, so that would have been better than no short description. They also probably don't know what NHL means.
CapnZapp, what all do you suggest goes into this introduction you request? Could you suggest a structure that would provide all the information you think is necessary?
There is no "associated policy", any part of any policy that exists for content and conduct may aply to a specific instance or event. Guidance is developing, as it does.
Short descriptions were imposed on Wikipedia by WMF as the alternative to using the descriptions provided by Wikidata, which are of highly variable quality, and hosted outside of Wikipedia. The full background is available via links, if you wish to inform yourself. This includes the discussions and the reluctant acceptance that we are over a barrel on this. If you think more of the background should be included in an introduction, feel free to propose an example.
Making the short description directly visible in the article does not have consensus. It has not been proposed by RfC. If you think that it should be displayed by default, please get some support first, as this is a change with wide-ranging consequences, and I am not sufficiently bold to make that level of a change without getting a broad consensus first. Please feel encouraged to start an RfC yourself, and notify the Wikipedia:WikiProject Short descriptions if you do, as we would be interested and affected parties.
If you do decide to remove short descriptions, it seems very likely that it will be considered disruptive editing. This is only my opinion, and you can take the chance and find out by experiment if you think that would be a good idea. Replacing with a better short description is entirely acceptable, as they are ordinary content. If someone else decides your improvement is not an improvement it could be reverted, so it would be prudent and polite to explain your reasons, just like for any other content revision. · · · Peter Southwood (talk): 04:10, 5 January 2019 (UTC)
Bhunacat10, An article in the Signpost could be useful. I am trying to get some stats on numbers of editors adding short descriptions, and how many they have added, but not making much headway, as I don't know how to do it myself. Do you think it is stalled? If so, why? The initial burst was grabbing the low hanging fruit of relatively easy inclusion in other templates for generic short descriptions. What continues is adding the majority of short descriptions which require human editor input, because the general case actually requires intelligence and competence. · · · Peter Southwood (talk): 03:42, 5 January 2019 (UTC)
Good discussion, and I don't want to disrupt this desire to publish the effort. Let me just explain once more: Please don't treat me as an editor wanting to know for personal benefit. Please treat all my questions as things the article should answer. That is, please pretty please don't reply to me here at talk and think the job is done - instead use my questions (and the provided answers) as food for thought on how to improve the actual article. It is currently not written to cater for the editor that knows nothing about the project, and comes here equally curious and suspicious. Thank you. CapnZapp (talk) 10:11, 5 January 2019 (UTC)
I sympathize with your unhappiness about the lack of information regarding wtf a short description and its template are. However, the recent edits are quite wrong. The WMF did not "impose" anything. I don't have time rehash history at the moment but in brief the WMF have been trying to improve mobile access to Wikipedia for years (a good thing). A fundamental problem on devices is that navigation is difficult (you can't really have multiple tabs and switch back and forth). People find a topic from a search. As they type a description of an article they are looking for, alternatives are suggested. The titles often do not help so a short description is added to clarify what you will see if you visit that article. The short descriptions are essential for mobiles so they were added at Wikidata. Then people here (justifiably) complained because vandalism on Wikidata could show, for example, "expletive doofus" as the description for a politician. Editors are enwiki would not see the vandalism but mobile users would. Therefore the WMF provided a mechanism whereby descriptions at Wikidata could be overridden with a description added here. Editors here can choose to display short descriptions. More importantly, anyone watching an article would see vandalism that changed the description. Johnuniq (talk) 10:33, 5 January 2019 (UTC)
I heartily encourage you to use your superior knowledge to improve upon my flawed attempt! Please don't just revert back to the non-informative state the article was in before, though. Cheers CapnZapp (talk) 10:37, 5 January 2019 (UTC)

(edit conflict)There. A very quick and rough clean-up. Hope that helps. CapnZapp (talk) 10:34, 5 January 2019 (UTC)

User:RexxS (Replying to your revert) I didn't remove it because I didn't think it was useful. I removed it because I don't find that it is properly placed so prominently in an introduction to the concept. I removed because I want y'all to find a better place for such detail. Catering to all users does not mean we should abandon user-friendliness, something that this page was sorely lacking. I won't contest your revert - I just wish you saw what I see: it is misplaced at its current location. Cheers CapnZapp (talk) 13:51, 5 January 2019 (UTC)
More generally, I won't get involved even if y'all revert all of my changes. After all, I can't save you from yourselves. If you don't see my points about accessibility and talking directly to readers in regular English, and noone else on the team does, then all I can suggest is: maybe create another page to use as an introductory landing for regular editors? Leaving you to it - regards CapnZapp (talk) 13:55, 5 January 2019 (UTC)
CapnZapp, You may find people are happier to discuss proposed changes when you don't delete material to make a point, but rather explain why you think it should go somewhere else, or alternatively move it constructively to the somewhere else of your choice, and for the convenience of all, an explanation of why you chose that place is generally appreciated. Since you added a couple of maintenance tags, and we have done some changes in an effort to make the explanation both technically correct, and non-tech friendly, I call on you to please take a look and see if the explanation now works for you. It would be appreciated if you would explain any remaining problems in the same simple and accessible language that you expect others to use, here on this talk page. Cheers, · · · Peter Southwood (talk): 14:18, 5 January 2019 (UTC)
(edit conflict) @CapnZapp: What you fail to understand is that we are all volunteers on this project, and I don't take kindly to you setting the agenda for what I have to do. You have exactly the same obligations to the content on this page as we all have, so you're expected to help out by improving the page just as much anybody else is. If you can't find a better place yourself for a useful piece of information, then leave it alone. Getting rid of it isn't improving what is there. If you think the page isn't user-friendly, then try to improve it, not remove it. You have made no valid points about accessibility nor about talking directly to readers. This page is for editors, not readers, and on Wikipedia we do expect a certain degree of competence for editors, so we don't need to talk to them as if they had the reading age of a 12 year-old. There is no "team", so if you want a simplified introductory page, go ahead and write it yourself. Just don't expect the other editors here to do the work that you demand for you. --RexxS (talk) 14:28, 5 January 2019 (UTC)
Peter You asked: Do you think it [the project] is stalled? If so, why?
As this is at a tangent to the rest of the thread I've put my thoughts over at Wikipedia talk:WikiProject Short descriptions#Progress with adding short descriptions: Bhunacat10 (talk), 12:31, 6 January 2019 (UTC)
Fair enough, · · · Peter Southwood (talk): 13:35, 6 January 2019 (UTC)

Local descriptions edited in iOS app

Just as a minor update: It’ll be possible to edit already existing local English Wikipedia short descriptions in the version of the iOS app (6.2) planned to be released in January. This is currently not the case. See phab:T206786 for more information. /Johan (WMF) (talk) 19:31, 11 December 2018 (UTC)

This has now included in the latest beta release of the iOS app. /Johan (WMF) (talk) 07:51, 14 January 2019 (UTC)

Random divs

Starting today, every edit I make adding this template appears with random div tags around it (example). Other edits do not have this problem. Any idea what might be going on? Nikkimaria (talk) 13:20, 9 February 2019 (UTC)

@Nikkimaria: i'm not seeing anything that should cause that. Can you check whether the same thing happens if you're using a different browser or any alt account you might have? --RexxS (talk) 14:03, 9 February 2019 (UTC)
Hm. Logged out and logged back in, and that seems to have sorted it, for whatever reason. Odd. But thanks for looking into it. Nikkimaria (talk) 17:27, 9 February 2019 (UTC)

Could someone add an example of the "noreplace" parameter?

It would help me understand how to allow templates to autogenerate short descriptions that can be overridden. Thanks guys. --Daviddwd (talk) 18:34, 18 February 2019 (UTC)

@Daviddwd:
When there is more than one short description defined on a page, the last one normally replaces all of the previous ones. That's a nuisance if we actually want one of the earlier ones to display. So we find a way to tell a short description not to replace any previous ones. That's where the noreplace parameter comes in. For example:
In Template:Disambiguation page short description which is a generic template for placing somewhere on disambiguation pages, it contains this:
  • {{short description|Disambiguation page providing links to topics that could be referred to by the same search term|noreplace|pagetype = Disambiguation page}}
That sets the short description to "Disambiguation page providing links to topics that could be referred to by the same search term".
However, if somebody manually added a better short description at the top of a particular disambiguation page, that would become the short description for that page. That's because the Template:Disambiguation page short description has the noreplace parameter, so it does not replace the earlier description at the top of the page.
Is that the sort of thing you're looking for? --RexxS (talk) 19:24, 18 February 2019 (UTC)
Yes, exactly. Thank you!! --Daviddwd (talk) 01:40, 19 February 2019 (UTC)
(also, I thought this was the Template talk for {{Short description}} at the time of posting 😅) --Daviddwd (talk) 01:41, 19 February 2019 (UTC)

Generic short description on redirect templates

Would it be useful to add generic short descriptions to redirect pages on templates like {{Redirect template}} like {{Disambiguation}} did with {{Disambiguation page short description}}? It could be simple text like "Wikimedia redirect". –eggofreasontalk 20:06, 27 February 2019 (UTC)

Template-protected edit request on 6 March 2019

I created Category:User pages with short description to hold pages from that namespace; please change the code so that pages from that namespace go there rather than defaulting to the top level Category:Pages with short description. Thanks! UnitedStatesian (talk) 14:31, 6 March 2019 (UTC)

  Done {{3x|p}}ery (talk) 22:41, 6 March 2019 (UTC)
Return to the project page "Short description/Archive 2".