Wikipedia talk:Wikidata/2017 State of affairs/Archive 12

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 5

←

Archive 10

Strategies for improving the descriptions

Hi everyone,

Following up on Jon's summary of the concerns, I'd like to explore some of the options we have for making the Wikidata descriptions better and more reliable.

To start with, the screenshot here is an example of how the descriptions are useful for navigation. This is the "top read" feature on the iOS Wikipedia app, which shows the articles with the highest pageviews for each day. I look at this every day; it's one of the ways that I keep up with what's happening on Wikipedia, and in the world.

In this case, I think 3 of the 5 top articles benefit from having a short description -- I have no idea who Gennady Golovkin and Canelo Álvarez are, and having them described as "Kazakhstani boxer" and "Mexican boxer" tells me whether I'm going to be interested in clicking on those. (The answer on that is no, I'm not really a boxing guy.) I know that Mother! is a 2017 film, but I'm sure there are lots of people who would find that article title completely baffling without the description. Clicking through to the full list of top read articles, there are a lot of names that people wouldn't know -- Amber Tamblyn, Arjan Singh, Goran Dragić. This is a really popular feature on the apps, and it would be kind of useless without the descriptions.

That being said -- I've also occasionally been annoyed and mildly embarrassed by a description. I read the Wikipedia article on Evil clown on the app a while back, and the description said "Evil clowns are evil clowns that are scary" -- an obviously juvenile description. When I got to my laptop, I went to Wikidata under my volunteer account, and changed the description to "Pop culture trope". But I only knew how to do that because I work at Wikimedia. If I was still a Wikipedia volunteer contributor who didn't go to wiki conferences, I don't know if I would have heard of Wikidata, and I wouldn't know how to fix this.

So I think it's important to find a way to keep the usefulness of the short descriptions, and improve the quality and reliability. There have been several different options proposed here, and I want to summarize them, look at some pros and cons, and then talk with everyone here about changes that the product team/communities can work on to make this better. I'm sure that I'll miss some stuff, so it would be great if folks could help me fill in the gaps.

1). Having more eyes on the descriptions, encouraging people to fix mistakes

This is one of the goals for allowing people to edit descriptions from the Android app. If there are more good-faith people looking at descriptions and it's easier to edit them, then vandalism gets reverted faster, and inadequate descriptions are replaced by better ones.

The potential con: it's also easier for bad-faith people to edit the descriptions, and we're not sure how quickly those would get picked up and reverted/corrected. This is also true for well-meaning people making "bad edits", as Jytdog points out in the Vandalism on Wikidata discussion above; these might not be picked up as vandalism, but need to be corrected all the same.

I'm not totally familiar with how the moderation works on Wikidata; hopefully folks can help me out here. Are there enough people watching items to patrol descriptions effectively? When the apps team rolled out description editing on the Russian, Hebrew and Catalan apps, the data they collected shows that 4.6% of the description edits were reverted. This will need to scale to English.

I see a recent discussion on the Wikidata:Project chat -- "Pending changes?" -- where people are acknowledging that vandalism is an issue, and suggesting either a pending changes system or using ORES or bots to surface likely vandalism on items that have Wikipedia pages. That's potentially an area that we could support.

2). Including Wikidata description edits in Wikipedia recent changes, watchlists, history

Surfacing Wikidata description edits to Wikipedia editors would provide more experienced eyes who could look at the edits, and make sure the descriptions are appropriate and accurate.

The Wikidata team is currently working on separating out the relevant changes to surface -- in this case, just English descriptions. They're just about to deploy a test version on Greek Wikipedia to see how their current solution scales.

There are some questions about this approach: Is this going to create extra work that some people don't want to deal with? Is it a barrier if you have to go to Wikidata to revert? What if you get in a revert war with someone, do you have to go to Wikidata to report and resolve the situation?

There would be further feature work depending on the answers to those questions. It would be helpful if people patrolling description changes on Wikipedia could do as much from Wikipedia as possible, rather than switching over to Wikidata.

3). Magic words in Wikipedia articles to override Wikidata descriptions

This could be a magic word like {{DESCRIPTION: .

This would be a more direct way for Wikipedia editors to ensure that moderation or discussion about a specific page's description happens on Wikipedia, and not on Wikidata. It would only replace the Wikidata description when there's something typed in the field, not just blanking the description completely.

A con for this idea is that it might be confusing for people who see a bad description and want to change it -- do they go to the Wikipedia page, or the Wikidata page? Also, this would have to be accounted for in the app description-editing feature.

4). Use the first sentence of the Wikipedia article, when appropriate

This was proposed and discussed above, including a comparison table with sample descriptions. It would have to filter out some pieces -- "(title) is a", birth and death dates, translation and pronunciation, etc.

Pros for this approach: it's derived from Wikipedia text, so it's under enwiki control. Also, it guarantees that there is a description; there are gaps in the Wikidata descriptions, but every article has a lead paragraph.

A con for this is that sometimes the first sentence is too long or dense to be helpful as a short description. Maybe we can come up with an idea for how to handle long first sentences. The Wikidata descriptions could be a fallback, or the magic word.

5). Protecting the description on protected pages

This would protect the short descriptions on pages that are likely vandalism targets, presumably synching protection on Wikidata with protection on English Wikipedia, so that admins protecting a WP page wouldn't have to remember to do something on Wikidata.

I'm not sure exactly how this would work, and can't find a description of it right now. Have people figured out a mechanism for this? How would you go about protecting the description on Wikidata?

So there's a lot of questions, and I'm sure I missed some pieces, but I'm hoping that this helps focus some discussion on potential solutions. What do you think? -- DannyH (WMF) (talk) 22:03, 19 September 2017 (UTC)

My preference would be a combination of 3 and 4: Use a local magic word when available, fall back to (a filtered version of) the first sentence otherwise. That way everything is under local control, the interaction with Wikidata is significantly less complex, and (unlike Wikidata) we're guaranteed to get something. The descriptions will occasionally be too long, but that's not really a worse problem than being occasionally missing, and if editors insist on long sentences in article text we can still achieve tighter descriptions using the magic word. If Wikidata wants to run bots that import this information from Wikipedia to use as their descriptions, they could also do that, but it would be their local decision and wouldn't affect what we see here. —David Eppstein (talk) 22:09, 19 September 2017 (UTC)

This is not place or time to solve this problem in my view. This is (again) all begging the questions. To put a pointy analogy on it:

Putin: "So let's discuss the plans for the highway system in Crimea. There are lots of problems, lets fix them!"

Rest of world: "Dude, what the hell are you doing in Crimea"

The questions are 1) about WMF's role in making content decisions, and 2) even deeper questions about navigating differences in the various projects' content policies and governance processes.

I am not convinced that folks from the WMF even understand these two fundamental issues, and "solutions" that aren't grounded on a good understanding are also going to be unstable.

Reversing direction, and stepping back, is the correct way to go here. Not deeper in.

Please reverse course. Jytdog (talk) 23:49, 19 September 2017 (UTC)

Having descriptions (on mobile, on Visual Editor, etc.) is an unambiguous good for Wikipedia. As a Wikipedian, I have zero interest in this boundary conflict, and think the analogy to sovereign independent states is pointless. We are neither sovereign nor independent, we are collaborating and interdependent. Moreover, this is a list of options, (almost all of which) give Wikipedians control over "their territory": how things look on Wikipedia. Let's skip the diplomatic crisis and figure out how to make this work best.

I tend to think that Options ~~4 &~~ 5 are strong starting points. I also would love to have a tool that shows the descriptions for my watchlist, and either lets me edit those descriptions or has clickable links to the corresponding Wikidata pages. (Editing description on Wikidata is actually very easy, unlike a lot of things over there.)

The real questions are: can we develop a manual of style for descriptions? Is that MoS compatible with Wikidata expectations? And, how does the Wikidata community feel about mass importing new descriptions from Wikipedia?--Carwil (talk) 01:37, 20 September 2017 (UTC)

It was a pointy example as I pointedly said, and trying to drive that down my throat is bullshit. I offered the colorful example because folks from the WMF don't seem to be getting it, that they overstepped and did a fucked up thing after they overstepped, and that continually setting the focus of the conversation on fixing their fuckup is not legitimate (it is as weird as talking with putin about fixing highways in Crimea... the whole conversation is surreal and begs the question - namely - why are we having this conversation at all?)

Collaboration depends on recognizing appropriate roles for all the collaborators. As Rilke said, "love is respecting the difference between". The WMF overstepped its role and its competence by doing this unilaterally (by 'competence' i mean that it, as an organization, didn't understand the policy and governance issues around this content).

The wrong thing to do now is flail around trying to fix this multi-layered fuckup. The right thing to do now is undo, step back, and think clearly before trying to implement again. Jytdog (talk) 01:52, 20 September 2017 (UTC)

Let me amend this Crimea analogy… The infrastructure contractors for Kyiv have built installed a subway system (mobile app, mobile view, etc.) that lets millions of people get around our city. In the process, they have installed navigation signage that draws on Russian-language text. What the WMF people are saying is: hey, how would you like us to get text for the signs. In response, what Jytdog is arguing is that the contractors should apologize for putting up signs at all. If your beef with WMF is so important to you, Jytdog, fine. Just stop pretending you speak for all of us.--Carwil (talk) 04:13, 24 September 2017 (UTC)

The community already rejected these roadsigns, installed by the WMF, for the mobile app. I am not speaking for myself. Jytdog (talk) 04:33, 24 September 2017 (UTC)

DannyH, the only acceptable options are those that are enwiki based (for enwiki articles). Descriptions are textual, language-based content which should reflect the article, and should be embedded and maintained by the project and editors, not by another project with completely different goals. The best solution seems to be some template placed at the top of the article. If this is easier for the WMF, we should strive to gove it a "universal" name, so that it can be used on all wiki-languages that want it. Initially, it can be filled by bot either by copying the Wikidata description or by a shortened, cleaned version of the first line of the article, whichever people think is best (I prefer the second, but this bit is not essential to the proposal). From then on, this gets maintained locally, independently of the Wikidata descriptions.

You say "A con for this idea is that it might be confusing for people who see a bad description and want to change it -- do they go to the Wikipedia page, or the Wikidata page?" which is obviously false. This would be simply a part of the article, very few people would really be confused and think "oh, I need to go for Wikidata for this". Why would they ever think this in the above solution? Fram (talk) 07:15, 20 September 2017 (UTC)

It's quite a task we're looking at. Five and a half million short descriptions is a hell of a lot of text to create and maintain. Over on Wikidata, I've been working on items for civil parishes in England. I hadn't got as far as the descriptions yet -- first I have been working on tidying up data and building up external matches. The prospect of addressing the descriptions has been quite daunting, even with only 15,000 items of more or less the same kind to consider -- a drop in the ocean compared to short descriptions for all the articles on en-wiki. (And I have to say, I am very dubious that one could simply automatically get the information from article first lines.

I get that there's a lot of unhappiness about Wikidata here, but one (admittedly small) thing in the other side of the scale is that at least it makes it possible to a quick idea of what sorts of descriptions there are, and also to (relatively easily) make systematic edits to large numbers of them at scale.

Anyway, to get an idea of what sorts of things we might like (and not like) for descriptions, it's maybe worth looking at some samples of what Wikidata is currently providing. In each case, the link below goes to a query for 200 examples -- follow the link and click the blue button half way down the left hand side to run the query.

People: tinyurl.com/yd6dvub7
Castles: tinyurl.com/ybxdr7g5
Populated places: tinyurl.com/yc3yq6gf
Rivers: tinyurl.com/ybdh6blw
Albums: tinyurl.com/yatcou33
Films: tinyurl.com/ybkk9928
Unidentified things: tinyurl.com/y7k3w6ud
Civil parishes in West Sussex: tinyurl.com/ydd2utow

(Note: to see more examples, increase the number in the LIMIT clause; to see different examples, change the number in the OFFSET clause; I didn't force a sort order, in order to increase variety, so the same query may produce a different set of 200 examples if you run it in 30 minutes time -- for a deterministic query, to get a repeatable set, add eg ORDER BY ?item before the OFFSET keyword. The 'link' button on the left hand side can be used to get a short URL to the modified query).

It is apparent that there is no great consistency or house style. (Though even what is there already may be useful for some purposes -- eg disambiguating searches). This is one question it would be really useful to have input on, eg from the reading team: what is actually wanted? I imagine there is quite a lot of flexibility in what is useful, but what is the ideal? How detailed/verbose is useful? How brief/succinct is better?

So for example for a civil parish like Donnington (Q666080), we currently have "village and civil parish in the Chichester district of West Sussex in United Kingdom". Is this appropriate? Would the shorter "village and civil parish in Chichester, West Sussex, England" be better to standardise on? Or drop Chichester district, and just "village and civil parish in West Sussex, England" ? Or just "civil parish in Sussex"? All of the above could be systematically rolled out, but what is most useful?

Looking at some of the other result sets, it appears that a lot of film descriptions have been standardised to "<year> film by <director>", sometimes with genre also given, or occasionally country of origin; a few have more discursive descriptions (eg Oliver Twist (Q645752), Thunderpants (Q708825).

Descriptions for albums seem less systematised. Most common seems to be "album by <artist>", sometimes specifying whether it is a studio, live, or compilation album. Some are longer, eg "debut studio album by the American rock band Flowerhead" (...Ka-Bloom! (Q14954705)) or "fourth studio album by CCM singer Mandisa" (Overcomer (Q15078867)). Many just say "live album" or "album".

For people a common form seems to be "<nationality> <occupation>". (I think these may have come from the old PERSONDATA templates -- more recently created items may not be so systematic). Again, some items are more discursive, eg Banksy (Q133600). Is this useful?

Raising quality and usefulness for short descriptions, wherever it happens, is going to be no small task. But a useful thing, however we go forward, would be some more discussion on what is considered a useful description, and what is one that could be improved. Jheald (talk) 12:36, 20 September 2017 (UTC)

I agree with Jytdog that this feature was implemented a couple years ago without due care and attention to the differences between the two sites. I don't think that's catastrophic; it's a mistake that we have to fix. But what we have right now is a feature that's useful, and people like it. I don't think that breaking the existing feature is a necessary step before we figure out how to make it better. That's basically punishing the people who use the app, in order to make a point that they don't know or care about.

Fram, I agree that creating a completely enwiki-based alternative is one of the options. I mentioned the problem of not knowing where to fix the description, because I was thinking of it as a combined system that used Wikidata as a fallback. As Jheald says, a con for the completely enwiki template/magic-word version is that there would be five and a half million descriptions to generate, and that's a serious thing to think about.

Jheald, it hadn't occurred to me that this was an opportunity to standardize the descriptions. That's actually an important thing to figure out, no matter where the descriptions live. I need to read your post again, slower, and think about it. I'm really glad you brought it up. -- DannyH (WMF) (talk) 14:21, 20 September 2017 (UTC)

Considering that Wikidata was apparently able to reliably source 50 million statements in a month (a feat no one has been willing or able to explain so far, but which is shown in the statistics and pushed Wikidata over the "50% of our statements are reliably sourced" threshold suddenly), it shouldn't be too hard to add 5 miilion descriptions to enwiki in a reasonable timeframe, if this is the way we choose (some clever programming which parses and "summarizes" the first sentence may also be an option and then wouldn't need article edits). We need a) a decision of the best solution (a global template, an enwiki template, or clever reading of the first line at runtime?), b) a decision (in the case of a template) of how we would populate it initially (copy the wikidata description, clever reading of the first line, something infobox or category related, ...?) and c) a botrun. In the meantime, we can decide whether we ask the WMF to turn off the Wikidata descriptions display off immediately, or wait until the bot run (or other solution) is finished.

If we start by copying the Wikidata descriptions, we don't even need to edit 5 million articles, as many Wikidata items don't have descriptions at the moment. (First random item I encountered, [1] doesn't have one and doesn't need one). Fram (talk) 14:41, 20 September 2017 (UTC)

Fram, I want to make sure that some other people get a chance to talk before we jump straight into a solution. I'm not trying to backtrack, I just want to make sure people can talk about the options.

If it turns out that's the solution we go with, it would be good to include the product team in the implementation, not just run a bot and ask the WMF to turn something off. We're offering to be a part of this, and work on this collaboratively. One thought about switching to Wikipedia-populated descriptions: we could think about porting the changed versions back to Wikidata, to be the English descriptions there. I know that not everybody here is interested in improving Wikidata as well, but it would be good to find a solution that benefits everyone. -- DannyH (WMF) (talk) 18:21, 20 September 2017 (UTC)

I can only speak for myself (I may sometimes give another impression though ;-) ), but I see no reason to not take some time to find the best solution here, and have no problem with a solution which then takes some time to actually implement. I have indicated a few times what I believe are minimum requirements for such a solution, but it makes no sense to e.g. create a Template:ShortDescription here when perhaps the WMF would prefer a somewhat different Template:Summary or a magic word or whatever instead, which they can then read more easily (to use in apps, search, ...) and which may be something other wikis can implement without too much effort if they want to. We have the time to do this right, and we have the time to run a massive botrun if that is required. As for your final point, I see no reason why Wikidata couldn't import (or mirror) our descriptions if they then would like this: it's not something we can or want to impose, but it would be nice. Fram (talk) 19:09, 20 September 2017 (UTC)

My views on these options (from a perspective that using the Wikidata descriptions are a good idea in principle) are:

Making things easier to edit is always a good step forward, however there should also be an easy way to revert the edit. Maybe some sort of "this was recently changed, does it look bad?" tag may be useful there.
Sounds good, but it would be better to make all Wikidata edit summaries more useful rather than picking on particular bits.
This is a terrible idea - it's basically duplicating a bit of Wikidata here (and, presumably, also on every other language Wikipedia). It would be much better to have some way of editing the Wikidata descriptions directly here instead.
Sounds good. Maybe this could be done in such a way that it can feed into Wikidata - either by a bot, or some sort of gamification/user checking. I think this would be welcome on Wikidata, particularly for entries that don't yet have English descriptions.
This is something that needs properly thinking about by people that are active with page protection. If a page is protected here, should the wikidata entry as a whole be protected, or all of the wikidata properties used in the page? Or some sort of semi-protection? Although we don't currently do this with Commons media included on a page.

Thanks. Mike Peel (talk) 23:08, 20 September 2017 (UTC)

@Mike Peel: I see your point about a magic word here being redundant duplication of what is already on Wikidata but I consider it that Wikidata is itself duplicating a role that should be en's (describing things in English text) rather than vice versa. I would only be willing to see Wikidata descriptions used here if we can make them subject to our local standards for sourcing, etc. Consider e.g. the long debates over whether someone should be described as a "climate change denier". We have well-established rules for sourcing biographies of living people here, despite which these questions are still difficult. Should we let tendentious editors forum-shop Wikidata's much looser rules over ours in such cases? I think not. —David Eppstein (talk) 23:20, 20 September 2017 (UTC)

@David Eppstein: I care more about avoiding the duplication of work/content than I do about which project should have which role. Technically, I think Wikidata has better infrastructure to hold the information (structured rather than free-form content), while the community and English-specific expertise is here. If we could forget the different project names, the ideal case might be the enwp community taking ownership of the English Wikidata descriptions and running them according to enwp rules. ;-) Thanks. Mike Peel (talk) 23:30, 20 September 2017 (UTC)

Since when are short bits of text "structured rather than free form content"? Fram (talk) 06:50, 21 September 2017 (UTC)

For me (4). Use the first sentence of the Wikipedia article, when appropriate is the only one that makes sense. The con is that "sometimes the first sentence is too long or dense to be helpful as a short description" but this is not a problem for Wikidata descriptions but for Wikipedia. Our guidance, at WP:BEGIN, is that "If possible, the page title should be the subject of the first sentence", and "Try to not overload the first sentence". The first sentence, as part of the first section, should also be accessible, even in a highly technical article. So too long, dense, or technical first sentences are not appropriate for WP.

The only issue is what to do when the first sentence does not describe the topic. E.g. List of songs recorded by Steps (from tomorrow’s front page) begins "The British group Steps have recorded songs for five studio albums". Wikidata though describes it as a "Wikimedia list article"; presumably other lists can be handled the same way. Other topics that are hard to describe might use a standard form, or just the title, as e.g. History of Iran does.--JohnBlackburne^words_deeds 23:34, 20 September 2017 (UTC)

"Wikimedia list article" is a rather dreadful description. That article doesn't even need a description, the title is self-explanatory, but if it has one it should be something "Songs recorded by Britsh band Steps", i.e. a description which adds something useful to the title, not a description which adds a totally irrelevant concept (Wikimedia) which can only confuse people instead of helping them. It looks as if all List articles have the very same description at Wikidata, which is again a good argument to take this functionality away from there and give it back to the local wikipedia versions (at least those that want this). Fram (talk) 06:50, 21 September 2017 (UTC)

(Of course, there may be a very good reason why these list descriptions are ideal for Wikidata, and I am not arguing that they should change them; but for enwiki, they are just not useful at all) Fram (talk) 06:55, 21 September 2017 (UTC)

The list description needs to be considered in the context of how it would be seen -- namely in a list on a mobile screen as in the picture shown at the top of this article, or as an explanatory line in a set of search results. In those contexts, I submit, it is quite adequate. Jheald (talk) 09:16, 21 September 2017 (UTC)

Umm, how? They explain nothing at all, they only introduce a concept which has no useful information and proably no meaning for the average reader, "Wikimedia". Thta it is a "list article" is rather obvious from the name anyway, so the end result is two superfluous words and one irrelevant one. In what world is that "quite adequate"? Fram (talk) 09:21, 21 September 2017 (UTC)

I'm gonna suggest an alternative: Let's just take the first sentence from TextExtracts. Just for English Wikipedia. Problem solved, little engineering required, English gets to be holier than holy, rest of the wiki's get the benefit from centralization and structured info, apps retain 'some form' of disambiguation labels for en.wp. No need for specialized edit interfaces, no need for magic words. Just toss ellipsis at the end, and maybe reduce the font size a bit and just live with that. I think first sentence is subpar from the descriptions that Wikidata provides, but we have to find some place of compromise and this seems like the least terrible option to me. I definitely DONT see a reason to spend engineering effort to duplicate Wikidata descriptions in Wikipedia.—TheDJ (talk • contribs) 07:30, 21 September 2017 (UTC)

What exactly is the benefit of centralizing descriptions, which are language-based? This means that you need editors fluent in all these languages to not only patrol and edit their own language wikipedia, but also Wikidata. Apart from that, you seem to continue to repeat the same misconceptions about "structured data" when it is just a short freetext sentence fragment, and the supposed superiority of current Wikidata descriptions when just above it is e.g. shown how all lists have an utterly useless description at Wikidata: we have about 100,000 of these, with many of them among our most popular articles, so this is not something marginal. To push for a subpar, English-only solution out of some kind of bitterness is not productive or helpful, when there may be opportunities here to make things better for enwiki and other wikis that might prefer the same solution in the end. Fram (talk) 07:56, 21 September 2017 (UTC)

A Wikipedia centric approach. From the global state of information and knowledge... what is it that that list is ? It is nothing physical in the real world that matches it from a data topic point of view. It's a Wikipedia article. Now if it were called "Discography of Steps", then that description might be different, because a discography is a real life concept, but 'list of' has no inherent meaning for most people.

When people say structured, it means structured storage and linking, not structured authoring. While for one property the value of that might be limited, when combined with all the other properties it is a very strong and Wikidata is proving that again and again. Wikidata is becoming the entry point for how others interact with the content in our movement, Wikipedia is the long form appendix that you can link to when someone is really interested. Making things better for Wikipedia is awesome, but I think that for 95% of all our language variants for Wikipedia, this change would have 0 benefit and might even be detrimental. Even for English Wikipedia the quality concerns are limited to a very specific set of articles. And that forgoes the point that I think that the ROI simply doesn't make sense for that option. Prediction; will take a year to complete such a feature and only 5-10 wiki's will use it. There is no space for it right now in the roadmap, and no budget allocation either... Shortcuts are the only option that I think are serious candidates. —TheDJ (talk • contribs) 09:24, 21 September 2017 (UTC)

Are you really arguing that in general, people will know what "Discography of X" means but will have trouble understanding what "List of songs by X" means (unlikely), and that somehow "Wikimedia list article" will then somehow lead to a better understanding for these people? I'll try to stay polite and just say that I disagree and think that most uninvolved people would disagree as well. As for your arguments about structured data, the descriptions are one bit which is actually quite separate from the remainder of Wikidata and doesn't really benefit or interact with the remainder. It just doesn't fit in with what Wikidata is and how it is structured at all, it is presented differently, edited differently, ... It has no room for sourcing, it is multilingual, it is everything the remainder of Wikidata is not. As for roadmap and budget problems, fuck them. Enough time and budget has been spent on things no one wanted or needed, and a lot of time has been spent by volunteers to convince the WMF that some things really are not welcome and should be shut down or totally rewritten. Here they have the chance to work together instead of against the community, and to develop a solution which may be beneficial to everyone involved. Fram (talk) 09:56, 21 September 2017 (UTC)

There is actually a problem here. Indeed in 99.99%, or most likely in 100%, "Discography of X" means "List of albums/songs performed by X". However, once in 00.01% cases (which may not apply specifically to Discography but may apply to other examples) it can make a name of a magazine, or a music band, or indeed a discography of another performer with a similar name. This is why it happens to be useful. Note that whether there are other meanings or not are language specific.--Ymblanter (talk) 10:11, 21 September 2017 (UTC)

For clarity: this shows that currently only one (Discography of Nico Carstens) out of 11 non-redirect article titles in the "Discography of X" format is an article containing a "List of albums/songs performed by X" (so less than 10%, with only one single instance, instead of "99.99%, or most likely in 100%"). --Francis Schonken (talk) 10:27, 21 September 2017 (UTC)

"This is why it happens to be useful. Note that whether there are other meanings or not are language specific." Your conclusions don't follow from your reasoning. Are you arguing that a generic "Wiimedia list article" is useful because not all "Discography of X" articles are a list of recordings of X? That's a total non sequitur. As for "language-specific", yes, but how is that relevant? Perhaps the Finnish equicvalent of "Wikimedia list article" is extemely helpful in Finnish, fine, then use that. But people who are so hell-bent on keeping the Wikidata descriptions that they can't even admit that 100,000 or so instances of "Wikimedia list article" are 100,000 examples of totally useless Wikidata descriptions (in English) for use on enwiki views, searches, ... simply make a mockery of this discussion and any attempts to find a rational compromise. Fram (talk) 11:55, 21 September 2017 (UTC)

First, I hope I demonstrated that your statement that descriptions are not needed because every sane person can say from the title what the article is about is wrong. Second, a "Wikimedia list article" description is not ideal, but it is better than no description, because is says, well, that the article is a Wikimedia list article.

I said that for most list articles (like list of Steps records) no description is really necessary, and you demonstrate something (not really sure what) about "discography of " articles, which are not the same (and don't even have a "Wikimedia list article" description by default. So no, you haven't demonstrated anything about my statements. Further, please explain in what way "Wikimedia list article" is better than no description? That it is a list article is obvious as it is an article titled list of; only the exceptions, where an article with such a title in fact isn't a list but e.g. the title of a book, film, or record really need a description. Like I also said already, even if they don't need a description, it may be helpful to have one which gives the reader more useful information, e.g. describing "List of Steps recordings" as "Recordings by British band Steps" or something similar, which adds that they are a British band, and not e.g. a type of dance. The current description though, adored now already by three of the more vocal defenders of getting descriptions from Wikidata, doesn't add anything useful. Please, all of you, understand that either readers don't know what Wikimedia is, and will think probably it a typo for Wikipedia (and whether it says "Wikimedia list article" or "Wikipedia list article", or they do know what Wikimedia is, i.e. the foundation behind the site they are surfing on. It tells you absolutely nothing, nada, zilch, about the list of X you are searching for or just started reading. It is just an annoying "thing" you get at the top of every list and which you have to scroll past. Having no description is in these cases clearly better than having this generic, bot generated description. Just like it makes no sense that our 200,000+ disambiguation pages like Blackboard (disambiguation) get the description "Wikipedia disambiguation page" (oh, here it is Wikipedia and not Wikimedia?); no kidding, Sherlock. (Did you know that we have a page titled Disambiguation (disambiguation)? The Wikidata description is "Wikimedia disambiguation page", which I wouldn't have known otherwise). Those descriptions make sense on Wikidata, where e.g. this doesn't have (or need) "Disambiguation" in the title: they don't make sense on enwiki. The fact that they serve two different purposes, two different needs which require two different descriptions is a very good reason why this feature should be hosted on enwiki for display in enwiki searches and articles. Fram (talk) 12:53, 21 September 2017 (UTC)

Honestly Fram, is this really the best you can do? So some of the descriptions are mildly redundant. Is that really such a big deal? Seems "mostly harmless" to me. I thought you had some concerns that were actually *serious* about WD descriptions. Yet I post some queries so we can look at typical samples, and you're not even bothered to comment on them. Get serious or stop wasting everybody's time. Jheald (talk) 13:27, 21 September 2017 (UTC)

No, this is not "the best I can do", it is but one argument among the many I have made. I try not to repeat everything in every post, as I already get the complaint of carrying on a monologue (which, considering how few of the replies I got had anything to do with what I actually said, is probably accurate). My main reasons are that a) the WMF should never push data from another site into enwiki content, b) this is language-based content which is not the domain of Wikidata but of the different language-based Wikipedias, c) Wikidata policies are too different (or lacking) compared to enwiki d) vandalism reversal at Wiki is on average way too slow (and note that while statistically vandalism is rare at Wikidata, in reality for descriptions it is pretty high), e) things like blocking, protection, ... on enwiki don't work on this, so people we want to get rid off can still subvert our articles through Wikidata (and Commons, but having one backdoor is hardly an argument to open a second one), f) hundreds of thousands of Wikidata descriptions are useless and confusing, and we would be better of without them, and g) probably a few other things I already said but which I don't immediately recall now... Which you would have known if you had actually read my posts, instead of taking pot shots at "is this really the best you can do" when I just gave yet another reason why this is a problem, not the only one or necessarily the best one. Anyway, looking at your queries, taking the one for albums, I see that the vast majority of albums have no description on Wikidata, and that for the remainder, about half is useful (giving extra, relevant information) and half is basically a repeat of the enwiki disambiguator we have in the title anyway (e.g. for "Spirit", it is nice to have the description "Depeche Mode album", but considering that our article is called Spirit (Depeche Mode album), it is hardly helpful to have this description). For your query for "unidentified things", only 11 of the 200 items (with an enwiki article) even have a description... Fram (talk) 13:50, 21 September 2017 (UTC)

For items with no description, it's worth noting the mobile app can fill in with an auto-description generated on the fly based on the wikidata statements available. Unfortunately I don't have a link to the code (perhaps somebody on this board can supply it?), but auto-descriptions by Magnus can be seen in action on eg Mix'n'match, which shows both auto-descriptions and manual ones for matched entries. Indeed, not two weeks goes by without User:GerardM suggesting that manual descriptions should be abandoned altogether, and descriptions just left to the automatic generator. I wouldn't go as far as that, as I think there are times when manual description can be necessary for clarification (eg two civil parishes with the same name in the same district of the same county -- yes, there are some examples of this). Also there can be advantages for queries in having baked-in text available. (Though in principle one could also make the auto-generated descriptions available within queries via a SERVICE routine).

But I am glad if discussion can take a harder look at some of the descriptions we have, and how they could be improved. External services and Wikidata-based systems will go on using this descriptions whatever WMF does or doesn't do, sometimes even as an index to Wikipedia content, simply because they are so accessible, so it's worth looking at them hard and thinking how we could do better. For the moment I think what we have at the moment is mostly better than nothing, and even in less useful cases mostly harmless; so I don't see it as a case of the sky falling.

I do share some concern about potential vandalism. It's one thing to say Wikidata's vandalism rate is low because it mostly skates under the radar as a low-reward proposition for vandalism. But much higher visibility and editability effectively paints a target on those statements. (Indeed, when this change was announced at Wikidata's Project Chat, my first instinct was to ask whether vandal fighters on en-wiki felt confident that they had the capability and the capacity to handle it. I think now after all the discussion above everyone would have to accept that the only current answer to that question has to be: No). But I think it's probably fixable.

As for BLP issues I think we need to accept that there is certain information in descriptions that we need to be very careful about, that perhaps should only be accepted on the basis of flagged revisions (perhaps triggered by particular words), if those descriptions are going to be presented alongside Wikipedia text. Giving Wikipedia admins the ability to activate flagged revisions for en-descriptions of a particular item (perhaps automatically if the item is protected on en-wiki) might also be a way forward to deal with concerns in that area.

Verifiability of descriptions (at least as interpreted as a requirement for explicit sourcing) I see as less of a concern, just as lead sections of articles on en-wiki don't require explicit footnotes, so long as they are supported by the rest of the article. Even with references, it's hard to control against people changing the information while leaving the reference. But for the most point, the contents of the description will be the most basic facts about an item, and are likely to be readily supported by the content of external links, and/or references in the attached wiki article.

In my view there is work to do on both the current description data and the underlying systems tying Wikidata and the wikipedias. But I believe this is achievable, to a good outcome. Jheald (talk) 14:52, 21 September 2017 (UTC)

I did not get the impression that you listen to what I am saying. I can reply, but, to be honest, I do not see any point in doing so, since you will likely come up with a new explanation completely unrelated to my reply, so I better do not. As I said earlier, I do not have any stakes in descriptions.--Ymblanter (talk) 13:07, 21 September 2017 (UTC)

I directly replied to the two statements in your post (conveniently labeled "first" and "second"). You are free to leave the conversation, but it would do you credit if you didn't fabricate reasons for doing so. Then again, you didn't refrain from fabricating things I supposedly had claimed ("your statement that descriptions are not needed because every sane person can say from the title what the article is about"), so this shouldn't come as a surprise. Fram (talk) 13:20, 21 September 2017 (UTC)

I can not really leave the conversation because there never have been one - you consistently fail to address the points I made instead cherry-picking quotes and making a strawman. As I said, I do not see any sense in continuing this exercise. Your position is also clear, it did not shaft a bit on this page irrespectively on any arguments which were brought by different users here. At some point, an RfC will be organized, and then we are going to see how much the community shares your ideas.--Ymblanter (talk) 13:28, 21 September 2017 (UTC)

We are here because an RfC was organized but only implemented partially by the WMF, remember? Fram (talk) 13:50, 21 September 2017 (UTC)

(ec) In most cases I have to say that I think just using mw:Extension:TextExtracts would not be very helpful. If we consider the image of the mobile screen at the top of this section, the short descriptions need to come to the point very quickly, without prefatory matter like pronunciation, etymology, field of the subject, or repetition of the subject name.

Unlike some others in this discussion, I am also pretty dubious about the extent to which good short descriptions could be extracted automatically. I think often they would still be too wordy and not suitable.

The point about whether it makes sense for WMF to put much in the way of limited engineering resources into duplicating delivery mechanisms when Wikidata already exists is a fair one.

@Fram: You are correct that the text slugs on their own are not structured data. However, it makes sense to put them into a retrieval system that is structured, so that as per the queries above they are instantly retrievable for any subset. As the queries above show, it's a lot easier to extract from Wikidata descriptions for eg all the civil parishes in England that it would be from eg Wikipedia -- it makes sense to store the descriptions in a structure that makes them directly accessible. Primarily these are going to be delivered as 'explanation lines' accompanying search results. One doesn't want to have to scrape the pages every time one wants to present the summary explanation line. Jheald (talk) 09:36, 21 September 2017 (UTC)

"Primarily these are going to be delivered as 'explanation lines' accompanying search results. One doesn't want to have to scrape the pages every time one wants to present the summary explanation line." Such scraping is done every time one does a standard search, e.g. this, where every result shows the start of the article anyway. Fram (talk) 09:56, 21 September 2017 (UTC)

DJ you want to say that Wikipedia is some kind of spoiled princess. Whatever. Here is a what a Wikidata editor wrote at Jimbo's If a change occurs to the Wikidata item linked to a Wikipedia page I watch, then that change shows up with a diff link to Wikidata. If you have issues with Wikidata's content, then you need to work with our (Wikidata's) community to work out a solution. Keep in mind though that Wikidata is a highly multilingual, mixed community where insisting that every Wikipedia policy be applied there is highly frowned upon.

No surprise to me, that a Wikidata person expects the norms of that editing community to be respected. The projects are different. There is this continued fantasy that norms are the same. They aren't. Jytdog (talk) 08:18, 21 September 2017 (UTC)

And maybe it deserves to be a spoiled princess. Maybe. But at the same time, we should also recognise that it is the exception. So instead of making everything follow Wikipedia's norms, the better option might be to have Wikipedia be the odd kid out. Princesses might grow up a bit in isolation at some point due to their status. —TheDJ (talk • contribs) 09:24, 21 September 2017 (UTC)

You continue with the sloppy garbage that it is OK for the WMF to play content DJ, breaking the fundamental deal here as well as policies in one or more projects, and setting projects against one another, in order to serve some aim that it sees as For The Greater Good. I am not going to get sucked into trying to convince people in Wikidata to follow en-wp BLP. That would be stupid and imperialistic. Nor am I am going to accept a mechanized process to introduce content into en-WP that is created without V or BLP. That too is idiocy. Jytdog (talk) 09:40, 21 September 2017 (UTC)

Could you please expand which people are going to be blocked and banned here? And by whom?--Ymblanter (talk) 09:49, 21 September 2017 (UTC)

Last week I had launched an RfC at VPP calling for blocks for the people who kept this going after we had the RfC in March, as this violated clearly expressed community consensus. I withdrew it when dialogue was opened last week. If the "dialogue" continues to beg the question on a "Lets fix the highways in Crimea" basis (see above in this thread) then I will re-open it. That one didn't specify individuals. Jytdog (talk) 10:13, 21 September 2017 (UTC)

Ok, thanks. You should have been more clear: not "people are going to be blocked or banned" but "I would like to see these people blocked or banned". The RfC as formulated does not have a single chance to succeed.--Ymblanter (talk) 10:21, 21 September 2017 (UTC)

Ok thanks. You should have been more clear that you are making the newbie and slimey mistake of Trying To Make a Big Deal And Even Quoting things that people obviously retracted before they were responded to. (I know how to step back when I make a mistake - I do understand that this is something rare around here). And thanks for consulting your crystal ball for me. Jytdog (talk) 10:42, 21 September 2017 (UTC)

I am not sure I understand whether this is meant as a personal attack or not, since English is not my mothertongue, but you are welcome to continue the rant, I am not going to respond to it.--Ymblanter (talk) 12:31, 21 September 2017 (UTC)

(e/c) And how would using the first line of the Wikipedia extract be playing content DJ for English Wikipedia ? That's my suggestion. I think it's totally unnecessary other than to keep the peace, but its what i'm suggesting none the less. —TheDJ (talk • contribs) 10:03, 21 September 2017 (UTC)

the WMF wants a single line of description it can use everywhere. I understand how that is very attractive. (i really do). It is however a huge deal for them to have made the decision to do so. Your solution is based on kissing en-WP ass and doesn't deal with the fundamental issues and in many ways is even more outside the norms of the movement than what the WMF did. Jytdog (talk) 10:13, 21 September 2017 (UTC)

I think in part, the WMF's role is to do things that communities and individual volunteers can't, like making apps, which have special app-specific features that need full-time product and engineering roles. I don't think that's an overreach. But I agree that that work needs to be done with the knowledge and the involvement of the communities, and that wasn't done well enough here. I'm hoping that having these conversations and working with folks here to come up with solutions is a step towards correcting that mistake. -- DannyH (WMF) (talk) 16:24, 21 September 2017 (UTC)

Making an app and making content decisions in an app are two different things, and you continue to obfuscate that. I am looking for the WMF to take these descriptions down and renounce the overstepping. I am not accepting what you are presenting as a fait accompli. Jytdog (talk) 17:55, 21 September 2017 (UTC)

I'm thinking about the discussion/argument above about descriptions of lists, albums, etc. On one hand, whatever the solution we end up with for short descriptions, there'll be plenty of time to figure out the standard format for rivers, museums, etc. But the conversation here is revealing, because it highlights a couple important questions that people have raised:

1.) Who's going to make the decisions about the standard format -- the Enwiki community, the Wikidata community, or both working together?

2.) Are Wikidata descriptions just for putting a heading on Enwiki articles, or are there other purposes they serve that would require a description to be different than what the Enwiki community would want?

Lists and disambiguation pages are an interesting example, because the Wikidata description isn't describing the subject of an article; it's describing the page. The description for the Gennady Golovkin article is "Kazakhstani boxer", which is useful both for a description on enwiki and any other use that someone might have for Wikidata information. But "Wikimedia list page" is not a very useful description for the enwiki app/search, and I can't think of any other use case where it would be helpful. It's kind of a description for description's sake, and seems like an example of something that enwiki could override with no real consequences.

If we can figure out a way for folks from Wikipedia and Wikidata to work together on making the descriptions appropriate for enwiki use, then that could benefit everyone. If not, then it seems to me like a template/magic word override on enwiki would make sense. There are a lot of useful descriptions on Wikidata, and I don't think it's practical for English Wikipedia to come up with five million descriptions from scratch. But using the helpful ones and overriding the unhelpful ones is a potential way forward. -- DannyH (WMF) (talk) 17:25, 21 September 2017 (UTC)

Wikidata descriptions, at the very least, serve to provide a proper choice on Wikidata itself - for example, when I am trying to fill in a property of an item, and I do not known the Q-number of the item I want to refer to, I just type an approximate name and get a bunch of options to choose from. Without descriptions, these options are not usable. With long descriptions, they will not be usable either. Every description, unless false, is better than nothing.--Ymblanter (talk) 17:34, 21 September 2017 (UTC)

Nobody has disputed the Wikidata editing community's use of the description field in Wikidata. That is their deal and none of en-WP editing community's business Jytdog (talk) 17:59, 21 September 2017 (UTC)

I was reacting to point 2 by DannyH (WMF) above.--Ymblanter (talk) 18:05, 21 September 2017 (UTC)

DannyH, you missed question zero as you have throughout this discussion. 0) Is it appropriate for the WMF to make content decisions? If (a big if) the answer is "yes", how should it interact with the content-producing communities? Jytdog (talk) 18:10, 21 September 2017 (UTC)

I think the way that the WMF should interact with the content-producting communities is the way that I'm doing it right now -- talking to people, and working collaboratively towards a solution that works for the Enwiki contributors, the Wikidata contributors and the app users. I agree with you that that hasn't always happened in the past. -- DannyH (WMF) (talk) 18:28, 21 September 2017 (UTC)

DannyH, by limiting the discussion to the English, you allow them to high jack the conversation. Thanks, GerardM (talk) 06:14, 22 September 2017 (UTC)

So that addressed question 0b, and leaves 0a unaddressed. Which is the primary issue here... which to restate the analogy, is "Putin in Crimea". I do not accept this fait accompli. Jytdog (talk) 22:02, 21 September 2017 (UTC)

DannyH (WMF), thanks. You missed #4 supplemented with a variation of #3: A Magic word to override the first sentence of the Wikipedia article.

To restate in this section: My !vote, and I believe the community preference, is #4. Adding a magic word override would be a nice plus. Alsee (talk) 03:47, 22 September 2017 (UTC)

@DannyH (WMF): you ask us two questions:

1.) Who's going to make the decisions about the standard format -- the Enwiki community, the Wikidata community, or both working together?

2.) Are Wikidata descriptions just for putting a heading on Enwiki articles, or are there other purposes they serve that would require a description to be different than what the Enwiki community would want?

Neither of these is in any way a relevant question if you go with the requested solution, and to pose these questions here and now gives the strong impression that you don't intend to do this or haven't actually read this page. There will be descriptions on enwiki, either directly (as text in a template probably) or at runtime (as text parsed from the first line and/or from the infobox). There will be descriptions on Wikidata. Wikidata is completely free to decide their standard format (including copying them from enwiki if they so desire), Enwiki is completely free to decide their standard format as well; the only thing we have to do at enwiki is discuss this with the WMF or whoever is behind the apps, search results, ... so that we get the best possible result, something which is workable in as many circumstances as possible. Your question 1 is thus a false trilemma: the correct answer, which you happen to omit, is "both working separately". Question 2 is probably even worse. If you want to know what Wikidata descriptions are for go to Wikidata and ask them. When you come here, ask enwiki what we want to use the descriptions for (or make suggestions of course). For us, "Wikimedia disambiguation page" is a useless description; I can imagine that for Wikidata, it is the perfect description. Fine, no problem, that's their choice, their right and I have no intention to make them change this in any way at all. That would be rude, unhelpful. Unless of course you continue to force enwiki to use these decriptions, whether we want to or not, which is the direction you seem to take again and again. If enwiki has to display these Wikidata descriptions, then they will have to be the text we want, and Wikidata be damned. This will only lead to a direct confrontation between the two communities and much ill will between the two (and even more towards the WMF probably). If that's what you want, just say so. If that's not what you want, then think harder about what you post here and whether it is in any way helpful. We've had enough fiasco's in the communication between enwiki and the WMF (which you, as the one responsible at the time Flow went down the drain here are certainly aware of), it would be best if we avoided this here and could continue with the more productive, open tone the WMF had adapted at the start from this discussion. Fram (talk) 07:20, 22 September 2017 (UTC)

Continued: you state "There are a lot of useful descriptions on Wikidata, and I don't think it's practical for English Wikipedia to come up with five million descriptions from scratch." For starters, as evidence above a few times, many, many enwiki articles don't have a description at Wikidata, hundreds of thousands have an unhelpful one, and many others have an unnecessary one (where the description on Wikidata is the same or similar to the parenthetical disambiguation on enwiki). These descriptions are useful on Wikidata, but not here. So even to get as good as the WIkidata descriptions are now, we wouldn't need to come up with 5 million descriptions, 1 million would probably be sufficient. And we don't need to come up with them from scratch, multiple possible solutions have been given, like initially copying the Wikidata descriptions (preferably in a smart way, e.g. dropping the ones for lists and disambiguation pages), using text from the first line, or using info from the infobox (if the infobox is an "infobox album", you can construct a description with "a "year of album" "type of album" by "artist or band" description fairly easily). Yes, it would take some bot coding and one massive bot run, but it isn't the first time something like this has been done. Fram (talk) 07:26, 22 September 2017 (UTC)

Fram, you and I are more on the same page than you think we are right now. I'm sorry that I wasn't clear about my intentions in that post; I'll clarify. This is going to be okay. :)

The reason why I'm asking questions in this discussion is that I want everyone here to have a chance to think and talk through some possible alternatives. When you say "Neither of these [questions] is in any way a relevant question if you go with the requested solution" -- I want to point out that that's the solution that you requested, which is a good one. Other people in this current thread are talking about other approaches or variations on that approach, and I want to leave some space for people to think them through, so that we can get to something closer to consensus. I'm not planning to spend the rest of our lives dragging this conversation out, but people are still actively discussing some different ideas.

When I asked those two questions, I was trying to summarize the discussion above my post, where people were talking about "Wikimedia list page", "Disambiguation page" etc. The answer to question #1 could be "the Enwiki community should make those decisions", and #2 could be "yeah, Wikidata has its own purposes, and it's just not appropriate to use that description field on Wikipedia." That's where that discussion was trending, but I wanted to leave some room for somebody to come up with a compelling argument for an alternative.

For the part about English Wikipedia coming up with five million descriptions: the solution you're championing involves importing all of the existing Wikidata descriptions. That means that you think there's value in starting with the work that's already been done on Wikidata, and then using some of it, changing some of it and building on that work. I agree with you that that would be more practical than the alternative that Jytdog is supporting, which is to scrub all the Wikidata descriptions completely, and start over from scratch.

So: if changing and building on top of the existing Wikidata descriptions is the direction we're going, there are two different ways that we could do it. One is to do the bulk import, and fork completely from Wikidata, which is your requested solution. Another is to use the template/magicword as an override, as we did with the "related pages" feature a while ago. That means good and useful descriptions added on Wikidata in the future could still appear, while English Wikipedia contributors could change the descriptions for the pages/topic areas where the Wikidata descriptions aren't good enough. There's pros and cons for both directions. I think it's reasonable to have some discussion about those alternatives. -- DannyH (WMF) (talk) 19:14, 22 September 2017 (UTC)

As the queries above showed, there are a fair proportion of the descriptions of Wikidata that could benefit from some systematic improvement, either before or in the process of any such import. But also the statements at Wikidata can often provide just the content needed to do just that. Jheald (talk) 19:34, 22 September 2017 (UTC)

From my perspective Options 2 and 3 would be helpful: keep drawing from Wikidata, but allow a local override. I don't mind making changes to the Wikidata descriptions, but others do. Let's allow a local override. I would also add an option 3a:

Option 3a: Allow a null override of Wikidata description for cases where the title itself is adequately descriptive. So, History of Iran and List of songs featured in Shrek just don't have a description below them.

Also, let's write a manual of style for this, and see whether our MoS and Wikidata's overlap or not.--Carwil (talk) 04:13, 24 September 2017 (UTC)

Still, History of Iran might be a notable book with its own article, and it would be useful for descriptions to discriminate it from the item on the history proper.--Ymblanter (talk) 07:42, 24 September 2017 (UTC)

Option 3 can effectively be converted into 4a, by a bot running at one edit per second for two months overriding wikidata on every article. However if that is the result community wants, it would be better to do so directly via 4a rather than via a bot-hack on top of 3. Alsee (talk) 08:31, 24 September 2017 (UTC)

@Ymblanter: That's what History of Iran (book) is for. There's no need for any description in that case as well.--DarwIn (talk) 12:06, 24 September 2017 (UTC)

Really? If you see History of Iran (book) you know immediately what it is about? I actually doubt this.--Ymblanter (talk) 12:30, 24 September 2017 (UTC)

@Ymblanter: Most certainly. And if the book actually is about the History of Iran, as it should be in 99.9% of those situations, there's no need for description at all. When you look at it, you wouldn't think it's a book about "Fishing in Portugal", would you?--DarwIn (talk) 12:56, 24 September 2017 (UTC)

I do not know about you of course but I happen to think that the name of the author of the book is essential information about the book.--Ymblanter (talk) 13:00, 24 September 2017 (UTC)

@Ymblanter: Sometimes it is, sometimes it isn't - many of the most important History books I know are the work of a large group of people under some coordination, and not of a single author. And History of Iran (book) is more than enough "to discriminate it from the item on the history proper", as you stated. Anyway, I understand your point. When/if a description is needed, add one, just don't use Wikidata as the prime source for it.--DarwIn (talk) 13:08, 24 September 2017 (UTC)

For users of the mobile app and the VisualEditor, the description does more than disambiguate, it also clarifies the exact topic being referenced. So, A History of Iran should not just say "book" in the description, it should say "2008 book by Michael Axworthy." And The History of the Siege of Lisbon should (and now does) say "1989 novel by José Saramago." Unlike disambiguation pages, the descriptions should aim to still work even as more items are added to Wikipedia/Wikidata.--Carwil (talk) 15:47, 24 September 2017 (UTC)

clarification

User:DannyH (WMF) I am trying to understand your role at WMF and in the WMF decision-making process about what to do with the descriptions. I checked the org chart and it appears that you are within "Community Tech" as a "Senior Product Manager". Would you please clarify - are you here writing as some individual employee of the WMF, or as someone with authority over decision-making on this issue? It is also not clear to me how your position relates to Jon's; would you please explain? Thx Jytdog (talk) 19:43, 22 September 2017 (UTC)

Sure, I can see how that's unclear. Jon is the product lead on the Reading team; I'm product lead on the Community Tech team. In my work on Community Tech, I've had a lot of experience over the last couple years working directly with community members on feature design, including some experiences where things got heated. I was talking with Jon and other people on his team about this discussion, and they asked if I could take lead on the feature-related communication, and help to find a solution. I'm not directly in charge of the product team that would work on making these changes, but we're all talking, and when we get closer to a conclusion on the community side, I can bring everybody together, and we can figure out requirements and timelines. -- DannyH (WMF) (talk) 00:40, 23 September 2017 (UTC)

OK, thanks for explaining. So, a) you are kind of "chief negotiator" for the WMF here, and b) you are looking to arrive at a concrete solution here. Please tell me if I have that wrong.

Three additional questions:

With regard to the goal of arriving at a conclusion here, is the intent that what is decided here is what will be implemented, or is WMF intending to take the conclusion to RfCs at the relevant communities?

Reviewing what you have said here, my sense is that the WMF is unwilling to take the description off of all en-wP content (the apps, visual editor, etc). Is that correct?

If that is correct, who is the person at WMF responsible for the decision to not take the description off?

Thanks again. Jytdog (talk) 01:05, 23 September 2017 (UTC)

Regarding Jytdog's last two additional questions: indeed, a lot of talking next to each other seems to be going on. Seems like, to use an analogy, WMF is trying to keep a car with a leaky tire driving (we'll figure out how to repair or replace the leaky tire while driving, in a sort of "think of the children" reasoning ("how would they get to school without the car?" or something in that vein)), while many of the Wikipedians in the discussion give clear signals the car would be better taken out of traffic first, and not allowed back in traffic before the leaky tire situation is remedied. The proverbial children may never reach school in the car driving around with a leaky tire. For the less technically inclined: continuing to drive around with a leaky tire is not so much an issue of loss of comfort, as the technical fact that it makes the tire heat up, and ultimately explode, due to friction causing heat and heat causing air to expand uncontrollably ("friction" and "hot air on the brink of explosion" fit well in the analogy of what I'm seeing on this page). So, indeed, who is the driver who can decide to take this car out of traffic before serious injury (read: some sort of loss of credibility for WMF projects, ultimately leading to less users) is caused? Figuring out repair modes is less prone to controversy during a period when the vehicle is temporarily not "live". --Francis Schonken (talk) 08:49, 24 September 2017 (UTC)

Well put. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 13:01, 24 September 2017 (UTC)

Removing all of the Wikidata descriptions "immediately" would be a time-consuming engineering project that would take longer to implement than finishing this discussion and coming up with a better solution. It's really not a practical strategy. I understand why people aren't trusting the Foundation on this, since there was already an RfC. And I understand why people aren't trusting me, because why should you, and it's up to me to act trustworthy. I'm going to keep talking to people about a practical solution. I think the Crimean school bus is going to be okay for a minute. -- DannyH (WMF) (talk) 16:21, 24 September 2017 (UTC)

??? Who said anything about "removing all of the Wikidata descriptions"? I understand it is just about disabling an automatic coupling of "Wikipedia" and "Wikidata" in the two remaining apps that still make this coupling (and keep it off in all implementations where en.Wikipedia editors can't turn it off by removing a template etc). All the rest is "solutions", or not something for which WMF needs to intervene (whether or not Wikidata content is pulled via certain en.Wikipedia templates, is, as such, and putting it in as few words as possible, nothing for you to negotiate). Wikidata descriptions are of course useful within the Wikidata system, for instance when manually updating an item's properties. So, nobody asked to remove Wikidata descriptions from the Wikidata system.

@DannyH (WMF): seems the basic distinctions needed to negotiate in this discussion are lacking (e.g., distinction between "content", which nobody asks to remove, and "automatic coupling of Wikidata and Wikipedia", which the en.Wikipedia community has asked to switch off in all remaining apps that still do that *automatic* coupling). Maybe time to ask for a different negotiator, that is, one who can make these distinctions. --Francis Schonken (talk) 16:56, 24 September 2017 (UTC)

@Francis Schonken:: sorry, that's what I meant by "removing all of the Wikidata descriptions" -- taking out the automatic couplings from the apps. I didn't mean removing them from Wikidata. The concept of removing Wikidata descriptions from being displayed on the apps sounds simple, but is actually technically more complex than it sounds, because they're integrated in a lot of different places. It's not a grand project that would take months, but it would take more than the couple weeks that I hope it will take to figure out a better consensus solution to this problem. -- DannyH (WMF) (talk) 13:31, 25 September 2017 (UTC)

DannyH, that ("figure out a better consensus solution to this problem", combined with the previous sentence, sounds as if you have already decided that "taking out all the automatic couplings from the apps" is not the best (or even a good) solution. Why? That it may be hard for the developers (which may or may not be true, the WMF has too often used this excuse even when it was patently untrue) doesn't mean that it isn't a good solution or that we have to find a better one. You still seem to be pushing for a certain direction (pro-Wikidata), despite claiming that this is not what the WMF does. And of course, you (WMF) could take them out one by one, and keep us posted about the progress. Or you could actually present a concrete reply to some of the suggested better (!) solutions, like introducing a new, general template which (like Persondata) could be used across wiki-languages and could be read by the WMF where needed. As it stands, I see very little actual progress being made by the WMF, more stalling and pushing in a certain direction. Fram (talk) 13:41, 25 September 2017 (UTC)

User:DannyH (WMF) thanks for posting here. Would you please answer the three follow up questions? Thanks! Jytdog (talk) 18:48, 24 September 2017 (UTC)
- @Jytdog: just a friendly suggestion: maybe reformulate the second follow-up question a bit clearer, the part starting from "take the description off of all ..." which may have set Danny on a wrong foot regarding what exactly was being asked (if I understand correctly, Danny seemed to think that the request was to "remove all of the Wikidata descriptions", which is a question they answered with "no", but not really the question you asked, I suppose). --Francis Schonken (talk) 19:15, 24 September 2017 (UTC)

Jon listed the places where it is used well above in their section 4 which I will copy/paste here:

As you may know Wikidata appears in other places on Wikipedia. Wikidata descriptions appear not only below the title on mobile web in all languages except English and Russian, but in the following places:
Apps under the title

Visual editor (desktop and mobile)

Portal search (www.wikipedia.org)

Mobile web and mobile app search

Related pages (bottom of mobile web and app pages)

iOS widgets

App maps feature

Apps feed feature

The ones that are of the most concern are the first two, as both are explicit interference with en-WP content. I understand the descriptions have been taken down from the 4th in en-WP as a result of the March RfC. I have been uncomfortable with use of the Wikidata description field in the various navigation places -- as far I understand it, these uses arose in the course of the work of the Discovery team following the lines laid out by the Knowledge Engine debacle under Leila when the WMF completely lost its way and wanted to become The Great Aggregator of All Noncommercial Content... but I am not currently contesting that use for those purposes. I probably should, and may do later, but that is not the issue now. So to restate the three questions

Is the intent that what is "decided" here is what will be implemented, or is WMF intending to take the conclusion to RfCs at the relevant communities?
Would you please confirm that WMF is unwilling to remove the Wikidata descriptions from Apps under the title ~~and Visual editor (desktop and mobile)~~ for en-WP content?
If that is correct, who is the person at WMF responsible for the decision to not take the description off these places?

-- Jytdog (talk) 19:33, 24 September 2017 (UTC) (removing VE as this is a navigation thing Jytdog (talk) 18:05, 25 September 2017 (UTC))

"as far I understand it, these uses arose in the course of the work of the Discovery team following the lines laid out by the Knowledge Engine" eh.. that seems extremely unlikely to me. Other than the portal work, all those usages originate from different teams. I think some even predate that entire team... —TheDJ (talk • contribs) 12:38, 25 September 2017 (UTC)

@Jytdog: P.S... what makes VE a content usage in your view? To me the usage by the link inspector seems more similar to the other usages, than to the subtitle usage... —TheDJ (talk • contribs) 15:00, 25 September 2017 (UTC)

Perhaps I am misunderstanding: i don't use VE and didn't actually go check. By listing "VE (desktop and mobile)" this way, I believed that the description field is what you see at the top of an en-WP article when you are using VE on web or mobile. Is something else meant? Jytdog (talk) 15:10, 25 September 2017 (UTC)

That's absolutely not how the VisualEditor uses these descriptions. It offers a drop-down menu for new links—see image on the right—which is (as I said above) exceptionally useful for people editing a page. When the link is chosen, you don't see the description, nor the does the VisualEditor help you see or edit the Wikidata description of the page you are currently editing.--Carwil (talk) 17:28, 25 September 2017 (UTC)

I see, so it is a navigation thing. As I noted above, this is... problematic but not what I am focused on now. Thanks for explaining. Jytdog (talk) 18:05, 25 September 2017 (UTC)

Hi everyone: Based on the conversations that we've had here, I've made recommendations to the Reading team and to Product as a whole. It's going to take people a day or two to talk about it, just because there's a bunch of people to check in with, in different time zones. I don't want to say much about what the recommendations are just for the next day or so, because I don't want to end up making promises that I couldn't keep. I'll definitely get back to everyone here by end of the day Wednesday (in SF) -- if I don't have anything clear to say then, I'll at least check in and explain what's going on in more detail.

So, to answer Jytdog's questions: #1. My intention is that decisions here will be implemented. There was already an RfC in March, and based on the discussions here, I don't think another RfC would be much different. But, like I said, there needs to be conversations with a bunch of people. #2. Right now, while this conversation is going on, (ie for the next couple days, and maybe couple weeks if things drag out) the WMF does not want to pull all of the Wikidata descriptions out of the apps before we've all discussed and agreed on a solution. That's what I've understood from Jytdog's posts over the last week -- that the Wikidata descriptions should be pulled from the apps immediately (as in, today) before we discuss or decide on a solution that gives Enwiki editors more control over the descriptions. If the question is "Would you please confirm that WMF is unwilling to ever remove the Wikidata descriptions," then the answer is no, we are not permanently unwilling to to ever remove them or give Enwiki editors more control. Sorry, I'm trying to be super extra clear, but there are a couple double negatives involved. :) #3. The decision to not remove the Wikidata descriptions this week is shared among pretty much everyone at the WMF, because we want a couple more days to talk about it and figure it out. The decision on whether to remove the description or give Enwiki editors more control has not been made; we'll be talking about it, and I'll definitely check back by Wednesday. Sorry I can't be totally definitive right now. I know that it's frustrating that people on this page have been talking about this since March (or longer) and you're not getting a definitive answer right now. -- DannyH (WMF) (talk) 13:51, 25 September 2017 (UTC)

Thanks for your replies. The notion that the WMF is "considering" giving the en-WP community "more control" over en-WP content is completely upside down. I will until your Wednesday reply before deciding my next steps. Jytdog (talk) 18:19, 25 September 2017 (UTC)

DannyH (WMF) as long a reasonable progress is being made, I accept that it would be more efficient to leave the current system in place while building an agreed-upon-solution. On the other hand, I'm feeling a bit wary/paranoid about the vague way you phrased "give Enwiki editors more control". If that means continuing to use wikidata descriptions and providing 'more control' by increasing wikidata-integration - then I am willing to help draft an RFC on the proposed enhancements. However I don't support it and I suspect the proposal will fail. Alsee (talk) 18:45, 25 September 2017 (UTC)

Alsee, if in their Wednesday response the WMF doesn't say it is taking the descriptions down from the apps and that it will seek consensus from the relevant editing communities before re-instating some new version, I am thinking that I will re-instate an RfC along the lines of the one you asked me to take down. In my view this is somewhat of a movement constitutional crisis. The folks from WMF don't understand the fundamental deal here (volunteers generate content following their project policies and guidelines; the WMF publishes it) nor do they understand the importance of consensus nor even why that process is so fundamental in this environment. (It is telling that they were going to run with whatever the few people talking here had suggested.)

I realize that the descriptions are just a few words but the principles here are important to me, and I think they are important to most other people in en-WP as well. The world should not remain upside down. Jytdog (talk) 19:22, 25 September 2017 (UTC)

Isn't stripping functionality for 5.6 million Android users, unknown millions of iOS users ([2]) on the Mobile App, and thousands of VisualEditor users because of "a constitutional crisis" between active editors and WMF exactly what WP:POINT is meant to try and prevent? Why are we not talking about this in terms of the experience of readers: What helps them navigate? What helps new editors write (and link)? What will cause the least astonishment: fixing a problem iteratively or ripping out functionality and then putting it back in?--Carwil (talk) 17:26, 27 September 2017 (UTC)

Putin: But look, I really improved the highways in Crimea! Isn't that great?! I mean, look at this metric I created -- all the numbers are great!! I am improving Crimea while all you people just stand around and wring your hands over trivia and criticize me. Stop getting in my way and help me improve Crimea!"

Rest of the world: "....." Jytdog (talk) 17:30, 27 September 2017 (UTC)

When the WMF builds a highway—I mean an app—it appears simultaneously in every country—I mean language. The "rip it out" request requires forking the Wikipedia app to be less functional in English than any other language. Again, we and the WMF collaborating and interdependent, not sovereign and independent. Anyhow, you're just reinforcing that this is about making a point, not improving the encyclopedia.--Carwil (talk) 17:39, 27 September 2017 (UTC)

Putin: "The territorial imperatives of Russia are not a matter for you tiny people to debate. Now who will help with the highways in Crimea!? Where is my 'attaboy!' for this great work I did!?"

Rest of world: "................." Jytdog (talk) 19:45, 27 September 2017 (UTC)

Hi everyone: I said on Monday that I would let you know what's going on today. The product team is still talking things over, so I don't have anything substantial that I can talk about yet.

There are a bunch of people from several different teams who are actively talking about this question right now, and what our response should be. People are coming at this from different perspectives, and as you know, sometimes it takes a while to reach consensus.

We're having a meeting tomorrow morning to talk things over. I don't know if we'll have a clear answer yet, but I'll definitely come back to this page tomorrow and let you know how it's going. This issue is important, and we're taking it seriously; we want to make sure that we're on the same page, when we come back here and talk with you all again. Sorry for the delay, I'll write more tomorrow. Thanks. -- DannyH (WMF) (talk) 00:38, 28 September 2017 (UTC)

Proposal from WMF

Hi everyone: As I mentioned yesterday, the product teams had a discussion this morning about the Wikidata descriptions. I'll tell you how we're thinking about the problem, and what we think would be a good direction for the feature. We're seeing this as a continuing discussion, so we want to know what you think.

Short descriptions are useful in search, and they're essential to features that are used very heavily on the apps, including the list of Top Read articles. Removing the descriptions completely would be damaging to the readers' educational experience, with no benefit to anyone.

But there is a problem with editorial control and dispute resolution, which we didn't pay enough attention to. When there's a content dispute on English Wikipedia, there's a structure for how to resolve it, with a way to escalate the problem if the editors can't resolve it amicably. We don't have a structure like that for cross-project work, so if there's a difference of opinion between Wikipedia editors and Wikidata editors, it's difficult to resolve. The existing feature gave that editorial control to Wikidata, because they had a structure for defining a short description. But through this discussion, we're understanding that if the page we're showing is from English Wikipedia, then it's appropriate for English Wikipedia to be the center for editorial control. So we're thinking of the proposed approach as a cross-project default with a local override, which gives the local community the ability to resolve any differences. This is similar to the way that we use images from Commons, or interwiki links from Wikidata.

We're proposing a new magic word -- {{#D:description}}, or something similar. That local description would be the one that's used. If there's no magic word or the parameter is left blank, then it defaults to the Wikidata description.

We think that it wouldn't make sense for English Wikipedia to start from scratch and create millions of descriptions, so the local override would allow people to use the existing Wikidata material that's good, and override it when there's a reason to fork from the Wikidata version. We'd like to encourage people to continue partnering with the Wikidata community as a source of new and updated descriptions, but we also acknowledge that once this feature is set up, it's up to the English Wikipedia community to decide how to use it.

If this is where we're going, then we'll also talk about how editing descriptions in the app should work. Right now, on all languages but English, users on the Android app can edit the Wikidata descriptions. We could work on supporting editing the local exceptions instead, but we'll need to figure out how the user interface would work. We're still talking about it, and we're interested in what other folks think.

Now, if descriptions are still coming from Wikidata as the default, then people will want to be able to monitor changes from Wikidata. Right now, you can see Wikidata edits in your watchlist if you uncheck "hide Wikidata" or enable the Wikidata edits filter, but that includes all edits to the item, not just the English description. The Wikidata team is currently working on showing only the locally relevant Wikidata properties -- a test version of that feature is currently live on Greek Wikipedia -- but it's too early to say when that feature would be available for English.

Like I said, we'd like to continue this discussion with folks here, to find out what you think and see if we can get closer to a consensus on this feature. While this discussion touches on larger questions -- like governance on cross-project features, inter-project dispute resolution, and Wikidata integration in Wikipedia -- I think that this discussion isn't the right place to resolve those. I'd like to keep this conversation focused on the practical things that we can do to restore English Wikipedia's editorial control for the short descriptions. If you think this requires bigger conversations, we're open to having those discussions, but I want to work on tangible solutions here. So that's where we are right now. What do you think? -- DannyH (WMF) (talk) 23:31, 28 September 2017 (UTC)

This is not like how images from the Commons are used. Use of images from the Commons in en-Wikipedia is a) driven by en-WP editors who add images to en-WP voluntarily one by one, and b) is governed by en-WP's WP:Image use policy.

When you say "We'd like to encourage people to continue partnering with the Wikidata community", I hear "extortion".

The Wikidata field will show, and if it violates en-WP policy, then it is up to en-WP editors to take action to override it, and everybody has to learn some weird template to do that. I do not find it all reasonable that WMF dumps a bunch of unsourced content into en-WP and then just leaves that for en-WP volunteers to fix (and that you would "give" us tools to fix it, is even crazier.) I have said this before but the arrogance and ignorance of this, is just beyond my understanding. And I really believe you have no idea at all how batshit crazy what you are saying is or how blatantly the WMF is displaying power and disdain.

Putin: "So I get it that that when we changed all the highway signs in Crimea to Russian that has messed with people and we have done some mistranslations maybe. You all can fix those signs where ever you find them - I will give you all some paint brushes. OK, go get moving. Aren't these highways great?!"

Rest of world "...................... "

Please listen to the metaphor. This is what you sound like.

You never got consensus to systematically add content to Wikipedia. You just moved on in. Jytdog (talk) 03:05, 29 September 2017 (UTC)

It was a (very) bad idea to give Wikidata editors control over Wikipedia content. Giving Wikipedia editors a gizmo with which they can control Wikidata content is a stupidity of the same order, and doesn't even begin to address the first issue, which was, summarized: one WikiMedia project should not decide on the content of another WikiMedia project. Wikipedia editors do not control the content of Commons (which seems to be a misunderstanding in Danny's explanation above), Commons editors do not control what Wikipedia editors decide to retrieve (or not) from Commons for use in Wikipedia. --Francis Schonken (talk) 05:56, 29 September 2017 (UTC)

Another way to think about this, is that WMF has essentially run a bot to systematically add content to en-WP articles. en-WP has a bot policy: WP:Bot policy. Did WMF go through the process described in that policy to run the software that made these systematic changes to en-WP content in the apps? Jytdog (talk) 06:00, 29 September 2017 (UTC)

"So we're thinking of the proposed approach as a cross-project default with a local override, which gives the local community the ability to resolve any differences. This is similar to the way that we use images from Commons, or interwiki links from Wikidata." As has been siad countless times now, this is not how we use images from commons. With Commons, we decide which image, if any to use, no images are sent by default ever (I hope, or has the WMF done this as well somewhere?). Interwiki links is exactly what Wikidata has been set up for, and where enwiki and the others voluntarily relinquished the lead. But this is not content shown in articles and seen as the first thing by all mobile or app users.

"We're proposing a new magic word -- {{#D:description}}, or something similar. That local description would be the one that's used. If there's no magic word or the parameter is left blank, then it defaults to the Wikidata description." No, no, no! The default is enwiki. There may be an override where we can explicitly say "use the Wikidata description instead", but in many cases we will want no description at all, or certainly prefer "no description" over "the Wikidata description". The examples of lists and disambiguation pages have been given, or something like Spirit (Depeche Mode album), which doesn't need a description here, and certainly not the utterly redundant "Depeche Mode album" used as description on Wikidata (where this description makes 100% sense). At the very, very least, either "no magic word" or "magic word without description" should result in "no description" instead of the Wikidata one. My preference would be "no magic word = no description".

"We think that it wouldn't make sense for English Wikipedia to start from scratch and create millions of descriptions, [...]" I doubt that Wikidata hsa "millions of descriptions" we could use, if you discount all lists and disambiguation pages, and most or all pages with a disambiguator on enwiki (which already serves as a description in many cases), and take into account all pages on Wikidata without a description anyway. Bot adding the magic word to all pages which don't meet the above exceptions shouldn't be too hard anyway. Using a smarter bot instead which creates descriptions from either enwiki first lines or enwiki infoboxes may be even better of course.

"We'd like to encourage people to continue partnering with the Wikidata community as a source of new and updated descriptions [...]" Why? It is not the role of the WMF to encourage or discourage such things, and the descriptions on Wikidata very often serve a different purpose than the ones here. It doesn't make sense to look at a much smaller, multilingual community to be the source of descriptions on enwiki, when the descriptions on that community often serve a different need in the first place.

"We could work on supporting editing the local exceptions instead, but we'll need to figure out how the user interface would work. We're still talking about it, and we're interested in what other folks think." Well, it would be rather ridiculous to show people the enwiki description, and then have an "edit" functionality that sends them to Wikidata, where any change they make won't affect the end result anyway. Which is a god reason to drop the "use Wikidata decriptions under circumstances X, Y and Z anyway" approach and go for a full and only enwiki approach instead. Fram (talk) 06:45, 29 September 2017 (UTC)

Note: I've added this discussion and proposal to WP:CENT [3], feel free to amend the note if it is unclear or biased. Fram (talk) 06:56, 29 September 2017 (UTC)

Note 2: now also added to WP:VPPR, WP:AN and WP:BON. Please drop a note elsewhere if necessary. Fram (talk) 07:08, 29 September 2017 (UTC)

Bottom line: WMF thinks that short descriptions of some kind are essential, and doesn't believe the airy assertions above that 5 million perfect pink unicorns can be created here overnight. Instead, it suggests going with the nags we already have, even if some of their faces need a wash; and trusting in the wiki way of improving these where they fall short, by opening them to the community and letting the community improve them. (It's also a lot easier to improve them and systematise them at scale on WD than it would be here). In some cases they may not be great, but in most cases the current descriptions or auto-descriptions are better than nothing and at worst mostly harmless. The proposed over-ride mechanism lets editors improve descriptions from in here if they want to, and start hand-crafting bespoke descriptions for WP where we can be bothered -- eg in the first instance perhaps for the pages that are highest rated or most read or considered to be at a particular high risk. And probably a mechanism will evolve to offer these locally optimised descriptions back to Wikidata.

User:Jytdog might like to reflect on a point that earlier versions of one of the policy pages, perhaps WP:NOT, were quite brutally blunt about: WP is not a democracy. Ultimately it's WMF that owns the servers, and they can and will do what they want. If you don't like that, WP is not WP:COMPULSORY. Jheald (talk) 08:05, 29 September 2017 (UTC)

To be honest, I do not see any problem. There is an RfC that descriptions should be not taken from Wikidata automatically. There is a common wisdom that they can be taken from Wikidata, but many people, some of whom are especially vocal, believe this is not appropriate. I think the solution is obvious: (i) make a mechanism which would only show a Wikidata description on the English Wikipedia if the description was created from the English Wikipedia (similarly to interwiki links) or validated from the English Wikipedia in a similar way; (ii) instantly disable and do not show Wikidata descriptions unless validated. This is the only way to let people to start caring, and it should not affect any other projects.--Ymblanter (talk) 08:11, 29 September 2017 (UTC)

We can do more than nothing. And I don't think WMF actually wants to pull this kind of power play. I really hope not. Jytdog (talk) 08:28, 29 September 2017 (UTC)

This is also how I personally see it: since descriptions are tightly bound to article and language (this en-Wikipedia in this case), the solution which would make the most sense to me would be not for WikiData entries to be overridable by a special/magic variable, but for it to originate from en-Wikipedia directly, considering that it's only a short text which could be as part of a template. A bot could initially import existing descriptions into en-Wikipedia articles. However, I understand that from an implementation's standpoint the existing code depending on WikiData and perhaps the mobile applications might need modifications if this was done. An alternative would be to support the proposed override magic variable and to use a bot to override all existing uses, such that the code requires less changes while technically obtaining a similar result... On the other hand, while new articles are created, more and more articles could end up with descriptions from WikiData in the long term (unless a regular robot run systematically moved to en-Wikipedia any WikiData-originating description). —Paleo Neonate – 08:32, 29 September 2017 (UTC)

I am sure 95% descriptions can be generated by bots and be acceptable on both English Wikipedia and Wikidata. I think the real question is what to do with the existing description. I proposed to not show them on the English Wikipedia unless explicitly validated (possibly by bot)--Ymblanter (talk) 08:42, 29 September 2017 (UTC)

In the event any sort of 'magic word' was implemented, it would be trivial to create a bot to run through the ENWP articles making sure none get descriptions from wikidata. It might be a large number of articles (as Fram has pointed out it might not be as large as expected) but that would still be a matter of time to work through, in the weeks rather than months. If the end result is WMF using valuable engineering time in order to implement something we can then use to actively prevent any Wikidata descriptions being shown, it would be time better spent just disabling the descriptions from wikidata from your end. Its a waste of time and money implementing something that will only be used to bypass a *previous* waste of time and money. Only in death does duty end (talk) 09:26, 29 September 2017 (UTC)
There's a lot coming up here, but I want to respond to one thing in particular. As I said yesterday, we want to give English Wikipedia control of the descriptions. When we're figuring out possible solutions with you all, the thing that makes it hard for us is the idea of blanking all of the current descriptions.

I agree with Fram that the Wikidata descriptions that describe the page rather than a subject are useless -- "Wikimedia list page," "Wikimedia disambiguation page," and any other examples of that kind of thing. Those should be removed, and that's something we can do. But there are lots of helpful existing descriptions that make using the app a better learning experience, and the idea of going from x million descriptions to zero, even for a short time, is hard for us to agree to. That's what made us lean towards local exceptions, rather than automatically pulling all descriptions from Wikipedia. I think that we could come to a productive, workable solution that gives control back to English Wikipedia where it belongs, if that solution doesn't involve a period when there are no descriptions displayed at all. What do you think? -- DannyH (WMF) (talk) 22:52, 29 September 2017 (UTC)
Why is it such a hard thing to agree to? It would indicate that WMF is willing to accept Wikipedia control over Wikipedia content. Retaining the descriptions shows a reluctance to leave Wikipedia content/appearance in the control of Wikipedia, and sends us a message that (somebody at) WMF is dead set on continued interference and on winning this battle, which should not even be a battle. This reluctance is likely to escalate the problem. · · · Peter (Southwood) ^(talk): 06:09, 30 September 2017 (UTC)
"If there's no magic word or the parameter is left blank, then it defaults to the Wikidata description." What is the justification for this proposed behaviour? I can understand, if not necessarily support, wanting to continue using the WD descriptions as default, and using the magic word to "opt out" for a localised description instead, but articles are not created containing magic words by default: editors place them there deliberately. And it follows that if a blank {{#D:}} tag is in an article, it is because editors feel the description should be left blank. The null parameter should be respected as a null description. Please don't make use pass a single non-breaking space to all the pages we feel are better left without descriptions. Snuge purveyor (talk) 08:52, 30 September 2017 (UTC)
I have not seen objections which address the key point mentioned just under "Proposal from WMF", namely that descriptions are very useful as they allow the software to give better results when people search for topics, and they allow showing a brief outline of what an article covers when listing Top Read articles. Those objectives should be supported. Johnuniq (talk) 10:13, 30 September 2017 (UTC)
- @Johnuniq: Personally, I find descriptions very useful, and I applaud that idea to make such thing appear at certain places, such as the search list, or the mobile app. In Wikipedia I've the article preview gadget activated, which does a similar function (and sometimes in a better way), and I recognize the great value of those short descriptions. But they should be entirely placed on the Wikipedia side, and under Wikipedia control. That's where content belongs to, that's where it can be properly curated, maintained, updated. Wikidata is useful for interwikis and possibly other things, but should never had been brought into this process. They should be excluded from it as soon as possible. Wikidata here it's only messing up things, with no gain at all. Generate short descriptions on the fly from the leading sentence/infobox from Wikipedia articles, seems to me by far the best option, if it's possible to implement. If Wikidata wants those descriptions as well, they can copy them afterwards, and do whatever they would like to with them.-- Darwin ^Ahoy! 12:31, 30 September 2017 (UTC)
I don't think this proposal is going to work, because it is a compromise. More important, I think it puts WMF in the awkward position of having to defend this compromise, while the community itself is still deeply divided. This opens up the foundation to a neverending amount of wikilaywering that they have to deal with. This community clearly has no interest in evolving any of this, has no consistent message for WMF and no plan. Just return it back to status-quo pre-2015, so that we can move past the drama. I'm not saying we should not have this functionality on English Wikipedia, but by now I've arrived at the point, where as WMF I wouldn't work on this until the community has made a design for it and gets sizable portion of the community to sign off on that design. It's time to let the editors do the software development, they clearly have a desire to work on this. This has gone on long enough, the foundation has more important stuff to work on. —TheDJ (talk • contribs) 18:00, 30 September 2017 (UTC)
DannyH (WMF), I think there is a lot of understanding for your concern: thing that makes it hard for us is the idea of blanking all of the current descriptions. Maybe it will help if I explain why that option keeps coming up. Many on the community side find it hard that the WMF keeps turning the discussion to blanking descriptions. I believe the effective community consensus would be for using the lead sentence, preferably with the override option added. That would effectively give descriptions for all articles. Major win. The reason 'blanking' comes up is because we can't build the desired solution from our end, and we do not presume to be able to order you to build it. When the WMF drops that option from the discussion, we naturally turn to the options that you leave available to us. When you narrow the discussion to "The WMF won't discuss anything except Wikidata descriptions", people who think this shouldn't be Wikidata at all are cornered into the "blank it" option. I don't know if the WMF is willing to discuss non-Wikidata solutions, but hopefully this helps you and others at the WMF understand why the discussion is going the way it is.
Remember when I said I was wary and paranoid about what response you would bring back from the WMF side? I am disappointed, but completely unsurprised that you silently excluded the non-Wikidata option from discussion. You haven't explicitly declared it "out of scope for discussion", but your response here has implicitly done so. You are effectively asserting that "blank it" is the only alternative remaining on the table. Alsee (talk) 04:30, 1 October 2017 (UTC)

first sentences

Alsee, thanks for saying that. Actually, using the first sentence isn't out of the question -- you're right, I should have talked more about that option. I think you're right that blanking has come up because of WMF stonewalling, and then we respond to that by getting more nervous about community control, and the cycle continues. I should be thinking outside that cycle. We're going to have more internal conversations about solutions today, and I'll make sure that deriving descriptions from the first sentence is part of the discussion. I'll report back later today on what we're thinking. Thanks. -- DannyH (WMF) (talk) 16:29, 2 October 2017 (UTC)

Okay, we talked about it some more today. If folks here don't feel like the Wikidata-hosted descriptions with local override gives enough control, we're open to another idea which has been proposed on this page, which is copying the existing descriptions from Wikidata to English WP using the magic word, at which point everything is under English WP control, and people can decide on appropriate standards as people usually do on wikis. I'm interested in hearing people's thoughts on that alternative.

We talked about pulling descriptions from the first sentence, rather than copying the existing description from Wikidata, and it doesn't sound to me like it would be an improvement. It's possible to write some code that pulls out the subject, the words "is a", the pronunciation, etymological data, birth and death dates, etc, and end up with a short description. But those descriptions would be flawed, in the way that algorithmically-generated text always is, and in the past, English Wikipedia editors have objected to doing things algorithmically that could be done better by hand. The majority of existing descriptions are already the same thing that what we'd want to generate anyway.

I'm going to do a quick comparison here, using the 33 pages listed in today's Top Read module. I'll post screenshots so you can see where these come from, and then compare the existing description and what we'd want the algorithm to pull from the first sentence. Here's the comparison:

Here's the list:


Article	Wikidata description	Derived from first sentence
Catalonia	Autonomous community of Spain	Autonomous community of Spain located on the eastern extremity of the Iberian Peninsula
Hugh Hefner	American businessman and magazine publisher	American business, magazine publisher and playboy
Puerto Rico	Unincorporated Territory of the United States	Unincorporated territory of the United States located in the northeast Caribbean Sea
O.J. Simpson	Retired American football player and actor	Former National Football League (NFL) running back, broadcaster, actor, advertising spokesman, and convicted armed robber and kidnapper
Catalan independence referendum, 2017	Independence referendum in Catalonia, 1 October 2017	The regional Government of Catalonia held a referendum on Catalan independence on 1 October 2017
Monty Hall	Game show host	Canadian-American game show host, producer, and philanthropist
Marilyn Manson	American rock musician and actor	American singer, songwriter, musician, composer, actor, painter, author and former music journalist
It (2017 film)	2017 film by Andres Muschietti	2017 American supernatural horror film directed by Andy Muschietti, based on the 1986 novel of the same name by Stephen King
John Lithgow	American character actor, musician, and author	American actor, musician, poet, author, comedian and singer
Gerald's Game	Book	1992 suspense novel by Stephen King
Deaths in 2017	Wikimedia list article	Chronology of deaths in 2017
Blade Runner	1982 American science fiction film	1982 American neo-noir science fiction film directed by Ridley Scott and starring Harrison Ford, Rutger Hauer, Sean Young, and Edward James Olmos
Compulsory sterilization in Canada	(no Wikidata item, uses first sentence)	Compulsory sterlization in Canada has a documented history in the provinces of Alberta and British Columbia
List of Dragon Ball Super episodes	Wikimedia list article	(probably don't include descriptions for "List of" articles)
Kingsman: The Golden Circle	2017 film by Matthew Vaughn	2017 action spy comedy film produced and directed by Matthew Vaughn and written by Vaughn and Jane Goldman
Judwaa 2	2017 film by David Dhawan	Indian Hindi-language action-comedy film directed by David Dhawan
Barry Seal	American smuggler of drugs and arms, aircraft pilot, dealer, and money launderer	American airline pilot who became a major drug smuggler for the Medellin Cartel
Meghan Markle	American fashion model, humanitarian, and actress	American actress, model and humanitarian from Los Angeles
Joanna Gleason	Canadian actress and singer	Canadian actress and singer
Queen Victoria	British monarch who reigned 1837-1901	Queen of the United Kingdom of Great Britain and Ireland from 20 June 1837 until her death
Blade Runner 2049	2017 film by Denis Villeneuve	Upcoming American neo-noir science fiction film directed by Denis Villeneuve and written by Hampton Fancher and Michael Green
Inhumans (TV series)	TV series	American television series created for ABC by Scott Buck, based on the Marvel Comics race of the same name
Star Trek: Discovery	American television series	American television series created for CBS All Access by Bryan Fuller and Alex Kurtzman
Ryan Gosling	Canadian actor	Canadian actor and musician
Cardi B	American hip hop recording artist, as well as a television and social media personality	American hip hop recording artist, and comedian as well as a television and social media personality
Max Verstappen	Dutch racing driver	Belgian-Dutch racing driver who competes under the Dutch flag in Formula One with Red Bull Racing
The Founding Ceremony of the Nation	Painting series by Dong Xiwen	1953 oil painting by Chinese artist Dong Xiwen
Big Mouth (TV series)	(no Wikidata item, uses first sentence)	American adult animated sitcom created by Nick Kroll, Andrew Goldberg, Mark Levin, and Jennifer Flackett based on Kroll and Goldberg's teenage years growing up in the suburbs of New York City, with Kroll voicing his fictional self
Catalan independence	(no Wikidata item, uses first sentence)	Political and popular movement, derived from Catalan nationalism, which seeks the independence of Catalonia from Spain
Gerald's Game (film)	2017 American psychological horror thriller film directed and edited by Mike Flanagan	2017 American survival horror film directed and edited by Mike Flanagan and written by Jeff Howard and Flanagan
Pablo Escobar	Colombian drug lord	Colombian drug lord and narcoterrorist
Spain	Constitutional monarchy in Southwest Europe	Sovereign state located on the Iberian Peninsula in southwestern Europe, with two large archipelagoes, the Balearic Islands in the Mediterranean Sea and the Canary Islands off the North African Atlantic coast, two cities, Ceuta and Melilla, in the North African mainland and several small islands in the Alboran Sea near the Moroccan coast
Kingsman: The Secret Service	2014 film by Matthew Vaughn	2014 action spy comedy film directed and co-produced by Matthew Vaughn

Now, I would want to improve some of those existing descriptions, but on the whole, I think the existing ones are better than the generated ones would be. The generated descriptions are often longer, and a human is better at deciding which words are important and which aren't.

So I don't think the existing Wikidata descriptions are toxic; they don't need to be killed with fire. They're mostly fine. I agree with folks here who say that English Wikipedia should have editorial control over the descriptions, and I want to figure out a process that gets us there without having a period where users don't see any descriptions at all. What do you think? -- DannyH (WMF) (talk) 02:07, 3 October 2017 (UTC)

Looking at the most viewed pages obviously gives a biased result about how good the descriptions are, as they are more often viewed and a specific type of articles (not e.g. the lists and disambiguations). In any case, I agree that it would be better not to have a period without descriptions, if this can be achieved in a reasonable time period. Not having descriptions for a while isn't too terrible either, we did well without them for a very long time anyway, but if we can achieve a smooth and relatively fast transition then so much the better. Basically, 1. the WMF has to tell us which template or magic word they would support (this should come from WMF an dnot from us, as perhaps other wikis may want to follow the same path), 2. enwiki has to decide how to implement and fill that template/magic word, 3. a bot must do the actual implementation, and 4. the WMF needs to change (application by application presumably, no need for a big bang) all instances where this description is now used / shown. Fram (talk) 08:09, 3 October 2017 (UTC)

DannyH (WMF), I'd like to confirm my understanding. Is it accurate to say the current proposal is (1) a bot to add {{#keyword:copy of wikidata description}} to articles then (2) turn off Wikidata descriptions? An article without #keyword would have a blank description?

Assuming I understood it correctly, I think this should be agreeable. I think we would want #keyword inside a template and have the bot insert the template instead. That would give us more flexibility. For example the template might apply a category or preview message if the description is too long. It also avoids putting a #parserfunction: directly in articles. It's easier for people (especially new users) if everything is {{xxxxxx|value}} rather than randomly mixing in {{#xxxxxx:value}}.

Assuming others on this page are good with this option, I'd like post the proposal as an RFC. I think it will be an easy consensus and there are benefits to the RFC itself. It ensures we catch any other concerns, it effectively publicizes the plan, and it provides something to point to if anyone complains later. I also think it's helpful if we can experience more RFC's as positive tools and success stories between WMF&community. Alsee (talk) 18:19, 3 October 2017 (UTC)

Hi, FYI: We're having more internal conversations about these ideas with the product teams. It's a big group of people, and coming to consensus is hard. I'll post tomorrow with an update about where we are. Sorry to go dark for a minute. -- DannyH (WMF) (talk) 22:42, 4 October 2017 (UTC)

Hi everyone, another update: We've been talking a lot about this issue internally, and we need to have a meeting with the product teams, so we can come to consensus on what our approach should be. That meeting is scheduled for Wednesday. I know, that's six days from now, but there's a three-day weekend in the US, and this is the earliest when we could get everybody together. I'll have a substantive update for everybody after that meeting on Wednesday. Thanks for being patient with us while we talk about it. We're taking it seriously, and we don't want to short-change the discussions. -- DannyH (WMF) (talk) 00:33, 6 October 2017 (UTC)

Hi everyone, we were hoping to get some plans together today for addressing the moderation concerns around the Wikidata descriptions. But there are some current database issues related to listing Wikidata changes in watchlists and recent changes, which are being discussed on this Phabricator ticket. We need to see what happens there, before we can make plans around the descriptions. I'm sorry about that; we'll see what we can do. -- DannyH (WMF) (talk) 00:43, 12 October 2017 (UTC)

Thank you, DannyH (WMF) and the rest of the WMF team, for recognizing the seriousness of that situation. Risker (talk) 05:46, 12 October 2017 (UTC)

At best, we get back to the situation where Wikidata can be used without breaking watchlists and recent changes. At worst, Wikidata usage will be heavily restricted. How does any of this have an impact on a solution to get rid of the Wikidata descriptions completely on enwiki? It seems as if either (and most likely), it won't have any impact on the other problems, or it will help alleviate the server load. If the problem is that the same people work on both issues, then of course such a serious problem takes precedence for now: but if the people working on it are not the same, then I don't see how it is a reason to postpone a solution here even further. Fram (talk) 12:45, 12 October 2017 (UTC)

DannyH (WMF), When can we expect an update from WMF? I notice that my watchlist is timing out on average 3 times on an incomplete script before it renders completely, and there are large numbers of Wikidata edits listed which are in no obvious way related to Wikipedia and do not appear to display on desktop in any way.

Re-pinging DannyH (WMF), maybe you did not get a notification. · · · Peter (Southwood) ^(talk): 12:26, 19 October 2017 (UTC)

I have been doing some editing on Wikidata relating to my work on Wikipedia and Wikivoyage, and so far I have seen nothing to suggest that the average Wikidata item has any place being imported to Wikipedia. · · · Peter (Southwood) ^(talk): 06:07, 17 October 2017 (UTC)

Ah, I also got script errors on my (long- watchlist), but I thought it was my machine. No idea if it is Wikidata-related or not though, the Wikidata-on-watchlist problem is supposed to be under control (FWIW). Fram (talk) 07:25, 17 October 2017 (UTC)

My watchlist is 1,641 pages - moderately long? I get much the same result on desktop with Firefox and laptop with Chrome, takes a bit over 30 seconds to complete. · · · Peter (Southwood) ^(talk): 07:43, 17 October 2017 (UTC)

Mine is 10,029 pages, I do not get any errors (Firefox on laptop).--Ymblanter (talk) 07:46, 17 October 2017 (UTC)

Hi Peter, thanks for the re-ping. According to the Phabricator tickets, the watchlist issues on most wikis are fixed (phab:T171027), but the database admin is testing and cleaning up some smaller wikis (phab:T178290). I'm not sure what the decisions are going to be yet, but I'm hoping to learn more tomorrow. -- DannyH (WMF) (talk) 18:40, 19 October 2017 (UTC)

@DannyH (WMF): can we please get some timeline and indication of what actions are being taken? This starts to look suspiciously like a very long exercise of "everyone is busy, please wait a bit longer" but without the typical Vivaldi music to make the waiting seem less annoying. It's especially bizarre that in other discussions, people tell us that the watchlist / recent changes issue isn't that important, already solved, not affecting enwiki (which already has on average the most problems with the delay between the changes on Wikidata and them appearing here in recent changes); while here the same problems are the reason that an answer (which was already long in the making) isn't forthcoming now. Fram (talk) 13:47, 23 October 2017 (UTC)

Hi Fram and all, sorry about the delay. The Wikidata team is now working on the problem of making the watchlist entries more specific, and they're making progress on specifically tracking the description as a single item -- the ticket is phab:T106287, if anyone's interested in that. Now that that crisis is being handled, we're going to meet this week to talk about what we're going to do about the descriptions, and (more importantly) who's actually going to be responsible for doing it. I'll be able to post an update by Friday, when I'll have more information. Thanks for being patient over the last couple weeks. -- DannyH (WMF) (talk) 00:00, 25 October 2017 (UTC)

This may help speed up watchlist rendering, but will not solve the problem that the descriptions of Wikipedia articles are not curated on Wikipedia. · · · Peter (Southwood) ^(talk): 20:58, 27 October 2017 (UTC)

Magic word

Hi everyone, thanks for being patient while we figured out what to do with the Wikidata descriptions.

We think that using a magic word on Wikipedia articles to override the Wikidata description is a good approach here. The description on Wikidata would be used by default, but when the description isn't good enough, then editors on Wikipedia can override it. This gives editorial control to Wikipedia editors, while still using the work that people have added on Wikidata.

Using both the Wikidata default and the Wikpedia override makes it more likely that articles will have descriptions, especially new articles. When a new item is created on Wikidata, there's a strong call to action in the UI to write a description -- it's right at the top of the page. There isn't a direct call to action to encourage adding descriptions on new Wikipedia articles, so people may be less likely to add a description for every new page.

The magic word won't work if it's blanked, because the descriptions are useful and we don't want to lose them. But various people in this discussion have pointed out that some kinds of pages don't need descriptions -- list pages, disambiguation pages, category pages, the main page, and anywhere else where the description is describing the page, rather than a subject. "Wikimedia category page" and "Wikimedia list page" aren't helpful. As part of this project, we'll hide those from display.

Also, the Wikidata team is currently working on making it easier for Wikipedia editors to monitor the Wikidata descriptions, by separating out the English descriptions from other changes. (The tracking ticket is here if you like tracking tickets.) The work that we do on the magic word will be parallel to that work, they don't depend on each other.

So that's our current plan. We still need to talk to some developers on the team about the technical feasibility of this change, and how it slots into the existing product roadmap. Right now, I don't have a date for when that work is going to start, but I can post an update when I know more. What do you think? -- DannyH (WMF) (talk) 22:04, 27 October 2017 (UTC)

I suggest that the appropriate response to the continued refusal of WMF to stop injecting Wikidata text into Wikipedia by default (evident above) is to write a bot that makes sure every Wikipedia article has a non-blank magic word. It could be generated automatically from the first sentence as suggested in earlier discussions; getting accurate text for the bot-generated description is less important than getting something there, to override the use of Wikidata everywhere and bring this to the attention of human editors who can fix bad descriptions. —David Eppstein (talk) 22:47, 27 October 2017 (UTC)

I think this is a reversal from what you said last time.

I think the WMF is once again asserting Wikidata as the only option.

I think we have allowed this stonewalling to drag on far too long.

I think I'd like to modify David Eppstein's proposal above. If the WMF refuses to even discuss any option other than Wikidata, if the WMF escalates saying the magicword-override will even disregard blank descriptions, then we shouldn't have a bot apply non-blank descriptions. If the WMF wants us to edit our pages via Wikidata, fine, let's do it properly. We should apply our blank descriptions at Wikidata itself. If the Wikidata community gets pissed off and blocks us, I'm OK with that. All the better to help get Wikidata banned entirely from Wikipedia. Alsee (talk) 10:57, 28 October 2017 (UTC)

... or you could be constructive by adding useful descriptions to Wikidata? Thanks. Mike Peel (talk) 11:26, 28 October 2017 (UTC)

As I'm sure you're aware, consensus was against Wikidata descriptions. Perhaps to should ask the WMF to be more constructive.

P.S. to my original comment, I withdraw my tepid statement of support for "Wikidata-default with an if-present magicword override". I was trying to reach for a compromise the WMF would accept, but it's a dumb design. We shouldn't have to run a bot to enforce a magicword on every page in order to suppress a problem-default pushed out by the WMF. ^{Nevermind that part. I think I was mis-remembering. I considered the option, but I don't think I expressed tepid support for it.)} Alsee (talk) 11:38, 28 October 2017 (UTC)

Frankly, I think it is a crock of shit and it stinketh. You asked for my opinion, you got it. I may come back and explain why I have this opinion, but it is apparent that WMF is not going to bother to pay any attention because I have already explained and this crap just keeps coming back. · · · Peter (Southwood) ^(talk): 16:52, 30 October 2017 (UTC)

I think also that it is time that someone from WMF who is not part of this delaying action steps forward to deal with this. It is getting to the stage where it is becoming a governance issue. · · · Peter (Southwood) ^(talk): 16:59, 30 October 2017 (UTC)

DannyH, I don't know whether you are just the messenger or the actual force behind this proposal, and I really don't care any longer. This is just the same as what happend with Flow, Gather, ... and your role seems to be the same as with the Flow debacle. I don't know whether you don't care about what enwiki thinks and still believe that the WMF can get away with anything and everything, or that you simply are incompetent, but please let this be the last time that you work "with" us, as you are simply a total waste of our time and patience. Why do you and the WMF continue to insist that Wikidata is the default? NO! This is language-based content which should be curated here and only here. Using Wikidata may have seem like a good idea from the WMF ivory tower and from the idea that Wikidata is the future for everything, but in reality it isn't, and this long discussion should have made that abundantly clear by now. Every time you came with this same idea of using Wikidata as the efault, it has been shot down, so your final solution is to use Wikidata as the default? Get lost. All you are creating is more aversion against both the WMF and Wikidata, as if either of those was needed.

I'll address just one blatant fallacy in your supposed justification: "When a new item is created on Wikidata, there's a strong call to action in the UI to write a description". Tell that to the bots who create most of the new items on Wikidata. Apart from the "scientific article" ones which will for 99.99% never have an enwiki article anyway, we get all kinds of persons created (without a description) by "QuickStatementsBot"[4][5][6], "Emijrpbot"[7][8][9], and so on. Note that the persons created by Emijrpbot already have an enwiki article, so here the inaccuracy of your claims is blatantly obvious. "Real" editors sometimes do use the description, but when some of the most fanatic pro-Wikidata editors don't bother adding a description[10] then even this segment is not really corresponding with your hopes. Oh, and perhaps someone should block this bot which has created the same Wikidata item five times in a row (and a sixth time a while ago, and something like this which is a duplicate of this. Basically, Wikidata has highly insufficient editorial oversight, vandal fighting, consistency, policies, ... which is obvious any time you look at what happens there.

In general, enwiki shouldn't outsource English language content maintenance or production to other sites anyway; in particular, enwiki shouldn't outsource it to Wikidata. So why, after all this, is this still what you propose? Fram (talk) 09:53, 30 October 2017 (UTC)

Fram, I think this is a worthwhile compromise. This will be a tool that English Wikipedia editors can use to override Wikidata descriptions, in the places where WP editors think they need to change. I agree with you that there are issues on Wikidata that need to get solved as that wiki matures, but the things that you mentioned aren't about bad Wikidata descriptions appearing on Wikipedia.

There are several things that we learned from the discussion on this page that contributed to our thinking. People expressed strongly that English Wikipedia editors should have editorial control over text that appears on Wikipedia, and we agree, hence the magic word. People also pointed out places where using the description is unnecessary and looks silly (list pages, etc) -- we agree, and we're taking those out. If there are more examples that we've missed that can't be solved with the magic word, then I want to know about them. -- DannyH (WMF) (talk) 17:26, 30 October 2017 (UTC)

@DannyH (WMF): if that is your final proposal, I suggest you open an RFC about it on the village pump for proposals. I personally still think this makes no sense. To disable the entire feature, rebuilt it specifically for en.wp or to keep the status quo, seem the only viable choices to me. Otherwise we are needlessly complicating everything, muddling the messaging, the expectations and the development. This compromise is even more susceptible to the "mixing of wikidata and english wikipedia", the original concern of many regarding the status quo. I think it is doomed to fail for that reason. I understand the desire to compromise in order to find a solution that best suits all our users, but this route seems extremely risky to me. —TheDJ (talk • contribs) 18:04, 30 October 2017 (UTC)

Question for DannyH (WMF): suppose WPians get to work and come up with a pretty decent script that produces page descriptions for all 5.5M pages in article space (including some null descriptions, as you've pointed out), given input of the first sentence or two and other information on the page. Assume that the script isn't perfect, but also assume that we get a community process going that fixes the things that aren't perfect within a reasonable span of time. Also assume that our descriptions may be shorter on average than some descriptions from Wikidata ... because it's not a good use of editor time to fight over whether something is an X or Y or Z, if we can simply avoid the controversy by picking a more general description that includes X, Y and Z. Is the WMF likely to override the community again, on the theory that longer descriptions from Wikidata would be better? (I get that even asking this question may anger some Wikipedians. Please hold your fire; depending on the answer, I'll probably have a question for Fram.) ("Override" doesn't seem like a mischaracterization to me, given the fairly clear reactions to these descriptions at the March RfC. I'm aiming for accuracy here, not escalation. But if you'd prefer different wording, I'm listening.) - Dank (push to talk) 18:08, 30 October 2017 (UTC)

Dank, we're planning to create this magic word in order to give English Wikipedia editors more editorial control over the descriptions. I've been saying all along that we don't want to facilitate blanking the descriptions, because they're useful, and it would hurt people's learning experience for the sake of making a point about governance.

But we don't have control over whether people can run bots; that's up to the bot approval process. If you want to run a bot (as Dank and David Eppstein suggested) that would potentially make the descriptions worse rather than better, then I think that's a shame. But we're not judging the quality of the descriptions; that's up to the communities to decide. So far, the format and quality has been up to the folks who edit on Wikidata; the magic word would give more control to English Wikipedia editors. The one outcome that we're trying to avoid is having the descriptions blanked en masse, or rendered useless in some other way (like replacing them with asterisks or something). Beyond that, it's up to the community; that's why we think it's a reasonable compromise. Dank, does that answer your question? -- DannyH (WMF) (talk) 20:15, 30 October 2017 (UTC)

That's a relief. I used the word "script" because I think "bot" conjures an image of some process that runs incessantly, which isn't what I have in mind, but I don't care what we call it. Okay, I can imagine some problems that Fram and others might have with this suggestion, but I'm not sure, I'll have to ask (over at Fram's talk page, for the moment, but I'll be back). - Dank (push to talk) 20:25, 30 October 2017 (UTC)

Danny H, "The one outcome you are trying to avoid" is the one you make more and more likely by continued patronizing. Just give us the magic word, and decide on a timing. We'll file a bot request to populate the magic word in every article (even if it is with "blank" in articles that don' need a description. We're not going to provide you wqith an exhaustive list of "in this case, we don't need the description from Wikidata, but in that case, you can provide it" which is what you propose. Some examples of pages that don't need descriptions (or at least definitely don't need the Wikidata ones) are presented, but this is not a full list or an attempt to provide this. Give us the magic word, and we'll let you know when it is populated here so you can switch from Wikidata descriptions to Magic word descriptions. That's all that is needed. Feel free to present the magic word and the reasons we implement it at other wikis as well, perhaps someone else may find it interesting too.

But don't continue with the "This will be a tool that English Wikipedia editors can use to override Wikidata descriptions, in the places where WP editors think they need to change." and similar things which show that you still absolutely don't get the problem. The issue is not that we will look at 5 million pages and decide case-by-case which pages need a changed description, the issue is that we will override all 5 million descriptions with a local one, which we can locally monitor, locally protect, track in the page history and in our standard watchlist and recent changes. This may be blank, this may even be identical to the Wikidata description. But it will not be the exception, but the only rule.

"People also pointed out places where using the description is unnecessary and looks silly (list pages, etc) -- we agree, and we're taking those out. If there are more examples that we've missed that can't be solved with the magic word, then I want to know about them." Like I said above: NO. You don't decide which pages don't need descriptions based on a list we have to provide you. We decide which pages don't need descriptions. The best solution would be "no magic word = no description", the second best is "magic word left blank = no description", but the worst solution is as usual the one you are presenting. Feel free to monitor our use of the magic word and suggest improvements if there are areas where you feel we let the reader down: but don't overrule our content decisions from above. This is what caused this problem in the first place. Fram (talk) 08:24, 31 October 2017 (UTC)

Support. I completely agree with what Fram explains in the above post. In every detail that I have noticed. I will commit to personally provide at least 1000 short descriptions on Wikipedia to help get this abomination off our backs. · · · Peter (Southwood) ^(talk): 13:42, 31 October 2017 (UTC)

Yeah, that sounds great. Like I said, it's up to Wikipedia editors to decide how you want to use this. -- DannyH (WMF) (talk) 14:48, 31 October 2017 (UTC)

I have done about 100 so far. I have also been copying them to Wikidata where appropriate. What I have seen there does not make me any more enthusiastic about using Wikidata short descriptions on Wikipedia. · · · Peter (Southwood) ^(talk): 16:16, 1 November 2017 (UTC)

Peter (Southwood), I'm confused. Why have you added ~100 hidden comments? Alsee (talk) 16:51, 1 November 2017 (UTC)

If there are going to be short descriptions, they must be from Wikipedia, not from Wikidata.
There is currently no accepted and available way to use local short descriptions.
It will take some work and time to produce such local short descriptions.
I want to get a personal feel for how much effort this will take, and how many usable ones are on Wikidata.
Therefore I am producing short descriptions for a sample of Wikipedia articles which are on my watchlist, and adding them to the top of the articles as a comment. When there is a way to use them usefully, they can be transferred into the relevant template quickly and easily by cut and paste. I am adding them to Wikidata too because I also edit on Wikidata, and they are useful there too. Putting them in as comments means they don't mess up the appearance of the articles. Does that clarify sufficiently? · · · Peter (Southwood) ^(talk): 17:34, 1 November 2017 (UTC)

Some of the things I have already found out: Some short descriptions are trivially easy, others are rather difficult, and require a reasonable understanding of the subject. The sample I am using may not be representative, but (a) most of the articles in it did not have a Wikidata description; (b) some of the existing Wikidata descriptions were useless, some were not very good, some looked like they had been written by someone with a shaky command of English, and not much idea about the topic, and some were simply wrong. Most of the ones that were usable, were put there previously by me. However the sample is very small so far, and I would not presume to draw any strong conclusions from it. It does lead me to suggest a survey of the number of Wikipedia articles on Wikidata, and the number of them which actually have a description, no matter how bad it may be. This may be easy to someone who knows how to do it, but that person is not me.· · · Peter (Southwood) ^(talk): 18:04, 1 November 2017 (UTC)

Concerning the first question, you can safely approximate that all English Wikipedia articles are on Wikidata - new items are typically created by bots day after the articles get created here. For other languages (or sister projects), there might be a considerably longer delay.--Ymblanter (talk) 18:30, 1 November 2017 (UTC)

Ymblanter, Thanks for that explanation. It seems plausible enough so I will accept it as a good working hypothesis. Do you know of a reasonably practicable way to count the number of Wikipedia articles with descriptions on Wikidata, or failing that, to make a representative survey of what percentage have descriptions? · · · Peter (Southwood) ^(talk): 08:52, 2 November 2017 (UTC)

Peter (Southwood), I do not know, but I know that there is statistics on this, so apparently people can count the number of description in a certain language. I would just ask at d:Wikidata:Project Chat, I am sure someone knows.--Ymblanter (talk) 10:46, 2 November 2017 (UTC)

I have done that - still waiting for a response. I have found that questions on Wikidata are often not answered, so not expecting anything soon. · · · Peter (Southwood) ^(talk): 05:30, 5 November 2017 (UTC)

Pbsouthwood, I gave an answer to your question at Wikidata's Project chat two days ago [11]. Not sufficient? —MisterSynergy (talk) 07:35, 5 November 2017 (UTC)

MisterSynergy, My apologies, I did not notice your response, nor those of the others who replied. Somehow I was expecting some form of notification of a reply. The numbers are surprisingly high at about 70%. This does not fit my personal experience of less than 50%, but my sample was small, in the order of one to two hundred. · · · Peter (Southwood) ^(talk): 11:39, 5 November 2017 (UTC)

According to MisterSynergy,

7.415.123 items with enwiki sitelink
5.176.179 items with enwiki sitelink and English description (i.e. ~69.8% of all items with enwiki sitelink).

This is a fairly high percentage. However, I think the articles include nearly 2 million non-article enwiki pages. I dont know how the no-description items are distributed. Best case would be all descriptions are for mainspace articles, worst case would be for all non-mainspace articles to have descriptions. There is also no obvious way to estimate percentage of good/usable descriptions, but it will not be 100%. Cheers, · · · Peter (Southwood) ^(talk): 16:09, 5 November 2017 (UTC)

Update: MisterSynergy checked further and found:

5.486.860 items with enwiki sitelink to ns0 (excluding the ~86.5k enwiki redirects in ns0); this means that 99.7% of enwiki articles are connected to Wikidata
3.309.337 items with both enwiki sitelinks in ns0 and English description

So the ratio for the article namespace is 60.3%.

This is still fairly high and suggests that Wikidata may be a useful source of first approximation short descriptions.

However, anyone copying them over to Wikipedia must at the least personally check to ensure they are not wrong, and should also check that they are actually better than nothing. It would be best if they were to be checked for being actually useful. Any arbitrary mass transfer without checking should be considered abusive and equivalent to spamming. Any short description copied to Wikipedia from Wikidata, should be tagged with the level of compliance checking applied. Wikidata short descriptions should never be copied over existing short descriptions generated on Wikipedia by Wikipedians. This pretty much removes the option of a mass bot transfer. A semi-automated transfer could be allowable under accepted conditions. This might speed up the accumulation of short descriptions considerably.

A Wikidata description should never be displayed on mobile (or anywhere else) if a local short description from Wikipedia exists. Where Wikidata content is displayed on the same page as Wikipedia content it should be clearly and unambiguously be labelled as such. (Any Wikidata content displayed by Wikipedia as part of a Wikipedia page, visible on all platforms to all users, inserted by Wikipedians and editable through all Wikipedia editing software is considered part of Wikipedia.)

A mass addition of a "Magic word"/template to display Wikidata descriptions by default on mobile could also be considered abusive. An RFC should be run to gauge opinion of the wider community. WMF should not attempt to force any option on Wikipedia. Other opinions may differ. This is my own analysis of the options. · · · Peter (Southwood) ^(talk): 04:58, 6 November 2017 (UTC)

I think we can trim the task by excluding descriptions for Lists, pages with (disambiguation), and maybe other cases that don't need descriptions. However I'd like to reiterate (especially for DannyH (WMF)) that I will run an RFC-challenge against any result that includes defaulting to wikidata. If we delete the keyword from an article that doesn't need one, that removes the description. If a new page is created and it doesn't have a keyword yet, it doesn't attempt to call wikidata. Alsee (talk) 09:10, 6 November 2017 (UTC)

Alsee, That may be a valid option in many cases. We will have to find out by doing it. If a description is not needed, leave it out. Ideally put in a null indicator so that other editors can see that someone has checked and found a description to be unnecessary. This is purely to avoid duplicating the work, possibly several times. When in doubt, follow Bold-Revert-Discuss on talk page. Any mass addition of anything by WMF needs to go through an RFC first. Anything that Wikipedians want to automate must go through bot approval first. Also agree about the default options and RFC as you specify above. · · · Peter (Southwood) ^(talk): 09:38, 6 November 2017 (UTC)

@Pbsouthwood: You speak of 99.7%, which is awfully close to 100% .. can I please have some examples of articles that do not link to WikiData. I would also like to note that we have {{Wikidata property}}, which is transcluded in content namespace and which, obviously, results in a link. --Dirk Beetstra ^{T C} 10:14, 6 November 2017 (UTC)

Beetstra, I didn't do the analysis myself, it was done by MisterSynergy, and originally reported at d:Wikidata:Project chat#number of English Wikipedia items on Wikidata with and without description in English, so I can't help you there. I did mention my source, but maybe did not make it sufficiently clear. The missing articles are a small percentage, but quite a large number of articles. I have no opinion on whether it is in any way important in other contexts, but I don't think it matters here. Cheers, · · · Peter (Southwood) ^(talk): 10:41, 6 November 2017 (UTC)

Clarification: 99.7% describes the fraction of articles which are entered as sitelinks in a Wikidata item, compared to the total number of enwiki articles (in ns0, excluding redirects). You can find unconnected pages via Special:UnconnectedPages (namespace filter is available). The 99.7% connected pages pull interwiki links from Wikidata by default, and their Wikidata description (if existing) is used in Wikipedia in some contexts. I would like to emphasize that the number explicitly does not tell anything about statement or label use from Wikidata via templates or modules. —MisterSynergy (talk) 10:34, 6 November 2017 (UTC)

So roughly, that 99.7% is practically all articles that have interwiki (the few missing within the 99.7 will be articles without interwiki but having one piece of 'content' pulled from WikiData). The 0.3% are en.wikipedia 'unique' articles (so they do not have, or may not have an interwiki yet). So we do not know how many articles pull parameters (data excluding the interwikis) from WikiData and it is therefore difficult to assess how much damage we will do by removing a property link in a content template, except if we would have something alike 'Category:PropertyX pulled from WikiData'? --Dirk Beetstra ^{T C} 11:10, 6 November 2017 (UTC)

No, this is not correct. It is actually a much higher percentage of articles which have no interwiki at all, I would not be surprised if 50% and more of English Wikipedia articles have no counterparts at other projects. I believe 0.3% are new articles for which no Wikidata items have yet been created as well as items vandalized by removing an English Wikipedia sitelink (presumably not a big number).--Ymblanter (talk) 16:46, 6 November 2017 (UTC)

@Ymblanter: I think I did not express that correctly, the article gets linked even if the only interwiki on WD is the en.wikipedia link. I understand that 50% of the articles on en.wikipedia do not have any interwiki counterpart, but for those 50% I guess that 95% do have their en.wiki 'interwiki' connected.

If I understand correctly, as soon as the en.wikipedia 'interwiki' is set on WD, the items are connected, as well as if it pulls any other data from an article (say, only a birthday pulled from WD, even without the en.wikipedia 'interwiki' being connected). Getting above numbers ignoring any 'interwikis' (i.e., how many articles pull content from WD) is probably going to be difficult. --Dirk Beetstra ^{T C} 05:50, 8 November 2017 (UTC)

Alsee, my hidden comments are being converted to currently hidden templates {{short description}}, to make them easier to handle later, by editing the template. Display of the short description on Wikipedia will be decided later by the Wikipedia community. I have preferences, but this will be an internal decision by community process. What use Wikidata and WMF choose to make of them is their choice, like it is with any other Wikipedia content. If WMF make a magic word that suits our purposes, the template can be edited to use the magic word, by Wikipedians. I chose the template title as self explanatory and reasonably short, and because I thought it was time to do something to actively start fixing this mess. If we wait for WMF we may wait forever. Cheers, · · · Peter (Southwood) ^(talk): 09:17, 2 November 2017 (UTC)

Peter (Southwood) that's a good start. The documentation should probably be a bit more clear that it's an experimental template that doesn't really do anything yet, and mention that the software functionality may be built. I think someone would be quite confused if they tried to investigate what the template was and why it's in an article. Alsee (talk) 22:22, 3 November 2017 (UTC)

Good point, I will look into this. · · · Peter (Southwood) ^(talk): 20:35, 4 November 2017 (UTC)

I purged the cache for the description. much of what you suggested is now visible, and I will add a notice about the experimental status. · · · Peter (Southwood) ^(talk): 05:16, 5 November 2017 (UTC)

Notice of experimental status added. · · · Peter (Southwood) ^(talk): 05:30, 5 November 2017 (UTC)

The biggest problem with the proposal to add "descriptions" at the top of biographies is something we already have a lot of experience with: over-labeling. It's hard enough trying to come up with accurate, non-offensive labels for things like nationality and vocation, but the problems go deeper than that. I recently worked on a blurb for a woman who was an Olympic swimmer for Australia in the 80s. To label her only as a swimmer and nothing else, as if she hasn't done anything useful since the 80s, could easily come across as offensive and demeaning. On Wikipedia, the general approach to problems like these is to minimize the use of labels and to focus on what someone has done and how others have reacted to them.

The proposed "descriptions" can't avoid being 100% labeling and 0% context. (An additional problem is that there are in fact lots of people who like to slap labels on people ... politicians, tabloids, and people acting badly in general ... and we don't want our writing to resemble their writing.) Someone might say "There's no problem here, short descriptions are only meant to be read as part of the text, never by themselves" ... but that statement would be either dishonest (the opposite has been proposed in previous conversations), or silly, or dangerous, at least in the context of biographical articles. It's silly if the short description merely repeats the most prominent labels from the first sentence, leading to: "[Name]. A Serbian actor. [Name] is a Serbian actor ...". Wikipedians would never support that. It's dangerous if the labels are different, because then we're front-loading with potentially divisive and inaccurate labels. Even if all the new labels eventually wind up being 100% accurate, by some miracle, how much editor time would be wasted arguing over the labels for a million biographical articles? I'm not going to be offended no matter what the community decides about whether or not to allow short descriptions at the top of bios, but I'd really like to see an RfC where we find out what the community intends to do, and I'd like to see how the WMF reacts to the result, so we can get some of these conflicts behind us and move on to more productive things. - Dank (push to talk) 19:57, 31 October 2017 (UTC)

Good points but the necessity of the Wikidata description becomes obvious when you try reading Wikipedia from a phone. On a phone, it's easy to see a list of titles for things that might be of interest (from a search, for example). However, the titles are usually insufficient to identify which page you want to look at and the description merely identifies which person or topic the title refers to (do you want Judy Smith [swimmer] or Judy Smith [politician]?). On a computer, the description doesn't matter so much because you can easily open a few likely topics in separate tabs and quickly decide which ones to look at. On a phone, it's much harder to navigate like that—opening a page, waiting for it to load, then deciding it's not the one and returning to the list is not easy. Wikipedia is great, but it's not useful if people can't access it. Johnuniq (talk) 21:58, 31 October 2017 (UTC)

The mobile issues are ultimately caused by mediawiki being a legacy system not remotely suitable for modern smart device use. It needs a complete re-write. Everything so far to make it work on mobiles is essentially a dirty hack. Which is why when they try 'improvements' like this it goes belly up. The wikidata description isn't necessary, its just a patch for a problem that is only going to get worse. Only in death does duty end (talk) 11:40, 1 November 2017 (UTC)

Dank, when the short descriptions are hosted on Wikipedia, we will be able to fix them as necessary or desirable, like any other article text. It will be marginally complicated by probably being contained in a template, which could make them a little harder to edit for inexperienced editors, but this gives greater freedom for display options. · · · Peter (Southwood) ^(talk): 09:00, 2 November 2017 (UTC)

@DannyH (WMF): any update on this? In response to my "The best solution would be "no magic word = no description", the second best is "magic word left blank = no description", but the worst solution is as usual the one you are presenting. Feel free to monitor our use of the magic word and suggest improvements if there are areas where you feel we let the reader down: but don't overrule our content decisions from above. This is what caused this problem in the first place. " you replied "Yeag, that sounds great". That was (I think) the last we heard about this. Can you give us any indication of the actual magic word, when it will be available, and how long after this you plan on switching the current Wikidata-use to the Magic word use? Fram (talk) 09:18, 6 November 2017 (UTC)

Update on experimental addition of short description templates

I have now done about 600 short descriptions of articles on my watchlist.

Tentative conclusions

Many Wikidata descriptions don't exist.
Of those that do exist, some are quite good, but significant number, possibly in the order of half, are not appropriate for use to describe/disambiguate a Wikipedia article.
Some classes of Wikipedia article could be usefully described by a standardised description.
Lists usually don't usually need a short description - the title is usually sufficient, but a small number would probably benefit by having one.
Writing a good short description ranges from trivially easy to quite difficult, and generally requires competence. Writing them also concentrates the mind on the actual topic of the article, and may well lead to a significant improvement of lead sections in the long run. One also notices other problems in passing. A good short description may therefore lead to a better lead.
Short descriptions will be most efficiently generated by WikiProject members, where the editor is at least reasonably familiar with the subject matter.
Short descriptions do appear to be potentially useful for the purposes for which they are used by WMF, but the current Wikidata descriptions are often not fit for this purpose as they are intended for another entirely legitimate purpose, and forcing them to be changed for this purpose is not appropriate. Using them this way is opportunistic but not optimal.
I think that locally hosted short descriptions are not only feasible but desirable. It will be a lot of work to generate them and may take years to complete the backlog, but in the long run I think it will be a net gain to the readers, and will have the side effect of getting some improvements to a moderate number of articles which really need some work. Therefore they should be an improvement to the encyclopaedia. Cheers, · · · Peter (Southwood) ^(talk): 17:11, 17 November 2017 (UTC)

November Magic Word proposal from WMF

Hi all, we had a meeting with the Readers product team to talk about technical feasibility, and we'll be able to build the magic word in the way that I described above. The magic word will override the description per page, and if there isn't a local description, then Wikidata is the fallback default. In addition to this, the Wikidata team is currently working on making granular changes easier to see in recent changes and watchlists, so that it'll be easier for people on English Wikipedia to keep an eye on descriptions that are pulled from Wikidata.

We can remove descriptions completely on types of pages where the description is inherently worthless or repetitive. The examples that I know right now are list pages, disambiguation pages, category pages and the main page. "Disambiguation page" may be useful in search and in the VE link modal, but they're not useful at the top of the article page, and descriptions for list/category pages are worthless in all circumstances. It's possible that there are other examples where descriptions are inappropriate or meaningless, and it would be really helpful for any/everybody on this page to identify more examples, so that we can exclude them as well.

Fram, I know that you want Wikipedia editors to decide all of those things without any WMF product involvement. I think that this is something that we can productively work together on. (Not necessarily you and me, specifically, but the larger "we" of the community and the product team.) WMF doesn't and isn't going to control the content or format of the descriptions, or how the Wikipedia community makes those decisions. But there's an existing library of good-to-acceptable-quality descriptions currently on Wikidata that's providing value for readers and editors, and we want to make sure those descriptions don't get blanked. I'm happy to keep talking about this, especially if there are other examples of page types where the description should be blanked, but I want to be clear that avoiding mass blanking is a big deal for us.

For the timeline: the product team is planning to start making the changes in January, with estimated finish by the end of February. That may seem like a while, but there are several pieces to this -- creating the magic word, having the display check for the magic word when the page renders, and blanking the list/category pages -- and it needs to fit in with work that the team has already planned. We can provide updates along the way, on Phabricator and here (or wherever it's appropriate).

So that's where we're at. What do you think? -- DannyH (WMF) (talk) 01:19, 8 November 2017 (UTC)

For a start I think the specification is way too vague. Please be exact and specific in the placement, format and action of the proposed magic word, so that if we agree to something, we know what it is and can hold WMF to deliver on what they specify, not on something they later decide is what they prefer and can be weaseled out of the contents of this page. · · · Peter (Southwood) ^(talk): 05:25, 8 November 2017 (UTC)

It's too early to say exactly what the implementation will be; the product team will figure that out when they're working on it. As a similar example, the related pages override looks like this: {{#related: Mbula language}}. It'll be something like that. The important thing is the functionality -- that Wikipedia editors will be able to specify a short description, and that will be used instead of the description on Wikidata. -- DannyH (WMF) (talk) 02:27, 9 November 2017 (UTC)

Does estimated finish by the end of February mean that the code is expected to be functional, doing all that is specified, running on enWikipedia and debugged by the end of February? · · · Peter (Southwood) ^(talk): 06:02, 8 November 2017 (UTC)

Yes, estimated finish by the end of February means that the feature should be live and working by then. We can provide updates; if anything unexpected comes up that would make that estimate slip, you'll know about it before then. -- DannyH (WMF) (talk) 02:27, 9 November 2017 (UTC)

What you are proposing is a contract between WMF and the Wikipedia community of editors. Once those of us who contribute to the discussion on this page are basically satisfied with any proposal it must go to RfC for the wider Wikipedia community, as we cannot make a contract on their behalf. Or you can bypass us and go directly to RfC. Either way, a concise and unambiguous specification will expedite matters. · · · Peter (Southwood) ^(talk): 06:02, 8 November 2017 (UTC)

I'm happy to keep talking with folks about this. If people think that conversation should happen in another place or in another format, I'm fine with wherever you think it's best. -- DannyH (WMF) (talk) 02:27, 9 November 2017 (UTC)

If WMF do not provide a suitable specification, then we will try to do that. We may decide to do it in parallel as a counter-proposal anyway. I am not sure which way will be quicker and easier. It is unlikely that it will be acceptable to all parties on first draft either way, so the sooner we start, the sooner the RfC can be concluded. · · · Peter (Southwood) ^(talk): 06:11, 8 November 2017 (UTC)

I'm sorry, I'm not sure what you mean by a counter-proposal here. We're talking about a technical change done by a product team. The team needs to come up with a specification when they begin the work. -- DannyH (WMF) (talk) 02:27, 9 November 2017 (UTC)

Many Wikipedians do not follow Phabricator. Updates on Wikipedia will be highly desirable, both to actually inform us of progress, and to relieve us of the necessity for someone to report second hand information to the Wikipedia community, with all the pitfalls of miscommunication that may entail. · · · Peter (Southwood) ^(talk): 06:20, 8 November 2017 (UTC)

Yes, that's why I said that we would provide updates both on Phabricator and here on this wiki page (or on another wiki page, if there's a more appropriate place). -- DannyH (WMF) (talk) 02:27, 9 November 2017 (UTC)

The size of the existing library of good-to-acceptable-quality descriptions currently on Wikidata is yet to be established. It would appear from recent surveys that there are descriptions available for approximately 60% of Wikipedia articles. Of these, an unknown number are good, another unknown number are acceptable and another unknown number are not-acceptable/useless/appalling/add-your-own-descriptor-here. Opinions vary considerably on the proportions. My personal experience on a small sample is that good/useful is less than half of those that exist. Based on this I reject any assertion that the majority of descriptions are good to acceptable that is not accompanied by verifiable research. However, even 20% useful is a huge number of useful descriptions, and could be used as long as the crap is filtered out. That is the difficult part. Compared to identifying the good from the bad, the rest of the exercise should be almost trivially easy. I have no Idea how you propose to filter out the garbage, but look forward with some interest to finding out. My somewhat cynical guess is that you will discuss this, come to the conclusion that it can't be done, or is not worth the effort, or run out of time, and will simply foist the whole bundle onto Wikipedia, which will be followed by a bot run overwriting the lot as a precautionary measure, leading to more loss of credibility and bad feelings. Convince us otherwise. · · · Peter (Southwood) ^(talk): 06:44, 8 November 2017 (UTC)

I'm sorry, I might be misunderstanding this as well. The idea here is that we'll create a magic word that English Wikipedia editors can use to override the Wikidata description. It's up to the English Wikipedia community to decide how to use that magic word. As you said, there's a very large number of existing descriptions. We can't quantify the number of "good" vs "appalling" descriptions, because that's a judgment made by human beings. I'm sure that you and I (or any two people) would look at any given sample of 100 descriptions, and come up with a different count of what we would consider good or bad. Like any wiki content, the best way to improve the existing descriptions is for people to look at them, and either keep them as they are, or write a better one. You'll probably want to talk about a standard format for specific types of pages -- for example, historical battles, or Michael Jackson songs. Once people have agreed on a format for a particular type, then maybe somebody can write a bot to quickly populate that category. Five million+ articles is a lot of short descriptions to write, and it'll probably be a while before they're all finished. That's why we want to use the existing Wikidata descriptions as a fallback -- so there's something there, while people are discussing the correct formats for pages about rivers and psychological disorders and types of glass. -- DannyH (WMF) (talk) 02:27, 9 November 2017 (UTC)

@DannyH (WMF):

OK, Buck passed. We will work on a proposal. Please define "Magic word" since you will be creating it. If we are to use it we need to know what it is.

How would this differ from extracting the short description from the already existing experimental template {{short description}}?· · · Peter (Southwood) ^(talk): 07:32, 10 November 2017 (UTC)

Everything that Peter said.. —TheDJ (talk • contribs) 10:10, 8 November 2017 (UTC)

I would second the need for another RfC here. From my perspective, developing a magic word for this usage is completely pointless and a waste of developer and editor time, as it's trying to include structure information in a plain-text format. It's much better to just use Wikidata descriptions, and invest the developer time there instead, e.g. by displaying the descriptions in the desktop Wikipedia article view (so that editors here can see them easier), making the descriptions editable from Wikipedia (so that people that don't want to click over to Wikidata can edit them from here), adding support for references for descriptions (if needed), and so on - and asking editors here to improve the descriptions there. Or develop ways of automatically deriving the descriptions from existing content, whether that's Wikidata values or the first sentence or so of the Wikipedia article. Of course, that's the complete opposite of what others are pushing for here, and there are only a few voices here so you're not going to get a representative opinion here, hence the need for a more open RfC on the different possibilities that then samples all the different viewpoints people have (and, of course, this shouldn't be monolingual/enwp specific...). Thanks. Mike Peel (talk) 22:34, 9 November 2017 (UTC)

Completely agree with Mike Peel. Wikidata descriptions should be visible and editable from Wikipedia. The current proposal is a waste of time and energy. --Ita140188 (talk) 04:59, 10 November 2017 (UTC)

If the descriptions are visible and editable from Wikipedia, are they still Wikidata descriptions? Which set of policies and conventions applies - Wikipedia's or Wikidata's? They are not currently compatible, let alone identical. Who will win the edit wars? Who will be able to protect the data when there is persistent vandalism? Will Wikipedia admins get this right on Wikidata? How will protection of the short description in one language be separated from protection of short descriptions in other languages? Will that require major coding fixes? Does the Wikidata community want this? Do they understand what they will be letting themselves in for? Does WMF need the kind of strife this is likely to cause? This option would require an RfC on both Wikidata and Wikipedia, and preferably on all other potentially affected projects, which constitutes roughly all the Wikipedias. That looks like a fairly big project, unlikely to be concluded within a month or two, meanwhile what is the interim plan? Status quo forever? If this was to be the plan it would be necessary to first shut down the use of Wikidata descriptions until agreed by consensus otherwise it will go on forever as WMF will have nothing to gain by getting things fixed. It does not look like a cheap and easy fix. Quick and dirty maybe. · · · Peter (Southwood) ^(talk): 07:16, 10 November 2017 (UTC)

@Pbsouthwood: I agree there are many problems and open questions, that's why I think WMF should focus on solving these issues instead of introducing useless features. There are already examples of inter-project collaboration, for example with Commons. I don't see why a solution to all these points should not be found. In the case of the descriptions, you are right, there is not much to gain, but for structured data Wikidata has huge potential (especially for lists and graphs). --Ita140188 (talk) 08:42, 10 November 2017 (UTC)

Ita140188, I agree that Wikidata has the potential to be useful in many ways, and that Wikipedia should be free to use data from Wikidata in whatever ways suit the building of the encyclopaedia. Also Wikidata should be free to use what suits their needs from Wikipedia. Where I have a problem is with WMF arbitrarily using Wikidata in a way that looks like it comes from Wikipedia, and where Wikipedians have no direct control over the data from within Wikipedia. Using content from Commons is not generally a problem because the link to the material in Commons is inserted into the Wikipedia article by a Wikipedian, and if anything goes wrong with it on Commons, a Wikipedian can remove the link from Wikipedia using any of the usual editing tools. Wikidata content must be used in a similar way. Wikipedians must put the link into Wikipedia and must also be able to remove it or override it using the usual Wikipedia editing tools. Either the data/content must be on Wikipedia, or the link must be accessible and editable on Wikipedia. No special tools are needed for this. If the content is linked into Wikipedia by wikicode, It should be quite easy to display as and when WMF need to use it.

I don't think anyone is keen on WMF introducing useless features, and I don't know which useless features you refer to. I would say we are asking them to remove harmful features, not introduce useless ones. · · · Peter (Southwood) ^(talk): 09:35, 10 November 2017 (UTC)

@Pbsouthwood: I was referring to the original topic of the conversation, the "magic word" thing. My opinion is that there should be a distinction on Wikidata between language-specific elements, like descriptions, and universal elements, like structured data about items. The English description of Wikidata can be then considered responsibility of the English Wikipedia editors. This would allow to also simplify the recent edits checking. For example, language-specific edits on Wikidata in other languages (such as links to Wikipedia pages in other languages or description in other languages) should not appear in the watchlist of editors of the English Wikipedia (when Wikidata edits in the watchlist is enabled). --Ita140188 (talk) 10:13, 10 November 2017 (UTC)

Ita140188, Since I still don't know what a "magic word" is or what it might do, or how it might work, I look at it as a black box with unknown characteristics that might or might not be useful in some way, and might be easy to implement or not. I am still waiting for a useful response from DannyH (WMF), so for all I know I might agree with you, or not... At present, with the information available, I remain convinced that short descriptions should reside on Wikipedia, where they can be effectively maintained without extra software, by Wikipedians, without having to encroach on the turf of Wikidatans, where some Wikipedians will undoubtedly make themselves unwelcome, while doing work entirely within the scope of Wikipedia.

Your suggestion of a distinction between language based and universal elements is not unreasonable, and could work in a more perfect world, but I still predict turf wars because of conflicting policies, and vandals using Wikidata to mess with Wikipedia, with predictable reactions. · · · Peter (Southwood) ^(talk): 10:41, 10 November 2017 (UTC)

Help:Magic words —MisterSynergy (talk) 10:45, 10 November 2017 (UTC)

Indeed; it will be similar to {{DEFAULTSORT:sortkey}}, something like {{SHORTDESC:description}}, but we will need to know the actual name of the magic word, the max length of the description, and any restrictions (e.g. the use of "#" is not allowed in the decsripti:on). Especially these restrictions may turn out to be problematic. Fram (talk) 11:17, 10 November 2017 (UTC)

Thanks, MisterSynergy, it appears they are much like templates that can't be edited by most editors. In what way would this be better than a regular template that could be modified as useful by template editors? Would it be more efficient code? Can it do things that are needed that an ordinary template cannot do? Standard wiki template syntax would also be more familiar to most editors. And while I am bugging you with questions, how does one link to a Wikidata description from Wikipedia? I guess the syntax is explained somewhere, but so far I have not found it. · · · Peter (Southwood) ^(talk): 13:09, 10 November 2017 (UTC)

I have no idea how exactly WMF would solve this request best. However, there has to be some keyword (“magic word”) such as __LOCAL_DESC__ or {{SHORTDESC:…}} somewhere in the page in order to trigger the intended behavior (e.g. no descriptions should be shown, use the local definition which is given at a defined location, take Wikidata’s en-description, …). Depending on the actual implementation, this could very likely be hidden into templates to some extent, but in fact your request will create substantial workload and permanent need for oversight by a group of maintaining editors, which have to make sure that local descriptions fulfill all technical requirements in order to work as desired.

If you only used regular templates and some complex “policies” as you have proposed below, Mediawiki would not be able to process your local descriptions. A description given in a template (and all information stored in template parameters) is indeed structured information within the generally unstructured wikitext, but Mediawiki’s template technology was never designed to be used in the way you propose here, and thus it cannot solve your problem alone. A “magic word” is thus necessary. —MisterSynergy (talk) 13:34, 10 November 2017 (UTC)

Thanks for your explanation MisterSynergy. I will assume that you are right about the necessity for a magic word, as I do not know the technology well enough to have a useful opinion. The alternative to constant oversight is constant vandalism, which we know from experience. Oversight within Wikipedia reduces the workload on the overseers by spreading it more evenly over all the people with watchlists, who generally care enough to fix things, rather than leaving it to Wikidata editors, who my not even know when damage is done, because they may not know whether a change is an improvement or not.· · · Peter (Southwood) ^(talk): 15:50, 10 November 2017 (UTC)

Fram, what would limit the description length? What would happen if the length exceeded the limit? Can one substitute forbidden characters in the usual ways? (sorry about the barrage of questions, I don't know where to look up the answers, and also the answers may be useful to others to understand the problems). · · · Peter (Southwood) ^(talk): 13:09, 10 November 2017 (UTC)

Description length was just a passing thought, no idea what would happen (I suppose, if such a limit would exist, it would just not display anything beyond that). In general, the answers to these questions should come from the WMF, from the people who are developing this magic word. Fram (talk) 13:30, 10 November 2017 (UTC)

I agree, but they don't seem to be very forthcoming.· · · Peter (Southwood) ^(talk): 15:50, 10 November 2017 (UTC)

Mike Peel, Could you explain how the short descriptions are structured data as opposed to text? There may be something I am missing, as they look like text to me. · · · Peter (Southwood) ^(talk): 08:02, 10 November 2017 (UTC)

@Pbsouthwood: You're saying "description=This", not just "This" in the article text. That's some sort of structure. Descriptions are included in introductions to structured data, e.g. see [12]. Thanks. Mike Peel (talk) 14:35, 10 November 2017 (UTC)

Mike Peel, Thanks for your reply. By that definition, a lot of information in a Wikipedia article is structured. We have several standardised section headings, and a lead section which is an implied section, we have templated images, tables, lists, references etc that are also structured to some extent. The reason we are considering saying "description=this" is for the benefit of the WMF needs as described as reasons for the use of Wikidata descriptions, so that inappropriate descriptions can be more conveniently avoided.· · · Peter (Southwood) ^(talk): 15:50, 10 November 2017 (UTC)

Proposal from Wikipedia

(I am just starting this because someone has to. I hope it will be a work of co-operation by anyone who has something constructive to contribute. · · · Peter (Southwood) ^(talk): 11:25, 10 November 2017 (UTC))

English Wikipedia will have an RfC on this before it can be considered in any way an official proposal.
All content drawn from Wikidata to Wikipedia will be controlled at Wikipedia, using the currently existing editing tools.
A template will be added at or near the top of each Wikipedia mainspace article, and where necessary to articles in other namespaces.
1. This template will have a parameter which contains a short description of the article.
2. How the short description is to be displayed on Wikipedia pages will be decided by the Wikipedia community. WMF may use it as they wish. Wikidata may use it as they wish. External search engines may use it as they wish. (subject to the usual conditions for re-use of Wikipedia content)
3. The template may contain one of three classes of content:
  1. the text string none (or similar, to be decided) will indicate that no display of a short description is considered useful or desirable. This decision will be up to the editors of the specific article. WMF should not impose a description from any other source to override this specification. If anyone thinks they know a good short description that is preferable to none, they can propose or add it as a normal Wikipedia edit.
  2. a text string which constitutes a plain language, unformatted, short description of the intended content of the article. No guarantee that the article actually contains everything implied by the description. This will be the description we expect WMF to use. If they don't like it they are free to discuss on the article talk page or edit like any other user.
  3. the text string Wikidata, (or magic word, or similar, to be decided), which authorises the use of the Wikidata description in English. This Wikidata description should be displayed on Wikipedia in edit mode by default, so that editors can see it and judge whether it is acceptable, and if so decided by the community, or by user option, it may be displayed in read mode.
  4. If the parameter is empty, no display by WMF or in read mode. Normal visibility of the template in edit mode.
  5. If none of the above, an error message should be displayed. (nice to have, but not critical)
4. There is an experimental template for this purpose {{short description}} which is suggested as the name is appropriate. Other suggestions will be considered.
5. Wikipedians may choose to add other parameters as may be useful for maintenance purposes, such as categories, dates etc, following normal Wikipedia procedures.
It may be desirable to license the short descriptions under CC0. This may require some fancy coding somewhere to warn editors as some may take exception.

Discuss

This needs a little more clarification of what you mean by Wikidata may use it as they wish. Unlike suggestions from David Eppstein and Fram, Wikidata cannot import descriptions from en.wiki. Any description written on Wikidata has been explicitly released to Wikidata under CC0 when the edit was made. The data Wikidata imported from en.wiki's infoboxes is factual data. It qualifies for CC0 since factual data is not protected by copyright. However a short description written on en.wiki may or may not be factual data, but may instead be a creative expression. StarryGrandma (talk) 23:15, 12 November 2017 (UTC)
- I suspect that many of the existing Wikidata descriptions were, in fact, cribbed from En, by people other than the original author of that text. If that's true, wouldn't that mean that on top of all its other issues Wikidata is now a mass copyright violator? If so, it shows why blurring the line between data and text on Wikidata was a mistake. —David Eppstein (talk) 23:20, 12 November 2017 (UTC)
  - In the same way that Wikipedians (don't) crib content from other publications when writing a Wikipedia article? Mike Peel (talk) 23:31, 12 November 2017 (UTC)
    - Probably, but when we are notified of, or discover, copyright violations on Wikipedia, we tend to revdel them. Does that also happen on Wikidata? do they even investigate? As they are supposedly hosting data which is not copyrightable, it may be that they have not even considered the possibilty. · · · Peter (Southwood) ^(talk): 09:06, 13 November 2017 (UTC)
      - d:Wikidata:Oversight exists. You're right that it's not a common situation, though, so it's not thoroughly thought through. It is something that's discussed when bots are being proposed to do import tasks, though. But do you have any examples of where this has actually happened, or is this all WP:CRYSTALBALL/WP:BEANS? Thanks. Mike Peel (talk) 11:13, 13 November 2017 (UTC)
        Mike Peel, your question appears to be addressed to me based on position and indent, but I made no assertion that this alleged cribbing from Wikipedia actually happens. I would not be surprised if it did, but did not make the claim. I do know that I have used the same words that Wikipedia uses in the articles for short descriptions, sometimes even in similar order, but there is a limit to how many ways a simple fact can be usefully expressed in a small number of words, and I don't think I have overstepped that mark. In some cases the wording is identical, usually for articles where I produced the original text anyway. I do know that the copyright status of my Wikidata descriptions has never been challenged. · · · Peter (Southwood) ^(talk): 20:35, 13 November 2017 (UTC)
        Sorry, I think my comment ended up half being addressed to you, half to David above. I don't think I'd had enough caffeine before poisting it. ;-) Thanks. Mike Peel (talk) 20:49, 13 November 2017 (UTC)
        No worries, Mike Peel, an example of text almost identical except for idiosyncratic idiom can be seen in RexxS' second example below - for Caravan Palace, but I have not checked which one was earlier, or if the same person provided both. I don't think that particular short description is sufficiently creative to be copyrightable, but IANAL etc... Cheers, · · · Peter (Southwood) ^(talk): 08:46, 14 November 2017 (UTC)
  - I don't see any evidence of mass imports of text from en.wiki. Wikidata's description guidelines ask for a fact or a short list of facts. The purpose of the description is to disambiguate the label of the item so that it can be picked out of a list of similarly labelled items in the Search box. However en.wiki could import Wikidata's description to populate a template holding the description. StarryGrandma (talk) 00:12, 13 November 2017 (UTC)
    - That ties in with my limited experience of Wikidata descriptions. The problem with importing them to Wikpedia is that an unknown but significant fraction of them (possibly more than half) are unsuitable for that purpose, and there is no sure way of telling which ones they are other than reading them and comparing with the article content. · · · Peter (Southwood) ^(talk): 09:06, 13 November 2017 (UTC)
- StarryGrandma, If Wikidata can't use text from Wikipedia because of licensing issues, that is a different problem. It is their problem, not Wikipedia's. However,
- If Wikidata request that short descriptions on Wikipedia be licensed CC0, we can consider that. It might be technically difficult to prevent editors managing not to notice that all short descriptions must be released under a different license to the rest of the page, but it may not be a formidable obstacle. If requested, I will cheerfully release all my existing short descriptions under CC0, even though some of them did require a bit of creative thought. If this is a thing that would be useful, it should be requested before the software to support this is written, and before large numbers of short descriptions are added. I will proactively mention this at the experimental template documentation. · · · Peter (Southwood) ^(talk): 08:50, 13 November 2017 (UTC)
  - it would be handy for those purposes, but I think it would be very unwise to use a different license for 1 line inside the same storage point of wiki text. As magic word descriptions would basically be part of the wiki text, it means that we need to have to take into account two licenses not just when the description is being presented, but everywhere we use the complete wiki text, which would be confusing and messy I think. —TheDJ (talk • contribs) 13:49, 13 November 2017 (UTC)
  - Pbsouthwood, I wanted to point out that Wikidata can't use the short descriptions since there had been some discussion above. The issue of descriptions is between en.wiki and WMF. Wikidata descriptions have a particular purpose there and they have some nice tools for creating them from an item's properties. WMF would like a short description to display on mobile and other places, and one created by en.wiki would seem to better serve that purpose. As to license, WMF would not need descriptions to be CC0 to display them with Wikipedia articles. StarryGrandma (talk) 16:57, 13 November 2017 (UTC)
    - TheDJ, StarryGrandma, Your points are taken. RexxS has made a similar point on the template talk page. Making the short descriptions available under CC0 would probably be more trouble than it is worth, and if they are neither needed nor requested by Wikidata, there would be no point in going out of our way to make them available. It should default to standard license unless there is a strong case otherwise. At this stage there is not. · · · Peter (Southwood) ^(talk): 19:26, 13 November 2017 (UTC)

As I was pinged, I thought I ought to help Peter with the proposal. I've created Template:Short description/sandbox which actually does display text, so that you can see how it looks. I've enabled the display of the Wikidata description for the article where the template is used only when the description is set to 'Wikidata' (case-insensitive). So, for example in Colotis zoe, you would get:

{{Short description/sandbox|Wikidata}} →
Wikidata

And in Caravan Palace you would get:

{{Short description/sandbox|Wikidata}} →
Wikidata

"Based at Paris"??? We really need English speakers to edit these descriptions on Wikidata. I'm not watchlisting this shambles, so ping me if you need me. --RexxS (talk) 22:43, 13 November 2017 (UTC)

When there is no description at Wikidata, nothing is displayed. · · · Peter (Southwood) ^(talk): 08:38, 14 November 2017 (UTC)
To experiment with the effects of invoking the Wikidata description, copy-paste the code as provided above to the page in question, and preview, then cancel.

To override the short description from Wikdata and provide it on Wikipedia, all that would be necessary would be to overwrite Wikidata in the template with the improved description. This would be reasonably intuitive, and very easy.· · · Peter (Southwood) ^(talk): 08:38, 14 November 2017 (UTC)

Short descriptions from Wikipedia already imported in Wikidata

Re. (above) "Wikidata cannot import descriptions from en.wiki. Any description written on Wikidata has been explicitly released to Wikidata under CC0 when the edit was made. The data Wikidata imported from en.wiki's infoboxes is factual data. It qualifies for CC0 since factual data is not protected by copyright. However a short description written on en.wiki may or may not be factual data, but may instead be a creative expression." (boldface emphasis added). En.Wikipedia's infoboxes *can* contain short descriptions, which have been imported into Wikidata, after which they were deleted on en.Wikipedia. The examples I'm thinking of are image captions (short descriptions of the content of an image):

e.g., image caption "City hall from the market place, Roland in side view":
- Present in 6 August 2017 version of {{Infobox World Heritage Site}} in Bremen City Hall article
- Copied to Wikidata 22:36, 3 October 2017 (without mentioning origin of the short description)
- Deleted from en.Wikipedia 22:37, 3 October 2017

Don't know whether this short description is a creative expression in the sense above, but if short descriptions of images (and these would be as liable as article content short descriptions of being a creative expression) can be "mercilessly" transferred from en.Wikipedia infoboxes to Wikidata, disregarding copyright intricacies, then what is the problem? Should such transfers of image captions from infoboxes to Wikidata be disallowed? Or can copyright provisions be overridden for both these short descriptions and the article content summaries? --Francis Schonken (talk) 09:40, 14 November 2017 (UTC)

This needs someone more familiar with US copyright law than me, but looking at [13], "Copyright does not protect names, titles, slogans, or short phrases". Mike Peel (talk) 10:23, 14 November 2017 (UTC)

Couldn't tell whether (in copyrightese) City hall from the [[Bremer Marktplatz|market place]], [[Bremen Roland|Roland]] in side view is a "short" or a "long" phrase (IANAL and so forth):

Anyhow, it doesn't have much sense to show the "double square brackets" wikicode in Wikidata imho while the Wikidata software doesn't parse that as a wikilink and simply shows the square brackets, pipes, etc.
Also, the issue is not whether in this particular example the short description is a short or a long phrase: image captions can be long phrases, two or more short phrases, even multiple long phrases in one caption. That may be exceptional in practice, but as such there is no difference with a short description of the topic of an article, which may also be ranging from short to long phrases (also without the ability to contain wikicode at Wikidata).

--Francis Schonken (talk) 11:10, 14 November 2017 (UTC)

Support starting an RFC generally in line with the proposal by Peter (Southwood) above. We can sidestep the whole CC0 discussion above by dropping the unneccessary mention of Wikidata using the descriptions. If Wikidata is interested, they can figure that out.
Ping DannyH (WMF), I suggest/request/invite WMF collaboration. A collaborative RFC can better address your concerns, we can include your preferred proposal as an option in the RFC, and we can put more attention on populating the descriptions. If the WMF continues to stonewall on not even acknowledging anything except a wikidata-default, an RFC-absent-collaboration will get written&run. And everyone will be painfully unsurprised that the WMF&community still can't bridge the collaborative gap. Alsee (talk) 14:02, 14 November 2017 (UTC)

Hi Alsee, I'm happy to work on a collaborative RFC, if that's what folks want to do, and I appreciate the offer. As far as acknowledgement goes, I think there are four basic options that we've talked about in this discussion: stripping all short descriptions immediately, using a per-page magic word override and leaving Wikidata as a fallback, importing all existing Wikidata descriptions into the per-page magic word and not using Wikidata as a fallback, and leaving the system as it currently is. There are also some variants based on timing, and doing some parts earlier than others. I think we've acknowledged and talked about them all, and the magic word override/Wikidata fallback is the option that we'd like to do. But I may be misunderstanding you; let me know if I am. -- DannyH (WMF) (talk) 17:03, 14 November 2017 (UTC)

(Clarification attempt)

strip all short descriptions immediately = Stop displaying Wikidata description of Wikipedia articles in a way that suggests that they are content from Wikipedia regardless of accuracy and possible conflicts of policy on Mobile view and VE (and possibly other uses) - Won'tfix veto from WMF
using a per-page magic word override and leaving Wikidata as a fallback = Inadequately defined. I interpret this as "Wikipedians can manually override the default of displaying the often inappropriate default Wikidata description on mobile if they go to the trouble of finding out that it exists by using mobile, then editing the Wikipedia article to insert a magic word (with undefined syntax) which will do something as yet undefined", perhaps the magic word is to include a local short description, but I don't think I have seen this explained yet. This leaves Wikipedians with the task of finding and fixing all the bad descriptions by overriding them using as yet undefined code. Any short descriptions left to Wikidata will be out of the jurisdiction of Wikipedia policy and can be vandalised under a considerably different set of policies.
importing all existing Wikidata descriptions into the per-page magic word and not using Wikidata as a fallback = What does this actually mean? I am guessing this means that the articles would be populated with a magic word (with undefined syntax) which has a parameter which is the short description to be displayed, which will initially be bot loaded from Wikidata, warts and all, leaving Wikipedians to clean up the mess, because the mess is claimed to be convenient to WMF.
leaving the system as it currently is = What it says; pay no attention to Wikipedia policies because they are inconvenient to WMF. ("never mind the quality, feel the width")
(Not listed by DannyH (WMF)) Adding a template to all articles, which contains a short description provided on Wikipedia, by Wikipedians, defaulting to displaying Wikidata description if and only if there is a specific parameter or magic word invoked. The possibility of bot population of articles which do not already have a manually provided short description with a template containing such a call to Wikidata is a possibility that can be explored. This would still leave Wikipedians with a large job of fixing the inappropriate short descriptions, but the work would be less, some could be automated or semi-automated, and most importantly, it would require far less learning of new code and editing methods by Wikipedians, which would put more eyes and hands on the job. If there are technical problems with this approach, we remain uninformed of them by WMF. Effectively we have a failure to communicate. · · · Peter (Southwood) ^(talk): 06:15, 15 November 2017 (UTC)

I think it's better to split this into "essentially WMF side" and "essentially community side". On the WMF side:

Wikidata-only, presumably with new features for viewing and editing the wikidata value; OR...
Wikidata default, with a keyword to override it (how they handle a blank turns out to be irrelevant); OR...
Keyword, and Wikidata values get switched off on date X. X would presumably be after many/most articles had local descriptions.

On the Community side, assuming a keyword is created:

We would almost certainly wrap the keyword in a template. If the description is "wikidata", we can have it fill in the wikidata value if we want. If the description is blank, we could convert that to spaces or a period or something else to forcibly blank it if necessary. We can set tracking categories if we want. We could put up a preview message if the description is more than # characters long. If the description is blank we could put up a preview message asking for it to be filled. I think that last option would be very helpful for getting them filled quickly. AND...
We can do a bot run to add a {{short description|}} template to articles. We would presumably skip redirects, and I suspect we can skip list articles and disambiguation pages, and anything else we want to skip. We could have the bot insert empty templates, or we could have the bot pre-fill it with the Wikidata value, or we could use some/all of the lead sentence, or we could assign specific descriptions for certain groups of articles. Etc etc etc.

The code for creating a keyword, and for using wikidata by default, is on the WMF's servers. The rest of it is pretty well in our hands. I believe the WMF's willingness to phase-out Wikidata descriptions would be related to our plans to get local descriptions in place. Alsee (talk) 11:48, 16 November 2017 (UTC)

Alsee,

Redirect short descriptions appear not to be used by the mobile view (if I understand DannyH's statement correctly), so could be safely ignored.
List articles may occasionally benefit from a short description, so we should allow for this possibility, but could leave them out of a bot run. My limited experience suggests that less than 10% will benefit from short description, and of these, not having it will do little harm in most cases.
I have not checked disambiguation pages, but you may well be right.
Lead sentences vary from almost perfect to completely useless, with an unknown spread. I don't think we would be doing significantly better than Wikidata descriptions by using them, but again this is a not very well educated guess. Many would need to be severely trimmed of pronunciation guides etc, so not sure if they would be worth the effort. Status quo has many crappy descriptions and many absent descriptions, Not adding more crappy descriptions would be a gain. Where the lead sentence is good, it is reasonably quick to selectively cut and paste an acceptable to good description manually. Coding a bot to do a reasonable approximation of the manual option seems likely to be a lot of work, but I will defer to anyone who actually knows how to do this.
Any automatically generated description, whether from Wikidata or the first sentence should be flagged for human review. which would be a big task, maybe worthwhile, maybe not. Empty descriptions (as opposed to null descriptions) should also be flagged, so the gnomes who wish to create them can find them easily.
We should always bear in mind that the purpose of Wikidata descriptions is not what WMF are using them for in this case. It is a purely opportunistic use case. A good short description on Wikipedia would serve WMF's purpose much better. We should not encourage harming Wikidata to force short descriptions on them for a different function, therefore they should be generated, stored and maintained on Wikipedia. There is some overlap, but this is coincidental, not functional. · · · Peter (Southwood) ^(talk): 19:03, 16 November 2017 (UTC)

Hi Alsee and Pbsouthwood: As I understand it, the tool is going to be a magic word, like {{DEFAULTSORT:Bogart, Humphrey}}. That's not quite the same thing as a template, but close enough. It'll probably be something like {{SHORTDESC:American actor}}. As Alsee says, once the tool is built, it'll be up to the English Wikipedia community to decide how to use it. But it's good for us to collaborate at this stage, because you're starting to make some plans based on your ideas of how the tool would work.

I'd like to understand more about where you think a blank description would be appropriate. In your descriptions of the tool, you've both written about setting a description as blank, and I think talking about the use cases for a blank description would help us when we're building the tool. I've talked on this page about some page types where we agree that descriptions aren't useful: redirects, list pages, category pages, disambiguation pages and the main page. Are there other places where a blank description would be appropriate? It doesn't have to be a major page type or anything, it could be individual examples. Where would it be better to not have a description than to have one? -- DannyH (WMF) (talk) 00:47, 18 November 2017 (UTC)

DannyH (WMF). In high level terms, what would {{SHORTDESC:American actor}} actually do?

Could {{SHORTDESC:none}} (or {{SHORTDESC:null}} or similar) override and provide an empty description field?
Could the display of the short description on desktop be customised and have user display options, so that anyone who strongly objects to seeing it can switch it off (I don't know if there will be any such users, but history suggest the possibility, and having the answers can speed up the discussions.)
Would editing of the parameter field be equally simple in source and VE editors?
Would {{SHORTDESC:Wikidata}} (or similar) be the code for selecting display drawn from Wikidata?

I have not been looking for specific examples, but any page where the title is unlikely to be confused with anything else and adequately describes the topic might not need a short description. Also the best short description is will not be reached on the first iteration, like everything else on Wikipedia it is a work in progress, and must be easily editable because one does not know who will think of an improvement, and should be constantly visible, so that the probability of an improvement is maximized by having more eyes on it, just like any other content.· · · Peter (Southwood) ^(talk): 05:54, 18 November 2017 (UTC)

section break

There isn't just one question here, there are several.

For biographical articles only, see my paragraph above that starts "The biggest problem".

I think probably everyone who has been or will be involved in this discussion has some format in mind, something they've seen on the web or in print, that they're trying to reproduce, or avoid reproducing, with this new feature. It would be easier for me to talk with someone about what they want and why it might or might not be a good idea if I knew what they're trying to emulate.

Here's how the Abraham Lincoln article begins, on my screen, when I type "abraham lincoln":

Abraham Lincoln

(Redirected from Abraham lincoln)

This article is about the American President. For other uses, see Abraham Lincoln (disambiguation).

Abraham Lincoln (February 12, 1809 – April 15, 1865) was an American statesman and lawyer who served as the 16th President of the United States.

And on the right side: Abraham Lincoln. 16th President of the United States.

So, would inserting another "American president" add something we don't already know here, or would it add to the clutter? And that's the best case ... the description field might well contain something that is technically correct but sounds stupid (by comparison with what we've already got), such as "American politician".

Finally: for almost 17 years now, Wikipedians have invested a lot of time in answering questions such as

What are the proper categories to put Abraham Lincoln in? (I see he's in Presidents of the United States, for instance).

What should we put at the top of the lead infobox? ("16th President of the United States")

What's the best first sentence, that is, what do readers want to know first?

So far, I haven't heard an argument made that the best way to proceed in filling in 5.5M description fields (assuming we want them, and there's some evidence to the contrary) is to pretend that all this work never happened, or to pretend that none of it is relevant to the question of what the best short description would be for Abraham Lincoln. - Dank (push to talk) 02:11, 18 November 2017 (UTC)

Inserting a response to some of what's below, quoting Peter: "You may not be talking about desktop, but currently desktop is where a large amount of quality control is done". It's too early to predict how all of this will shake out, and Wikipedians may not be okay with having the first words of an article, the words that readers are most likely to judge us by, be in special field that is invisible in desktop view. If that's the case, then what I just said is relevant, and if not, then a subset of it is relevant. Unwatching; ping me if you need me. - Dank (push to talk) 18:52, 22 November 2017 (UTC)

There has been discussion previously of somehow automatically modifying the first sentence of the article to act as the description. You'd have a hard time using categories instead, at least automatically, because the software can't decide which is most "important". The article has a couple dozen categories, and a system based on that would currently have no way to decide that "Presidents of the United States" is more appropriate as a description than "Survivors of smallpox" or "Illinois Central Railroad people". And the whole reason we would want a description is to represent the article in instances where the full text isn't being viewed. Nikkimaria (talk) 02:25, 18 November 2017 (UTC)

It is in no way a simple problem, and my best guess is that some short descriptions would be amenable to rule based composition, and others will be debated in the same way as contentious content, and would have to be settled by consensus on the talk page. It is a microcosm model of Wikipedia, and frankly, a pain in the butt, but at present I think the presence of a set of reasonably good short descriptions would make the encyclopaedia more accessible, and therefore should be worth the effort in the long term.

To me it is clearly better to have a local short description that can be optimised by the people who have some experience in describing the topic and take the trouble to look after the articles, rather than pulling the description from another project, (controlled by a different community with different rules, created for a different, and entirely legitimate purpose,) by a third group, who don't appear to be constrained by the rules of the other groups, because it is convenient for their purpose, which is also a reasonable and well intentioned purpose, but may contravene the policies of the group who created the article. It is a can of worms, which was opened, and now will not easily be forced back into the can.

It is entirely likely that there will be a strong objection to any given proposal to sort out the mess by Wikipedians, as that is traditionally how things go. Some will object for rational reasons, some just because that is what they do. There is no guarantee that a workable solution will be accepted by the Wikipedia community, and this may be exacerbated by the history of this dispute. There will be those who feel that anything that was imposed on Wikipedia by WMF without prior discussion must be turned down on principle, whether or not the end result is an improvement. Nevertheless, we must try.· · · Peter (Southwood) ^(talk): 05:54, 18 November 2017 (UTC)

There's a lot of questions here, so I'll try to answer all the ones that are for me -- please excuse me if I miss something. :)

Pbsouthwood: {{SHORTDESC:American actor}} would be the short description that appears in all the places where the Wikidata description currently appears: at the top of articles in the apps, in search results, and in the link suggestion in Visual Editor.

For what would happen with "none" or "null": That's what I want to talk about, I want to know more about the use cases for when you'd want a blank description to appear.

For the display on desktop articles: the description doesn't currently appear on desktop; as far as I understand it, we're not talking about desktop at all.

For how to edit in source & VE: I don't actually know how magic words are edited in VE -- looking at the Humphrey Bogart page in VE, I don't see the DEFAULTSORT magic word. I'll have to find out more about that.

For pulling {{SHORTDESC:Wikidata}} -- I'd like to talk more about that idea; I'm not sure I understand the use cases for that. When would you want to use that?

Dank: The short descriptions are used in the app in places like the "top read" list, which you can see in the example here. In that example, as somebody who doesn't follow boxing, I wouldn't have any idea who Gennady Golovkin or Canelo Álvarez are; the labels " Kazakhstani boxer" and "Mexican boxer" are very helpful. I did know that Mother! is a 2017 film by Darren Arnofsky, but for someone who doesn't follow film, that page title would be pretty baffling as well. That's why these short descriptions are helpful -- they provide clarifying information in places where a reader needs it.

As for the display: the short description doesn't appear on desktop, so some of the instances of "American president" that you list aren't visible in the mobile view. Here's a screenshot of the Abraham Lincoln article -- "16th President of the United States" doesn't look redundant here. Yes, that phrase does appear twice, but that's also the case on the desktop, where you see it in both the first sentence and the top of the infobox. -- DannyH (WMF) (talk) 20:17, 18 November 2017 (UTC)

DannyH (WMF), The usual use case for a null short description will be when there is no need for a short description as the article title is sufficient on its own. This appears to be a common but not universal case for list articles, and will occasionally occur for other articles. As there is no simple and universal rule which is likely to cover all cases where a short description is not desirable, it is necessary to have a way of specifying that an editor has assessed the article and its title and has come to the conclusion that no short description need or should be shown. This would be subject to the usual consensus based discussion and modification if there is disagreement, but we need a way to show that the lack of a short description is not because no one has bothered to provide it, but is an editorial choice.

The Wikidata option is in case there is a consensus that Wikidata descriptions could be used as short descriptions in cases where they have been checked and found suitable. My personal opinion is that this could be omitted altogether and Wikidata descriptions never used for this purpose, but I do not represent a consensus view, and we have not established one yet, so I cannot rule out the possibility that this would be required.

You may not be talking about desktop, but currently desktop is where a large amount of quality control is done, and it absolutely must be possible to both see and edit any Wikipedia content in desktop, and preferably possible to edit it using all editing interfaces, so we are talking about desktop. My personal opinion is that it would be best if the default is to display the short description in all views, as this would maximise the exposure, and improve the probability of improvements being made and vandalism being spotted, but again, there is no consensus and will not be until the proposal has been through RfC.· · · Peter (Southwood) ^(talk): 21:23, 19 November 2017 (UTC)

DannyH (WMF), I believe blank descriptions escalated as an issue when it was suggested that a blank would default to Wikidata. The tension on that point may have muddied communication. Setting that aside, a main reason for seeking classes of pages that don't need descriptions was to reduce the task size. The more cases we can identify for automated description, or as not needing description, we better we can focus on pages that do benefit from descriptions.

Note that I suggested a "wikidata" value on principal, not because I advocate it. I was making an effort to acknowledge the possibility, if anyone wants to make a case for it. There's no need for the keyword to recognize "wikidata". I expect the keyword will get wrapped in a template, and a template could implement {{description|wikidata}}.

A "none" value can also be handled by a template, rather than the keyword. A "none" value is useful for general reasons. If there's a dispute it could be convenient to fill in "none" until the issue is resolved. A bot could add the keyword or template without any value, and an editor might fill in "none" showing that it had been explicitly set. I wasn't pushing any particular criteria for when an article might not need a description. I presumed such standards would be sorted out via the usual policy/guideline processes.

Desktop visibility: It doesn't seem very useful in desktop read mode, and visibility in the edit-view/watchlist/diffs/recentchanges plus wherever-it-does-display is probably sufficient.

Visibility on mobile-web presumably could/would be restored when the wikidata issue is resolved. Alsee (talk) 11:25, 21 November 2017 (UTC)

DannyH (WMF), Alsee adequately explains the utility of "none" directly above. Iridescent, below, proposes a possible way of managing desktop view, and explains why it is useful. Both of these replies mesh seamlessly with my previous comment. · · · Peter (Southwood) ^(talk): 13:23, 21 November 2017 (UTC)

Alsee & Pbsouthwood: In order to build the "none" feature, I need to know some use cases where that would be appropriate and helpful for the reader. The example that Alsee gives -- blanking a description during a dispute -- sounds to me like removing the lead paragraph from the "Charles Dickens" page because people are disagreeing about one of the sentences in it. Nobody on Wikipedia would ever do that, because we know that having a lead paragraph is important, even if there's something in it that's currently contested. I don't see why you would want to completely blank a description that's under discussion. I can see why there would be disagreements about phrases like "conspiracy theorist," "pseudoscience" or "religious cult", but if that description is contested, you could use a bland phrase like "radio show host", "theory" or "religious movement" while people are discussing the more contested language. Like I said, I need to know some actual examples before we build a feature. -- DannyH (WMF) (talk) 01:20, 22 November 2017 (UTC)

DannyH (WMF) as I note below, there's no need to build a "none" feature. Letting no-value be blank is enough. You asked to understand how "none" could be helpful for the reader: You're missing an important detail. It's helpful to editors. We famously[14] had a 40,000 word battle over whether Star_Trek_Into_Darkness should have a capital-i or lowercase-i in the word "into". People are idiots and they can battle over everything and anything. The community owns the headaches of content issues and people-problems. Descriptions are a content issue.

If there is a BLP issue, we remove the content until it is resolved. Period. The battle may come down to a single charged word. One side may argue-to-the-death that any description including the word is absolutely unacceptable. The other side may argue-to-the-death that any description excluding the word is absolutely unacceptable. We may blank that content until we can reach some tolerable result. Readers are not directly served by a blank description. However readers are served when we coerce editors to either (A) work with each other; or (B) go do productive work on something else. That kind of incident may be rare, but it can be a major time-sink detracting from work on everything else.

It's weird having to come up with "use cases". Deliberately blanking a description seems like such obvious basic functionality for generic work, in a wide-ranging and chaotic environment. Alsee (talk) 06:17, 22 November 2017 (UTC)

DannyH (WMF) and Alsee, My suggestion for having a "none" feature is so that an editor unfamiliar with the reasoning behind not having a short description, does not go and create one where it is not wanted. The "none" entry is not intended to suppress display of an actual short description, it is there instead of a short description, to indicate that someone has decided that a short description is unnecessary or undesirable. There should never be a case where a short description and a "none" entry coexist, and the point of having a "none" entry is to occupy the space that the short description would occupy so that it cannot be there. However, displaying "none" would be silly, so it should not be displayed. It would be possible to approximate this functionality by leaving the short description field blank, and adding a comment somewhere in the vicinity to explain why no short description is needed, but that might not be visible, depending on how the edit interface works (maybe in VE? I don't know) and if it is not visible, people will add unwanted short descriptions, leading to frustration and incivility, which wastes time and goodwill, and does not serve the purpose of building the encyclopaedia. Having a "none" feature makes it easier to recognise the difference between a short description being missing and a short description being unwanted. Less pointless quibbling may improve productivity and editor retention.· · · Peter (Southwood) ^(talk): 07:16, 22 November 2017 (UTC)

What would happen if a comment were to be put into the magic word instead of the short description? As in {{SHORTDESC:}} - this might work as a way to notify editors that no short description is needed without the need for special coding, and would have the added advantage that any explanation could be included, like {{SHORTDESC:}} or {{SHORTDESC:}} · · · Peter (Southwood) ^(talk): 07:32, 22 November 2017 (UTC)

DannyH (WMF), I have explained this before, but will do it again: Not all lists do not need a short description. Some lists do need a short description. I will try to find you a use case for this, and a use case for a non-list article that does not need a short description, but as I said, they are the minority case and not easy to find. It may take some hours of work, but they are not hypothetical as I have already seen them. However if the comment inside the magic word works, it may be a moot point. · · · Peter (Southwood) ^(talk): 07:16, 22 November 2017 (UTC)

{{DEFAULTSORT:}} is available in VE under "Page settings" in the right dropdown menu under "Categorization". That's likely also where an edit option for {{SHORTDESC:}} would reside. I do note that VE cannot edit {{SHORTDESC:}} if you wrap it in a template. Because it doesn't know about the logic inside of a template. Instead it would probably be an "invisible template", that would get one of those puzzle pieces blocks, and when you click it, you can edit it like any other template. Pagesettings have no content to preview. —TheDJ (talk • contribs) 12:20, 21 November 2017 (UTC)

TheDJ: Thanks for telling us that; I couldn't figure out where it was. :) So that's the way that this magic word would work -- visible in the wikitext editor as {{SHORTDESC:American actor}}, and in the VE editor under Page settings. It would not be a template; magic words and templates are different. I can explain the distinction between magic words and templates in more detail, if that would help? -- DannyH (WMF) (talk) 01:24, 22 November 2017 (UTC)

Maybe that would be useful. Can a magic word generally be used in a template or must it be specially coded to work there?· · · Peter (Southwood) ^(talk): 07:16, 22 November 2017 (UTC)

I have no intention of reading the above wall of text to see if this has already been suggested, but some variant of the WP:Metadata gadget—either as an preferences-enabled gadget, or as an extension for all logged-in accounts—by which the short description is visible at the top of the article for logged-in editors, would seem to me a good idea, particularly if it included a "fix or remove this" button that didn't involve having to navigate to Wikidata. Most errors on Wikipedia aren't fixed by people in edit mode, but by editors reading articles who notice mistakes. ‑ Iridescent 11:37, 21 November 2017 (UTC)

@Iridescent: A user script for this already exists in the form of wikidata:User:Yair_rand/WikidataInfo.js (screenshot). But I note that we currently seem to NOT going to be using Wikidata and therefor, we will not really have a need for this anymore I suspect. —TheDJ (talk • contribs) 12:02, 21 November 2017 (UTC)

Thanks, Iridescent, that may be a useful solution, and as far as I can remember it has not been explicitly suggested before. · · · Peter (Southwood) ^(talk): 13:23, 21 November 2017 (UTC)

Solutions involving Wikidata

While I tend to agree with Ita140188 and Mike Peel above, I also understand the hesitation about Wikidata hosting the descriptions while standards differ. Thus far, we've only tried to answer this question between Wikipedia and the WMF development team, and I think we're leaving out a better solution.

First, let's ask ourselves if there's any great willingness over at Wikidata to fully populate the English short description fields. And if there's any reason for Wikidata folks to object to English short description fields that are fully compliant with the English Wikipedia policies and visible and editable by English Wikipedia editors. I think there's not a huge willingness/capacity to fill in the missing 2 million descriptions, and that if descriptions are improved over here on en.wiki, there's no reason for Wikidata to not import them. Of course we should ask the Wikidata community about these questions.

If that's all true, then either…

Wikidata could wait for us to get new software, get the magic word, then produce a lot of improved descriptions, and finally reimport them by bot back to Wikidata.
Wikidata could create a new policy requiring X-language descriptions be compatible with x.wiki policies.
WMF could create software to provide an editbox for Wikidata X-language descriptions on x.wiki. and/or
We could just start editing Wikidata descriptions with better, policy-compliant English descriptions.

Ultimately, all of these things are good for the broader community. If 2 is easier than 1, I'd rather see the effort go into improving Wikidata and causing some important conversations (BLP, V) to happen there, even if the conversation is about the restricted domain of English language descriptions. If 2 is impossible, then fine. But asking the Wikidata community to implement 2 means attempting to improve Wikidata (and the broader Wikimedia community) rather than trying to quarantine ourselves from it.--Carwil (talk) 20:09, 15 November 2017 (UTC)