Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

New proposals are discussed here. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
• Consider developing your proposal at Village pump (idea lab).
• Proposed software changes should be filed at Phabricator (configuration changes should have gained a consensus).
• Proposed policy changes belong at Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.
• Proposed new articles belong at Wikipedia:Requested articles.

« Archives, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213

RfC: Removing locally-defined links to Commons categories if they match the Wikidata sitelinks

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 previous RfC there was a rough consensus to develop the functionality presented here, but there was no consensus to implement the changes. This RfC asked whether there is now consensus to implement these changes. There is still no consensus to implement these changes. For context, the previous proposal was supported by a roughly 2 to 1 margin (about 15 to 8), this proposal was supported by a roughly 1 to 1 margin (about 15 to 14).

The supporters point out that the proposal would save a good deal of editor effort. When a page on commons is moved the hardcoded links break, but Wikidata is automatically updated. With this proposal, links would no longer break due to page moves. Some point to other benefits such as simplified wikicode and ease of use for newcomers. They contest the opposition argument regarding vandalism, saying that the risk is minimal and the benefits outweigh any such risk.

The general opposition is to the removal of locally defined data. The commons page to which an article links is currently subject to local consensus, and implementing this proposal would result in some pages having content which is not subject to local consensus. Additionally it would make it hard for readers and new users to fix errors because a template with no parameters does not make it clear where the data is coming from. They also disagree that the benefits outwiegh the risks of vandalism, pointing to the consensus against using WikiData for short descriptions and arguing that the benefit of using Wikidata for short descriptions did not outweigh the risk of vandalism.

Given the strong arguments on both sides, and the significant level of opposition in this proposal (especially in relation to the previous proposal) there does not appear to be consensus to implement this proposal at this time. Wugapodes [t^hɑk] [ˈkan.ˌʧɹɪbz] 08:43, 25 June 2019 (UTC)

Should we remove locally-defined links to Commons categories where they can be provided through the Commons category sitelinks on Wikidata instead? Thanks. Mike Peel (talk) 18:09, 4 May 2019 (UTC)

Proposal (Commons category links)

While we have been using interwiki links from Wikidata to provide the sidebar links to other language Wikipedias for the last few years, we are still mostly using locally defined links in sister project templates. In an RfC in August 2018, starting to use Wikidata to provide these links in the case of Commons categories was conditionally allowed, with the requirement to return to the community after further testing, which leads to this follow-up proposal.

Since the previous proposal, the following things have changed:

• {{Commons category}} and {{Commons category inline}} have been rewritten to use the Commons category sitelinks in preference to Commons category (P373) from Wikidata: this means that they automatically update when a category is moved, providing that the category name has not been locally defined. These sitelinks are maintained by Wikimedians that edit Wikidata and Commons, as they are also used to display information from Wikidata in Commons categories. They can only be added if the category exists, which significantly reduces any risk of vandalism.
• Category:Commons category Wikidata tracking categories have been revised, to track cases where we're already using Wikidata, where the locally-defined value matches Wikidata, where we're using P373 rather than the sitelink from Wikidata, where there is no local definition or a Wikidata link so we're using the pagename, and where the link is locally set as the pagename or is defined as something different from the pagename.
• Pi bot now checks through those tracking categories to update the links to categories that have been redirected to the Commons category that is sitelinked from Wikidata, or don't exist but there is a Commons category sitelink on Wikidata that we can use instead - or if that fails, and the category doesn't exist or have any redlinked category inclusions, then it removes the commons category link. This is ideally a temporary measure, though.

As the next step, I propose to bot-remove the locally-defined Commons category names from the categories and pages in Category:Commons category link is on Wikidata, where they match the Commons sitelinks from Wikidata. If this proposal is accepted, then I will submit a bot request for approval to do this using Pi bot. This change should have no immediately visible effect, but any future changes to the category names on Commons would automatically be updated here. This would not affect any locally-defined Commons category links that are not on Wikidata.

Pinging those that !voted in the last proposal: @Robby, Rhododendrites, Alpha3031, AfroThundr3007730, Johnbod, Jo-Jo Eumerus, Fram, Izno, GermanJoe, Compassionate727, Keith D, Peter coxhead, Ammarpad, Killiondude, Rschen7754, Nihlus, Finnusertop, ARR8, Gamaliel, Bidgee, Bluerasberry, GreenMeansGo, PBS, Wikisaurus, and Nemo bis:

Pinging as well those that modified template Commons category since 2015 and thos e who discussed the same category on it's discussion page: @Ahecht, Redrose64, Fayenatic london, Rich Farmbrough, Pigsonthewing, IJBall, Magnolia677, Andy Dingley, JJMC89, Zhanlang1975, Michael Bednarek, Krinkle, and FunkMonk:

Survey (Commons category links)

• Support as proposer. Thanks. Mike Peel (talk) 18:09, 4 May 2019 (UTC)
• Oppose now – see below. Cluttering articles with links to Commons when these are in the sidebar isn't desirable. However, my support is conditional on the point noted below, that only the Commons category link that matches the Wikidata link is removed. (As has been discussed, here and at Wikidata, many times now, there are problems caused by Wikidata insisting on 1:1 inter-wiki relationships, when for various reasons different wikis, including Commons, don't have 1:1 links – e.g. for monotypic taxa, enwiki has one article, whereas Commons usually has a category for each rank.) Peter coxhead (talk) 09:51, 6 May 2019 (UTC)

  @Peter coxhead: Just to be clear, the proposal is to go from e.g., {{Commonscat|Example}} to {{Commonscat}} where the Commons sitelink on Wikidata is "Category:Example". The template itself would not be removed. Thanks. Mike Peel (talk) 10:32, 6 May 2019 (UTC)

  @Mike Peel: ah, my mistake. Then I now Oppose the proposal. So long as the template is present, then as with {{Taxonbar}}, I think it's better to explicitly document the connection. A tracking category is enough to flag up cases where none of the stated commons cat links matches Wikidata, as happens for {{Taxonbar}}. What I favour is removing the template altogether when the link will be in the sidebar. Peter coxhead (talk) 11:12, 6 May 2019 (UTC)

• Support - as long as the Commonscat template is kept available for non-standard situations, this should be an unproblematic and reasonable change. GermanJoe (talk) 11:08, 6 May 2019 (UTC)
• Support with the general expectation that only the matching values are removed. --Izno (talk) 11:38, 6 May 2019 (UTC)
• Support Pages that link to more than one cat or have special need to keep the local link should be exempted, otherwise this is good. – Ammarpad (talk) 14:28, 6 May 2019 (UTC)
• Fine by me. I can't comment on the technical details as they're beyond me (as usual). But in principle I don't see any issues. GMG^talk 20:58, 6 May 2019 (UTC)
• Support - the Commonscat template should be kept available for non-standard situations. --Robby (talk) 21:22, 6 May 2019 (UTC)
• Support this as a sensible next step — Martin (MSGJ · talk) 21:46, 6 May 2019 (UTC)
• Oppose: The commons category listed in the Wikipedia article is the "ground truth", that is, users who actively contribute/watch to that article are presumably in consensus that this (or these, where there are multiple commons categories) is the most appropriate Commons category for this article. The information on Wikidata is merely a copy. Users who contribute to articles care about keeping them correct and safe from vandalism and often have real world topic knowledge, users who contribute to the Wikidata Qnumber are acting more in the role of a database administrator and are generally not familiar with the topic. By all means, take a copy of this into Wikidata but do not destroy the original information on Wikipedia. Firstly because that is a generally poor practice to remove authority over information from subject matter experts to database administrators, but more specifically because if someone vandalises the information on Wikidata, it will not show up on the watchlists of those who watch the Wikipedia article and damage will go undetected. It is one thing to exploit Wikidata information where the information starts its life on Wikidata (e.g. as an uploaded data set from some authoritative source). Rather than remove the information from Wikipedia, it would be better to add a template to flag on both Wikipedia and Wikidata where there is an inconsistency between Wikipedia and Wikidata, as I have seen done with coordinates, which is an invitation to investigate the matter and not impose the presumption that what is on Wikidata is always the "truth". We already have the ability for a commons category template on Wikipedia to default to the article title, and I never use that feature as I have seen too many times when the articles is renamed and nobody thinks about the implication of that move on the commons category (which has normally not been renamed). Kerry (talk) 23:50, 6 May 2019 (UTC)
• Support I don't see any issues. Go on. Sincerely, Masum Reza^☎ 04:40, 7 May 2019 (UTC)
• Support seems like a smart move -- reduces clutter in the markup, Sadads (talk) 18:13, 7 May 2019 (UTC)
• Oppose Per Kerry's extremely well written and reasoned comments above. Beeblebrox (talk) 20:23, 7 May 2019 (UTC)
• Oppose - If Wikidata isn't stable & nuanced enough for short descriptions, then I don't think it is for this either. I think it would be better to keep the info locally and have a bot set up a list or drop a notice on the talk pages of articles with differing cats or where only Wikidata has a cat. Daß Wölf 22:17, 7 May 2019 (UTC)

• Oppose. Compare the Commonscat box at right with the Wikidata link in the toolbar, and imagine a Commons link, or any other inter-project link, in the toolbox at left. Which one's more visible? As a longtime admin on both sites, I'm quite familiar with our layout, but I virtually never think of inter-project links appearing on the left, aside from other languages' Wikipedia articles. What about the newbies or those who never edit: do we expect them to find Commons links amid all the other stuff? It's much more reader-friendly to have a sizeable right-side box or an entry in the external links than to bury a link on the left side with lots of other things that are mostly irrelevant to someone who's not editing. Nyttend (talk) 22:44, 7 May 2019 (UTC)

  @Nyttend: You may want to reread the proposal. The box would stay in either case. ARR8 (talk) 00:28, 8 May 2019 (UTC)

• Support per nomination. ARR8 (talk) 00:28, 8 May 2019 (UTC)
• Oppose An edit that does nothing but remove local information that is already on Wikidata is functionally cosmetic. Bots performing cosmetic edits are not allowed per policy. * Pppery * _survives 00:42, 8 May 2019 (UTC)

  You seem to have mischaracterized Wikipedia:Bot policy#Cosmetic changes. A bot implementing community consensus is specifically allowed regardless of whether the edit is cosmetic or not. Anomie⚔ 11:19, 8 May 2019 (UTC)

  @Pppery: As well as Anomie's point, I think it falls under "administration of the encyclopedia" - it's preventative maintenance. Thanks. Mike Peel (talk) 19:04, 8 May 2019 (UTC)

• Oppose I agree with what Kery has said, to me the bigger issue is creating a process with excemptions as we know from practice that exemptions are rarely accepted once a policy is written, as groups of editors haunting the discussion boards see it as means to enforce uniformity and standidise everything to their preferred format. What could could be done is to allow for Qnumbers in {{Commonscat|Q00000}} to make the link Gnangarra 05:56, 8 May 2019 (UTC)
• Oppose. Kerry put it well. I have long been troubled by persistent efforts for systematic bulk deletion of content from Wikipedia, in favor of obscure remote-ownership of everything by the bot-farm known as Wikidata. One of these days we need to reach a community consensus on the practice in general. Either we should transfer everything possible over to Wikidata and accept that that Wikidata is going to manage everything from now on, or we need to roll back Wikidata to tracking-categories and rare purposes of specific value. This endless struggle to roll Wikidata forwards (or backwards) one inch at a time is wasteful at best and disruptive at worst. Alsee (talk) 16:26, 8 May 2019 (UTC)
• Support This is safe, raises quality, saves humans from tedious labor, stages content from English Wikipedia to migrate into other languages of Wikipedias, and this small project is a model for greatly scaling up integration of English Wikipedia with automated tools. I am keen on eventually using more automation in English Wikipedia for quality control and monitoring. We do not have the technology to apply automation generally everywhere, but for mundane things like limited category maintenance, automation and integration with Wikidata is a good fit for being unlikely to cause problems and likely to prevent problems. I recognize that people here fear wiki editors developing annoying edit bots, but personally I fear and am seeing bad actors with malicious bots attacking Wikipedia. We are entering an arms race and I want us to develop our technology and also advance conversations about how humans and bots will collaborate to sustain Wikipedia. The bad actors do not follow rules, and I want us to start the slow conversations with good actors and safe cases as we see here. I do not see this primarily as a technical experiment, because this proposal is so small in scope and so safe. Instead I see this as a social experiment for how we negotiate the introduction of quality control bots into English Wikipedia and across Wikimedia projects. I interpret the opposition here as resistance to Wikidata, slippery slope that this change pre-approves future risky changes, and resistance to bots consuming human attention on English Wikipedia. I definitely agree that bots cause stress to humans, but I see the solution to that as research, discussion, planning, and experiments, and not in an ongoing prohibition of this necessary and inevitable change. Relatively low-impact proposals like this are good experiments to get information about how bot-Wikidata-Wikipedia interactions play out. Blue Rasberry (talk) 19:43, 8 May 2019 (UTC)
• Support As reduces issues when categories are renamed. -- WOSlinker (talk) 07:50, 9 May 2019 (UTC)
• Oppose this scope creep of the obscure, poorly monitored Wikidata needs to stop. Plus, Kerry says it well, especially in the discussion below, eg: And please don't bother to say that Wikipedians can watch directly on Wikidata, because that is unlikely to happen and we all know it. In IT it is never a good idea to remove the authority over data from the subject matter experts to database administrators, as it usually disengages the subject matter expert and then data quality falls as a result of the disengagement. . - Sitush (talk) 07:58, 9 May 2019 (UTC)
• Strong support (and actually, for most sister links). The links do often not lead to significant / more information - what is the use of looking on commons if I see exactly the same image or see 11 images on commons while 10 of them are already used in our article. And if there are images there that are of real significance, then they should be used (e.g. in a gallery). Commons categories often contain mostly the images already used in the article (and a promise that the commons category will/can grow is WP:CRYSTAL). I can see that there is sometimes a reason to include sisterlinks, but that should absolutely not be a standard, it should be a well considered and one should be allowed to challenge existing links based on content, not being countered with the argument 'it is standard' or 'we do that always'. --Dirk Beetstra ^{T C} 08:23, 9 May 2019 (UTC) I read this wrong, Oppose, this is not removing the sisterlinks from the bottom of the article, this wants all to be done through WikiData. WikiData is poorly monitored, local content should always have preference. --Dirk Beetstra ^{T C} 08:26, 9 May 2019 (UTC)
• Support. Vulphere 12:26, 11 May 2019 (UTC)
• Oppose per Kerry, and because of problems of consistency when more than one commons link is desirable in a Wikipedia article, which I think would be confusing after this suggested change. I think that Gnan's suggestion "What could could be done is to allow for Qnumbers in {{Commonscat|Q00000}} to make the link", could be worth pursuing as a compromise. -- PBS (talk) 17:01, 11 May 2019 (UTC)
• Oppose per Kerry. I'm all for flagging pages where the template and wikidata don't match by putting them in a category for manual review, but vandal-fighting over at Wikidata isn't robust enough for us to be trusting it as an authoritative source. --Ahecht (TALK
  PAGE) 21:57, 15 May 2019 (UTC)
• Support This is a change that will allow us to better serve readers and editors alike by automatically updating data for the 99% of cases where Commons/Wikidata was updated correctly – Instead of preventing 1% of potential incorrectness at the cost of being outdated and likely wrong by default for 100% of cases, with no notification to editors that watch articles to know whether something might need fixing, until someone manually realise it (which is what we do today). There is currently no technology in place to notify us about a Commons category rename. What we do have is Wikidata. Commons users update this for us already (or even automatically, in case of simple page rename on Commons). This data can in turn be queried from articles. In addition, Wikidata has the ability to notify us (as Wikipedia editors) directly on our watchlists whenever such manual or automated change from Commons/Wikidata affects an article we watch. As such, we would still have the ability to review and fix these as-needed. I believe this fits in with a wider theme of giving ourselves more time to focus on the things that matter (e.g. reviewing meaningful changes to articles on our watchlist, improving the quality and breadth of our content), and demand less wasted effort on people manually fixing things that we could have prevented from breaking in the first place using a bit of automation. --Krinkle (talk) 22:35, 15 May 2019 (UTC)

  For those that oppose, I wonder what their opinion would be on a proposal for a bot that updates these templates automatically as an edit whenever the previous value on Wikidata matches the current value on Wikipedia (effectively the same proposal with similar Watchlist events, but more wasteful toward the limited time and resources that volunteer bot operators would spend). --Krinkle (talk) 22:35, 15 May 2019 (UTC)

  Krinkle if we were to run a bot, why would we want the bot to look at Wikidata at all? The bot should directly watch for Commons category moves. I think most opposes would spot that, and see your proposal as motivated by serving Wikidata advocacy itself. Alsee (talk) 00:08, 19 May 2019 (UTC)

• Oppose now; maybe later. I looked at a few examples from Category:Commons category link from Wikidata to see how well it works at the moment. I found Category:5 Kanal (Ukraine) where {{Commons category}} generates "Wikimedia Commons has media related to commons:Category:Kanal 5 (Ukraine)." Well, that turns out to be a redirect; the Commons category was moved and then merged in October 2018. This demonstrates that the Wikidata links are not currently being adequately maintained. Therefore we should not yet increase our reliance on them. Bots would be better employed in tracing and fixing errors such as that one. – Fayenatic London 09:39, 16 May 2019 (UTC)
• Oppose The use of a template without a parameter is very confusing for new users who scratch their head wondering where the data comes from. We should be making things easy for users by making it clear what we are linking to and where the data is coming from. It gets even more confusing for uses where there is 2 templates in an article 1 with a parameter and 1 without a parameter. There is also the unreliability of wikidata entries and no visibility that there has been a change to the destination of a link, unless you are also watching wikidata changes on an article. Watching wikidata changes just adds to watchlist length and can cause the limit of 1,000 changes to be reached far to easily. Report differences in the entries by tracking categories (removing the tracking category that it is on wikidata). By the way I did not get either of the pings that this was taking place. Keith D (talk) 12:26, 18 May 2019 (UTC)
• Late oppose per Kerry & Keith D. Happy days, Lindsay^Hello 11:24, 31 May 2019 (UTC)
• Support as admin on Commons and heavy Wikidata user. Pushing to the extreme, any interlink template should be deleted in every project as the "Commons" in the sidebar should be enough. The templates on en.wiki are often filled with obsolete / improper data (i.e.: commons categories which are not the right ones, or that have been redirected to a more appropriate name) and the bots that read those parametres import wrong data to Wikidata. Wikidata has been created to be a centralized archive, not as a double for data present on the other chapters and projects. -- SERGIO aka the Black Cat 13:18, 2 June 2019 (UTC)
• Oppose - on the grounds that wikidata, whether reliable or not, is outside Enwiki editors view and any incorrect data, whether poor editing or vandalism or anything else, will be unnoticeable. Too much reliance on the external project for invisible functionality is dubious to my mind. GraemeLeggett (talk) 06:01, 15 June 2019 (UTC)

Discussion (Commons category links)

• I think we have cases when one article has two commonscat templates pointing to two different categories. I suggest that these cases be kept. If there is only one commonscat template, I agree with the proposal to remove it. Whereas we do have vandalism instance at Wikidata, in which case the sitelink disappears or is invalid, we have way more cases of commonscat templates pointing out to redirects just because the Commons category was moved and the template has not been updated.--Ymblanter (talk) 18:24, 4 May 2019 (UTC)

  @Ymblanter: In cases where there are multiple commonscat templates in one article, this proposal would only remove the local text from the one that matches the sitelink. I can add an exception to avoid those cases if that's what we want to do, though. With that type of vandalism, that would be a cross-project problem to fix, and it would be caught by tracking categories both here and on Commons. Thanks. Mike Peel (talk) 18:39, 4 May 2019 (UTC)

• @Mike Peel: FYI, I didn't receive your ping, and I assume the rest didn't either. Probably you've not signed the edit with the mentions. – Ammarpad (talk) 04:58, 6 May 2019 (UTC)
  • Let's re-ping them all, then: Pinging those that !voted in the last proposal: @Robby, Rhododendrites, Alpha3031, AfroThundr3007730, Johnbod, Jo-Jo Eumerus, Fram, Izno, GermanJoe, Compassionate727, Keith D, Peter coxhead, Ammarpad, Killiondude, Rschen7754, Nihlus, Finnusertop, ARR8, Gamaliel, Bidgee, Bluerasberry, GreenMeansGo, PBS, Wikisaurus, and Nemo bis: WhatamIdoing (talk) 06:05, 6 May 2019 (UTC)
    • I'm not sure that @Robby:'s ping got through either, so trying again: "Pinging as well those that modified template Commons category since 2015 and thos e who discussed the same category on it's discussion page:" @Ahecht, Redrose64, Fayenatic london, Rich Farmbrough, Pigsonthewing, IJBall, Magnolia677, Andy Dingley, JJMC89, Zhanlang1975, Michael Bednarek, Krinkle, and FunkMonk: Thanks. Mike Peel (talk) 19:06, 15 May 2019 (UTC)
• Request for example @Mike Peel: Can you provide an example where this proposal would change things? Can you talk through what the bot would check in that case to determine the need for a change? Blue Rasberry (talk) 13:55, 6 May 2019 (UTC)

  @Bluerasberry: For example, Category:2012 in the Maldives linked to commons:Category:2012 in Maldives, which was correct until the commons category was renamed. That was automatically updated on Wikidata, but required a bot edit here rather than updating automatically (as it would have if the locally defined text didn't exist). You can look through the edits of Pi bot to find many more examples like this. You can also dig through the other commons category tracking categories to find cases where the bot hasn't managed to catch it for some reason. The new bot would check for cases where the commons sitelink exactly matches the locally defined one, and would only remove it if that was the case. Thanks. Mike Peel (talk) 19:21, 8 May 2019 (UTC)

  I see, thanks. Blue Rasberry (talk) 19:43, 8 May 2019 (UTC)

• When pulling from Wikidata, is there a link to the page where an edit may need to be made to correct the issue of a bad link (whether that's the same item or the category item)? --Izno (talk) 18:56, 7 May 2019 (UTC)
• @Kerry Raymond: A sensible argument. If there were only the two sites, Wikipedia and Wikidata, then it could be said that Wikipedia, as the more active site, would be a good place to keep the data, since more people will monitor it. But consider: there are more than two sites. Besides the English Wikipedia, there hundreds of other Wikipedias, not to mention sister projects and all of their languages. Is English Wikipedia really the more active site for every page? Many of our pages are stubs, and some of those same pages are flourishing on other language editions. Wikidata is the natural central location to keep all of these links, so all of the Wikimedia family wikis can benefit from each others' work. ARR8 (talk) 00:34, 8 May 2019 (UTC)

  Is this RfC occurring on all Wikipedias and only proceeds if all WPs agree? This village pump can only decide policy for en.WP and not impose it on other Wikipedias and vice versa, so I don't see this as a relevant issue unless it's a global proposal. I don't have a problem with a Commons category being suggested based on information held in Wikidata but not to impose it. Kerry (talk) 02:01, 8 May 2019 (UTC)

  @Kerry Raymond: This RfC is enwp-specific, I'm not sure there's a good place to raise it globally across the different Wikipedias? But regardless of that, I'd contest that the 'ground truth' of this is now the sitelinks on Wikidata, not the locally defined text here. The sitelink is used on Commons to add the interwiki links to the various Wikipedias in the sidebar (the same as interwikis work here), and to display information from Wikidata about the topic of the category (through the infobox there). If that sitelink is wrong, then a Commons editor can fix it by editing Wikidata. However, that won't currently fix the link to the category from here, unless they also come to enwp to fix it, which they won't if it's a topic in a non-English country (I know you mostly edit about Australian topics, but think about editors that work on Portuguese or Spanish content both on their language wikis and on commons). Vandalism of the sitelinks is possible, but it's not trivial - you have to change the sitelink to point to a different, existing, category (compared with just changing some text in an article), so it's unlikely. For the cases that this RfC is concerned about, the information here is merely a copy that can easily go out of date. I'm out of energy to argue about your other points now, I'll follow up on them another day. Thanks. Mike Peel (talk) 19:39, 8 May 2019 (UTC)

  @Kerry Raymond:, well, at first Wikidata was used by everyone but en.wiki users, who seemingly didn't believe very much in that project at begin :-) BTW I can assure that, as Commons admin and 'Data heavy user, the use of parametres in Commonscat is annoying/problematic for the correct maintenance of the categories on Commons. I'll omit the cases in which commonscat links to a whole improper category (this or this, for example); but there are a lot of Commonscat templates filled with Commons categories that either no longer exist or have been redirected. It's not a mattere of data authority (anyway, as a matter of fact, Wikidata users have to reference data too, thus 'ground truth' is a false argument. If you have a solid source for the data migrated on Wikidata, include it in the property on the Wikidata item, there are fields created just for that purpose, and the chain won't be broken...). -- SERGIO aka the Black Cat 08:06, 3 June 2019 (UTC)

  The Commons category named in an en.WP article represents at the time it was asserted the current consensus of which Commons category(s) best correspond to the article content. I agree entirely that changes on Commons can take place without alerting anyone on en.WP interested in that article. I would welcome some system of notifications so such relevant changes correctly propagate through the notification system cross-project so the changes to the Commons category can be reviewed by interested en.WP contributers (and of course vice versa). This proposal increases the existing problem by additionally allowing changes on WikiData to silently override the intentions of contributors on local projects. Each project controls its content; where we have dependencies between the projects, we need to find ways to manage such dependencies. Just as WP articles may reference a Commons category, many Commons categories contain links back to a Wikipedia article to provide a description of the topic in a specific language, so often there is mutual co-dependency. Right now we don't have any agreed social or technical process to notify and resolve cross-project dependencies, but I would like to think consensus from all affected projects would be the overarching principle. This proposal (not being discussed on Commons or any other WPs which allegedly benefit from it) will bypass consensus on other projects by silently automating and implementing a decision made on Wikidata. Wikidata right now is full of bad modelling and inappropriate population of data based on the presence of a certain template. One that directly affects me is Queensland place ID (P3257) which has incorrect constraints and has been populated incorrectly, resulting in hundreds of constraint violations for which I have asked "to fix the problems on Wikipedia", but Wikipedia is not the problem here, the problem is on Wikidata, but nobody on Wikidata will take responsibility for fixing the problem. If Wikidata contributers had bothered to discuss with Wikipedia contributors who use these place IDs in articles in the first place (i.e. created a cross-project consensus), we could have avoided the problem. As far as I know, there may be ongoing automated processes continuing to make this problem worse (I create new Queensland place articles all the time). Imagine if someone said "let's transclude the value of the Queensland place ID held on Wikidata automatically into Wikipedia articles", we would trash thousands of article and their citations with bad data. How does such a proposal differ from this one? Both are based on the unquestioned assumption that Wikidata has it "right" (or at least "more right" than any other project); well, I am questioning that assumption. Nobody has explained how having copied and removed the Commons category from an en.WP article, what keeps that data safe on Wikidata (whether from vandalism or the result of poor-quality modelling/population as I illustrate above) resulting in erroneously changed values on Wikidata being silently transcluded back into a rendered Wikipedia article bypassing those people on Wikipedia who maintain that article. I am not anti-Wikidata in concept, but I have developed an increasing concern about what is happening in practice given the apparent indifference to quality modelling and quality "scraping" from other projects. We need a cross-project dependency notification system and once we have that, we have a better basis for the kinds of automated transclusions being proposed as contributors on local projects would be aware of it, just as if it was manually changed on that local project. Kerry (talk) 09:26, 3 June 2019 (UTC)

  I know what you mean, @Kerry Raymond: but Commons is everyday less and less dependent on en.wiki referencing, since there are templates like "Wikidata Infobox" or "Creator" that take data directly from Wikidata, and wikidata itself relies less and less on data imported from regional chapters (for example, all the data I upload on Wikidata come from reliable third party sources), and this will be the future of Wikidata: no longer a recipient of data collected from the local chapters but a centraliser of data collected from reliable sources. Further, consider that you can have on Commons a category on an item that doesn't appear in any Wikipedia, because Commons and Wikipedia have two different goals... -- SERGIO aka the Black Cat 08:49, 8 June 2019 (UTC)

First, I note it has not been raised on Commons:Village_pump/Proposals and that's just one place, but if the benefits are for all WPs as sugggested above, surely all WPs should be in this conversation. Kerry (talk) 23:22, 8 May 2019 (UTC)

Second, I don't think you understand what is meant by "ground truth", which Wikipedia defines as "information provided by direct observation (i.e. empirical evidence) as opposed to information provided by inference". In science, the ground truth is the laboratory notebook; you never destroy them, just because the information has been copied elsewhere, because in the event of questions/dispute, you always go back to the lab notebook. When it comes to Commons categories, the ground truth is the decision/consensus of editors on Wikipedia. Are you seriously proposing that Wikidata editors should decide from now on which Commons categories should be added to a new article and not Wikipedia editors? How will it work in practice? Let's say I have an article on the Marian sugar mill which has its commons category set as Category:Sugar mills in Queensland. Let's say someone takes a lot of photos of that mill and creates a sub-category on Commons called Category:Marian sugar mill, which is a better commons category for the article to use. Who will update it and how? A Wikipedian do so by updating the template in the Wikipedia article to add the new category, or will they be forced to go to Wikidata to do this? Can we have this proposal spelled out for the whole lifecycle please, currently all it deals with is taking existing information away from Wikipedia and does not explain what happens next, how updates will be oversighted, how and where disputes will be conducted. If we go down this path, I think we need Wikidata watchlist notifications that affect the Commons category to be propagated through into the watchlists of Wikipedia articles (on all WPs) that are affected by it. Not *all* Wikidata updates to the Qnumbered thing, just the ones affecting Commons category. If the watchlist situation can be resolved and the ability to update the Commons category locally from Wikipedia (and not having to learn anything about Wikidata), then I would be much less worried. Because who on Wikidata is putting their hand up to watch the Queensland sugar mill edits that I would normally watch on Wikipedia? And please don't bother to say that Wikipedians can watch directly on Wikidata, because that is unlikely to happen and we all know it. In IT it is never a good idea to remove the authority over data from the subject matter experts to database administrators, as it usually disengages the subject matter expert and then data quality falls as a result of the disengagement. Kerry (talk) 23:22, 8 May 2019 (UTC)

@Kerry Raymond: I'd be happy to point this proposal out on Commons and elsewhere, but then I'd probably be accused of WP:CANVASS. :-/ With most of what you say, substitute 'Commons' in place of 'Wikipedia', and it changes the perspective. The point is that Commons editors also play an important role in linking Wikipedias<->Commons, and using Wikidata to do this in one place is a lot better than doing it in multiple places. I'm not proposing to remove the ability to set a local link here if needed, so in the example you give you could still define that manually, I just propose to remove the duplication of exact data. There are over 2 million commons sitelinks now, and the 600k or so here is just a subset of that. Thanks. Mike Peel (talk) 06:08, 9 May 2019 (UTC)

It's only canvessing if you do so in a way to influence someone and, yes, the RfC as written does run that risk as it is supposed to be written to be NPOV. So rewrite the RfC to be NPOV and then advertise it on other sites that it affects. Kerry (talk) 07:20, 9 May 2019 (UTC)

In practice, I see a lot of Commons categories which were set here on the English Wikipedia long time ago and then moved on Commons. Our template leads nowhere (or sometimes to a category redirect) because nobody cared to go here (and to 200 other Wikipedias) and update the commonscat template. However, if a category has been moved on Commons, the record has been automatically updated on Wikidata, and the sitelinks in the same articles are usually correct.--Ymblanter (talk) 15:00, 11 May 2019 (UTC)

Oh, I see, Mike Peel has already made above the same point.--Ymblanter (talk) 15:02, 11 May 2019 (UTC)

@Ymblanter: It's a good point, worth repeating. :-) A lot of the work I've been doing here recently has been to try to fix these (by bot/manually), but it takes time, and it would be better if the problem didn't exist in the first place, hence this proposal. I hope you consider !voting on it. Thanks. Mike Peel (talk) 15:38, 11 May 2019 (UTC)

• One of the concerns with {{Commons Category|<no parameter>}} was that if the article was moved, the category would then be wrong. This is the reason we have been adding parameters. Ideally this would track moves of the Commons category too. I'm not sure if this proposal addresses the first issue. All the best: Rich Farmbrough, 12:59, 16 May 2019 (UTC).
  
  • @Rich Farmbrough: - Yes, that's the idea. If things work correctly (they don't always), when you move a page on a local project that is linked to Wikidata, the software will automatically update WD with the new location. This applies equally to local moves here and it does on Commons. GMG^talk 13:05, 16 May 2019 (UTC)
    • But could the WD entry be manually overwritten, thus allowing a vandal to play havoc? - Sitush (talk) 06:39, 18 May 2019 (UTC)
      • @Sitush: How do you mean? The sitelink must link to an existing page, which should avoid most vandalism. Thanks. Mike Peel (talk) 16:30, 18 May 2019 (UTC)
• @Fayenatic london: Cases like that are caught at d:Wikidata:Database_reports/Complex_constraint_violations/P910#Items_that_link_to_a_Commons_category - there's more of a backlog there than I thought, I'll look into it. Thanks. Mike Peel (talk) 18:45, 16 May 2019 (UTC)

  @Fayenatic london: Thanks for pointing this out. I've written some code to work through the cases where one of the sitelinks redirects to the other. It's also finding more cases here where the manually-defined text links to a redirect category, e.g., at Sierra de Grazalema Natural Park - those would be automatically fixed if this proposal passed, but as it stands they'll wait until pi bot next runs through the maintenance categories. There are also more complex cases that will take time to resolve, either manually or through more code. Thanks. Mike Peel (talk) 17:36, 18 May 2019 (UTC)

• I've asked for a formal closure of this at Wikipedia:Administrators'_noticeboard/Requests_for_closure#Wikipedia:Village_pump_(proposals)#Survey_(Commons_category_links) - hopefully that will happen soon. Thanks. Mike Peel (talk) 19:11, 7 June 2019 (UTC)
  • Any volunteers to close this? @AGK: since you closed the last one, could you perhaps have a look at this? Thanks. Mike Peel (talk) 17:32, 21 June 2019 (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.

Remove "suspected perpetrator" field in Template:Infobox civilian attack

(Discussion moved from Template talk:Infobox civilian attack#Suspected perpetrator field? on recommendation to gain full consensus.) I struggle to see the benefit of listing a "suspected perpetrator" in an infobox, especially when a suspect is part of an ongoing case and will be either removed or moved to "perpetrator" when that is complete. Looking at Christchurch mosque shootings and the contention over how prolific suspect Brenton Tarrant's name should be (see ongoing RfC about keeping suspect's/suspects' name in lead), I don't think his name in an infobox offers any encyclopedic value (officially and legally, as little doubt as there is over his guilt, it has not been proved yet) and if anything only unduly promotes his name which we should also avoid. When a suspect is proven to be a perpetrator, they become part of the historical/encyclopedic record of the attack rather than the subject of a current matter/desire for notoriety. Christchurch is one particular case, but I don't think it's unique in this regard. I suggest this field be removed. U-Mos (talk) 03:28, 22 March 2019 (UTC)

(Comment copied from original discussion) I concur. There's no reason for this parameter to exist – when the identity is known and certain, the appropriate parameter is "perpetrator", and when it is not, it doesn't belong in the infobox at all to begin with. TompaDompa (talk) 08:17, 22 March 2019 (UTC)

• I agree. This gets into NOTNEWS territory. We have to be aware that a reported “suspect” can be falsely accused (for example: the reports that Richard Jewell was a suspect in the bombing that took place during the Atlanta olympics). At a minimum, we need to wait until a “suspect” is actually charged with the crime before we report names. Blueboar (talk) 12:59, 22 March 2019 (UTC)
• I also agree. If suspects are to be named in the article then we can word things to make it clear that they are only suspects, and to say whether they have been charged or prosecuted, but an infobox entry is too blunt an instrument for such sensitive content. Phil Bridger (talk) 13:33, 22 March 2019 (UTC)
• The idea makes sense, but I know from how less experienced editors see infobox fields and if you took out the suspected perp field, they will want to fill the name in on the actual perp field because they feel it would complete the infobox (unaware of the implications of this towards BLPCRIME). --Masem (t) 13:36, 22 March 2019 (UTC)
  • Well, that gets us into the murkier question of what fields should be included in an infobox in the first place. Perhaps we shouldn’t even have a “perpetrator” field. Indeed, when it comes to this sort of topic, we probably need to question whether an infobox is aporopriate at all. Is an infobox an appropriate method for conveying information in an article about a mass killing? Blueboar (talk) 13:55, 22 March 2019 (UTC)
    • Arguably yes, it just shouldn't be filled in until after conviction. (Contrast that to a religon= field in the BLP infobox ) Its that well-intentioned editors unaware of why the field is blank will think to fix it blindly. --Masem (t) 14:09, 22 March 2019 (UTC)
      • Deprecate |perpetrator= and add |convicted_perpetrator=. --Izno (talk) 14:15, 22 March 2019 (UTC)
        • That would of course mean that when the perpetrator dies and there is no trial, there is nowhere to add them. Which is not necessarily a bad thing. TompaDompa (talk) 17:28, 22 March 2019 (UTC)
          • I think we should find a way to identify the perpetrator in some such cases, for example if there is a mass shooting that ends with the perpetrator killing himself (it's nearly always a "him"). The best way to deal with this whole issue would be for Wikipedia to stop trying to be a news service and only to have articles about events when good secondary sources (which breaking news reports are not) exist, but people putting forward that point of view always seem to get shouted down by people saying, "of course it's notable, it's front-page headlines in all the newspapers." Phil Bridger (talk) 17:50, 22 March 2019 (UTC)
            • +1. Never lose the dream, even if forced to drop the stick. ―Mandruss ☎ 21:56, 22 March 2019 (UTC)
          • And in cases where the perpetrator dies and there is no trial I believe that there's a difference between jurisdictions. In some places an inquest into the death of a victim will name in its verdict the person who caused the death, and in others it will not. Phil Bridger (talk) 17:54, 22 March 2019 (UTC)

I support changing "perpetrator" to "convicted" - feels more appropriate for factual record rather than mere description of an event, and hypothetically if there was an appeal in process or new doubts over a historical case it wouldn't invite any unnecessary infobox changes. U-Mos (talk) 06:23, 23 March 2019 (UTC)

Changing Wikipedia's infoboxes because some politicians want to play damnatio memoriae is not a good idea. Offering a choice of a "convicted" field per User:U-Mos is reasonable, but a plain "perpetrator" field should remain as an option even so. Because sometimes, for example, a widely known perpetrator might flee to ISIS territory or the next equivalent and not be prosecutable. Suspected perpetrators also should be described when sources widely describe the accusation. (WP:WELLKNOWN) Wnt (talk) 07:42, 23 March 2019 (UTC)

I don't see how describing suspected perpetrators in the infobox, where the room for nuance is scant to none, would be helpful. In prose is a different matter. TompaDompa (talk) 10:34, 23 March 2019 (UTC)

Why not? There are a lot of cases where the perpetrator is known beyond reasonable doubt but will never be convicted. Judicial sentences are not the only reliable source of information. On contrary there are cases where the person convicted is known not to be the perpetrator! Would not it be helpful to describe convicted but not guilty persons in the inforbox where the room for nuance is scant to none helpful? You seem to put to much trust in formal convictions. In addition, what is conviction? There is no clear definition of this term. Ruslik_Zero 08:45, 24 March 2019 (UTC)

That a convicted person may not be the perpetrator seems a very good reason for the change to me. Having the field as "convicted" removes any form of supposition, leaving any nuances or complications to the prose where they can be outlined in all necessary detail. U-Mos (talk) 08:53, 24 March 2019 (UTC)

This is incredibly poor reason. 90% people do not read beyond the infobox. Ruslik_Zero 13:47, 27 March 2019 (UTC)

• Convicted is not quite the right answer. If the perp dies he is not convicted. If he confesses or brags/claims responsibility we can name without conviction. I'd venture that at least half the places this box would be used never see a conviction. Legacypac (talk) 09:28, 24 March 2019 (UTC)
  • Why's that an issue? If they die, and are therefore not convicted, do they need to be in an infobox? U-Mos (talk) 23:05, 25 March 2019 (UTC)
    • Yes, they need to be in the infobox because this is important information. Ruslik_Zero 13:47, 27 March 2019 (UTC)
      • +1 to LegacyPac's point about conviction being the wrong standard for this, with suicide bombings and most unprosecuted war crimes being two obvious cases where the perpetrator is known with certainty but there is no judicial process confirming guilt.--Carwil (talk) 17:15, 1 April 2019 (UTC)
• Creating an additional template for suspects and one for perpetrators would remove all the confusion. ^{~^\}\_\.rTG'{~ 23:35, 25 March 2019 (UTC)
• Oppose. In some cases it is appropriate for us to name the perpetrator prior to his conviction (e.g. when extremely widely reported in highly public events, or when the suspect evaded capture and trial (which in many places can't be done in absentia) - but it known with a high degree of certainty). In other cases - e.g. historic cases, events in warfare, etc - while we might not have a definite perpetrator it might still be appropriate to name in the infobox those covered extensively in RSes. Icewhiz (talk) 11:45, 2 April 2019 (UTC)
• The template should first be merged into {{Infobox event}}; then the parameters should be rationalised. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:40, 2 April 2019 (UTC)

Note: This proposal was restored from the archive for the purpose of consensus being assessed and the discussion closed. TompaDompa (talk) 22:31, 18 May 2019 (UTC)

• Not sure if this means it's still open for votes, but if so support per WP:NOTNEWS, etc. Any time it's actually warranted can be covered in article prose. – John M Wolfson (talk • contribs) 23:35, 18 May 2019 (UTC)

Proposal for a new file naming criteria: harmonize extension name

Hi. I recently came across some oddly named files, and it prompted me to do some digging. Below is a table of the number of images hosted locally on enwiki by file extension in the name:

jpg Extension Count .jpg 586975 .JPG 39738 .jpeg 20617 .JPEG 309 .Jpg 62 .Jpeg 16 .jPG 1 .JPeG 1 .JpG 1

png Extension Count .png 167198 .PNG 9677 .PnG 1 .pNG 1 .Png 1

svg Extension Count .svg 25507 .SVG 13

gif Extension Count .gif 21548 .GIF 749

tif Extension Count .tif 596 .tiff 402 .TIF 17

ogg Extension Count .ogg 9294 .OGG 24 .oga 1

Other Extension Count .pdf 476 .mid 146 .ogv 91 .bmp 65 .webp 48 .webm 40 .wav 31 .mp3 19 .xcf 15 .opus 9 .MID 7 .flac 2 .pov 1

You can see, for example, that JPEG files are split between .jpg, .JPG, .jpeg, .JPEG, .Jpeg, .jPG, and .JPeG, .JgP, while PNG files are split between .png, .PNG, .PnG, .pNG, and .Png. Even if the "jpg" vs "jpeg" shouldn't be standardized (I think it should be), I believe that the differences in capitalizations should be resolved, since file names are case sensitive. Thus, I propose the following new criteria, to be added to WP:FMV/W:

• Harmonize file extension format names to ease their usage

With the following extension name formats prefered: .jpg, .png, .svg, .gif, .tif, and .ogg. This is not a proposal to prefer a specific formatfile type over another, but rather to standardize the suffixes for files already of the same format. --DannyS712 (talk) 23:10, 29 May 2019 (UTC) (clarified 10:15, 27 June 2019 (UTC))

Survey (file format names)

• Support new criteria as proposer --DannyS712 (talk) 23:12, 29 May 2019 (UTC)
• Meh for most feel free to clean up the obvious ones with very low populations, but I really don't care to see 40,000 files renamed from JPG to jpg for example. — xaosflux ^Talk 23:40, 29 May 2019 (UTC)
• Oppose First, please establish a need for the change - for instance, does a variant extension mean that a file becomes undisplayable? Second, you say "harmonize file extension format names to ease their usage" - in what way would usage be eased? Third, this is unenforceable, since there are far more images hosted at Commons than here on English Wikipedia, and we cannot make a decision here that would change policy on Commons. --Redrose64 🌹 (talk) 10:15, 30 May 2019 (UTC)
• No thank you. I can appreciate the desire to keep things tidy and organized, and I give the OP credit for doing the research and crunching the numbers. But if the name/extension of a file isn't impeding its use in any way (and I don't see how it can be), then this is a make-work project that will annoy all the thousands of users who uploaded images to Enwiki with the "wrong" file extension without any improvement to the file, to its use in articles, to its usability. More importantly, the overwhelming number of files used on English Wikipedia are hosted on Wikimedia Commons, which does not have such criteria for files. In other words, there are still going to be tens to hundreds of thousands of images that *still* have the "wrong" file extension. It's not possible to enforce consistency on this. Risker (talk) 16:46, 30 May 2019 (UTC)
• Support - making the format names consistent will help in some situations where users might "fix" image files without realizing that the formats are case sensitive (because of course they are...), and as Danny says might also help users find files in some situations. There really is no down side to this. The "mark-work" is not placed on anyone, as I'm pretty sure Danny, as a person that helps out with bot requests, will do this themselves, and users should feel no more annoyed by this, as they would if an article or template was moved. Also, specifically, I'd hate to see files like "pNG" in a FA. Now that's annoying. --Gonnym (talk) 17:18, 30 May 2019 (UTC)
• Oppose per Redrose's comment about the proposed change not syncing with Commons and Risker's comment about make-work that annoys thousands. It was interesting to see the data about enwiki though, so thank you for posting them. Killiondude (talk) 19:34, 2 June 2019 (UTC)
• Oppose per Redrose and Risker. Thryduulf (talk) 17:43, 3 June 2019 (UTC)
• I see no good reason for this honestly... Maybe the mixed case versions would be acceptable to me, but the rest... It's just not an issue i regularly see people struggle with. —TheDJ (talk • contribs) 07:17, 4 June 2019 (UTC)
• Support basically per Gonnym. I see this as basically like an MOS-type thing. The source (the user who uploaded the file) may do things however they want in their personal usage, but Wikipedia will harmonize usage for itself. --Khajidha (talk) 22:10, 7 June 2019 (UTC)
• Oppose per Redrose and Risker.--Vulphere 17:24, 12 June 2019 (UTC)
• Support. Having spent a considerable amount of time on the related project of moving non-descriptive TLA-titles for Commons files to names descriptive of the file contents, it was surprising and unpleasant the degree to which file names for completely unrelated things could be identical but for capitalization of the filename extension. It is not technically difficult to make every filename unique irrespective of this capitalization, and we should do it. bd2412 T 02:07, 17 June 2019 (UTC)
• Weak Support - having been tripped up many times by suffix variations, and resolved several troubleshooting requests by new users who couldn't get an image to display (for this reason), I would appreciate this. That said, I think all of those cases I've been involved with were on Commons, not here. It would be ideal for this to happen there, too, but I just don't see any downside here. Assuming Danny is willing to tackle the particulars, I see no reason to get in the way. I don't really see "annoyance" as a reason not to do this, either. Anyone dedicated enough to their watchlist to care about such a thing should know how to hide bot edits. — Rhododendrites ^talk \\ 18:00, 23 June 2019 (UTC)
• Support, but iff such changes are synchronized on/with Commons. Headbomb {t · c · p · b} 21:35, 29 June 2019 (UTC)

Discussion (file format names)

Notified: Wikipedia talk:File names, Wikipedia talk:File mover DannyS712 (talk) 23:12, 29 May 2019 (UTC)

• See also: c:Commons:Village pump/Proposals/Archive/2018/12#Normalize file extensions for new uploads
• @Redrose64: file extensions are case sensitive - for the 749 .gif files that are named as .GIF, users must remember to capitalize the file extension. The data above only deals with files that are hosted locally, and it would be easier to use local files if extension names were consistent. --DannyS712 (talk) 16:10, 30 May 2019 (UTC)
  • I'm having a hard time wrapping my head around this explanation. Do people *really* enter the entire file name by hand including extension when searching for/inserting a file? They don't use the search function? They don't copy/paste the file name? Risker (talk) 16:39, 30 May 2019 (UTC)

    I do, and others probably do so too, or even if they don't it would be easier to do so if extensions were standard --DannyS712 (talk) 16:41, 30 May 2019 (UTC)

    I don't see how this would make copying and pasting any easier or harder than it is with inconsistent names. Phil Bridger (talk) 18:04, 30 May 2019 (UTC)

    File extensions are case sensitive on Wikipedia and some operating systems like Unix. But on Windows-type setups, they are case-insensitive. If you use a Windows application like MS Paint to create an image, then when you come to save the file for the first time you get a dialog box which includes a selection for the file type. The selection that you make will set the file extension, and it's always uppercase (you can use Explorer or similar to rename the file with a lowercase extension later on, and it won't make any difference as far as Windows is concerned - but not all users will bother to do that). Who are we to say that lowercase is the only correct form? Do Unix browsers reject uppercase file extensions? --Redrose64 🌹 (talk) 22:18, 30 May 2019 (UTC)

    @Redrose64: I don't use a unix system, and I am explicitly not saying that lowercase only is the correct form. All I suggest is that the extension formats be consistent. This should make absolutely no difference to users (such as yourself) that copy-and-paste the file name, but for users that want to type the file name, it should be consistent. If (not a part of this proposal) a bot were to execute the file moves, meaning that there wouldn't be any extra work for users, what downsides would you see from harmonizing the formats? I understand where the differences come from (thanks for that explanation by the way) but that doesn't mean that they should be kept. --DannyS712 (talk) 07:20, 17 June 2019 (UTC)

• I really don't see any value to this proposal, other than making things look tidy, which, if you looked at my desk, you would see is not something that I rate highly, so it would be better if people spent their time on doing something that actually improves the encyclopedia rather than on such make-work projects. Phil Bridger (talk) 18:04, 30 May 2019 (UTC)

Moving the file to the consistent file names could be automated by a bot (leaving a redirect), except if the filename is already in use. --Chanc20190325 (talk) 18:05, 1 June 2019 (UTC)

But why do it? What benefit does this bring to Wikipedia, especially when most of the files we use are are hosted at Commons? Phil Bridger (talk) 18:48, 1 June 2019 (UTC)

To clarify: the above data is for images that are hosted here on enwiki. I've added the data for commons below. --DannyS712 (talk) 06:03, 3 June 2019 (UTC)

Commons data

jpg Extension Count .jpg 38954436 .JPG 7115025 .jpeg 722895 .JPEG 7176 .Jpeg 961 .Jpg 583 .jPG 47 .JPg 24 .jpG 15 .JPeG 7 .jPeG 7 .JpEg 5 .JpG 3 .jPg 2 png Extension Count .png 2473405 .PNG 125542 .Png 34 .pnG 2 svg Extension Count .svg 1493642 .SVG 507 .Svg 4 gif Extension Count .gif 167101 .GIF 5515 .Gif 16 .gIF 1 tif Extension Count .tif 1110594 .tiff 200199 .TIF 3357 .TIFF 16 ogg Extension Count .ogg 919282 .oga 7166 .OGG 312 .Ogg 15 pdf Extension Count .pdf 443407 .PDF 867 .Pdf 1 webm Extension Count .webm 71003 .WebM 36 .WEBM 4 .Webm 1 djvu Extension Count .djvu 108225 .Djvu 2 .DJVU 1 wav Extension Count .wav 127401 .WAV 26 ogv Extension Count .ogv 69589 .OGV 15 mid Extension Count .mid 5056 .MID 314 Other Extension Count .flac 15305 .mp3 8571 .xcf 1283 .stl 1022 .webp 670 .opus 661

• See also a related discussion - Wikipedia:Village pump (proposals)/Archive 74#Several changes to file naming --DannyS712 (talk) 10:59, 10 June 2019 (UTC)

“Thank” button in signature.

I suggest adding a “thank” button in the Wikipedia signature to be able to thank faster without searching the revision history. Example: –Chanc20190325 (talk • thank) 13:55, 2 June 2019 (UTC)

• Oppose. Benefit: Saving of perhaps 20–30 seconds for most thanks, for the small fraction of comments that receive thanks. Cost: About 35 characters of additional markup in the wiki editor window, for every comment posted by a registered editor using the default signature. Cost exceeds benefit. AFAIK there is nothing currently in signature policy to preclude this in a customized signature. ―Mandruss ☎ 14:34, 2 June 2019 (UTC)

  @Mandruss: Except from a technical standpoint, thanks depends on REVISIONID data, which can not be substituted. So while you could link a link to thank me for something static I did in the past (e.g. (CLICK HERE TO THANK ME FOR BEING THE BESTEST) you wouldn't be able to thank me for the edit related to that instance of the signature. — xaosflux ^Talk 16:07, 2 June 2019 (UTC)

  I think you're saying that this would be impossible in a customized signature. I can live with that. ―Mandruss ☎ 16:40, 2 June 2019 (UTC)

• Oppose. I really do not think it's necessary, maybe it will save you a few seconds, but I think the editors are here to improve Wikipedia and not for recognition.--AnbyG (talk) 08:41, 3 June 2019 (UTC)
• Comment - I like the idea, but also get that adding additional markup/text in each instance of a signed comment could add up to a lot. I wonder if there's a way to handle this with a script for those who want it? Perhaps pulling a diff based on the timestamp/name? — Rhododendrites ^talk \\ 20:18, 4 June 2019 (UTC)
• Oppose per others. Millbug ^talk 03:27, 7 June 2019 (UTC)
• Oppose per others.--Vulphere 17:26, 12 June 2019 (UTC)
• @Enterprisey: Did you have some gadget which provided this functionality? I thought that you did. Blue Rasberry (talk) 19:35, 12 June 2019 (UTC)
• Leaning oppose. The vast majority of times that I thank someone, it is because I am already looking at the specific diff to see what they've added. I don't know if this is the common experience, but surely I can't be the only one doing that. bd2412 T 02:10, 17 June 2019 (UTC)

  I'm the other one, you're not crazy. InedibleHulk (talk) 02:40, June 24, 2019 (UTC)

• Oppose, but might be a good idea for a user script. Anne drew 14:02, 19 June 2019 (UTC)
• Oppose The easier it gets to thank people, the less genuinely thankful other people need to be to instaclick a button, and the more our notification feed is oversaturated with platitudes from merely suggestible folk. You think Kanye West feels any sort of joy when he gets a like, thumbs up or booty call anymore? It could happen to any of us in the public eye, best to set a simple impulse barrier, like we have. InedibleHulk (talk) 02:35, June 24, 2019 (UTC)
• This could definitely be written, but the script would have to dig through the page history to figure out when a particular comment was added. If there's enough demand, let me know. Enterprisey (talk!) 05:14, 24 June 2019 (UTC)

A new use for Wikidata external IDs in Wikipedia (template)

I would like to propose a new template which would make a more visible use of the external identifiers contained by Wikidata. Similarly to Authority control and Taxonbar, it would collect the IDs leading to pages which expand on the subject with additional text (so not only data) like encyclopedias, biographies, etc. This would create a condensed portal to trustworthy sites and could:

• encourage further reading
• propagate and show reliable sources
• make Wikidata more visible
• add depth to article stubs, help finding sources for expanding them

Visually, I would imagine that the template could follow (or be part of) the infobox or it could be a sidebar next to the External links section. It could also be set as default to the language of the Wiki it is used in so in the German Wikipedia it would only list (or prioritise?) German language sites.

Two examples for what the template would contain (here without the language setting):

• Hannah Arendt: Encyclopædia Britannica, American National Biography, Stanford Encyclopedia of Philosophy, Internet Encyclopedia of Philosophy, FemBio, Encyclopaedia Herder, Gran Enciclopèdia Catalana, Cultureel Woordenboek, Encyclopædia Universalis, Wien Geschichte Wiki, Great Russian Encyclopedia, Enciclopedia delle donne, Treccani Enciclopedia, Enciclopedia Italiana
• Cyberpunk: The Encyclopedia of Science Fiction, Techopedia, Giant Bomb, Encyclopædia Britannica, Computer Desktop Encyclopedia, Nationalencyklopedin, Store norske leksikon

From the side of Wikidata I think it would require:

• labeling external IDs according to content type (new property)
• labeling language of external IDs (mostly done)

From the side of Wikipedia:

• template coding, design
• documentation of the template

What do you think? Please also indicate if you would like to help in the development. - Adam Harangozó (talk) 13:04, 9 June 2019 (UTC)

• Mixed opinion - I have no problem with templates that export data from Wikipedia TO Wikidata... I continue to oppose templates that would automatically import data FROM Wikidata. I see no benefit to our project in this proposal. Blueboar (talk) 13:15, 9 June 2019 (UTC)

  Does it follow that it takes use cases that show how Wikipedia will benefit from data FROM Wikidata or is it just that you are against? Thanks, GerardM (talk) 17:31, 9 June 2019 (UTC)

  Blueboar, if you see no benefit for Wikipedia readers to get curated links to high-quality third-party sources, then perhaps the problem is your vision, and not Wikidata? --Magnus Manske (talk) 08:35, 10 June 2019 (UTC)

  I see great benefit to including curated links... but the curation has to be done manually, here on WP... not automated through WD. Blueboar (talk) 11:14, 10 June 2019 (UTC)

  What makes you think curation on WD is "automated"? There are certainly more bots and tools involved, but mostly because WD is easier to edit through those. Tools like Mix'n'match do a combination of manual and automated (where highly reliable) curation. Claiming WP is, overall, better at curation is insulting at best. --Magnus Manske (talk) 14:05, 10 June 2019 (UTC)

  You miss the point... the curation needs to be done HERE on WP... not at WD. Blueboar (talk) 14:28, 10 June 2019 (UTC)

  The first round of curation is done on Wikidata: already the fact that there is a property for that external ID means that there was a consensus about its importance. Also, if we label it there as having descriptive text is another round of filtering. After this the export would be automatic but I think there should be an option to manually exclude IDs from the template in the article. Adam Harangozó (talk) 17:54, 11 June 2019 (UTC)

  ”The first round of curation is done on Wikidata”... exactly... that is what I object to. Blueboar (talk) 22:30, 18 June 2019 (UTC)

• Oppose any further automatic import from Wikidata. To pick up Magnus Manske's phrase, the problem is that a lot of links in Wikidata are not curated links to high-quality third-party sources. The "curation" is far less than here, as there are far fewer active editors. There's isn't the body of long-established and widely discussed policy which defines what a "high-quality third-party source" is, as opposed to the policies on sourcing here. Peter coxhead (talk) 09:07, 10 June 2019 (UTC)

  I protest this (deliberate?) mis-quote. The display of WD data on WP would be automated. The curation on WD is a mixture of manual (as here on WP, but with better tools) and automated (where highly reliable). Please change to Support, or remove me as your reasoning. --Magnus Manske (talk) 14:08, 10 June 2019 (UTC)

  I believe that most of the external IDs collect reliable sources but even if there are exceptions this could be sorted out when labeling their content type on Wikidata and any problematic source could be removed manually from the template later. An overview of some of the sites that are being worked into WD (here only the biographies): https://tools.wmflabs.org/mix-n-match/#/group/biography Adam Harangozó (talk) 18:05, 11 June 2019 (UTC)

• Support: I believe this is an important step towards the main goal of Wikidata: to feed sister projects with structured data. --Hjfocs (talk) 09:08, 10 June 2019 (UTC)
• Support: but with a couple of caveats. Number of external IDs (too much ?), language of external IDs (Russian or Italian less helpful in WP-En), probably this project would benefit from some design and curation work on the WD side. Kpjas (talk) 09:24, 10 June 2019 (UTC)
  • probably this project would benefit from some design and curation work on the WD side – yes, but that's the problem for me. Who is going to do this work? Consider {{Taxonbar}} as an example. This template is now present on the great majority of articles about organisms. My experience is that when I create a new organism article (I mostly work on plants and spiders), on average I have to spend quite a bit of time (perhaps one third to half the time to create a "Start" class article) fiddling with Wikidata items to get the taxonbar to work as it should in our article – and quite often it's not entirely possible, because the design principles of Wikidata are not compatible with ours (e.g. insisting on 1:1 relationships between wiki articles and Wikidata items, when this is not how it actually is). So the odds are that if the curation of Wikidata were done well, it would involve considerable continued input from editors here, which distracts from the main goal of building an English language online encyclopedia. If there were lots of receptive editors at Wikidata, open to discussions, it would be a different matter. But that's not my experience. Peter coxhead (talk) 10:06, 10 June 2019 (UTC)
    • I really think this could be more constructive. Of course there might be issues but WD are WP are for each other not against. The 1:1 relationship would work with articles about individual people, and the others we might need to work on more - from both sides. Also, please check Elmidae's opinion below. Adam Harangozó (talk) 18:22, 11 June 2019 (UTC)
  • The number of IDs shown is a design question regarding the template on Wikipedia (sidebar, navbox, collapsing, etc.). The languages have to be tagged in Wikidata but as I said I think the template should only show IDs that are in the language of the WP article. (This would also keep the numbers at bay.) Adam Harangozó (talk) 18:22, 11 June 2019 (UTC)
• Oppose per Peter coxhead. This scope creeping by Wikidata aficionados needs to stop and they need to get their own house in order. We have enough maintenance problems here without importing more from somewhere else. - Sitush (talk) 10:50, 10 June 2019 (UTC)
• Neutral middleground Hi all, there is a grant project that could help out here called GlobalFactSync (GFS). The major problems are: (a) On the one hand, Wikidata is not considered good enough yet to be imported into WP-EN, so GFS tries to sync all info from WP-EN into Wikidata to improve it. (b) On the other hand, Wikidata is used in exactly the proposed way in the Italian Wikipedia, see Usain_Bolt#Collegamenti_esterni GFS just started, but discussion as such seem very relevant. We are looking for 10 concrete sync targets. One will be the domain of Albums/Singles with MusicBrainz. So another one could be the links to the external sites mentioned above. The goal is to improve Wikidata in these sync targets to a level that meets WP-ENs standards and then make it much easier to maintain, so quality stays better than now and work becomes less. GFS just started, so we will still need good feedback. SebastianHellmann (talk) 12:08, 10 June 2019 (UTC)
  • Thanks, I'll check this out. Though I think it would be important to have this as a separate template and not to mix it with the external links section. Adam Harangozó (talk) 18:25, 11 June 2019 (UTC)
• Support. Please inform yourself about Wikidata before tossing a vote because you heard your buddy say "WD is bad". Don't make this another Brexit referendum; there, it was all the EU's fault... --Magnus Manske (talk) 14:11, 10 June 2019 (UTC)
• Support. Indeed a good idea and it is definitely too simple to claim one wiki project to have in general beetter quality than another one it just depends on the topics and often just the individual item or article. Unfortunately users tend to see the projects they are deeper involved with in a much more positive way than other projects they are less involved in. Robby (talk) 16:22, 10 June 2019 (UTC)
• Weak support I share the concerns about the reliability and curation of Wikidata. This does not reflect on the work of the editors on that project, but on the fact that there are so many fewer eyes on harder-to-curate material. For most purposes, WD import into WP still seems like a dangerous proposition. - Having said that, this particular proposal sounds largely innocuous to me. As with WP, the main issue with misleading material in WD is statements that are not backed up by sources. Bypassing any import of statements and directly linking to sources avoids this step (and it is the step where shit mostly happens, if it does); and readers must always be capable of assessing sources for themselves. This would in effect work like an extended "External links" section, and probably of overall better quality than that. --Elmidae (talk · contribs) 18:04, 10 June 2019 (UTC)
• Too soon to ask. I think this proposal, while well-intentioned, needs some more workshopping before we can come to a reasonable conclusion. For example, is the proposed new property of external ID content type something that Wikidata wants, and how will this be implemented? What types of IDs would we import and what types would we exclude? What happens if someone disagrees about importing a particular ID? Will it be possible to exclude it on the article level, on a more global level? Would there be overlap with the existing {{authority control}}, which already imports some external IDs from Wikidata? How will this proposal interact with WP:EL? Will there be a max number of links imported? For the moment until some of these questions are answered I will oppose the proposal, but I'd encourage some more work in conceptualization with an eye to a future proposal. I'd also expect that such a template would need a broad RfC before widescale implementation. Nikkimaria (talk) 00:51, 11 June 2019 (UTC)
• Support per many of the above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:19, 12 June 2019 (UTC)
• Oppose would directly violate WP:EL - which requires external links are justified on-wiki on their merits. A template drawing through whatever Wikidata is deciding to host today doesnt fulfil our editorial criteria. Most of the examples above would fail point 1 of WP:ELNO. As an aside two of the links above triggered my virus scanner for malware/popup-ads. Only in death does duty end (talk) 21:30, 12 June 2019 (UTC)
  • The proposal is not "whatever Wikidata is deciding to host today, but links to a set of sites curated here on Wikipedia, much as is already done in {{Authority control}} or {{Taxobar}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:57, 18 June 2019 (UTC)
    • Unless you get the wording of WP:EL changed its dead in the water for the above already mentioned reasons. Only in death does duty end (talk) 22:35, 18 June 2019 (UTC)
• Oppose. The issues I list below range from "difficult" to "effectively impossible" to resolve, and the list clearly incomplete:
  • Wikidata content is not subject to Wikipedia policies and guidelines, including but not limited to WP:EL. Challenged External Links are removed and stay-out unless there is an active consensus for inclusion.
  • Any such content needs to be administered on Wikipedia.
    • Even non-autoconfirmed editwarrior or vandal can go to Wikidata and BYPASS Full page protection. An IP editor could even bypass Superprotect (if it were redeployed). This is a fundamental design problem with Wikidata integration.
    • Page protect at Wikidata can prevent us from repairing policy violations on our articles, even if Nazism or pedophilia related content is maliciously placed on the biography of a living politician.
    • It bypasses our editfilters and link blacklists.
  • Any such content needs to be curated on Wikipedia.
    • It's impossible to find (and potentially clean up) these links, as they don't show up in search results.
    • A significant number of editors here are are uninterested or unwilling to go to Wikidata to edit.
    • It makes things more difficult for new users - and even for many experienced editors. The content magically appears in the article, and it can be confusing to figure out where the hell it's coming from. And once you do find where it's coming from, Wikidata imposes a different and potentially confusing interface that is (in my experience) functionally deficient. To anyone who is happy with Wikidata and the Wikidata interface: Good for you. Not everyone agrees with you, and it creates an additional and unnecessary hurdle for those who don't agree with you.
  • The majority of Wikidata edits are essentially a bot-farm, with some human edits intermingled. Note: Wikidata "editor" statistics are wildly inflated. For example when a page tracked by Wikidata is moved, that edit gets mirrored as a Wikidata edit by that user.
  • We really don't need the headaches of cross-language editwarfare. In particular, there's currently major drama at Meta involving a language-wiki where essentially the entire admin corp are waging "information warfare" of genocide denialism. Note that Google Translate for the language is abysmal and often reverses the meaning of a sentence, making any sort of discussion almost impossible. Alsee (talk) 07:22, 16 June 2019 (UTC)
  • The huge RFC on Wikidata-in-infoboxes ended with approximately half of the community wanting Wikidata gone from infoboxes. We should not be rolling forwards major Wikidata integration until we can reach some consensus on whether we want to keep or eliminate the existing integration. Alsee (talk) 07:22, 16 June 2019 (UTC)
  • Again: The proposal is for links to a set of sites curated here on Wikipedia, much as is already done in {{Authority control}} or {{Taxobar}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:57, 18 June 2019 (UTC)
• I love the idea of using Wikidata more on Wikipedia. I've read through your proposal a few times, and I'm not really sure exactly what it is you're proposing; could you produce a few mockups to illustrate your idea? --Deskana (talk) 21:15, 16 June 2019 (UTC)
• Support.--Vulphere 05:52, 27 June 2019 (UTC)

RfC: Deprecate webcitation.org aka WebCite

This RfC is to allow editors and archive bots the voluntarily leeway to stop using webcitation.org and replace existing webcitation.org URLs with other archive providers where available. To begin divesting from WebCite. 14:49, 13 June 2019 (UTC)

Background:

• Approximately 5% of Enwiki archive URLs are to webcitation.org, 5% to archive.today, 2% to "others" (Library of Congress, etc), and 88% to archive.org - in raw numbers there are about 5 million archive links of which about 250,000 to are to webcitation.org
• webcitation.org is unreliable. Talk:WebCite#Service_outages lists known outages and there have been others. Outages can last for days and weeks.
• WebCite is a non-profit and almost shut down in 2013 due to lack of funding. The site has not changed since - documents, features, bugs etc.. no evident development of the service or changes to the website in years. Bug reports go unanswered and unresolved. It appears to be the work of Gunther Eysenbach and not a full-time occupation.
• WebCite is one of the oldest archiving services. It was unique for archiving on-demand vs. automated crawling. On-demand archiving is now available at Wayback, Archive.today etc.. a standard feature at most archive services. There is nothing that sets WebCite apart that other archives can not do, and do better.
• WebCite uses a system of accepting archive requests, returning an archive URL, backgrounding the job then emailing if the archive was successful or not. Often users submit a job and get the URL and paste it into Wikipedia without waiting to see if the archive request was successful. As a result:
• WebCite has the highest rate of archive link rot. My bot WaybackMedic monitors archive links and WebCite is the leader in terms of raw numbers of links that need replacing with other archives, despite only representing 5% of the total archives.

Proposal:

• Archive diversity is important. WP:WEBARCHIVES lists about 20 archive providers currently in-use on Enwiki. Plus, not every archive has every page, some will have a page that others do not (eg. archive.org does not have everything). In the end it is up to users which archive provider they choose.
• This RfC would demonstrate a general best practice of avoiding and/or changing WebCite URLs to other archive providers. Deprecate does not ban the site or make a hard red-line rule. It would give users and bots some leeway to begin changing URLs and point to this RfC as a rationale. It would change the documentation to encourage users to use a different provider. Users who still wish to maintain a WebCite URL can add {{cbignore}} to keep bots away and act as a notice to maintain the URL. If WebCite is the only source for an archive it should obviously be kept and not converted into a {{dead link}}. -- GreenC 14:49, 13 June 2019 (UTC)

Survey (deprecate WebCite)

• Support per above and survey bump. -- GreenC 14:49, 13 June 2019 (UTC)
• Support I used to use WebCite but Wayback does everything it did, and better.-- Pawnkingthree (talk) 16:34, 13 June 2019 (UTC)
• Support per the above. Kudos to the initiator for one of the best written proposals I've seen on Wikipedia. Thryduulf (talk) 21:43, 15 June 2019 (UTC)
• Support. It's clearly beneficial both to readers and editors to prefer archive sites which are more stable and actively maintained, if they are equivalently archiving the content. Alsee (talk) 06:06, 16 June 2019 (UTC)
• Support It is out of service again and is unreliable due to its outages. The archive for links that are dead needs to be reliable. Ahmad^Talk 16:29, 16 June 2019 (UTC)
• Support its better to use a archive website which is more reliably up, so that our readers can nearly all of the time see the archived source. I agree that outright banning of WebCite is a bad idea, as diversity in archive websites is a good thing, but conversion to Wayback is something which (unless WebCite becomes more reliable) needs to be done. Dreamy Jazz 🎷 ^{talk to me | my contributions} 21:16, 18 June 2019 (UTC)
• Support - per above. ___CAPTAIN MEDUSAtalk 17:58, 19 June 2019 (UTC)
• Oppose for the reasons I wrote below. All of the arguments given here are why other archivers are better than WebCite. They aren't reasons why WebCite is useless or detrimental except insofar as there is a better alternative. My position is that the best solution would be making it so that we can use multiple archivers. Redundancy. A citation has a WebCite archive? Add one for archive.org and archive.to. There are problems with all of them. That's not to say that the others aren't overall better, but that it doesn't need to be a choice. If we can use multiple, nothing is gained by removing WebCite. — Rhododendrites ^talk \\ 05:16, 20 June 2019 (UTC)
• Support; at the very least, using WebCite to save pages that are currently live should be discouraged since better options are clearly available. Jc86035 (talk) 10:48, 20 June 2019 (UTC)
• Support - Seems like a reasonable proposal. Editors can continue to use "WebCite" if they wish, it just wont be via bot. - Knowledgekid87 (talk) 16:25, 20 June 2019 (UTC)
• Support - There are no indications that the situation with WebCite will improve in the future; instead, it is reasonable to expect further deterioration. — kashmīrī ^TALK 09:54, 22 June 2019 (UTC)
• Support - I think that WebCite has to be given full credit (with citations :)) for (apparently) being a pioneer in on-demand URL archiving. I'm not sure how to do that, apart from solidifying its Enwiki entry. But unless the WebCite maintainer(s) very quickly inform Wikipedia (or the world) about a major overhaul and long-term sustainability project and convince us that the probability of future down time will drop to very low, this proposal makes sense. The world of knowledge should not be dependent on a single well-intentioned, hardworking individual. See the discussion section below for a related proposal of implementation, which seems to implement Rhododendrites' point above: add archive1url, archive1date, dead-archive1url, archive2url, archive2date, dead-archive2url, ... parameters to the standard citation template; possibly retain the WebCite urls but convert them to archive2url, archive2date, dead-archive2url=yes. [Comment: I have added a huge number of WebCite urls to Enwiki and I'm hoping that webcitation will return to online status at least long enough to make sure that alternative archival backups can be created. A lot of articles risk being greatly weakened without archival references, and this especially affects WP:BIAS.] Boud (talk) 16:43, 22 June 2019 (UTC)
• Support per above.--Vulphere 05:50, 27 June 2019 (UTC)
• Support per above. Johnbod (talk) 00:38, 2 July 2019 (UTC)

Discussion (deprecate WebCite)

• Comment Could we have a list of the other web archiving sites available? Personally, I am only aware of https://archive.is/ In my experience it's not true that they all do everything. Some may capture greater depth in terms of links off the selected url which may be necessary for context. They also don't all capture the same content, for instance, webcite captures pdfs, unlike archive.org. Philafrenzy (talk) 22:00, 13 June 2019 (UTC)
  • Wikipedia:List of web archives on Wikipedia Graeme Bartlett (talk) 23:16, 13 June 2019 (UTC)

    Thanks, the number on that list allowing on-demand archiving, which is what we are principally concerned with here, is small is it not? Philafrenzy (talk) 01:13, 14 June 2019 (UTC)

  • Archive.org captures PDF so does archive.today (ie. archive.is) and most of the others. This RfC concerns webcitation.org which does not work at all. Like, right now. It is a dead site, forcing 250,000 links on Enwiki offline. For about a week and counting. This is not the first or even fifth time. It is unadvised to use it if other equally good options are available. -- GreenC 00:42, 14 June 2019 (UTC)
• @GreenC: This RfC is not showing properly at Wikipedia:Requests for comment/Wikipedia technical issues and templates, so in accordance with WP:RFCBRIEF (sentence beginning "If the RfC statement is too long"), please provide a brief and neutral opening statement. --Redrose64 🌹 (talk) 22:12, 13 June 2019 (UTC)

  User:Redrose64: This RfC is to allow editors and archive bots the voluntarily leeway to stop using webcitation.org and replace existing webcitation.org URLs with other archive providers where available. To begin divesting from WebCite.

  -- GreenC 00:31, 14 June 2019 (UTC)

  OK, after JJMC89 (talk · contribs) did this, the effect is this. --Redrose64 🌹 (talk) 15:57, 14 June 2019 (UTC)

• Is there a reason that we shouldn't add the website to the blacklist at this time? Replacement first? --Izno (talk) 00:31, 14 June 2019 (UTC)

  (moved from survey section). There are times it is the only archive provider for a given page, it is worth keeping in the toolchest, for now, but make it a last resort and begin the process of moving away where possible. -- GreenC 00:51, 14 June 2019 (UTC)

  • Also, adding to the blacklist can have the effect of making it difficult to edit any article that includes a link to this site. Risker (talk) 21:54, 15 June 2019 (UTC)

• Comment WebCite has one very important feature: it allows you to request archiving a page, and returns an archive URL. To the extent I know, archive.org does not have an on-demand archiving feature (and I'm not sure if any of the other alternatives have this feature either). In light of this, I don't think banning WebCite is a great idea. huji—TALK 18:49, 16 June 2019 (UTC)
  • @Huji: archive.org does have an on-demand archiving feature (go to https://archive.org/web/ and use the "save page now" option in the bottom right). Archive.is (AKA archive.today) also does archiving on demand (from the main page of that site). I'll do them for this page immediately after this comment and add the links in my next edit. Thryduulf (talk) 23:30, 16 June 2019 (UTC)
    • links: Archive.org Archive.today. Thryduulf (talk) 23:32, 16 June 2019 (UTC)
      • @Thryduulf: sorry, I meant to say that it does not have an "automatable" way of requesting pages. For instance, on fawiki we are currently using the webcitation Python library in this Pywikibot script to archive all links on pages that are being promoted to GA or FA (so that future readers of our "best" articles will have a way to access their references in the future). This cannot be done robotically using Archive.org because (to my knowledge) it does not have an API for requesting page archives. huji—TALK 23:37, 16 June 2019 (UTC)
        • user:InternetArchiveBot has options that I think might be what you are looking for (submitting live links to the internet archive), Cyberpower678 is the person to ask about that I believe. [1] also seems to suggest APIs are available. Thryduulf (talk) 00:22, 17 June 2019 (UTC)

          Thryduulf, Yes. IABot has authorized access to the advanced SPN2 APIs. Regular users have open access to the SPN APIs. archive.org allows for automated archiving of weblinks. Also archive.org already does this for all 900 WMF wikis. —CYBERPOWER (Chat) 00:29, 17 June 2019 (UTC)

• Comment - It seems like the best approach would be to allow use of as many of the archives as possible, no? Archive.to has its own problems, after all (previously blacklisted, with multiple RfCs ending in its allowed use, preferred by some users while avoided by others, etc.). Wouldn't discrete parameters and redundant archives be the surest bet against linkrot? — Rhododendrites ^talk \\ 19:41, 16 June 2019 (UTC)

@Rhododendrites: (moved from the survey to discussion section). Yes the RFC proposal says exactly this, you can use WebCite, if you want. But there are good reasons to deprecate. Deprecate does not mean "you must not use" or blacklist, it means archive of last resort and default switch to others when possible. It isn't about picking favorites, I really do wish WebCite were available and reliable. -- GreenC 01:37, 17 June 2019 (UTC)

Aside: not sure why, but this didn't generate a notification for some reason? Yes the RFC proposal says exactly this ?? I said we should allow use of as many archives as possible. This is a proposal to not use a particular archive. Regardless of whether it's a suggestion or a hard rule, all of the reasons are predicated on the idea that we shouldn't use it because others are better. I say we shouldn't have to choose one over another. The best solution is finding a way to take advantage of all of them. WebCite may not be as good as another service, but WebCite and that other service is better than either one. If you see a WebCite citation, supplement it with an archive.to and/or archive.org; none of these are reasons to replace. — Rhododendrites ^talk \\ 05:10, 20 June 2019 (UTC)

@Rhododendrites: WebCite is offline. http://webcitation.org is dead. Maybe they will come back? These extended outages are not new, though I've never seen it go this long. The outages are getting longer, more frequent, the site is not maintained or updated.. no updates or news on Twitter or anywhere about what is happening. Emails to the owner go unanswered (as always). So I'm confused why you said "all of the reasons are predicated on the idea that we shouldn't use it because others are better". Unless by better you mean "not dead". -- GreenC 16:07, 20 June 2019 (UTC)

@Rhododendrites: It seems to me you're making a proposal for a modification of Wikipedia:Citation templates: allow the use of multiple archival parameters, e.g. archive1url, archive1date, archive2url, archive2date, ... The more critical a Wikipedian thinks that the reference is, the stronger his/her motivation to list at least two archived copies of the reference. A maximum number of archives should probably be set - 2 or 3? By default, the second and subsequent archivenurls would be hidden or semi-hidden from the reader; if the archive is long-term dead, then a bot could easily swap between them. A simpler possibility could be to add a dead-archive1url, dead-archive2url, ... parameter, similar to the present dead-url=yes|no. This proposal might let robots add new archive1urls while converting existing Webcite archiveurls to archive2urls with dead-archive2url=yes, rather than deleting the webcite urls. This would be useful for cases where Webcite has a good quality copy (in terms of avoiding javascript rubbish, zillions of external scripts, and so on) but the other archiver doesn't. Boud (talk) 16:28, 22 June 2019 (UTC)

This already exists with {{webarchive}} which supports up to 10 archive URLs and was made for this purpose.

{{cite web |url=http://example.com |title=Example website |archiveurl=http://web.archive.org/web/20190101000000/http://example.com |archivedate=2019-01-01}} {{webarchive |format=addlarchives |url=http://archive.today/20190609163259/http://example.com/ |date=2019-06-09 |url2=https://wayback.archive-it.org/all/20190621232545/http://example.com/ |date2=2019-06-21}}

Produces:

"Example website". Archived from the original on 2019-01-01. Additional archives: 2019-06-09, 2019-06-21.

To be honest though few people use it, and not many people add archives at all much less worry about redundancy. I wouldn't worry too much about it, bots can replace dead archive URLs with other archive URLs. My bot could fix the WebCite problem in a couple weeks if needed and so can IABot. We have bots for this. The only question is how many of these URLs are unique to WebCite that no other archive provider has, thus are irreplaceable. This is an open question that will be answered once the bots start replacing URLs. -- GreenC 16:57, 22 June 2019 (UTC)

Thanks for sharing this. First time I've seen {{webarchive}}. I think it would be better built into the citation templates, but that the functionality exists is good to know. I do still feel like we (or maybe just I) don't have the sufficient information to write off WebCite for good. Unless we know it's gone forever, if it's the lone archive of a page, a temporary broken link seems preferable to none. If it's not the lone archive, it would be just as easy to supplement it with another archive as it would be to replace it. — Rhododendrites ^talk \\ 18:05, 23 June 2019 (UTC)

It's nice to know this already exists. I don't expect that I'll be paranoid enough to use it often - it's enough work to add a single archive for each reference. But we'll see: I wasn't paranoid enough to expect webcite to have such a long down time... Boud (talk) 00:56, 24 June 2019 (UTC)

Manual of Style for fictional characters?

Hello. Back in 2012, we discussed a possible MoS proposal on fictional characters at WP:MOS/VG and Sergecross73 (talk · contribs · blocks · protections · deletions · page moves · rights · RfA) and I made a proposal for fictional characters, using the WP:MOSANIME as a reference. A few months ago, I also proposed and withdrew an RFC here. Long story short, one of these suggestions is to propose some sort of manual of style for the fictional characters. I'm planning to open a centralized discussion to see how we can manage a MoS regarding all fictional characters (i.e. Video games, anime, novels, TV series, films, etc.). Thoughts? Lord Sjones23 (talk - contributions) 22:46, 18 June 2019 (UTC)

• Is this meant to solve some actual problem not already covered by the MoS or some other guideline? Curly "JFC" Turkey 🍁 ¡gobble! 22:58, 18 June 2019 (UTC)

  Yes, there are a lot of disputes related to whether or not fictional characters should have their own article spun out, and there have been for many years now. It aims to give guidance with that. Sergecross73 msg me 23:08, 18 June 2019 (UTC)

  Sergecross73 how is that a MoS issue? MoS doesn't deal with content. Curly "JFC" Turkey 🍁 ¡gobble! 00:28, 19 June 2019 (UTC)

  Look, I don't care where its hosted, or even if my guidance in particular is used. I want there to be a wide-ranging discussion where we can get an enforceable consensus, because the recurring disputes in the area are both a massive time sink and a source of sour feelings among many disagreeing-but-very-good-editors. Sergecross73 msg me 01:00, 19 June 2019 (UTC)

  What are the recurring disputes? Why would having a character MOS be more effective at preventing them than letting the MOS for the various media set their own guidelines? Argento Surfer (talk) 13:10, 19 June 2019 (UTC)

  My two comments above just explained the problem and what I wish to accomplish. I don’t understand why this is so hard to understand. I’ve observed years of disputes and I wish to cut down on them. This is all very bizarre. I’ve never encountered so much skepticism for a desire to solve a problem while having complete openness on changing their stance. I’d get it if I had a controversial stance. But I just want resolution of any kind. Sergecross73 msg me 23:13, 19 June 2019 (UTC)

  I re-read your comments twice, and maybe I'm blind, but I do only see you talking about "recurring disputes" without links or descriptions. Do these disputes have recurring themes? Do they often end with outcomes that conflict with similar, earlier discussions? Without details like that, it's I find it impossible to evaluate the potential impact of your proposal. Argento Surfer (talk) 13:05, 20 June 2019 (UTC)

  • At least to me, yes. Our articles on notable fictional characters particularly in any form of serial work often focuses far too much on primary material. For example Rick Grimes (which actually has a decent "out of universe" set of sections but still has far too long in the tooth on the fictional biography), and I'm sure I can find more with some time. People writing these fictional biographies tend to want to go by breaking it up by each serial element (episode, comic issue, etc.) rather than describe the broad trends. No existing MOS or P&G really says anything against this, barring the lack of secondary sources for notability. Because we tend to allow works of fiction to serve as sourcing for themselves, these articles seem to get away with excessive reliance on primary sourcing.
  • I would then probably add that the focus of these articles should be on the out-of-universe facets more than the in-universe ones. How was the character conceived? How has the character changed over the years? How have they been received in the world of critics? etc.
  • Then another whole thorny issue is when you have multiple iterations/versions of the same character, ala something like Robin (character) especially when it comes to NFC use. That's a whole pickle that we really haven't touched on. --Masem (t) 00:17, 19 June 2019 (UTC)
    • "How have they been received in the world of critics?" Why? This is at best a trivial aspect of the topic and of minimal interest to a reader. I have a few relatives (my sibling, a few cousins, and a niece) who are Wikipedia readers, but not editors. They only read the plot sections and just ignore whatever "critical" opinion is added as indifferent. Dimadick (talk) 16:19, 22 June 2019 (UTC)
      • So, because people misunderstand the purpose of Wikipedia, and misuse it accordingly, we need to accommodate that? Wikipedia isn't supposed to be Cliffs Notes For Pop Fiction. -Jason A. Quest (talk) 16:28, 22 June 2019 (UTC)
• To clarify, is the text of User:Sjones23/Proposal what is being proposed here? Satellizer el Bridget ^(Talk) 00:47, 19 June 2019 (UTC)
• Support at least some set of guidelines. I would estimate that we have tens of thousands of articles on fictional characters, mostly comic book characters. bd2412 T 00:54, 19 June 2019 (UTC)
• Support I think this is a great idea.Blue Pumpkin Pie (talk) 01:01, 19 June 2019 (UTC)
• Oppose as instruction creep, until it can be demonstrated this will solve concrete problems our guidelines don't already address, rather than be a collection of pet prescriptions. Curly "JFC" Turkey 🍁 ¡gobble! 01:55, 19 June 2019 (UTC)
• I think Masem does bring up some good points. I give the example of Sansa Stark, a major character that appears in two different mediums, and with two very different storylines. Right now the article is 75% in-universe retelling of her story by book and by season (all unsourced, naturally) and only then comes the real life coverage of the character. This is excessive reliance on primary sourcing even on a well-known character with a number of reliable sources available. I think WP:PLOT argues that summary descriptions of works should be limited, yet it's not being done in many (most?) character articles. Then there's the whole issue of having hundreds of articles like Griffin Castillo, AJ Chandler, Nick O'Bannon, Nitro (comics), A. J. Chegwidden and Natalie Marlowe that obviously fail MOS:REALWORLD on a whole (as in, there's no independent sourcing on these characters). I think that the rules do exist regarding coverage of fictional elements in wikipedia voice but I'd personally welcome some discussion regarding what we should reasonably expect from an article about a fictional character (development, reception, difference between original work and adaptations, merchandise, casting, etc.). RetiredDuke (talk) 18:23, 19 June 2019 (UTC)
• I also think this could be expanded to articles that handle more than one character and List articles that handle characters.Blue Pumpkin Pie (talk) 21:42, 19 June 2019 (UTC)

  I would definitely think that we can include "list of characters" as part of a MOS for fictional characters in general. We're not talking notability here (there is no specialized notability for fictional characters, they are expected to meet the GNG), but the biggest issue in both single character and character lists is that the content from primary seem to be around 90% of the article, ideally it should be 50% or lower. Outside of WP:NOT#PLOT, and the little that is in WP:WAF, there is nothing to help with this imbalanced primary/secondary ratio. --Masem (t) 23:20, 19 June 2019 (UTC)

• Don't support the current wording of User:Sjones23/Proposal, if this is what is proposed, but do support a centralized MoS guideline, as currently TV has Wikipedia:Manual of Style/Television#Character article structure, WikiProject Fictional characters has Wikipedia:WikiProject Fictional characters/Style guide, Video games have Wikipedia:Manual of Style/Video games#For characters, comics have Wikipedia:Manual of Style/Comics#Characters 2 and there are probably others. This needless fork of guideline has in certain situation also conflicting style guides. --Gonnym (talk) 00:07, 20 June 2019 (UTC)

  I plan to merge all of the guidelines there into a single MoS guideline. Lord Sjones23 (talk - contributions) 05:57, 21 June 2019 (UTC)

• Oppose per WP:CREEP. I just had a look through the FAs of this sort. To start at the top, consider the vexed question of infoboxes. Should fictional characters have an infobox like Jabba the Hutt or not, like Tom Swift? There's no practical consensus on this, is there? Andrew D. (talk) 09:04, 20 June 2019 (UTC)
• Oppose as instruction creep, the question of standalone notability for a fictional character should be determined by WP:GNG on a case by case basis, while the MOS is not the right area for such decisions, thanks Atlantic306 (talk) 11:54, 20 June 2019 (UTC)
• Oppose per User:Atlantic306 and User:Andrew Davidson's rationale. Would've supported per WP:NOTCREEP however the matter seems a lot more complicated and integrated into wikipedia. Consensus would seem very mixed on the matter too so, echoing Atlantic306 I'm going to emphasize his/her argument that "Standalone notability ... should be determined by WP:GNG on a case by case basis."
• Oppose I made an essay in 2016, which is linked as WP:A&M/CHARACTER based on common layouts found on GA and FA anime and manga related character articles. This being said, we already have so many projects doing their own thing here. In theory its a good idea, but implementing it across Wikipedia is another matter. - Knowledgekid87 (talk) 15:57, 20 June 2019 (UTC)
• As seen by what Gonnym pointed to, we already have style guides for fictional characters. And we have Wikipedia:Manual of Style/Writing about fiction. Flyer22 Reborn (talk) 05:12, 21 June 2019 (UTC)
  • That doesn't solve a lot of problems with fictional characters. In recent months I've seen various problems for which there have been no specific answers, even for simple things like how you should write the chaacter's name in the lead sentence. A common thing that I see is editors not being able to separate fiction and reality. They like to add birth dates, often based on OR, or claim citizenship for particular characters based on how it applies to the real world. When you try to refer to WP:WAF or other guidelines to resolve the problem, there is no guidance in the area. We really do need something specifically for fictional characters. --AussieLegend (✉) 06:22, 21 June 2019 (UTC)
    • So which MOS or essay do you propose we go by? We have an MOS mention for comic book characters, an MOS mention and essay for anime characters, a style guide for fictional characters, an MOS mention for television characters, and an MOS about writing about fiction. - Knowledgekid87 (talk) 15:23, 21 June 2019 (UTC)
      • I would start by looking at what you've mentioned and improve those if necessary. Then, look at what is common to all and create a MOS based on that. --AussieLegend (✉) 08:31, 22 June 2019 (UTC)
• SMcCandlish and I have previously discussed a centralized MOSWORKS (see also Talk:Virtual Pool 3). It would be a massive undertaking. I'd be willing to work with other editors to consolidate our guidance on works, fictional and otherwise, of which the characterization is a part. That said, I would reject the 2012 Sjones page out of hand. --Izno (talk) 16:26, 22 June 2019 (UTC)
  • Since a few of us in this thread repeat this sentiment, maybe the question for a RfC shouldn't be if we should adopt Sjones's page, but wether we should consolidate the various MoS and essay pages on fictional characters into one MoS. --Gonnym (talk) 09:31, 27 June 2019 (UTC)
    • Perhaps the thing to do, then, is to make a draft of what such a consolidation would look like. bd2412 T 19:49, 27 June 2019 (UTC)
    • Yeah, I'd Just Do It after finding a few likeminded editors from the various groups maintaining pages that talk to characters/works, and other fictional/non fictional things of similar nature. --Izno (talk) 21:30, 27 June 2019 (UTC)
• Oppose per User:Atlantic306 and User:Andrew Davidson.--Vulphere 06:19, 27 June 2019 (UTC)
• Oppose. We're not currently at a state where we could "solve" all these diverse series of issues all at once. Yes, various fictional characters are treated differently in WP, because the fiction treats them differently. Maybe would devise some sort of classification system and create useful guidelines for each, but that's just step one of many required, and that by itself is too big a step. Perhaps we could start with a few essays that suggest some ideas for how some types of fictional characters could be identified and treated, and see if that clarifies how we might start to find a way to cover everything. All I know is dictating something right now would actually delay these preliminary steps, and inhibit a workable solution. --A D Monroe III^(talk) 21:05, 27 June 2019 (UTC)

RfC: Ending the system of portals take 2

Should the system of portals be ended? This would include the deletion of all portal pages and the removal of the portal namespace. This of course does not include our main page or other portal style pages as they are not in the portal namespace.....with the current event portal being moved--Moxy 🍁 03:41, 19 June 2019 (UTC)

Rationale discussion

It's clear that the portal space is no longer support by the community. Since the last rfc to retain portals and desire to try improve what we had...and then mass creation of automated portals; we have had 4000 plus portals deleted in the past 6 months with very little opposition and participation in those talks. Many portals have been deleted with just a few votes with most having zero improve attempts. At this point with only 900 or so left we should consider the fact it's over. What do others think? Should we just keep deleting one by one or does the community except that it's a failed experiment and our resources can be better used.--Moxy 🍁 03:35, 19 June 2019 (UTC)

Regarding "with just a few votes" - When I look at any xFD if the nom makes a good case and all the !votes are to delete (even if there are only one or two of them) then I don't usually bother to !vote. Many other editors may do similar. DexDor ^(talk) 05:25, 19 June 2019 (UTC)

The vast majority of editors do not go to, or even know about, xFD, so removing things via that route probably doesn't give an accurate picture of true feelings of the community. Randy Kryn (talk) 13:19, 19 June 2019 (UTC)

The vast majority of editors do not go to, or even know about, any type of Wikipedia discussion. ―Mandruss ☎ 14:41, 19 June 2019 (UTC)

Those at the isolated deletion board don't care about the last Rfc and they have littld interest in updating any or even giving the community a chance to fix them. If there is any desire to retain portals we will need content editors to step up and update the portals. As of now portals are being deleted bases on views or the fact a topic like the military of the United States is considered not a broad topic. If no one is will to help there is no point in having them...as they will all be gone soon anyways. I voted last time to end portals...but now find myself trying to explain that back door deletion is not what the community intent was in the last Rfc. I still think they should be deleted overall...but am not a fan of the non policy bases they are being bandwagon deleted.--Moxy 🍁 19:09, 19 June 2019 (UTC)\

Well, I have occasionally looked at some portals since the last RfC and they looked fine. It's rather a mystery why some people would want to trash every portal that might interest others and the last RfC suggests rational people do not. It's fine to trim, but 900 is just not that many pages and neither is 4000. Alanscottwalker (talk) 19:51, 19 June 2019 (UTC)

• I think this proposal is too rash and misses a lot of points that would help build consensus. Given the lack of consensus in the previous RfC, the next step is not to propose all or even most portals be deleted. The recent mass portal deletions were in response to what was as much a conduct dispute as a content dispute. The XfD discussions were largely because a proposal for a new speedy deletion criterion applying to all portals created by a single user failed to gain consensus. Pointing to those to say that there is consensus to delete all portals is not a good example. The AN discussion has over 10 proposals on how to handle portals, some of which, like proposals 7 and 13, seem like they might actually find consensus.

If anything, the problems pointed out regarding the upgrades to portal maintenance can at best show that we should not create any more portals as they are likely to wind up unmaintained and just as complex as before. I think a proposal to mark WP:PORTAL historical but maintain what we have for the time being is far more likely to gain consensus than deleting portals en masse. Lots of people believe there are portals which still have value and are actively maintained and so blanket deletion is not going to find consensus because of that.

I fear that this discussion is only going to harm consensus building by making people more entrenched in their positions. It's unlikely to pass and those who support portals will be more likely to view further good faith attempts at consensus building as attempts to delete all portals. I suggest this be withdrawn or closed in favor of a more nuanced proposal. Wugapodes [t^hɑk] [ˈkan.ˌʧɹɪbz] 21:25, 26 June 2019 (UTC)

• Procedural close this bad faith, disruptive RFC. This proposal is just a blatant act of bad faith by Moxy, who doesn't understand what was actually decided at the 2018 WP:ENDPORTALS RFC. That was a proposal to delete all portals, now, and it was rejected. That's all; it was not a decision to keep any individual portal, just a decision not to delete them all immediately.

However, Moxy has spent the last few weeks opposing deletion of long-abandoned portals, repeatedly making the false claim that ENDPORTALS decided to keep them all.

This pseudo-RFC is just a re-run of the false binary thinking, intended to demolish a straw man. It posits them single option of deleting them all, in the hope that when that's rejected Moxy can then use the outcome to oppose deletion even of abandoned crap.

The current situation is that good portals are being kept, but the abandoned junk is being deleted. Moxy's aim is simply to stop that cleanup, and there is no need for the community to waste its time indulging this game-playing. --BrownHairedGirl (talk) • (contribs) 20:38, 1 July 2019 (UTC)

Just have to read There exists a strong consensus against deleting or even deprecating portals at this time . Not sure that it could be more clear...so here we are again trying to get you to move in the right direction to no avail. Have you seen what is being said here??? You 2 have been asked many many times to give the community time to fix the portals you guys dont like......simply not possible to fix hundreds of portals at a time. --Moxy 🍁 20:46, 1 July 2019 (UTC)

Moxy, it was a decision to not delete all portals now.

It was not a decision to never delete any portal ever.

It's a great pity that Moxy's deep deficiency in logic and of reading comprehension does not debar him wasting the community's time with this WP:POINTy RFC. --BrownHairedGirl (talk) • (contribs) 21:00, 1 July 2019 (UTC)

Your simply not doing right by our editors and this should be clear by all the feed back your getting . Cant believe you dont understand why editors are upset with you 2 ...your deleting portals based on view and what you guys think is not a big topics....zero effort at fixing portals that are clearly valid like Wikipedia:Miscellany for deletion/Portal:Military of the United States that has 1,197 featured and 3,088 good articles to use. Now you 2 are deleting portals based on no attribution...thats every portal we have a ... So were does your deletion end and the fixup work begin?? 3000+ portals deleted is definitely not what the RfC is looking for.--Moxy 🍁 21:12, 1 July 2019 (UTC)

Your Moxy, the feedback I am getting is very clear that most editors have no objection to the deletion of portals which fail the portal guidelines, while keeping those which do meet the guidelines. It's a great pity that you continue to refuse to actually read the guidelines. If you did read and comprehend them, you might understand why Wikipedia:Miscellany for deletion/Portal:Military of the United States was closed as delete.

However, there has always been a small trickle of editors like yourself who object to the deletion of even portals which have been abandoned for a decade ... and every now and then one of them tries to make a drama.

Fixup begins whenever you or anyone else wants to start fixing them. --BrownHairedGirl (talk) • (contribs) 00:00, 2 July 2019 (UTC)

Voting discussion

• Oppose: I think we should keep portals, because they're useful for organization, navigation, and bridging between reading and project space. Benjamin (talk) 06:36, 19 June 2019 (UTC)
• WP:ENDPORTALS: Electric Boogaloo? Moxy, I would suggest pausing this a bit to work on the wording of the RfC, at least. The last RfC got muddled up with Wikipedia:Community_portal and Portal:Current_events (with the intention being that the current events portal would be moved to Wikipedia space), and with some opposition to full deletion (with preferrence a slower process than Nuking the whole space). So I would suggest some rephrasing of the RfC question or changes to the format to allow a consensus for a less dramatic step. Galobtter (pingó mió) 12:32, 19 June 2019 (UTC)

  Done I guess we should make it as clear as possible.--Moxy 🍁 19:30, 19 June 2019 (UTC)

• Oppose, this was fully discussed in the last well-attended and novel-length RfC. Some editors have worked diligently on the collection since then. Randy Kryn (talk) 13:13, 19 June 2019 (UTC)
• Not now per Galobtter. I think you're right that recent developments might have changed consensus. I agree with the spirit of the proposal, but per the last RFC, Community portal and Current Events are going to be stumbling blocks to consensus unless there's an explicit plan to deal with them from the beginning. I think you should withdraw this and consider a better compromise than deleting portals which I don't think will find consensus. Wugapodes [t^hɑk] [ˈkan.ˌʧɹɪbz] 14:41, 19 June 2019 (UTC)

  Note: Wikipedia:Community portal probably isn't relevant - it isn't in portal namespace, isn't a WP:Portal and was only mentioned once in the previous RFC. DexDor ^(talk) 18:15, 19 June 2019 (UTC)

  Have amended wording for those not familiar with topic portals.--Moxy 🍁 19:30, 19 June 2019 (UTC)

• Oppose The major portals still appear on the main page and that's not a problem. People bickering about lesser portals is typical disruption per WP:LIGHTBULB. Tsk. Andrew D. (talk) 22:36, 19 June 2019 (UTC)
• Oppose I have been appalled by the tone of the discussions at MFD but I simply haven't have the inclination to take part. All the same, I think portals should continue. Thincat (talk) 08:03, 20 June 2019 (UTC)
• Strong Oppose - We already had a lengthy discussion on the matter that has its own subpage saying there is a "strong consensus" to retain the portals, no need to beat a WP:DEADHORSE. - Knowledgekid87 (talk) 16:02, 20 June 2019 (UTC)
• Oppose That there was consensus to delete some portals does not imply consensus to delete all portals. Articles are deleted every day at AfD but this does not imply a consensus to delete the article space. Hawkeye7 (discuss) 19:46, 20 June 2019 (UTC)

  Going by the reasons for deletion that I see most days I think that there are some editors here who would like to make this place neat and tidy by deleting the whole of article space, so they would be able to argue about things without having that messy encyclopedia to worry about. Phil Bridger (talk) 20:38, 20 June 2019 (UTC)

  This just goes against WP:IMPERFECT (which is a policy), no amount of deletion cleanup will ever be enough to please everyone. Things that hinder editing I can understand, but to go after things just to go after them is wrong in my opinion. - Knowledgekid87 (talk) 15:16, 21 June 2019 (UTC)

• Oppose I'm against deleting high level portals such a those on the main page and Portal:Contents, plus any others which don't duplicate article content such as Portal:Current events and Portal:Featured content. I would be happy to consider proposals to drastically reduce the number of portals but not get rid of them entirely. Hut 8.5 12:53, 22 June 2019 (UTC)

  My guess is this is the plan...deleted all but main portals..--Moxy 🍁 12:00, 24 June 2019 (UTC)

• Strong support. I feel that portals are long obsolete and that their removal is inevitable and would benefit Wikipedia. Also, in response to those who note that we have had a discussion on it before, I remind you that that was over a year ago and that consensus can change. Having said all that, I get the feeling that consensus does not currently support the eradication of the namespace, so I will support the form of consensus that is closest to it (such as removing all but the main-page portals, etc.). EDIT: After thinking it over for a little bit I realize that I've been a bit overly harsh on portals. I still see no use for them personally, and would not oppose deleting all but the main-page and non-article-duplicating portals, but those who really want to maintain the portalspace should be able to do so provided that they don't spam with cruft and, most importantly, help the encyclopedia. – John M Wolfson (talk • contribs) 18:02, 26 June 2019 (UTC)
• Strong oppose. Look, there are a lot of useless portals. If that makes the whole system useless to you, fine, ignore them. If you think it could be useful but it isn't because of the cruft, then decide whether it's worth your time to help clean it up. If it is, then do it. If it isn't, see sentence 2.
  The "resources" argument is fundamentally misbegotten. There is no common pool of resources that we draw on. There are volunteer contributors, who allocate their resources as suits them. --Trovatore (talk) 19:51, 26 June 2019 (UTC)

Would be nice but efforts to improve are just reverted....got just a few editors voting rrsulting in deletion of thousnads of portals.--Moxy 🍁 21:41, 26 June 2019 (UTC)

Moxy, if you genuinely believe that efforts to improve are just reverted, then please post evidence of this. I have seen no evidence of this raised at MFD or at WT:WPPORT ... so unless you can show actual evidence I will mark it down as simply more of Moxy's lies.

As to just a few editors voting rrsulting in deletion of thousnads of portals, that's a blatant lie (as in something which you stated it when you knew to be untrue). As Moxy well knows, the majority of the deleted portals were removed in two mass deletions of automated portals: one, and two). Those were widely-advertised discussions, and they were some of the most heavily-attended MFDs ever. Claiming that this is just a few editors voting is a simply a lie designed to deceive other editors. --BrownHairedGirl (talk) • (contribs) 21:10, 1 July 2019 (UTC)

More lies what are you talking about? Cant BS the facts girl...its clear portal after portal that was not automated is being deleted by just a few votes (as mentioned here by others). As for your revert I am simply not sure what to say]...editors cant do much when an admin is reverting fix attempts now can we. You sure your on the right side here...are you doing right by our editors?--Moxy 🍁 21:47, 1 July 2019 (UTC)

Moxy, either you are either a congenital liar or you have a very poor grasp of facts.

You claimed just a few editors voting rrsulting in deletion of thousnads of portals.

The facts are that:

1. ~2500 automated portals were deleted by overwhelming consensus at the two mass MFDS.
2. Another ~1900 automated portals were deleted per that consensus
3. ~570 portals have subsequently been deleted at MFD, in discussions with varying numbers of participants.

So your claim that a few editors have deleted thousands of portals is a complete lie. That description could be applied to at most a few hundred portals.

As you know, those portals have been deleted because they don't meet the portal guidelines ... so your whole claim of this being the work of a few editors is either more lies, or a paranoid delusion.

Now, that diff.[2]

1. It is not a revert. It was a removal of a category on Portal:Washington, D.C..
2. I removed Category:Portals by city because the portal was already in the subcat Category:United States portals by city, so per WP:SUBCAT it shouldn't also be in Category:Portals by city. This is very very basic categorisation policy, so it is bizarre that you try to make an issue of this at in an RFC.

So that's another of Moxy's fairy tales disposed of. So where exactly is this evidence of portal improvement being blocked? --BrownHairedGirl (talk) • (contribs) 23:51, 1 July 2019 (UTC)

• Oppose Portals are useful.--Vulphere 05:48, 27 June 2019 (UTC)
• Oppose The possibilities are important to retain. I look at Portal:Feminism and only wonder where Gender-responsive prisons could be referenced. The article isn't even categorized correctly! I may inhabit the search box, but users should have other ways of finding topic-related articles. We need multiple avenues for discover. Shenme (talk) 22:00, 1 July 2019 (UTC)
• Oppose - IMHO they should all be killed with fire ... however the last portal RFC was closed with a consensus to keep these .... I don't support repeatedly creating the same RFC in the hope consensus will change even if I do disagree with said consensus. –Davey2010^Talk 21:53, 2 July 2019 (UTC)

• @Davey2010, I agree with all that. I voted delete in the 2018 RFC (as the lesser evil of a binary choice), but I accept the outcome and see no benefit in a re-run.

However, this proposal isn't actually born out of a desire to end portals. The proposer Moxy actually wants to keep all portals, and this RFC is a thoroughly bad faith straw man proposal after Moxy's objectives failed through other channels.

In the last 4 months, many portals have been deleted at MFD because they were abandoned, stillborn, or had too narrow a scope. These last few months have seen a cull of several hundred of the worst portals, because they failed the criteria set out in WP:POG. Moxy has objected to many of these deletions, almost always without success.

So Moxy and others have tried to change the guidelines to remove the quality criteria. See e.g. WT:Portal/Guidelines#How_often_to_update? and WT:Portal/Guidelines#Pageviews where such proposals have been roundly rejected. In his characteristically abysmal writing style, Moxy has been quite explicit about his goal: "We need to fix what the criteria are so deletionest cant use it in a bad way,,,should be greadre towards improvement and sustainability over deletion. criteria."

Having failed to remove the quality threshold from the guidelines, this RFC is a straw man: Moxy hopes that its rejection will allow him to claim that there is a consensus not to delete any portals.

This disingenuous tactic is foolish, because most editors can well understand that a decision not delete the entire namespace is not a decision to keep every piece of ten-year-old abandoned junk in portalspace. There are some really good portals which serve readers well, and most editors want to see the junk culled while keeping the good stuff ... but Moxy is going to play his transparent game of trying to pose it as a binary choice between keep keep all or delete all.

I'm inclined to think that there should be some certification process for RFCs, requiring a number of co-signatories before the Village Pump can be abused in this way. It is a waste of the community's time for a linguistically-challenged "editor" to be free to unilaterally start to waste the community's time with this sort of straw man game. --BrownHairedGirl (talk) • (contribs) 00:15, 3 July 2019 (UTC)

Hi User:BrownHairedGirl, I agree if they're not being used then yeah I see no valid reason for keeping them,

I have to say looking at their contribs I'm rather disappointed at the continuous !votes on various portal MFDs- The time trying (and failing) to keep these crap could seriously be better spent on writing or improving articles for our readers,

If they've genuinely created this to make some sort of point then I hate to say it but they've all but failed on that too. –Davey2010^Talk 00:57, 3 July 2019 (UTC)

@Davey2010, given the exceptionally poor writing skills which Moxy has displayed in all the discussions I have seen, it is probably a blessing that Moxy puts their efforts into defending the indefensible chunks of portalspace rather than polluting articlespace with gobbledygook such as We need to fix what the criteria are so deletionest cant use it in a bad way,,,should be greadre towards improvement and sustainability over deletion. criteria. --BrownHairedGirl (talk) • (contribs) 01:04, 3 July 2019 (UTC)

Proposal concerning padlocks

This is based partly on my own experience, but regardless I think it has merit. When a registered and qualified Wikipedian logs in to a semi-protected article, or any other relevant protected article, for that matter, I would like to see the padlock/s automatically disappear. That would make it clearer, (especially for newbies) in my opinion. Obviously, it would not apply to registered and unqualified or unregistered users. Editrite! (talk) 02:26, 22 June 2019 (UTC)

Let's say a suitably-privileged user adds a padlock to a protected page. How would they test that the padlock was actually being displayed? --Redrose64 🌹 (talk) 20:00, 22 June 2019 (UTC)

Should be doable via gadgets/scripts or something, but it's not something that should be on by default. Headbomb {t · c · p · b} 21:01, 22 June 2019 (UTC)

But an editor can already find out whether they can edit a page by the state of the Edit button (for example whether it says "Edit" or "View source"). However, if an editor wants to find out whether a page is protected, how are they going to do that if the padlocks are invisible to them? – Uanfala (talk) 22:24, 22 June 2019 (UTC)

In answer to both Redrose64 and Uanfala, the padlock/s ONLY disappear when you LOG IN, so in other words, when you log out they will automatically reappear, or alternatively they will appear BEFORE you log in, as if you were unregistered. It's true that there is an Edit button but here's the thing. When I registered and qualified as an editor, because the padlock was still displayed on protected articles after logging in, I mistakenly assumed that meant I was still not allowed to edit. Hence my proposal to avoid ambiguity. I doubt that I was the first, or will be the last to experience this situation while the padlock remains all the time. Editrite! (talk) 05:11, 23 June 2019 (UTC)

If a page is protected, a padlock icon can only be added by a person who has the matching (or higher) editing right, and logged out users have none of these rights. Imagine that somebody locates a page that is protected because of vandalism, but has no padlock. They log in (if not logged in already) and add a template like {{pp-vand}} to the page. But nothing then displays, because you (Editrite!) don't want that person to see anything. They then think that they made an incorrect edit, and remove it again. Nothing is solved. --Redrose64 🌹 (talk) 13:54, 23 June 2019 (UTC)

I honestly wouldn't put this as a high priority for implementation or even discussion. But we could display a locked padlock for users that do not have the required rights, and an open padlock for users that have. And no padlock for unlocked pages... --Stephan Schulz (talk) 14:17, 23 June 2019 (UTC)

1. Mouseover the padlock and it explains that the article is protected. It doesn't say that the article is protected from you. Use information resources that people have gone to some effort to provide you, and you will be less likely to "mistakenly assume". 2. In real life, padlocks don't disappear for those who have a key. 3. We generally require a demonstrated cost-benefit case, which means evidence that a proposed change would save editors enough time or mental energy to justify the cost of the change. We don't mistakenly assume that all editors are like us. ―Mandruss ☎ 14:48, 23 June 2019 (UTC)

I wouldn't put any priority on this except as an opt-in user script. The padlocks are to convey information about the protection levels of the article. I'm a template-editor, but knowing if a template is unprotected, semi- or template-protected is still useful because it lets me know who else can or can't edit the template. Same for articles. Headbomb {t · c · p · b} 16:38, 23 June 2019 (UTC)

Some of the comments that I have received here are bizarre, to say the least, for example comparing online with "real life". Are you serious? They show that you didn't read, understand or even worse still, distorted what I said. The only issue here, if there is an issue is cost. The software gurus shouldn't have any trouble coming up with an answer quickly, but in the unlikely event that they can't and it's not viable, (Wikipedia being a non-profit organisation) then obviously it's not a proposition. No system is perfect. The subject of vandalism is always a problem, and no matter what you do, you can only minimise it not eliminate it. As for the assertion that it's only for my benefit, or "assume that all editors are like us", nothing could be further from the truth, and I've made that clear. If you can't or won't see the bigger picture, then I can't help that. Just to be clear, what I am proposing is that ONLY while you are logged in to a semi-protected or protected article, as a registered and qualified user, will the padlock not appear i.e. it's only temporary. When you are not logged in, or you have logged out it will appear as normal, so it's easy to tell if it's protected or not. Editrite! (talk) 06:04, 24 June 2019 (UTC)

Calm down. People understand what you're proposing but disagree that it's a good idea. The fact that a page is protected is important information. For example our protection policy states that "Protected pages may not be edited except to make changes that are uncontroversial or for which there is clear consensus" so as an admin I need to know if a page is protected before I try to edit it.

Nonetheless, if you insist this feature is useful to you it can be done with a single line of javascript added to your common.js file:

if ( mw.config.get('wgIsProbablyEditable') ) { $('[id^=mw-indicator-pp]').hide(); }

the wub "?!" 13:19, 24 June 2019 (UTC)

@thewub Thanks for your input. There seems to be a perception that my proposal is for purely selfish reasons, but that's not how I operate (it would have been useful as a newbie to avoid confusion which was the point I was making, but not now). I'm more interested in constructive suggestions that benefit others. Nevertheless, I am willing to accept your interpretation that the handful of contributors here do not agree with my proposal at this time, and leave it at that. It's a pity . . . but that's life. Editrite! (talk) 22:56, 25 June 2019 (UTC)

FPC needing feedback

Hi all! I proposed an image on WP:FPC and it didn't reach the quorum for one vote. For days it was on "FPC needing feedback" yet it didn't work. Any idea?, shouldn't FPC needing feedback receive a further time to reach consensus? Thanks! --LLcentury (talk) 15:08, 23 June 2019 (UTC)

@LLcentury: You seem to have nominated a number of images at WP:FPC. Which one are we talking about? --Redrose64 🌹 (talk) 15:31, 23 June 2019 (UTC)

@Redrose64:, sorry for not being clear Wikipedia:Featured_picture_candidates/Byun_Yo-han. --LLcentury (talk) 15:33, 23 June 2019 (UTC)

This was closed by Armbrust (talk · contribs). Have you asked them why they reached that decision? In any case, I don't see why this is a WP:VPR matter: are you proposing a new process that would be different from the processes that already exist? --Redrose64 🌹 (talk) 15:59, 23 June 2019 (UTC)

The nomination failed because it didn't reach the necessary quorum (5 supports) during the voting period (10 days). As an image can be renominated at any time, I don't think expanding the voting period is needed. Armbrust ^{The Homunculus}

No no just a proposal to expand the time of those pictures needing feedback. Sorry my English is not expansive. --LLcentury (talk) 16:00, 23 June 2019 (UTC)

Display A class as a top icon

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.

---

Currently, we only display two article qualities as top icons... GA and FA. I propose we change this and show A-class as well. My reason behind this is that A-class articles are inherently better than a GA. A-class basically approaches FA but falls just short. Considering A-class has multiple reviews that are likely more thorough than what it received at GAN (if it went through the process), I see no reason why we shouldn't display a top icon on A-class articles. Noah^Talk 16:06, 24 June 2019 (UTC)

"Inherently better" Not really. A-class is not required to be reviewed by the community and is not generally required to have more than one reviewer. Maybe this is something to discuss on WP:VPI instead, but I do not think it will be likely to be accepted by the community. --Izno (talk) 17:36, 24 June 2019 (UTC)

@Izno: Well... maybe we need to discuss implementing a hard process for A-class articles. According to the current A-class criteria, it must be reviewed by at least 2 impartial reviewers. Would it be okay to just move this whole section over to the idea lab then? Noah^Talk 17:49, 24 June 2019 (UTC)

Hurricane Noah, Some WikiProjects already have one, such as Wikipedia:WikiProject_Military_history/Assessment#ACR. Adam9007 (talk) 19:06, 24 June 2019 (UTC)

@Izno: A-Class is inherently better, at least in the sense that it's a higher grading than GA. It makes little sense to skip a grade with top icons. – Finnusertop (talk ⋅ contribs) 11:42, 25 June 2019 (UTC)

Uh, no. A and GA are strictly unrelated. One is a WikiProject grading and one is a Wikipedia grading, and the requirements for each differ accordingly. --Izno (talk) 13:47, 25 June 2019 (UTC)

Izno, Then the grading table needs changing. Anyone reading it would think that A-class is a step above GA. Adam9007 (talk) 00:37, 26 June 2019 (UTC)

@Adam9007 and Izno: If you even look at the main content assessment page, an article is not complete until it reaches A-CLASS... GAs may have weak areas according to one of the description boxes while an A-class is a nearly complete rendering that will leave non-experts wanting no more. Therefore a GA is an incomplete article, while an A-class article is. That means that A-class is above GA. Noah^Talk 01:09, 26 June 2019 (UTC)

• Support Per nom. For the few WikiProjects that actually do A-class, it's listed a grade above GA and has a higher standard and articles go through more scrutiny. It thus makes no sense to display a badge of honour for GAs but not for A-class articles. The only problem with this is that an article can be part of a WikiProject that does A-class and another WikiProject that doesn't. Perhaps being A-class one of the applicable WikiProjects would be enough to display the badge? Adam9007 (talk) 18:57, 24 June 2019 (UTC)
• Support. Our current practice of skipping a grade with top icons makes little sense. A-Class is definitely a badge of honor, not shame, as the process is quite rigorous and results in quality content. – Finnusertop (talk ⋅ contribs) 11:48, 25 June 2019 (UTC)
• If we want to use bold, oppose. Supporters are under some misapprehension about how these rankings interrelate. If they personally are interested in knowing what the class is without visiting the talk page, there's a gadget for that. --Izno (talk) 13:48, 25 June 2019 (UTC)

  Izno, By that logic, we should do away with having GA and FA top icons. I can't see that ever happening... Adam9007 (talk) 23:38, 25 June 2019 (UTC)

  I have corrected the misapprehensions above. If you are interested in responding to what those misapprehensions might be, above is the correct place so that we don't split the discussion. --Izno (talk) 00:25, 26 June 2019 (UTC)

• Oppose. A may be placed between GA and FA in the table at WP:ASSESS, but I don't see them forming a strict hierarchy. For example, if you look at the criteria at WP:ACLASS, you'll find that they're not a superset of WP:GACR. Also, A/B/C grades are assigned by Wikiprojects. How they determine those grades is basically up to the individual Wikiproject. GA/FA are determined by independent editors following a very well-defined process (they also have well-defined processes for reviewing/revoking the status after it's been given). Also, even if you could fix the A criteria/processes such that they were clearly comparable to GA/FA: I don't see the need for another level of granularity. The difference between GA and FA is not huge. And for a casual reader, grokking the difference between GA and FA is probably already confusing enough. Colin M (talk) 23:31, 25 June 2019 (UTC)

@Colin M: If the difference isn't that great, why don't we just abolish A class entirely? Why not abolish B class while we are at it since there isn't much difference between it and GA? If you read the difference between GA and A, you will see there is a decent gap there. A GA may still be incomplete and lacking in areas while an A-class is required to be a nearly complete treatment of the subject. There are some GAs that are absolutely horrible and would warrant a withdraw if submitted for a FAC. The wikiprojects that actually do A-class reviews (makes up at least a majority of the current A-class articles) do a pretty good job at it. I'm pretty sure quite a few projects review according to FA standards as well. To say A-class is worthless and there isn't much of a difference just means you haven't gotten a lot of experience with those processes under your belt yet. I have gone through the GAN process several times and have two incumbent FAs. Trust me when I say there is quite a large difference. Noah^Talk 00:50, 26 June 2019 (UTC)

• While I might be misunderstanding something, from what I understand A-Classes are assessed by WikiProject and thus subject to local whims, so what may constitute A-class in one WikiProject may not be so for another. This is in contrast to FACs, which are assessed by a project-wide panel, and GANs, which have universal criteria. While I won't adamantly oppose this proposal I am skeptical of it, especially if one WikiProject assesses it as A-class but other relevant WikiProjects either don't have such a mechanism or view it only as a GA or even lower. (I've also never quite grasped the concept of A-class in general; from what I understand it's something in between GA and FA, but I've never really gotten how that works or what the criteria are as opposed to either respective grade. That is irrelevant here, though.) – John M Wolfson (talk • contribs) 06:31, 26 June 2019 (UTC)

@John M Wolfson: A discussion needs to take place for either the refinement or abolishment of A-class based on arguments above. I am archiving this as it is clear said discussion needs to take place before this. Noah^Talk 12:26, 26 June 2019 (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.

Proposal for a policy to speedily move advert/COI pages to draft

We have over 18,000 pages tagged as {{advert}}, and nearly 13,000 tagged as {{COI}}. Some of these are actually in reasonably good shape, but need to be slightly more balanced and have some puffery removed, while others are barely more than a resume or a page of promotional jargon. In the middle ground, there are a substantial number of pages that are for individuals and entities that are probably notable, and which are not fit for speedy deletion under CSD:G11 as unambiguous advertising or promotion, but which also are not in a shape to properly serve our readers. As an administrator, I probably deal with more of those than the average editor. I would like to be able to speedily move pages that are farther towards the bad end to draft space. I propose the adoption of a policy structure along the lines of CSD:G11, but directed at articles that are theoretically fixable, but predominated by advertising, promotion, or clear COI content to the point that they require substantial revision to be a useful and credible part of the encyclopedia. bd2412 T 00:50, 27 June 2019 (UTC)

I agree with this concept. In borderline cases where there is some genuine encyclopedic content, it is better to preserve it as a draft than to delete it outright. Any good faith editor can do cleanup work and then move the draft back to main space. Cullen³²⁸ Let's discuss it 04:16, 27 June 2019 (UTC)

I would support this in principle. My main concern is in borderline-borderline cases where there are roughly equal amounts of promotion and content, but I think such concerns could be ameliorated and are not fatal to the idea. – John M Wolfson (talk • contribs) 05:27, 27 June 2019 (UTC)

Just to pick an example to see how this would work. NASCAR is marked advert. Would you like to draftify it? ☆ Bri (talk) 03:19, 28 June 2019 (UTC)

• That is a good question, and the answer is no, since that page is not clearly "predominated by advertising, promotion, or clear COI content". This would be a policy directed at pages that have some smattering of salvageable content, or are clearly notable topics that should have an article, but which have very little on the page that is not advertising, promotion, or clear COI content. Basically, it would cover pages that fall outside CSD:G11, but whose content does not really serve readers looking to learn neutral and unbiased information about the subject. 04:25, 28 June 2019 (UTC)

What would the eventual fate of such a page be? I am talking empirically, not in terms of policy. Jo-Jo Eumerus (talk, contributions) 07:55, 28 June 2019 (UTC)

• Empirically, the fate of such a page will be whatever editors make of it. I have previously solicited the creation of a banner for pages that are sent to draft through AfD ({{AfD-userfied}}), and I these pages would be similarly tagged, so they would show up in a maintenance group together. Of course, the ones that no one really thinks are worth having in the encyclopedia will end up being abandoned, which is a better result then having them abandoned in mainspace. bd2412 T 16:04, 28 June 2019 (UTC)

Support as a part of new page patrol. Quarantining new promotional articles in draft space deprives spammers of what they want - being indexed by Google. I quarantine a lot of suspected undisclosed paid adverts - from what I've seen about 10-20% get deleted via G5 or G11, <5% get tendentiously moved into mainspace by the author, sock or meatpuppets, <5% get moved into mainspace via AFC and the rest will be deleted via G13 once the time expires (but that's because I block the creators in most circumstances). A G13 deletion isn't too much of a concern - we don't want drive-by spam by non-contributors anyway. MER-C 09:58, 28 June 2019 (UTC)

• I'm inclined to interpret this as a deletion policy by the backdoor (I don't think that's the intent, I just think that's what it is). The loss of drafts through G13 will make up such a large proportion (either no-one watching, or no-one avid enough to fix them (particularly a hoard of such)) that it would be more coherent to amend DELPOL and note that they are automatically to be refunded on request. Please note I do not advise this. Nosebagbear (talk)

I would say that if the topic is notable, but there isn't relevant or encyclopedic content it can be deleted at AfD for being promotional, even if it doesn't reach the unambiguously promotional level needed for CSD. See WP:DEL#4 Nosebagbear (talk) 11:55, 28 June 2019 (UTC)

• I am trying to do something here for the edge cases, the ones that have some glimmer of promise. Those frequently survive AfD precisely because of that glimmer, but are then forgotten and remain in their dismal state for years thereafter. Of course, these are generally not subjects that are vital to our encyclopedia, so if they end up getting deleted as abandoned, it is not a great loss. However, it is to our detriment to keep them in mainspace perpetually, with drive-by added tags lingering, and it is an administrative burden to the project to go through deletion discussions which often resolve nothing where the solution is not going to be a binary "keep" or "delete". bd2412 T 16:10, 28 June 2019 (UTC)

Is there a reason to only apply this reasoning to articles with COI issues? Let's accept that, in some cases, pages are plagued by such serious promotional tone issues that having them visible in mainspace does more harm to readers than good (despite those pages having some small amount of redeeming content). What about an article on a notable topic that's dominated by a long-standing WP:COATRACK with no sign of improving? Or an article on a notable topic which is written like a personal essay with ruinously jumbled prose? Couldn't such articles also fall in the Goldilocks zone where the issues are so bad that the article is more likely to confuse or mislead a reader than help them, but not so bad that they'd qualify for speedy deletion (or even AfD)? Colin M (talk) 17:41, 28 June 2019 (UTC)

• The proposal is not limited to COI, but also includes ADVERT. I see your point, but my concern is that articles in these categories are more likely to actively misinform our readers. Of course, a COATRACK problem can also be a form of advertising. At the moment, however, we only have 69 pages transcluding {{Coatrack}}, so it is on a much smaller-scale problem than more direct advertising. Also, I would clarify that COI should only be an issue where it is an undeclared COI, particularly the kind where a topic is the product of SPAs bombarding a title with promotional factoids rather than a reasonable assessment of the sources. bd2412 T 17:52, 28 June 2019 (UTC)
  • That makes sense. I would support something like this. Based on my somewhat limited experience, I can believe that the scale of the problem is large. I realize that the best solution in these cases is to just fix the problem by removing the promotional content and rewording the WP:PUFFERY, but I just can't muster any enthusiasm for spending even 20 minutes picking through sources to try to clean up an article about a borderline notable dating app/jewelry maker/music blog/whatever. I'd prefer if paid editors didn't get to profit because everyone is too apathetic to spend the time cleaning up their mess. Colin M (talk) 21:57, 28 June 2019 (UTC)

Wikipedia homepage

I am proposing that on the WP homepage, that Italian and Polish be swapped with Hindi and Arabic because these languages are more widespread. Interstellarity T 🌟 01:37, 29 June 2019 (UTC)

This is handled by Project portals and not something within control of the English Wikipedia. There's some info there about how it's structured and who maintains it. Killiondude (talk) 02:04, 29 June 2019 (UTC)

Killiondude, Where can I propose the change? Is there a talk page I can go to to do that? Interstellarity T 🌟 11:05, 29 June 2019 (UTC)

@Interstellarity: If you're talking about www.wikipedia.org, the languages change dynamically. I don't recall what the logic is that selects the defaults, but, if you've expressed a preference for a language in your browser, then the portal will alter which links it shows to include that languages. If you express multiple ranked language preferences (which most modern browsers support), then the portal will change the links to display as many of those languages as possible. --Deskana (talk) 22:29, 29 June 2019 (UTC)

For the most part @Interstellarity: you can theoretically change this: www.wikipedia.org generally lists the top wiki's by number of articles, so get more articles in the other languages and they will move up the priority list. — xaosflux ^Talk 23:26, 29 June 2019 (UTC)

@Xaosflux and Deskana:, The Swedish and Cebuano Wikipedias have a lot of articles, but they are not listed on the languages circling the Wikipedia ball. Is there a reason behind this? Interstellarity T 🌟 23:44, 29 June 2019 (UTC)

Like I said, "for the most part". There is a long story about cebwiki's 5million+ "articles" - a huge (controversial) bot dump of machine created articles was done at cebwiki,svwiki, and warwiki (see Special:CentralAuth/Lsjbot) so these aren't really counted along with actual human-produced articles for that page. — xaosflux ^Talk 23:54, 29 June 2019 (UTC)

See also meta:List_of_Wikipedias for a list of all the various language wiki's by size. — xaosflux ^Talk 23:57, 29 June 2019 (UTC)

Xaosflux, There's probably not much I can do at this point so I won't bother discussing the issue at the point. Interstellarity T 🌟 00:15, 30 June 2019 (UTC)

The top ten are actually set by how many page views each language project gets (unless the user's browser language preferences indicate that some particular language(s) might be preferred). --Yair rand (talk) 23:40, 30 June 2019 (UTC)

Proposal: To make it clearer that there are multiple Wikipedias (for several different languages), note the Wikipedia's language in the title logo for each Wikipedia

Many, if not most, users seem to have an incorrect mental model of what Wikipedia is. They seem to think that it is a single global encyclopedia, encompassing all of the world's languages. When users navigate to Wikipedia, they automatically go to the Wikipedia for the particular language that their computer is configured for, and therefore they often don't realize that there are actually multiple Wikipedias, one for each of several of the world's languages.

Why is this a problem? If a user has a mental model of a single Wikipedia that encompasses all of the world's languages, then they may get frustrated or angered by a Wikipedia page that uses a spelling in the particular Wikipedia's language, rather than in the topic's language of origin (if it's different). They may think that Wikipedia is appropriating, belittling, or ignoring the topic's language of origin. This is especially true for the English-language Wikipedia (as it is so comprehensive, and includes many topics about subjects whose names in English are different from the name in its language of origin). Users often do not understand that - being the English-language Wikipedia - article titles generally use the common spelling/usage in English - i.e., WP:COMMONNAME.

Proposal: Note each Wikipedia's language prominently near the top of each page. For example, change the text of the Wikipedia logo from:

Wikipedia
The Free Encyclopedia

to

English-language
Wikipedia
The Free Encyclopedia

(and similarly for other languages' Wikipedias). Ross Finlayson (talk) 05:22, 29 June 2019 (UTC)

No. That's just superfluous. All Wikipedia logos are already localized to the language of the wiki. If you go to the French Wikipedia https://fr.wikipedia.org, the logo reads in French Wikipédia, L'encyclopédie libre, the text is not even in English so it borders impossibility to be confused on which language domain one is unless you don't understand the language. Localization is more than any translation to tell you now you're on a xxx-language Wikipedia. You know it by mere seeing if you understand the language. The same thing goes for all other language versions. See m:Wikipedia logo in each language. – Ammarpad (talk) 05:57, 29 June 2019 (UTC)

I think you misunderstood what I said; please read it again. I never said that a user is confused about which language 'their' Wikipedia (i.e., the one that they're taken to, based on their computer's language preference) uses. What I said is that users are often confused about the fact that there are multiple Wikipedias (for multiple languages). Noting each Wikipedia's language prominently near the top of the page would help do this. There might be better solutions, though. Ross Finlayson (talk) 06:34, 29 June 2019 (UTC)

I don't know if it is often but it definitively happens. Gråbergs Gråa Sång (talk) 10:36, 29 June 2019 (UTC)

• If we had a tag saying "Wikipedia - the Free English language encyclopedia that any one can edit" - would there not be a danger that this might make some readers think that Wikipedia is only available in English? Vorbee (talk) 14:49, 29 June 2019 (UTC)

Perhaps the tag should say: “Wikipedia(En) - one of several Wikipedia brand encyclopedias - that anyone can edit.” Blueboar (talk) 15:26, 29 June 2019 (UTC)

• Wrong venue - As noted above, this is the English Wikipedia, and as such, any discussions here have absolutely zero influence over how any other Wikimedia project chooses to self-identify. The place to discuss this is at Meta (either meta:Requests for comment or meta:General requests, not sure which). --Redrose64 🌹 (talk) 17:08, 29 June 2019 (UTC)
• Just concentrating in the English Wikipedia, which we can influence even though the WMF has made it clear that this is only influence and not power, how about just having a link in the left side panel to Other language Wikipedias? I'm not convinced that this misconception is widely held enough to justify changing the strapline. Phil Bridger (talk) 17:40, 29 June 2019 (UTC)
• Wrong venue and even if it weren't this is like changing a chandelier in a condemned house as long as the T&S controversy rages. —A little blue Bori v^_^v ^Bori! 18:21, 29 June 2019 (UTC)

Proposal: Renaming Wikipedia:Village Pump

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.

---

Simple suggestion - A proposal to have Wikipedia:Village Pump to be renamed to Wikipedia:House of Wikipedia — Preceding unsigned comment added by Regice2020 (talk • contribs) 18:59, 29 June 2019 (UTC) Having it named Village pump sorta indicates small amount come here, but having it named House this can match million for people who used Wikipedia to edit. Regice2020 (talk) 19:03, 29 June 2019 (UTC)

Support or Oppose

• Oppose Why? --Redrose64 🌹 (talk) 19:02, 29 June 2019 (UTC)
• Oppose - Nonsensical. —A little blue Bori v^_^v ^Bori! 19:31, 29 June 2019 (UTC)
• Oppose - House is still too small, even a large house could only hold about a thousand people. Suggest Wikipedia:Cattle ranch. (Not really.) As said below, this is what we often call a solution in search of a problem, not that I care for the dismissive tone of that phrase. ―Mandruss ☎ 19:36, 29 June 2019 (UTC)

Clearly @Mandruss: is the person to know - can I come stay in your 1000 person house? Nosebagbear (talk)

Obviously a terrible idea- "Wikipedia:City Center" is the only logical title⸮ TheAwesomeHwyh 00:29, 1 July 2019 (UTC)

• Oppose as idiotic and that's the politest way of putting it. –Davey2010^Talk 19:41, 29 June 2019 (UTC)
• Oppose - Personally, I wish we had gone with “Village Pub” back when we were naming things. But too late to change it now. Blueboar (talk) 20:51, 29 June 2019 (UTC)

  @Blueboar: wikivoyage has got you covered. — xaosflux ^Talk 00:36, 30 June 2019 (UTC)

• Oppose - as said, there doesn't seem a reason for this. @Regice2020: - have you seen people being unable to find VP? And even if you have, would "House of Wikipedia" be notably easier? Nosebagbear (talk) 21:14, 29 June 2019 (UTC)
• Oppose Good faith proposal but this is DOA. I suggest the OP withdraw this before it starts snowing. -Ad Orientem (talk) 21:19, 29 June 2019 (UTC)

Comments

(after edit conflict with another editor making an identical edit to that which I was trying to make) Why? Phil Bridger (talk) 19:05, 29 June 2019 (UTC)

In response to the original poster's explanation, a village pump is precisely the kind of place where everyone has to go. How else would you get any water? "House of Wikipedia" sounds like a royal dynasty or a department store, both things that many people, such as me, would rather avoid. Phil Bridger (talk) 19:11, 29 June 2019 (UTC)

Before changing anything in an established system (such as Wikipedia) you should first establish that there is a need for a change, such as the existence of a problem that requires a solution. So: where is the need for change? --Redrose64 🌹 (talk) 19:20, 29 June 2019 (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.

End the Signpost

Should Wikipedia:Wikipedia Signpost be discontinued? wumbolo ^^^ 20:11, 2 July 2019 (UTC)

Survey (End the Signpost)

• Yes. Many have asserted that editorial changes would solve disputes, but the team of editors keeps getting worse and the harassment more vicious. I love reading old Signpost articles, but I believe that it has become a net negative and a waste of time. wumbolo ^^^ 20:11, 2 July 2019 (UTC)
• No The Signpost (for which I volunteer) is not only the editing community's best news source for the Wikipedia movement, it is one of the best collators of community sentiment, helping all to understand where we collectively sit. Especially now, under the dictates from a distant home OFFICE, a sense of collaboration and community is key. Wumbolo, a non-contributor upset about perceived sleights, wants to kill what little community conversation we have outside massive RfCs and talk page discussions. Chris Troutman (talk) 20:19, 2 July 2019 (UTC)
• No. This request by Wumbolo is insufficient because he cites the editorial board (for which I am a member) as the problem. My apologies to Wumbolo for any distress that our coverage has caused, but I'm not exactly empowered to change the direction of the Signpost here. I wasn't even involved with the last issue nor do I even have the influence or control to make publishing decisions. No offense to Smallbones, but the paper is currently structured to run like a benevolent dictatorship à la Leviathan. Our people are great, but our structure is what's lacking. –MJL ‐Talk‐^☖ 20:34, 2 July 2019 (UTC)
• No but the culture there needs to change (see [3] in particular), big time, and become much less of a walled garden. The Signpost has a purpose, and publishing mockery, anonymous allegations, and BLP violations is not part of it. Headbomb {t · c · p · b} 20:34, 2 July 2019 (UTC)
• No Wumbolo has failed to present evidence that The Signpost is a net negative. Cullen³²⁸ Let's discuss it 20:36, 2 July 2019 (UTC)
• Not yet. The Signpost needs to stop pretending Gamaliel and others didn't happen and stop pretending that policy doesn't apply to them, but there's still a legitimate function for it. ‑ Iridescent 20:37, 2 July 2019 (UTC)
• Not Never One of my favorite things about Wikipedia. More please. -- GreenC 20:58, 2 July 2019 (UTC)
• Not quite time: In my view, The Signpost has its issues: it seemingly always manages to inflame and infuriate its readership; the editor-in-chief needs to consider their words and actions long before the newsletter goes to press; and the culture over there needs serious change in light of Headbomb's good suggestions. Having said all that, however, I believe it serves its function as an internal newsletter quite well. For now, it should remain. —Javert2113 (Siarad.|¤) 21:20, 2 July 2019 (UTC)
• No. They are trustworthy and I enjoy their reporting. Anne drew (talk) 21:29, 2 July 2019 (UTC)
• No - No reason has been provided, and we shouldn't delete something all because of one silly report. –Davey2010^Talk 21:45, 2 July 2019 (UTC)
• No. It may need a bucket of cold water thrown over it, and some extra heads to restrain some of its excitability ... but while its's not as good as in the old days, it remains a net positive. --BrownHairedGirl (talk) • (contribs) 23:51, 2 July 2019 (UTC)
• No What is it about Wikipedians, babies and bathwater? Triptothecottage (talk) 23:56, 2 July 2019 (UTC)
• No. The current issue around the Signpost is 100% fixable, and is only one case out of many that have gone otherwise fine. --Masem (t) 00:02, 3 July 2019 (UTC)