Change 688381 had a related patch set uploaded (by Huji; author: Huji):

[operations/mediawiki-config@master] Enable ShortDescriptions on fawiki

https://gerrit.wikimedia.org/r/688381

This was often denied in the past (e.g. T204136), thus pinging @DannyH.

@Zabe the reason for declining, as explained in T204136#4594847, has nothing to do with this case.

@DannyH: can you please provide me with the reasoning of why this was rejected back in 2018 at T204136#4584681 and clarify whether your 2021 comment at T279829#7034774 plus the fawiki community consensus linked above means this task should be proceeded with or not?

I will convey the reasoning to the fawiki community.

I also want to point out the community's reasoning for this request: (1) it is unlikely that the community will be able to monitor Wikidata against vandalism; (2) Wikidata community has failed to monitor Persian content against vandalism several times; and (3) the community is seeing an increasing amount of mobile users who, among the first things they say on a page, are constantly exposed to short descriptions.

I -2'ed the patch for now, because of the declining comments from 2018 and because the dewiki deployment (T279829) is happening under DannyH's supervision, setting a newest precedent for how this sort of thing should be done.

@Huji: Yes, if there is community consensus on fawiki, and we talk about the deployment process with them, then we are willing to support using the shortdesc magic word there.

On English Wikipedia, this process had two steps:

First, the magic word was enabled, and people started writing or copying short descriptions. When the shortdesc magic word existed on an article, the features and apps used the local description. For articles that didn't have a shortdesc description, we fell back to using the Wikidata description.

Once we hit an agreed-upon number of short descriptions on the article pages, we went to the second step, which was to disable the Wikidata descriptions completely, and only use the descriptions used on local article pages.

Reading the fawiki discussion (using Google Translate), it looks like the community has agreed just for that first step — a way to override Wikidata descriptions on individual articles where there has been vandalism. Is that correct?

Yes, the scope of the consensus right now is only focused on the first. This way, if vandalism occurs on Wikidata, the local community has a very easy way to stop its impact (by adding local description); similarly, if an article is locally protected, its short description can be locally specified so that it would also be subject to the protection.

The decision as to whether and when to proceed to the next stage is something I expect would happen later, based on community's assessment of the usefulness of the first stage. This may also be influenced by T282504 and if the usability of the Wikidata-based solution is improved, the community might never decide to go to that next stage.

In T282486#7076466, @Huji wrote:

@Zabe the reason for declining, as explained in T204136#4594847, has nothing to do with this case.

The reason I pinged was T204136#4584681

In T282486#7077726, @Zabe wrote:

In T282486#7076466, @Huji wrote:

@Zabe the reason for declining, as explained in T204136#4594847, has nothing to do with this case.

The reason I pinged was T204136#4584681

Understood. That 2018 comment has been challenged in several Phab tasks and as you see above and in T279829#7034774 it seems like Danny's stance on the matter has changed. I think we should not reference that 2018 comment going forward.

Yes, the 2018 comment is no longer applicable. After the change on English, we wanted to make sure that everything would work properly, without unforeseen problems. I would still like to treat these case-by-case, to make sure that the community consensus is clear, and to make sure that the WMF teams that are involved with descriptions are aware of the changes.

@DannyH with this understanding, should I schedule the patch for deployment again? If yes, I will ask @Urbanecm to remove the -2 as well.

@DannyH just checking in about the above comment from last year.

From the Wikidata PM side this unfortunately is still not ok to do.

In T282486#9422018, @Lydia_Pintscher wrote:

From the Wikidata PM side this unfortunately is still not ok to do.

Is there any reason why this is not ok? What would be the problem?