Wikipedia:Village pump (proposals)/Archive 170

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

---

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Adding and using a template called Falseredirect for pages that redirect somewhere else, but need separate pages

Sorry if it isn't the best place to post this, if it's the case, please say me on what page it's better to post it.

Basically, on Russian Wikipedia there's a template that is used in the beginning of a page where another page redirects, but where the said page need a separate article instead of redirecting because its a different topic, such as :
"Page" redirects here. This topic needs a separate article.
This is a very useful template, but I haven't seen it on English wikipedia, the only other languages are languages of Russia, and neither I've seen any template that acts the same way. So where to ask people to implement this template into English Wikipedia? Of course, I can translate this template myself, but it won't be used and will probably deleted. Cappyinator (talk) 10:49, 3 August 2020 (UTC)

We have the template {{R with possibilities}}, but it goes on the redirect rather than the target article. Can you give an example of where this could be useful? If a title shouldn't redirect to another article then surely it's better to write at least a short stub or delete the redirect altogether and make the title a red link? Phil Bridger (talk) 10:59, 3 August 2020 (UTC)

My template is useful for people who will for example automatically be redirected from Super Mario 64 DS to Super Mario 64 (it's how it is currently on Russian Wiki. They'll know that this is a different topic that needs a different article, just like Template:Redirect does fow showing people there's a disambiguation page about other topics of the same name as the redirect. And for Wikipedia editors, this'll show them what page they could create. As for your template, I couldn't clearly see where there is written that a new page can be created instead of the redirect so your template isn't very clear. And also, it shows on a redirect page, which you won't see if you specifically don't go to the redirect page, unlike mine, where both readers and editors will clearly see there's a redirect that needs a separate page.

Cappyinator (talk) 18:33, 4 August 2020 (UTC)

I think the idea is to display a hatnote saying something like "Wikipedia doesn't have an article on [redirected-from title]. You can [piped link to editor|write one]!" It's a bit problematic on this wiki, though: {{R with possibilities}} checks for draft titles and I think we'd want this template to do the same; also, English Wikipedia requires editors to be autoconfirmed before creating articles in main space (but not for overwriting a redirect - still, consensus is already kind of against this). Interesting idea, though. Ivanvector (^Talk/_Edits) 15:12, 3 August 2020 (UTC)

I want more parity between versions. You say the difference is that you need to be autoconfirmed to create articles? If you want either only confirmed users to create articles or you want that people would create articles with draft titles, you could link here : "Wikipedia doesn't have an article on [redirected-from title]. You can [piped link to Incubator editor|write one]!". And also there's many cases where there's a redirect and a separate page needed, because the main page is related and maybe has a section for the redirect, and so creating a red link would be bad.

I'm sorry if I coudn't explain to you properly why this template can be useful, but I think another user from a Russian wiki could explain to you better. Since you were from a wiki that didn't use this template, you would think it's useless, but anyone from a russian wiki would tell to you how useful it is. Cappyinator (talk) 18:49, 4 August 2020 (UTC)

So, if I understand you correctly, the basic idea of this proposed template is to help building some infrastructure for a still non-existent article, which, however, clearly has possibilities, right?

I agree with this. Sometimes, there's a certain momentum needed to get a new article created. Many people, even if they are knowledgeable about a (potential) topic, "feel" that something is missing or not structured in the best possible way, but don't know how or where to start (or only know about portions of the new topic not enough to push a new article above the necessary threshold right from the start, and instead of risking an article to be deleted, they don't contribute what they know about it at all). Others might have a good overview on the needed structure, but are not knowledgeable about a topic (or don't have the time) to write an article about it. While the normal procedure is to first write the article, then build the infrastructure around it, I have made the experience that it is sometimes helpful to do it the other way around: If red links to a named but missing topic get focused onto a single future target name in multiple places this creates more momentum than some randomly distributed red links which happen to be about the same future topic, but don't end up on the same target page name. If the red links get focussed, tools like "What links here?" can be used to sense relevance and context, to find more potential useful material for the article, and seeing a future structure people can already start to better differentiate between the new topic and the existing ones.

You could already do this by just providing a red link as a parameter to one of the various templates for article hatnotes. However, in the current state of affairs, this will likely be removed by other editors who are more focussed on "cleaning up" than thinking about building infrastructure for new articles, unfortunately. If I understand you correctly, that's why you think a dedicated template for such hatnote links with possibilities would be useful, telling editors to leave that red link alone, right? {{Falseredirect}} might not be the best possible name for it, perhaps {{Hatnote with possibilities}} would be a better one.

Thinking this idea a bit further, it might be useful to also have some means to frame normal red links in articles in a special template as well if they are clearly links with possibilities rather than leftover red links from page moves or deletions. Framed this way, it would make editors think twice before removing such red links. Something like {{Link with possibilities}} could do the job (similar to a HTML comment, but more consistent and functional):

Once the corresponding article has been created, these templates could automatically detect this and either switch the displayed hatnote from "Wikipedia doesn't have an article, you can write one here: xyz" to "Don't confuse with xyz" (like {{Distinguish}}) or just mute themselves to look like a normal link (like {{ill}} does) and put the article in a hidden maintenance category, so that the template can be easily found and removed from an article's source code by bots or editors.

Red links are already allowed on disambiguation pages (at least in the German Wikipedia - IIRC, they are not in the English WP, but I would have to look it up) if they point to articles with possibilities (indicated by several links already pointing to the same place per "What links here?").

Something I personally sometimes do is to WP:IAR and add red links to topics which would be relevant in the context of an article to the SeeAlso section, if they don't have an article in the English WP yet, but already have one in another language entity. I use {{ill}} for this. Similarly, I sometimes also do this on disambiguation pages. Although, formally, our MOS does not allow for red links there, I have made quite good experiences with this. Such links are almost never removed - until someone has created an article about the topic in the English WP as well, which typically happens in a year's time after adding such an inter-wikilink.

So, yes, I think such (a) template(s) and a few more remarks about red links with possibilities in our guidelines could be helpful.

--Matthiaspaul (talk) 10:26, 7 August 2020 (UTC)

A particular example of where something like this template could be useful occurs with articles on organisms. When there's no article on a species, misguided editors frequently create a redirect from the species to the genus to which it belongs. ("Misguided" because there's a clear consensus among the relevant wikiprojects against doing this.) This practice makes it look as though the species already has an article, discouraging its creation (as well as being unhelpful to readers of the genus article who want information on a species, but end up back where they started). Peter coxhead (talk) 08:50, 9 August 2020 (UTC)

Universal Audio Articles for English Language Learners and Persons with Disabilities

It strikes me that it would be amazing if we could get a dedicated, designated team of volunteers to start universal narrating of articles so we can present content in audio format for English language learners and persons with visual and/or learning disabilities (and anyone else who enjoys a good listen!) Screen reader technology is nice, but it lacks inflection, pronunciation, and nuance. The current project in this vein is a good start but doesn’t quite go far enough in that it requires the user to request recording.

Profczerwonka (talk) 01:59, 7 August 2020 (UTC)

Profczerwonka, WP:WikiProject Spoken Wikipedia is a thing, and it used to have more volunteers. There are a number of articles that have such recordings, but most are quite out of date. Really we just need to recruit more folks to the project. CaptainEek ^{Edits Ho Cap'n!}⚓ 05:58, 7 August 2020 (UTC)

@CaptainEek and Profczerwonka: I agree that WikiProject Spoken Wikipedia is a good thing, but longer-term, I think we need to look at the bigger picture. Making spoken versions of articles is a lot of work, and they go out of date easily. Machine readings, by contrast, can be done at scale, and their quality is constantly getting better as technology improves. I made a thread at the Spoken Wikipedia talk page about setting up a system to produce machine-read versions of articles without current spoken versions, and it got a positive reception, but I lack the technical expertise to move that initiative forward. {{u|Sdkb}} ^talk 06:42, 7 August 2020 (UTC)

Sdkb, Oooh, I'd be a big fan of that! Although I also lack the technical expertise required, but don't think it would be toooo difficult. All a bot would need to would be to feed articles into a reader, record the output, and turn it into a file that gets appended to an article. CaptainEek ^{Edits Ho Cap'n!}⚓ 06:53, 7 August 2020 (UTC)

While we're waiting for the technology to become available and be scalable, I know that I, and a few other editors, can read in a very robotic voice, so I think we should just get started with it now. They don't have to know it isn't being done automatically; it'll just seem like a beta release version. Mathglot (talk) 09:24, 7 August 2020 (UTC)

I'm flattered you thought of me, Earthling. <beep!><bloop!>EEng 22:03, 7 August 2020 (UTC)

@CaptainEek, Sdkb, and Mathglot: I totally hear you on the scalability issue. I suppose I hadn’t thought of the staleness issue (Articles go out of date quickly.) I am a new editor here, but it occurs to me that the Wikimedia foundation might be a source of, or be able to apply for, grant money to support a scalable machine reading initiative. Otherwise we could continue doing it on an ad hoc basis. Thoughts on drawing their attention to this thread?

Profczerwonka (talk) 13:00, 7 August 2020 (UTC)

• These all sound good. I only joined Spoken Wikipedia as a project last year (by which point it was already pretty quiet), but I decided I'd commit to making a spoken version of any article I wrote. Obviously it'd be better if I worked on other articles, too, but there's a scaling issue, and recording and then editing recordings for my two longer articles each took a long time. I suspect the WMF might be very interested in offering a grant if someone has a viable proposal for machine-handling it. Pinging a member or two of relevant staff members (that is, not grants, but anyone who handled engagement or accessibility) Nosebagbear (talk) 13:20, 7 August 2020 (UTC)
• Have you considered involving the accessibility people? Several of them use screen reader software - for example Graham87 (talk · contribs) uses it all of the time - and should be able to assist here. --Redrose64 🌹 (talk) 18:43, 7 August 2020 (UTC)
  • @Redrose64: As one of the least audio-oriented blind people I know, I'm not exactly qualified to say much about this except to mention Pediaphon. In general, inflection and nuance in speech synthesisers aren't as important to screen reader users as they are to the wider population. Graham87 02:54, 8 August 2020 (UTC)
• Procedural note: We may want to move this to the idea lab, since there's lots of good discussion happening here, but this is more at the brainstorming stage than a finished proposal. {{u|Sdkb}} ^talk 20:27, 8 August 2020 (UTC)
• Check out meta:Wikispeech for a text to speech project and mw:Extension:Wikispeech for its technical documentation. For this to work we need massive amounts of structured multilingual data and audio files, and meta:Lingua Libre is the project for that. See commons:Category:Lingua Libre pronunciation for what the project does for audio files, see their main website https://lingualibre.org/ for a Wikidata front end for recording, editing Wikidata, and posting to Commons all at once, and check out the d:Wikidata:Wikidata Lexeme Forms to see how this is sorted. For anyone interested there is a lot to do, including playing to sort individual words, documenting what the project is and why it matters, and what all these various pilot tools do. The Spoken Wikipedia project is important also to get data about usage and integration into Wikimedia projects. Blue Rasberry (talk) 14:35, 9 August 2020 (UTC)

Guideline or not?

PLS see Wikipedia talk:Reference desk/Guidelines/Medical advice#‎Marked as a guideline page.--Moxy 🍁 18:38, 9 August 2020 (UTC)

CentralNotice banner for Alumni and Mentors of Russia 2020

Dear colleagues, please comment on CentralNotice banner proposal for Alumni and Mentors of Russia 2020 article contest. (20st August 2020 → 10th November, all IPs from Russia, WPs only, 1 banner impression per 2 week). Thank you. JukoFF (talk) 17:15, 10 August 2020 (UTC)

Wikipedia:Move review proposed for renaming

I'm notifying this board that there is currently a move request to change the title of Wikipedia:Move review. The discussion can be found here. I'm informing this board since this proposal could, in one way or another, affect the scope of what this page is used for (given that this page has several monthly subpages), and since there was an RfC which happened over a year ago which occurred to change the scope of the page, but the current title may or may not adequately reflect the scope change. Steel1943 (talk) 18:38, 10 August 2020 (UTC)

Implement an easier way to view a user's contributions

To view all contributions of a user (if they haven't put a link of their contr. in their signature) you have to go to Special:Contributions/ and type in their name. My proposal is we put a new "Contributions" button next to the "Talk" button of a User page. --  ApChrKey   ^Talk 21:50, 7 August 2020 (UTC)

If you enable WP:POPUPS in your preferences, you can just hover on a signature, hover over user, then click Contributions. (Popups are wonderful for many purposes.) Schazjmd (talk) 21:53, 7 August 2020 (UTC)

Wow those pop ups are really useful.. They can go several layers down. --  ApChrKey   ^Talk 22:04, 7 August 2020 (UTC)

Huge time-saver if you use a watchlist. You can just hover on each diff to see what changes have been made without having to go to the article. Enjoy! Schazjmd (talk) 22:09, 7 August 2020 (UTC)

@ApChrKey: There's already a "User contributions" link in the sidebar under "Tools". If you want it as a tab anyway, a user script can easily do that. (If you want that but aren't sure how to write one yourself, let me know and I'll build it for you.) Jackmcbarn (talk) 21:55, 7 August 2020 (UTC)

Thank you. I didn't know that. --  ApChrKey   ^Talk 21:58, 7 August 2020 (UTC)

ApChrKey, one of my faves is WP:SUPERLINKS Ed talk! 22:46, 7 August 2020 (UTC)

Many users also put a contribs link in their signature. That doesn't really address the problem here, just noting it since nobody above me appears to have done so. Ivanvector (^Talk/_Edits) 14:21, 10 August 2020 (UTC)

ApChrKey: Since AMC, the mobile interface (and Minerva skin in general) gained a toolbar at the top of the page, which on a main User page has a contrib's icon (the languages icon is hidden to make space for it). The Timeless skin has a contributions icon (or link, depending on page width) for any User: or User talk: page or subpage. It's to the right of History and separate from the Page Tools drop-down. The Desktop Improvements project for the default Vector skin is considering to move Page Tools (or "Article tools") out of the left sidebar and into a separate menu, but I'm not sure what their thoughts are about the placement of User Contributions. Pelagic ( messages · Z ) – (05:55 Tue 11, AEST) 19:55, 10 August 2020 (UTC)

@ApChrKey, Jackmcbarn, Schazjmd, Ivanvector: I posted a topic about this proposal at the DI project on MediaWiki Wiki. Pelagic ( messages · Z ) – (07:24 Tue 11, AEST) 21:24, 10 August 2020 (UTC)

CHINESE SIMPLIFIED VS TRADITIONAL

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Please add the ability in Mobile Apps to select either simplified or traditional script. It would make life easier for Chinese readers — Preceding unsigned comment added by 2606:a000:101c:c6f5:b048:991f:7d1:5749 (talk) 22:05, 11 August 2020 (UTC)

Hi 2606..., this is not something we can set on the English Wikipedia - you can place a feature request on phabricator. — xaosflux ^Talk 13:38, 12 August 2020 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

What are proposals?

Are we getting married or somethang? Here's a proposal for you: explain shortly at the top of this page what this page is all about! --Palosirkka (talk) 09:38, 13 August 2020 (UTC)

There is an explanation box at the top of this page. 331dot (talk) 09:48, 13 August 2020 (UTC)

There is a box but it says nothing about what proposals are. --Palosirkka (talk) 09:52, 13 August 2020 (UTC)

It certainly does, right below the first sentence. 331dot (talk) 09:54, 13 August 2020 (UTC)

The box is a mess. "Before submitting: Proposed policy changes belong at Village pump (policy)." That's not a coherent sentence but a word salad. --Palosirkka (talk) 10:10, 13 August 2020 (UTC)

Palosirkka, this is already done and well documented on both the village pump main page and other locations. There's nothing for us to do here. Ed talk! 09:48, 13 August 2020 (UTC)

No it's not Ed. And I'm not talking about the main page or some other page but this very page. --Palosirkka (talk) 09:52, 13 August 2020 (UTC)

Palosirkka, "New proposals are discussed here." - I think that sums it up enough. Either way, you can edit this page and change it yourself? I don't know why exactly you needed a proposal here for something that's as trivial as a page edit, and really then this thread belongs on WT:VPR Ed talk! 10:01, 13 August 2020 (UTC)

I would gladly do it myself if I only knew what they are. --Palosirkka (talk) 10:07, 13 August 2020 (UTC)

I am pretty sure you are capable of using a dictionary. Ed talk! 10:17, 13 August 2020 (UTC)

Ed6767, I don't think it's necessary to be snarky. The box really doesn't give any guidance as to what types of proposals belong here. It details the types of proposals that don't belong here, so is the presumption that this page is for any proposals that don't belong somewhere else? Is it intended for a specific class of proposals (my guess: "ideas for changes that apply to the Wikipedia project as a whole, but do not involve policies, projects, software..." etc)? I watch this page to stay informed, but never really thought about its purpose, and I think Palosirkka asked a reasonable question (if a bit flippantly). Schazjmd (talk) 16:30, 13 August 2020 (UTC)

I believe a proposal in the sense used here is an idea for a change to this wiki that has been discussed enough to be fairly specific and reasonably thought through. The idea should already have been discussed in the Idea Lab or perhaps a talk page elsewhere. The intro to the page lists other places that are better for specific types of ideas. — GhostInTheMachine ^{talk to me} 10:40, 13 August 2020 (UTC)

The best evidence for "what a proposal is" can be found by reading 'proposal' aired on this page, following discussions, and participating in the process. No need for a definition when you should gather experience first. Use analogy. Evaluate the participation of other editors and their reactions to your ideas and arguments. — Neonorange (Phil) 23:20, 14 August 2020 (UTC)

This is an odd conversation to say the least. Regardless, the OP makes a good point (echoing what Schazjmd said) about the top of the page not explaining what kind of proposals belong here. Perhaps some examples of passed past proposals at the top would help. I myself am style unsure on how this proposal page can differ or overlap with changes made on the WT:MOS, that should at least be clarified at the top. Suggesting that the reader reads through proposals to understand what this page is, is like suggesting readers read through questions in the tea house to understand that it is a place for questions, rather than just telling them that at the top! Aza24 (talk) 00:46, 15 August 2020 (UTC)

Yeah, I don't think it's clear what type of proposals are meant to be proposed here. The brief descriptions at the top of the main Wikipedia:Village pump are a bit more helpful, but then the broad strokes there paint a picture that's not all quite really followed in practice. I think it will be more accurate to state that the village pump is the place to bring up pet projects (or pet peeves) that a proposer believes are too important to be discussed in the appropriate venue, and the choice of page – idea lab, proposals, or policy (in this order) – is largely dependent on how important the proposer believes themself to be. – Uanfala (talk) 17:36, 15 August 2020 (UTC)

Arbitrary break

Yikes, the threading here is a mess, so resetting with a break. But I agree with GhostInTheMachine. It's certainly an issue that some very half-baked ideas end up here, but I'm not sure there's much we can do about it, since the types of editors likely to propose half-baked ideas are also the sort not to read instructions (even in an editnotice). Regarding criteria, a few come to mind:

1. Concrete and specific: You need to have a solution in mind, not just say "let's find a way to solve problem X". (Ironically, this means this thread doesn't qualify.)
2. Developed: Especially for major proposals, there needs to be some clear work put into it, evidenced by a quality framework, prior work at the ideas lab or elsewhere, etc. Any thread that just gets dropped here with e.g. "Let's deprecate portals" and nothing else should be nipped before it spirals into a mess. (This problem affects RfCs, too, where it's very hard to terminate one that's non-neutral/unneeded/inappropriate/etc. once it gets going. I can't think of a single instance where people !voting "abort" actually got an RfC aborted.)
3. Has broad implications: Most proposals should be hosted at specific project pages, etc., not the pump. Giving a {{Please see}} notice here should usually be sufficient, especially for more minor issues.

Regarding enforcement, is there a gadget available for easily moving threads from here to the idea lab or elsewhere? That would help.

Also, there's another dynamic at play here besides the newcomer spam: more experienced editors who want attention given to their still-undeveloped idea, and know that this page is a lot more closely monitored that the idea lab, which has fewer watchers and more junk to wade through. I've had some good experiences at the idea lab, but also times (e.g. recently) when I've had to basically plead to get a discussion going, and that wouldn't have been needed if I'd come here. Unfortunately, strict enforcement here of the criteria I propose above would actually make that dynamic worse, since there would be even more junk heaped on the idea lab. Perhaps we need a gadget there to transfer to the Teahouse.

The core problem is that we have no good way to enforce whatever rules/norms we have about appropriate discussions to start and ways to start them. From RfCs to WP:CENT to Talk:Donald Trump to here, if we could find a way to address that, we'd be a lot better off. {{u|Sdkb}} ^talk 21:24, 15 August 2020 (UTC)

I can't think of a single instance where people !voting "abort" actually got an RfC aborted See here. There have been other instances. --Redrose64 🌹 (talk) 22:50, 15 August 2020 (UTC)

Redrose64, fair enough. Our system can handle utterly obvious cases, but for anything short of that, it often breaks down. {{u|Sdkb}} ^talk 09:38, 16 August 2020 (UTC)

Add basic HTML syntax-checking on user signature field changes

Can we please add an HTML syntax check every time someone attempts to save a customized user signature? (Maybe even on preview; give them a chance to fix it.) I just added this comment at a User talk page, asking the user to fix their signature, and it's not the first time I've addressed a user about this topic.

The more obvious HTML mistakes, a missing font-end tag that turns an entire Talk page red, or a missing </sup> that leaves the whole page tiny and superscripted, are obvious enough that someone finds them and fixes them quickly. Less obvious errors like this one, leave the preview page syntax highlighting broken. And because they are more subtle and don't garble the rendered talk page but only the wikicode syntax highlighting, they stay around for much longer. This user's signature has been breaking Talk page syntax highlighting since 2014, but until now, I guess we never had a Watchlist Talk page in common that I edited, so I never noticed before. To be clear: I don't doubt that this is an innocent, good-faith mistake, but there's no reason for it not to have been caught at the outset.

I don't care much about fixing up all the pages where this must have happened before, but I don't see why we should let users just put whatever they want into their signature, and leave it to the community to mop up the mess in case of problems. HTML syntax checkers have been around forever, and are robust even for long, complex web pages. We shouldn't allow a Talk page to be inadvertently screwed up, because a custom user signature has invalid HTML syntax. Is it too much to ask to put the signature input field through the same level of validation before we allow it to be saved? Thanks, Mathglot (talk) 01:39, 19 August 2020 (UTC)

Mathglot, are you aware of mw:New requirements for user signatures? --AntiCompositeNumber (talk) 01:45, 19 August 2020 (UTC)

@AntiCompositeNumber:, I wasn't aware. For reference here, I'll just add that the relevant section there for this issue is #Proposal: signature validation requirements, and that it's being tracked in T140606. They do talk about certain types of errors including unbalanced <font> tags and others, and if I'm readiing it right, it would also catch the error I identified above as a misnested tag, so that's good news. Thanks for the link. I'm not a stranger to mediawiki (or to other sister projects and wikipedias) but my main presence is at en-wiki; and I'm not sure if mediawiki needs to advertise themselves more widely at sister projects, or if I need to widen my scope somehow so as not to miss such things. In any case, thanks for that link! Mathglot (talk) 03:18, 19 August 2020 (UTC)

Mathglot, That page doesn't make it exactly clear, but the relevant changes are deployed currently (see mw:New_requirements_for_user_signatures#Outcome). The only exception is the "obsolete HTML tag" lint error, which is not enforced on signatures. If you try to edit your signature to introduce a lint error, you should find that you can't. You can also use my tool to check someone else's signature for problems, in this case https://signatures.toolforge.org/check/en.wikipedia.org/Gourami%20Watcher. --AntiCompositeNumber (talk) 04:12, 19 August 2020 (UTC)

AntiCompositeNumber, that's really great to know, thanks! And it's good to have my analysis of where the problem lay in GW's sig confirmed by your tool, which nailed it. (I'm not bothered about obsolete HTML tags, as most browsers are forgiving about such things.) Mathglot (talk) 05:05, 19 August 2020 (UTC)/

It was raised at the technical village pump by Whatamidoing (WMF). See Wikipedia:Village pump (technical)/Archive 182 § Changes to custom signatures and Wikipedia:Village pump (technical)/Archive 182 § Custom signatures changing on Monday, where Whatamidoing said users with invalid signatures would be gradually contacted. isaacl (talk) 10:35, 19 August 2020 (UTC)

Looks like I need to clock in for a minute.  ;-) Yes, it's already happening. For enwiki, we started with ~1200 active editors (=edited during the last 30 days) with some error. Most of them have a problem called "plain-fancy-sig" that just means you have an unnecessarily ticked box in your prefs.

I and a couple of volunteers have individually contacted around 100 editors here so far, and several hundred others have fixed their sigs on their own (or stopped editing, unrelated to this. Our attrition rate for new editors is very high, so newbies who created a sig in June and then stopped editing aren't in the list any longer, and the newbies from July onwards can't make the same mistakes). https://signatures.toolforge.org/reports/en.wikipedia.org will probably update tomorrow, and we'll see how much difference it made. If the message seems to be working, then we'll contact the rest, in smallish batches.

If you are interested in helping/answering questions, then mw:New requirements for user signatures/Help is the central point for instructions. At this wiki, we're asking people to take their questions to WT:SIG, so that's the page for helpful folks to be watching. So far, it's received no questions, which I hope means that our instructions are clear.

The timeline for ending the "grandfather" period is officially "When I get around to it" (I'm the bottleneck, and the devs have agreed to wait on me). It's probably months from now (not weeks, not years). Less than 900 of the current 126,740 active registered editors need to even think about this, and about 700 of them have an error that's solved by unchecking a single box in their prefs. Whatamidoing (WMF) (talk) 04:08, 20 August 2020 (UTC)

Allow fair use non-freely licensed photos of politicians

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I recently attempted to make an edit to the page of Laura Loomer. She is a congressional candidate and a public figure. Currently, her picture is that of a blurry YouTube screenshot, and I sought to improve her page by replacing the screenshot with a clearer image. Unfortunately, there are no photos available of Ms. Loomer that have been explicitly released as free license or public domain. There are however, photos of Ms. Loomer that have been released on her campaign website, and can be inferred to be released for public distribution.

I had two admins (@MelbourneStar and @GorillaWarfare) explain to me that Wikipedia policy says that we cannot use images of living people unless they are explicitly free license. But I don't think this makes sense for a public figure, especially someone currently running for political office. In one edit, I suggested a picture of Ms. Loomer posing with a sign that had the words "Laura Loomer for congress." But because the photo was not explicitly marked as public domain, it is unusable on Wikipedia.

Just for a second forget about current policy. If Ms. Loomer did not want that photo distributed, would she have had it taken and posted on her campaign website? It makes no sense. I have been informed that this is long standing policy since possibly 2006, but perhaps it is time for fresh ideas? Other online publications like the New York Post and Politico use these kinds of photos routinely without fear of violating copyright. Why can't Wikipedia do the same? Even if it cost some money to access these photo databases, Wikipedia isn't broke. Surely they could possibly set aside funds.

Another thing to consider with politicians: Doesn't Wikipedia have a responsibility as the premier free Wikipedia to ensure the most concise and clear information possible? Especially for would be voters? Need I remind anyone that Wikipedia is banned in many dictatorships? Free, and clear information is vital to democracy. People look to Wikipedia for important information. And that includes politicians. If a politician does not have a clear photo, this could cause confusion in the poll booth.

Please reconsider this policy.

(SamMontana (talk) 04:36, 21 August 2020 (UTC))

This is pretty much non-negotiable as the requirement that we use free images of living persons comes from the WMF in the non-free resolution that applies to all Wikimedia projects. And we are not her to serve as a political platform for any politician, at all. If a running candidate is notable, we will give them encyclopedic coverage, not coverage as you would see as a candidate. Not our place at all do be doing that. --Masem (t) 04:45, 21 August 2020 (UTC)

No per Masem. Sorry, but as said above this is pretty much not really up for change, given that living persons can have a free photograph taken of them at a future date. – John M Wolfson (talk • contribs) 04:50, 21 August 2020 (UTC)

@John M Wolfson: But at a later date could be too late. This could affect the election. (SamMontana (talk) 04:55, 21 August 2020 (UTC))

SamMontana As said earlier, we are not here to influence elections in any particular direction (not to mention the idea of a Wikipedia article affecting an election's outcome striking me as implausible and risible), and I would highly encourage you to acquaint yourself better with our principles regarding fair-use and especially living persons (we are also not here to right great wrongs, actual or speculative). I have the feeling that this will be closed soon as it doesn't appear to have a chance to pass. – John M Wolfson (talk • contribs) 05:14, 21 August 2020 (UTC)

• Oppose — Wikipedia doesn't get into the business of promoting political candidates, period, so talk of uploading images to satisfy voters is a non-starter. The solution to the problem put forward by SamMontana would be for the political candidate to release their photos under a free licence – not change our longstanding policy which ultimately upholds the Third Pillar. —MelbourneStar☆^talk 05:21, 21 August 2020 (UTC)

Wikipedia has no firm rules. (SamMontana (talk) 05:42, 21 August 2020 (UTC))

Sorry, a longstanding and reasonable policy. Either way, I don't see it changing anytime soon, so I'm not sure if bludgeoning the process will be helpful. —MelbourneStar☆^talk 05:50, 21 August 2020 (UTC)

Oh look I can cite "longstanding" rules too. The principles and spirit matter more than literal wording, and sometimes improving Wikipedia requires making exceptions. WP:5P5 (SamMontana (talk) 05:56, 21 August 2020 (UTC))

Even with some famous politicians it is difficult to find a decent free image of them for the infobox. They could easily solve this problem themselves by releasing one image that is CC licensed; some politicians have done this. However, the WP:NFCC rules cannot be bent and non-free images in the infobox are usually a no-no.--♦IanMacM♦ ^{(talk to me)} 05:56, 21 August 2020 (UTC)

Why can't it be bent? Wikipedia has no firm rules. Politicians aren't known for being tech savvy. (SamMontana (talk) 06:00, 21 August 2020 (UTC))

If we start paying for these sort of photos, why not pay for everything else? Or rather why would anyone continue to give stuff for free? If we were going to change policy it would be more logical to drop "fair use" altogether - politicians at the least would then start releasing openly licensed images as a matter of course. I'm actually not against the principle of the Foundation paying for content, I'd just rather they did so by buying reference books for active Wikimedians in countries without good public libraries (some of this already takes place). ϢereSpielChequers 06:18, 21 August 2020 (UTC)

• Oppose: no non-free/fair-use pictures of living people, a picture can be taken or be made available. And if that is 'too late' then that is not Wikipedia's problem. If it is a problem for the neutral display of the elections, then go out there and get a picture, or remove the other pictures even if they are available. And yes, you can argue that Wikipedia does not have firm rules, but Wikipedia does have firm rules. Most rules on Wikipedia are not set in stone, but some of these rules are. One group of those are our policies that have legal implications, another set are the rules set out by WMF. --Dirk Beetstra ^{T C} 11:10, 21 August 2020 (UTC)
• Close discussion I'm a little surprised myself that politicians and public figures who can certainly afford a professional photographer often don't care to make good photos of them freely available for all purposes, but that's their problem. As this proposal relates to a political campaign described by reliable sources as a publicity stunt with almost no chance of succeeding, I recommend closing this discussion as fruitless. Blythwood (talk) 11:30, 21 August 2020 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Manual Tag: "Error in edit summary"

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

In the idea lab, there was discussion regarding allowing users to edit their edit summaries, which admittedly doesn't isn't a very good idea. However a few other users (credits to [primarly] Majavah, xaosflux, and Sdkb) mentioned the possiblity of creating a new Manual Tag that would indicate "Error in edit summary". To quote Majavah:

On fiwiki there is a tag for "error in edit summary" that you can add to your own edits if you made a mistake in the summary. When adding a tag you can add a reason for tagging the edit which is shown on the tag management page. We could probably try a system like that here too. – Majavah talk · edits 19:34, 11 August 2020 (UTC)

Obviously this is hard to imagine, so I have created page on this proposal: Wikipedia:Editing Tags. Note: although this proposal features photos on how to change any tag, it is specfically about just adding a feature to add "Error in edit summary", unless there is consensus to allow editors to edit all tags. P,TO 19104 (talk) (contribs) 21:39, 24 August 2020 (UTC)

• Although this could be useful, I have doubts about whether it's needed enough to justify the complexity it'd introduce or effort it'd take to introduce it. Errors in edit summaries significant enough to require marking aren't that common, and they can normally be handled well enough by subsequently making a dummy edit. {{u|Sdkb}} ^talk 21:44, 24 August 2020 (UTC)

Seems unnecessary. Just follow up with a WP:DUMMY comment, and rewrite the summary the way you wanted to say it. I haven't seen a case yet, where this would somehow not be sufficient remedy.

Bear in mind the following much more serious use case as a comparand, and even this does not require such a tag. It's the case of adding copied/translated text to an article; this involves a legal requirement in the Edit summary, namely, per Wikipedia's licensing requirements, it is obligatory to leave an attribution statement for added content that is copied or translated from another article. Not suprisingly, this isn't always followed, whether inadvertently, or not. The remedy for missing attribution is spelled out in WP:RIA, which is to simply supply the legally required, but missing attribution via a dummy edit. If that's good enough for the legal team, it should be good enough for an editor who forgot something in some previous edit summary. Mathglot (talk) 22:12, 24 August 2020 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Add 'last edit' column to xtools articleinfo

Please add a 'last edited' column to the xtools utility "articleinfo", and/or other method to help determine whether a user is a good candidate to be pinged to a current discussion at the article's Talk page. (I.e., pinging editors who haven't edited in a year is a waste of time and effort.)

I not infrequently use the very handy xmflabs tool, "articleinfo" (sample) to make up a ping-list of "concerned editors" to be notified about a discussion at the article Talk page. However, that could be up to 20 or 30 editors (top ten by edits, byte count, or authorship) so I usually drop any user from the list with no contributions in the last three months (or whatever threshold). But that takes up to 40 or 60 clicks to determine. A new date column in the tables in the Top editors section containing the date of the editor's last contribution to Wikipedia would make this a lot easier. (Even better: a font-height sparkline showing their contribution pattern of the last 6 months or so, if any, plus last-date.) Thanks, Mathglot (talk) 21:02, 24 August 2020 (UTC)

@Mathglot: "xtools" isn't really an "English Wikipedia" thing - it is a private tool and the maintainers of it may do with it as they please. You can see the list of maintainers here and they accept feedback for it here, you can also try to place a feature request here. — xaosflux ^Talk 15:36, 25 August 2020 (UTC)

@Xaosflux:, Thanks! T261247. Mathglot (talk) 19:23, 25 August 2020 (UTC)

Reworking Wiki app's "today in history" algorithm.

Hello, I recently got the wiki app and have immensely enjoy browsing it. I particularly like the "Today in history section." However, I find that the vast majority of articles it shows are, for lack of a better word, bad news. I would say that most days more than half of the articles are about terrorist attacks, railway accidents, or natural disasters. I personally don't find these articles very enjoyable to read. Please forgive my massive ignorance if the inner workings of Wikipedia, I have no idea how to solve this problem, or if this is the correct forum for suggesting this change. I am curious if anyone else has been bothered by this and if there would be a way to alter what articles in general appear in the "today in history" section. Thanks in advance, That01Llama — Preceding unsigned comment added by That01Llama (talk • contribs) 13:54, 21 August 2020 (UTC)

@That01Llama: These aren't generated by an algorithm; they're chosen by Wikipedia editors like you. The one in the home screen seems to be drawn from the same list on the main page, and the ones you get from pressing "More on this day" come from the day-of-year articles like August 21. The main page list criteria are at Wikipedia:Selected anniversaries; the day-of-year list criteria are described at Wikipedia:Days of the year. I would encourage you to find pleasant or enjoyable events that meet those criteria. Vahurzpu (talk) 17:34, 21 August 2020 (UTC)

That01Llama, this gets at a larger issue with the concept of news, which is that negative developments are more likely to be sudden (and thus able to be pegged with a date), whereas positive developments happen over time. Perhaps adding more birth dates of important people would be able to help counter this a bit. I'm not all that familiar with WP:OTD, though; you'd get more helpful feedback from posting there. {{u|Sdkb}} ^talk 22:11, 22 August 2020 (UTC)

You reach my point perfectly @Sdkb, I would gladly add more positive events myself, but the truth is, I would hardly make a dent unless I spent all my time editing. It sounds like, correct me if I am wrong, there are standards for what can be tagged as a "of the day" article. perhaps this standard could be edited slightly to encourage more positive editions in future. ever, it is still unclear to me if anyone else is bothered my this. If no one else is then I say, "if it ain't broken don't fix it!" — Preceding unsigned comment added by That01Llama (talk • contribs) 21:54, 25 August 2020 (UTC)

Remove the Draft namespace from $wgNamespacesWithSubpages

In the main namespace, there are no subpages, so / is just a character in an article name like any other. Pages in the Draft namespace are generally supposed to have the same name as they would in the main namespace once accepted, so it doesn't make sense to have subpages there either. For example, Draft:Andreas Hedlund (arranger/orchestrator) shouldn't be considered a subpage of Draft:Andreas Hedlund (arranger, and Draft:9/11 Review Commission shouldn't be considered a subpage of Draft:9. And to my knowledge, there's no legitimate, intentional subpages in use in the Draft namespace. As such, I propose that we have the Draft namespace be removed from $wgNamespacesWithSubpages. Jackmcbarn (talk) 04:12, 10 August 2020 (UTC)

Current pages under consideration: quarry:query/47324. Plenty of intentional ones there, so I guess this comes down to what you consider to be "legitimate". —Cryptic 05:19, 10 August 2020 (UTC)

Almost all of those look like they're either (1) using slashes in a way not meant to be subpages, (2) leftovers from someone moving "User:Foo/Bar" to "Draft:Foo/Bar" instead of directly to "Draft:Bar", or (3) a result of people using the Draft namespace for things other than drafting articles. Would you consider any of those legitimate, or do you think there's some other group that I'm underestimating the number of? Jackmcbarn (talk) 23:25, 10 August 2020 (UTC)

I think that if I were editing a lot of draft articles at once, I might want to name them Draft:RexxS/Foo, Draft:RexxS/Bar, etc. to keep them together, but that would probably work almost identically if subpages were disallowed. Of course I could simply use my own userspace for the drafting if I really wanted subpages, so I can't see any problem with removing draft namespace from $wgNamespacesWithSubpages. Can we be sure what will happen to the current set of draft pages containing the / character when the configuration is changed? --RexxS (talk) 17:41, 11 August 2020 (UTC)

@RexxS: Nothing at all will happen to drafts that currently have a slash in their title. They'll still be accessible at their current names. Also, users will still be able to make drafts with those titles. The only thing this change would do is change the output of {{BASEPAGENAME}} and {{SUBPAGENAME}}, get rid of the automatic breadcrumb links to parent pages, etc. Jackmcbarn (talk) 20:53, 11 August 2020 (UTC)

@Jackmcbarn: yes, I'd figured out those that you mentioned, it's just the "etc." that I was concerned about --RexxS (talk) 21:01, 11 August 2020 (UTC)

@RexxS: Having checked the MediaWiki documentation, I see only two other effects: any relative links will break, so "[[/bar]]" on "Draft:Foo" would now link to "/bar" instead of "Draft:Foo/bar", and moving drafts would no longer show an option to move their subpages. Since drafts are supposed to eventually become articles, and those kinds of links wouldn't be valid in mainspace, I don't consider that much of a loss, and I also don't think we move drafts with their subpages very often (if ever). Jackmcbarn (talk) 21:19, 11 August 2020 (UTC)

Might Draft: space be used for a round-robin move of a page with subpages, e.g. a template complete with /doc, /sandbox and /testcases, or a portal? Certes (talk) 21:28, 11 August 2020 (UTC)

@Certes: you could just as easily use your own userspace for the temporary pages. --RexxS (talk) 21:36, 11 August 2020 (UTC)

@Certes and RexxS: WP:ROUNDROBIN currently recommends using a subpage of Draft:Move for that purpose, a behavior which is mirrored by the popular pageswap user script. I'm not sure whether that functionality requires access to the MediaWiki-side "move subpages" option (which would be the only thing truly affected by this change, as far as I can tell), but it is certainly worth noting that this change may disrupt the currently accepted flow for round-robin moves. Nathan2055^{talk - contribs} 01:54, 23 August 2020 (UTC)

@Nathan2055: We would be foolish to allow the currently suggested route for doing round-robin page moves to become a block to implementing a useful proposal. It is trivial to update advice when circumstances change. Nevertheless, for single page moves, the current advice would work identically whether draft-space or user-space were used as the temporary location. An admin who is contemplating moving a page along with all its subpages would need to understand the limitations of the namespace that they were using for the temporary pages. Perhaps we could agree to use User:Example/Move as the root for such moves. --RexxS (talk) 17:30, 23 August 2020 (UTC)

• Support Users who want to organize their drafts using subpages can use their userspace; users who want to do round-robin page moves with subpages can use userspace or project space; the remaining use cases would be invalid in mainspace so I don't see a loss. DYK has lots of problems with slashes because its namespace has subpages when main doesn't, so this would likely make some dev's life easier in the future too. — Wug·a·po·des​ 20:47, 20 August 2020 (UTC)

• Support: makes complete sense to me. It will prevent stuff from breaking when working on drafts in draftspace. Aasim 02:12, 26 August 2020 (UTC)

• Support It makes sense to have spaces used for such similar purposes work the same way. · · · Peter Southwood ^(talk): —Preceding undated comment added 08:09, 28 August 2020 (UTC)

Blanking expired editnotices

Notification of a discussion at Wikipedia talk:Editnotice proposing maintenance cleanup of expired editnotices by blanking, here. ProcrastinatingReader (talk) 14:08, 28 August 2020 (UTC)

Second Wikipedia Blackout??

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

In case you do not know, US transactions with TikTok and WeChat will be banned soon. I just watched a video by Vox [1] about how such a ban poses a threat to the open Internet. I was wondering should we black out Wikipedia on the day the site gets banned? We did this in 2012 when Congress was considering SOPA and PIPA. I think raising awareness of this issue may help raise issues about the current threats in the United States to the open Internet.

"But it is Chinese apps getting banned, not Wikipedia!" - firstly, this is in the United States, a country that has for a long time embraced the open Internet and secondly, the Internet landscape across all countries is changing rapidly to embrace censorship and block freedom of speech. If we decide to black out Wikipedia for a second time, how long should we do it, what pages should be blocked (if any), and when should we stop the blackout? We want a free and open Internet. Sure not everyone likes TikTok, but if TikTok is banned in the US, who will be next? Google? Wikipedia? We do not know. And while it may be two Chinese apps, this will have long-lasting effects on how we view the Internet.

I am not making this proposal lightly, I recognize the amount of disruption it may cause to readers, editors, and the like. If this gets turned down, I will completely understand. After all, we are not supposed to promote a cause first, but I think given that we have done so before in 2012 means we could do so again. This may be a case of WP:IAR that we can invoke just this once.

If we were to black out Wikipedia a second time, I would suggest it be blacked out from 16 September to 18 September affecting all mainspace and portal pages except pages related to censorship and the threat the open Internet has. I recognize it may cause a lot of disruption to people accessing online resources, but it gives us what us Wikipedians want: a free and open Internet where we can access content freely and safely. We do not want websites blocked because people use them to organize sellouts or boycotts or to get revenge for COVID-19; by blocking content, it greatly impacts Freedom of Information.

I do not want this to sound super political, but an open Internet is what us Wikipedians have been fighting for for the past 19 years. We do not want paywalls or government censorship of Internet content; we want the ability to freely access and communicate information when needed. Aasim 09:30, 30 August 2020 (UTC)

• Strongly Opposed to any and all blackouts... for any cause. Wikipedia is not a venue for activism. It is not a place to right great wrongs. We must maintain a NEUTRAL point of view. Blueboar (talk) 12:49, 30 August 2020 (UTC)
• Oppose per Blueboar. Jerm (talk) 12:54, 30 August 2020 (UTC)
• Oppose this effort to RGW. It isn't even a certainty they will be banned(they may be purchased). 331dot (talk) 13:00, 30 August 2020 (UTC)

• Oppose- this is not the same as the SOPA/PIPA nonsense. Reyk _YO! 13:07, 30 August 2020 (UTC)
• Blackouts should be reserved for potentially existential crises, considering the huge negative impacts they have on readers. Using them for anything else cheapens them. – Teratix ₵ 13:09, 30 August 2020 (UTC)
• Oppose I'm not opposed in principle to political action as a project when something directly threatens our work. But "some app" that teenagers use to share dance videos is pretty daggum far down the list of threats. GMG^talk 13:15, 30 August 2020 (UTC)
• Oppose I am not opposed to any blackout, but they should only be used when there's an existential threat to Wikipedia (or potentially a sister project, if such a division could happen). Given that en-wiki opted against a blackout on the EU copyright amendments, it's going to take a truly drastic action to trigger another blackout. Nosebagbear (talk) 14:20, 30 August 2020 (UTC)
• Oppose. This would be seen as a political protest, and we really need to stay out of politics. -- RoySmith (talk) 14:24, 30 August 2020 (UTC)
• Oppose While there are existential risks at play with the TikTok/WeChat bans, they presently are very specific and do not directly threaten WP's model. Something like the various Section 230 laws and EOs being thrown around do, but so far its hard to do what affect they have so no need yet to cry wolf. --Masem (t) 14:30, 30 August 2020 (UTC)
• Strong oppose per Blueboar. ―Mandruss ☎ 14:35, 30 August 2020 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Add ESRB/CERO/PEGI rating to video game listings.

As the name suggests, it would be very beneficial to add the game's rating to the right side information panel.

This could also have the added advantage of linking back to the ratings page (because CERO A, B, C, etc to me is very confusing unless you look at their meanings/age range).

As there are many systems around the world, maybe either a regional setting based on site translation (like UK only seeing PEGI, Germany only seeing USK, etc), and having the .com article contain the main release areas (usually Japan, North America, and Europe). --2600:1702:260:9100:C184:A0D6:6368:8E56 (talk) 05:27, 29 August 2020 (UTC)

They used be included but were removed by consensus years ago Template talk:Infobox video game/Archive 11#Propose removal of ratings section.. Any proposal to add them again would need to explain what changed since that discussion and WP:VG should be informed of this discussion.--67.68.208.64 (talk) 13:40, 29 August 2020 (UTC)

We remove them because there are so many, not all games get them, and that no other media that has ratings (like film and TV) also includes them. If the rating is of importance (like for being banned in a country) we'll cover it in the body. --Masem (t) 20:47, 29 August 2020 (UTC)

The worldwide aspect makes this such a non-starter for me. A worldwide game is rated on several different boards (and they do get changed over time). As Masem says if a game has anything particularly notable about its rating, it can be prosified. Best Wishes, Lee Vilenski ^{(talk • contribs)} 07:39, 30 August 2020 (UTC)

Oppose strongly The ratings provide little in context. The only time they provide value is when there's controversy surrounding it and the articles for those games usually have those details described. – The Grid (talk) 14:20, 31 August 2020 (UTC)

Move protected topicons

Do we really need them? I've always thought they're a pretty useless icon to have, and it just adds bloat. Almost nobody is trying to move these articles, the icon is just clutter and should be removed imo. Wild example, Frank Sinatra. If it's the categorisation we need, we can keep the template/bot as now, and just edit {{pp-move}} to remove the topicon part. ProcrastinatingReader (talk) 17:52, 27 August 2020 (UTC)

Agree. {{u|Sdkb}} ^talk 08:51, 31 August 2020 (UTC)

• Remove. The menu does not offer the move option (if you do not have the permission to move the article), which has to be enough of a clue should somebody try to move it. There is a small logic for having the protection status (maybe with the reason stated) as one of the items at the start of the talk page. — GhostInTheMachine ^{talk to me} 09:22, 31 August 2020 (UTC)

  The move menu offers the option if you can move the page. A page can be move protected at, for example, the extended confirmed level, leaving the option to move it available to you but not newer editors. ~ Amory (u • t • c) 10:13, 31 August 2020 (UTC)

  I think that's what Ghost was getting at? That one can only see the move button if you have the permission to move it. ProcrastinatingReader (talk) 12:47, 31 August 2020 (UTC)

  Indeed, thus: the move button is a reliable indicator of whether or not you can move a page, but not a reliable indicator of whether a page is move-protected, which is what the icon indicates. Similar for "view source" vs "edit" for edit protection. ~ Amory (u • t • c) 18:30, 31 August 2020 (UTC)

  Ah, I follow now. Does that specific case matter, though? I mean, almost all editors (and certainly 99.9% of readers) don't really care if a page is move protected, regardless of whether they can move it. Maybe an editor here or there does (and they can click "page information"), and such editors would usually be regular editors of the page, but imo it doesn't justify showing that useless icon to every single editor & non-logged-in reader. If should be shown at all, I think it should be opt-in (by means of a gadget, or so), rather than default for all. ProcrastinatingReader (talk) 19:37, 31 August 2020 (UTC)

  I've not expressed an opinion, just pointing out that the two are not interchangeable as they do not convey the same information; whether it matters is up to you. Readers can never move a page (assuming readers==not-logged-in), so the icon is actually the only way to convey the information. Again, I analogize to "view source" for edit protection. ~ Amory (u • t • c) 00:12, 1 September 2020 (UTC)

  so the icon is actually the only way to convey the information what about clicking "Page information", eg [2] ProcrastinatingReader (talk) 11:00, 1 September 2020 (UTC)

Globally locked users should have their usernames in strikeout style

There's a gadget (Special:Preferences#mw-prefsection-gadgets / Appearance / Strike out usernames that have been blocked) which strikes usernames if they've been blocked. It seems (obvious) to me it should do the same for globally locked users. Has this been discussed before? Is there some reason it doesn't, other than it hasn't been implemented yet? -- RoySmith (talk) 13:22, 1 September 2020 (UTC)

RoySmith, there's a slow discussion/request at MediaWiki talk:Gadget-markblocked.js#Globally locked and blocked users Cabayi (talk) 13:54, 1 September 2020 (UTC)

Ah, cool. I've opened T261752, as suggested in that thread. -- RoySmith (talk) 14:08, 1 September 2020 (UTC)

Flag edits for review

Discussed a bit at Wikipedia:Village pump (idea lab)/Archive 32#Flag edit for review? where I was encouraged to bring my idea here to see whether there might be community consensus. My idea is that we establish, similar to the thanks functionality, the ability to flag edits for review by other editors. This could be useful in cases where an editor sees a problematic edit but doesn't have the time to address the problem properly, or when an editor sees an edit that they feel is potentially problematic, but they don't have the experience or confidence to know for certain and don't wish to stick their foot in it with an inappropriate revert. Flagged edits could be highlighted in watchlists, and perhaps captured for review in other manners as well. There could also be a mechanism whereby editors could unflag edits that they believed to be comfortably unproblematic.

Beyond tagging other editors' edits for review, this functionality might more easily allow editors to ask others to review their work. I'm unsure how much this might actually be used in such a capacity, but it doesn't seem like a bad idea. As an example, I've sometimes tried to edit tables but haven't been able to get them looking the way I intended. Flagging my edit would be a quick way to get the attention of other editors.

It was suggested at the linked discussion that this could be technically accomplished without significant difficulty thusly: "extend the changetags right to more users (admins + rollbackers?) and create a new tag named "flagged for review"(?)".

There are some obvious potentials for problems here, which were also discussed at the idea lab: for instance, it might be easy enough to harass another editor by flagging their edits, and enabling this functionality might make editors less likely to "push the button" themselves. In the end though, I'm not sure there's a good way to establish whether this enhancement would be abused enough to be a concern without making it available and seeing how it goes.

I welcome other editors' opinions on this; thanks for your time! DonIago (talk) 14:31, 25 August 2020 (UTC)

• @Doniago: I don't like the idea of adding a tag or a template in the hopes that another volunteer will take on the work. I think that it would be better instead to revert the potentially problematic edit and then start a discussion on the article's talk page, following WP:BRD. Or not revert it and post on the talk page about it. If you don't have time to do even that much, then just come back to it later when you can be WP:BOLD and fix whatever might be wrong. There is also WP:RCP recent changes patrol that is watching for problematic stuff. RudolfRed (talk) 16:45, 25 August 2020 (UTC)

• Doniago, we already have a feature like that. It is called Pending Changes. When this is enabled, all edits must be approved before they are visible to readers.

I have edited wikiHow, a separate wiki, and they do just that. But the reason why they can do that is because their community is small enough that it is easy to revert vandals. But on Wikipedia, we have 10-40 edits per second. If all of those edits had to be reviewed before hand, then it would create an unnecessary burden on editors.

We do have anti vandalism bots revert potentially problematic edits and we do have ORES which shows edits that likely need review, but we do not force every single edit to be patrolled. That would create a huge burden on editors managing backlogs. In theory, we could do that, but in practice, we don't. Aasim 18:25, 25 August 2020 (UTC)

I think you misunderstood me; my proposal is for a manual feature that would allow human editors to tag edits as potentially problematic. I'm not proposing any sort of backend process to automatically tag edits as needing review. DonIago (talk) 18:51, 25 August 2020 (UTC)

I think they are saying what is the point of that if you can just undo edits. Emir of Wikipedia (talk) 21:20, 25 August 2020 (UTC)

And his response is that there are non-clear edits where someone doesn't feel confident undoing (even undoing and starting a discussion) but thinks someone else might be better able to make a discussion. I'm personally unsure whether the positives outweigh the negatives of reducing number of clearcut action. Nosebagbear (talk) 21:23, 25 August 2020 (UTC)

The German Wikipedia has enabled something like "Pending changes"/"Flagged revisions" as well. It differs in the details from our configuration. Either way, the proposal here is kind-of-the-other-way-around, changes are published by default, but could be flagged for review (without unpublishing them until reverted) if someone finds them questionable. So, it's on a middle ground between the extremes. I like that. --Matthiaspaul (talk) 18:39, 28 August 2020 (UTC)

• I would like to see something along these lines. As a gnome, my watchlist flags many changes on topics I know little about. Today, for example, an IP changed the ethnic origins of several dances, which is suspicious but not obviously wrong. I've left a message at a Wikiproject in the hope that someone with a clue will check, but the process might be smoother if there were some sort of flag I could wave. Certes (talk) 22:08, 25 August 2020 (UTC)

Certes, if I remember correctly, admins have the ability to edit tags for a particular diff. That means if there are two bad edits, they can mark it as vandalism. Bots can do the same. But it would be nice if this can be expanded to rollbackers so we can apply appropriate tags to an edit. Aasim 22:34, 25 August 2020 (UTC)

The flag might be most useful for non-admins; something an ordinary editor can use to say "please can an expert take a look at this?". If it's for admins only then it might still be useful, but possibly not worth bothering to implement for a small audience who already have other methods available. Certes (talk) 23:31, 25 August 2020 (UTC)

• I'm skeptical of this idea because it's not clear what the limits on such a feature would be. Without clearer guidelines on when it would be appropriate to assign an edit a vague "needs review" tag, I fear it would lead to a similar situation we saw with {{cleanup}}, which is an article maintenance tag that reads simply, "This article may require cleanup to meet Wikipedia's quality standards". For many years some editors placed this extremely vague tag without providing any elaboration on how the articles needed cleanup. This was clearly undesirable, and in 2012 a request for comment finally made the |reason= parameter of the tag mandatory. On a similar vein, this proposal does not seem different from the creation of an inline version of {{cleanup}}, which is undesirable if there is a more specific tag that would better inform why the content needs attention, e.g. {{citation needed}}, {{dubious}}, or {{POV statement}}. See also Template:Inline cleanup tags for more of these alternatives. Mz7 (talk) 01:25, 26 August 2020 (UTC)

I agree that implementing the cleanup template without requiring clarification was a misstep. That said, I don't think the reasons why one might find themselves wanting to use this tag can be easily pigeonholed into existing or possibly new templates; if they could be, I'd be advocating for the creation of a new template right now. :)

As an arbitrary example - I'm reviewing my watchlist, and I see a film article listed on it. The diff shows that an editor has restructured some existing text addressing the film's reception, and added information regarding how great (or terrible!) several well-known film directors considered the film to be. Is this information appropriate for addition to the article? Yes, because they're well-known film directors and their opinions matter. No, because they aren't known for being film critics and their opinions don't deserve more weight than others. Maybe, because it is multiple film directors weighing in on a classic film. I'd like to dig through this, but one of those life circumstances comes up that requires I step away for an unknown duration. There isn't time for me to start a cogent Talk page discussion, and there isn't really an appropriate template that immediately comes to mind. If I can flag the edit, then even if nobody else gets to it anytime soon, it will still be outstanding, and perhaps I myself will see it.

I hope this is helpful! I agree with other editors in that I'm not really sure how great an idea this is or whether the potential cons outweigh the pros, but it seemed to merit a hearing at least. Cheers! DonIago (talk) 17:24, 26 August 2020 (UTC)

• I believe Huggle has similar functionality, but that would only really appear to blatant vandalism (which is basically the purpose of Huggle). As far as this functionality goes, it would require development effort, and as everyone knows: you're only going to get the dev time to implement a non-trivial feature if you top the Community Wishlist for 3-4 years in a row, then wait another 3-5 years for resource allocation. Even then it's a maybe. So realistically, probably not happening. Closest we could get to this is a userscript which provides a button to send an edit into a central repository (like WP:CCI), or just an easier way to send an edit to a certain Wikipedian's talk page for them to look at. But I imagine the functionality would quickly get overwhelmed, to be honest. ProcrastinatingReader (talk) 20:41, 26 August 2020 (UTC)

  @ProcrastinatingReader: This doesn't require any development time as the infrastructure already exists. The only changes needed is the extension of the changetags right to user groups other than admins (which is trivial) and creating a new tag (which can done locally by an admin). The only thing that's really required here is the community consensus. – SD0001 (talk) 10:18, 31 August 2020 (UTC)

  SD0001, if I understand correctly, giving those changetags rights also allows people to remove tags? example url, and see rights: Add and remove arbitrary tags on individual revisions and log entries (changetags). I don't think it's possible to unbundle that functionality, and obviously we don't want to allow people to be able to remove tags. Whilst we could sidestep it (eg a bot reverting any removals of tags that aren't this tag, or patrollers viewing the log for tag changes), I still indifferent about it. A better way may be to 'tag' revisions using a script (add into Twinkle, perhaps?) which adds a hidden template to an article with revisions as its parameters. A bot compiles a list of such revisions (ie, transclusions of the template with specified revisions). ProcrastinatingReader (talk) 11:27, 31 August 2020 (UTC)

  Meh, if someone has the right to add tags, it is natural to let them remove tags as well. I don't see what's controversial about that. "Tagging" revisions using a script creates a new entry in the page history, plus the tag would have to be removed as well which clutters the history. OTOH by using the native tagging feature, we're only cluttering the tag log which no one is looking at. – SD0001 (talk) 11:48, 31 August 2020 (UTC)

  SD0001, what I mean is: the issue is that they'd be able to remove existing tags (like editor used, mobile, etc.). Removing the tags they've added is fine, but not the other tags. ProcrastinatingReader (talk) 12:16, 31 August 2020 (UTC)

• I like this proposal, in particular if the flagger would be able to specify a reason from a predefined list of possible reasons, or even to leave a visible comment, so that it would be easier for other editors to know what they should be looking for.

There is some potential for abuse, so we should allow this only for logged in users beyond some threshold, but the threshold should be reasonably low so that many users could use it. It could also be useful to select if the review-tag should be publicly visible or only for personal use, listed in a special internal list for later review (when time allows).

The alternative today is to improve on an edit (ideal, but often not possible due to lack of time), revert it or open a talk page thread, but the later two options often create unnecessary stress and drama for issues that could be solved in much more subtle, relaxed and friendly ways given enough time and man-power to look at an edit.

--Matthiaspaul (talk) 18:39, 28 August 2020 (UTC)

I imagine adding a predefined list would make this more technically complex, but I'm not sure whether it would be significantly more complex. I'm not sure about a visible comment, as at that point you could pretty much make a dummy edit. Agreed on limiting it to logged-in users. As newer editors are perhaps more likely to rely on this functionality were it available, I concur that a low threshold would be nice as well.

My feeling is that a review-tag should be publicly visible so that other editors can review as well and possibly address the issue...or if they feel there's no issue, untag the edit.

Thanks for your thoughts! DonIago (talk) 19:18, 28 August 2020 (UTC)

The facility to specify a reason also already exists, see Special:log/tag. – SD0001 (talk) 10:22, 31 August 2020 (UTC)

I'm concerned that this could become a "troll's charter". Following a user around flagging everything they're doing, or flagging an edit because you disagree with a political or other stance, or maybe an MP or similar could flag an edit which is a truth they're inconvenienced by. What safeguards are there to stop edit tagging becoming manipulative? doktorb _words^deeds 10:02, 2 September 2020 (UTC)

Besides the fact that that would be harassment and a blockable offense? DonIago (talk) 13:51, 2 September 2020 (UTC)

Talk pages

On the talk pages of articles, it is often said "The talk page is for discussion of the article in Wikipedia, not for general discussion of the subject". However, if one reads what is said in talk pages, quite often the talk gets to be on the subject more than the article. Apart from abolishing talk pages altogether, which would be quite a radical proposal, should we allow discussion of the subject? Vorbee (talk) 06:05, 4 September 2020 (UTC)

• At first take, I would say no. The guideline is a viable tool for intervening in disruptive discussions at talk pages. If anything, it should probably be upgraded to a citable policy instead of scrapped. VanIsaac_WS^cont 06:17, 4 September 2020 (UTC)
• This has always puzzled me. If I want to seek opinions on whether to add something to the article then this must result in discussion of the subject, more so than the article. If I want to suggest that someone with the requisite subject knowledge might add something to an article then ditto. Etc. Downsize43 (talk) 06:59, 4 September 2020 (UTC)

• I think the issue's about to what extent some users might arrive at an article talk page and start a discussion about the subject (offering opinions, treating the page as a forum), compared with when a specific, content-related thread widens in scope to become more of a general discussion. I agree that wider discussion of the subject is often inevitable and, most importantly, it can be beneficial to a genuine content-related discussion, because context is often needed rather than focusing on the one point in isolation. I've seen editors shut down the more blatant chat variety, citing WP:NOTFORUM (#4), which is very sensible. Unless there are some pressing examples, I'd say the guideline works well and is applied well. JG66 (talk) 07:19, 4 September 2020 (UTC)

Thank you for your kind and helpful comments. I see this issue is already discussed at Wikipedia: Perennial proposals, under Section 3.4. Vorbee (talk) 07:48, 4 September 2020 (UTC)

Synchronising short descriptions and Wikidata descriptions

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Should a bot synchronise short descriptions and Wikidata descriptions? Mike Peel (talk) 21:34, 6 August 2020 (UTC)

Hi all. Enwp recently gained 'short descriptions', which is "a concise explanation of the scope of the page" (for the background, see the links at Wikipedia:Short_description#History). These are currently a local override for the English language descriptions from Wikidata for 2.3 million articles (1/3 of the articles here), but this may change soon so that only the local descriptions are used (removing them from 2/3 of articles). I think that it is important that the short descriptions and the Wikidata descriptions are kept in sync as much as possible. That is both because the descriptions are most visible on enwp, but also because the English Wikidata descriptions are used in many other places, in particular (from my point of view) in the infoboxes in Wikimedia Commons categories. As such, I am proposing four options for bot tasks to synchronise them, namely:

1. On Wikidata, option D1: If there is no English description from Wikidata, then import the short description from English Wikipedia
2. On Wikidata, option D2: If Wikidata has an English description, but it doesn't match the English Wikipedia short descriptions, then replace the Wikidata description with the enwp short description
3. Here, option E1: If there is no short description here, then import the English description from Wikidata.
4. Here, option E2: If the short description here does not match Wikidata, then replace the short description here with that from Wikidata.

I started a discussion on Wikidata about the first two, which you're welcome to participate in. There are also discussions on both bot proposal pages. I initially started a thread here at Wikipedia_talk:Short_description#Copying_short_descriptions_to_Wikidata, but discussions on Wikidata led to the bot proposal here, and discussion there in turn suggested an RfC. I assert that these descriptions are too short to be eligible for copyright (which could be an issue since we use CC-BY-SA here but CC-0 on Wikidata) - I've emailed WMF legal to confirm this.

I know that this is a controversial discussion: this thread, and the thread I started on Wikidata, are aimed at starting discussions about how we keep things in sync. I am open coding to up other cross-wiki bot scripts if needed. I think it is in the best interests of both projects to work together. What do you think? Thanks. Mike Peel (talk) 21:34, 6 August 2020 (UTC)

Survey

I would support D1 and E1 as they are just importing what is available. D2 and E2 could result in a better description being replaced, so a solution to prevent that would be needed. Emir of Wikipedia (talk) 21:38, 6 August 2020 (UTC) (please  mention me on reply; thanks!)

@Emir of Wikipedia: Is there a way to automatically tell which one is better, or would it need a human to check it? Thanks. Mike Peel (talk) 21:48, 6 August 2020 (UTC)

Better is somewhat subjective, so it would have to be human probably. Emir of Wikipedia (talk) 21:52, 6 August 2020 (UTC)

• Support D1 & E1; oppose D2 & E2. Copying to fill empty slots is fine, but automated overwriting is a recipe for fierce conflicts. --BrownHairedGirl (talk) • (contribs) 21:46, 6 August 2020 (UTC)
• Comment on D1 and D2: These are Wikidata content decisions for the Wikidata community to decide. Has the Wikidata community delegated its decision-making authority regarding English-language Wikidata descriptions to the English Wikipedia? – Jonesey95 (talk) 21:57, 6 August 2020 (UTC)

  Indeed, which is why I said "I started a discussion on Wikidata about the first two, which you're welcome to participate in." Thanks. Mike Peel (talk) 11:20, 7 August 2020 (UTC)

• Partial Support of E1: Some of the descriptions are poorly written, and others are far too long to comply with our guidelines. I would support importing a limited set of short descriptions for certain categories of articles, like animal/plant species and footballers, where the descriptions can be checked for appropriate length and parsed against category membership here at en.WP. Oppose E2, because local short descriptions are usually better than those at Wikidata, as has been shown at the Wikidata discussion linked above. – Jonesey95 (talk) 21:57, 6 August 2020 (UTC)

  Jonesey95, Do you have any suggestions on how to identify acceptable short descriptions from Wikidata for this purpose? It could be a useful option if it is sufficiently reliable. Cheers, · · · Peter Southwood ^(talk): 10:47, 7 August 2020 (UTC)

  I have populated a few thousand short descriptions, and some categories of articles appear to be pretty consistent in their quality. Sportspeople of various types tend to have reliable short descriptions, as do fossils, for example. A human could identify a parent category on Wikipedia like Category:Association football players, or dig down into a subcategory like Category:English footballers (22,000 articles). Within those categories, exclude articles that already have a short description, then run a report that shows the Wikidata description for each article. A human could look at a report on 1,000 articles at a time, manually eliminate pages with bad Wikidata descriptions, and do a batch import of the rest. It wouldn't be an automated bot process, but I think that once you got the system set up, it would be quick to process many thousands of articles per hour. You could ask on the project page for likely categories. In footballers alone, you could probably add 100,000+ short descriptions in a couple of days. The same process could be used for species, books, movies, and other items where the Wikidata bot that created descriptions had an easy time processing the lead sentence (or whatever information it used). – Jonesey95 (talk) 16:02, 7 August 2020 (UTC)

  Jonesey95 That would make it semi-automated, in that there would be an editor taking the responsibility for checking the batch. I support that in principle. · · · Peter Southwood ^(talk): 08:01, 28 August 2020 (UTC)

• Partial support. D1 and D2 are a matter for Wikidata; if I were more involved there I'd support D1 but have reservations about D2. E1 is good in principle but risks importing vandalised or Wikidata-specific descriptions (made-up example: "philosophical concept; for the verb use Q12345 instead"). Oppose E2, but perhaps we should report cases somewhere. Is there value in maintaining a list/category/whatever of descriptions which deliberately differ between enwiki and Wikidata, and downsizing D2/E2 to "find and report differences not on that list"? Certes (talk) 22:14, 6 August 2020 (UTC)

  Someone is a step ahead of me. See also Category:Short description is different from Wikidata, Module:SDcat and WT:Short description#Adding tracking categories. Certes (talk) 23:23, 6 August 2020 (UTC)

  If we do adopt E1, for some or all pages, we should tag imported descriptions (hidden category:Short description imported from Wikidata?), so we can gradually go through them, improve if necessary then remove the tag. Certes (talk) 11:08, 11 August 2020 (UTC)

• Strong oppose E2, as it defeats the point of the introduction of {{short description}} entirely. * Pppery * _{it has begun...} 22:37, 6 August 2020 (UTC)

  @Pppery: How would you suggest we resolve those differences? Thanks. Mike Peel (talk) 23:01, 6 August 2020 (UTC)

  A tracking category could be used to find articles with short descriptions different from the Wikidata short descriptions. The Shortdesc Helper could be used by editors to import (with or without modification, based on WP's guidelines) or export (with the Wikidata community's consent) the better description. – Jonesey95 (talk) 23:20, 6 August 2020 (UTC)

• I've split my !votes into separate lines to make tallying easier for the closer:
  1. Strong support D1, E1 as obvious improvements. We can remove redundant descriptions like "List article" once the Wikidata link is turned off.
  2. Weak support D2 because it's more likely that enwiki will have a better description than wikidata, since there are many more active editors and far fewer articles/items on enwiki than on wikidata.
  3. Weak oppose E2 for the reason above. These are weak, because I recognise that there will be many exceptions to the general case, and some care will be needed to implement any overwriting. --RexxS (talk) 22:57, 6 August 2020 (UTC)
  • @RexxS: How would you propose that we resolve the differences between enwp and Wikidata in the cases of D2 and E2? Thanks. Mike Peel (talk) 23:00, 6 August 2020 (UTC)
    • @Mike: Do a short run if either gains consensus, then analyse every single one of those replacements manually. Wait a couple of days for reaction and criticism. If it's not too bad, rinse and repeat a couple of times before any large-scale work. --RexxS (talk) 23:07, 6 August 2020 (UTC)
      • @RexxS: I'm happy to do short runs, and to resolve any issues that are raised. My main worry is an absence of consensus. Thanks. Mike Peel (talk) 23:40, 6 August 2020 (UTC)
• Comment – does the result of an en-wiki Rfc have any bearing on what Wikidata decides to do? I can hear Lydia's voice saying, "Not happening." This Rfc may be pointless. Mathglot (talk) 23:16, 6 August 2020 (UTC)
  • @Mathglot: I think you missed that there are parallel discussions on Wikidata and on enwp. If we can't work together, then we're screwed. Thanks. Mike Peel (talk) 23:44, 6 August 2020 (UTC)
    • Meh... There has been a distinct lack of cooperation between the two projects for a while. Both seem to be doing OK. I don’t think either is screwed. Blueboar (talk) 00:17, 7 August 2020 (UTC)
      • WP:NODEADLINE. We will be. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:38, 8 August 2020 (UTC)
• Wikidata and Wikipedia.en are separate projects, and do not NEED to be in sync.
  Ideally I would support E3 - we don’t pay any attention to Wikidata, and write our own short descriptions. However, I do realize that this would be extremely labor intensive, so (begrudgingly) I would accept E-1 - as long as we can subsequently amend any descriptions if we wish to. I would oppose E-2. Blueboar (talk) 23:36, 6 August 2020 (UTC)
  • This is the status quo for the last couple of years. Not so much labour intensive as most people probably still don't know about them and don't have the tool that makes them easy. Changing them at any time is also easy with the gadget. Making the gadget default would probably accelerate the process quite a bit.· · · Peter Southwood ^(talk): 13:54, 7 August 2020 (UTC)
• Oppose: The original error was someone assuming that Wikidata item-descriptions and EnWiki article descriptions were (or should be) the same or interchangeable. Wikidata item-descriptions and EnWiki article-descriptions serve different purposes, and under different policies. Wikidata can and should have descriptions that do not belong here, and we can and should have descriptions that do not belong there. It would be disruptive to pressure either community to make them the same. (Importing Wikidata descriptions may have been acceptable as part of a one-time process&cleanup had Wikidata-descriptions been shut off immediately, but obviously that did not happen.)
  1. D1 - Out of scope. It is an internal matter for the Wikidata community.
  2. D1 - Out of scope. It is an internal matter for the Wikidata community.
  3. E1 - Oppose:
     • A bot should not overwrite (or potentially editwar) deliberately blank descriptions.
     • The Short description helper gadget makes it trivially easy to import Wikidata descriptions, after human review considers the Wikidata version to be appropriate for Enwiki purposes and under local policies&guidelines, and they consider it an improvement. We shouldn't be importing stuff without consideration of whether it belongs here at all.
  4. E2 - Hard Oppose. It would make more sense to propose rolling back the local system completely, going back to automatic display of Wikidata descriptions. Spoiler alert: That will not get consensus. There was overwhelming consensus to kill the original system of displaying Wikidata descriptions here. Alsee (talk) 01:56, 7 August 2020 (UTC)

  There is no such thing as "a deliberately blank description". When the short description is missing or empty, the software provides the Wikidata value instead, which is out of our control. If we imported the Wikidata value into a previously blank short description, we would lose nothing and gain the ability to edit the short description to fit our policies and protect it with our anti-vandalism measures. --RexxS (talk) 16:53, 7 August 2020 (UTC)

• Oppose any bot editing, especially E2. If Wikidata would like to import EnWP descriptions, thats fine by me, and I'd support that, but its really up to WikiData folks. But I don't think we should be importing Wikdata descriptions. If you use the shortDescription tool, you can already do that, and the WikiData descriptions are almost always machine generated garbage. They are very quick to make, and I add a short description to every article I visit. Most don't have WikiData descriptions when I create new descriptions anyway. E2 is highly problematic in my view: it would make vandalism of short descriptions easy, cause edit wars, and be all around not good. CaptainEek ^{Edits Ho Cap'n!}⚓ 05:55, 7 August 2020 (UTC)
• Thanks Mike Peel for raising this as a discussion, but have to agree with Alsee that D1 and D2 are out of scope for the en-WP community to decide, and E1 and E2 should be Opposed as (regrettably) too open an invitation for inaccuracies and crosswiki vandalism. Shortdesc additions are progressing well on en-WP, let's just let that continue in its current form. -- Euryalus (talk) 06:02, 7 August 2020 (UTC)
• Strongly support syncing as a general concept. Wikidata descriptions and en-WP short descriptions are fundamentally the same thing: short descriptions. Are there occasional instances where they might properly diverge? Sure. But does that mean they should be totally split, leading to probably thousands of hours of duplicated (i.e. wasted) editor effort to create the same thing in two separate places? Absolutely not.

It's important to connect this to the bigger picture here. The success of the Wikimedia movement is fundamentally predicated on having enough people to do the work. That's the main reason we delete non-notable pages. Whenever we choose to fork, that literally doubles the amount of work to be done, which when you multiply by 6 million, comes out to a gargantuan cost in editor effort. Thus, preventing forks needs to be one of our highest priorities. Worse, once a fork has been made, re-integrating becomes harder and harder over time. I recognize that there are a lot of challenges to doing so here, both because of the initial reasons for the fork and because of the hurdles from the divergence so far, but at a fundamental level, that is the path we need to be on.

Regarding the specific proposals, D1 and D2 are decisions for Wikidata to make, not us, so those are out of scope. E1 may make sense, and E2 definitely doesn't make sense, since where they diverge, en-WP descriptions tend to be better (due to the larger user base). I think what's likely to happen is that Wikidata will at some point recognize (perhaps now, perhaps in a few years) that en-WP descriptions are better and seek to adopt them. The question then becomes how to handle the situations where they are supposed to be different. Some further discussion is needed over at Wikidata to define what exactly those circumstances are, and how best to handle them (probably through some technical modification, so that e.g. "for the verb use Q12345 instead" can be tacked on to the en-WP short description). {{u|Sdkb}} ^talk 07:21, 7 August 2020 (UTC)

This would be a good point if it can be shown that Wikidata descriptions and Wiikipedia short descriptions do in fact have a sufficiently close match in uses. On Wikipedia we have a reasonably good idea of what the uses for short descriptions are, and we can expand them as an when we like, but where is it defined on Wikidata? Also there are fairly clearly quite a number of types of case where 'no short description' would be most appropriate on Wikipedia. This may not be true for Wikidata. Note that on Wikidata it is not even possible to provide a reference for the description. On Wikipedia we can use the article as the source, and if we find it necessary or desirable, we can make a way to add a reference.

Since they are considered content on Wikpedia, the proper place for them is on Wikipedia, where they can be created and maintained by Wikipedians. If there is no point in duplication, then transclude them to Wikidata. Then they also cannot be vandalised on Wikidata (2 problems solved - not duplicating and more eyes on the content.)

In the bigger picture the independent projects of The Wikipedia movement tend to rub along together much better when it is left to the community of each project to decide which content from other projects they choose to use. Trying to convince them that they must use another project's content because the other project thinks it is better is often met with stubborn resistance and a selection of good reasons why it would not work, which the proposers failed to think of, because they don't have to deal with the problems which they don't see as problems. Cheers, · · · Peter Southwood ^(talk): 13:36, 7 August 2020 (UTC)

• Oppose E1: e.g. for disambiguation pages, enwiki may decide that no short description is needed (if the page already has "disambig" or something similar in the title), while Wikidata will have "Wikimedia disambiguation page" as the short desc. Importing this would be counterproductive. Strong oppose E2 as completely missing the point of why this whole effort has been done in the first place. If we wanted our descriptions to be the same as those on Wikidata, we wouldn't have bothered with the "short desc" in the first place. As has been said, D1 and D2 are completely out of scope for a discussion here (just like E1 and E2 would be out of scope for a discussion at Wikidata). Fram (talk) 07:28, 7 August 2020 (UTC)

  It's easy enough to avoid pages that use {{Disambiguation}} if you want. Thanks. Mike Peel (talk) 11:20, 7 August 2020 (UTC)

  Yes, disambiguation pages need a standard short description or none at all. They are special because they describe their title rather than one of its possible meanings. Venus needs something to tell the reader that it's about a planet rather than a deity or a clam. Mercury is about "mercury" in all its senses. Certes (talk) 11:32, 7 August 2020 (UTC)

  It doesn't matter if enwiki decides that certain articles should have no short description, because the software doesn't allow it. The current choice is between a description automatically taken from Wikidata where we have no control of it, or creating a description on enwiki that we can edit to fit our policies and guard against vandalism. --RexxS (talk) 16:53, 7 August 2020 (UTC)

  The software doesn't allow it yet: the WMF promised they would turn this off when we reached the 2 million mark, but "surprise" they haven't done anything to actually achieve this and have been "working on it" for months now. But if and when the WMF does what they promised, then a "blank" short description on enwiki will be perfectly possible technically. Fram (talk) 17:19, 7 August 2020 (UTC)

  Jam tomorrow. But this is now. If and when the WMF turn off Wikidata short descriptions from enwiki, it will be a simple bot job to remove all of the useless boilerplate descriptions like "List article", including any that we import from Wikidata today. But in the meantime, we get control and vandal patrol over the ones that we've put here, instead of relying on Wikidata to control this bit of our content. --RexxS (talk) 11:45, 10 August 2020 (UTC)

  No idea what you mean by "Jam tomorrow". In any case; with E1, we import all Wikidata descriptions (which are shown now anyway, so no improvement now) and then we're stuck with that unsupervised mass import when the WMF keeps it promise of turning off Wikidata descriptions. Bsically, E1 is a way to undo the community RfC on Wikidata descriptions for the millions of articles that don't have a shortdesc yet (assuming they have one on Wikidata, which often isn't the case as well). Then we could just as easily had copied the descriptions in the first place; but the community decided against this, because of the quality issues. These quality issues haven't magically disappeared in the meantime, so there is no reason to import these now anyway. Better no descriptions than blindly importing the Wikidata ones; and better good descriptions than no descriptions. Fram (talk) 15:31, 10 August 2020 (UTC)

  "Jam tomorrow" is a phrase from Alice's dialogue with the White Queen. I think you'll find the conversation quoted in our Jam tomorrow article eerily reminiscent of our interactions with the WMF teams. I can sympathise with your position if I can bring myself to believe that that a tomorrow will arrive when the Wikidata descriptions are actually turned off, but we've been bitten like that once already. --RexxS (talk) 15:51, 10 August 2020 (UTC)

  The rule is, jam to-morrow and jam yesterday——but never jam to-day. - Lewis Carroll, Through the Looking-Glass, and What Alice Found There, chapter V. --Redrose64 🌹 (talk) 16:46, 10 August 2020 (UTC)

  Thanks, both. Fram (talk) 10:09, 11 August 2020 (UTC)

• Oppose E1/E2 – E1, because a lot of times, especially with naturally descriptive titles which can't be improved upon or better described briefly, empty is what you want. And also partly for reasons given by Alsee (and Fram). Likewise E2, because of the genesis and raison d'etre of short descriptions (and per A & F). Mathglot (talk) 09:15, 7 August 2020 (UTC)
• Oppose E1 as a bot action. All imports of short descriptions from Wikidata are at the discretion of a live editor, who will be held responsible for their being appropriate. Multiple inappropriate imports may lead to a block. There is already significant consensus for this item on en:WP. · · · Peter Southwood ^(talk): 09:37, 7 August 2020 (UTC)
• Oppose E2 There is fairly broad-based and long-standing existing consensus on this point that does not look likely to be changed here. This would be a blockable offence. · · · Peter Southwood ^(talk): 09:37, 7 August 2020 (UTC)
• Comment on D1 and D2 Not our circus, not our monkeys. This is something to take up with the Wikidata community, it is outside of our competence to decide, They are welcome to do it if they choose. · · · Peter Southwood ^(talk): 09:37, 7 August 2020 (UTC)

  I have notified the Wikipedia:WikiProject Short descriptions on its talk page. Anyone may feel welcome to check and ensure that the notification is appropriately neutral in tone. Cheers, · · · Peter Southwood ^(talk): 09:58, 7 August 2020 (UTC)

• D1 and D2 are out of scope for an enwiki RfC, so won't comment on them here (I understand there is a discussion on wikidata, but this is just to cover this for sake of completeness)
• Strong oppose E2, as this is essentially the situation we had before {{short description}} but with added bot edits. If the community feels this is OK, then surely we just keep using the descriptions from wikidata? I have not fully looked into the benefits / disadvantages of wikidata being used for short descriptions, so this oppose is based on the idea that having a bot periodically import is not as good of an idea compared to automatic server side syncing (which is what we had before).
• Oppose E1. If the community has issues over short descriptions being inaccurate or that labels are not always a good idea for short descriptions, then mass importing would be disruptive. Also a proportion would likely be incorrect or needing of improvement. The userscript which imports short descriptions seems to be doing a good job of covering the issue, by having an editor verify the short description before importing it. Dreamy Jazz ^{talk to me | my contributions} 11:39, 7 August 2020 (UTC)
• Oppose importing into English Wikipedia, as many short descriptions on Wikidata are overgeneric and not useful. For Wikidata imports, please discuss it there. Graeme Bartlett (talk) 12:11, 7 August 2020 (UTC)
• Comment on alternative to E1: write our own bot. Nearly six 3.7 million Wikipedia articles don't have any short description, and they should. For those, it would be better as a last resort to take the Wikidata bot-texts than to expect editors here to fix up that number of articles manually within a reasonable time. But those aren't the only options. Someone populated the Wikidata texts using a fairly simple bot, and there's no reason why the Wikipedia community here couldn't do the same, but with more sophistication. There's already an active group of editors working on WikiProject Short descriptions, and bot-assistance has been requested (by me and others). With a suitable commitment from a skilled bot writer, I'm confident there would be enough eyes to ensure a high level both of reliablity and of usefulness for our purposes. It takes a huge amount of time to edit and check each new SD manually if the article has to be opened each time, but if a bot writer could provide draft texts in a table format for manual review before updating, the manual effort would be far less. I, and I'm sure several others, would be only too happy to help with the technical specifications of such a bot, though I'm not able to do the actual coding. MichaelMaggs (talk) 13:07, 7 August 2020 (UTC)

  See also: PearBOT 5. Certes (talk) 13:58, 7 August 2020 (UTC)

  @MichaelMaggs: In principle I could help with this, as I can code and operate pywikibot scripts (which is what started this whole discussion). I'm not sure there is consensus to do this, though, given the anti-bot comments in this discussion. Perhaps you can draft specifications that you think would get consensus, I can code something up, and we can add an extra option to this discussion to see if it would be OK (or start another discussion)? Thanks. Mike Peel (talk) 19:15, 7 August 2020 (UTC)

  @Mike Peel: Thanks Mike, that would be most helpful. I don’t think there will be serious objections to auto-generating new SDs from entirely within Wikipedia, as that’s already been done on a sporadic basis by several editors at WikiProject Short descriptions, and indeed is recommended there; the objections above are more to the importation of rather poor-quality Wikidata descriptions. I’ve set out more details of a proposal at Wikipedia talk:WikiProject Short descriptions#Miniproject to generate new short descriptions by category. MichaelMaggs (talk) 10:17, 8 August 2020 (UTC)

• Oppose E1 & E2 (the only ones we need to decide here on English Wikipedia, what Wikidata does is their own decision that should be made on their own project) per Alsee. And didn't we already pretty much decide on E1 and E2 in the past, so why are we doing this again? --Ealdgyth (talk) 13:13, 7 August 2020 (UTC)
• Strongly Oppose E2. Regarding E1, Dreamy Jazz wrote (above), "The userscript which imports short descriptions seems to be doing a good job of covering the issue, by having an editor verify the short description before importing it." - I agree. Thus, I Oppose E1 if it means an autonomous bot filling in short descriptions from Wikidata.  - Mark D Worthen PsyD (talk) (I'm a man—traditional male pronouns are fine.) 00:16, 8 August 2020 (UTC)

  The script is a fine tool, but it would work better if more people used it. Getting them to use it requires them to know that it exists, and that short descriptions are needed. Not everyone cares, or is interested. I think they are useful when of reasonable quality, and mostly worth the effort, but not everyone shares this view.· · · Peter Southwood ^(talk): 08:18, 8 August 2020 (UTC)

• Support D1 & E1; Strongly oppose D2 & E2 — In my experience we want content control here. I have found graffiti and worse in wikidata. Make this wiki the authority and import what wikidata has so we may correct it. —¿philoserf? (talk) 08:27, 8 August 2020 (UTC)
• D1 & D2 are not for us to address here. Oppose E1 as needing clearer definition. Strongly Oppose E2 as being the opposite of consensus and would undo much progress. — GhostInTheMachine ^{talk to me} 15:24, 8 August 2020 (UTC)
• Support E1, oppose E2, Wikidata can do what it wants regarding D1 & D2. Really I'm fine with synching in either direction but in cases where data exists in both places, local data must always override remote, otherwise there's an enormous vulnerability to remote disruption we cannot use local tools to prevent. Ivanvector (^Talk/_Edits) 14:29, 10 August 2020 (UTC)

  Sorry to question you, but did you really mean to oppose E1? That's the case where English Wikipedia has no local description (so the software uses the remote description from Wikidata anyway). Wouldn't importing that remote description at least make it easier to edit here, and reduce the chance of it being vandalised? — Preceding unsigned comment added by RexxS (talk • contribs) 15:11, 10 August 2020 (UTC)

  If I've understood correctly, that's true only until the promised change occurs. Afterwards, E1 moves us from no description to a blindly imported description which can be edited or removed. That's not obviously bad, but it's different. Certes (talk) 15:50, 10 August 2020 (UTC)

  Apologies if I've misunderstood the options. If there is no description here already, importing the description from Wikidata ought to be harmless, it's what users see anyway. My only really strong opinion is that if there is a description here, Wikidata should not overwrite it. Ivanvector (^Talk/_Edits) 00:17, 11 August 2020 (UTC)

  @Ivanvector: What you describe then is neutral on D1/D2, support for E1 (If there is no short description here, then import the English description from Wikidata.) and oppose for E2 (If the short description here does not match Wikidata, then replace the short description here with that from Wikidata.) --Redrose64 🌹 (talk) 09:15, 11 August 2020 (UTC)

  Yep, you're right, my mistake. Changed my comment. Ivanvector (^Talk/_Edits) 10:00, 11 August 2020 (UTC)

• Strongly oppose both E1 and E2. Until Wikidata has much better verification, I don't want anything from Wikidata imported into EN articles. DES ^(talk)_{DESiegel Contribs} 01:17, 12 August 2020 (UTC)
• Support E1, Oppose E2. No opinion on D1 and D2 which are up to the Wikidata community. I see comments such as DESiegel's above about not wanting anything from Wikidata, and I sympathize, but as a practical matter it's already happening since in the cases that fall under E1 we are displaying the Wikidata text. What E1 would do is immediately make vandalism to the description visible on watchlists here, and that's a big plus. It also means we can quit worrying about vandalism to Wikidata since it would have no effect here. E2 makes no sense in the light of previous community decisions to have the short description here override whatever is in Wikidata. Mike Christie (talk - contribs - library) 18:19, 13 August 2020 (UTC)

  Mike Christie you make a valid point that once the Wikidata descriptions are copied to WP any vandalism on Wikidata becomes irrelevant and we can improve them here, but until that is done, they are our responsibility for BLP etc. Who would be held responsible? The bot owner? The person who authorises the bot run? Also, does anyone know how many of the outstanding SDs actually still have a Wikidata version available to copy? I guess it would be in the order of a million but could be out by a lot. · · · Peter Southwood ^(talk): 14:26, 28 August 2020 (UTC)

  Well, tell me if I'm wrong, but anything that we would consider vandalism is already showing up, right? E.g. if a BLP has a short description of "convicted criminal" in Wikidata, we're seeing that on mobile search now, but can't detect it here in enwiki. If we import it we have not made things worse. If someone were to go to that article, as they might do now, to set up the short description, instead of seeing "Convicted criminal" - Import - Import and edit they'd see Short description: Convicted criminal. So it wouldn't have any negative effect on our current drive to put in short descriptions, and would have the beneficial effect of preventing future vandalism on Wikidata from affecting us. Plus many of the bot edits would get reviewed (we would want them to be spaced out, not a flood of two million edits in a month) and that would have the additional benefit of cleaning up some of the incoming short descriptions if they are in fact vandalism. I don't see much of a negative. What am I missing? Mike Christie (talk - contribs - library) 15:15, 28 August 2020 (UTC)

  You're right about the current situation. What's missing is that the WMF has promised to stop displaying Wikidata descriptions, which will get rid of many descriptions (good or bad) but not those imported per E1 or E2. Certes (talk) 15:45, 28 August 2020 (UTC)

  I was under the impression that the promise to stop displaying Wikidata descriptions has not been implemented even though we have enough short descriptions to meet the requirement they set, and there's no date given for them to make that change. I agree that if we believe it's going to happen soon that makes a difference, but I also think the functionality is genuinely useful in mobile, and if most of the descriptions are correct (and I would guess the great majority are) then we might as well import them and fix them. That saves a lot of editor time on putting in short descriptions too so I suspect it would be a net benefit. Do we have evidence the WMF is really going to make the change soon? If so I would change to weak support for E1. Mike Christie (talk - contribs - library) 16:42, 28 August 2020 (UTC)

  For me, the WMF keeping its promise is a necessary assumption, in the sense that if they don't then I intend to stop editing and will no longer care about the outcome. However, that's slightly off-topic and I can understand that other editors have different opinions and objectives. Certes (talk) 17:18, 28 August 2020 (UTC)

• Support E2, but only support E1 after the Wikidata descriptions are actually ignored. I don't want to see even more redundant edits in my watchlist until it's really necessary. Nemo 11:06, 21 August 2020 (UTC)
• D1 and D2 are obviously not for us to decide. E2 would defeat the purpose of local short descriptions. Unsure about E1: it sounds like a good idea, and I certainly welcome the prospect of my watchlist never again getting cluttered by human editors importing descriptions from wikidata. On the other hand, it appears that imported descriptions do sometimes (often?) need to be changed, and they won't get changed unless either a human imports them or they get noticed by watchers (a bot eliminates the first and reduces the likelihood for the second). – Uanfala (talk) 18:03, 21 August 2020 (UTC)
• Strong oppose E2 because en.Wikipedia content should be controlled by en.Wikipedia, not overridden by a different project with different quality standards and different compunctions about low-quality mass bot text-creation. Oppose D1 and D2 because we should not be making decisions here about what gets stored on Wikidata. Oppose E1 on the general principle that Wikidata content is sufficiently dubious that every instance of copying text from Wikidata into en.Wikipedia should require a human to pay attention to it and check its validity, not just mass-copy by bots. —David Eppstein (talk) 07:08, 22 August 2020 (UTC)
• Oppose E1 & E2, no comment on D1 & D2 which are matters for the Wikidata community to decide. Noting that a description on Wikidata is a "descriptive phrase for an item, property or query" while a description on Wikipedia is a "concise explanation of the scope of the [article or other mainspace] page"; these are not the same thing. Also noting that Wikidata is a wiki and hence it is inherently unreliable; we should not be importing anything from Wikidata. --Malcolmxl5 (talk) 15:11, 25 August 2020 (UTC)
• Oppose E1, strongly oppose E2 No to E2 per many above. As for E1, I find the quality of Wikidata short descriptions too erratic for wholesale import. Some are far too long, others are so trivial they are pointless and still others are simply incorrect. I would not oppose a tool that would allow a category-worth of SDs to be reviewed together, with check boxes, allowing all the checked Wikidata SDs to be imported at once. That would speed things up without omitting human editor review of this highly visible content. We already have a user script that allows the page SDs in a category to be listed. See #Script to show short descriptions in category listings, below. It could be used as a basis for a review script.--agr (talk) 23:42, 31 August 2020 (UTC)
• Strong oppose E1 and E2: I don't know how many folks have been looking into and editing the short descriptions and all, but I can confirm that ArnoldReinhold is right: put kindly, the Wikidate short-descriptions are simply "too erratic". I would call them bad, quite frankly, and unsuited for import onto our Wikipedia. — Javert2113 (Siarad.|¤) 16:59, 1 September 2020 (UTC)

Possible alternatives

I cannot see the proposals above getting acceptance, but part of the problem that they are intended to resolve is real. We need a lot more short descriptions, and sooner is better than later. They do not have to be perfect, just good enough, as they can be improved at any time. I throw these in to stimulate thought and discussion, including better proposals.· · · Peter Southwood ^(talk): 08:18, 8 August 2020 (UTC)

1. A semi-automated system which goes through a category and provides suggestions, one of which can be selected and if necessary edited before saving. One of the suggestions would be the Wikidata description, because it is there, and is fairly often usable as is, and quite often can be edited into something better. The script for other options could be designed around the category. I don't know if this would be more or less work than just using the gadget and a moderately informed brain.
2. Relatively small bot runs per category followed by manual checks for quality.
3. Semi-automatic runs, where the bot opens and displays the proposed SD, and the user must accept it as appropriate to save.
4. Do a major bot run on the whole encyclopedia adding a maintenance category Category:Articles without a short description where relevant, to keep track of what is left to do.
5. Request NPP to consider adding SD wherever they can - Could even make a reasonable SD a condition of passing review, but I am not going to try to push more work onto NPP if they don't want it.
6. Make the gadget active by default to logged in users. An RfC would be necessary as otherwise there is likely to be strong pushback.
7. If Wikidata want to synchronise their descriptions to match those used on Wikipedias, they are welcome to update Wikidata by any means they choose that does not change Wikipedia short descriptions by automated process.

Peter Southwood ^(talk): 08:18, 8 August 2020 (UTC)

• Question: I have nothing against short descriptions, but WHY is there a rush to add them? I don’t understand the idea that sooner is better than later. I would think a slow and deliberate approach would be better... enlighten me. Blueboar (talk) 18:21, 8 August 2020 (UTC)

  @Blueboar: Because the WMF have given us a two million target, beyond which they will allow us a lot more control. See also WT:SHORTDESC and its archives. --Redrose64 🌹 (talk) 20:04, 8 August 2020 (UTC)

  I’m still confused... why is WMF in such a rush? Blueboar (talk) 20:30, 8 August 2020 (UTC)

  @Blueboar: Because things will break after WMF turns off the usage of the descriptions from Wikidata, which sucks. Thanks. Mike Peel (talk) 20:19, 8 August 2020 (UTC)

  What will break? Blueboar (talk) 20:30, 8 August 2020 (UTC)

  Currently the "short description" is used in certain scenarios related to mobile search and Wikipedia app usage; if no short description is there, the description from Wikidata is used instead. The functionality is extremely useful to navigate Wikipedia content on small devices which account for roughly half of the reader base.
  The enwiki community requested to ditch usage of Wikidata descriptions once ~2 million local descriptions have been created, which is the case meanwhile. Nevertheless, there are currently 2.4 million articles which have a Wikidata description, but not a local English Wikipedia short description. When the usage of Wikidata descriptions is ditched now, a really large fraction of the enwiki content becomes substantially less accessible for millions of readers. —MisterSynergy (talk) 20:41, 8 August 2020 (UTC)

  Ah... so nothing will actually BREAK. People will still be able to read and edit WP. It just won’t be as mobile friendly as it could be. Thanks. Got it. Blueboar (talk) 20:59, 8 August 2020 (UTC)

  The WMF may already have turned off Wikidata descriptions. I've not seen any announcement but I no longer see short descriptions on, for example, Abdomen, neither in mobile view nor with the gadget. Some but not all other editors still see the description, so perhaps only some servers have been updated. The change doesn't seem to have broken anything other than removing some descriptions. Certes (talk) 20:51, 8 August 2020 (UTC)

• Many of these seem like good ideas. But #6? Definitely not, since not all logged in users are editors. Remember the WP:READER. {{u|Sdkb}} ^talk 20:24, 8 August 2020 (UTC)

  Why would people log in just to read? How often does this happen?

  In what way would making the gadget active by default inconvenience anyone who does not intend to edit? · · · Peter Southwood ^(talk): 11:05, 9 August 2020 (UTC)

  Logging in allows you to set some preferences a reader might want to set.

  Short descriptions are not intended to be seen by desktop readers on a page. Showing them through the gadget would significantly change their purpose, and clutter the top of every page. Also, the gadget does not format them well enough for usage that widespread (it's unclear what exactly they are to the unaware, and the indent is a bit weird; that's fine for editors but wouldn't be for readers). {{u|Sdkb}} ^talk 20:12, 9 August 2020 (UTC)

  Short descriptions were indeed not originally intended to be seen by desktop readers. It is more debatable whether being able to see them is an advantage or a disadvantage to desktop readers. The display can be changed to something more aesthetically pleasing, if anyone could work out what that might be, Or it can be left as opt in, to avoid potentially inconveniencing the readers whose opinions are currently untested, and take a lot longer to finish the job because most editors don't know they should exist. · · · Peter Southwood ^(talk): 18:48, 13 August 2020 (UTC)

  The question of how many desktop readers who do not edit actually log in remains. Is it significant? Is it known? Can it be measured? · · · Peter Southwood ^(talk): 18:52, 13 August 2020 (UTC)

Script to show short descriptions in category listings

I'd like to call attention to a recently created user script that might be helpful in this discussion: Wikipedia_talk:WikiProject_Short_descriptions#Script_to_show_shortdescs_of_all_pages_in_a_category. I requested this script and SD0001 was kind enough to write it. In addition to aiding in editing short descriptions, I think it may have value in getting a general sense of the quality of local and Wikidata SDs. I would suggest trying it out on some categories you are familiar with.--agr (talk) 23:26, 31 August 2020 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.