Wikipedia talk:Wikidata/2018 State of affairs: Difference between revisions

Archives

Archive 1

This page has archives. Sections older than 14 days may be automatically archived by Lowercase sigmabot III when more than 3 sections are present.

Preceding discussions at Wikipedia talk:Wikidata/2017 State of affairs (and archives)

Is it just me, or is this is a common problem ("feature" probably)? When I go to Homer on Wikidata, I can see the references. When I log out (visit as an IP or a normal reader), the "X references" beneath each item becomes grey, and I can't open them; this means that all non-logged in editors can't actually see any references... I don't think it is useful to send readers to items where they can't even see the references. Fram (talk) 13:33, 30 January 2018 (UTC)[reply]

That's weird. I can reproduce it, but only on some entries. I think it's related to when the Wikidata pages are protected. Pinging @Lydia Pintscher (WMDE): and I'll raise it on phabricator - now at phab:T186006. Thanks. Mike Peel (talk) 14:26, 30 January 2018 (UTC)[reply]

Thanks for filing the ticket, Mike Peel. That is indeed weird. We'll look at it. --Lydia Pintscher (WMDE) (talk) 14:59, 30 January 2018 (UTC)[reply]

This is not related to the RfC going on, but to the mobile version displaying Wikidata contents from description field. As we are approaching St. Valentine's Day, a fellow sysop from the Portuguese Wikipedia noticed there were gross obscenities displaying in the mobile version of our article, and not immediately finding the source of the vandalism, asked my help to remove it (which I did, of course). The obscenities were there, at such an high-profile article, apparently unnoticed, since July 2017. This is absolutely not acceptable, the irresponsibility of using those Wikidata descriptions on our Wikipedia articles is damaging even more the reputation of our project. we already have our problems, which are not few, and we don't need one more to pill up. Can this thing be reverted? Where can we appeal to remove that "functionality" from our project? Thanks, -- Darwin ^Ahoy! 23:18, 5 February 2018 (UTC)[reply]

The RfC on the short descriptions magic word has been closed. The result is

"The consensus is #5 for the first question - To populate the magic words by starting with blanks, and allowing them to be filled in manually and/or by bot (as per usual bot procedures). The consensus is #2 for the second question - Show no description where the magic word does not exist. "

Can the WMF please indicate whether they will respect the result of this RfC and when we may expect the magic word to be available? Fram (talk) 10:44, 7 February 2018 (UTC)[reply]

• I guess now we'll see whether the WMF will shut off almost all short descriptions for mobile users probably indefinitely, on a mere 10-6 vote. I rather hope they don't. @DannyH (WMF): ? Jheald (talk) 11:07, 7 February 2018 (UTC)[reply]
  • You (one of the "6" of that vote, let's not restart that RfC here) are free to populate the magic word once it is available, or to request a bot to populate it. The rfC was not "we will not use the magic word" or "no short descriptions". And of course, it wasn't the first RfC on this, we already had a previous RfC which supported the shutdown of the Wikidata descriptions on mobile, this is just a confirmation for the WMF that yes, this is what we really want. Fram (talk) 11:12, 7 February 2018 (UTC)[reply]
    • Meh. 4 !votes isn't much of a mandate. I think WMF would be entirely within its remit as steward for the interests of our users to say: fine, we note this vote, we will turn off descriptions drawn from Wikidata -- once the community has demonstrated it has the capability and will to step in, and that it will not leave mobile users hanging in the lurch, eg once it has created local descriptions for at least 50% of articles. That would seem an entirely reasonable and discriminating stance for the WMF to take.

    As for myself, thank you very much, but I already have a full slate of sources I'm working on, sticking to adding new stuff that's actually useful, rather than wasting my time pointlessly duplicating content we already have. But one thing I would say, if people are thinking of automated creation of local descriptions here, is that it probably makes sense to go via improving the descriptions and/or auto-descriptions that are on Wikidata first. The nature of Wikidata makes these easier to extract for particular large subsets of articles, to understand their patterns, adequacies, and deficiencies in bulk, and easier to then iteratively re-extract and re-update, to evaluate at scale against conformance for particular goals. If the aim is collaborative assessment and improvement, it's a platform that provides the capabilities needed for the work. Certainly better to put in what fixes can be made there first, rather than to blindly import whatever WD may have at the moment to here as an initial step, where it will probably never be systematically looked at, and never fixed. Jheald (talk) 12:21, 7 February 2018 (UTC)[reply]

    • • They have never (or cerainly not adequately) checked whether the Wikidata community (who currently "maintain" these descriptions" had the "capability and will to step in", so imposing this as a conditio sine qua non on enwiki seems rather one-sided. The WMF is rarely if ever a "steward for the interests of our users", usually they are a steward to the interests of their paid developers and myriad of managers and intermediaries only. Episodes where the WMF imposed its will against the wishes of the community have invariably ended in strife and have created lots of distrust and disdain, and in the end usually resulted in the WMF having to back down anyway (Gather, Flow, ...). And you still don't seem to get that it is not within our remit to go and "fix" the Wikidata descriptions on Wikidata, as many of them are perfectly suited for their real purpose (a description on Wikidata) but unfit to be used on enwiki. To change these to descriptions suited for enwiki would not be welcomed (and rightly so). We are two different projects, and using one to populate the other is in most cases a bad idea (e.g. the millions of "imported from Wikipedia" sourced items on Wikidata, which are now being imported back into Wikipedia as if they are reliable information). Fram (talk) 12:44, 7 February 2018 (UTC)[reply]
        • I'm not saying you have to do it this way. I'm just saying, if you want to populate local descriptions on en-wiki, going this way and using Wikidata as a staging area probably makes sense.

        First, though, you need to create a style guide for the descriptions you want on en-wiki -- ie how long they should ideally be, what information should be included if available for various different types of article, etc.

        Then, as I presume you won't be literally creating 5.5 million descriptions from scratch, you need to come up with sources of candidate descriptions -- perhaps what's already at Wikidata, or one of Magnus's auto-descriptions based on Wikidata, or some other source; or perhaps multiple such sources, making a bespoke choice or combination per article.

        Then you need to evaluate whether those descriptions actually match your style guide -- do they contain the key information they should do?

        Maybe not all of it, and maybe not for every article, but a lot of this work it would make sense to do in a Wikidata environment -- because Wikidata gives you a space where relevant information is available, and where it is easy to query and retrieve the texts and properties for large related groups of articles at scale.

        Yes, there will be some cases where en-wiki's needs aren't precisely the same as Wikidata's (eg disambiguation pages?); but mostly I imagine descriptions in line with whatever style guide en-wiki will come up with would be entirely acceptable on Wikidata (wd's requirements are probably not as exacting in this area as en-wiki's) and I would think that descriptions that had been systematically analysed and raised up to the en-wiki style guide for information inclusion and conciseness would be very welcome.

        You may see all the Wiki projects as entirely separate. I don't. I see the relationships as much more synergistic. If I create a tracking table like Talk:List of Royal Academicians/RAs it's because it makes sense to make a hub for improving all of the projects together -- which RAs don't have Wikipedia articles? Which don't have Commons categories? Which might we identify with more external IDs? Sometimes different projects need to go their own way, and that flexibility is valuable. But it makes little sense to create walls where they don't need to exist. Jheald (talk) 13:29, 7 February 2018 (UTC)[reply]

        • (ec)I have no objection to Wikidata eventually using our descriptions if they are so inclined, that's their choice (and usually they will be so short and simplistic that copyvio / need for attribution seem to me like something of no concern in this case, although others have raised this as an issue when one would copy in either direction). As for your "improving all of the projects together" and "which RA don't have Wikipedia articles", I think you refer to enwiki alone, and not the 200+ other languages? In any case, no one is stopping you from doing this (I hope), but I have no interest in dividing my limited time over multiple projects, with their own policies, rules, goals, ..., and I see it as seriously detrimental to divide the actual textual article content over multiple, poorly integrated sites, as it seriously complicates editing, maintenance, ... for little actual benefit (Wikidata is not in general more up-to-date or reliable than what we have here, and has much looses sourcing rules). Using Wikidata to generate project lists, talkpage lists, ... all kind of checks and balances, fine! That's a thing it can be really useful for, e.g. lists of missing articles and so on. But not for autogenerating actual articles and mainspace lists, or populating infoboxes, or showing texts to readers which isn't maintained at enwiki. We shouldn't throw away the strength, the core of Wikipedia just because we have a shiny newer tool. Fram (talk) 13:50, 7 February 2018 (UTC)[reply]

          • Fram, I am just saying that practically, as a matter of workflow, if you're serious about creating these vast numbers of description texts, with any form of group quality control, it probably makes sense to use Wikidata as a staging area, because of the technical capabilities that would give you. Jheald (talk) 14:04, 7 February 2018 (UTC)[reply]

            • I don't edit Wikidata and have no intentions of doing so. Too many toxic personalities who have been shown the door or are seriously restricted here are given free reign there. Furthermore, the policies (or near-total lack of them) and anything-goes mentality (be it unsourced articles about non-notable minors, or the use of sources which are completely unreliable and full of copyvios) turn it into a place I don't want to be a part of. I have no idea how you would actually use Wikidata as a staging area unless you propose overwriting their descriptions with whatever we want. Like I said, you (or anyone) is free to make such suggestions at the bot owners noticeboard or at some village pump. I don't see how this would be practical or beneficial, seems much easier to e. copy all Wikidata descriptions to the corresponding article talk pages and get some approval process there, but it isn't up to me to decide if, when and how we will populate the magic word. Fram (talk) 14:11, 7 February 2018 (UTC)[reply]

              • My point is, if as an initial step you're going to copy all Wikidata descriptions to the corresponding article talk pages, then before you do that, as a first stage, it makes sense to fix deficiencies and raise those descriptions as far as you can closer to what you are looking for in a systematic way on Wikidata first, because to make those changes on a mass scale is far easier at that stage than later; and to do it in a way that is open to collaboration. If going to do that first draft as a machine process, then do it on Wikidata, because the very design of Wikidata is created to be easier for machine processes like that -- easier to read on a mass scale, easier to write on a mass scale, easier to analyse on a mass scale. Jheald (talk) 14:52, 7 February 2018 (UTC)[reply]

        Wiki projects have different communities and different standards. It would be inexcusably offensive to overwhelm the community at Wikidata to enforce English Wikipedias norms, and it would be equally inexcusable to allow content to be imported against the requirements of English Wikipedia's policies, particularly regarding BLPs, medical information and other things which we hold ourselves accountable for and which may have real life consequences. Using Wikidata just does not cut it. Wikipedians are accustomed to the Wikipedia editing environment and can usefully watchlist their areas of interest. Wikidata is a foreign territory, with foreign customs to most Wikipedians. This is not a fault of Wikidata, it is because they are not Wikipedia. Some of us are both Wikipedians and Wikidatans, but not enough for it to work. Short descriptions are text, not data - they are different in different languges, and the articles they describe are different too. In some cases the articles have different scope, so there is doubt whether the same data item realistically applies. If English Wikipedia has an article that uses the same Q number as another article in another Wikipedia, and the subject is different, which one gets priority? Even Wikidata does not have a procedure for settling such a problem. There is no definitive scope for a Wikidata item as far as I can find out. On Wikipedia we can adjust the short description to match the article as and when the scope changes. Changing it on Wikidata takes no account of how it relates to other articles in other languages, which may change in different directions. · · · Peter (Southwood) ^(talk): 14:13, 7 February 2018 (UTC)[reply]

        I'm not talking about using Wikidata as the final resting places for these descriptions, I'm talking about using it as a staging area where draft descriptions can be created and reviewed on a mass scale -- because you are going to need to create millions of these things. It's going to need to be done and quality-controlled systematically, as a driven process. Just leaving it to haphazard meanderings on individual talk pages is not going to cut it -- if you go that route you still wouldn't have even a fraction of the 5.5 million you're going to need, even after a decade.

        It's all very well for people to talk airily here about what may or may not be acceptable. But will the capability and commitment of the community exist to actually implement an alternative? Talk is all very well, but who will commit all the hard graft to make it actually happen? Will the 10 who voted for it be able to achieve what they have voted for? WMF would be very sensible to see some evidence on that score, before dismantling the existing capability for all its imperfections. Jheald (talk) 14:39, 7 February 2018 (UTC)[reply]

    [ec]Consensus closure is not suppoed to be a count of votes, !votes or any other form of numerical majority. It is supposed to be about the quality of arguments made in support or opposition as well as an indication of general opinion. The closure is not quite my preference, but it does not appear to be wrong. If you think that the closure does not follow the consensus, take it up at the RFC. Otherwise we are held to this decision and we expect WMF to go with it as well.

    I too would welcome an update on the progress of the magic word. At the least I would like to see the syntax defined, so we can start entering short descriptions with the correct format. That would give the WMF the desired information sooner rather than later, and as I understand it, the RFC requires that WMF should stop using Wikidata (short descriptions^{(correction added)}) to identify English Wikipedia articles in any way, anywhere. · · · Peter (Southwood) ^(talk): 13:47, 7 February 2018 (UTC)[reply]

    @Pbsouthwood: "the RFC requires that WMF should stop using Wikidata to identify English Wikipedia articles in any way, anywhere" - no, that's not the question that was asked. There is no such requirement from an RfC. Thanks. Mike Peel (talk) 14:13, 7 February 2018 (UTC)[reply]

    Mike Peel, you are right, I left out short descriptions. · · · Peter (Southwood) ^(talk): 14:31, 7 February 2018 (UTC)[reply]

    Actually we already had an RFC that covered that. Its only because the WMF decided to sneakily not do what was asked that we have ended up at the magic word compromise. What there has been consistently consensus for is for Wikipedia articles to not have associated descriptions that are based elsewhere, edited elsewhere and out of the control of Wikipedia editors, and displayed as if they are part of the Wikipedia article. Either the descriptions for ENWP articles are under the control of ENWP, or they are not displayed. Only in death does duty end (talk) 14:15, 7 February 2018 (UTC)[reply]

    @Only in death: As in this RfC? That was withdrawn, it was never completed. I'm just pointing out that there is not an RfC decision on this, that's all. Thanks. Mike Peel (talk) 14:21, 7 February 2018 (UTC)[reply]

    • It was closed because the WMF promised to stop using Wikidata, it wasn't closed as no consensus. Using the lack of formal closure, caused by the WMF promise, as a reason to claim that that result wasn't decided, seems, well, let's settle for "unfair". And in any case, the RfC now concluded with Show no description where the magic word does not exist which seems to be what Only in death said, "stop using Wikidata to identify English Wikipedia articles". No magic word or blank magic word = no description, magic word populated on enwiki = show enwiki description. There is no room in that conclusion to add a "show Wikidata description" somehow. Fram (talk) 14:26, 7 February 2018 (UTC)[reply]

      • That's a rather creative way of interpreting RfC results (or non-results as the case might be). Mike Peel (talk) 14:30, 7 February 2018 (UTC)[reply]

        • ? Not much creativity involved, actually. If people want to continue showing the current Wikidata descriptions, they will have to add these to our articles (by bot presumably). But the closure of the RfC indicates that we will no longer display the Wikidata descriptions directly on enwiki (mobile, search, whatever). That seems rather clear from the RfC closure. Fram (talk) 15:03, 7 February 2018 (UTC)[reply]

          • That is not at all my understanding of the outcome. Once the magic word is available and in action, then yes. But right now, we haven't got the magic word - and you need to generate a few million descriptions for it before it is turned on the second part of the RfC comes into action... Mike Peel (talk) 16:27, 7 February 2018 (UTC)[reply]

            "you need to generate a few million descriptions for it before it is turned on" Iff that is the case, I predict a riot. No one is going to populate a few million articles with a magic word when this has no effect at all until the WMF may decide that our effort is sufficient, or not. I don't know where you get these ideas, and whether you believe them to be good ideas or not, but this is possibly the worst way to deal with this at all. The WMF proposal was to only switch off the Wikidata descriptions as default / backup for missing or empty magic words after some time and/or number of descriptions had been generated. You propose to provide us with a magic word which won't do anything until millions of them have been added and filled. Which is not what the WMF wants (or at least, not what they say), and not what the RfC outcome wants. And is not helping the discussion at all of course. Fram (talk) 16:50, 7 February 2018 (UTC)[reply]

            • Sorry, I mis-spoke, I've struck the last bit and clarified it. As I've said repeatedly, I think a magic word is a daft idea in the first place, so none of this is a good idea. Mike Peel (talk) 17:10, 7 February 2018 (UTC)[reply]

              Hi all. WMF's intention is to do what we talked about in late December/early January. We're building a magic word -- the Phabricator ticket is phab:T184000, and the developers have started work on it. There are two stages. In the first stage, descriptions posted on English Wikipedia using the magic word will be displayed as the short description for that article. On a given article, if there isn't a magic word or the description is blank (broadly construed, including blank spaces) -- then it falls back to the Wikidata description as a default. The second stage starts when the English WP editors have filled in enough descriptions that it's roughly comparable to the existing Wikidata descriptions (around 2 million descriptions). At that point, we switch to only using the Wikipedia magic-word descriptions, and won't use the Wikidata descriptions as a backup. -- DannyH (WMF) (talk) 19:12, 7 February 2018 (UTC)[reply]

              @DannyH (WMF):--Hmm...In that case, you are not respecting the result of the 2nd part of the RFC or am I missing something? Regards ~ Winged Blades^Godric 03:46, 8 February 2018 (UTC)[reply]

              Oh! I missed your earlier statement--.....we're not going to agree to a course of action that results in the mass blanking of existing descriptions, for any meaningful length of time. Best, ~ Winged Blades^Godric 03:49, 8 February 2018 (UTC)[reply]

              Who is this "we" of whom you speak?· · · Peter (Southwood) ^(talk): 14:07, 8 February 2018 (UTC)[reply]

              @Pbsouthwood:--Obviously, Danny.~ Winged Blades^Godric 09:22, 9 February 2018 (UTC)[reply]

              • All one of them? · · · Peter (Southwood) ^(talk): 13:21, 10 February 2018 (UTC)[reply]

Yes, Danny, we know your intention. Which isn't what the enwiki community wants. Wy is it so unacceptable to get rid of the descriptions if enwiki doesn't want them as is (and will populate them if and when they want to), but apparently it is no problem that mobile viewers lose data from articles (e.g. navboxes and categories)? It seems highly hyprocritical and fundamentally wrong from the WMF to impose their content decisions (which parts can be hidden from view and which parts need to be there at all costs) when that is not the role of the WMF. The WMF should make things available which are up to the communities to use or not, and the WMF should do their best to make sure that content is visible for most users on most devices. If some content is not provided by a project (like enwiki), then the WMF should not provide it from elsewhere, nor should they force the project to provide such content. Fram (talk) 10:13, 8 February 2018 (UTC)[reply]

This brings me back to a question I have asked before, but has not yet been answered. I will try to make it simple and unambiguous, and request a simple and unambiguous answer. DannyH (WMF), Who is responsible for the decision to continue displaying Wikidata short descriptions for English Wikipedia articles on mobile and other interfaces? If it was one person, please provide their name, If it was a committee decision, please name the committee and chairperson. · · · Peter (Southwood) ^(talk): 11:26, 8 February 2018 (UTC)[reply]

Pbsouthwood: There were a lot of people from different teams involved in the decision. The most visible use of the short descriptions is on the iOS and Android apps, so that team was a big part of it, along with other people from the Readers team and Community Engagement. I took the lead on communication and figuring out the compromise solution, so I am the person most responsible for that decision.

Responding to Peter and Fram's questions: The short descriptions are useful for the readers and editors that use them, and we're not willing to mass blank them, even with the RfC consensus. It would be bad for those users, and those products. But I agree that Wikipedia editors should have editorial control over the descriptions, and that's why we're building the magic word, and why we'll switch to entirely Wikipedia-generated descriptions once there are enough that the current users won't notice the change. Sorry for just repeating things I've said before, but it's the same question, so I still have the same answers. -- DannyH (WMF) (talk) 19:35, 8 February 2018 (UTC)[reply]

@DannyH (WMF): Categories and navboxes and so on are useful for the readers as well, but the WMF had no problem with "mass blank" them on mobile view either. Talk pages were nearly inaccessible from mobile view for years as well. It seems like you use that argument only when it suits you, but ignore it otherwise (just like you ignored it here). Fram (talk) 19:41, 8 February 2018 (UTC)[reply]

Fram: That's actually been the subject of some conversations at the WMF as we're working on the annual plan for next year (July 2018-June 2019). We haven't finalized the plans yet, but the mobile and apps teams are talking about helping people edit on both the mobile web and the apps. That means providing more functionality on those platforms, including better notifications and access to talk pages. I'm not sure about categories or navboxes, but I can ask. We'll have a better idea of what the plans are in a couple weeks, and then various teams will be having conversations on wiki about what people need, and how to provide it. -- DannyH (WMF) (talk) 19:54, 8 February 2018 (UTC)[reply]

But meanwhile it wasn't considered a problem to remove this functionality from the readers in mobile view (while adding the rather rubbish "related articles" instead). I'm just trying to understand why if it suits the WMF, it is acceptable to remove content, functionality, helpful links from articles, but when it suits enwiki, it suddenly becomes unacceptable. Fram (talk) 19:58, 8 February 2018 (UTC)[reply]

On a more constructive aspect, I have opened a discussion at Wikipedia_talk:Manual_of_Style#Article_short_descriptions, to consider what we want the short descriptions to look like. · · · Peter (Southwood) ^(talk): 14:55, 8 February 2018 (UTC)[reply]

DannyH (WMF), Would it hinder the developers in any way if we set up a temporary {{SHORTDESC}} on Wikipedia so that we can start populating with the short descriptions? · · · Peter (Southwood) ^(talk): 15:38, 8 February 2018 (UTC)[reply]

There is a fair chance that the syntax will be different: template takes {{SHORTDESC|desc}}, while magic word probably takes {{SHORTDESC:desc}} (a colon instead of a pipe). So any descriptions you would set up would need to be changed anyway. Fram (talk) 15:45, 8 February 2018 (UTC)[reply]

That is a pain, but brings me to another question.

Is there a semi-automated method by which we can work through a set of articles, which would check if there is already a short description, and if not, open the article to edit, suggest the Wikidata short description, and add it on a click of acceptance, otherwise add the magic word syntax in the right place, wait for the user to type it in and save, then move on to the next article? Such a tool could accelerate the process by an order of magnitude. · · · Peter (Southwood) ^(talk): 16:07, 8 February 2018 (UTC)[reply]

Any bot could do it. This was actually what I proposed at the RfC. If you really want a click in the end (I am not sure why, there are too many articles), probably a wizard like Magnus Manske can write it (it would be similar to a Reasonator). I am not sure though people at the Wikidata side would be super happy to write tools which result from a clear rejection of Wikidata.--Ymblanter (talk) 16:15, 8 February 2018 (UTC)[reply]

Oh I don't know, Ymblanter. We're going to get human eyeballs on a lot of descriptions out of this, and with luck a pile of improved descriptions that can be imported straight back to Wikidata. That's quite an upside!

A few thoughts

• What Peter proposes above isn't far off what can be done with AWB, though I've not had that much experience with AWB, and I've never quite worked out if there's a way to give it a list of a articles and a list of strings, if the string to be added is different for each article. A bespoke tool would be a lot more user-friendly however, and (though I'm not a tool-maker) I wouldn't have thought would be too hard to create.
• Nevertheless, 5.5 million is a lot of descriptions to create/review. I would think, as Ymblanter suggests, that some heavier automation would be needed, ie auto-writing some sort of draft description to pages.
• To highlight what's going on, if a description is added to a page, IMO it would be good to also add a section on a talk page, saying what has been added, how desktop people can see it and edit it, perhaps with a templated checkbox that it had been reviewed and considered adequate.
• Such a template is likely also to kick off a healthy discussion process on the more heavily curated pages over the precise text to show. This would be no bad thing, but we should be cautious not to move faster than WikiProjects and editors seeing things across their watchlists can cope with. For individual WikiProjects, the initial set of descriptions added may set off intense discussion, that it would be good not to flood; but after that, once the descriptions have started to become more of a known territory, it should be possible to accelerate.
• Putting a template on each talkpage saying "this is how you change the short description" will be like painting up a target; it will make these descriptions much more high-profile than they have been up until now on Wikidata. It will be important to make sure that anti-vandalism assessment code is ready for this, ie primed to pay special attention to changes to short descriptions, in particular e.g. changes that seem to produce changes that bear no relation to the properties of the corresponding item on Wikidata. Such assessment software will need to have a good idea of the range of what good descriptions look like; and probably will also take time to settle in. Jheald (talk) 16:42, 8 February 2018 (UTC)[reply]
• One further thing, as I wrote on the MoS thread: does anyone have a link to the code that currently produces auto-descriptions when there is no manual description on Wikidata? Looking at this may give a useful typology of cases to consider, and a useful set of initial formats to critique. Jheald (talk) 16:48, 8 February 2018 (UTC)[reply]

• See d:Wikidata:Automating descriptions for a link to Magnus Manske's AutoDesc. This picks up information from the statements in the item entry. StarryGrandma (talk) 19:54, 8 February 2018 (UTC)[reply]
• Jheald, Some good ideas there. The reason I would prefer that the process be semi-automated is that the Wikidata descriptions are very inconsistent in quality, and there are a lot of them that we dont want to import. After all, that is the reason for this whole fiasco. Semi-automated will be slower, but will encourage relatively fast improvement. There will be an ongoing task on WP to add short descriptions to new articles and fix/improve them on old articles, so worth investing some coding time to make a really good tool. One of the functions will be adding a category indicating the presence of the SD, which will help find the pages without them. Talk page notices are a particularly good idea. A short notification of when the description was added and the name of the editor would encourage good practice and due diligence, and make the change known to those not watching the article and who choose not to make the SD visible on desktop view. As to Wikidata copying them back, sure they are free to do it if the new SDs suit them better than the old ones. This may well be most of the time, but probably not all of the time. Many of the unsuitable for WP descriptions look adequate for WD at present. It may even be possible to code the tool to do this function as well, which would be a gain for both projects.· · · Peter (Southwood) ^(talk): 04:46, 9 February 2018 (UTC)[reply]

Getting back to my original question about the possibility of a template. I assume the magic word will do the things that WMF wants it to do, not necessarily the things we want it to do, so there may be some value in a template after all. One which calls the magic word as one of its functions and passes over the short description character string as a variable. Other functions would include adding maintenance categories, and possibly other things. Or am I over-complicating this? · · · Peter (Southwood) ^(talk): 22:34, 9 February 2018 (UTC)[reply]

I'm not sure that's how magic words work -- I'm not sure you can template them. I think it may be that they have to be in the raw wikitext of the page. But it's not something I have ever looked into.

The advantage of a template is that it would be very easy for a bot to convert into a magic word when the time came. The disadvantage is -- would anyone have any interest in it, until it did actually do anything?

If we want to start getting descriptions onto pages before the magic word is available, it's almost the only game in town. And of course it can be used to set categories. A downside is that it is hard to query at scale -- if you want to review a list of the descriptions on a particular set of articles, I think you'd pretty much have to write a scraper -- I don't think there's any other way to get the values of a template for a whole set of pages. That said, {{GeoGroup}} seems somehow to manage to do it, but that may be a very special case.

One alternative, that would allow querying, would be to ask for a new property on Wikidata, specifically for short descriptions in development. But in the current climate, I can see that's not likely to be a runner.

My recommendation then, until the magic word is available, would be to have a new template, but to put it on the talk page, where one could make it fully visible, where it would trigger watchlists, and likely be a focus for discussion. The only thing one would need to do would be to make very sure it didn't get archived by archive bots.

Are you on good terms with any wikiprojects that might consider trialling such a thing? Jheald (talk) 23:16, 9 February 2018 (UTC)[reply]

Jheald, As the most active editor on WP:SCUBA I have been testing it there, I have written about 477 short descriptions using a template {{short description}} coded for the exercise by one of the other major WP:SCUBA contributors, RexxS who is skilled with templates and Lua. The template also adds the article to a maintenance category - . There has been some resistance where articles are tagged for several projects, but this has been minor, and I just leave them for later. The main objection has been that it is experimental and therefore not necessary, and so they can delete it. Less than 1% reversion rate at a guess. At present there is no display on the read view, but it could be used to test display formats.

I am also mildly and tangentially active on WP:MED, as there are some diving articles that are about medical topics, and on WP:OSH, for similar reasons. WP:MED is big and active and high profile, and would probably be very serious about the quality of short descriptions. Some of their more active members are aware of the short description saga and may be sympathetic to trials. Biographies are outside my field of interest and competence, but also a project where the quality of short description would likely be an issue. · · · Peter (Southwood) ^(talk): 13:02, 10 February 2018 (UTC)[reply]

FYI

 – Pointer to relevant thread elsewhere.

Please see Wikipedia talk:Manual of Style#Article short descriptions. While it's on the MoS talk page, it's really a continuation of this discussion, and is primarily about a) the idea of using an en.wp template; b) whether using WD-provided descriptions should be done at all, and if so how/why/when/to what extent/etc.; and c) the inherent difficulties of using descriptions as short as 40 chars. Personally, I think this discussion should be centralized, probably here not at WT:MOS (it has virtually nothing to do with style, but with content), and then particular things eventually broken out for further practical refinement at WP:VPTECH. At some point these ideas have to get more buy-in from the community than just the people who talk about WD all the time, and specific solutions need to be put into place, probably requiring some Phabricator tickets.  — SMcCandlish ☏ ¢ 😼  23:51, 9 February 2018 (UTC)[reply]

I notice that the phabricator ticket specifically by-passes the ability for Wikipedians to specify a blank short description.

If the magic word isn't used on the page, or if the description is blank, then it should show the description from Wikidata.
"Blank" means:
not having any description in the field {{SHORTDESC:}}
just blank spaces {{SHORTDESC: }}
just punctuation {{SHORTDESC:.}}
just non-breaking space {{SHORTDESC:<code>&nbsp</code>;}}
In those cases, it should pull the description from Wikidata.

I consider this an act of bad faith and a clear disregard for the consensus on the part of DannyH (WMF) until a satisfactory explanation is forthcoming. · · · Peter (Southwood) ^(talk): 06:40, 11 February 2018 (UTC)[reply]

In stage one of this process, if {{SHORTDESC: }} blanked the description, then it would be easy for someone to run a bot and put that on every page. I have said consistently that mass blanking of the descriptions is not going to work for us. Once there are ~2 million descriptions on English WP articles, we move to stage two, and at that point any page that doesn't have a SHORTDESC magic word will automatically be blank. This is the same thing I've said throughout the discussion.

Regarding the consensus, I had offered to co-write the RfC with Alsee, so that our point of view would be included. Alsee didn't start writing it, and then Fram went ahead and created the RfC without my input. Still, I participated actively in the conversation, and I expected that my point of view would be included in the consensus. A month into the RfC conversation, I came up with a new proposal for a compromise -- the one that's on that Phabricator ticket. This was belatedly added to the RfC choices as #5, and you (Pbsouthwood) crossed out your original statement and switched to #5 as your preferred choice. Other people didn't change their original statements -- this was a month after the start, and most people had drifted away -- so it wasn't really considered in the final consensus summary. Still, I think this #5 compromise is reasonable and fair, and so did you, as of January 6th. -- DannyH (WMF) (talk) 21:29, 11 February 2018 (UTC)[reply]

@DannyH (WMF): What about disambiguation pages, list pages, category pages, and other pages where the content may be implicit in the name? Jheald (talk) 22:32, 11 February 2018 (UTC)[reply]

Jheald, I was thinking that would be addressed after people had written the article page descriptions and we switch over to just using Wikipedia-hosted descriptions. At that point, all of the category, list and disambig descriptions would disappear, along with all of the other unwanted descriptions. -- DannyH (WMF) (talk) 16:54, 12 February 2018 (UTC)[reply]

@DannyH (WMF): Well, as part of the descriptions creation process, I think it would be good to be able to indicate affirmatively the cases in which no description is the preferred choice, and for that then to take effect there and then. Is there a problem with that? Jheald (talk) 17:04, 12 February 2018 (UTC)[reply]

DannyH (WMF), your understanding of the Wikipedia community and culture is deplorably lacking in someone who is acting as a spokesperson for WMF in negotiations with Wikipedia if you do not understand the workings of consensus on Wikipedia. The fact that I think that option 5 was a reasonable compromise does not override the fact that the RFC was closed as consensus for option 2. If you think the closure was wrong (the closure was reasonable by my assessment, but not indisputably so), you can reopen the RFC, you do not say nothing and immediately proceed blatantly against the consensus. That is the kind of thing that can get you sanctioned on WP, which would not help your work at WMF.

You made your points at the RFC, they were mainly rejected. I do not think that if you had co-written the original question it would have greatly affected the outcome. Better, more timeous replies, and less ignoring the questions and giving partial answers apparently avoiding the issues might also have helped.

Your counter-consensus specification on the phabricator ticket goes beyond simple disagreement into the realm of actively obstructing the preference of Wikipedians to be able to leave out a short description in cases where Wikipedians agree that a short description is unnecessary or even undesirable, as Jheald mentions above.

It also appears that there is a misunderstanding regarding the use of short descriptions. Wikipedians were expecting (to the best of my understanding) that all mainspace articles will be populated with the magic word, not that the magic word would be omitted from some articles to later display no short description. That is an arrangement that will cause endless confusion, as editors will be adding and removing the thing at great waste of time and effort. A magic word present in the article, with a comment to the effect the there is local consensus to the specific short description avoids that confusion and allows easier maintenance categorisation. This you just dismiss without discussion, and do as you please. Not a way to instill confidence in WMF within the community Again one is reminded of superprotect.

You appear to misunderstand the process of bot runs on Wikipedia. Anyone who ran a bot to install blank descriptions across the whole Wikipedia without consensus and specific permission, would immediately face sanctions, and most likely permanantly lose bot operator permission, and the run would be reversed. I doubt that we have that many suicide botters.

There is more I could add, but the wall of text is already uncomfortably high. · · · Peter (Southwood) ^(talk): 06:34, 12 February 2018 (UTC)[reply]

Pbsouthwood, we've been talking about this for a long time, and at the end of the day, you and everybody else on English Wikipedia are getting exactly what you want. The engineers are working on the magic word, which will allow editors on WP to write the short descriptions. Once that's deployed and there's a roughly comparable number of Wikipedia-hosted descriptions, we'll switch over to entirely Wikipedia-hosted descriptions. This is a simple question of timing, and that timing hinges entirely on English WP contributors doing the thing that you're currently working on doing. -- DannyH (WMF) (talk) 16:54, 12 February 2018 (UTC)[reply]

DannyH (WMF), If we do get approximately what we need at the end of this it will only be as a result of constant vigilance and seeking out the deviations and protesting them in public. I will once more appeal to logic and common sense and request that the counter-consensual specification for bypassing a blank magic word to Wikidata be removed from the specification. It is against the requirements of English Wikipedia, and though the added complexity may be small, it is an added complexity to make those tests. We do not want this added dysfunctionality and the developers will have less to code and test without it. You personally will be less resented on Wikipedia, so we all win. Cheers, · · · Peter (Southwood) ^(talk): 17:13, 12 February 2018 (UTC)[reply]

Pbsouthwood and Jheald, what's the plan for how the magic word is going to be populated? One way to do it would be to use that bot to add the {{SHORTDESC:}} to every page, which will be a call-out for people to start filling them in. But if that's how it's done, then honoring those blank descriptions would mean a complete blanking of all descriptions for the users.

I've said many times, before, during and after the RfC, the one outcome that I need to be assured of is that the descriptions should not be mass blanked. The consensus specifically says that is the outcome that you want -- "start with blanks, allowing to fill in manually" and "show no description for blanks". I don't know how I can make it more clear that that the WMF is not going to build that. If that is the thing that you're asking for right now -- to immediately mass-blank every description before people start to fill them in -- then I'm not sure how to make this conversation more productive. -- DannyH (WMF) (talk) 05:26, 13 February 2018 (UTC)[reply]

I was under the impression that WMF would only turn the magic word on when they (you?) arbitrarily decided (Quoting a number of 2 million, and whether or not this was agreed by Wikipedians) that there were enough short descriptions on Wikipedia, not that the magic word would be switched on immediately before we even start adding short descriptions. If this was not your intention, you could try to communicate more clearly. On the reasonable assumption that you would be doing what you said you would, mass population with blank descriptions would have literally no effect on the search display function until the magic word is activated, which you said would only happen when we had put in about 2 million short descriptions, based on your statistically dubious estimate of the numbers on Wikidata. We regard this as a form of extortion, but it would require a major campaign to fight it, which may not be worth the trouble.

Some of us are not keen for inappropriate short descriptions to be copied over from WikiData, others may not care. This probably means that bot runs requests will be watched and debated if there is any likely controversy, so reducing the risk of mass blank descriptions anyway. I am advocating semi-automated runs, requiring a user check on each short description copied or generated automatically from whatever source the user chooses, in the interests of quality assurance. This is still early days, and I cannot predict the outcome.

Whatever bots, if any, are used to add the magic word to articles, they will have to go through bot approval for each run first, We do not allow bots to run wild at the whim of any lunatic.

This conversation would probably be more productive if there was a clear description of what is planned by WMF, not a vague (mis)understanding based on several things stated in various places at different times and subject to personal interpretation and arbitrary movements of the goalposts. Since it is WMF who caused the problem, and will be writing the code to fix it, it would be appropriate if the person running the WMF side would write a clear and unambiguous explanation of what WMF is planning to do, preferably with a timeline, in language that the average Wikipedian can understand. · · · Peter (Southwood) ^(talk): 06:29, 13 February 2018 (UTC)[reply]

Pbsouthwood, unfortunately, you have misunderstood this. I'll explain it more carefully.

The magic word is currently being built. When it's complete, it will be deployed to Wikipedia and will be live. There are two stages after the magic word goes live:

Stage 1: Wikipedia editors will populate the magic word (SHORTDESC) on Wikipedia pages. During that period:

• Pages that have a Wikipedia-written SHORTDESC description -- {{SHORTDESC:American stage actor}} -- will display the new description.
• Pages that don't have a SHORTDESC description will display the Wikidata description.
• Pages that have a blank magic word -- {{SHORTDESC:}} -- will display the Wikidata description.

Stage 2: Once Wikipedia editors write ~2 million descriptions, we'll switch to entirely Wikipedia-hosted descriptions. From that point:

• Pages that have a Wikipedia-written SHORTDESC description -- {{SHORTDESC:American stage actor}} -- will display the new description.
• Pages that don't have a SHORTDESC description will not display a description at all.
• Pages that have a blank magic word -- {{SHORTDESC:}} -- will not display a description at all.
• The Wikidata description will not be displayed on any page.

This is the same plan that I posted in the RfC on December 22 under "WMF two-stage proposal for Wikipedia-hosted descriptions", and it's the plan described in the Phabricator ticket.

What we've been talking about for the last couple days is what happens in Stage 1 when a page has a blank magic word. I hope that this explanation clears things up. What do you think? -- DannyH (WMF) (talk) 19:39, 13 February 2018 (UTC)[reply]