Wikipedia:Village pump (proposals)/Archive 159

Surely file redirects from meaningless names should not usually be deleted. See

wp:FILEREDIRECT. Thincat (talk

) 08:10, 17 June 2019 (UTC)

File redirects are generally kept for attribution reasons, especially if the files are likely to have been reused elsewhere. However, most of the files requiring renaming right now shadow Commons, and should be handled with the help of suppressredirect. I'll note that this has been proposed before (1 2 3), including at the time of the introduction of the right. --AntiCompositeNumber (talk) 10:50, 17 June 2019 (UTC)

If you have a sufficient tenure and are regularly running in to this, you can request pagemover access just for this use case, as it already includes that permission. (It is redirectsuppression criteria 5) — xaosflux ^Talk 12:01, 17 June 2019 (UTC)

Yeah, I just was going to say that - also,

WP:G7 (nor should admins be deleting it, but sigh..) Galobtter (pingó mió

) 12:59, 17 June 2019 (UTC)

File mover is pretty useless honestly, may as well combine it into the page mover userright Satellizer el Bridget ^(Talk) 01:06, 19 June 2019 (UTC)

Is there a particular reason why various infoboxes use different words to portray when the thing in question was founded? For example, Infobox university uses "established", Infobox organization uses "formation" and Infobox company uses "founded". For consistency, wouldn't it be better to agree on a common term and use it across all infoboxes. Perhaps "founded"? Morris Schaffer (talk) 18:19, 19 June 2019 (UTC)

The terms aren't synonymous. To found is to originate, create, initiate (something which continues to exist thenceforward); to establish is To set up on a secure or permanent basis; to form is To give form or shape to (all three from OED). A university is intended to last forever; a company is intended to last until it goes bankrupt or is absorbed by another company; an organisation isn't necessarily intended to be permanent, as they often have a specific objective and are dissolved once that objective is met or becomes unattainable. ‑ 

Iridescent

20:02, 19 June 2019 (UTC)

Hi,

since there is currently now way to download PDF versions of books from the Book: namespace and there are currently no plans to implement such a feature I propose that I run a bot to create such PDF versions and upload them to Wikipedias File: namespace. This way users can directly downloaded them from the pages in the Book: namespace. I expect to update each of them once in 200 days.

The following examples show how PDFs will look like:

https://drive.google.com/drive/folders/17g5Ey6jauKd3CLMDNBOnV3RYKcJN0QZu?usp=sharing

This proposal was started in idea lab on 19 May 2019:

Wikipedia:Village_pump_(idea_lab)/Archive_29#Re-enabling_downloadability_of_Books_/_Collections

Dirk Hünniger (talk) 21:25, 19 June 2019 (UTC)

Category:Wikipedia books (community books) shows about 6,700 books is that how many would be added to File: space? -- GreenC 16:32, 20 June 2019 (UTC)

My goal is to add all of them. Still there might be some unforeseen effects. So I expect something like 90 % within the first two years to be quite realistic. I currently expect a disk usage of around 300 GBytes in total. Dirk Hünniger (talk) 16:47, 20 June 2019 (UTC)

Thanks. Seems like a reasonable idea. My only thought was Commons but since this is specific to Enwiki makes sense to organize files locally. -- GreenC 17:23, 20 June 2019 (UTC)

Question... I am unclear as to the purpose of the bot... How do you envision our editors using it in an article? Blueboar (talk) 17:15, 20 June 2019 (UTC)

It's not a user run bot. It creates PDF files of Wiki Books and uploads them to File: space. It's so end-users can access Wiki Books in PDF format. -- GreenC 17:23, 20 June 2019 (UTC)

Ok... but why do our editors need to access Wikibooks in PDF format? Do you see it helping with citations or something?

I get that you want to use Wikipedia as a host for these PDF files, but I’m not sure if that is our function. I don’t see how hosting these PDFs benefits Wikipedia and our function as an encyclopedia. Blueboar (talk) 17:35, 20 June 2019 (UTC)

FYI it's not my proposal ("you want to"). We already hosts these books in the Book: namespace. There is consensus for this content to be hosted on Wikipedia. I don't see a problem making it available in PDF format. -- GreenC 17:58, 20 June 2019 (UTC)

The value of these PDFs is that they reflect the current version of the articles. Having fixed PDFs would be rather pointless.

b

} 18:25, 20 June 2019 (UTC)

The PDF are going to be updated regularly. The update frequency is a question of computational resources, and thus money. The advantage is that the PDFs can be downloaded in seconds even for large books containing hundreds of articles, while the PDF generation might take hours in such cases. I am planning to add a link to the PDF file of each book on the page of the book in the booknamespace. So there is nothing changed in the experience of our editors. Its just going to change the experience of end users who are in need of getting a full copy of book in the book namespace. The on demand rendering is already available here: http://mediawiki2latex.wmflabs.org/ http://mediawiki2latex-large.wmflabs.org/ Dirk Hünniger (talk) 18:49, 20 June 2019 (UTC)

How do you plan to license these? Specifically, are you going to include all authors in the book? Are you going to exclude fair-use images? — xaosflux ^Talk 17:41, 20 June 2019 (UTC)

Yes as you seen the PDF I provided as examples above there is a list of figures and a list of contributors at the end of each PDF file. The files will be licensed under the same license as Wikipedia itself. Currently fair use images are included, but it is easy to exclude them in case there a consensus decision to do so.Dirk Hünniger (talk) 18:49, 20 June 2019 (UTC)

@Dirk Hünniger: I don't normally follow third party file hosting links, you could put your example here for better accessibility. — xaosflux ^Talk 18:51, 20 June 2019 (UTC)

Hi, its a bit of funny since I think I am not supposed to upload such a file to Wikipedia and I am just requesting to upload such a file in this very discussion. So a very nice case of recursion. But fortunately someone else has already done so, although its just a single article: File:Ion Keith-Falconer from German Wikipedia converted with MediaWiki2LaTeX.pdf

Thanks, so assuming these are not going to try to include fair-use images - wouldn't you just put these on commons? — xaosflux ^Talk 19:06, 20 June 2019 (UTC)

Well for now, I include fair use images. And as long as there is no consensus decision to exclude them I am going to keep the included. And this why I am currently proposing to upload on the English Wikipeda.Dirk Hünniger (talk) 19:10, 20 June 2019 (UTC)

We are a group of researchers at the University of Minnesota collaborating with the Wikimedia Foundation to improve ORES, a machine learning-based algorithmic service designed to automate critical wiki-work (e.g. vandalism detection and new page patrolling). Our research team is carrying out a Value-Sensitive Algorithm Design (VSAD) process in order to engage Wikipedia community members and incorporate their tacit values, knowledge, and insights into how ORES should work in the future. You can find the full study description here.

Our team has completed interviews with 16 stakeholders, including five (5) Wikimedia Foundation employees, two (2) external researchers who use ORES in their work on Wikipedia, two (2) volunteer developers who have built ORES-dependent applications, and seven (7) editors with varying degrees of experience on Wikipedia.

Our interview data indicate that there is broad agreement across stakeholder groups about what is most important when it comes to designing machine learning algorithms, and applications that depend on those algorithms. We have derived five major values that should guide future development efforts related to how algorithms ought to operate on Wikipedia. The purpose of this post is to give the broader Wikipedia community a chance to weigh in on our interpretation of the data.

If you are interested in viewing our derivation of these values from our interview data, please view and comment on the current draft of our results here. (We will eventually publish these results in an academic, peer-reviewed venue.) The five “convergent community values” are as follows:

1. Algorithmic systems should reduce the effort of community maintenance work.
2. Algorithmic systems should maintain human judgement as the final authority.
3. Algorithmic systems should support the workflows of individual people with different priorities at different times.
4. Algorithmic systems should encourage positive engagement with diverse editor groups, such as newcomers, females, and minorities.
5. Algorithmic systems should establish the trustworthiness of both people and algorithms within the community.

Feel free to share your thoughts here, or leave comments on the google doc draft, or talk us at my or Estelle's talk pages. Thank you for your time and thoughtful consideration!

Bobo.03 (talk) 20:44, 14 June 2019 (UTC)

• I particularly like your CCVs. I also like the demonstration of what happens when individuals with different views talk to each other. Nosebagbear (talk) 19:50, 15 June 2019 (UTC)
  • Thank you Nosebagbear! FauxNeme (talk) 14:21, 16 June 2019 (UTC)
• I am extremely wary of the use of algorithmic systems in Wikipedia (I have seen too many cases where relying on algorithms resulted in unintended consequences)... so I am very pleased to see the second value listed above. Indeed, I am not sure it goes far enough. Humans can certainly use algorithmic AI as a tool, but we need to keep human judgement in the forefront. Blueboar (talk) 22:31, 15 June 2019 (UTC)
  • Thank you for expressing your wariness Blueboar. Yes, the second value emerged very clearly and repeatedly in our data. When you say it does not "go far enough," I wonder how the expression could "go further" to really capture the essence of what you're getting at? Our WMF employee participants were especially wary of unintended consequences, as you mention. Perhaps we need to highlight that more... FauxNeme (talk) 14:21, 16 June 2019 (UTC)
  • @Nosebagbear: @Blueboar: Yes, we do value having humans especially with different views in the process a lot. One of our current projects is working to develop an interface tool that can visualize algorithm/model tuning for different value trade-offs, e.g., error v.s. fairness, thus individuals with different views (or different stakeholders) can select a model that can address their primary concerns and discuss to make a collective decision about the model to be deployed in the community. Bobo.03 (talk) 14:28, 16 June 2019 (UTC)
• The document appears to show an impressively high understanding of, and respect for, the needs and values of the community. In particular I believe editors will particularly appreciate the comments of P1 (a staff member), about keeping the balance of power in the hands of the editors using the systems.
  I'd like to note that any efforts at "establishing the trustworthiness of people" is a particularly sensitive area, and any ideas in that area would most particularly require careful consideration by the community. Regarding "diverse editor groups, such as newcomers, females, and minorities": I definitely support the goal itself, however aspiration for that goal often needs to be counterbalanced by critical consideration of proposed means for pursuing that goal. It is an area where I've seen too few positive results and a few too many metaphorical roads to hell paved with good intentions. It can lead to conflict when people let that ideal come into conflict with the ideals of Wikipedia policy. To cite an existing area of tension: Most editors welcome more articles on women and minorities, but most editors also oppose giving such articles a privileged pass in deletion-discussions. Favoring inclusion of obscure (non-notable) biographies is generally not considered an acceptable means of pursuing the goal. Alsee (talk) 11:13, 16 June 2019 (UTC)
  • Hi Alsee, you raise an excellent point. When I make an editing pass on the document after this discussion is over, I will do my best to incorporate your feedback and note the tensions you have pointed out. FauxNeme (talk) 14:21, 16 June 2019 (UTC)
  • @Alsee: Thanks for sharing your thoughts. Would you like to provide more insights about the conflicts of creating more articles on women and minorities. The goal of one of our ongoing projects is to promote gender diversity in Wikipedia contents, by creating a tool to help editors identify articles that are for instance more female related but may be underdeveloped. Does the idea sound appealing to you? Bobo.03 (talk) 14:37, 16 June 2019 (UTC)
    • Notability - a topic (or a biography) is only allowed to have a Wikipedia article if there are sufficient sources of an acceptable quality. If someone is on a noble-cause to create lots of women biographies, they're not here motivated to write about a specific famous woman, they're here to dig up a bunch of random women to write about. Notice that the priority there is backwards, the femaleness of the article-subject precedes and takes precedence over how famous or Notable the person is. As long as all the new biographies are clearly notable, there's no issue. When the notability of one of those articles is questioned and a discussion is opened to consider possible deletion, there have been cases where the article-author interpreted that as an attack against the Noble Cause. Anyone seen as attacking the noble cause is, almost by definition, evil. Then there's a risk that someone, usually the article-author, calls in allies for the noble-cause. At this point normal debate about the sourcing and acceptability of the article goes out the window. It can turn into a warzone for the noble cause. People may show up to vote keep just because it's a female biography, disregarding Wikipedia article standards. People who argue the article fails our policy-standards may be accused of sexism (for opposing the noble cause). Good people end up battling against good people. Big ugly drama ensues.
      Back to the main topic, "positive engagement with diverse editor groups, such as newcomers, females, and minorities" is a good goal, but how do you accomplish that? The first obstacle is that On the Internet, nobody knows you're a dog. And beyond that, we haven't had much luck finding simple or easy solutions. We could give biographies on women/minorities privileged immunity to deletion-discussion, but I'm pretty sure most editors are opposed to padding Wikipedia with "junk biographies" to (poorly) serve a cause, no matter how appealing that cause is. Ideas for pursuing this goal likely need some level of community review. There may be policies or ideals that raise non-obvious concerns. Alsee (talk
      ) 21:00, 20 June 2019 (UTC)

This will be available as part of feature-rich mobile history page being developed as part of mw:Advanced mobile contributions project. A beta version has already been deployed on some wikis; see prototypes in this task. – Ammarpad (talk) 09:34, 11 June 2019 (UTC)

On mobile you can switch to the desktop interface. The writing is tiny, and you may have to zoom in to be able to touch the right link, but it can work. Graeme Bartlett (talk) 08:22, 14 June 2019 (UTC)

Plus it confirms that you meant to click on the rollback link to avoid accidental rollbacks.--Breawycker (talk to me!) 00:09, 17 June 2019 (UTC)

@

LittlestPetShop) (MyLittlePony

) 05:41, 21 June 2019 (UTC)

Scroll to the bottom of any page in the mobile view and you can click on the link that says, "Desktop". Killiondude (talk) 05:43, 21 June 2019 (UTC)

Why is there no article yet on

See the section entitled “wives and concubines” in the Solomon article. It may be that there are not enough scholarly works written about it to support a full article. Blueboar (talk) 01:56, 16 June 2019 (UTC)

I'd like to see one on Solomon's mines, but I think there's a lack of sources there too, Solomon doesn't mention anything outside pop-cult. Gråbergs Gråa Sång (talk) 22:56, 16 June 2019 (UTC)

see King Solomon's Mines, and In Search of King Solomon's Mines and there are also several articles about the films. eg The Search for King Solomon's Mines. Graeme Bartlett (talk) 11:46, 21 June 2019 (UTC)

Hi all! I proposed an image on

@

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

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)

I suggest adding a

• 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.--
  here
  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, 24 June 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, 24 June 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)

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

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 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: @

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,
  ^☎
  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.
  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)

Wikimedia Commons has media related to Something.

• 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.
  here
  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: @
    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)

@

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.

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.

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.

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)

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 {{
  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: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 {{
    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 {{
    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.--
  here
  05:52, 27 June 2019 (UTC)

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)

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.,

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
  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)
• Question - "When users navigate to Wikipedia, they automatically go to the Wikipedia for the particular language that their computer is configured for" When I navigate to Wikipedia itself (rather than an article from an external search engine), in the sense that I would if I didn't get how the language prefix worked (i.e. wikipedia.org (or even .com), the page is a search page that presents some of the most popular languages around the logo, with the number of articles on each. Is there some sort of place where navigating to Wikipedia in that manner redirects you based on computer (or browser) language, or are you speaking of searching a topic in a specific language in a search engine? - Purplewowies (talk) 22:14, 6 July 2019 (UTC)

  With one exception, all links to Wikipedia pages (whether internal wikilinks or URLs from outside) are language specific; for instance, the URL for this page is https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals) - the language code is the en after the first two slashes. The one exception is the URL https://www.wikipedia.org/ which is the "official" front page for the entire Wikipedia; that offers various means of proceeding further, but all of them require the user to choose a language to continue in. --Redrose64 🌹 (talk) 23:24, 6 July 2019 (UTC)

  Yeah, I understand the language code thing; it just seemed like the OP was saying if you went directly to Wikipedia and your OS language was English (and if you don't already know about different languages of Wikipedia, I feel like you'd be likely to go to www.wikipedia instead of (for example) enwiki if you were going straight to Wikipedia and not Googling), then you'd be redirected to enwiki and never see the no-language-code front page, which doesn't make sense (at least to me), and that page at least gives you an inkling there are multiple projects, regardless of what you search or where you go from there. 0_o The assertion just confused me is all because it sounded like it was talking about something in a way that it wasn't a thing. - Purplewowies (talk) 04:06, 7 July 2019 (UTC)

Hi all!

Are you curious about what tools are effective in reaching Women in Red’s goals? Are you interested in contributing to the building of scalable solutions for closing Wikipedia’s gender gap?

I’m with a group of researchers working on using Artificial Intelligence (AI) tools to promote gender diversity in Wikipedia contents and thus to close the gender gap. We want to make sure you, as an important member of the community, can be heard as we build and refine these AIs.

We would like to invite you to a quick interview to share your thoughts about gender gaps on Wikipedia and the current efforts, as well as potential solutions to them. It would only take about 30 minutes over phone or video chat. We will send you a $15 Amazon gift card as a way to thank you for your time.

For more details about our project, please refer to our Wikipedia page here.

If you decide to participate, your opinion could help build the future of Wikipedia. Hope to talk to you soon! Reply to this message here or send me an email at [email protected] and I can share more info and plan a time to connect. Bobo.03 (talk) 19:36, 3 July 2019 (UTC)

The best approach for Wikipedia in this area, is to adopt a gender-blind practice. Editors shouldn't be identified as male or female. GoodDay (talk) 16:28, 6 July 2019 (UTC)

That is a terrible approach. — The Hand That Feeds You:^Bite 21:43, 6 July 2019 (UTC)

Not to mention it's already a thing. You don't have to bring up your gender or lack thereof unless you wish to. Heck, I'm a woman and while I mention it offhand sometimes, on the software end I'm gender-neutral in my preferences. I think gender-blind is a bad idea because it doesn't necessarily address actual issues that might be causing a gender gap in Wikipedia's editors (that have potential solutions on Wikipedia's end, anyway). (Maybe for other reasons too.) But I feel like I don't have any ideas I could put into words that are applicable to this issue on Wikipedia in terms of helping alleviate it, myself. - Purplewowies (talk) 22:08, 6 July 2019 (UTC)

• @Bobo.03: Is there no way of participating in text (e-mail or talk page)? I'd be interested in participating but don't use telephone or video chat. Espresso Addict (talk) 07:23, 7 July 2019 (UTC)
• What gap are you referring to? The alleged gap among editors or among articles? Or both? Are you not starting from a dubious premise, ie: that there is a noteworthy gap and that, if so, it can be fixed? All this said, I echo Espresso Addict re: the means of communication. - Sitush (talk) 07:33, 7 July 2019 (UTC) To clarify: research that has a predetermined goal of improving representation of alleged marginalised groups but which uses a method that excludes people with low bandwidth and/or hearing disabilities seems somewhat hypocritical. - Sitush (talk) 07:58, 7 July 2019 (UTC)

Hi, @Espresso Addict: @Sitush:, yes, guess we can do it through user talk page if live audio chat is impossible for you, though it’s always the best to chat alive, so that we can ask followup conversations and have a more involved chat. I’ve left a message on your talk page. Looking forward to hear back from you. Thanks!

We refer to the content gender gap (e.g., gaps among articles, etc). We are working on this project with the goal of helping close the gap and we’d hope it would work. Bobo.03 (talk) 03:36, 8 July 2019 (UTC)

@

second wave of feminism, the Caroline Herschels

are the exception rather than the rule. The gap should be commensurate with the biases of history.

A wording/mentality that will help you win support is language that recognizes this and wants to bring the gap to what it should be given the history of the world. Reducing the gap is good. Achieving parity (fully-closed gap) is, in many fields, impossible and undesirable. If, in the 1970s, biology had a 60% men/40% women breakdown, then biographies from the 1970s should have a rough aim of having a 60%/40% breakdown, although that has to be adjusted in light of bias against women. Many will have been prevented from having career that are as prolific as men, due to a variety of reasons, and that will skew the notability curve towards men more, so maybe the end result should be 70%/30% instead of 60%/%40. Likewise, if in the 2010s the breakdown is now 20%-80% due to a shift in who studies biology, the result should be around 20%-80% before adjusting for source/productivity bias.

b

} 04:00, 8 July 2019 (UTC)

Using live audio chat means you have chosen a tool that will obviously attract a very biased sample of editors. Not a wise approach when your goal is to reduce bias in another area. HiLo48 (talk) 03:46, 8 July 2019 (UTC)

Thanks for your message, Bobo.03. Editors here are very used to communicating via the medium of talk pages, and it's easy to ask any follow-on/clarification questions as necessary. Espresso Addict (talk) 03:51, 8 July 2019 (UTC)

Hello. Back in 2012, we discussed a possible MoS proposal on fictional characters at

• 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
  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: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
  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
  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)
      • I would oppose the idea as there are so many different character universes. Things for comics or fictional characters like Juliet may not apply for things that have to do with an anime/manga character and vise versa. - Knowledgekid87 (talk) 23:38, 7 July 2019 (UTC)
        • I think that's a bit irrelevant. All character articles should strive for a few things: concept and creation, involvement in the works in which they appear, reception, themes, and legacy, i.e., their focus
          should be about their real-world impacts. --Izno (talk
          ) 00:49, 8 July 2019 (UTC)
• Oppose per
  here
  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)

• Comment to several of the opinions above:
  • We are not talking about fictional character notability. We've tried setting a standard, and there just isn't any. Fictional characters must show they meet the GNG with secondary sourcing about the character, to have a standalone article. This proposal does not change that.
  • I agree that in detail, how a comic book character is treated compared to a film or television character will be significantly different at that level, but at the broad scope, there are still many common things we expect to see in all articles on fictional characters: concept/creation, development, a brief fictional summary, and reception to the character. Regardless of the media, every character should have something akin to that. There are MOS elements that apply across the board, how to write about in-universe events, concise plot aspects, etc. We don't want to get too far in the way of special approaches needed in, say, comic books for generational characters or those with many different iterations, but the same basic concepts that would apply to a notable one-off character apply there. Should a MOS for fictional characters be developed it is not intended to step on the toes of any other medium's specific MOS, and should be harmonizing those parts. --Masem (t) 18:34, 8 July 2019 (UTC)

I suggest we create a hidden category, something like Category:Pages which will not work if moved, mostly to be populated by those templates which, well, will not work if the page is moved, as they use {{PAGENAME}} in a non-trivial manner. The only ones I'm sure of are the year articles, using (directly or indirectly) {{Year in various calendars}}, but I'm sure other projects than WikiProject Years have templates which will cause trouble.

I suppose {{DISPLAYNAME}} (although not exactly a template) may also require work, but that should be a bit obvious if the mover actually looks at the page before moving it. — Arthur Rubin (talk) 18:59, 8 July 2019 (UTC)

It's always good to identify a problem before proffering a solution. Apart from the pages using {{Year in various calendars}} (which we know for sure they're not going to be renamed overnight without discussion) what other set of articles fall into this description? – Ammarpad (talk) 09:05, 9 July 2019 (UTC)

I don't know of any other systematic problems, but I've been active in WikiProject Years for some time. I suppose a database search for templates using {{PAGENAME}} might be productive, although I noticed that there are some templates which used to use {{PAGENAME}} which now use LUA modules. There are definitely some categories which use {{PAGENAME}} to locate their primary article as displayed, so that if either the article or the category is moved, the category text will be wrong. — Arthur Rubin (talk) 08:40, 10 July 2019 (UTC)

If we take the example you gave of {{

911 (year). If the code is set up to only look for numbers and unless the words "BC" and "AD" are changed, I don't see how anything should break with a page move from "911 (year)" to "911" or from "AD 1" to "1 (year)" (or even from "911 (year)" to "911 (best year ever)"). Before tagging pages with "will break if moved" its a better idea to first see if the design is set up correctly. --Gonnym (talk

) 09:01, 10 July 2019 (UTC)

Minceraft is Minecraft easter egg. Please create easter egg section in Minecraft article and redirect Minceraft there.

09:14, 10 July 2019 (UTC)

Discuss at

WP:SIGNATURE.) — Arthur Rubin (talk)

10:05, 10 July 2019 (UTC)

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)

New Developments (July 10, 2019):

• Webcite is now back online. What happened this time is unknown.
• They are not accepting new pages to be saved.
• As the RfC nominator I should disclose that I am now a Paid Editor of Internet Archive, which happened recently after the RfC. More information at User:GreenC/Paid editor. I am not paid expressly for this project or RfC but I guess anything is related. This RfC was initiated on my own volition, was not requested by anyone nor is it connected to why I became a paid editor. A 5 week outage with no communication from WebCite, and the long history of outages, is why.
• Bots started replacing dead WebCite links abut that has stopped since they are online. -- GreenC 17:13, 10 July 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
  WP:BIAS.] Boud (talk
  ) 16:43, 22 June 2019 (UTC)
• Support per above.--
  here
  05:50, 27 June 2019 (UTC)
• Support per above. Johnbod (talk) 00:38, 2 July 2019 (UTC)
• Support no downside, lots of positives.
  b
  } 01:05, 3 July 2019 (UTC)
• Support with certain qualifications. In software development, 'deprecated' usually means the use of the feature is discouraged and it will most likely be removed in a future version. I think it should just be discouraged indefinitely, or until the service becomes trustworthy again (or completely dysfunctional). And I think it should be acceptable to use WebCite as a secondary archive, as a backup. Archive services go down or become untrustworthy. If Wikipedia is supposed to exist indefinitely then using just one archive service for a source is probably not a good idea.
  Template:Web cite only supports one archive link at the moment, but Template:Webarchive supports several (Thanks to User:GreenC for pointing that out). Cite-web should probably be expanded to allow multiple archive links. Bots should only add archives, not remove or replace archive links unless they are dead. Hecato (talk
  ) 15:44, 10 July 2019 (UTC)

• 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)
• @
  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. [2] 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)

Support with amendment "Archive diversity is important..." agreed. We should avoid discouraging people from using WebCite, while archiving content with other services. Other services could go down as well. The most important reason to continue archiving pages with WebCite is addressed in the article on this service: "WebCite checks robots.txt only at the time of archiving, Internet Archive checks robots.txt occasionally, so changes in robots.txt (which can be caused by a change in the ownership of the domain name) can result in removing the cached pages from the Internet Archive." Otherwise the new owner of a URL could destroy all record of the publisher who owned the URL before by using robots.txt.--Truthtests (talk) 22:19, 9 July 2019 (UTC)

That robots.txt information is outdated. Internet Archive largely ignores robots.txt in part for the reason you describe. More information at Wayback Machine. -- GreenC 22:48, 9 July 2019 (UTC)

As it (to me at least) appears to be the easiest way to access ongoing discussions, I think it should be on the sidebar (maybe below the Com. Portal). Should it?

Yep, go for it. ——SerialNumber54129 10:12, 11 July 2019 (UTC)

I cannot, as I am not an iadmin and cannot find it on the Wikidata page (I guess I should clarify this was brought here because it would be a site-wide change). Unless I'm just confused?

talk

) 10:29, 11 July 2019 (UTC)

Did you know why most of the templates are protected? It's because they're high risk. To prevent vandalism, we should do this. Is that okay? 114.124.165.28 (talk) 09:16, 12 July 2019 (UTC)

This is already done where appropriate; see User:MusikBot II/TemplateProtector. Protecting each and every template by default is probably overkill. -- zzuuzz ^(talk) 09:44, 12 July 2019 (UTC)

Also, any vandal who knows enough to go mess with the templates would probably already be Autoconfirmed. Nosebagbear (talk)

There is a clear consensus to replace the current design with the proposed design for:

1. Semi-protection
2. Move protection
3. Pending changes protection
4. Extended confirmed protection

Permanent protection

was not changed.

Some editors objected to replacing the current design with the proposed design for:

1. Full protection
2. Template protection

largely because of the concerns raised by pythoncoder:

The full protection and template protection locks look too much like the interface-protected lock vs. under this proposal. We should not be making the locks look identical in the name of branding.

There is no consensus for or against the "full protection" and "template protection" proposed icons owing to many editors not specifically discussing them so there is no prejudice against opening a new RfC to discuss only these two proposed icons.

Cunard (talk) 09:37, 14 July 2019 (UTC)

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.

---

Hello everyone. Padlock icons have been redesigined to be more accessible which is great but they lack one small part, using the consistent color scheme we are using in the interface. Recently, several parts of the interface have been recolored to algin with the software interface. More generally speaking Wikimedia UI style guide. You can see the discussions in Special:Diff/754712927. In short, we use the same blue shade (#3366cc) as much as possible, from "Publish edit" button to the left border of ambox (notice) to color of links in mobile frontend, this blue-ish plus a dedicated set of grays is to give feeling of ink and book and giving a consistent look/experience to readers and sort of brand ourselves with those colors. Lots of small and invisible changes have been made (like chaning background of wikitable and infoboxes) to help aliging with the consistent color scheme. This padlock icon recoloring is a good step too IMO. Most changes are invisible to naked eye and we don't need to agree on all of them, you can shout out that color of padlock "foo" seems wrong to you. You can see the reasoning behind this color scheme in Wikimedia UI style guide.

Type of protection	Current design	Proposed design
Permanent protection †
Full protection
Template protection
Semi-protection
Move protection
Pending changes protection
Extended confirmed protection		Extended confirmed protection

† No change, added for reference

Do you support this change? Thanks! Ladsgroup^overleg 21:09, 29 May 2019 (UTC)

• To my eye, the only padlock that looks different is full-prot. The rest look virtually identical. —A little blue Bori v^_^v ^Bori! 21:16, 29 May 2019 (UTC)
• Support since I can think of no possible negative consequence of this. It's not clear to me that this change does any good, but if there's no real drawback and you think it's helpful, then I'm all in favor. Go for it. Ajpolino (talk) 22:16, 29 May 2019 (UTC)
• Semi, ECP, and Pending look almost exactly the same. Move barely changes. Template goes from a pink to a red and Full goes from a gold to an orange. Those last two are the most likely to be controversial. I'd definitely support the first four. --AntiCompositeNumber (talk) 22:32, 29 May 2019 (UTC)
• I can see the move icon get notably bluer with the Wikimedia UI color, but otherwise have similar opinions to AntiCompositeNumber. * Pppery * _{it has begun...} 22:43, 29 May 2019 (UTC)

  For clarity, Oppose full and template, support others. * Pppery * _{it has begun...} 02:09, 5 June 2019 (UTC)

• Oppose for full and template only, support others. The full protection and template protection locks look too much like the interface-protected lock vs. under this proposal. We should not be making the locks look identical in the name of branding. —pythoncoder (talk | contribs) 18:10, 1 June 2019 (UTC)
• Support these minor changes. I find myself agreeing with User:Ajpolino: There's no obvious harm, and you think it's helpful, so let's do it. WhatamIdoing (talk) 05:35, 3 June 2019 (UTC)
• Ambivalent support. Minor changes which don't do any harm (though I can't say any good they do either). – Ammarpad (talk) 05:54, 4 June 2019 (UTC)
• I don't feel strongly either way. —TheDJ (talk • contribs) 07:12, 4 June 2019 (UTC)
• Oppose full per User:pythoncoder, indifferent/support the rest. – John M Wolfson (talk • contribs) 00:09, 5 June 2019 (UTC)
• Oppose the Yellow 30 for full prot, the golden lock just looks better to me and yellow30 seems to "brown", from the reference palette, Yellow 50 seems to bright as well. — xaosflux ^Talk 03:41, 5 June 2019 (UTC)
• Comment What about changing the full protection shackle to be more like the one used at Commons and other wikis, for the sake of consistency? funplussmart (talk) 19:27, 10 June 2019 (UTC)
  • Comment On "other wiki", the symbols are chosen because a letter won't make sense. Viztor (talk) 00:56, 14 June 2019 (UTC)
• Oppose for full and template only, support others per pythoncoder.--
  here
  17:22, 12 June 2019 (UTC)

• Moved back from archive for closing. Ladsgroup^overleg 22:55, 9 July 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.

If a topic does not meet general or subject-specific notability guides, but is noteworthy enough to be covered in some degree at another article, then it can be redirected (with or without merge) instead of being deleted. If a topic of marginal notability is covered at two or more articles and there is no clear primary redirect then this doesn't work. An "Article Interlink Page" (Ok, there is probably a better name) would allow a better and consistent handling of topics of some level of noteworthiness but limited RS coverage. It would be not entirely unlike a

• 1-2 fully-referenced sentences outlining the topic and ending in a colon
• A bulleted list of brief claims of noteworthiness, each with a bluelink where the topic is covered and an RS reference. Links to indefinitely bounded lists are not to be included (eg, a list of those holding a particular notable position is fine, while a list of people in a particular occupation is not)
• An AIP footer (different for different types of AIP) which would run something vaguely like This
  creators
  .
• Reflist
• Appropriate categories

I believe that this restricted format would:

• provide an intermediate level of inclusion between those who should have no article and those who should have a full article -- something approximating a mini Who's Who entry.
• allow a less bitey way of handling (particularly) a bunch of biographical articles of marginal notability without opening the floodgates for definite non-notables
• be resistant to promotionalism
• simplify some decisions at
  WP:NPP
• reduce some of the inflows into AFD and provide
  an alternative to deletion
  for some of those which do make it there.
• be better than a bunch of scattered redlinks (possibly with inconsistent naming)
• be searchable/categorisable (and probably highlightable in article text with script)
• be potentially bot-identifiable where restrictions are not met (>2 sentences in intro, bullet without reference, bullet without bluelink, bluelink without mention, link to indefinite list, ...). Removal of the AIP template should triggers NPP as conversion of a redirect does.
• provide some guiderails for editors who wish to expand the topic

Ultimately, having the AIP might also allow us to escape the currently useful trap of presumed notability for new articles of sportspeople (as well as others such as bishops) who have limited independent and significant biographical coverage immediately available, but who would generally appear at multiple articles. They could instead be given an AIP with links to their coverage at seasonal articles (diocesanal articles, etc) until sources are actually found. ^~Hydronium^~Hydroxide^~(Talk)~ 10:46, 7 July 2019 (UTC)

Often a topic can be shoehorned into a location article. Eg a school, or a shopping centre could be covered in that geographic location. I am not very convinced by the set index for a non-notable topic. It would be better to redirect and then link from the section to other relevant sections. Can you think where this is needed? One example could be the location of some crime that is newsworthy enough to make a location article, and the business could be part of a chain. But it is probably "undue detail". Graeme Bartlett (talk) 12:11, 7 July 2019 (UTC)

@Graeme Bartlett: Some examples of the type of thing where I see an AIP as a useful option would be:

• Musical groups with multiple bluelinked members (potentially meeting NBAND#6) but not sigcov
• Musicians with extemely limited RS biographical coverage who appeared in multiple bluelinked bands (potentially meeting NBAND#6)
• Creators with limited public profile who don't meet WP:CREATIVE but with multiple works that would meet NBOOK, NFILM, etc due to a marginal level of critical coverage.
• Minor actors with multiple film/tv feature roles and basically no RS bio coverage
• Winners of bluelinked pageants with limited coverage who subsequently went on to a further bluelinked pageant
• Companies with limited coverage but multiple notable products
• Unsuccessful party political candidates with some level of coverage at multiple bluelinked elections

^~Hydronium^~Hydroxide^~(Talk)~ 13:27, 7 July 2019 (UTC)

I think it could be case where

WP:XY applies. Emir of Wikipedia (talk

) 21:26, 7 July 2019 (UTC)

• Oppose this idea. I believe there is value in in-prose redlinks because they encourage eventual article creation (even if that means waiting until the subject's notability can be demonstrated). I also think creating an additional set of pages that are exempt from
  WP:N is a bad idea. UnitedStatesian (talk
  ) 21:32, 10 July 2019 (UTC)
• I don't think this is a bad idea. In a way, that's almost what already happens if the subject's name is ambiguous: there'll be a dab page and the relevant entry there is sort of a mini version of what an interlink page would look like. – Uanfala (talk) 17:08, 14 July 2019 (UTC)

I think the current password policy isn't that effective for some reason. There are still compromised accounts that are trying to edit the Main Page. I think we need a new password policy for these users.

The new policy is:

• at least ten characters including at least a capital AND a lowercase letter
• at least a number and a symbol
• shouldn't be in the fifty most common passwords

Thanks 114.124.165.28 (talk) 09:34, 12 July 2019 (UTC)

See

2FA. -- zzuuzz ^(talk)

09:41, 12 July 2019 (UTC)

Enforcing what appears in a password is known to negatively impact recall of the password, and That Leads To Re-use. However, two of your requirements are already met; see link above. --Izno (talk) 14:01, 12 July 2019 (UTC)

I think the meta password policy is sufficient for advanced users without specifying which character components are necessary. — xaosflux ^Talk 13:24, 14 July 2019 (UTC)

I'd personally like to see an optional 2nd factor introduced into the login process ... or is that, in fact, already available? --User:Ceyockey (talk to me) 02:32, 15 July 2019 (UTC)

Help:2FA. — JJMC89 (T·C

) 03:52, 15 July 2019 (UTC)

Whenever I visit a Wikimedia Foundation website for the first time, it always leaves a welcome message on my talk page.
Granted, the talk pages for different projects are kept separate, but these messages seem presumptuous at best.
It would be nice if there was an option to opt out of greetings, so that I could go from project to project without needing to bother with dismissing notifications. Daniby2013 (talk) 05:26, 16 July 2019 (UTC)

There are no such automated greetings here, and we can't control here what people on other projects do. You may want to take this to somewhere on Meta. Anomie⚔ 11:18, 16 July 2019 (UTC)

@Daniby2013: OK, so it looks like you have 22 attached accounts for WMF public wiki's. Of those, it looks like you were greeted by a person twice, a bot 3 times - but most of the time (17 times) noone greeted you at all. Are you seeing something different, because it seems very far from "always". If you don't like how a specific project greets people, you would have to bring it up with them. — xaosflux ^Talk 01:54, 17 July 2019 (UTC)

@Xaosflux: I seem to have misremembered the frequency with which these messages are sent, but I reaffirm that a message being sent without any prompting is still bothersome.

However, seeing as this is a niche issue with a solution requiring significant changes to the Wikimedia infrastructure, I suppose I'll just have to make do. Daniby2013 (talk) 09:06, 17 July 2019 (UTC)

@Daniby2013: OK, if you "edit" on lots projects you may get a bunch of the "congratulations on your first edit" notifications. You may be interested in following phab:T21161 and the related task phab:T30369 that could alleviate your original condition if they were implemented. — xaosflux ^Talk 12:10, 17 July 2019 (UTC)

See

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

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)

I like the idea and would support such a proposal. There are always large numbers of new articles coming through at NPP that pose the problem outlined by Colin M immediately above: not such sheer promotion that they could be CSD'd, not suitable for a jaunt at AfD because they could conceivably be cleaned up, but cleaning up would take a fair amount of (disagreeable, grudging) work and is not likely to happen in a hurry. Result, promotional content live in mainspace for an indeterminate length of time. Having a clear mandate to refer the responsibility of making these acceptable back to the creator would be most welcome. --Elmidae (talk · contribs) 17:37, 5 July 2019 (UTC)

It is already common practice for new page patrollers to draftify newly created articles that are not ready for mainspace (

WP:DRAFTIFY) and they can expire there then get deleted if inactive. If I understand this would be different and recommend to do it even with older articles that have long standing COI/promotion issues, but not blatant enough for CSD/AfD? I have a concern though: there are so many and there's the issue of cross-namespace redirects and cross-namespace wikilinks not allowed when moving non-orphans (so we'd treat those links just like for deleted articles, presumably). Where to draw the line, how to evaluate? We'd probably need a few guidelines as part of the proposal... —PaleoNeonate

– 21:07, 5 July 2019 (UTC)

I expect that cross-namespace redirects would be deleted, as they are with any article moved to draft. We probably would need some additional guidelines, but I think the standards would not be much different from those for moving a new article to draft space. Consider, if one article is brand new, and another of the same quality is ten years old, why should the new one be moved to draft and the old one allowed to remain in mainspace merely because it is old? Perhaps there is some greater chance that the authors of the new article will still be around to improve it, but that is not a good reason to maintain bad content in mainspace perpetually. bd2412 T 01:30, 6 July 2019 (UTC)

• Moving to draft is equivalent in many cases to a six-month-delayed speedy deletion, with less admin supervision than the other speedy criteria. That's a no, in case there was any doubt. They are far more likely to get improved in mainspace. In my experience we need less draftifying not more. It's entirely acceptable to take any long-term tagged article to AfD if its net benefit to the encyclopedia seems in doubt. Failing that you could always try improving it. Novel approach, but it has been known to work. ETA: See for example Ntoi Rapapa (although that was moved as a BLP lacking sources) & King Billy Island which continue to exist only because I idly refreshed the G13 queue before going offline. Espresso Addict (talk) 04:04, 6 July 2019 (UTC)

  We are talking about over 30,000 articles here. Sure, they should be improved, but if the people writing them are using Wikipedia to advertise, then they should be given some incentive to clean them up other than their being a tag on the page. We have articles that have been tagged like that for over ten years. bd2412 T 14:34, 7 July 2019 (UTC)

  This seems to come down to a preference for, regarding a given notable subject, having no article until someone writes an acceptable one; versus having live a bad, promotional article, for a possibly long period. I do prefer the former. --Elmidae (talk · contribs) 17:41, 7 July 2019 (UTC)

• Support proposal. I appreciate all the hard work editors who patrol these pages take. Pages with serious COI and advert issues that are on notable subjects and aren't suitable for mainspace should be moved to be moved to draft. Our policies and guidelines shouldn't allow COI editors to game the system. --Gonnym (talk) 14:49, 7 July 2019 (UTC)
• There are too many of them, and too few people to fix them. I can fix about 2 a day if I do little else-- 1 a day is more realistic, which for me comes to about 25 a month, or 150 in 6 months, which is the standard time at Draft. There are probably about 20 other people who could do as much, lets suppose half of them are willing, that's 1500. Othe people who waould do a smaller about woul dprobably do at least as much as those of us willingto concentrate on it, so that's about 4,000 in 6 months. We have about 5 times that. Of course, not all will be fixable, but the only way to see that is to try--if they were obviously unfixable they swould have been deleted not tagged. But more fundamentally, this is furthermore an improper use of draft space. The criterion for promoting from draft to main space is that the article would probably pass afd. These arearticles thathave not been deleted--standard were lower in the past, but even so, probably half of them would have a decent chance of passing afd--and, if so, they should't be in Draft space.We already have a considerable amount of confusion in AfC about the proper standards for passing, and we already have a lage of about 2 months for the non-obvious drafts. All of this would be made much worse. Kudpung, and those few people of us who have been helping him over the past three years have managed to at least keep AfC/draft from being an inconsistent chaos, and this would negate all that we've been doing. DGG ( talk ) 19:03, 10 July 2019 (UTC)

• Support At least it is one tiny step in the good direction. But more steps are needed. I have too often seen promotional articles being kept at AfD as "it can be fixed by normal editing". And then it stops and the promo stays there. The Banner talk 19:47, 10 July 2019 (UTC)

• Support in principle, and
  WP:ARS
  is the best venue for such articles that might show some potential for surviving AfD.

The Draft namespace was created thus allowing the useless

WP:INCUBATOR

(where articles were left to rot indefinitely) to be deprecated. Drafts can be quasi automatically deleted G13 if they are not touched for 6 months, and this is good, but the namespace should not deliberately be used as a backdoor route to deletion.

Over the past 12 months a lot of work has been done, and for once with excellent collaboration between the community and the WMF coordinated by MMiller (WMF), myself, DGG, Barkeep49, Primefac, Insertcleverphrasehere, Kvng, Vexations, and others to modernise the two systems with new technology, and the work done at WP:Copypatrol by Diannaa and Sphilbrick.

Nevertheless it's probably too late for the 18,000 pages tagged as {{

WP:NPR

user right, only two (yes, 2) are doing well over 90% of the work.

We need fewer minor-rights hat collectors, and more truly skilled and qualified reviewers who can work quickly but judiciously through their respective article feeds - which incidentally are now both available at the combined feed. Kudpung กุดผึ้ง (talk) 23:24, 10 July 2019 (UTC)

• Support. This is de facto already part of the
  click me!)
  23:41, 10 July 2019 (UTC)
• I also support this. We as an encyclopedia need to be serious about SPAM as there are huge financial incentives for people to use us in ways counter to our mission. As Kudpung points out having skilled editors make this determination while still giving time for notable content to actually be improved strikes me as a win. It also seems like this might be easier for some people if G13 were a PROD rather than a speedy but that's a different discussion for a different day. Best, Barkeep49 (talk) 23:57, 10 July 2019 (UTC)
  • I want to point out that the standard for accepting at AfC is that thearticle will probably pass an AfD.Articles that are only somewhat promotional will generally pass AfD if the subject is more than borderline notable. (It's been a major accomplishment in the last year or 2 that the ones that are borderline promotional nd borderline notable generally do not get kept--a few years ago the argument that even the borderline ones should stay and be improved in mainspace was generally accepted, and it sitll sometimes is, because AfD is by its nature inconsistent. So if we move to afc, and then they get accepted by a reviewer, who thinks they will pass, many possibly most, of them will be kept, with the cost of everyone involved doing a great deal work both at afc and afd with nothing to show for it. Remeber that anyone may assign a coii or advertising tag, whheher legitimately or illegitimately, and it is actually posssible that about 1/3 actually do deserve to stay in mainspace and be improved. DGG ( talk ) 14:09, 12 July 2019 (UTC)

D.

• Semi-Opposed. This is just tossing a problem over the wall. Draft space is already flooded with junk, and the folks who work there are
  WP:AfD. -- RoySmith (talk)
  14:36, 12 July 2019 (UTC)
• Oppose - This is a bit more than tossing the problem over a wall, it is tossing a problem into a dumpster hidden over the wall. Articles are unlikely to be improved in Draft space. When they don't get improved, they get G13 deleted after 6 months. If we want to delete these, let's delete them. Feel free to convince me otherwise but passing them through draft space is just an alternate and inappropriate delete path. ~Kvng (talk) 15:30, 12 July 2019 (UTC)
• Comment - I have another active concern about over-the-wall uses of Draft space. See Wikipedia_talk:New_pages_patrol/Reviewers#WP:NPPDRAFT_vs._AfC_acceptance_criteria. ~Kvng (talk) 15:41, 12 July 2019 (UTC)
• Oppose per Kvng.
  WP:STUBIFY). This proposal would open the door to so much abuse because it will, as Espresso Addict rightly puts it, basically mean that they will be G13ed when nobody fixes them, which is likely most of the time, especially those articles that have been in the mainspace for years and whose creators have long left. Last but not least, it's easy to forget the reader's best interest. Someone looking about information about a subject is better served by a shoddy article than by no article at all and if interested at all, might actually use this opportunity to fix some problems they perceive. Many editors got their start by noticing something wrong or missing and fixing or adding it. We should encourage these readers to become editors and that requires keeping sub-par articles in mainspace where people can actually find them. My first attempts (back in the good old days of 15 years ago) were clumsy additions of new articles on books I liked but had no article and fixing typos and suchlike, stuff I couldn't have done if there hadn't been imperfect articles to fix. Regards SoWhy
  16:38, 12 July 2019 (UTC)
• Oppose as part of NPP, I've moved quite a number of unreferenced or very badly referenced new articles to draftspace and about 99% are just abandoned and deleted as G13 unless I make an edit to avoid G13 if I think they have potential. Moving more articles such as coi will just cause more abandoned articles in a slow deletion zombie state, and is open to abuse where articles are not overtly or even slightly promotional or have no coi are moved to draftspace and in the case of older articles where the author is no longer active no-one will notice at all, thanks Atlantic306 (talk) 22:47, 17 July 2019 (UTC)
• Oppose Subject to abuse, I also feel that it would risk overriding an AfD in some cases - they could have draftified it, but chose not to. Sending them now would be overriding a broader consensus. I think the potential positives are over-optimistic, and heavily outweighed by the negatives. Nosebagbear (talk) 13:48, 18 July 2019 (UTC)
• Oppose. Sending a newish article to draft is ok; there is reason to believe the person who created the article is still around keeping an eye on it and will come back wondering where it went, hopefully see the note you left them, and fix the issues before 6 months is up. Sending older articles to draft (as in this proposal) is counter-productive if we want the articles fixed. If the article is 5-10 years old and was created by a drive-by account who is no longer editing and only watched by a handful of editors, if any, sending it to draft is a 6-month death sentence. When the article is sent to draft all the categories are removed, no one hits it via the random article button, no one will ever find it, and if no one finds it, no one fixes it. Things should only be moved to draft if there is a reasonable belief that there is someone who may return and work on it. ~
  problem solving
  13:58, 18 July 2019 (UTC)
• The best solution is to delete them, which most of them qualify for in one way or another. Draftifying just becomes a 6 month deletion rather than an immediate deletion. TonyBallioni (talk) 18:12, 18 July 2019 (UTC)
  • Therein lies the rub. An advertisement disguised as an article but still meeting a low threshold of viability will evade deletion, and may go unimproved in perpetuity. Furthermore, spammers probably know this, and know how much credible content to put into an article to gain this advertising foothold. bd2412 T 03:22, 19 July 2019 (UTC)
    • The correct response is accordingly STUBifying the page or submitting it to PROD/AFD if the topic is not salvageable. --Izno (talk) 14:17, 19 July 2019 (UTC)
• Alt Suggestion Draftifying hides the deleted edits. If we want to make it easier to delete articles on commercial entities we should implement a sticky CorpProd. A bit like BLPprod, but entirely focused on independent reliable sources. Any article on a currently trading business or commercially sold product is eligible if it doesn't have a single independent reliable sources, and adding a reliable source justifies removing the tag. At the least it should force spammers to act a bit more like Wikipedians. ϢereSpielChequers 08:55, 20 July 2019 (UTC)
• Oppose At the end of the day, it's not our responsibility to "fix" advert-filled pages. The great majority of pages meeting G11 or close to G11 need a fundamental rewrite to become encyclopedic, thus it is not going to save any work to keep them.--Jasper Deng (talk) 09:01, 20 July 2019 (UTC)