Wikipedia:Village pump (idea lab)

The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas.
Before creating a new section, note:

Discussions of technical issues belong at Village pump (technical).
Discussions of policy belong at Village pump (policy).
If you're ready to make a concrete proposal and determine whether it has consensus, go to the Village pump (proposals). Proposals worked out here can be brought there.

Before commenting, note:

This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.

Discussions are automatically archived after remaining inactive for two weeks.

« Archives, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60

Fix Draftification with a new template

Draftification has long been criticized as a backdoor to deletion. In New Pages Patrol (NPP), it is common to move new articles that are not ready for mainspace to draftspace. This way, articles that could potentially be suitable for Wikipedia, but are not yet, are preserved. The article creator then gets a chance to improve their article without NPPers breathing down their necks or having it taken to Articles for Deletion. If anyone, including the article creator, objects to draftification, the article should be moved back to mainspace (draftification should be reversed). This is explained by DRAFTNO #6 and #7. No reason is required for the objection.

Problem: However, we also have a rule that drafts that haven't been edited for six months get automatically deleted, under Criterion for Speedy Deletion G13. So, well-meaning New Page Patrollers will unilaterally draftify new articles that are not yet ready for the encyclopedia. The new editors who created the article may disagree with the move, without knowing that they can object. The new users can get discouraged and leave Wikipedia altogether, and after six months the draft is deleted under CSD G13. As this process happens without community discussions, it results in draftification being called a "backdoor to deletion".

Solution: This problem can be solved without changing policy or current practice. We just need to make it very obvious to new users that they can object to draftification. We can also make it easy to reverse the draftication (assuming the new user is autoconfirmed). I suggest we do this by adding a template to all draftified articles. The template would include a big blue button, similar to the "Submit the draft for review!" button at Template:AfC submission/draft, which says "Object to this move". Clicking this button either: 1. Leaves a message on the talk page of the editor who draftified, notifying them that there has been an objection to the move and requesting that it be immediately reversed. 2. Moves the page back to mainspace automatically, or if the editor's account is unable to perform this task, creates an entry at Requested moves/Technical moves to that effect. The latter is better, but also more technically complex. Adding a similar button to Template:Uw-articletodraft, the warning typically given upon draftification, would also be helpful.

Implementation: Once the new template is ready, it can be added to MPGuy's MoveToDraft userscript, which is the most common way for NPPers to draftify articles. It should be placed above the AfC template on all draftified articles.

I would appreciate comments from technically skilled editors, who could create this template (or tell me that it's impossible), from NPPers who draftify articles, and from uninvolved editors who have opinions on the draftification process. Toadspike [Talk] 10:37, 26 September 2024 (UTC)[reply]

This idea isn't really my own, it was obviously sparked by the most recent RfA. A similar idea was previously discussed here, but that discussion proposed a requirement that all editors have to follow (policy), not a technical solution, and turned into a trainwreck. To prevent something similar, I ask all participants to please focus on improving the current situation instead of debating the morality of draftification as a whole. Toadspike [Talk] 11:03, 26 September 2024 (UTC)[reply]

Notifying the users who commented most directly on this topic at the RfA: @Alalch E.@User:Onel5969@User:Hobit@User:Fangz@User:Nsk92. I have also notified the NPP Talk page and posted a message on Discord. I am not sure how to notifying all participants of the previous discussion (aside from doing it manually) and I am not sure that is productive considering how many people were involved and how offtopic it got, so I won't do that for now. Toadspike [Talk] 11:07, 26 September 2024 (UTC)[reply]

Are you sure you want to make this an RfC? Is there a BEFORE somewhere? Aaron Liu (talk) 11:32, 26 September 2024 (UTC)[reply]

Good point, I am not sure if the RfC label applies, so I'll remove the templates. I was looking for ways to notify people and misread RFCBEFORE. Toadspike [Talk] 11:34, 26 September 2024 (UTC)[reply]

Oppose: The draftification message could be tweaked, but a big button to reverse the move will lead to more AfDs, higher strain on NPP, more BITEY behaviour, and worse editor retention. Draft space is incredibly valuable, and people have some incredibly warped views about the space. If we did something like this then we'd end up chasing away new editors because learning how to make your article meet our complicated guidelines in under 7 days (AfD tag) is not easy for a lot of folks. Draft space gives them the opportunity to work on the content, to receive advise, and to make articles that will actually survive at AfD and allow them to stick around. Really we need to draftify more, and I've taken it upon myself to begin to do so again and encourage others to do. I'm big on editor retention. This is not the way to do it. Hey man im josh (talk) 12:15, 26 September 2024 (UTC)[reply]
The problem with unilateral draftification is that it can also be incredibly bitey, especially when done for arbitrary reasons that have nothing to do with any of the reasons why something might be deleted at AfD (although this is less prevalent than the trivial reasons things are rejected at AfC). We should be draftifying fewer articles and not sending them to AfD either but rather leaving them in the mainspace (With appropriate tags where justified) so that they can be found and improved rather than pretending that they don't exist for six months and then deleting them. Thryduulf (talk) 12:34, 26 September 2024 (UTC)[reply]
I'm not really convinced draftification is any worse than the alternatives - tagging is *also* bitey as well, and one user tagging an article and leaving it in mainspace could lead to another user seeing it and deciding to AfD. Draftification could be a way to protect an article until it enters a better state. But I think the other part I have an issue with is the lack of clear guidelines. Clearly some people have an issue with draftification and others do not, and people have different ideas what it is for. That needs to be made more concrete. Otherwise just saying "we should use draftification less" isn't going to lead to any positive changes. Fangz (talk) 12:43, 26 September 2024 (UTC)[reply]
I agree with the general sentiment – arguing for more or less draftification does not solve the problem that new users basically can't object to it. Toadspike [Talk] 12:47, 26 September 2024 (UTC)[reply]
I envision a template (possibly one specific for relatively new users?) being something like:

1. Hi, this article has been moved to a draft form because another user thinks it has potential but is not ready for the encyclopedia just yet. REASON:

2. You can continue to work on it while it's not published, though note that if not editted for 6 months it will be deleted. Here are some useful resources.

3. When you think the article is ready you can submit the article to a review, which can give useful feedback. []

4. Alternatively you may return the article to the main encyclopedia at any time and have it be editted while part of the main encyclopedia. See WP: Draft Object. Note however that if other users think there are unfixable issues with the article it may be put forward as a candidate for deletion. Fangz (talk) 12:54, 26 September 2024 (UTC)[reply]
I like the idea for the user warning. Aaron Liu (talk) 12:59, 26 September 2024 (UTC)[reply]

Tagging never leads to an article being automatically deleted. – Joe (talk) 18:43, 26 September 2024 (UTC)[reply]
In my view draftified articles should (semi?) automatically return to the mainspace after timeout instead of be deleted. Or at least be re-evaluated for notability. I do not really see the reason for automatic speedy deletion, except as backdoor deletion. Fangz (talk) 18:59, 26 September 2024 (UTC)[reply]
I like that idea. They don't, though, so it's a bit of a moot point in terms of current policy. – Joe (talk) 06:16, 27 September 2024 (UTC)[reply]

Why can't they just improve it in mainspace, without the sting on of an initial rejection and a six month deletion countdown hanging over them? I don't get why you keep presenting this as a choice between draftspace and AfD. – Joe (talk) 18:46, 26 September 2024 (UTC)[reply]
The reason is that "improving it in mainspace" has its own issues. An article in mainspace has to juggle being of service to the reader to being of service to the editor. This implies formal processes and wikijargon for consistency, unified templates for issues in the article, clear and ruthless labelling of problems and so on. There's a strong tendency for the first experience of an editor to be a very public and humiliating fight against established editors who have a better understanding of wikipedia processes, quickly driving the editor away or getting them blocked. It is also very difficult to improve on this experience as it would imply fundamental changes affecting all sorts of things. Meanwhile improving an article in draft mode allows for a more informal process of communication to shepherd an article towards an acceptable state. Fangz (talk) 19:10, 26 September 2024 (UTC)[reply]
I did a little work on page view statistics recently. The median article gets about one page view per week. So if the new article is typical, then it doesn't have to "be of service to the reader", because there aren't really any readers. Editors (especially NPP and RecentChanges folks) may look at a brand-new article a few dozen times on the first day, but once the reviewers leave it alone, most articles just don't have much traffic.

I think the reason we are unwilling to "improve it in mainspace" is because we're scared that we'll forget that it was there, and years later, someone will be embarrassed to discover that an WP:UGLY article has been neglected ever since. We are using draftification and other threats as a way to make other WP:VOLUNTEERS improve the article to our idea of acceptable quality. WhatamIdoing (talk) 20:40, 26 September 2024 (UTC)[reply]

I don't know if we're looking at different draft namespaces, but an "informal process of communication to shepherd an article towards an acceptable state" sounds like the precise opposite of our current AfC process. – Joe (talk) 06:19, 27 September 2024 (UTC)[reply]

I don't like the idea of a button but I do think the template should be changed. I think having a button suggests it's a default option, but I think a link is okay. Fangz (talk) 12:37, 26 September 2024 (UTC)[reply]

This is pretty much what {{subst:draft article}} does but MoveToDraft uses {{subst:AfC submission/draft}} for whatever reason. C F A 💬 12:41, 26 September 2024 (UTC)[reply]
For the record, I would support using either {{draft article}} or creating a new template with your proposed changes. C F A 💬 12:44, 26 September 2024 (UTC)[reply]

All AfC drafts are supposed to use the AfC template. If you're talking about the "publish now" button, that's for autoconfirmed only. Aaron Liu (talk) 12:45, 26 September 2024 (UTC)[reply]
But articles aren't inherently "AfC drafts" once draftified. People are allowed to move them back to mainspace themselves, no questions asked, or optionally submit them to AfC. The AfC draft template makes no mention of the first option. C F A 💬 12:48, 26 September 2024 (UTC)[reply]

BTW, the MTD script was changed yesterday to use {{draft article}}. -MPGuy2824 (talk) 12:48, 26 September 2024 (UTC)[reply]
Oh, I didn't notice. That's better, at least. C F A 💬 12:49, 26 September 2024 (UTC)[reply]
I wonder if we will ever quit using the inappropriate and legally unsound "publication" language in that template. On this wiki, it's the author, not the AFC reviewer, who "publishes" it. WhatamIdoing (talk) 20:43, 26 September 2024 (UTC)[reply]
@WhatamIdoing: Can you think of a better word? (Seriously, I've been trying for ages and can't come up with anything.) – Joe (talk) 07:33, 27 September 2024 (UTC)[reply]
Yes: WP:MOVE. WhatamIdoing (talk) 20:28, 27 September 2024 (UTC)[reply]
Yeah but then you have to specify "move to mainspace" or something and that feels really jargony. "Move out of draft", maybe? – Joe (talk) 04:49, 1 October 2024 (UTC)[reply]
That would work. WhatamIdoing (talk) 05:19, 1 October 2024 (UTC)[reply]

Well, that might solve the problem. I doesn't explain to new users how their article turned into a draft, but at least there's an easy way to reverse it. I won't withdraw this for now, maybe others have thoughts. (P.S. you might want to update User:MPGuy2824/MoveToDraft) Toadspike [Talk] 12:51, 26 September 2024 (UTC)[reply]

This is the idea lab so no bolded comment from me, but I have mixed feelings. I am in favour of softening the experience for newcomers, but I'm opposed to the concept of draftification being automatically reversible. If a new page patroller reviews a new article and moves it to draft because it's clearly unsuitable for mainspace, the creator should need to do more than just say "I object" in order to move their clearly unsuitable article back again. I've recently proposed that all of draftspace should be move-protected at the semi level (the proposal was not well received - fair enough). This is probably the rule I ignore more than any other on Wikipedia, mostly dealing with spam sockfarms that try to abuse the rule to promote their garbage. Besides, a new user whose submission is quarantined to draft space and they're left with instructions and a list of suggestions with helpful links is already getting better treatment than most editors ever have or will, and if their reaction to that is to rage-quit then they're probably not a good fit for the collaborative environment of Wikipedia anyway. Ivanvector (^Talk/_Edits) 12:57, 26 September 2024 (UTC)[reply]
@Ivanvector, you know the joke about "If you ask three people, you'll get four opinions"? I wonder if we ask three NPPers what "ready for mainspace" means, if we'd get four opinions. AFAICT, "ready for mainspace" most often means "contains at least as many refs as the median article, but higher quality ones". All the children in Lake Wobegon are above average, and all the new Wikipedia articles must be, too. WhatamIdoing (talk) 20:12, 26 September 2024 (UTC)[reply]
I feel like I might vaguely recall a discussion on that topic sometime in the not too distant past. Folly Mox (talk) 22:55, 26 September 2024 (UTC)[reply]
176 comments from 22 editors, and I probably had 22 opinions all by myself. ;-) WhatamIdoing (talk) 22:23, 27 September 2024 (UTC)[reply]

All pages are effectively move-protected at the semi level already. Moving requires an (auto)confirmed account. SilverLocust 💬 07:17, 5 October 2024 (UTC)[reply]
As far as I see it draftification should never be used for subjects which pass GNG, and it should only be standard for things like films/TV series/games which are in the works but have not yet begun production. Subjects with debatable notability should be sent to AFD to the issue can be resolved.★Trekker (talk) 13:00, 26 September 2024 (UTC)[reply]
Subjects that pass WP:GNG should never be draftified at all, instead they should be tagged and dealt with using normal community procedures. I agree that films/TV series/games/political events probably best fit the bill for draftifications, but so do potentially notable but underdeveloped articles. Sohom (talk) 13:33, 26 September 2024 (UTC)[reply]
This is out of step with the present form of Wikipedia:DRAFTIFY, and I don't think it makes sense anyway. Articles that fail GNG should not be draftified, they should be AfDed. Films etc that are in the works should not be draftified merely because they aren't in production, and it's not really a great use for draft space because there's no guarantee that there would be a change of situation to establish notability within 6 months. Articles should be draftified only if the reviewer believes the article can be editted into an acceptable state within the time window. This implies a pass of GNG - i.e. a belief that reliable sources are potentially out there. Remember that GNG is about the *subject*, not about the state of the article. Fangz (talk) 14:09, 26 September 2024 (UTC)[reply]
In my view the correct use of draftification is sort of as an alternative version of the WIP template. An acknowledgement that the article is not ready and should be being worked on and will likely have multiple issues, but in a protected sandboxed environment to avoid overly zealous moderation and promotion of misunderstanding for casual readers, and without implying the original editor is the one working on it. For new users it should offer a less formal and jargony process to learning how to improve an article than tagging based methods, because the latter has to balance the need to inform *readers* as well as editors. Fangz (talk) 14:23, 26 September 2024 (UTC)[reply]

If you evaluate that a article passes WP:GNG, then there is not point in draftifying it, you could just add a {{sources exist}} template, patrol and move on. Alternatively, if you evaluate that a article fails WP:GNG, there is no point in wasting the article creator's time and you should WP:AFD/PROD it.

The only case where you would draftify a article is if you saw a article that a) had a credible claim to significance/notability b) does not meet/prove notability in it's current state c) has been created in the last week or so by a inexperienced article creator. Sohom (talk) 14:43, 26 September 2024 (UTC)[reply]
Not sure if we're disagreeing or we're having some semantics thing about what "passes GNG" means.

But anyway there's issues beyond notability, in my view that's probably more useful. Fangz (talk) 15:08, 26 September 2024 (UTC)[reply]
If an article has a credible chance of being kept or merged at AfD then it should not be draftified.

If an article would definitely fail AfD and there is no editing that can fix that it should be sent to AfD. Thryduulf (talk) 15:57, 26 September 2024 (UTC)[reply]
I think then you're pretty much arguing that the draftification process should be removed entirely, and I don't agree with that. It has its advantages. It should not be made a mandatory process by any means but just as some users prefer to work on articles as a draft and then push to the public wiki, it can be a better resolution to certain issues than the alternatives. Fangz (talk) 17:44, 26 September 2024 (UTC)[reply]
I'm not sure that the Draft: namespace has any advantages over a user sandbox, and m:Research:Wikipedia article creation and m:Research:AfC processes and productivity says that the Draft: namespace is where articles go to die.

I do think that we've fallen into a false binary here. The options are not "garbage in the mainspace" vs "auto-deleted as in the draftspace". There are other options (e.g., sticky prods for uncited articles, userification, bold stubbification, bold merging, developing a more consistent and predictable standard for evaluating articles, etc.). WhatamIdoing (talk) 20:20, 26 September 2024 (UTC)[reply]
I think there is a argument to be made that this landscape might have changed a fair bit since this research was done. The latest data that these projects consider is from 2014-2017. WP:ACTRIAL happened after that research was done, and Wikipedia's policies have changed since those times. Sohom (talk) 20:48, 26 September 2024 (UTC)[reply]
It's possible that things have changed, and I'm never one to turn down a new research project if you happen to be volunteering to do it (I believe that all the necessary data is public), but looking at the overall deletion rate in that namespace, it seems unlikely that the result will be materially different. WhatamIdoing (talk) 20:31, 27 September 2024 (UTC)[reply]

I think then you're pretty much arguing that the draftification process should be removed entirely, and I don't agree with that. I'm sorry to pick on you but this is the clearest example yet of the circular reasoning that has got us into this mess: draftification must be good because we do it, so we must keep doing it because it's good. From literally the moment draftspace was created and people started doing this (before that, the equivalent process of userfication was expressly forbidden without prior discussion), others have been pointing out that the underlying logic makes no sense. Draftification is only for articles that shouldn't be deleted, but it's also only for articles that can't be in mainspace. But since fix good content in place is a part of the editing policy and almost all the community accepted reasons for deletion involve the potential of the article, not it's current state, the intersection of those two sets is functionally zero (apart from some consensus-established edge cases like paid creations or upcoming films).

This is why attempts to clarify and improve policy around draftification—and I've been closely involved in many of them—keep failing. You try to find a solid basis for guidelines and there just isn't one. We really need to stop trying to square the circle of justifying draftification as it is practiced now, and start asking what we the community actually wants to achieve with it and whether what we're doing now fulfils that aim. So far it's not looking good for the send-them-all-to-draftspace-and-the-god-of-notability-will-recognise-his-own camp, because there's not a shred of evidence that it helps improve content, retain editors or manage the NPP workload, and as WAID says above the empirical studies we do have concluded the precise opposite. But that picture could change with more research – somebody just needs to step up and do it! – Joe (talk) 07:01, 27 September 2024 (UTC)[reply]
@Joe Roe Draftification is only for articles that shouldn't be deleted, but it's also only for articles that can't be in mainspace. That is the exact reason why draftspace exists in the first place. Imagine you see a article with the following content: Nicholas Carlini is an amazing researcher at Google working on adversarial machine learning. created in the last week or so and sourced to a person's personal web-page. On doing a quick google search, you see that the person exists and is a researcher at said company, however, due to your unfamiliarity with adversarial machine learning topic-area you are not able to immediately identify the person's impact on the field. Do you 1) WP:BITEly nominate the article for deletion 2) leave the content up for somebody to deal with it (and hope that the other somebody will not choose option 1) or 3) draftify the article with a note that more sources are required to prove notability? Sohom (talk) 11:25, 27 September 2024 (UTC)[reply]
@Sohom Datta None of them. What you do is add a template to the article noting the lack of sources, leave a friendly message on the creator's talk page explaining the issues in plain English, and leave a note about it at Wikipedia talk:WikiProject Computer science. Depending on what your research found you could add more information, add some sources that might or might not demonstrate notability, remove the peacock terms, etc. Yes, this is more effort than blinding draftifying or AfDing but it is far more important that things get done well than things get done quickly. Thryduulf (talk) 12:37, 27 September 2024 (UTC)[reply]
@Sohom Datta, thanks for creating Nicholas Carlini, whose first version does not contain the hypothetical sentence you gave in your comment above. In your example above, why can't that stay in the mainspace? I frankly don't love it, and I'd immediately pull the word "amazing" out, but what's the policy basis for saying "that article truly can't be in mainspace"? WhatamIdoing (talk) 21:10, 27 September 2024 (UTC)[reply]

@Fangz I'm not arguing for the elimination of draftspace, it has it's uses as an optional space where articles can be developed over time so they don't have to meet all the relevant content policies from the very first edit. I'm also not arguing for the elimination of all draftifcation, just the majority of unilateral draftification because, as Joe has put better than I can, it is not a net benefit to the project as currently practised. Thryduulf (talk) 12:46, 27 September 2024 (UTC)[reply]

There's a middle ground between meets-GNG-mark-as-reviewed and fails-GNG-send-to-AfD: recently created articles where the sources in the article do not validate GNG, but where the new page reviewer hasn't done a BEFORE search. I think it's perfectly fair (and permissioned within the current draftification process) to say "this recently created article doesn't demonstrate GNG yet, but I'll kick it back to the creator in draft form to put in some more sources." Dclemens1971 (talk) 04:43, 29 September 2024 (UTC)[reply]
Punting it to draftspace without doing a BEFORE is definitely not something we should be tolerating. Thryduulf (talk) 10:21, 29 September 2024 (UTC)[reply]
This would mean we're either leaving these articles unpatrolled (which is obviously undesirable), or giving new page patrollers the job of finding sources on every article where the original author hasn't, which would be ideal in, well, ideal conditions, but puts the burden of actually sourcing the encyclopedia on a very small group of editors. In my opinion, there should be a way to ask the original author to add sources to show it meets GNG, beyond just putting a "notability" tag and being done with it. Chaotic Enby (talk · contribs) 19:53, 1 October 2024 (UTC)[reply]
I agree with Chaotic Enby. Drafification is a good solution because it strongly encourages the author to improve the article, and, most importantly, gets it out of mainspace so that it isn't a problem for innocent readers – without forcing NPPers to clean up other peoples' messes. Cremastra (talk) 20:06, 1 October 2024 (UTC)[reply]
Drafticiation [...] strongly encourages the author to improve the article. That's the theory but the evidence is that in practice it very rarely does this. There is also little to no evidence that most pages moved to draftspace are actually a problem for innocent readers rather than being a problem for those who want immediate perfection. Thryduulf (talk) 20:47, 1 October 2024 (UTC)[reply]

About wanting to ask the original author to add sources to show it meets GNG, beyond just putting a "notability" tag and being done with it, I wonder if it's actually possible to do this in a non-coercive way. The options right now are:
Just ask (what the {{notability}} tag does).

Ask under threat of deletion (WP:BLPPROD and WP:PROD).

Move article to Draft: space (essentially holding the article hostage, to be deleted if you give up or can't figure out how to do it).

Send to AFD today.

AFAICT a method for "force another WP:VOLUNTEER to improve the article to my standards" option has proven pretty elusive. But if you want to reach that point, I suggest that you take a baby step towards it in the form of getting a policy (any policy, really) to actually, directly, unambiguously say that every article must cite at least one source. Until the community agrees that this actually is a requirement, then we have no hope of getting them to increase the requirement all the way up to "show it meets GNG". WhatamIdoing (talk) 00:20, 2 October 2024 (UTC)[reply]

If a new editor thinks their article is ready for mainspace, they will put it there. They will also happily revert the move. If a new editor is unsure, they will probably ask for help first or use draftspace. Cremastra (talk) 19:35, 26 September 2024 (UTC)[reply]

I think the concern expressed by Joe and others who support the "backdoor" theory is that new users do not know how to revert the move to draftspace. Do you disagree with that assumption? Toadspike [Talk] 19:53, 26 September 2024 (UTC)[reply]

I think most users do not know how to revert the move, yes. I also think we shouldn't hand it to them on a silver platter, because that likely largely annuls the whole point of draftification. What is the solution to this? I couldn't tell you. Cremastra (talk) 20:09, 26 September 2024 (UTC)[reply]

Is "the whole point of draftification" to make my view of the subject's value more powerful than the newbies' view? Security through obscurity kind of works for that, but not reliably. WhatamIdoing (talk) 20:22, 26 September 2024 (UTC)[reply]

They don't know how, maybe, but more importantly that they don't know that they're allowed to. We have to remember how very unusual our collaborative process is. If an inexperienced editor contributes an article to Wikipedia and then it is swiftly unpublished with a message that there's something wrong with it, they won't think, hmm, I'm not sure if I agree with that, I'm going to revert and/or discuss this with my peer-editors to find a consensus. They'll think that with someone the authority to decide what happens to articles has rejected my contribution, and I'm a mere newbie. At that point they will either give up (the majority) or they'll persevere and get into cycle of trying to satisfy first the NPP reviewer and then a succession of AfC reviewers until they finally give up or manage to write a GA, which seems to be roughly the standard AfC is applying these days Even very experience editors fall into this trap because even though the templated messages try to communicate the full range of options the user has (now at least, after I and others have spent several years fighting for it), it's really hard to communicate that we're all equal and all have a say here within a draft–review structure that implicitly elevates the opinions of reviewers over others. – Joe (talk) 07:31, 27 September 2024 (UTC)[reply]

I've pulled the most recent 10 articles moved to mainspace with the AFCH script. They are:

607th Air Control Squadron – 80 words per Wikipedia:Prosesize, 2 refs: Stub per mw:ORES article quality rating.
Will Putnam – 296 words, 15 refs: Start.
Coat of arms of Saskatoon – 380 words, 4 refs: Start.
Urban Realism – 304 words, 4 refs: Start.
Devara: Part 1 (soundtrack) – 547 words, 29 refs: C class.
Honor Thy Father and Mother: The True Story of the Menendez Murders – 562 words, 8 refs: C class.
XP-21279 – 200 words, 11 refs: Start.
Crew Dragon Launch Abort System – 641 words, 23 refs: B class.
Vince Zampella – 536 words, 18 refs: C class.
Jeffrey Kahn – 179 words, 14 refs: Start class.

That's an average of 372.5 words and 12.6 refs. The median article has 338 words and 4 refs. Compared to existing articles, 53% of our existing articles have fewer than 372.5 words, and 83% have fewer fewer than 12.6 refs. One in six articles has fewer words than the shortest in this list. One of three articles is shorter than the second-shortest in this list.

I think it is clear from these numbers that AFC is expecting more refs than existing community practice, and that they are trying to accept only articles that are already as long as ones that editors have been working on in the mainspace for years.

BTW, during the same span of time, more than 100 pages were deleted from the Draft: namespace. You shouldn't assume this means that more than 90% of drafts get deleted, because deletions are bursty and this is a relatively small sample size, but that's about what I expected. WhatamIdoing (talk) 20:56, 27 September 2024 (UTC)[reply]

A Conclusion: I am sadly not surprised at the current state of this discussion. Some of the heated off-topic arguments verge on NOTHERE behavior. I am very disappointed to see this from experienced editors. To those of you who simply commented on the proposal: I appreciate you a lot.

Since the default NPP draft template was changed to Template:Draft article a day before this discussion began, I think my proposal is moot. I don't see how we could improve that template much, but I may raise some minor wording changes on the Template Talk. If someone wants to close this discussion, that's fine; if others wish to continue discussing other things here, I wish you the all best. Toadspike [Talk] 21:16, 27 September 2024 (UTC)[reply]

Worth also talking about the usertalk notification MTD leaves, which only provides one option: submit for review. Agree in principle we shouldn't trick people into thinking draftification/AfC is mandatory for a typical article creator. — Rhododendrites ^talk \\ 13:29, 28 September 2024 (UTC)[reply]

Strong Oppose All it will do is destroy the draft system as it stands and eventualy destroy Wikipedia. This almost happened between 2008 and 2012, before the draft process was available, when Wikipedia was flooded with paid/coi editors and there was no effective system to deal with them. Do folk not understand what draftification is. Every publisher has draft process. It is NOT a route to deletion. That is what the detractors of the system say, many of them who are paid to oppose it and destroy it. It is the one of the core safeguards we have against the complete destruction of Wikipedia. scope_creep^Talk 11:46, 29 September 2024 (UTC)[reply]
That comment is almost entirely evidence free assumptions of bad faith. Please try engaging with the discussion rather than just knee-jerking oppose to changing the status quo because it would change the status quo. Thryduulf (talk) 12:56, 29 September 2024 (UTC)[reply]
Its not evidence free and I resent the fact that you have said my comment bad faith. Why would I make the comment if I didn't know what I was talking about. I've worked in NPP/AFC since it was created and was involved in some of the early discussions. I now how exactly how UPE/paid editors behave. It would lead to an exodus of editors after the place gets flooded with adverts. It would be free-for-all. The reality is that the editor who posted hasn't thought it through and hasn't looked in the archives to see what the situation was like then. scope_creep^Talk 16:05, 29 September 2024 (UTC)[reply]
"Trust me, I was there" is not evidence. Your comment assumes bad faith from those disagreeing with you, and of everybody submitting new articles. Not every editor is paid (and disclosed paid editing is explicitly allowed), not every paid edit (disclosed or otherwise) is bad, not every paid editor (disclosed or otherwise) is attempting to harm the encyclopaedia, not every paid edit (even undisclosed ones) does harm the encyclopaedia. Thryduulf (talk) 16:19, 29 September 2024 (UTC)[reply]
That is true to certain extent, but the majority of editors who create modern biographical, organisational and product articles which make up the majority are undeclared paid editors. They do not have our best interests at heart and never have done. scope_creep^Talk 16:53, 29 September 2024 (UTC)[reply]
Even if that is true (and you haven't provided any evidence, of either your assertion or the implications of it that these articles harm Wikipedia and/or that draftification as currently implemented and practice prevents that harm), that doesn't mean that draftification as implemented currently can't be improved and that any changes to the status quo will mean the death of Wikipedia. Thryduulf (talk) 17:02, 29 September 2024 (UTC)[reply]

@Scope creep, what percentage of articles in the draft space do you think get deleted? WhatamIdoing (talk) 18:51, 29 September 2024 (UTC)[reply]
If drafts get deleted, that's because their creators have abandoned them. That's what G13 is. Perhaps more effort should be spent encouraging article writers to improve their articles after they got moved to draft (where they can be improved without interference), but draftification is not deliberate, malicious backdoor deletion, and I resent it being characterized as such. Cremastra (talk) 19:47, 29 September 2024 (UTC)[reply]
Is this a Double-barreled question? The comment you're replying to said only "route to deletion", and you've turned it into four separate parts:
deliberate

malicious

backdoor

deletion.
I wouldn't personally characterize any of them as malicious, but I think a fraction of them are deliberate. IMO claiming that nobody ever sent a borderline subject to AFC instead of AFD (which has lower standards in practice) would be rather extraordinary. I frankly don't think we're all so stupid that we can't figure out which route is most likely to end up with the result we prefer.

If we characterize AFD as the "front door" for deletion, then it seems fair to describe letting articles expire in the Draft: space as the "back door".

But the original comment is merely that it's not a route to deletion. But if 90–95% all of the articles put on that path actually do end up getting deleted, then is it not basically fair to say that it is one of our routes to deletion? WhatamIdoing (talk) 20:22, 29 September 2024 (UTC)[reply]
Oppose. The current verbiage of the tag makes it clear to anyone with a lick of common sense, that the article has potential, but in its current form it is not ready for mainspace. Some of the comments here from folks clearly indicate a lack of understanding of what the draftification process is for. If an article, in its current form, passes GNG, then there are only certain circumstances where it should be draftified (e.g. paid editing), but if an article probably would pass GNG, but does not in its current form (e.g. there are not enough in-depth sources from independent, reliable sources to meet the standard), than that is a poster child for draftification. When I was more active in reviewing articles, I created several custom responses, which took the standard message and massaged it a bit depending on the reason for draftification (e.g. UPE, lack of GNG) or a specific topic (e.g. NFOOTY, Populated places). In some instances those messages contained an offer to ping me directly when they felt the article was ready for mainspace. I am all for article creation, but I also care about the quality and reputation of Wikipedia, which is often seen as the punchline for jokes regarding garbage information on the internet. And I would completely disagree with those who say that draftification is not a net benefit. In fact, I think it is one of the most useful tools to helping improve the quality on WP. Is it always used correctly? No. But that's an education problem with individual users, not an overriding issue with the process itself.Onel5969 ^{TT me} 14:34, 29 September 2024 (UTC)[reply]
I agree with Onel5969. (But also remember to not leave !votes as this is the idea lab, not a formal proposal). Cremastra (talk) 14:36, 29 September 2024 (UTC)[reply]
Apologies, Cremastra. Onel5969 ^{TT me} 19:38, 29 September 2024 (UTC)[reply]
That might be fine in theory, but it doesn't match the what is happening in practice. Especially given that articles are being moved to draftspace for not being of sufficient quality that are C or even B class. If an article is neutrally written and meets the GNG then there is no justification for moving it to draftspace just because someone might (or might not) have been paid to edit it. Thryduulf (talk) 15:21, 29 September 2024 (UTC)[reply]
@Thryduulf: Do you have a specific example in mind when you mention C or B class articles? scope_creep^Talk 16:13, 29 September 2024 (UTC)[reply]
See @WhatamIdoing's comment in this discussion. Thryduulf (talk) 16:15, 29 September 2024 (UTC)[reply]
This list is the state of articles when they come out of the Draft: space. For articles going in to the Draft: space, here's a current list:
Draft:Sargodha Satellite Fields – 376 words, 5 refs (reason: "more sources needed")

Draft:Näsir Zaman – 20 words, 10 refs (reason: "more sources needed")

Draft:Ahsan Khalil – 48 words, 15 refs (reason: "more sources needed")

Draft:Martin-J. Sepulveda – 232 words, 9 refs (reason: "likely covert advertising")

Draft:Gregory Bortz – 270 words, 22 refs (reason: "likely covert advertising")

Draft:Yury Yuriyovich Shikula – 40 words, 3 refs (really ~150 words; reason: "more sources needed")

Draft:Dwight Carlton Harris – 151 words, 3 refs (moved by the author for having no sources; the same editor added sources half an hour later)

Draft:Rhodesia Railways 19th class – 4 words (it's a list), 0 <ref>s, but two sources named (reason: "no sources, custom reason")

Draft:De Zandbak – 107 words, 5 refs (reason: "more sources needed")

Draft:Kian Breckin (footballer) – 316 words, 15 refs (moved by the author with no reason given, but it was deleted at AFD last year)

I have skipped redirects, some round-robin page swaps, and a couple of editors moving AFC submissions from User: space to the Draft: space, and tried to include only articles being moved from the mainspace to the Draft: space. I can't get the ORES ratings for these articles, but at a glance, I think that Start and C-class is not an unreasonable description. WhatamIdoing (talk) 19:31, 29 September 2024 (UTC)[reply]
First, thanks for providing the list. The issue is, in reviewing those drafts, most are solid drafts, and not " Especially given that articles are being moved to draftspace for not being of sufficient quality that are C or even B class." Although I think a more careful explanation could have been made. For example, the first one would have been better with a "more in-depth references from independent, reliable sources" needed, rather than simply saying "more sources needed", as there isn't a single, in-depth reference from an independent, reliable source in the draft. The second and third examples are the exact same issue. The 4th and 5th examples are properly labeled as covert advertising (both editors have been blocked for it - in addition, the 4th one didn't have a single in-depth reference from an independent source, either). The 6th example, while having 3 sources, none are in-depth, and while it might be a spelling difference on the translations of the 2nd and 3rd refs, it does not appear that the article's subject is mentioned in any of them. The 7th article is not a true example of draftification, as it was moved by the author. The 8th and 9th article have zero independent reliable sources (for the 9th, the newspaper referenced does not have a page number, and the link does not appear to bring up anything in depth about the hack lab). Not sure about the 10th, for the history is a bit wacky, but again, does not look like an example of draftification.

I think this illustrates some of the misunderstanding that folks who don't like draftification make. You look at the list provided, and you go, wow, lots of references, most not stubs or micro-stubs, why in the hell were they draftified? Hell, I did that myself, wondering if all 10 were done by a single editor, who perhaps did not have a firm grasp of draftification. But then you dive into the merits of the sourcing, or the upe issues, and it appears all 8 of the draftifications appear justified.Onel5969 ^{TT me} 20:32, 29 September 2024 (UTC)[reply]

@Onel5969, I wonder if you could explain "the newspaper" in the 9th article a little better. You say that the article has "zero independent reliable sources", but traditional print newspapers are independent reliable sources. Then you say it doesn't have a page number, but the link takes you directly to a scanned copy of the correct page; the cited article [title given in the citation] is in the last two columns. None of that makes the newspaper less independent. Is your concern that the article appears to predate the use of the name in the article title ("De Zanbak" means "The Sandbox")? WhatamIdoing (talk) 20:51, 29 September 2024 (UTC)[reply]

Could be the translation, but there does not appear to be anything connecting the group mentioned in that article, with De Zanbak. But even if there is, agf, that still is the only in-depth independent source. Onel5969 ^{TT me} 01:15, 30 September 2024 (UTC)[reply]

I'm glad we agree that a newspaper is an independent source. WhatamIdoing (talk) 01:20, 30 September 2024 (UTC)[reply]

If a new editor includes 5 sources in their submission and it gets moved to [somewhere I didn't put it] because "more sources needed" or "no sources" how many of them are going to take the time to learn that the experienced editor actually meant none of these sources contain what I think is significant, in-depth coverage in independent reliable sources and then have the confidence to say "actually, this experienced person with the power to remove my article from Wikipedia is wrong and I'm right, I'll learn how to challenge them and how and where to express my view in a way that the powerful people will listen to me" rather than just give up at some point along that path? And before anyone says it, no, just because a few bad faith editors might be among the dissuaded does not justify the loss of good faith editors. Thryduulf (talk) 21:29, 29 September 2024 (UTC)[reply]

I guess that's the difference between editors who care about quality on WP, and those who care about quantity. But that's why I said that the rationale given could have been better. Onel5969 ^{TT me} 01:17, 30 September 2024 (UTC)[reply]

Is it really a quality vs quantity question?

Or is this the difference between editors who would rather see a page run through Wikipedia:Articles for deletion or Wikipedia:Proposed article mergers instead of being unilaterally hidden until it gets deleted without the level of community oversight that we expect from AFD? For example, I'm not convinced that "De Zanbak" is a viable subject for an article, but I think there are several ways that we could address that concern, and I don't see the Draft: space helping. In fact, the only thing that moving that page to the Draft: space does that's different from moving that page to the User: space is: It's far more likely to get deleted during the next year if it's in Draft: space than if it's in User: space. WhatamIdoing (talk) 01:26, 30 September 2024 (UTC)[reply]

Well, since draftification isn't a "backdoor to deletion", nor is it "hiding an article", it's definitely a question of quality vs. quantity. Draftification, in short, is a quality control measure. These are articles that might be notable enough for mainspace, but simply aren't in good enough shape to be there. But, like other vehicles in WP, good faith editors might disagree on an article's notability, so for example in the De Zandbak articlem, Jay8g (who tagged it for notability), and Jonathan Deamer (who draftified it) might deem it potentially notable, while you, WhatamIdoing, might have simply sent it to AfD, because you do not feel it notable. But that doesn't mean the system isn't working. Perhaps we can tweak the current verbiage in the template to include where resources about where an editor can reach out for help might be added (e.g. AFC or Teahouse)?Onel5969 ^{TT me} 09:20, 30 September 2024 (UTC)[reply]

Well, since draftification isn't a "backdoor to deletion", nor is it "hiding an article", you say that as if there is no possible way good faith editors could disagree, but that simply isn't true. Whether either of those things is true is a matter of opinion (and, in my opinion, one that is consistent with the evidence presented). Thryduulf (talk) 10:07, 30 September 2024 (UTC)[reply]

Hi. No, editors can certainly have different interpretations and disagree on issues. However, in this instance, it is not a matter of disagreement. In order to hold those views indicates a lack of understanding of what the draftification process is. That's not what draftification is, it is, as I've said, simply a quality control measure. It would be like saying, it's a matter of opinion whether or not this person wrote an article about themselves, that can be interpreted as not being COI editing. Of if a an article simply cut and paste the info from Encyclopedia Brittanica, you cannot say it's your opinion that that isn't a copyvio. I mean, I have the utmost respect for you, Thryduulf, and you do a great job on WP. There are things on WP which are subjective (e.g. exactly what constitutes SIGCOV), while others are objective, (e.g. UPE/COI editing, copyvio). What draftification is falls into the latter category. All that being said, we can disagree on whether or not an individual article should or should not have been draftified. You say the evidence presented shows that it was not warranted that those articles be sent to draft. Going through the sources, however, it looks like draftification was justified. That is a difference of opinion. Onel5969 ^{TT me} 14:20, 30 September 2024 (UTC)[reply]

It's your opinion that moving an article to the Draft: space is simply a quality control measure.

It's my opinion that moving an article to the Draft: space is also simply a quality control measure that, compared to the available alternatives of leaving it in the mainspace, sending it to AFD, or moving it to User: space, substantially decreases the likelihood of the quality being improved and substantially increases the likelihood of the article being deleted.

Oh, right: Those last two points ("substantially decreases the likelihood of the quality being improved" and "substantially increases the likelihood of the article being deleted") aren't "opinions". They're objective facts. WhatamIdoing (talk) 22:17, 30 September 2024 (UTC)[reply]

Rhodesia Railways 19th class is not a list; it's a train that was in operation for multiple ranges of time. Even if it were a list, the empty headings and only content being a table is nowhere near start-class, maybe even substub. Aaron Liu (talk) 20:47, 29 September 2024 (UTC)[reply]

The existing content in the article is an infobox and a table. Tables are the format preferred by Wikipedia:Featured lists. Empty sections aren't banned, and ratings are based on what is already there. I'd rate it as |class=List today. WhatamIdoing (talk) 20:53, 29 September 2024 (UTC)[reply]

only content being a table have you actually read the page? That infobox is full of content, there are two apparently reliable sources and the table itself has about 20 rows of content. Thryduulf (talk) 21:33, 29 September 2024 (UTC)[reply]

Sorry, yes the infobox as well. I still wouldn't call it a start, though. Aaron Liu (talk) 22:03, 29 September 2024 (UTC)[reply]

Can we consider EC level pending changes?

This is just an idea, and I want to workshop this a bit more, but I think it would be helpful to have pending changes at the extended confirmed level. This could be called "PC2" again (not to be confused with the original PC2) or "PCECP". The idea would be to help enforce WP:ARBECR and similar restrictions where non-extended confirmed users are prohibited from certain topic areas. Under this level, edits by non-extended-confirmed editors would be held for review, while extended confirmed users can approve these edits and thus take responsibility under WP:PROXYING.

I think it would be helpful for pages where (1) parts of the article intersect with a contentious topic, or (2) the article in its entirety intersects with a contentious topic, but not edited frequently. Awesome Aasim 16:54, 27 September 2024 (UTC)[reply]

This seems like it could be useful. It would have to be restricted to infrequently edited pages (likely excluding all current events articles) so as not to overwhelm Pending Changes every time Reuters publishes a new story or an edit war erupts. The big question is: what problem are you trying to solve? Toadspike [Talk] 20:39, 27 September 2024 (UTC)[reply]

There are some contentious topics designated either by ArbCom or the community where only extended confirmed users are allowed to participate. However, admins refuse to protect pages where there isn't enough disruption to justify protection. Although, it should be considered that the XCON restriction applies regardless of whether a page is protected or not.

What PCECP would do is essentially remove fears that there "isn't enough disruption to justify protection" while buffering all non-extended-confirmed contributions so they have to be approved, in line with "non-extended-confirmed can only make edit requests". Templates that are specifically for this case like {{edit protected}} break when the page is not protected. Awesome Aasim 22:00, 27 September 2024 (UTC)[reply]

The problem with that is that the 500/30 rule is specifically designed to keep newer editors out due to extreme amounts of disruption as a rule. There's a good reason why both of the world's main hot wars (the Arab-Israeli conflict and the Russo-Ukrainian war) are under 500/30. And, as has been brought up repeatedly and bears repeating again, high volumes of edits on a given article contraindicate CRASHlock.

But the biggest stumbling block here is that no consensus exists yet for an extended-confirmed CRASHlock. The last discussion about expanding CRASHlock to higher protection levels predates XCP entirely. There would need to be a formal RfC for this, not VP spitballing. —Jéské Couriano v^_^v ^{threads critiques} 15:37, 28 September 2024 (UTC)[reply]

XCON protection makes sense for high traffic articles, but low traffic articles? If the edit is minor such as fixing spelling mistakes or grammatical errors, there should be no problem. Fixing spelling and grammar is generally outside of contentious topic areas anyway. From WP:ARBECR: On any page where the restriction is not enforced through extended confirmed protection, this restriction may be enforced by other methods, including ... the use of pending changes.

I probably would set up abuse filters as well to see if a page is in a category that primarily deals with a contentious topic, and then warn and tag the edit in question. Awesome Aasim 16:22, 28 September 2024 (UTC)[reply]

Most low-traffic CT articles don't have any protection since they never saw amounts of vandalism necessitating protection. Protection requests that solely rely on arb enforcement and little to no evidence of vandalism get declined. Aaron Liu (talk) 23:26, 28 September 2024 (UTC)[reply]

Yeah I see that, but the problem is that a non-XCON edit will get approved on pages that not many people are watching. Pending changes still allows non-XCON users to make these edits, but their edits will need to be approved and they can be reverted if in violation of WP:ARBECR. This is also in line with how pending changes is used on low-traffic articles to monitor (not prevent) disruption. Awesome Aasim 18:26, 29 September 2024 (UTC)[reply]

@Aaron Liu Most low-traffic CT articles don't have any protection since they never saw amounts of vandalism necessitating protection. Protection requests that solely rely on arb enforcement and little to no evidence of vandalism get declined. Untrue, articles in ECR topics can and are pre-emptively locked. What actually happens is that articles with minimal disruption are usually not brought to WP:RFPP or noticed by a wayward admin. Mach61 19:53, 29 September 2024 (UTC)[reply]

Untrue, articles in ECR topics can and are pre-emptively locked.

Could you add an example? There is a long list of declined RFPP requests for arbitration enforcement. Aaron Liu (talk) 20:42, 29 September 2024 (UTC)[reply]

See this exchange between an admin who refused to protect based on ECR due to a lack of disruption and a (former) admin who explained to them otherwise. Mach61 19:46, 1 October 2024 (UTC)[reply]

Thanks, I get the "can" now. Aaron Liu (talk) 20:59, 1 October 2024 (UTC)[reply]

Seems reasonable. I've always wondered why pending changes isn't deployed more often. It seems a useful tool, and there are lots of pending changes reviewers so very little backlog Cremastra (talk) 14:18, 28 September 2024 (UTC)[reply]

Because there are enough people who dislike or distrust pending changes that it's hard to get a consensus to use it. See, for example, Wikipedia:Village pump (proposals)/Archive 183#RFC: Pending-changes protection of Today's featured article. Anomie ⚔ 14:41, 28 September 2024 (UTC)[reply]

Well, gee, I fucking wonder why? —Jéské Couriano v^_^v ^{threads critiques} 15:39, 28 September 2024 (UTC)[reply]

Would you care to elaborate on your point? I'm not seeing it. Anomie ⚔ 17:04, 28 September 2024 (UTC)[reply]

@Anomie: Read the "Proposal" section on the linked page. The fact that RfC even exists should give you a clue as to why CRASHlock is so mistrusted by a significant minority of editors. —Jéské Couriano v^_^v ^{threads critiques} 18:01, 9 October 2024 (UTC)[reply]

Still not seeing it. People supposedly mistrust it because there was a trial 14 years ago and enwiki admins didn't immediately stop using it after the trial period pending a consensus on the future of the feature? Anomie ⚔ 18:43, 9 October 2024 (UTC)[reply]

You familiar with the idiom of the Camel's nose? —Jéské Couriano v^_^v ^{threads critiques} 18:47, 9 October 2024 (UTC)[reply]

The TL;DR I'm taking away from this discussion is that you're still butthurt over consensus not going your way 12 or 13 years ago, and assuming that anyone opposed to PC shares that reason and no other. I think it's unlikely continuing this conversation is going to go anywhere useful. Anomie ⚔ 18:59, 9 October 2024 (UTC)[reply]

That isn't how consensus works, either. Consensus can be determined by an RfC, yes. But it can also develop just by the way that things are done already, regardless of whether it has formally discussed.

I think about the example given by Technology Connections about "the danger of but sometimes". The LED traffic light is superior in energy savings and much more, but sometimes snow and ice builds up on them, so they are bad. Likewise, XCON pending changes will help with enforcement of WP:ARBECR but sometimes admins might apply this to pages out of policy, so it shouldn't be used again. The correct response would be to place in policy guardrails so that admins don't do that. Awesome Aasim 19:00, 9 October 2024 (UTC)[reply]

How is an RfC from over 13 years ago still reflective of consensus today? I am pretty certain that while some opinions might not have changed, others definitely will have. No one is saying there should be full pending changes. Awesome Aasim 18:16, 9 October 2024 (UTC)[reply]

@Awesome Aasim: The RfC was linked specifically to point out one of the reasons for the mistrust in the PC system. The most recent RfC on CRASHlock, as I said, predates XCP as a concept. —Jéské Couriano v^_^v ^{threads critiques} 18:20, 9 October 2024 (UTC)[reply]

Also, please explain what you mean by "crashlock". I cannot find any discussion or glossary entry on "crashlock". Awesome Aasim 18:21, 9 October 2024 (UTC)[reply]

@Awesome Aasim: It should be VERY obvious from context. —Jéské Couriano v^_^v ^{threads critiques} 18:26, 9 October 2024 (UTC)[reply]

I guess you might be the only one using this terminology; as it is not in WP:GLOSSARY or anywhere else.

Nonetheless, this is the Idea Lab; it is the place to develop ideas, not to show stark opposition to ideas. That is what the other discussion boards are for; consensus polling. It should be noted that WP:ECP was created originally for the purpose of enforcing arbitration decisions and community sanctions. It was never intended for anything else; it just got used for other stuff de facto. Awesome Aasim 18:40, 9 October 2024 (UTC)[reply]

(edit conflict) All these things you think are obvious really are not. You should try explaining yourself better instead of emphatically waving your hands at something random. Anomie ⚔ 18:43, 9 October 2024 (UTC)[reply]

Obvious perhaps, but it still doesn't make much sense. I'm not sure how using your own special terms of unclear implications to disparage things you dislike is helping communication or community understanding here. Cremastra (talk) 19:37, 9 October 2024 (UTC)[reply]

I don't understand. People mistrust PC because of a bureaucratic misimplementation of an experiment over 10 years ago? (In a noncentralized bureaucracy where dumb shit happens all the time?) The RfC is explicit that it makes no normative judgement on PC, and it seems the !voters are not doing so either. SamuelRiv (talk) 18:37, 9 October 2024 (UTC)[reply]

It's one reason, and probably the biggest for some (who viewed the trial's mishandling as trying to force CRASHlock/FlaggedRevisions down our throats). Another reason is that, from 2010 to 2014, CRASHlock RfCs were called at least once a year, with most of them being written by pro-CRASHlock editors. —Jéské Couriano v^_^v ^{threads critiques} 18:42, 9 October 2024 (UTC)[reply]

Ok for those not into WP politics, there's an overview opinion piece from the August 2011 WSP that seems to capture the attitude and aftermath. It appears the closure results of the RfCs left admins in an indeterminate state as to whether PC can ever be applied or removed. SamuelRiv (talk) 18:47, 9 October 2024 (UTC)[reply]

as to whether PC can ever be applied or removed True in 2011 when that was written, but later RFCs resolved that. Anomie ⚔ 19:02, 9 October 2024 (UTC)[reply]

Could you link to said RfCs? All else that's linked previously regards the main page. SamuelRiv (talk) 19:56, 9 October 2024 (UTC)[reply]

Wikipedia:Pending changes/Request for Comment 2012 established basic consensus to use PC, with Wikipedia:PC2012/RfC 2 and Wikipedia:PC2012/RfC 3 clearing up some details. PC level 2, on the other hand, never got consensus for use and eventually in 2017 there was consensus to remove it from the configuration. Template:Pending changes discussions has a lot of links. Anomie ⚔ 22:14, 9 October 2024 (UTC)[reply]

It's worth noting that the 2017 RfC is the last one about any aspect of CRASHlock, to my knowledge. As I said above, there would need to be a new RfC in order to get consensus for extended-confirmed CRASHlock, as PC2 was originally full-protection level and no ECP!CRASHlock question was asked in the 2016 RfCs, none of which were particularly comprehensive. (The last comprehensive RfC was the 2014 clusterfuck.) —Jéské Couriano v^_^v ^{threads critiques} 06:47, 10 October 2024 (UTC)[reply]

I think the main reasons editors don't want to expand the use of pending changes are practical: no technical support for fixes (or additional feature development) is on the horizon, in spite of documented bugs; and uncertainty in the community's ability to manage expanded use. There are certainly vocal editors who are wary due to past history, but this has already been a factor in other decisions, and they have accordingly been influenced to be more definitive about how any trials will proceed. isaacl (talk) 18:55, 9 October 2024 (UTC)[reply]

Ok so there's a lot of history here as you are already seeing above, and no one's even gotten to discussing Phillipe's little misadventure yet. Despite all that I actually think the general idea here is sound. And since we are discussing history its worth pointing out that as a practical matter this is actually closer to what the EC restriction was intended to do in its earliest incarnation where it functioned as a softer version of 1RR originally enforced as a bespoke AE remedy on one specific article reverts of non-qualifying accounts did not count towards 1RR.

Times have changed, ECR now tends to be enforced in mainspace with ECP and is applied far more broadly than anyone from then would have envisioned, for better and for worse.

The best use case here is for quiet pages where the history of non-EC editing is largely one of minor non-contentious fixes and improvements, but have caught attention due to sporadic contentious edits, where it can offer a middle way between leaving enforcement to post-edit reverts and preventing all non-EC editing.

As a practical matter the limitations of the extension mean that it really only works-well on low-traffic pages and realistically improvements to the extension aren't coming anytime soon. So use case (2) makes sense, but (1) is a harder sell. Might not be enough of a use case to justify the hassle. Personally I'd have to do some research and think about this a little but the basic idea is sound.

Apologies for the hastily typed response, I'm a little pressed for time; hopefully there was something useful in there. 184.152.68.190 (talk) 16:06, 22 October 2024 (UTC)[reply]

Maybe what is needed is this...

A multi-part RfC asking how ECR should be enforced for existing pages, including based on activity. High traffic pages will need extended protection retroactively as those tend to get the most disruption from ECR violations. Low-traffic pages, not so much, but we can use abuse filters and workshop ECP pending changes for this. Spelling and grammar fixes as far as I am aware are excluded from WP:ARBECR. Awesome Aasim 19:52, 1 October 2024 (UTC)[reply]

I view the ECR in the PIA area to be absolute (no editing full stop by those who do not meet 500/30), so CRASHlock would be off the table there in any event. I'm not sure if this also applies to WP:GS/RUSUKR (which falls into the EE area). —Jéské Couriano v^_^v ^{threads critiques} 18:57, 9 October 2024 (UTC)[reply]

Can we build the proposal here?

Here is some starter text maybe to get the ball rolling:

What is the best way to enforce WP:ARBECR on articles?
- Option 1: Preemptive XCON protection
- Option 2: Preemptive XCON pending changes
- Option 3: Edit filters
- anything else?

This probably is incomplete, anyone else have ideas for this proposal? Awesome Aasim 19:41, 16 October 2024 (UTC)[reply]

I'd say remove "preemptive", as it is sometimes placed only in response to disruptive activity from non-ECs. Aaron Liu (talk) 11:31, 17 October 2024 (UTC)[reply]

So should reactive also be an option? Awesome Aasim 17:32, 17 October 2024 (UTC)[reply]

I think so. That's what I support. Cremastra — talk — c 19:29, 17 October 2024 (UTC)[reply]

So we should have it like this?:

What is the best way to enforce WP:ARBECR on articles? Please rate whether these options should be preemptive, reactive, or not used.
- Option 1: XCON protection
- Option 2: XCON pending changes
- Option 3: Edit filters/Revert filters
- anything else?

Awesome Aasim 19:39, 17 October 2024 (UTC)[reply]

sure. Cremastra — talk — c 19:42, 17 October 2024 (UTC)[reply]

#### in [topic]

Should articles about years in topics be linked in articles? For example, The Little Girl Lost's first link is to 1794 in poetry. The link feels like a Wikipedia:OLINK violation, but isn't specifically stated. Links to just years are already gone, but why aren't the ones about topics actively being removed? Roasted (talk) 22:56, 28 September 2024 (UTC)[reply]

Everything started in some year, and linking that year to an article about a bunch of irrelevant info is not helpful. But in an article about a poem written in 1794, it is quite reasonable to link to an article about other very related stuff in that year. That is not a rule but is a defensible view, particularly for poems from 230 years ago where it is a bit of a miracle that we have any record of the poem. Johnuniq (talk) 01:04, 29 September 2024 (UTC)[reply]

I think it's a defensible view, specifically for subjects that are discussed/linked in the article. It's similar to our WP:BIDIRECTIONAL principle for navboxes: if you can get from 1794 in poetry to The Little Girl Lost, then it would be ideal if you could get back.

I think it is more defensible for shorter/narrower subjects than for sprawling pages. 1794 in poetry is fine. 2023 in film might not be. WhatamIdoing (talk) 01:23, 29 September 2024 (UTC)[reply]

List of German films of 2023, from which you can rightly get to 2023 in film, could be a different story though. Thryduulf (talk) 10:19, 29 September 2024 (UTC)[reply]

I'd leave that one up to editors' judgment, and I wouldn't object whatever they decided.

Another thing to consider is the formatting. Compare these sentences:

The Little Girl Lost is a 1794 poem published by William Blake in his collection Songs of Innocence and of Experience.
This is a list of German films that are scheduled to release in 2023.

For the first, the link label is "1794 poem", and if you are surprised that clicking on "1794 poem" takes you to 1794 in poetry, then perhaps you weren't paying attention to what you were clicking on.

In the second, the link label is "2023", and you might expect 2023 instead of 2023 films. I would suggest changing that link so that it includes the words "in 2023" instead of the year alone. WhatamIdoing (talk) 19:37, 29 September 2024 (UTC)[reply]

My 2¢: remove direct links, but put the "YEAR in TOPIC" articles in the "see also" section. This removes any MOS:EGG issues and is if anything more consistent with an analogy to bidirectional navboxes Mach61 03:35, 30 September 2024 (UTC)[reply]

I like this.

(Man, I wish navboxes were in that section. Aaron Liu (talk) 11:43, 30 September 2024 (UTC)[reply]

I think the key issue here (justifying this position) is that while "2023 in poetry" may be related in that it's the same year and not too much poetry was published at that time, that doesn't mean it is relevant or useful in relation to that poem to know what 100 other random poems were published the same year. Mrfoogles (talk) 06:21, 13 October 2024 (UTC)[reply]

URL expansion bots

I agree that short URLs are undesirable. However, wouldn't it be better if a bot auto-expanded those URLs instead of them being blacklisted? For example youtu.be into youtube.com/watch?v= , tinyurl.com/example into example.com (that is its actual target). Elominius (criticize | contributions) 09:19, 30 September 2024 (UTC)[reply]

The reason they're blacklisted is not because they're "undesirable", it's because they can be (and have been) used to get around the spam blacklist and other anti-spam measures. If the link is legitimate, there's no reason the user trying to add it can't expand it. Anomie ⚔ 11:25, 30 September 2024 (UTC)[reply]

@Anomie: there's no reason the user trying to add it can't expand it The reason is that the enduser does not know that they have to do that, and the message does not explain that that is what should be done (or how). And several sites use shorter URLs when you use the Share button, which is a type of URL shortener that only goes to one domain, like a domain alias and therefore cannot be abused for malicious purposes. Polygnotus (talk) 23:00, 7 October 2024 (UTC)[reply]

I can certainly see a justification for treating shorteners linked to a single domain (like youtu.be) differently to generic ones like tinyurl. Thryduulf (talk) 23:22, 7 October 2024 (UTC)[reply]

@Thryduulf: See meta:Talk:Spam_blacklist#youtu.be. Polygnotus (talk) 23:43, 7 October 2024 (UTC)[reply]

For that case, as I had written in VPT, the bot could do blacklist checking and reversion if the expanded link hits the blacklist; or we just integrate the automatic expansion mechanism into MediaWiki. Milky Defer 08:34, 10 October 2024 (UTC)[reply]

This misses the point that people could use a URL shortener to link to spam or malware even if the target is not blocked. A quick check of a diff of someone doing that shows the shortener link and the person checking would need to be fully motivated to examine what happens if they click it. If the original edit adds a link to a marketplace or a dubious site, it is a lot easier to revert. We do not want a bot which blesses external links by expanding them. Johnuniq (talk) 01:32, 11 October 2024 (UTC)[reply]

Possibly the bot could discover who added the link, if the account passes some heuristic tests of trustworthiness, it would be considered reliable-enough for expansion. Lot of work though. How big of a problem are short URLs? -- GreenC 02:50, 11 October 2024 (UTC)[reply]

It depends what problem you are referring to. According to the Meta discussion they are used to post spam links, but they also prevent the addition of good links and may (I don't know of any statistics) discourage the inclusion of sources and/or lead to abandoned edits both of which could negatively impact editor retention (directly or indirectly) - all of which are problems, but different ones.

I think the ideal would be for MediaWiki to perform a pre-save transform to expand short URIs to their full form, then check them against the blacklist, then either save the long form or reject the edit as appropriate (The error message for a rejected edit should display both short and long URIs so editors know which link tripped the blacklist and why). I guess this is something that would need to happen at the software level though? I'm also wondering if there is some means of automatically detecting which URIs are shortened or if that would have to be curated manually? (e.g. would it know that http://sucs.org/uri/as is a short URI (leading to URL shortening) without being told?) Thryduulf (talk) 03:18, 11 October 2024 (UTC)[reply]

. I have not read the meta thread but suspect most cases are good faith and the bad instances are on the edge. It's easy to check, manually go through a couple dozen and see how it looks.

. To expand to long form requires querying a header, external site, or API, might not practical at the MediaWiki interactive layer.

. Shortened URLs could be documented; I made a page that documents archive URLs: Wikipedia:List of web archives on Wikipedia (including some that are shortened URLs). It's easy to start a technical document Wikipedia:List of URL shortening sites on Wikipedia, and hope over time people find it and add knowledge. -- GreenC 04:06, 11 October 2024 (UTC)[reply]

We should never rely on anyone to make a future edit. — xaosflux ^Talk 13:56, 17 October 2024 (UTC)[reply]

Creating Template:Wikidata Infobox

Hi, I propose to create a template called Template:Wikidata Infobox that creates an infobox from information exists on Wikidata. The same idea is implemented in WikiCommons. See http://commons.wikimedia.org/wiki/Category:Quantum_computing and section infobox which uses {{Wikidata Infobox}}. Cheers. Hooman Mallahzadeh (talk) 13:33, 1 October 2024 (UTC)[reply]

Using Wikidata for infoboxes has been discussed many times here and is surprisingly (to me) controversial. Some specific infoboxes do incorporate information from Wikidata (iirc Mike Peel has done some work on this), but I don't think a single generic infobox, whether pulling information from Wikidata or otherwise, will gain consensus. I'll leave a note about this discussion at Wikipedia talk:WikiProject Infoboxes and Wikipedia talk:WikiProject Wikidata. Thryduulf (talk) 13:42, 1 October 2024 (UTC)[reply]

Yeah… a LOT of resistance to importing data from Wikidata into our infoboxes. The two main concerns are Verifiability/reliability (although WD has improved on this front, they still are not in line with our policies) and ease of editing (having to go to WD to edit information appearing on WP can be confusing).

I’ll share a personal experience of confusion… the data focused structure of WD is often incomprehensible to me as a text focused editor here at WP. When I try to fix errors on WD, I have extreme difficulty doing so. simply locating the information I need to edit is hard. The way WD pages are organized and structured is alien gobbledygook to me. Blueboar (talk) 14:18, 1 October 2024 (UTC)[reply]

Wikidata is a good idea in want of a usable interface. It's use would be massively helped if you could edit data here and it was back flushed to Wikidata. -- LCU ActivelyDisinterested «@» °∆t° 14:39, 2 October 2024 (UTC)[reply]

That's how most of the Wikivoyages are set up. It's not automagic (except possibly at German), so you have complete control over which bits you import locally and which bits of your content you push back to Wikidata. The control is important because some content is different. For example, Wikivoyage usually wants to put the lat/long location at the entrance to an location, and Wikidata usually wants the center. There's no need to override each other's locations if these happen to be significantly different (e.g., entrance to Disney World vs center of Disney World). When they're the same, then you can share them back and forth. WhatamIdoing (talk) 04:23, 3 October 2024 (UTC)[reply]

Commons only has one kind of infobox. We have a lot of them that have very different data displayed. Personally, I'd love to incorporate wikidata into nearly all infoboxes, but one generic infobox is impossible to suit our needs. Aaron Liu (talk) 14:14, 1 October 2024 (UTC)[reply]

I really think that this type of infobox (maybe in collapse form) is the best replacement for infobox of articles that we cannot create any infobox for them like Quantum computing. These data includes links to WikiQuote and its library id etc., which makes them accessible and at hand. I propose to use this kind of infobox in other sections like "See also" section, instead of top, replacing many existing templates like {{Commons category}}. Hooman Mallahzadeh (talk) 14:32, 1 October 2024 (UTC)[reply]

Um, what value could be derived from using d:Q17995793 to populate an infobox for the article Quantum computing? Do we really need an infobox for that article to clarify that the subject is an instance of "academic discipline", subclass of "computation", and is the study of "quantum computer" and/or "quantum supremacy"? This is an excellent example of an article that has no need for an infobox. Folly Mox (talk) 02:31, 2 October 2024 (UTC)[reply]

Oh I see you want to use the infobox at the bottom of an article like a navbox? That's less objectionable, and also a different kind of box in our jargon. Folly Mox (talk) 02:44, 2 October 2024 (UTC)[reply]

@Hooman Mallahzadeh, not every article benefits from an infobox. In my opinion, Quantum computing is one of those. Remsense ‥ 论 06:14, 2 October 2024 (UTC)[reply]

@Remsense There are good links to WikiQuote, Wikiversity, Wikidata, WikiCommons, Library of Congress authority ID, that is attached to the main article by simply transcluding this template. This is a big benefit for Wikidata-Infobox of Quantum computing. But collapsing this Wikidata Infobox by default seems reasonable. Hooman Mallahzadeh (talk) 06:26, 2 October 2024 (UTC)[reply]

We can already do that by linking to the ones that are important at the bottom—this is extremely common, and is already done on that article! That brings up a key point of resistance to this, though. We don't want to outsource much to Wikidata because we can't as easily decide what not to show, lest we pollute articles with metadata that may be useful in a database but is functionally useless garbage in an encyclopedia article. Fundamentally, we shouldn't ever expect editors to have to use Wikidata also.Remsense ‥ 论 06:28, 2 October 2024 (UTC)[reply]

This method is a little hard, ⁣inserting cumulative links «by one template» seems more reasonable to me. Hooman Mallahzadeh (talk) 06:31, 2 October 2024 (UTC)[reply]

No, because the decision whether it's worth linking to Wikiquote on a given article should be up to the editors for that article. Remsense ‥ 论 06:32, 2 October 2024 (UTC)[reply]

I disagree. According to Zeigarnik effect, placing a Wikiquote link that is empty right now, motivates users to complete that page and put some quote about that concept. Hooman Mallahzadeh (talk) 06:38, 2 October 2024 (UTC)[reply]

It's not our job to build Wikiquote, but it is our job not to indiscriminately clutter our encyclopedia articles with useless garbage. Your position would be resented by almost any editor who cares about how the articles they write look and what exactly they present to readers. Remsense ‥ 论 06:59, 2 October 2024 (UTC)[reply]

Most readers don't care about those. The small bit that care are satisfied by it being at the bottom. Aaron Liu (talk) 11:34, 2 October 2024 (UTC)[reply]

Hooman Mallahzadeh, your idea of a single general use template to build sister project links from the associated Wikidata item for use in the ==External links== section does actually sound like a good idea, but people in this subthread have been confused by your use of the term infobox (which live at the top of the article). However, this sounds identical to the existing template {{Sister project auto}}. How does your idea differ? Folly Mox (talk) 12:35, 2 October 2024 (UTC)[reply]

If the notion is to show some source information, it may also be similar in concept to the wider-used template {{Authority control}}. SamuelRiv (talk) 15:07, 2 October 2024 (UTC)[reply]

Right, {{authority control}} is already ubiquitous (~2,131,000 transclusions out of 6,900,350 articles including redirects), is even included in the default output of Wikipedia:ArticleWizard, and {{authority control}} already pulls from Wikidata. Folly Mox (talk) 17:54, 2 October 2024 (UTC)[reply]

So all that considered, @Hooman Mallahzadeh, I'd suggest just making/forking a template along those lines (or editing the existing template in its sandbox), as this basic concept would be uncontroversial. The rest of the discussion here is hypothetical clutter until people see precisely what you have in mind that may be radically different from what is already being used in these templates above. SamuelRiv (talk) 18:41, 2 October 2024 (UTC)[reply]

Something like Category:Earth shows how hard it is to get an automatic, good infobox and not a load of weird entries. "Instance of: "inner planet of the Solar System (Mars, Venus)" And Mercury? if you for some reason list the others here, list them all... "Named after: *soil (Earth) *land (1, 地, 地球) *ball (2, 球, 地球) " Er, what? No idea why the Japanese is shown here. "Inception: 4,541st millennium BC (lead-lead dating, age of the Earth, Young Earth creationism)" Yeah, we sure want a link to Young Earth creationism here... "Dissolved, abolished or demolished date: unknown value (future of Earth)" Not even a link, just the text, as if this is in any way useful. And this is hardly some obscure example. Fram (talk) 14:30, 1 October 2024 (UTC)[reply]

{{Infobox person/Wikidata}}, anyone? — Qwerfjkl talk 18:42, 1 October 2024 (UTC)[reply]

What a great way to introduce unverified intormation (errors) and nonsense into Wikipedia articles. -- Ssilvers (talk) 20:46, 1 October 2024 (UTC)[reply]

Unverified information and incorrect information (what I presume you mean by "errors") are not synonyms. Not everything in WikiData is any of unverified, incorrect or nonsense. Thryduulf (talk) 20:51, 1 October 2024 (UTC)[reply]

@Ssilvers There's an easy parameter to only include information with references. Bad references exist and can be easily fixed using the same methods on both sites. Aaron Liu (talk) 21:01, 1 October 2024 (UTC)[reply]

Wikidata has different sourcing standards than enwiki - sites that are considered unreliable by enwiki consensus are considered quite fine at Wikidata. Wikidata entries are also left out of existing enwiki cleanup mechanisms. So it's not quite as simple as you're suggesting to apply the same methods to both sites - the two sites have neither the same methods nor a shared understanding of what a "bad reference" even is. Nikkimaria (talk) 00:22, 2 October 2024 (UTC)[reply]

Is anyone trying to develop a shared understanding, or does everyone think that it's just OK that the site are disconnected like that, even thought they could help each other much more? If you have links to discussions, I'd be happy to read them. Amir E. Aharoni (talk) 00:46, 2 October 2024 (UTC)[reply]

My perception is it's mutual apathy in both userbases: people who write an encyclopedia aren't coterminous with people who want to build a universal database. While the results are unfortunate, it really would be unreasonable to expect one group of volunteers to operate according to the standards of the other. Remsense ‥ 论 06:07, 2 October 2024 (UTC)[reply]

Then we should make it known to Wikidata why and which sources are bad and often false. I don't see any source that is considered very valid on Wikidata and removed-on-sight on Wikipedia. Aaron Liu (talk) 01:10, 2 October 2024 (UTC)[reply]

[1]. Nikkimaria (talk) 01:25, 2 October 2024 (UTC)[reply]

@Nikkimaria, was this a reply to me? Just one comment from one person? Amir E. Aharoni (talk) 02:15, 2 October 2024 (UTC)[reply]

It was not a reply to you. This one would be a better place to start for your question, though that perspective is also relevant. Nikkimaria (talk) 02:32, 2 October 2024 (UTC)[reply]

Thank you, point taken. In that case, we do need to have parameter-specific overrides at least. Aaron Liu (talk) 02:43, 2 October 2024 (UTC)[reply]

Curiously, one of the arguments in that RfC is "FInd a Grave is sourced from gravestones". Wouldn't citing the gravestone be better in that case instead? Veering off-topic here, though. Aaron Liu (talk) 02:46, 2 October 2024 (UTC)[reply]

The claim that Wikidata is wrong is just a claim. It's a wiki, it is closely integrated with Wikipedia, and it can be as right or as wrong as Wikipedia itself. Amir E. Aharoni (talk) 21:06, 1 October 2024 (UTC)[reply]

Yes, we know Wikipedia is flawed… Which is why we DON’T consider Wikipedia a reliable source, and DON’T use one part of Wikipedia to verify other parts of Wikipedia. Blueboar (talk) 21:18, 1 October 2024 (UTC)[reply]

But what's wrong with that if we can machine-verify that the reused part has a source? This isn't about sourcing to Wikidata, it's about reusing sourced content from wikidata, for all the reasons {{excerpt}} is good. Aaron Liu (talk) 21:20, 1 October 2024 (UTC)[reply]

Is anyone suggesting to use Wikidata to verify things on Wikipedia? I don't think so. I certainly don't.

People are suggesting to insert things that are written on Wikidata into the English Wikipedia in some cases when it's more efficient to do it. They can be verified just like Wikipedia itself. Amir E. Aharoni (talk) 21:32, 1 October 2024 (UTC)[reply]

I don't think Wikipedia should prioritise efficiency. We should prioritise care. If people want to reuse sourced content from Wikidata, they can add the content and add the source. We shouldn't just invite it in uncurated. Folly Mox (talk) 02:41, 2 October 2024 (UTC)[reply]

To paraphrase Shrek: But it is curated. What's the difference if it's curated by a Wikipedia editor or by a Wikidata editor? Wikidata it not a completely separate site. The two sites have always been closely related in terms of both community and technology, and with the same ultimate goal of free knowledge edited as a wiki. If there are differences between them in verifiability policy, I'd think about trying to bridge them instead of dismissing the idea of collaboration outright. Amir E. Aharoni (talk) 13:43, 2 October 2024 (UTC)[reply]

We shouldn't leave curation of content that is included in articles to people who generally aren't looking at or directly editing said articles. This seems very straightforwardly obvious to me. Remsense ‥ 论 13:51, 2 October 2024 (UTC)[reply]

But why do you think that they aren't looking at the articles? I very often edit things on Wikidata because I notice that they appeared incorrectly on Wikipedia, and then I check that the information was updated correctly on both Wikidata and Wikipedia. (It happens more in other languages, such as Hebrew, Spanish, or Russian, because the English Wikipedia uses Wikidata less.)

And what's the difference between changing a thing on Wikidata that will be included in a Wikipedia article and changing a template within Wikipedia that will be included in other pages? (Other than the different URL.) Or changing an image on Commons and Amir E. Aharoni (talk) 14:00, 2 October 2024 (UTC)[reply]

The curation processes between the two sites are entirely different. en.wiki is primarily curated at the individual page level, wikidata seems to be primarily curated at cross-sections where lots of pages intersect. (Also worth considering how much of Wikidata is created by bots pulling from other wikis.) CMD (talk) 14:03, 2 October 2024 (UTC)[reply]

Because they're editing a database! They might not even speak English, never mind take into account the nuances of how the English Wikipedia (or any other project, to be clear) may be affected by what they are directly doing. Whether you think they aren't totally different websites, they are different websites. I really don't think I have to get sociological to discuss a set of social facts here that are fairly obvious to everyone who contributes to a Wikimedia project. "Wikipedia is one site, Wikidata is another" should also answer your second question: if someone breaks a template, it is not a paradigm shift for me to fix it or ask someone else to, because that occurs on the same website. You're a free spirit and that's fine; any design decision that assumes this quality of contributors in general would be a terrible one. Remsense ‥ 论 14:11, 2 October 2024 (UTC)[reply]

Another way to think of it is that they are the same website with different URLs.

And I'm not sure what are you referring to by "quality of contributors" and "free spirit" towards the end. In my understanding, a free spirit in a free encyclopedia is a good thing, but I suspect that you mean something different. Amir E. Aharoni (talk) 19:08, 2 October 2024 (UTC)[reply]

Wikidata is definitely quite a different site, ubiquitous in its low standards for inclusion. Aaron Liu (talk) 19:29, 2 October 2024 (UTC)[reply]

That, by itself, is not a problem. You can include some things from it on Wikipedia, and exclude others. That's more or less what happens on the English Wikipedia already, but it happens more in some other languages, and it works there fairly well. I don't understand the resistance that some English Wikipedians have to include anything from Wikidata. Amir E. Aharoni (talk) 16:14, 3 October 2024 (UTC)[reply]

I agree that it is not a problem. I disagree with what you said about them being the same site and closely related. Aaron Liu (talk) 17:11, 3 October 2024 (UTC)[reply]

They:

Are maintained by the same organization.
Are built from the outset to be connected, similarly to Commons.
Share user accounts.
Share a large part of the editing community. I don't have precise numbers, and of course there are some Wikipedia editors who don't do anything on Wikidata and vice versa, but there is a lot of overlap.

So what makes you think that they are not closely related? Amir E. Aharoni (talk) 22:06, 3 October 2024 (UTC)[reply]

Closely related in terms of underlying infrastructure and overlapping goals doesn't equate to being the same website with different URLs. By design, each Wikimedia wiki has its own community, with its own culture, that defines its own guidance and operating procedures. isaacl (talk) 22:14, 3 October 2024 (UTC)[reply]

All I'm trying to say is that it's not very different from Commons. It's separate in some ways and the same in some others. Some data from Commons and Wikidata is useful in the English Wikipedia, some isn't. Emphasizing only the differences, as some English Wikipedians do, is neither correct nor useful. Amir E. Aharoni (talk) 22:22, 3 October 2024 (UTC)[reply]

All en.wiki takes from Commons is essentially file urls. It's a very different place to en.wiki with very different norms. CMD (talk) 23:24, 3 October 2024 (UTC)[reply]

And, um, the files, not just the URLs, right?

Whatever internal norms Commons has, the English Wikipedia takes a lot of files from it. And it can be the same with Wikidata. The English Wikipedia already takes some data from it, and it can take more.

I'm actually not specifically supporting using the generic Wikidata infobox in the English Wikipedia. I'm just trying to understand the resistance that some English Wikipedia editors have to including anything at all from Wikidata. Amir E. Aharoni (talk) 03:12, 4 October 2024 (UTC)[reply]

Key elements of the resistance have been explained elsewhere in this thread. They relate to a lower quality of sourcing, higher vulnerability to vandalism, and difficulty in editing Wikidata. Sourcing issues do not apply to commons, and file modifications there are restricted to those with advanced permissions. En.wiki does not import files from Commons, although it does host files separately when they are ineligible for inclusion on Commons. CMD (talk) 04:17, 4 October 2024 (UTC)[reply]

Commons benefits from the shared requirements set by the Wikimedia Foundation on media usage, so files are readily usable on any Wikimedia wiki. (Of course, media that embeds information, such as annual stats, suffer from similar problems as Wikidata: its accuracy is dependent on the uploader.) For those concerned about the verification standards on Wikidata, unfortunately I don't really have a good suggestion on creating better processes to validate edits while keeping the "anyone-can-edit, everyone verifies" approach. By its nature, the data is very dense, so I think trying to double check all incoming edits is a more tedious and onerous job than can be expected of volunteers to do. isaacl (talk) 06:35, 4 October 2024 (UTC)[reply]

However, the Wikidata editors do not curate content in articles: editors at wikis that use the wiki-data do. Wikidata is the sourced information, and editors decide which ones to include. That is also why I think templates should include per-parameter overrides before switching to wiki-data by default. Aaron Liu (talk) 19:30, 2 October 2024 (UTC)[reply]

As far as I know, per-parameter overrides is what is done in Wikipedia in all the languages in which templates pull information from Wikidata, and it makes perfect sense. If this is not the situation anywhere, I'd be very surprised. Amir E. Aharoni (talk) 16:17, 3 October 2024 (UTC)[reply]

The Wikidata Infobox on Commons came out of initial work that I was doing here on enwiki - it's the same codebase as {{Infobox person/Wikidata}} and the like, but evolved a lot more due to a lot of constructive input on Commons. It has two views - one for people, one for everything else, and that's been shown to work very well overall, and is a lot more scalable and maintainable than thousands of more specialised templates. Technically, Wikidata infoboxes are quite mature now - and similar ones to this are used a lot on different language Wikipedias. Wikidata is also quite well integrated into different workflows across Wikimedia nowadays (including here with WiR redlists). The main question is a social one: whether the enwp community is interested in pursuing Wikidata infoboxes, and spending the time and energy to constructively contribute to improving data and refining template logic, as the Commons community and other language Wikipedia communities have. Thanks. Mike Peel (talk) 21:00, 1 October 2024 (UTC)[reply]

I think that, at this point, we still have too much fear of the unknown and Not invented here syndrome to accept much help from Wikidata. Other wikis will (and do) benefit from it, but we will have to nibble around the edges for another decade.

It's possible that we should be exploring something closer to the bi-directional but manual syncing that the Wikivoyages use (e.g., for official websites and the latitude/longitude of notable locations). If you haven't seen that, then go to your favorite vacation destination at voy: (e.g., voy:en:Paris/7th_arrondissement#See) and scroll down until you find a section that has [add listing] next to the usual section editing buttons. Click that and you'll get a big dialog box. On the right, find the blank for Wikidata and put in a famous landmark (e.g., "Eiffel Tower"; it won't save the edit until you manually tell it to). Click on "quick fetch" to see what Wikidata offers (and then "Cancel" all the way out, so you don't make any changes to the article or to Wikidata). There's also a dialog that lets you choose individual bits (e.g., I want my URL but Wikidata's latitude/longitude, or to remotely replace old information in Wikidata with newer information). Something like this could be done, and could even be set to require sources. Adding sources to Wikidata is usually quite easy, as you just choose the type (e.g., ISBN, DOI, URL...) and add the raw id number/URL directly. WhatamIdoing (talk) 05:49, 2 October 2024 (UTC)[reply]

While agree with your assessment of WP decision processes, and I really do think we should ideally be doing more with WD structured data here, WD does not make anything easy (echoing Blueboar above), and frankly (from my attempts to raise this issue with them) does not seem to have any concern with the concept of UX at all. The Commons interface works well, but as soon as it migrates you over to edit Wikidata fields directly, you are forced into their bafflingly perplexing interface, where something that should be as basic as the difference between a "property" and a "reference" (and where to add a citation, which is recommended -- but which is not a "reference") is beneath several minutes of documentation. (The weirdest thing about all of this is that on the WD Discord it seems that people misplacing or not adding data is their #1 maintenance task.)

The project (in its current state) is usable if we can limit as much user interaction as possible to our end, but even Commons has not able been to do this fully. (Note: I feel free to complain about some WD editorship here because I've raised these same issues to WD editors directly many times already, often with poor responses.) SamuelRiv (talk) 15:03, 2 October 2024 (UTC)[reply]

The main things I would want to have in place before I could support deeper integration of Wikidata into Wikipedia articles are:

an obvious marker in the wikicode for where a parameter is being pulled from Wikidata (like |parameter=:wd or something), with the ability to overwrite it locally just by overwriting it or clearing it
clearer error messages that make it obvious to people with no experience in Wikidata which datum the template is missing or unable to understand, which links directly to the property on the Wikidata item that is causing the problem, or if it's not present, one link to the property description and one link to the source item

I've run into a few template errors where the error arose at Wikidata, and in no case was I ever able to resolve these myself. If pro-Wikidata–integration editors here are willing to put in the work to make their templates friendly to Wikipedia editors with moderate and below technical aptitude, then I might consider getting on board, but at present they act like inscrutable black boxes, and their effect in practice is to disempower a large subset of editors in this community. Folly Mox (talk) 12:47, 2 October 2024 (UTC)[reply]

I agree with this. I remember the fiascos when {{start date and age}} would scream when improper wiki-data returned multiple dates for just one selector. There should be a way for these templates to error themselves without having the error overwritten by outer, wrapper templates. Aaron Liu (talk) 13:05, 2 October 2024 (UTC)[reply]

"Adding sources to Wikidata is usually quite easy, as you just choose the type (e.g., ISBN, DOI, URL...) and add the raw id number/URL directly. "

Random item [2], first unsourced entry: "taxon". "Add reference" opens field "property", which gives a dropdown with 5 possibilities. I want to use a book, so I guess "stated in" would be the right choice. A new dropdown opens, with endless choices, starting with "human"???, "human settlement"???, painting, village, family name... What the bleep is this about??? Perhaps I need to enter "book" and I can continue? Oh, no, it just stops there. Wikidata is extremely non-intuitive and random. Fram (talk) 08:32, 2 October 2024 (UTC)[reply]

I want to use a book, so I guess "stated in" would be the right choice.

Yeah, so just enter the name of the book... Expecting that it can guess what book you want to cite is quite unreasonable.
You can also just choose "ISBN-13" instead of "stated in". Aaron Liu (talk) 11:38, 2 October 2024 (UTC)[reply]

Just like MediaWiki's own "non-intuitive and random" syntax for putting in a reference, Wikidata also has help pages like wikidata:Help:Sources that explain this exact thing to you. Aaron Liu (talk) 11:43, 2 October 2024 (UTC)[reply]

Even if it is possible to learn by reading the manual (I would hope so!) I think their challenge to the characterization of it as simply "easy" was fair enough. Remsense ‥ 论 11:54, 2 October 2024 (UTC)[reply]

It's at least as easy to add a reference in Wikidata as it is in Wikipedia. That the methods are not the same does not change this. Thryduulf (talk) 11:58, 2 October 2024 (UTC)[reply]

I do not dispute this. Remsense ‥ 论 11:59, 2 October 2024 (UTC)[reply]

I do. Fram (talk) 12:21, 2 October 2024 (UTC)[reply]

One difference worth noting is that on en.wiki someone can search Help:Citation and find something, while in Wikidata most Help: pages are Wikidata items. There is a guide at Wikidata:Help:Sources, but it only guides towards sources that are either Wikidata items or urls. CMD (talk) 12:31, 2 October 2024 (UTC)[reply]

Good point on the borked searching, but there is a "Help" button in the main menu.
You seem to have missed the "Different types of sources" section. Aaron Liu (talk) 12:44, 2 October 2024 (UTC)[reply]

Not sure how you come to that odd conclusion. The different types of sources section is a guide to creating Wikidata items, not to sourcing them. CMD (talk) 13:05, 2 October 2024 (UTC)[reply]

It guides you on how you can cite a database with an item ID (the database is indeed a Wikidata item, but usually, the item for the database you use has already been created), a headstone, Wikisource, and archive records. Aaron Liu (talk) 13:11, 2 October 2024 (UTC)[reply]

This threaded conversation is about the assertion of whether adding a Wikidata reference is "usually quite easy", in the context of comparisons to en.wiki. If I stated it was easy to reference something in en.wiki, you just have to create a new article for it, I suspect people would not find that a convincing argument or helpful contribution. CMD (talk) 13:16, 2 October 2024 (UTC)[reply]

New items on Wikidata are not articles. Their difficulty is far from that of new articles. That said, auto-generated reference items from e.g. a URL would help a lot. Aaron Liu (talk) 16:21, 2 October 2024 (UTC)[reply]

I think you underestimate the difficulty people may have in creating Wikidata items. CMD (talk) 03:02, 3 October 2024 (UTC)[reply]

It's genuinely easy. While the "Create a new item" button in the main menu isn't that noticeable, the steps from there are nearly as easy as filling out {{cite book}}. Aaron Liu (talk) 17:12, 3 October 2024 (UTC)[reply]

Having created items it is not quite as easy as the nice en.wiki citation creator, but aside from that I don't see what the value is in ignoring the multiple people who have stated they find it difficult to parse Wikidata. CMD (talk) 23:28, 3 October 2024 (UTC)[reply]

Auto-generated reference items from URLs are planned for Wikidata, and since Citoid will be used to generate them, they'll be just as erroneous and silly as they are here. Folly Mox (talk) 16:14, 3 October 2024 (UTC)[reply]

And that would mean wiki-data included on Wikipedia would be at the same level of quality as the wiki. Aaron Liu (talk) 17:13, 3 October 2024 (UTC)[reply]

That doesn't follow at all. Wikidata with a reference generated by the tool would have similar references as those generated by that tool if the editors involved are the same, and if the scrutiny afterwards is the same. But since Wikidata has for example poor bots creating articles or adding problematic references, and doesn't have the same level of vandalism control as Wikipedia (even though here as well too much slips through the cracks), the end result is that Wikidata quality is too often way below Wikipedia quality. Fram (talk) 18:07, 3 October 2024 (UTC)[reply]

Items included on wikis will be scrutinized as well as the main wiki is, and I'm not sure what problematic bot contributions you're referring to. Aaron Liu (talk) 20:12, 3 October 2024 (UTC)[reply]

As an example, CJMbot[3]. Latest edits include creating an item on a very obscure 17th c. author[4], and then a week later readding the same items and references to it. Another bot then comes along and removes the duplicate items, but adds the duplicate references to the earlier items. Good going... I noticed this bot because at John Cage it added a second date of birth[5] sourced to Museum Dhondt-Dhaenens. Completely unverifiable, the museum exists but what is meant? Some database, a catalogue, information inside the museum? The result is that e.g. the infobox at Commons now since nearly two years shows the correct and an incorrect birthdate. Fram (talk) 07:56, 4 October 2024 (UTC)[reply]

It looks as if that bot has wrecked countless Wikidata items, many subtly, some extremely blatant. Some concerns were raiesd on its talk page, but despite reassurances that the bot owner would look into it, nothing was done apparently, and no one noticed the massive amount of disruption. Which yet again illustrates to me that we should use Wikidata as sparsely as possible, and not trust it to be good enough to add content to enwiki. See [6], a chemical compound that thanks to this bot is also a human with a birth date and so on. Not a one-off, see [7][8][9][10]... Fram (talk) 10:12, 4 October 2024 (UTC)[reply]

Okay, that is problematic. Looking at its request for bot permissions, it takes CSV databases submitted by museums and attempts to match them for people, hence the comments on "this was indeed a problem in the data". There hasn't been any discussions on the bot linking people to chemical compounds yet, somehow. Hopefully this time I start a discussion at a talk page, someone will notice.
However, when such data is included on Wikipedia, I'm sure people will notice whatever incorrect data there is like you did and fix it. The Recent Changes also has a lot of edits that are shown as manually patrolled, so it's not like their vandalism control is that low. Aaron Liu (talk) 13:54, 4 October 2024 (UTC)[reply]

Sorry to disappoint you, but yes, their vandalism control really is way, waaaay too low. I'm still waiting for someone to revert even one of the 5 vandal edits I bookmarked more than 2 days ago, and today it took nearly 4 hours for someone to realise that "Succcca ahahhaha " (English description: "TUA MADRE STR")[11] is not the correct English label of The Lord of the Rings. If even such high profile articles and such blatant vandalism take this long to be reverted... (And yes, this means that the Commons infobox showed this for 4 hours as well). Fram (talk) 15:04, 4 October 2024 (UTC)[reply]

Have you considered that everybody who saw that is doing the same as you and timing how long it takes for someone else to fix it? Has it occurred to you to fix things rather than passively disrupting the wiki to make a point? 15:59, 4 October 2024 (UTC) Thryduulf (talk) 15:59, 4 October 2024 (UTC)[reply]

Yes, it's lacking. I'm saying that it's not too low. Aaron Liu (talk) 16:29, 4 October 2024 (UTC)[reply]

"Yeah, so just enter the name of the book": where? after the "stated in" box? "Stated in" comes with a lengthy explanation, which even on my widescreen ends with "in which a claim is ma..." without any possibility of accessing the remainder of that text. What's the point of the dropdown after you pick "stated in" if none of these make any sense here. But okay, I add a book title after "stated in". Oops, I want to include a book which doesn't have a Wikidata entry: impossible (or what else does the pinkish-red box mean?). Oh right, according to your help page, if you want to use a reference which doesn't already exist as an item on Wikidata, you first have to create an item for it. So easy! If you are truly out of luck, it is a reference with different editions, and then you have to create two new Wikidata items before you can use it as a source. Want to use a newspaper article as a reference? First create a Wikidata itam for the newspaper article. On Wikipedia, I take the dropdown for the type of reference I want to add (only showing things I can actually use, not "human"), it shows me what the standard fields are, and I don't need to create other stuff only to be able to source something. Trying to edit Wikidata is just an endless source of frustration which I happily avoid and don't want to inflict on others at all. Still, it is nice to see how the number of human edits at Wikidata is constantly artificially inflated by e.g. claiming that I have made 951 edits at Wikidata instead of a dozen or so. Oh well, I have bookmarked 5 bits of Wikidata vandalism to see how fast they get reverted, has that visit to Wikidata given me some fun after all. Fram (talk) 12:21, 2 October 2024 (UTC)[reply]

where? after the "stated in" box?

Yeah, there's a reason the param is called "stated in". That's more intuitive than the book icon in the source editor's toolbar.

which even on my widescreen ends with "in which a claim is ma..." without any possibility of accessing the remainder of that text

It displays completely on my standard 1080p.

What's the point of the dropdown after you pick "stated in" if none of these make any sense here.

That's just like how for the "author-link" parameter, TemplateWizard—the visual way of inserting templates—automatically suggests every article that begins with whatever you typed. However, I do agree that just like the TemplateWizard, Wikidata should not be automatically suggesting things when you haven't typed anything.

you first have to create an item for it. So easy!

It's genuinely easy. While the "Create a new item" button in the main menu isn't that noticeable, the steps from there are as easy as filling out {{cite book}}.
Fair point on having to fill it in twice for the edition item.

it shows me what the standard fields are

Wikidata also does. Every class of objects (denoted by whatever you put in for "instance of") has a recommended set of statements that you should fill in; these will be automatically suggested when you click on the "add statement" button. Aaron Liu (talk) 12:58, 2 October 2024 (UTC)[reply]

You must be looking at a completely different Wikidata (and Wikipedia) than I am than. If Visual Editor is as bad as Wikidata, then that's another good reason not to use it. I don't get a "book" icon, I get a nice textual dropdown with "cite book", "cite web", "cite news" and so on. Standard fields: you claim "Wikidata also does.". No, it doesn't. After I have added a book title after "stated in", nothing happens. I don't get e.g. the pages parameter, or "chapter", or anything. I just have to know which ones are expected. Fram (talk) 13:15, 2 October 2024 (UTC)[reply]

If learning how to edit Wikipedia can be a bit steep learning how to use Wikidata is like walking into a brick wall. Especially on mobile I find it simply unusable. I genuinely feel it would be easy to use if you had to write SQL commands. That's not an attack on the concept of Wikidata, rather a criticism of its implementation. -- LCU ActivelyDisinterested «@» °∆t° 14:49, 2 October 2024 (UTC)[reply]

You can basically SQL CMD (talk) 14:57, 2 October 2024 (UTC)[reply]

But not exactly user friendly. -- LCU ActivelyDisinterested «@» °∆t° 15:25, 6 October 2024 (UTC)[reply]

These are pretty good points. Aaron Liu (talk) 16:22, 2 October 2024 (UTC)[reply]

I believe the Drag'n'drop gadget is default-on, and this 22-second-long video: https://www.youtube.com/watch?v=jP-qJIkjPf0 shows that it takes only a couple of seconds to import a source directly from Wikipedia into the ref field in Wikidata.

Manually adding a ref such as the one I added here takes very few steps:

Click the 'edit' button for that item (if you're not already editing the item).
Click '+ add reference'.
Choose a reference type from the dropdown list. This may require a little advance knowledge (equivalent to knowing which of the many citation templates to use), but it usually suggests something sensible, like "reference URL".
Paste the URL (or other ref information) into the box.
Click 'publish'.

I'm certain that every person in this discussion is capable of learning how to do this, and I'm pretty sure that most of us would find that it takes mere seconds after we have learned the simple steps in the process. This takes, at the most, four clicks, pasting the source, plus sometimes typing the name of a suitable reference type (if the type you want isn't already showing in the list).

The drag-n-drop approach doesn't even require that much effort. Just scroll to the list of Wikipedias at the end of the Wikidata item and click [ref] for the language you want to copy the ref from. A copy of the Wikipedia article will open. Find the ref you want to re-use, and drag it over. Script-assisted copying and pasting does not sound like a difficult task to me. WhatamIdoing (talk) 04:18, 3 October 2024 (UTC)[reply]

So I first add the source to Wikipedia, and then copy it to Wikidata to be able to, er, use it on Wikipedia? How does this make life easier? The video uses Mabery Gelvin Botanical Garden [12] and adds a second ref to the state it is in, Illinois. So if we had an infobox generated from Wikidata, it would have shows that it was located in Illinois, just like it does now. Apart from the fact that the state is no longer mentioned at Wikidata for some reason... It was added in 2016 (with a retrieval date of 2012, not good) and removed more than a year ago. Good thing we don't rely on that site. Considering that none of the 5 examples of vandalism I yesterday recorded have been reverted, it seems vandal fighting on Wikidata is still problematic anyway. Fram (talk) 07:38, 3 October 2024 (UTC)[reply]

The tool is for easily importing existing citations. A tool to help create new citations still needs to be made.
Also, the Wikidata item was changed to be in Champaign county, which seems correct. Aaron Liu (talk) 13:57, 3 October 2024 (UTC)[reply]

As said by Chipmunkdavis below, the tool isn't even visible to mere mortals, is it a toggle in the preferences? And I didn't claim that Champaign county is incorrect, but that if the infobox was Wikidata-filled, it would have changed from "Illinois" (good, informative for most people, wanted) to "Champaign county" (not informative for most people, certainly without "Illinois"). Or, to be even more exact, it would have removed "Illinois" from the infobox but not even added "Champaign county" in its place, as on Wikidata, Champaign county is not even referenced... USA wouldn't be shown either, as that is "referenced" to enwiki. The only references in the article are 404 errors. It's not an example I deliberately picked, it's one given by WhatamIdoing (though involuntarily I guess), but it is typical of Wikidata, even after 10+ years. Even when one goes to a basic article, say Illinois[13], it has hardly any reliable sources. Fram (talk) 14:57, 3 October 2024 (UTC)[reply]

Yes, the gadget is not enabled by default and needs to be toggled.
Naming locations as within their provinces is a style convention independent of data. Infoboxes could easily make two calls to Wikidata for the location. Aaron Liu (talk) 15:29, 3 October 2024 (UTC)[reply]

Doesn't seem to be the default. My Wikidata interface (including for Mabery Gelvin Botanical Garden (Q5477670)) has the various wiki links at the bottom of the page, and without [ref] icons. CMD (talk) 09:30, 3 October 2024 (UTC)[reply]

Another key difference (in my experience) between WP and WD: on WP it is acknowledged that there is a learning curve and entry barriers to editing, and in virtually every VP conversation the notion of how to mitigate this is brought up; on WD the conversations I've had seem indicative that editors believe that it is completely intuitive at its core -- either they don't believe they can make it any easier for users, or that users' difficulties are their own fault (this is just the impression I've had from conversations -- admittedly I'm very direct about reporting interface problems). Additionally, when asked, WD editors did not seem interested in running user interaction experiments or examining existing UX data.

Again, this is not to dogpile on WD for no reason. I believe in the project's core purpose, but I feel at this point like I gotta yell at any direction to get them to wake up. SamuelRiv (talk) 14:58, 3 October 2024 (UTC)[reply]

This problem definitely exists on Wikidata, but it exists on Wikipedia, too. Amir E. Aharoni (talk) 16:06, 3 October 2024 (UTC)[reply]

Regarding the work required to update Wikidata: when I last made a change, which was admittedly a long time ago, I had to go down a long rabbit hole creating Wikidata items for each property value I was added to the citation that didn't already exist, which cascaded to creating more Wikidata items for the property values of the initially created items, and so forth. If this is still the case, then I would be a lot more inclined to update Wikidata if there were a tool to help generate the entire tree of cascaded Wikidata items for me to approve for submission. isaacl (talk) 16:35, 2 October 2024 (UTC)[reply]

Continuation

While the initial premise of this thread is challenging. I think it's worth regrouping to deliberate specifically on some other concepts and potentialities vis à vis Wikidata integration others have brought up so far. In particular, I think it's generally agreed that a range of features are potentially viable as long as they're bidirectionally transparent—i.e. Wikipedia users do not have to learn how to use Wikidata or leave Wikipedia in order to pull or update information. We're fairly familiar with this partially being the way short descriptions work, I think? Remsense ‥ 论 03:46, 3 October 2024 (UTC)[reply]

I believe Wikidata pull en.wiki short descriptions (and other languages?) for its relevant field only when there is no existing one on Wikidata, and similarly en.wiki only shows Wikidata if there is no en.wiki short description (unless that has already been disabled?). Wikidata will also pull coordinates and other items, but I don't know if much of this comes bidirectionally back to en.wiki. CMD (talk) 14:07, 3 October 2024 (UTC)[reply]

You can find more about usage of Wikidata on English Wikipedia at Wikipedia:Wikidata. Over 100 Infoboxes make use of Wikidata in some fashion. See Category:Infobox templates using Wikidata.

The other dimension this conversation neglects, is that English Wikipedia editors would have chance to support other language editions, if we maintain interoperability between Wikidata and Wikipedia; with all other language editions of Wikipedia. There are legitimate concerns about interface complexity (for all Wiki projects) and sourcing standards, but let's tackle them instead of carte-blanche rejecting any synergies. ~ 🦝 Shushugah (he/him • talk) 23:24, 3 October 2024 (UTC)[reply]

I'm familiar with our infoboxes using Wikidata. The uses I'm aware of though aren't bidirectionally transparent in the way Remsense mentions, as you very much do have to go into Wikidata to edit them. CMD (talk) 23:31, 3 October 2024 (UTC)[reply]

I'll probably again be accused of "passively disrupting the wiki to make a point"[14], but for anyone who believes that Wikidata has a well-functioning vandal patrol system, here are the 5 random bits of vandalism I bookmarked last week, surprise, none of them have been corrected. They are a varied bunch, from someone creating an unsourced BLP violating article on a non-notable person[15] to someone randomly vandalising some labels[16] (which also affects e.g. Commons), from the obscure but obvious[17] to an editor vandalizing 4 different articles without any problems[18], and ending with a Wikipedia editor with an enwiki article, who died fighting for Ukraine against Russia, being blatantly vandalized and insulted[19]. Fram (talk) 09:47, 9 October 2024 (UTC)[reply]

To sneak in a very brief aside I meant to post before this spawned a subthread, I do think passive disruption is a bit of a tough sell. Folly Mox (talk) 12:49, 9 October 2024 (UTC)[reply]

Putting aside the specifics, would semi-protecting all items used on enwp sufficiently assuage vandalism fears? It would've prevented all of those examples above. It's already the case that high-use items are semi-protected, but I don't really know the culture of semi-protection on Wikidata to predict whether a lower threshold is realistic. Seems worth acknowledging as a possible support condition amid the years-long "it's garbage" vs. "it's useful" debates here. — Rhododendrites ^talk \\ 12:04, 9 October 2024 (UTC)[reply]

If we transcluded such content onto Wikidata, the selections of content we actually use would be put under the same, quality countervandal lens that has worked for years. Aaron Liu (talk) 12:10, 9 October 2024 (UTC)[reply]

Do you mean "from" Wikidata? Otherwise I don't really understand your comment. And no, in the current system this wouldn't work, vandalism on Wikidata that has an impact here is not detected as quickly as vandalism here (in general, we have vandalism that remains for months or years as well). We can include Wikidata changes in e.g. "recent changes", but then we get things like this included (as "Dm Antón Losada Diéguez (Q3393880); 12:37 . . Estevoaei (talk | contribs) (‎Created claim: Property:P1344: Q12390563)", which has no bearing on Enwiki at all. Which is typical, most of the Wikidata changes we see are either interwiki links, English descriptions (which we don't display anyway), or things like this which will never be shown here. Fram (talk) 12:46, 9 October 2024 (UTC)[reply]

Yes, I meant from, sorry. You indeed don't get RC patrolling, but I think the biggest reason WD vandalism doesn't get detected is that it's not prominently displayed. Any vandalism that escapes initial RC patrolling would have little chance of detection unless the vandal has hubris (c.f. anyone who has nuked someone's contributions) or people actually read the article, which they do, and so they fix. If we increase the prominence of such data by actually using it, we will also substantially increase the countervandalism. I hardly see any vandalism on wiki-data we already include on articles. Aaron Liu (talk) 17:23, 9 October 2024 (UTC)[reply]

At least some of the examples I gave already impacted e.g. Commons, and no one detected it from there either. When the Wikidata descriptions were displayed on enwiki, vandalism of these descriptions was not significantly or rapidly detected on enwiki and reverted on Wikidata. This RfC discussion from 2017 gives many examples of what goes wrong when enwiki relies on Wikidata for its data, and also gives (near the bottom) examples of prominent Wikidata vandalism lasting for hours and impacting a number of enwiki articles, from during that RfC. It happens all the time. Fram (talk) 18:02, 9 October 2024 (UTC)[reply]

Commons isn't very prominent.

lasting for hours

So? That's not abnormal for vandalism, even on Wikipedia. The amount of edits nuking reverts means many cases of vandalism probably are still extant. There's this famous boxer I forgot the name of who had his infobox blatantly vandalized with the nickname changed to something like "imbecile"; it only got reverted after four days. Look at special:Diff/1241738467, which shut off the feedback request service for months. Disregarding the easy protection fix, does that mean all RfCs should be run manually? No. Aaron Liu (talk) 18:35, 9 October 2024 (UTC)[reply]

I doubt that vandalism moving Romania to Moldavia would last for hours on enwiki. This is not some sneaky vandalism, this is in-your-face vandalism. As for Wikidata vandalism being perpetuated across infoboxes in many languages (and not being spotted or corrected by the people at these languages either), we have now (since more than an hour) an impossible date of birth for Johan Cruijff, one of the best soccer players ever and thus an article of some importance. The Wikidata vandalism is visible in Catalan[20], Asturian[21], Galician[22], "ha"[23], Norwegian[24], Welsh[25], and so on. Using enwiki as a pool of editors to do vandal control on Wikidata (which is what the above proposal would boil down to) doesn't seem to be a productive way forward for enwiki. Fram (talk) 12:35, 14 October 2024 (UTC)[reply]

Vandalism moving Romania to Moldavia wouldn't last for hours on Wikidata either. Johan's DOB was reverted 7 minutes after your comment, and thus the wrong birthdate only stood for 1 hour and 15 minutes. And no, that's not because of your comment, as the reverter is a frequent RC patroller. We can see that Wikidata does have countervandalism. As for the wikis not spotting it, don't forget that it's a workday in Europe, and don't forget the boxer. Aaron Liu (talk) 12:56, 14 October 2024 (UTC)[reply]

Found the boxer edit I was talking about: Special:Diff/1249398659. Aaron Liu (talk) 13:04, 14 October 2024 (UTC)[reply]

If you start denying reality, it's hardly useful to continue this discussion. And no, I don't believe in such coincidences. When I posted the previous 5 bits of vandalism (one week after they occurred), one was deleted 2 hours later[26], and the others reverted a few minutes after my post (and a repeat occurrence only lasted for 3 hours, hurrah I guess[27]?). Meanwhile, an editor makes just one vandalim revert, which just happens to come directly after my post here, but doesn't care about other blatant vandalism like the 18 edits here[28], which again vandalizes Catalan Wikipedia[29] and even Spanish Wikipedia[30]. Less obscure articles? Stromae, the great Belgian singer: preferred image vandalized on Wikidata, so the infobox on e.g. Catalan Wikipedia or Norwegian[31] shows a wrong image for hours (oh right, during working hours, when no one uses Wikipedia...), as does Commons[32]. Never mind that since May, the Norwegian Wikipedia proudly displays at the top of their infobox, thanks to Wikidata: "Gary Lineker Golden Bollocks".[33] Clearly, using Wikidata to propulate your infoboxes is stupid and reckless, and only gives vandals an extra outlet to play around with. Fram (talk) 14:36, 14 October 2024 (UTC)[reply]

Alternatively, vandalism transcluded here will be seen and fixed much quicker meaning that for the exact same amount of effort vandal fighters will be fixing vandalism on multiple languages/projects rather than just one. Thryduulf (talk) 14:41, 14 October 2024 (UTC)[reply]

To quote myself from right above: "Using enwiki as a pool of editors to do vandal control on Wikidata (which is what the above proposal would boil down to) doesn't seem to be a productive way forward for enwiki." Wikidata is touted as good for multi-wiki data, some languages fell for this claim, and now enwiki should do the vandal control for them? Everyone here is free to go to Wikidata and do vandal patrolling, no one is stopping you. Some would even argue that if someone like Thryduulf knows that vandalism is affecting Wikidata and other languages Wikipedias, and they make no effort to do any patrolling there, they are actually "passively disrupting" the WMF landscape, no, the knowledge of the world. And as explained above by many editors, no, it's not "for the exact same amount of effort". Never mind e.g. the not yet mentioned issue of duplicated adminning effort, with blocks, protection, ... needed on both sides. Fram (talk) 15:13, 14 October 2024 (UTC)[reply]

We're just going round in circles by now, so I'm just gonna address your only new claim:

only gives vandals an extra outlet to play around with

No, it removes outlets. Previously, vandals can vandalize an infobox from an article on any edition of Wikipedia. Now, when they vandalize, they have to vandalize all of them at once and get more quickly reverted. Simplified: Previously, vandals have like 80 places to vandalize. Now, they only have like 20. Common sense shows that vandalism seen on the Spanish Wikipedia is reverted quicker than that of the Catalan Wikipedia. Wikidata centralizes information, and thus vandal control can be less duplicated.

Since you've been acrimoniously listing vandalism on Wikidata that reflects onto the Catalan edition, why don't you look at this giant list of vandalism on the Catalan WIkipedia instead? Aaron Liu (talk) 15:21, 14 October 2024 (UTC)[reply]

That math doesn't math. If there is a version of an article on 80 Wikipedias and they all draw their infoboxes from Wikidata, then there are still 80+1 places to potentially vandalize, because there's still the rest of the article - this proposal doesn't get rid of that. A vandal who wants to write "poop" at the top of the article on Catalan Wikipedia can now do so at either Catalan Wikipedia or Wikidata, and someone who wants to prevent vandalism from appearing in that article at Catalan Wikipedia needs to monitor both. Nikkimaria (talk) 15:36, 14 October 2024 (UTC)[reply]

Ah, so that's what it means. Fair point. But the information in the infobox is arguably (one of?) the most important part of an article, and the math would math there. Aaron Liu (talk) 16:44, 14 October 2024 (UTC)[reply]

Not if you allow overrides. Nikkimaria (talk) 16:50, 14 October 2024 (UTC)[reply]

A workday in Europe? But it's St Angadrisma's Day today. --Redrose64 🌹 (talk) 14:53, 14 October 2024 (UTC)[reply]

They take days off Christian feast days in Europe? Aaron Liu (talk) 15:07, 14 October 2024 (UTC)[reply]

Have you been to Cardiff on 1 March, or Dublin on 17 March? --Redrose64 🌹 (talk) 17:36, 14 October 2024 (UTC)[reply]

I know there are big saints, but I don't think Angadrisma is one that any country takes time off for. Aaron Liu (talk) 17:47, 14 October 2024 (UTC)[reply]

It's possible to think of it as vandal control on the English Wikipedia that also happens to be vandal control on Wikidata and Wikipedia in other languages. Amir E. Aharoni (talk) 13:34, 14 October 2024 (UTC)[reply]

There are simple implementations, which may perhaps be needed to be coded at WMF level, that we could implement to monitor cross-wiki vandalism from our watchlists here, which seems to be basically what you're talking about -- any change of a wikidata (or commons etc) transcluded material onto a watchlisted article should result in a notification on that editor's WP watchlist (or similarly implemented tool).

Of course, if for example every citation in an article becomes linked to wikidata (and this is beyond the scope of OP), this is a lot of items to place on a watchlist, but I don't know that it matters since the number of expected changes on WD and Commons items is so small (assuming one can watchlist individual properties and not entire items). But automating the process should not be an issue, and notification cross-wiki is already to some extent doable.

Of course it doesn't address what's brought up previously that WD is f-ing awful to edit, which really is something that can be fixed if editors there acknowledge it. SamuelRiv (talk) 15:50, 14 October 2024 (UTC)[reply]

Wikidata is WMDE, not WMF. WhatamIdoing (talk) 23:57, 16 October 2024 (UTC)[reply]

Really? There's nothing at d:Wikidata:Introduction saying that, indeed at the bottom of every page is the same little "a WIKIMEDIA project" box that we also have, that if clicked takes you to https://wikimediafoundation.org/ - admittedly, this is not the same as wmf: but it's not at all clear what the distinction is. --Redrose64 🌹 (talk) 07:20, 17 October 2024 (UTC)[reply]

The WMF hosts it, but WMDE does the software. See mw:Wikibase: "Wikibase is a free, open-source software made and supported by Wikimedia Deutschland and a large community of contributors." The Wikidata Change Dispatching & Watchlists project (the stuff that puts Wikidata changes in your watchlist) is one of WMDE's projects. WhatamIdoing (talk) 19:36, 17 October 2024 (UTC)[reply]

Automatically add archive date

The archive URL comes in this format: www.web.achive.org/web/yyyymmdd/https:www.placeholder.com

The date can be automatically entered when the URL is given, instead of having to add the date. Who am I? / Talk to me! / What have I done? 05:03, 7 October 2024 (UTC)[reply]

I know that is true of the Internet Archive, but I seem to remember that other archiving services have different URL formats. Alt.Donald Albury (talk) 12:00, 7 October 2024 (UTC)[reply]

Maybe we can detect the link (starting with web.archive.org), and if it is the internet archive, then the format can be used. The other archives are not used significantly, so this will not impact the process much. Who am I? / Talk to me! / What have I done? 12:43, 7 October 2024 (UTC)[reply]

This is an excellent idea. Archive.org does not use yyyymmdd but, for example, 20031224105129. I manually have to insert dashes at the appropriate points 2003-12-24105129 and remove the timestamp so I end up with 2003-12-24. It seems very very likely that a bot is already doing this task, but to be sure you can ask over at Meta or WP:VPT. Polygnotus (talk) 23:08, 7 October 2024 (UTC)[reply]

Ok, so only the archive URL is needed to fill the citation template. The date can just be filled in automatically

Who am I? / Talk to me! / What have I done? 02:47, 8 October 2024 (UTC)[reply]

Pinging @GreenC for archive.org's date format WhatamIdoing (talk) 17:43, 9 October 2024 (UTC)[reply]

As an idea, I fully support this. I also used to wonder why the heck the template would nag about the missing date when it's available in the URL, and was particularly annoyed by the timestamp mismatch message. However, I've since learned that this is not as easy to implement as it may seem.

{{cite}} templates literally can't add the missing parameter or alter it, because templates can only alter their output (i.e. the displayed HTML), not change the wikitext input. I guess strictly speaking this would be possible with subst:-ing, but forcing everyone to do that with {{cite}} isn't going to fly.
The editor (software) certainly could make this happen automagically, but I'm pretty sure the devs would (understandably) be disinclined to introduce special treatment for specific templates on a specific wiki. Also, while the visual editor could hide the necessary wikitext change behind the scenes, for the source editor this would have to mean auto-correcting the submitted wikitext after the fact, and AFAIK this is currently not done for any reason.
Since {{cite}} is usually placed inside <ref>...</ref>, mw:Extension:Cite could conceivably handle this, but again, good luck convincing the devs.

So, I think "fill in |archive-date= from |archive-url= while the user is editing" is probably going to be a hard sell. There are other considerations, though.

Since a missing or mismatched |archive-date= automatically lands the page in Category:CS1 errors: archive-url, is it necessary to nag editors about it (and, especially, put red error messages in the displayed page)? fixemptyarchive and fixdatemismatch functionality of WP:WAYBACKMEDIC can easily fix these errors, so why not have the bot run more frequently than the current every 2-3 months? Not necessarily with its full functionality, just against this particular category. I don't really see why this couldn't happen daily.
And to put this more radically: is a separate |archive-date= needed at all when its content merely duplicates that of another parameter? Since CS1 Lua code already has some special handling for archive.org, why not just add taking the date from the URL as well? CS1 predates the availability of Lua, so perhaps this was too inconvenient to implement with the old template functionality and requiring editors to always include this parameter was unavoidable. This no longer seems to be the case, though. Archive information doesn't seem to be needed for COinS (which wouldn't be taken directly from wikitext anyway), nor do I know of any other reason to keep it mandatory for archive.org links (or any others that include the date).

I'm very possibly missing something important regarding the status quo, so hopefully people like @Trappist the monk and @GreenC can chime in.

Gamapamani (talk) 12:29, 12 October 2024 (UTC)[reply]

Thanks a lot for refining the proposal. The second consideration makes a lot of sense. Adding an archive URL is always manual, even if you use the automatic tool, so I think it makes sense to remove the parameter and, using Lua, find the date from the URL. Who am I? / Talk to me! / What have I done? 14:23, 12 October 2024 (UTC)[reply]

--> Category:CS1 errors: archive-url currently has 33 pages. I clear it every 15 days. Last time it was cleared was around October 1. Not a big problem. -- GreenC 19:47, 12 October 2024 (UTC)[reply]

Sure, I didn't mean to imply it should be cleared more often as things stand right now. What I was trying to say was that if |archive-date= nagging in the editor and on the resulting page were dropped for archive.org, the category would presumably fill somewhat faster, but the bot could still handle it. Gamapamani (talk) 02:59, 13 October 2024 (UTC)[reply]

Yes, The CS1 error need not be shown. Who am I? / Talk to me! / What have I done? 03:53, 17 October 2024 (UTC)[reply]

Public figure photos on infoboxes

Hello. I would like to propose a project regarding photos on infoboxes on articles pertaining to executives and other public figures. I believe there is too much inconsistency on Wikipedia, with photos ranging from official, professional portraits to photos taken of them out in the wild, such as on a stage or during a live stream. To maintain consistency and make Wikipedia articles look more presentable, I would like us to move towards having portraits of said individuals whenever possible to avoid copyright infringement. Most articles of politicians follow this trend; and so, I'd like to broaden this to all public figures, especially those who hold or have held C-level positions. I look forward to everyone's thoughts and please let me know if this type of discussion should be moved elsewhere. MikeM2011 (talk) 21:29, 7 October 2024 (UTC)[reply]

Not sure what you want to do that hasn't already been done. The reason there's so much inconsistency in portraits is that we just don't have enough photographers to take pictures of subjects in public places (or get consent to take pictures of subjects in private places). Aaron Liu (talk) 21:36, 7 October 2024 (UTC)[reply]

There are many professional portraits available online we could use. I'm not sure why we can't utilize these with proper citations under the fair use agreement. MikeM2011 (talk) 02:12, 10 October 2024 (UTC)[reply]

You can't because anyone should be able to take a free image of them in a public location, and we can't afford to allow mass uploads and then get sued a ton. Aaron Liu (talk) 02:34, 10 October 2024 (UTC)[reply]

Unfortunately, the rules over non-free content do not allow to use fair use claims on photos of living people, and that policy is way too strong to even consider changing it (I'm not even sure if we can, or if it was decided by the Wikimedia Foundation). That means that, on a lot of things related to images, we don't use or do what we would want, but only what we can with the limited images available to us. I suspect that by "articles of politicians" you mean US politicians, and we have plenty of good images and even portraits because many official sites release their contents under free licenses. But try to write about politicians from elsewhere, and you'll likely have to deal with the same scarcity of good photos of many other topics. Cambalachero (talk) 03:58, 10 October 2024 (UTC)[reply]

I believe that requirement is purely local. We created it, and we can change it. But I share you skepticism that we would choose to change it. WhatamIdoing (talk) 18:13, 11 October 2024 (UTC)[reply]

foundation:Resolution:Licensing policy says An EDP may not allow material where we can reasonably expect someone to upload a freely licensed file for the same purpose, such as is the case for almost all portraits of living notable individuals. Anomie ⚔ 20:39, 11 October 2024 (UTC)[reply]

New fonts

I always wanted to see other fonts on Wikipedia (except Comic Sans MS, that is so bad). Try adding other fonts. Electrou (formerly Susbush) (talk) 16:09, 11 October 2024 (UTC)[reply]

Add this to your Special:MyPage/common.css:

body {
	font-family: "name of font family";
}

, with the part between the double quotes replaced with the actual font family, of course. Aaron Liu (talk) 16:32, 11 October 2024 (UTC)[reply]

Ok. Electrou (formerly Susbush) (talk) 16:54, 11 October 2024 (UTC)[reply]

I want Ubuntu font, can I get the code? Electrou (formerly Susbush) (talk) 17:04, 11 October 2024 (UTC)[reply]

does it support Ubuntu font? Electrou (formerly Susbush) (talk) 17:13, 11 October 2024 (UTC)[reply]

It doesn't work (I tried Ubuntu font) Electrou (formerly Susbush) (talk) 17:17, 11 October 2024 (UTC)[reply]

@Electrou, what web browser and operating system are you using? WhatamIdoing (talk) 18:56, 11 October 2024 (UTC)[reply]

I'm using the latest version of Google Chrome, and I'm on mobile (I use desktop view when needed) Electrou (formerly Susbush) (talk) 20:30, 11 October 2024 (UTC)[reply]

As Chaotic Enby suggests, you can't display Wikipedia in any font that isn't on the device you're using. If you open Google Chrome and go into the settings/preferences, there is an item (on my laptop, it's under "Appearance") that says something like "Customize fonts". It should have a drop-down menu that lists all the fonts. If "Ubuntu" isn't in that list, then your device can't display that font. WhatamIdoing (talk) 20:43, 11 October 2024 (UTC)[reply]

If you can't install it on that device, then you can still use fallback fonts! They're mostly useful if the same page can be viewed from different devices with different sets of fonts installed, and display if the preferred font isn't install.

body {
	font-family: "preferred font", "fallback font", "fallback fallback font";
}

For example, my userpage is best viewed in Josefin Sans, but also has a series of fallback fonts as it is not available on every device. Chaotic Enby (talk · contribs) 21:38, 11 October 2024 (UTC)[reply]

Theoretically, you can also do

@import url('https://fonts.googleapis.com/css2?family=Ubuntu:ital,wght@0,300;0,400;0,500;0,700;1,300;1,400;1,500;1,700&display=swap');

to download the fonts automatically. However, I don't think that'll work, since MediaWiki:Common.css is the top stylesheet and I'm not sure if the user's stylesheet is loaded individually. Aaron Liu (talk) 21:47, 11 October 2024 (UTC)[reply]

You can load fonts from other servers such as the Google font server, or the toolforge proxy for the Google font server, should you choose. Note page referrer info will get sent to the font server whenever the font is loaded (typically it will get cached so it will load infrequently), so some people are wary of doing this. Also note the toolforge mirror isn't recommended for general use. isaacl (talk) 22:00, 11 October 2024 (UTC)[reply]

User's stylesheet is also loaded individually, precisely so that @import works. – SD0001 (talk) 19:42, 17 October 2024 (UTC)[reply]

I have installed the font, but it doesn't display it. Electrou (formerly Susbush) (talk) 07:55, 12 October 2024 (UTC)[reply]

Have you installed it on your mobile phone? Chaotic Enby (talk · contribs) 20:36, 11 October 2024 (UTC)[reply]

Pages to be saved offline

It would be a very go thing to have this app where people can download or save Wikipedia for offline. This way, those who do not have access to Wi-Fi (Like me), can be able to research and edit things easily. HippieGirl09 (talk) 14:13, 12 October 2024 (UTC)[reply]

Look at the Tools tab on the article page. On my system, one of the options is to "Download as PDF". Another option is "Printable version". You can use that to print to a file. Actually, you can download all of the English Wikipedia, but you will need a lot of storage space. However, you will need to perform all edits on line.Donald Albury 18:58, 12 October 2024 (UTC) Edited 19:01, 12 October 2024 (UTC)[reply]

@HippieGirl09 The official Wikipedia Android and iOS apps allow you to save individual articles for offline reading. If you're interested in having the whole of Wikipedia available offline, then you might want to check out Kiwix. the wub "?!" 22:35, 12 October 2024 (UTC)[reply]

Adding personal page view history

I think it would be a cool feature to be able to view the history of articles which you have viewed in the past on the web version of Wikipedia (I think this might exist on the app version already?). I go through many Wikilink rabbit holes and I’d like to be able to see a list of all the articles which I have read. Is this a conceivable addition to the Wikipedia software? Cleebadee (talk) 21:10, 12 October 2024 (UTC)[reply]

I suggest using your browser history (which may mean finding a browser with a conveninent way to search your history). I think many users would feel uncomfortable with our Wikipedia reading history easily available for anyone to access on the Wikipedia server. (The information can of course be determined from web server logs, but that's less convenient for bad actors to take advantage of.) isaacl (talk) 21:32, 12 October 2024 (UTC)[reply]

As an analogy, my local library uses software that has an option of whether to retain a record of books I have checked out, which is turned off by default. With the default, the record of a book I have checked out is erased when I return the book. That way, if a government agency demands a record of the books I have checked out, and I have left the option set to not retain a record, the library has no information to turn over. Government agencies and other parties cannot optain records that do not exist. BTW, I might be paranoid, but I have earned it. I have copies of two FBI reports about me (via the US Freedom of Information Act), one about 200 pages long and the other 22 pages long. Donald Albury 22:05, 12 October 2024 (UTC)[reply]

Are you saying that Wikipedia should allow this as an option? It seems like this would be a good way to make it a thing without forcing people to use it. Maybe it could be a tool which is off by default? Cleebadee (talk) 03:28, 13 October 2024 (UTC)[reply]

I am saying that one of the considerations on whether to keep a record on what you have looked at on Wikipedia is that if a record exists it can be subpoenaed or hacked. Another consideration is that if such records do not exist, then the Wikimedia Foundation does not have to expend time and money responding to/resisting government requests for access to those records. If I could have a say on whether to have such an option, I would oppose it. I think users deserve the right to read whatever they want to on Wikipedia without worrying about someone looking over their shoulder. We cannot prevent someone from monitoring what a reader looks at from their end, but we can do what we can to preserve privacy within Wikipedia. Donald Albury 13:54, 13 October 2024 (UTC)[reply]

Would having the record available on Wikipedia itself make it easier to hack than it being available indirectly through one’s search engine history? Cleebadee (talk) 14:31, 13 October 2024 (UTC)[reply]

You can filter your browser history by websites. In the worst case, you can search "Wikipedia" in the history. Aaron Liu (talk) 22:11, 13 October 2024 (UTC)[reply]

I feel like using a hypothetical Wikipedia view history and searching Wikipedia in a search engine history are both easy things for a bad actor to do. So I don’t understand the idea that adding the Wikipedia one would make it easier for bad actors. Is it easier for them to hack into Wikipedia compared to search engines? Cleebadee (talk) 20:12, 14 October 2024 (UTC)[reply]

If you want the data to be synced across devices, you'd need to upload the information to Wikpedia's servers; meanwhile, history is usually not synced by default. It's also additional complexity to the software with very little benefit. Aaron Liu (talk) 20:49, 14 October 2024 (UTC)[reply]

I believe Zotero Connector has this option which you can activate for the wikipedia domain. That is, if you're interested in tracing back your wikipedia history (and of other websites and reading, and of sources for WP editing and general research + writing) beyond simply your browser history, Zotero is a nice thing to have around. SamuelRiv (talk) 22:23, 12 October 2024 (UTC)[reply]

Nice, I hadn’t heard of this website before. I use an iPad so I don’t think I’m able to use this though. Cleebadee (talk) 14:29, 13 October 2024 (UTC)[reply]

Wikipedia Main Page Proposal

Moved from WP:VPT

I think that the Wikipedia main page would be more educative and with a section riddles, proverbs, idioms, wise saying. You know, a collection from many languages around, their origins, past meanings, reforms, present meanings, examples of their usage in history (past & present), their literal meanings, word for word rendering in english, etc. I don't know, who has better ideas? Let Wikipedia be a fun place too for visitors and readers to always learn more. I'm looking forward to seeing this by the start of next year and in other language wikis. Any and all contributions are accepted. elias_fdafs (talk) 20:02, 13 October 2024 (UTC)[reply]

@Elías Fortaleza de la Fuerza Sánchez: I moved your idea to the idea lab here, it was not a technical issue. — xaosflux ^Talk 20:09, 13 October 2024 (UTC)[reply]

While this does sound more like a Wiktionary or Wikiquote thing, I feel like there might be fruitful discussion to be had about showcasing featured content from sister projects in the general case. Folly Mox (talk) 20:32, 13 October 2024 (UTC)[reply]

Oh dear, another Main Page redesign suggestion. Good luck with that. --Redrose64 🌹 (talk) 20:51, 13 October 2024 (UTC)[reply]

The thing is, one person's "wise saying" is another person's "deepity". I don't think having these on the Main Page, especially in a dedicated section, would actually be very encyclopedic. However, like Folly Mox says, a more general concept of showcasing sister project content (a word etymology, a quote, etc.) could be interesting! Chaotic Enby (talk · contribs) 21:03, 13 October 2024 (UTC)[reply]

How about a small section with whatever the sister project featured thingy is? It could cycle daily. Cremastra (talk) 22:57, 13 October 2024 (UTC)[reply]

That could very well work! Chaotic Enby (talk · contribs) 17:22, 14 October 2024 (UTC)[reply]

The tricky thing is actually transcluding something from another project, which I don't think is possible without mw:Scary transclusion. Cremastra (talk) 17:25, 14 October 2024 (UTC)[reply]

I assume you mean without scary transclusion? jlwoodwa (talk) 18:54, 14 October 2024 (UTC)[reply]

Fixed. Thanks, Cremastra (talk) 18:58, 14 October 2024 (UTC)[reply]

The problem with idioms and proverbs is that, usually, they are regional. They are widely used at some area, but hardly mentioned or even unknown in others. For each user that see such a section and says "oh, that's the origin of that proverb" we'll have several who will say "what, was that a proverb? Never heard about it". Besides, explaining their background is just impossible with the limited text in main page boxes. Perhaps DYK may be a better venue to show those articles in the main page. Cambalachero (talk) 13:18, 15 October 2024 (UTC)[reply]

Articles on idioms would be helpful, especially if they mentioned pitfalls when translating between languages. However, I don't believe that the main page is an appropriate venue. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:58, 15 October 2024 (UTC)[reply]

As I discussed at Wikipedia:Village pump (proposals)/Archive 213 § Proposal: Create quizzes on Wikipedia, I suggest finding people interested in creating that type of content, creating a project page, and producing the content regularly on whatever schedule you can manage. From that experience, you can try to figure out how to make the process sustainable. isaacl (talk) 15:59, 15 October 2024 (UTC)[reply]

I think that it could be put in Portal:Current events, on the side under the "2024 at Wikipedia's sister projects" box. There's plenty of room, and a "____ of the Day" could be fun. WhatamIdoing (talk) 00:03, 17 October 2024 (UTC)[reply]

Add 'Contribute' links to main page on iPad app

My last period of major editing was in 2017, and at the time the editing interface in the iPad app was pretty barebones, but now the mobile apps have really nice support for basic types of editing. Especially the iPad app, which has a customized interface that isn't quite the same as either the visual or source editors on web. I actually really wish that interface was supported on the iPhone app, that seems to use a less feature full version of the web interface for editing for some reason, but that's besides the point.

I edit about 50% on an iPad, and at those point the app is a better experience than using iPad safari, which has some persistent issues with editing for me. However, it's hard to find information about how to contribute to wikipedia on the iPad app, or to access things like community dashboards/proposals/task lists.

It'd be nice if there was a section of the main screen on the iPad that contained the same links as the "Contribute" section of the menu on the web, or otherwise encouraged and supported new contributors. It would not only support editors like me who just want to get to those things more easily, it might engage current readers who use the iPad app and thus aren't regularly being reminded about chances to contribute on the main screen like the majority of web users are. The iPad app is good enough now that its a really nice editing experience, and I think could work as the the primary interface for new editors. Alternatively, those links could be added to the main menu on the app, which would solve the convenience issue, but not engage/encourage new editors.

I don't know the procedure for changing what shows up on the main screen of the app, or if it's something the community even has influence over. My apologies if this has been brought up already, or there are reasons I don't know about in terms of why this can't work, or I'm discussing it in the wrong place, I just know that mobile editing is less common and less frequently brought up in discussions about supporting new contributors, so as a long time mobile editor I thought it'd be worth mentioning a pathway to better support and encourage mobile editing. penultimate_supper 🚀 (talk) 14:09, 17 October 2024 (UTC)[reply]

Pinging ARamadan-WMF, who has worked with the app teams. WhatamIdoing (talk) 19:38, 17 October 2024 (UTC)[reply]

Hello @Penultimate supper,

This is Amal Ramadan, Sr. Movement Communications Specialist with the Apps team at the Wikimedia Foundation. Thank you for your thoughtful suggestion and for sharing your editing experience with us. It’s great to hear that you find the iPad app a valuable tool for contributing to Wikipedia!

We appreciate your feedback about adding a 'Contribute' section to the iPad app's main screen or menu. Your suggestion aligns with our goal of improving user engagement and supporting new contributors. We're already working on a navigation refresh for the iOS app, and you can follow the project’s progress here:

https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Navigation_Refresh

For iPad-specific improvements, we also have an epic ticket focused on enhancing the iPad experience. You can stay updated through this link:

http://phabricator.wikimedia.org/T377283

I’ve added your suggestions to the ticket to ensure the team considers them during the iPad enhancements.

In the meantime, if you encounter any further issues or have additional suggestions, feel free to reach out through the support email within the app or ping me at any time.

-------------------------------------

Thank you, @WhatamIdoing, for the mention! ARamadan-WMF (talk) 17:16, 18 October 2024 (UTC)[reply]

Thank you! And thank you for your work, the apps are such great experiences, honestly my favorite reading experience of the encyclopedia, and a really solid way to edit. Appreciate all the work you do! penultimate_supper 🚀 (talk) 17:32, 18 October 2024 (UTC)[reply]

Limited Blackout of Wikipedia in the UK

Overview: This proposal suggests a partial blackout of Wikipedia for users accessing the site from the UK, implemented as a temporary measure to highlight concerns regarding the Online Safety Act 2023. The act requires services to adopt verification or estimation technologies and stricter measures for managing harmful but legal content, especially content accessible to children, with full enforcement expected by OFCOM in 2026.

Why Consider a Blackout? Wikipedia's first pillar is that it is an online encyclopedia with an educational mission. As such, a blackout, even when intended to educate the public about potentially harmful legislation, should only be used in the most serious of circumstances. It must be executed thoughtfully to align with our mission and to avoid damaging our credibility and reputation as a reliable educational resource.

Details of the Proposed Blackout:

Nag Page Implementation: The blackout will not be a complete shutdown but instead will present a "nag page" when UK users attempt to access Wikipedia. This nag page will:
- Display information about the Online Safety Act 2023 and its potential implications for free access to information.
- Collect user information (such as location) to show the scale of concern, but importantly, this data will not be processed or used further, respecting user privacy.
- Provide an option for users to continue to the encyclopedia content after viewing the information, ensuring they still have access if desired.
No Set Date: This proposal does not yet suggest a fixed implementation date. It aims to gather community feedback and observe OFCOM's actions as it defines the specific requirements of the act leading up to 2026.

Rationale: Wikipedia’s mission to provide free, reliable information could be significantly impacted if stringent and potentially restrictive measures are enforced without careful consideration. By adopting a limited blackout (nag page) approach, we raise public awareness while ensuring minimal disruption to access. Such a move would emphasize our role as an advocate for open knowledge and user rights while balancing our educational objectives.

Consensus Requirement: Given the potential impact on Wikipedia’s reputation and mission, this proposal seeks to engage the widest consensus possible before any action is taken. A blackout must remain an exceptional tool reserved for critical issues to ensure that it retains its effectiveness and credibility.

Comments and Feedback Welcome: Please share your thoughts, ideas, and suggestions to refine this proposal. We aim to ensure that any action taken is well-considered, aligns with our educational mission, and maximizes the positive impact for both Wikipedia and its users.

The true elf (talk) 22:29, 17 October 2024 (UTC)[reply]

With all due respect, what do you mean "our"? This is your first edit. If this is an alternate account, sock puppets are not allowed to participate in project space, so if you have a primary account, please log into that instead. Seraphimblade ^{Talk to me} 23:27, 17 October 2024 (UTC)[reply]

yeah this is my first edit I do kind of mean hour my bad. Even though I haven't edited anything directly I have made suggestions under

Furthermore, I have made edits to Wiki data, and I have a Wikipedia article that I am sorry about. I am working on it offline and will upload it at some point. 2A00:23C6:C780:4901:D52A:AFC2:3B4C:1F47 (talk) 05:42, 18 October 2024 (UTC)[reply]

WP:PROJSOCK is not quite an absolute, bright-line rule per the 2021 RFC. But do please log back in. WhatamIdoing (talk) 02:10, 19 October 2024 (UTC)[reply]

Oh, never mind—you wrote this with an AI, now that I read it again. Own words please, not a chatbot. Seraphimblade ^{Talk to me} 23:29, 17 October 2024 (UTC)[reply]

sorry about these of AI it was just using as a helpful tool to get my ideas together and formatted well I've got this severe dyslexia and it's a lifesaver sometimes. However I have read for everything and I stand by what it says I wouldn't be editing Wikipedia articles with using AI like this 2A00:23C6:C780:4901:D52A:AFC2:3B4C:1F47 (talk) 05:53, 18 October 2024 (UTC)[reply]

Well, don't edit Wikipedia like that, especially if you're making a major proposal. If you have a disability, just say so, like you did. No one would ever fault you for that, but we'd want to hear what you, not a bot, have to say. Seraphimblade ^{Talk to me} 08:02, 18 October 2024 (UTC)[reply]

I agree with the sentiment behind that remark, but the problem is that there are some people around who would fault people who have a disability, even though there is nothing they can do about it. Such people may be a small minority, but most disabled people have come into contact with some, especially on the Internet. That makes us a bit wary. Oh, and I'm totally against all blackouts - nobody should presume to speak for everyone else. Phil Bridger (talk) 16:37, 18 October 2024 (UTC)[reply]

This doesn't sound like an actual blackout. This sounds like a request for a (large) sitebanner.

(I agree with you that disclosing disabilities can trigger complaints. It can also trigger helpful responses.) WhatamIdoing (talk) 02:13, 19 October 2024 (UTC)[reply]

Warning when transcluding images of a certain size or higher

Since this happened to me on accident yesterday, why not bring it here. When you add an image to an article (specifically using source code), you may be unaware of how large that image will be when you click "publish". That's why I'm suggesting that when adding images of a certain size (let's say... 7,000 x 7,000 px or higher), before you are able to publish it will give you a warning that you are uploading images of a size that may not load properly on certain devices, so that you can maybe go back and either change the image, or something else. This diff is a really good example of why this may be needed. Sir MemeGod  15:59, 18 October 2024 (UTC)[reply]

I can see why that particular image might cause a problem, but how many others would? Do we have figures for how many images would trigger such a warning? These are genuine, not rhetorical, questions. Phil Bridger (talk) 16:20, 18 October 2024 (UTC)[reply]

I'm not sure, but I could assume that any image over a certain size could start crashing browsers, like the one I linked. I just need to find out what that size is. Sir MemeGod  16:26, 18 October 2024 (UTC)[reply]

Pretty much any image that isn't in thumb or frameless has no value. Aaron Liu (talk) 16:29, 18 October 2024 (UTC)[reply]

@Sir MemeGod: I don't see why you would want to put the full-size image into an article. You should use the |thumb parameter, and if people want to see a bigger version, they click the thumb image to reach the file description page, which not only shows a larger version, it also offers a selection of sizes to view. --Redrose64 🌹 (talk) 18:07, 18 October 2024 (UTC)[reply]

A warning can be added to the commons page, as shown on File:Van Gogh - Starry Night - Google Art Project.jpg. CMD (talk) 18:14, 18 October 2024 (UTC)[reply]

I started an edit filter request. Aaron Liu (talk) 04:12, 19 October 2024 (UTC)[reply]

Thank you, that is exactly what I was talking about, I probably just worded it badly. Sir MemeGod  23:45, 19 October 2024 (UTC)[reply]

Wikipedia has a problem with inactive WikiProjects

Hundreds of the over 2000 WikiProjects present on Wikipedia are either inactive or semi-active. Many WikiProjects overlap in scope, or are so niche that very few users have interest in participating. Even for WikiProjects that cast a wide net, some are inactive or semi-active. Historically speaking, WikiProjects were more active when Wikipedia was much younger, and we've seen more WikiProjects become inactive or semi-active.

Why is this a problem?

Having inactive/semi-active WikiProjects that overlap in scope or are incredibly niche causes confusion for editors who seek to collaborate on a topic, or seek help from others familiar with the topic. Additionally, inactive WikiProjects take up valuable shortcut real estate, shortcuts which could be used for other WikiProjects or policies.

An idea for a solution

This is where I'd like the community's feedback. It is unclear whether the outright deletion of WikiProjects is ideal, or if smaller WikiProjects should be merged into larger ones. It's also unclear if a singular solution can be applied to all cases of inactive WikiProjects.

As a personal example, there exists WP:WikiProject Vancouver, WP:WikiProject British Columbia, and WP:WikiProject Canada. Project Vancouver and Project British Columbia are both relatively inactive, with Project Vancouver being relatively narrow in scope. In this case, I believe that merging WikiProject Vancouver into WikiProject British Columbia is ideal, making it a subproject or task force. — Your local Sink Cat (The Sink). 20:09, 20 October 2024 (UTC)[reply]

Merging into subprojects/task forces could definitely be an idea – that way, we can keep the established structure while consolidating it into something easier to follow. Regarding members of the merged WikiProjects, should they automatically be added to the wider one, or just given an alert so they can choose whether to join it or not? The second option seems more natural to me.

There is also the broader question of why WikiProject activity is declining. I am far from a specialist on this topic, and wonder if specific things changed that made joining WikiProjects less practical or less useful than it was before? Chaotic Enby (talk · contribs) 20:22, 20 October 2024 (UTC)[reply]

Well the proposed parent project participants should decide whether to merge in the niche projects, if the project is completely inactive. At the top of the moribund project page, it could refer people to the relevant active project. And talk page project tagging for dead projects could be removed, or replaced by the parent project. I would say just alert former participants that are not part of the parent already. Graeme Bartlett (talk) 20:26, 20 October 2024 (UTC)[reply]

People who are active on pages don't own them. It's a courtesy to invite them to the discussion, but I don't believe they should get any more say than anyone else. Thebiguglyalien (talk) 20:32, 20 October 2024 (UTC)[reply]

The inactive projects are usually marked as historical and allowed to stays in place. Ruslik_Zero 20:39, 20 October 2024 (UTC)[reply]

A WP:WikiProject is not pages. A WikiProject is people. You can no more vote to make editors join a different group than you could tell your classmates who they were required to be friends with when you were all 10 years old.

The reason merges have to be voluntary is because that's the only way they work. We can merge, redirect, and move pages all day long, but if the individual participants don't voluntarily choose to participate in the new "larger" group, then we won't actually have a larger group: we'll have a bunch of people quitting.

I heard a joke about Church splitting (I didn't expect that to be a red link) many years ago that went like this: The church had a fight over whether the new hymnal books were to have a red cover or a blue cover. In the end, 10% of them split off to form a church with red books, 10% formed a church with blue books, and 80% of them got so disgusted that they quit going to church. Maybe this only seems like a plausible outcome if you're from the South, but we don't want any WikiProject participants to get so disgusted that they quit Wikipedia, or even just quit watching the WikiProject pages.

Consequently, we've established a procedure for voluntary merges. Basically, you make an offer and wait a month to see whether anyone objects. If anyone objects, then stop. If they don't, then merge. I'd guess that we've had objections about 10% of the time, so it rarely interferes with the ultimate outcome. WhatamIdoing (talk) 03:44, 21 October 2024 (UTC)[reply]

I think the reason why there are so many inactive Wikiprojects around is simply that nobody has bothered to do anything about them. I certainly, and probably most other editors, see that as a pretty low priority. Phil Bridger (talk) 20:50, 20 October 2024 (UTC)[reply]

I've merged a few projects I participated in due to scope overlap, including two recently, it's not even that hard to get consensus, but no one wants to bother. If there's a specific project that bothers you just propose it. PARAKANYAA (talk) 21:46, 20 October 2024 (UTC)[reply]

Merging WikiProjects comes up at the WikiProject Council talk page – the most recent discussion can be seen at Wikipedia talk:WikiProject Council/Archive 26 § Systematically merging WikiProjects. Previously. the only set of instructions was for converting a WikiProject into a task force, which might be preserving more infrastructure than necessary if the WikiProject is inactive. WhatamIdoing started Wikipedia:WikiProject Council/Guide/Merging WikiProjects as a first pass at instructions for merging a WikiProject without making it a task force. For better or worse, there is often resistance to implementing merges, as can be seen at the end of the archived discussion to which I linked. (I gave some of my thoughts on why WikiProjects might not be attracting participants in that discussion.) isaacl (talk) 21:55, 20 October 2024 (UTC)[reply]

I should get back to that page. @Joe Roe was working on a merge, and we need more template information. The TFD folks have suggested that they'll be generous with their template-replacing bots, but we need to write out a procedure for it, so people know what to do.

@Sink Cat, please consider putting Wikipedia talk:WikiProject Council on your watchlist. That's where a lot of this gets discussed. In terms of the general concept, I think we should aim for a world in which there are many fewer, but much larger (on average) active WikiProjects, but the whole thing happens one baby step at a time. The biggest challenge is that nobody is doing the work. Just reviewing 2,000 groups to produce a recommendation about how to merge them could be a full-time job for a month, and then each group has to be contacted with personalized messages to explain the idea, name the targets, and ask if they're willing. If someone wants to spend, say, 20 hours/week for the next year doing this, then that would be great, but that's the scale we're talking about. WhatamIdoing (talk) 03:55, 21 October 2024 (UTC)[reply]

Thanks for the response! I'll get in contact with them to see what can be done. — Your local Sink Cat (The Sink). 04:11, 21 October 2024 (UTC)[reply]

Not sure to whom you are referring when you say "them"? Note the word "council" is a bit misleading: it's just essentially the WikiProject wikiproject. isaacl (talk) 05:12, 21 October 2024 (UTC)[reply]

Echoing this – it's possible to get consensus for merges but it's really time consuming and slow. I know I've got a few outstanding because you have to wait 30 days after opening a discussion to action it (sensibly enough) and I'll often find that 30 days later I don't really have time to do it. – Joe (talk) 08:22, 21 October 2024 (UTC)[reply]

filter for removing closing markdown of comments?

By chance while doing some other work on pre 2006 pages, I noticed Bernard Lee, which, due to an IP editor, looked like a stub, despite being listed as a GA. I'm not really sure what the intention of their edit was but they removed part of the comment markdown, causing most of the article to be hidden. Is there some way of tagging instances of this happening via Edit filter or such? I could imagine someone maybe more malicious intentionally doing this that would otherwise probably just blank the page or remove large parts, which is already more or less mitigated by current measures. Akaibu (talk) 22:04, 20 October 2024 (UTC)[reply]

I think there are two separate things here - an edit filter to detect new edits that result in an unclosed HTML comment. I don't know whether one exists, but Wikipedia:Edit filter/Requested is the place to request this if it doesn't.

The second thing is to check for existing pages with unclosed comments, which sounds like the sort of thing a Wikipedia:Database report would be useful for, Wikipedia talk:Database reports is the place to request one.

In both cases a correctly closed comment after an unclosed one could cause false negatives, but I guess detecting  would catch those? Thryduulf (talk) 22:30, 20 October 2024 (UTC)[reply]

It may also be worthwhile to detect very big comments. But there are likely many of these deliberately inserted, so Thryduulf's idea sounds better. Graeme Bartlett (talk) 09:52, 21 October 2024 (UTC)[reply]

Related topic in phab:T304222. — xaosflux ^Talk 15:06, 21 October 2024 (UTC)[reply]

By the way, Markdown is a formatting language that we do not use. We use Wikitext. Aaron Liu (talk) 16:30, 21 October 2024 (UTC)[reply]

Ai chat bot

I have an idea of building an open source ai model trained on wikipedia available free of charge on wikipedia platform as new generations have less attention span and need to get things done fast. I want it open source so that it can be for the community and get inspired by contributors Yassinsamirhegazy (talk) 13:22, 21 October 2024 (UTC)[reply]

Hi, the contents of Wikipedia are CC BY-SA 4.0, so you can use the corpus to train an AI model if you wish to, assuming you release it under a compatible license. Regarding having it available on Wikipedia, this might not necessarily be a good idea, as AI models are prone to hallucinations, and a model trained on Wikipedia contents at a given time will not be editable like the encyclopedia itself. Chaotic Enby (talk · contribs) 13:48, 21 October 2024 (UTC)[reply]

I understand your point but this ai model can be just a start to cope up with the new generation of audience 41.46.109.7 (talk) 14:06, 21 October 2024 (UTC)[reply]

Have you considered that all of the major chatbot LLMs have already scraped Wikipedia into their corpus? Remsense ‥ 论 14:38, 21 October 2024 (UTC)[reply]

Please be aware that many Wikipedians more or less distrust AI, and some have been advocating for a ban on any use of AI in Wikipedia. While I consider a ban to be unenforceable, I would want editors to avoid using any AI without very carefully checking and correcting all output from the AI, which might well be more work than just writing content without using an AI. Donald Albury 14:44, 21 October 2024 (UTC)[reply]

Yeah, i've considered that but I want to add this feature some that people spend more time on wikipedia Yassinsamirhegazy (talk) 17:23, 21 October 2024 (UTC)[reply]

We want usefulness to readers, not engagement. Aaron Liu (talk) 17:31, 21 October 2024 (UTC)[reply]

ChatGPT, Ollama, and pretty much every major platform already did that. Aaron Liu (talk) 14:44, 21 October 2024 (UTC)[reply]

<- For interest, FutureHouse's PaperQA2 model is already matching or outperforming subject matter experts in article creation summarizing scientific topics in a very specific domain. See Language Agents Achieve Superhuman Synthesis of Scientific Knowledge. Sean.hoyland (talk) 14:53, 21 October 2024 (UTC)[reply]

Also, people (with less attention span) can already interact with Wikipedia content using the labs.google NotebookLM experiment. Sean.hoyland (talk) 15:10, 21 October 2024 (UTC)[reply]

Consensus Required Restriction and NPOV tags

I know that editors should seek to remain unbiased, but it seems on divisive topics we can end up with one side who manages to tilt the article toward their POV. We can then end up with half of the editors saying "This article is perfectly fine" and the other half of the editors saying "There are big POV issues, here they are..."

The side who are happy with the bias can actively work to prevent any fixes to the page to address the bias, while simultaneously blocking the addition of a NPOV tag to the page.

It seems that if half of the editors are saying "it's fine" and the other half are saying "there are big issues" this is extremely indicative of a POV problem even if there is not consensus that one exists.

So I'm wondering if there should be an exemption to the Consensus Required Restriction and if some sort of critical mass short of consensus should be enough to allow for NPOV tag.

Thoughts? Bob drobbs (talk) 18:48, 22 October 2024 (UTC)[reply]

Putting the {{POV}} should never be an end goal. The goal should be to fix the problem, and adding the banner frequently provides no practical benefit at all. Imagine a wildly non-neutral article about an article under the Wikipedia:Consensus required restriction. Maybe it's an article called 2+2. The article says that 2+2 is generally understood to equal four, but there is a significant minority of respectable mathematicians says that 2+2=5. Here's the story you seem to want:

Alice adds a {{POV}} tag.
Eve removes it because she disagrees.
The discussion on the talk page about the tag ends in a stalemate. Because of the 'consensus required' rules, the tag would normally not be added, but because of the newly carved-out exception, the tag can be added.
End result: The article is tagged, but it's still wildly unbalanced.

Here's the story we need:

Alice adds a {{POV}} tag.
Eve removes it because she disagrees.
The discussion on the talk page about the tag ends in a stalemate. Because of the 'consensus required' rules, the tag is not added.
Alice decides to quit worrying about the tag and start worrying about the content of the article. The regulars on the talk page can't reach a satisfactory agreement, so she takes the dispute to a relevant noticeboard or starts an RFC.

Remember: Maintenance tags are not badges of shame. They do not exist to 'warn the reader' or to formally express your disagreement with the article. They exist in a (mostly vain) hope that editors will fix the article's content. If you can fix the article's content without a tag, then everyone wins. If you can't fix an article (tagged or otherwise), then read up on Wikipedia:Dispute resolution. WhatamIdoing (talk) 19:05, 22 October 2024 (UTC)[reply]

Depends… how many are on each “side” of the debate?

If there are multiple editors on each “side”, then I don’t think we can say that a consensus actually exists (in either direction). However, if it’s just one or two disgruntled editors against many, then we can say there is consensus, and that consensus does not require unanimity. Blueboar (talk) 19:08, 22 October 2024 (UTC)[reply]

Describing Notability in plain English

The name we use for Wikipedia:Notability has long been a source of confusion. People can guess the basic concept of many policies and guidelines from the plain-English meaning of the title (e.g., Wikipedia:Reliable sources are sources you rely on; Wikipedia:Copyright violations is about violations of copyright etc.), but this one has quite a different meaning. You can have several sources that directly say ____ is a notable musician, and we'll reply that he's not WP:Notable.

I'd like to brainstorm some alternative phrases that could be used instead of "notability", or as a supplement to it, that would be less confusing to people unfamiliar with our internal jargon.

Background

From Wikipedia:Glossary:

NN, non-notable: Abbreviation found in comments at Wikipedia:Articles for deletion and in edit summaries, indicating that the article's subject is not notable enough for a Wikipedia entry. A subject is non-notable if editors agree not to have an article about this subject. Their decision is usually based on things like not finding enough reliable sources to write a decent encyclopedia article, but it can also be based on things like a desire to present a small subject as part of a larger one.
Notability, Notable: A characteristic held by article subjects that qualify for separate, stand-alone articles. A notable topic is one that "is suitable for a stand-alone article or list when it has received significant coverage in reliable sources that are independent of the subject." Note that "notability" is a property of a topic, and has nothing to do with the quality of an article, or whether an article exists for the topic.

From a recent discussion:

Words for the concept: criteria, concept, test, quality, qualities, requirements, notedness, guideline, threshold, when to create an article
Words for the result: separate article, stand-alone article, separate page, stand-alone topic, new topic, own page, article creation, article suitability, inclusion
Some specific ideas:

Collapsed list of prior ideas

The following discussion has been closed. Please do not modify it.

Article concept guideline
Article creation criteria
Article creation guideline
Article sourcing test
Article suitability criteria
Article test guideline
Article threshold
Criteria for article creation
Guide to which topics should be included as articles on Wikipedia
Guideline for when a topic should have its own article
Inclusion criteria
Is the subject written about in reliable sources?
New topic test
Notedness
Own page threshold test
Page sourcing guide
Primary notability criterion
Qualifying for a separate article
Separate article criteria
Source availability
Source depth
Stand-alone concept
Stand-alone article criteria
Stand-alone topic criteria
Stand-alone topic criterion #1 (#2, #3, etc.)
When to create an article

Feel free to expand the box if you want to see some of the prior ideas. It's collapsed because some research on brainstorming ideas suggests that looking at other people's ideas can reduce the total number of ideas shared. Duplicates are fine!

Your ideas (“notability”)

Please share your ideas here. Even a 'bad' idea might inspire the next person to think of another option. WhatamIdoing (talk) 21:04, 22 October 2024 (UTC)[reply]

I had also been thinking about this. The core issue, in my opinion, is that we're trying to describe as "notability" something that is closer to "for someone/something to have an article, they should be well-documented in reliable sources". At its core, the term "notability" carries more of a connotation of relative importance, leading to a lot of newcomers, and sometimes even other users, being misled as to what makes a topic notable. On the other hand, the actual guidelines describing it focus on the existence of reliable sources about the topic, with importance only being used by some guidelines as a proxy for these sources being likely to exist.

A word like well-sourced or well-documented would carry this idea better, without the a priori of "importance/fame is what matters" that "notability" carries. Chaotic Enby (talk · contribs) 21:13, 22 October 2024 (UTC)[reply]

Lots of topics are documented by primarily primary sources (eg like many news event), but we require coverage by secondary sources, so those would worsen the situation. — Masem (t) 21:20, 22 October 2024 (UTC)[reply]

Good point, although it could still be a first start, and no word can fully convey our notability guidelines either. Maybe encyclopedically sourced could help convey the fact that not any source works? Or, as you employ the term "coverage", we could make the difference between (primary) documentation and (secondary) coverage and call it well-covered? Chaotic Enby (talk · contribs) 21:27, 22 October 2024 (UTC)[reply]

Chaotic Enby: I am still chewing over all this. I fear that encyclopedically sourced could be easily misunderstood and potentially lead to more newbies trying to cite Wikipedia itself. I really don't have a sense of how well people outside Wikipedia and academia understand the distinctions between primary, secondary, and tertiary sources. I think well-covered does capture the essence of what we're trying to convey without causing more confusion. — ClaudineChionh (she/her · talk · contribs · email) 23:42, 22 October 2024 (UTC)[reply]

I'd say that people outside the wiki-verse and academia understand primary/secondary/tertiary "not at all", and I'd say that people in the wiki-verse understand the distinction "poorly". Editors struggle with WP:PRIMARYNEWS, especially when it comes to the question of notability ("But event is obviously important, so obviously this breaking news article is secondary"), and most of them could not explain why Wikipedia:Secondary does not mean independent. WhatamIdoing (talk) 00:17, 23 October 2024 (UTC)[reply]

Masem, the GNG requires secondary sources, but NPROF does not. Both are still wiki-notable. We therefore need a handle for this concept that does not assume the GNG approach. WhatamIdoing (talk) 00:13, 23 October 2024 (UTC)[reply]

I like “When to create an article”. SmokeyJoe (talk) 21:22, 22 October 2024 (UTC)[reply]

I caution against this because as it is used now, notability is not used as a check at new page review, and primarily is a method used for evaluating whether to delete an article at AFD. We should have an advice page with that title about how to make sure you have a good topic and reviewing the notability of the topic is a good starting point as part of it. — Masem (t) 21:35, 22 October 2024 (UTC)[reply]

So "When to have an article"? WhatamIdoing (talk) 00:18, 23 October 2024 (UTC)[reply]

“When to have a separate article”?

A nod to WP:Structurism as an existing concept. Also a hint that newcomers should add content to existing article, and no be trying to add a new orphan topic as their first contribution.

- SmokeyJoe (talk) 02:12, 23 October 2024 (UTC)[reply]

I'm inclined to something like "stand-alone topic criteria" (to clarify that the point is determining whether a topic warrants a stand-alone article) or, in a similar vein, "when to create an article" (or possibly "when it can be appropriate to create an article", since in occasional cases it can be appropriate to cover a small number of closely related topics that could be notable in the same article rather than separately). I do agree with the notion that notability isn't the best name for this guideline and that having a term that's more like plain English. Hydrangeans (she/her | talk | edits) 21:26, 22 October 2024 (UTC)[reply]
I like "stand-alone article criteria" as it is focused on when to create an article. --Enos733 (talk) 21:28, 22 October 2024 (UTC)[reply]
Maybe something like suitable topics or suitable article topics would work. That implies the existence of editorial judgement and that some topics simply aren't suitable. User:Chaotic Enby, this was inspired by your idea of "well-sourced", which has the potential to be confused with well-cited (i.e., the number of refs in the article right now, rather than the number of sources in the real world). WhatamIdoing (talk) 00:21, 23 October 2024 (UTC)[reply]
From all the suggestions so far, this seems the most understandable so far. It's short, it communicates that some things are excluded and that there is 'judgement' involved. —TheDJ (talk • contribs) 09:46, 23 October 2024 (UTC)[reply]
I really like this, because (1) it removes the emotional pain of being deemed "not notable", and (2) it avoids the confusion we currently have of subjects that are notable but about which we cannot have a meaningful article. To clarify: (1) AfD and Teahouse waste a lot of time trying to explain to upset people that Wikipedian notability has nothing to do with importance, creativity, or future value to humanity. We could save a lot of trouble by focusing on the objective need for sources rather than the subjective view of importance. (2) Notability is currently only half of the two tests we need to pass: We can't have an article unless the subject is notable and someone's written something about it for us to summarise. We have a lot of guidelines that say "XXX is generally considered notable", which result in unexpandable stubs because although it can be demonstrated from primary sources that two old ladies and a chicken once lived near a railway siding in Ohio (making it a genuine inhabited settlement), there is now nothing there, and no one has ever written anything about it, or ever will. Focusing on what is necessary to create an article would cut to what actually matters, practically, rather than getting tied up in legalistic debates about what constitutes a notable thing. Elemimele (talk) 16:14, 23 October 2024 (UTC)[reply]
But all too often, we get the argument that we should have an article on XXX because sources exist, even though no one has demonstrated the existence of such sources. Attempts to add the requirement that reliable sources must be cited to create or keep an article have been repeatedly rejected. I would support replacing "notability" with something like "specific topics are suitable for articles if they are well-sourced, NPOV, and meet certain broad topic requirements (i.e., replacements for SNGs)". Donald Albury 17:32, 23 October 2024 (UTC)[reply]
@Donald Albury, do you mean that topics are suitable/notable if they're neutral, or do you mean that articles are suitable/notable if they're neutral? I'm not sure if you mean that you want to repeal WP:NRVE and expand the deletion policy to say that a (deserved) {{POV}} tag is grounds for deletion, or if you mean that citing sources in a neutrally written article must be possible, even if it hasn't happened yet (including for many years). WhatamIdoing (talk) 17:44, 23 October 2024 (UTC)[reply]
I was just trying to express that availability of reliable sources is required, but not sufficient, and that other policies and guidelines also must be met for an article to be suitable for inclusion in WP. Donald Albury 18:30, 23 October 2024 (UTC)[reply]

I do like suitable much better than notable (and came here to suggest it). It's more accurate, but still gives some flexibility in definition, where something like well documented might be open to misinterpretation / lawyering. Folly Mox (talk) 17:50, 23 October 2024 (UTC)[reply]
Suitable / Suitability is the first suggest I like, it helps show that this is a Wikipedia stand not a general idea. -- LCU ActivelyDisinterested «@» °∆t° 20:23, 23 October 2024 (UTC)[reply]

Thanks a lot! I do very much like suitable topics (suitability?) too, as it is broad and flexible enough to cover our various policies on the topic. Chaotic Enby (talk · contribs) 19:26, 23 October 2024 (UTC)[reply]
Just to throw out an idea that I think can minimize disruption, is to consider a comparable situation to the relatively recent rename of of the old Naming Convention page to WP:Article Titles while specific advice of naming for various fields are still at "Naming Convention". In that same vein, if the GNG was moved to its own page (thus sitting alongside the sepearate SNG pages) and what's left at WP:N left there, then renaming that leftover to some of the suggestions above would still allow us to keep the principle of notability via the GNG and SNG while having a better landing page at a more familiar term and to explain the GNG and SNG functions within that. It would minimize a mass edit on p&g pages. The GNG and SNGs can be described as tests used on Wikipedia to measure how notable (real world definition) a topic is within the suitability on an encyclopedia. Masem (t) 18:11, 23 October 2024 (UTC)[reply]
There might be some advantages to splitting the GNG out onto its own page, but I think that might need to be a separate discussion. WhatamIdoing (talk) 18:36, 23 October 2024 (UTC)[reply]
Well, in terms of providing g a word that is closer to the real definition for our practice related to when a topic is suitable for it's own article, treating the existing idea of notability through the GNG and SNGs as is and focusing on a clear word for the broad concept is a clean solution. Masem (t) 19:39, 23 October 2024 (UTC)[reply]
The issue is that GNG is about how well-documented the topic is in independent secondary sources, which doesn't necessarily map to real-world notability, and using the latter word for it has been just as much source of confusion. Chaotic Enby (talk · contribs) 19:45, 23 October 2024 (UTC)[reply]

Timeline of significant figures

While many people have made contributions to history (many more than could fit in one timeline), it's undoubtable that some people's influence far exceeds that of others.

Therefore, I think we should have a timeline of the significant figures in history.

I completely understand that determining how significant some people are is a difficult task. It's expected to take struggle and effort to make this work. However, people deserve to know who made the greatest contributions to the advancement of humanity.

Also, many scholars themselves have written about who they believe are to be the most significant people.

I have created a sketch of this idea at User:Wikieditor662/sandbox. It's far from perfect, but you get the main idea. The people are colored based on the era they were in. The most significant people make it to the overview and those who are not as important but still nonetheless significant (as well as people born earlier so the overview doesn't get clumped) go to the individual timelines (below the overview) along with those in the overview.

I would again like to reiterate that this is something that is going to take effort, dedication, and much debate, but if we do this, then I think it could be worth it. What do you all think?

Wikieditor662 (talk) 20:34, 23 October 2024 (UTC)[reply]

Kindly, I'm experiencing philosophical opposition to this project. History has been a team effort, and further elevation of the already elevated is not likely to improve genuine understanding of historical processes. The Great man theory correctly fell out of fashion early last century.

Having said that, I don't mean to dissuade you from undertaking a project you're clearly interested in, and this seems like it could serve as some kind of subpage of WikiProject Vital Articles. Using the inclusion criterion "listed at WP:VA" is probably the only way you'd ever develop any kind of agreement as to which historical figures to include. That WikiProject has already done a lot of debating over which topics are more important than others.

The periodisation scheme is pretty parochial and Eurocentric, and would have to be converted to numeric year spans or whatever schema WP:VA uses (and the section headings would have to be delinked per MOS:NOSECTIONLINKS). You'll also want to consider how to handle cases where vital dates are approximate, unknown, disputed, etc. Folly Mox (talk) 00:12, 24 October 2024 (UTC)[reply]

I would tend to agree with Folly Mox on this. I'll add that it might be pretty much impossible to find an actual inclusion criteria, that is, any kind of consensus in reliable sources as to who is a significant enough figure – or even if we can compare the significance of historical figures across times, cultures, and domains. If anything, that page will inform more about our own selection than about any historical truth behind it.

However, having it as part of WP:VA, rather than as an encyclopedic article, could make it a pretty useful reference for articles about famous figures needing improvement, without claiming that these are necessarily the most significant ever. Chaotic Enby (talk · contribs) 01:07, 24 October 2024 (UTC)[reply]

Auto-amending bare URL tags

Is there any reason we aren't or can't scrape and extract basic cite template information (webpage title, domain, visited datetime) at submit-time from bare URL <ref>s? Personally, I use bare URLs all the time as I consider filling out the cite template the most emphatically tedious part of editing WP (as it is when writing scholarly manuscripts) and know that some robot editor will just come along and fix it for me anyway. Since the code already exists and could be done more efficiently server-side, why don't we just pull it into the WP core? Just a small and probably extant idea I had while feeling a little guilty for adding a bare <ref> to a nicely-formatted article with proper tag attributes and template use. Cheers, fellows. Elliott-AtomicInfinity (talk) 01:38, 24 October 2024 (UTC)[reply]