I really hope this never happens, and that the locally-defined descriptions are merged back to Wikidata. There are 2.8 million infoboxes on Commons that are using the English descriptions from Wikidata, and there is currently no way that they can access the enwp descriptions.

In T248457#6003779, @Mike_Peel wrote:

I really hope this never happens

There was repeated consensus on this, and if you recall you participated in one. The Foundation handled things badly, but committed to terminating wikidata descriptions when we reached 2 million local descriptions. I expect the result would be Bad all around if the Foundation were to renege.

There are 2.8 million infoboxes on Commons that are using the English descriptions from Wikidata, and there is currently no way that they can access the enwp descriptions.

Should we open a different task for English article-descriptions to replace the English field on wikidata?

In T248457#6004246, @Alsee wrote:

In T248457#6003779, @Mike_Peel wrote:

There are 2.8 million infoboxes on Commons that are using the English descriptions from Wikidata, and there is currently no way that they can access the enwp descriptions.

Should we open a different task for English article-descriptions to replace the English field on wikidata?

I'm sorry but this is not gonna happen.

In T248457#6004246, @Alsee wrote:

In T248457#6003779, @Mike_Peel wrote:

I really hope this never happens

There was repeated consensus on this, and if you recall you participated in one. The Foundation handled things badly, but committed to terminating wikidata descriptions when we reached 2 million local descriptions. I expect the result would be Bad all around if the Foundation were to renege.

Yes, my comment there still seems to hold true. "I personally think it is a bad idea and a waste of developer time." Add to that the massive waste of editor time to add those local descriptions, which can't even be copied back to Wikidata due to copyright restrictions. This whole situation sucks.

I note that Category:Articles with short description only has 1.8 million entries. Why the difference?

In T248457#6008042, @Pppery wrote:

I note that Category:Articles with short description only has 1.8 million entries. Why the difference?

Category numbers are terrible for determining anything (cache voodoo?). Elasticsearch indexing is more accurate and can be used for this purpose.

The current mainspace search count of about 2,250,000 matches up well with the category count when you include non-article mainspace pages, primarily disambiguation.

Category:Pages_with_short_description currently reports approximately 1,939,000 articles, approximately 312,000 disambiguation pages, plus some thousands of pages of other types in and out of mainspace.

In T248457#6006312, @Mike_Peel wrote:

In T248457#6004246, @Alsee wrote:

In T248457#6003779, @Mike_Peel wrote:

I really hope this never happens

There was repeated consensus on this, and if you recall you participated in one. The Foundation handled things badly, but committed to terminating wikidata descriptions when we reached 2 million local descriptions. I expect the result would be Bad all around if the Foundation were to renege.

Yes, my comment there still seems to hold true. "I personally think it is a bad idea and a waste of developer time." Add to that the massive waste of editor time to add those local descriptions, which can't even be copied back to Wikidata due to copyright restrictions. This whole situation sucks.

The disadvantages of using a database field that isn't tracked and is not capable of being sourced to verify its contents far outweigh the value of being able to pull an English-only value into other projects. Those arguments are well-rehearsed and the consensus is clear.

I seriously doubt that there are any genuine copyright barriers to importing enwiki short descriptions into the Wikidata description fields for two reasons:
(1) short descriptions are almost certainly too short to be copyrightable (see https://www.bitlaw.com/copyright/unprotected.html for example);
(2) we already import the English short description into Wikidata when we use short description helper to create a short description where Wikidata has no English description.

The task T191531 asks for local short descriptions to be exposed via a Scribunto library call, and is still open. The simplest work-around is to use the Wikidata description field to hold each wiki's local description where it exists. There's no mechanism for that to happen automatically as far as I can see, but having a bot crawling for changes to the local short description and updating Wikidata would be nothing unusual and timely enough for our applications on Commons, etc.

WMF staff, please hold up your end of our agreement by disabling the Wikidata fallback for short descriptions at en.WP.

See this discussion on en.WP, which summarizes the current request.

Since the only wikis using $wgWikibaseAllowLocalShortDesc are English Wikipedia and Test Wikipedia, I think we should just repurpose that config variable rather than creating a new one. To implement this change, we'll probably need to do some refactoring in client/includes/Store/DescriptionLookup.php and client/includes/Api/Description.php and update all the associated tests (within the Wikibase extension).

Hi everyone, I posted a response on the English WP Village Pump (WMF) page, saying that we are going to be working on this ticket. There are still a few things to work out, so there's no firm date. You can follow along by watching this ticket.

My post is here: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(WMF)#Update:_Scheduled_shutdown_of_Wikidata_descriptions_on_EnWiki

If you've got any thoughts or questions, please post them on that VP page, and do not post them on this ticket, even if it's a positive "yay, glad to see this" comment. This ticket is a workspace for the developers who are going to be working on making this happen, so please don't distract them from doing the thing that you want them to do. :) Thanks, talk to you on the VP.

Excuse me, I understand correctly that the devs, instead of including a changes in the Wikidata element's description to the watchlist and recent changes, agreed to such a strange decision?

@Iniquity - There are other issues as well. For example, the Wikidata community's insistence that Wikidata descriptions are primarily for disambiguation on Wikidata and not intended for other use cases. This is why we have Wikidata descriptions like:

one of two or more individuals having at least one parent in common. Avoid using with "relative" (P1038), use "sibling" (P3373) instead

... which are unusable anywhere besides Wikidata. Hopefully, this will one day be alleviated via T97566, however.

In T248457#6293589, @kaldari wrote:

There are other issues as well. For example, the Wikidata community's insistence that Wikidata descriptions are primarily for disambiguation on Wikidata and not intended for other use cases. This is why we have Wikidata descriptions like

@kaldari thanks for your answer! In this case, I don’t really imagine why these descriptions were included in all projects on mobile devices. But this, again, is not a reason to make crutches only for the English Wikipedia.

If you don't want to abide by the policies on the English WIkipedia, you need to stop adding content to the English Wikipedia. It's not a difficult concept.

In T248457#6326902, @RexxS wrote:

If you don't want to abide by the policies on the English WIkipedia, you need to stop adding content to the English Wikipedia. It's not a difficult concept.

By your logic, I can now go through all major wikis and say that wikidata adds garbage for all projects in the mobile version. And the initiative safely stops, instead of solving the problems of the "description" field.

Yes, you could do that and get laughed at. Nobody has said Wikidata adds garbage except you. What happens, though, is that it adds content that may not abide by the local policies and that is a fundamental flaw.

The description fields are monolingual, so only affect a single language. They are also unable to cite their source, which is major disadvantage for serious use. The mistake is to think that Wikidata is the best place to store the authoritative version of a subject's description for each language. The best place for that is on the individual Wikis and these changes are a step towards making that happen.

In T248457#6329589, @RexxS wrote:

What happens, though, is that it adds content that may not abide by the local policies and that is a fundamental flaw.

I don’t understand how a five-word sentence might not be in line with local politics. And I also don't understand why this policy cannot be negotiated with Wikidata?

The description fields are monolingual, so only affect a single language.

Yes, it is monolingual, but we have about ten monolingual projects, which in the future will also most likely be able to use Wikidata. And they may have cross-articles.

They are also unable to cite their source, which is major disadvantage for serious use.

There are no sources in your template either, this is not the subject of conversation.

The mistake is to think that Wikidata is the best place to store the authoritative version of a subject's description for each language. The best place for that is on the individual Wikis and these changes are a step towards making that happen.

I think you are wrong, Wikidata is the best place to store this kind of statistical information, information that can be used by many projects, not only Wikimedia projects. It was created for this. And given that Wikipedia is a place where content typing exists, as opposed to Wikidata, Wikipedia should be integrated into Wikidata for control these fields, instead of separating from the project. And even if we imagine for a second that you are right, it should be implemented differently, not by a template. It is also worth remembering that people who fill the fields first of all look at how these fields are filled in other large languages, and English is displayed by default.

@Iniquity this is not a good place to have this argument. If you want to convince the English Wikipedia community that Wikidata descriptions do not conflict with their policies, or that they should be used regardless of whether they conflict with their policies, you need to do that on English Wikipedia.

In T248457#6330315, @Tgr wrote:

@Iniquity this is not a good place to have this argument. If you want to convince the English Wikipedia community that Wikidata descriptions do not conflict with their policies, or that they should be used regardless of whether they conflict with their policies, you need to do that on English Wikipedia.

I came here not to convince the English Wikipedia community, I came here to express my disturbance to the Wikidata and MediaWiki developers that they support the deterioration of integration between projects.

Each project however retains full control over their content. The Wikidata
integration was done prior to receiving community feedback and hence
there's no reason to not undo this given that work has been put in to make
it better for everyone - integration does not equate to it being better. As
Tgr said, this is not the place to relitigate, if you object to this, start
a discussion on English Wikipedia.

In T248457#6330346, @QEDK wrote:

Each project however retains full control over their content. The Wikidata
integration was done prior to receiving community feedback and hence
there's no reason to not undo this given that work has been put in to make
it better for everyone - integration does not equate to it being better. As
Tgr said, this is not the place to relitigate, if you object to this, start
a discussion on English Wikipedia.

I would probably still agree with this if the integration would be simply disabled. But instead of that, the integration turns into support for a template, which is then transferred to other Wikipedia, where it is completely useless.

I would probably still agree with this if the integration would be simply disabled. But instead of that, the integration turns into support for a template, which is then transferred to other Wikipedia, where it is completely useless.

The template is a wrapper for the parser function of the same name. It only adds categorization options and a none option (probably should be added to the parser function). All changes here should probably be done at the parser function level so disabling it can be an option elsewhere as well.

In T248457#6330283, @Iniquity wrote:

There are no sources in your template either, this is not the subject of conversation.

I can add sourcing or references at any time to the template, and you can't do that with the Wikidata description field. The lack of the ability to source the content of the Wikidata description field most definitely is the subject of this conversation that you started.

I think you are wrong, Wikidata is the best place to store this kind of statistical information, information that can be used by many projects, not only Wikimedia projects. It was created for this. And given that Wikipedia is a place where content typing exists, as opposed to Wikidata, Wikipedia should be integrated into Wikidata for control these fields, instead of separating from the project. And even if we imagine for a second that you are right, it should be implemented differently, not by a template. It is also worth remembering that people who fill the fields first of all look at how these fields are filled in other large languages, and English is displayed by default.

You can think whatever you want; I'm not wrong. Text descriptions are not "statistical information", and the English description is not used in any of the other language projects. The description field was indeed created for general use and hopefully using the description from the English Wikipedia will improve the Wikidata description field for all of those other users. It would be a real step forward to improve the integration of Wikipedia into Wikidata for those very reasons.

The problem with your view that Wikidata has to be authoritative is that it undermines the efforts of folks like myself who have worked for seven years to gain acceptance for the principle of using Wikidata in the English Wikipedia. Every time an issue like this one arises, it hardens the attitudes of those who want nothing to do with Wikidata, and it makes it more difficult for me to gain acceptance for technical solutions that provide acceptable compromises.

I apologise for having taken space in the thread to vent my frustrations. I don't intend to do so any further.

a database field that isn't tracked and is not capable of being sourced to verify its contents...

Neither of those claims are true. Wikidata edits are tracked in watchlists, just like those in Wikipedia are. And Wikidata descriptions should be sourced in the body of the Wikidata item, just like material in Wikipedia ledes or infoboxes is sourced in the body of the Wikipedia article.

Can we please stop rehashing the RFC here? If there is difference of opinion on the merits of this change, please seek consensus on Wikipedia, not here. Arguing here only wastes the time of everyone involved.

I'll untag us on this; we have two parts of this project already getting scoped, so we'll leave the parent task untagged.

In T248457#6359928, @kaldari wrote:

Can we please stop rehashing the RFC here? If there is difference of opinion on the merits of this change, please seek consensus on Wikipedia, not here. Arguing here only wastes the time of everyone involved.

There is not about local consensus of enwiki, they can do whatever they want, it's about how the developers and the fond implement the integration with wikidata and between all projects.

There is not about local consensus of enwiki, they can do whatever they want, it's about how the developers and the fond implement the integration with wikidata and between all projects.

Nothing will change regarding the Wikidata integration for other projects (besides English Wikipedia).

In T248457#6361440, @kaldari wrote:

There is not about local consensus of enwiki, they can do whatever they want, it's about how the developers and the fond implement the integration with wikidata and between all projects.

Nothing will change regarding the Wikidata integration for other projects (besides English Wikipedia).

Once again, the current implementation creates an unused comfused template across hundreds of wikis because of ContentTranslator, and also allows large wikis to be removed from the workflow instead of integrating them, which degrades the quality of the data on Wikidata.

@Iniquity - Your continued arguments here are inappropriate and disruptive. Please stop. We have already agreed to implement this change at the request of the English Wikipedia community. If you have concerns about the merits of this change, please take them to that community and present your case there.

In T248457#6363684, @kaldari wrote:

@Iniquity - Your continued arguments here are inappropriate and disruptive. Please stop. We have already agreed to implement this change at the request of the English Wikipedia community. If you have concerns about the merits of this change, please take them to that community and present your case there.

I am completely at a loss as to why I should be doing this in a place that was not intended for this. My comments are not about English Wikipedia, my comments are about the workflow of all projects.

In T248457#6361568, @Iniquity wrote:

In T248457#6361440, @kaldari wrote:

There is not about local consensus of enwiki, they can do whatever they want, it's about how the developers and the fond implement the integration with wikidata and between all projects.

Nothing will change regarding the Wikidata integration for other projects (besides English Wikipedia).

Once again, the current implementation creates an unused comfused template across hundreds of wikis because of ContentTranslator, and also allows large wikis to be removed from the workflow instead of integrating them, which degrades the quality of the data on Wikidata.

If there is a problem with ContentTranslator importing a template that should not be imported, please file that as a separate feature request. The short description template can't possibly be the only template that is unique to en.WP.

Just to let you know that I've started at RfC about bot-syncing Wikidata and enwp descriptions at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#Synchronising_short_descriptions_and_Wikidata_descriptions

I find the lack of action on this ticket stunning. This is exactly why I said two years ago to completely cut off en.wp from these features, so that we wouldn't have this mess right now.

Stop making promises and then NOT keeping them. This completely undermines any remaining trust of the en.wp community in the foundation. This should be TOP priority, drag everyone out of their current tasks and halt all other stuff.
You had two years to prepare for this, in which you did NOTHING.

In T248457#6435718, @TheDJ wrote:

I find the lack of action on this ticket stunning.

FWIW, there is some discussion on this on https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(WMF)#Update:_Scheduled_shutdown_of_Wikidata_descriptions_on_EnWiki which gives the impression that there is some activity, just not very well tracked.

@TheDJ @Tgr - It seems that most of the work currently being done in relation to this is at T259617 and associated subtasks. Not sure why those aren't connected here though.

I'm removing this from the tech-product api roadmap since we've captured the API-specific parts on T259617.

Is there a reason for this task to still be open? Is there some aspect that is not 100% complete?