This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.
Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).
Policy
Starting a compilation of Wikipedia policies
I took long hours to condense core content policies into one document. By my calculations, I can retain at least 95% of the meaning of the policies, including most of their intricacies and details, by using only about a third of space that the policies and guidelines, scattered among multiple pages, now take (I estimated from raw text that the policies and guidelines I summarised have about 530 KB of raw text but under the compilation have just 173 KB - still a lot but much better).
It was a hard task and appears about as hard as working in one person to recompile the Constitution of Alabama - a ridiculously long document running at 373K words - 420K words before 2022 (for comparison, War and Peace is 587K words, and there's a good reason they publish it in volumes), but I think it is more than worth it, as people will have a unified set of policies that will be easier to read for people because there's gonna be much less of that but reflecting the same meaning. The overabundance of policies is one reason we have few new editors - there are too many rules, and then folks just randomly throw WP or MOS shortcuts not immediately obvious to the bystander, and suddenly nobody wants to join a project with United States Code-long rules and obscure jargon.
I will appreciate all feedback from you - positive or negative - and preferably some help into condensing further policies and guidelines, such as those about conduct, legal, editing etc. into one page where everything belongs.
I wish you well in your endeavour, but am worried that it will fail in the end because everyone thinks that "their" sub-sub-clause is vitally important. I admit that I rarely look at policies or guidelines now, but find a few basic ideas, along with common sense, to work. Phil Bridger (talk) 12:14, 22 August 2024 (UTC)[reply]
That works for me as well (I normally look into the rules on an ad hoc basis), but then you wouldn't need all those volumes of tiny rules covering, like, 99% of cases, and yet here we are. Also, admins themselves need a clear set of rules for proper enforcement (even if you catch the gist that the persob is just NOTHERE - an essay btw - you still kinda need a more concrete reason that just "that's my hunch")
It's like with RL: pretty common-sense that you shouldn't kill or rob anyone, or what appears common-sense like not using the army or the government to finance/securre your own reelection campaign, and yet these are codified lest anyone have an idea to bend the rules. Szmenderowiecki (talk) 17:29, 22 August 2024 (UTC)[reply]
This exists WP:Nutshell and I think your effort is noble but better focused on improving accessible language and navigation of existing guidelines for newcomers. Twinkle has feature to welcome new users for example. WP:Mentor finds ways to automate assisting newbies. ~ 🦝 Shushugah (he/him • talk) 12:47, 22 August 2024 (UTC)[reply]
Just to pick one example. There's no policy that an article must have (any) sources, let alone one. Yet we consistently advise new users to create articles with multiple sources. Save the edge cases and careful readings of guidelines/policies for advanced users who want to push the margins or change consensus. ~ 🦝 Shushugah (he/him • talk) 12:49, 22 August 2024 (UTC)[reply]
Actually there very much are two policies that prohibit articles without sources:
Verifiability says that you should only add content that you can check against a reliable source, and that you can remove any unsourced content
No original research says you just can't make stuff up. The only way you can have some sort of content is if it can be supported by a reliable source. Technically just have to demonstrate that the source for the passage is somewhere but if you don't provide it in the article, you can totally expect it to be removed and it's gonna be your problem.
No, policy prohibits unverifiable articles, not unsourced articles. Sources are required for BLPs and anything that is likely to be challenged should include a source (but this doesn't have to be inline). An article List of uncontroversial statements of fact consisting of things like "The sky is blue", "Many people are Catholics", "The 1970s happened before the 1980s", etc could be completely fine (it would be deleted, but for reasons completely unrelated to not having sources). Thryduulf (talk) 17:28, 22 August 2024 (UTC)[reply]
Look, I'm not making this up:
Any material lacking an inline citation to a reliable source that directly supports[b] the material may be removed and should not be restored without an inline citation to a reliable source
Which de facto means that if you are adding unsourced content, you are wasting your time as any editor may come by and just remove what you wrote, tell you "lacks an inline citation, I don't care why, pics or it didn't happen" and you are gonna still default to having to add a source (and then again giving time to fix it is a courtesy you needn't, though probably should, extend; though if you have the means to fix it yourself, you should do it)
So there's no obligation to source an article only in the most literal reading of policies. Anyone can enforce this policy provision. WP:SKYISBLUE is just an essay, although one with a pretty large following (and which totally makes sense for me, which is why there is a footnote to that effect) Szmenderowiecki (talk) 17:47, 22 August 2024 (UTC)[reply]
... any editor may come by and just remove what you wrote ...: the operative word is may. The reality is there's loads of unsourced text on WP, much of which will take years for it to be challenged, if ever. —Bagumba (talk) 18:29, 22 August 2024 (UTC)[reply]
It has been tried before. Take a look at Wikipedia:Attribution, an attempt 18 years ago to consolidate some policies. Some very active and well regarded Wikipedians put a lot of time and effort into that proposal, but it was rejected by the community. Consensus can change, but I suspect the community remains just as resistant to change as it was then. Donald Albury20:07, 22 August 2024 (UTC)[reply]
So I did read the poll, and a lot of stuff that was probably relevant here doesn't apply:
Users were complaining about lack of participation/that proposal being forced down their throats as policy - not an issue here (yet)
Merger of NOR, V, RS didn't appeal to people - not abolishing them, just giving sections to these concepts, not a problem.
Users complained about one massive page, or that they preferred separate policies rather than a massive policy code - well that is an issue to discuss but again it's not something that should extinguish all debate before it even starts.
Disgusted that truth is deprioritised - kinda not applicable here, because I'm not changing the framing of policy, just condensing it.
Change is unnecessary - again, debatable but let's have that debate in the first place
WP-links - well, you will have them all you like. Again, something to be discussed.
Assessment of any changes and their impact on disputes - to be discussed, again. This is how rulemaking process should work.
"If it ain't broke, don't fix it" - my whole point is that it is, in fact, broke, so needs fixing.
And again, you can say "meh, we tried eons ago and it didn't work, why bother anymore" but that's gonna be a catch-22, because nothing will change without discussion, which you don't want to hold anyway.
I believe the attitude should be "OK, let's see what you did there and if it makes any sense". It would be another thing if you told me why what I did was bullshit, which is fine. Szmenderowiecki (talk) 18:45, 23 August 2024 (UTC)[reply]
I know, but that's not the point of the compilation. What you are pointing to has a different purpose.
Nutshell, WP:5P etc. is a post hoc summary of policies and guidelines that summarise the main goals in slogans. Just like a company saying "we want to increase the market share; we want good treatment of workers" but not saying how.
WP:SIMPLE is a very high-level summary of policies and guidelines. It's the company analogue of saying: Good treatment of workers means paying more than the minimum wage, giving them extra breaks, paid leave and some other perks, without telling much specifics.
The body of the policies and guidelines is like all internal company directives about pay grades, conditions of getting worker benefits, levels of compensation, powers of HR/executives etc. This page intends to clean up all this body of policies and codify them in a couple of places, grouped by category, so that we remove unnecessary bloat, as in too many redundancies and passages repeated across different policy pages, extraneous comments etc.
@Szmenderowiecki, I don't feel like you're hearing what people are telling you, so l'm going to try a completely different, un-Wikipedian way of explaining this, because the previous efforts haven't worked, and maybe this will get your attention. Here's my new way:
Hi, Szmenderowiecki, and welcome to Wikipedia! I see you've been editing for just four and a half years, and that you've made a few hundred edits at Wikipedia:Reliable sources/Noticeboard, which I really appreciate. I don't know if you knew this, but you're in the top half a percent of contributors for all time. I also notice that you've never edited a single policy, and you have only made one small, uncontroversial edit to a guideline.
Just so you know, most of the people who have responded to you in this discussion have been editing for 15 to 20 years, and have made between 50,000 and 170,000 edits. Also, relevantly, we've been much more active in developing Wikipedia's policy and guideline ecosystem. If you'd like to see an incomplete overview of my own policy-related work, then you can start at User:WhatamIdoing#Policies and guidelines you can ask me about.
Now that you understand who's at the table for this discussion, I want to point out that there is an English saying that fools rush in where angels fear to tread. Every person in this discussion has more experience than you, and every single one of them thinks that, even though your goal is laudable and praiseworthy and at least partially shared by everyone here, your approach is not likely to be successful. It is, of course, possible that you know better than any of us and that rushing ahead is a great idea, but I suggest to you that it is unlikely that all of us are wrong in urging caution and small steps.
If you think you could slow down and get some more experience, and if you're willing to consider doing this over the space of years, then I think we could help set you up for success. For example, if we implemented this idea, that would get about 300 words out of a policy. The next step is to write a good RFC question. If you're interested in this, you could get some practical experience by helping out. WhatamIdoing (talk) 22:26, 23 August 2024 (UTC)[reply]
I don't know if you realise it, and I guess you didn't mean it, but the comment has a very strong patronising "you are too young to understand" vibe which I have a hard time shaking off rn.
I asked you for specific input in opinion and help, and I just think the folks who suggested Nutshell etc. misunderstood my intentions. I apologise if I wasn't clear. My intent is to retain the same scope and level of detail but in fewer words.
If what you meant is to do it in increments, fine, that's an option, still I'd love some feedback if I fucked up with the text in the first place. That is valuable. I'm open to discuss it one-by-one. I will hear input from people who actually drafted policies. That was what I intended to do anyway. Szmenderowiecki (talk) 23:30, 24 August 2024 (UTC)[reply]
You've dropped things, rearranged things, and changed things, and I suspect you have done this without knowing what effects any of that will have.
For example, you've added the word secondary to the WP:GNG, and swapped in a description for the WP:SIGCOV language:
Original: "A topic is presumed to be suitable for a stand-alone article or list when it has received significant coverage in reliable sources that are independent of the subject."
Yours: A topic generally may have a stand-alone article or list when several reliablesecondary sources that are independent of the subject address the topic directly and in detail, so that editors do not have to resort to original research.
I've been trying to get a definition of SIGCOV for years (and years), and failing repeatedly because nobody wants to admit how long (or, perhaps more precisely, how low) "in detail" actually is, for fear that some "unworthy" subject might deliberately seek a qualifying level of independent media coverage. The NOR line in the GNG is basically worthless, and AFAICT removing it would have no effect whatsoever on AFD outcomes, but the fear of making changes to such a high-visibility sentence will likely prevent us from fixing that. Your [e] footnote requires a huge amount of work (e.g., primary sources aren't always about events, sources don't have to adhere to the neutral point of view, a smaller number of high-quality sources is not automatically less indicative of notability than a large number of worse sources).
At the time we started leaning on secondary sources (about 15 years ago), we had a lot of editors who thought that secondary was a fancy way to spell independent. You have added a requirement for secondary sources that does not actually appear in the GNG statement (though it is in the explanations). The GNG offers a conditional rebuttable presumption, which you have turned into a statement of permission (may/are allowed to have...). The GNG says that multiple sources are only "generally expected", rather than required, and you have changed that. Oh, and "several" is often interpreted, at least in American English, as meaning "four" (a=one, a couple=two, a few=three, several=four), whereas the GNG is usually looking for "two".
Among the things you haven't resolved is whether the sources for an article must be considered in isolation. For example:
If I have ten brief independent secondary sources, is that multiple+independent+secondary+SIGCOV, or just multiple+independent+secondary and no SIGCOV?
If I have SIGCOV in a very lengthy, extremely detailed independent primary source, and I have a non-SIGCOV secondary source, does that add up to multiple+independent+SIGCOV+secondary and therefore notability overall, or do I have to get all three key qualities (independent+secondary+SIGCOV) in each source separately?
@Szmenderowiecki, just so you know, I'm always going to be interested in this. If you want to talk about how to improve our written policies and guidelines, then feel free to drop by User talk:WhatamIdoing and tell me about your ideas. It doesn't matter to me if that's that's next month, or next year, or next decade – I'd be happy to hear your ideas whenever you want to share them. WhatamIdoing (talk) 23:19, 25 August 2024 (UTC)[reply]
OK, I'm finally back after fixing my phone with 2FA, I will respond to your suggestions above on the user talk page. It will be there in an hour or two. Szmenderowiecki (talk) 19:31, 7 September 2024 (UTC)[reply]
If anything, the project would benefit from more "fresh eyes"—editors with enough experience to speak somewhat intelligently about these issues, but without so much experience that they are heavily invested in the status quo. There is a strong, almost indisputable case that current PAGs are far too convoluted and complex for the project's good. As a practical matter, the core problem is that the self-selected self-governance model, which created the problem, is incapable of addressing it. Resistance is futile; hence my semi-retirement after about ten years of futile resistance. ―Mandruss☎02:54, 25 August 2024 (UTC)[reply]
I would add that it's useful to hear from editors who still remember their first few edits, because a sentence that makes sense to the "old hands" isn't necessarily any good for the majority of editors. An actual majority of editors has made five or fewer edits, total, ever. WhatamIdoing (talk) 03:02, 25 August 2024 (UTC)[reply]
It might be "useful" in supporting the position that current PAGs are far too convoluted and complex for the project's good (but I think that's self-evident). As for fixing the problem, not so much. Incremental change is never going to be enough; what's needed is massive overhaul, and that's just not going to happen under the current model. Meanwhile, the current model is sacrosanct. ―Mandruss☎04:45, 25 August 2024 (UTC)[reply]
I'll confess that I rarely look at the written policies & guidelines, & mostly use them as a citation when I need to emphasize a point to another editor. I consider what they say is basic common sense, but I've been around so long that I've probably internalized all of the important points. (This is not to say that the original poster is wasting their time. The written policies & guidelines have been considered a mess for countless years.) -- llywrch (talk) 01:49, 26 August 2024 (UTC)[reply]
This is part of the reason why English Wikipedia's guidance is sprawling: a lot of additions get made because a situation arises, some people say "we should have a rule for that", it gets added with a shortcut used for jargon, and editors brandish it in future discussions. As I've written before, it would be better to address problems without creating new specialized rules. But in English Wikipedia's current decision-making environment, there is little appetite to delegate to a working group to more effectively rewrite any pages. Amongst those who like to discuss these matters, there are enough editors who want to be able to weigh in on each sentence that it's hard to modify existing guidance pages, and instead we accrete more. Writing well is hard; writing well in a group is even more so. The irony of a crowd-sourced web site is that crowd-sourcing works best for making incremental changes, but consumes a lot of editor time in discussion for larger-scale changes. Which is why the path of least resistance for modifying guidance pages (and articles too) is to add a few sentences, rather than rework the pages. isaacl (talk) 23:22, 26 August 2024 (UTC)[reply]
As a new editor, adopting this would help me contribute more effectively. I would cautiously suggest that it seems like people know too many abbreviations. Support ForksForks (talk) 22:08, 26 August 2024 (UTC)[reply]
And we use different WP:UPPERCASE for the same page/section, sometimes resulting in one editor claiming that "WP:PAGE" supports his view and the next saying that "WP:SAMEPAGE" requires the opposite, and neither of them realize that they're talking about the same page. WhatamIdoing (talk) 00:35, 31 August 2024 (UTC)[reply]
I don't see any substantive argument that our current P&G structure / the ability for users to peruse it is actually problematic. It should be telling that those editors generally seeing potential in this are relatively new, and those who don't are relatively experienced. That's not (just) survivorship bias, that's experience indicating that what is perceived by some newer editors as a pedagogical issue is (as stated above) actually just the inherent difficulties in learning how to do something conceptually multifaceted and difficult.
Editing is just hard intellectually and socially, and there's no shortcut to becoming familiar with it to be found in compiling one huge document people will not be able to digest immediately versus having several documents. Remsense ‥ 论22:18, 26 August 2024 (UTC)[reply]
I agree with the inherent difficulties in learning how to do something conceptually multifaceted and difficult, but I believe there are more effective and efficient ways to communicate the PAGs than our current structure. I also believe it is pretty much impossible to replace the current structure with a more effective one, having seen what it takes to add a sentence to a policy. Schazjmd(talk)23:32, 26 August 2024 (UTC)[reply]
I think there are substantial improvements that can be made throughout each policy, or even refactoring involving multiple policies, but I think on the broadest level the modular P&G structure has no actual downsides—this isn't Justinian's code. Remsense ‥ 论23:36, 26 August 2024 (UTC)[reply]
Remsense No, and neither was that my point. The whole structure remains modular, just the modules are larger. As in, when you open a typical English textbook for foreigners, you have six books (A1-C2), each having 8-12 units.
Right now you have a separate page for every unit. I propose a separate page for a whole book, and all units get codified in one book.
So no, it's not gonna be one mammoth document, but maybe 5-8 big ones. Again, not even touching the Manual of Style.
That is more or less the reason why civil law countries have law codes. Instead of the law being scattered around 20-30 acts, you have a big one, but it resolves like 90-95% of cases. Any additional laws just build up on the codes. And even for American folks, the United States Code is sorted into 53 titles, and that organisation is in some sense not unlike that of civil law codes.
The downside is that yes, you get a tl;dr document (if you need the short story, WP:SIMPLE is indeed what you are looking for). The upside though is that you actually don't have to repeat parts of other policies in other places. Note how WP:V repeats a lot of RS because without it, V would kinda fall apart. Or how WP:OR has to remind of "related policies". Look at any subject-specific reliability guideline - depending on the size, up to half of it is copypasta from WP:N, and the only reason, apart from making the PAGs internally structurally sound, is to try to show that the policies are interconnected. In that large document, the one thing that connects all these policies is at the very top: why we need them. Because right now it's scattered all over the place. Other than that, the idea is to avoid redundant repetition. Szmenderowiecki (talk) 19:49, 7 September 2024 (UTC)[reply]
No, because a navigation template, either the one at the top or at the bottom - not sure which you refer to - is not intended to answer what the policy says, only shows you the way to actual policies. It's just a signpost, and it should stay that way. Very useful, but are not the thing I propose.
Why do we need to start a complimentary, high-complexity codification of documents which are already all in the exact same place? Again, this isn't Justinian's code, it's simply not the case that policies are "scattered all over the place".Remsense ‥ 论20:45, 7 September 2024 (UTC)[reply]
It is not "complimentary", it is intended as a replacement. And I'd say the current system has way more complexity because you need a hundred pages or so, a couple of FAQs, explanatory essays that sometimes define scopes of guidelines (see WP:BIOMED) and a couple of essays that de facto have the force of a guideline.
And what's the "exact same place" anyway? I can think of no one such place other than a navigation template, and it's simply not good enough, because duplicating the same thing has numerous downsides. a) slightly different text will be interpreted slightly differently, and it's not like wikilawyering will disappear anytime soon, b) maintaining two instances of same text is harder than maintaining one, c) after a change on page A there may appear a contradiction either with same copy of policy on page B or with a different rule on page C, which the community may simply not notice at first.
And if you think there are substantial improvements that can be made throughout each policy, or even refactoring involving multiple policies, why haven't you proposed that yet? Like a rewrite of V or N or whatever? Szmenderowiecki (talk) 21:39, 7 September 2024 (UTC)[reply]
About WP:OR has to remind of "related policies": I wonder if we should pull that. It makes the pages longer and introduces some confusion (e.g., if someone cites WP:THISPAGE for a rule that actually belongs to WP:THATPAGE, but happens to get mentioned in WP:THISPAGE). WhatamIdoing (talk) 23:29, 8 September 2024 (UTC)[reply]
I'm all for condensing our guidance down where possible, but I have to agree with Remsense – I'm not sure the goal should be putting absolutely everything on a single page.
There are quite a few policies and guidelines which the average editor doesn't really need to understand in detail unless they're editing in the particular area where it applies. For example, you've included our guideline on reliable sources for medical topics in your compilation, but I'd say that's not a guideline every editor needs to know in detail. For the average editor, it's probably enough to know "medical topics have stricter standards on sourcing, and if medical topics ever come up in my editing there's a page out there I can consult for more information". I don't see the benefit in trying to squeeze the details of that guidance onto a single page together with every other policy.
Sometimes there's a good reason for guidance to be extremely detailed or unusually attentive to particular wording. Our notability guideline for companies comes to mind – it goes over what sourcing does and doesn't demonstrate notability in pretty exhaustive detail. But the details are there for good reason – there's a lot of bad actors out there who manipulate the system for commercial interests, so we need to be unusually strict and explicit about exactly how to determine notability.
Of course, there's still a lot of cases where these caveats don't apply and we really could condense things down without losing much. My advice would be a more targeted approach: rather than condensing everything at once, work out where the low-hanging fruit is and push for changes there. – Teratix₵13:11, 28 August 2024 (UTC)[reply]
Or rather, do you mean, the response to the proposal has reminded you of "On Exactitude in Science"?
The notion that one condenses a vast network policies to a simplified reference document, a map if you will, is well-founded (and as others have pointed out, a similar concept exists already in explanatory essays WP:Nutshell and WP:SIMPLE). Many objections posted here seem to be that currently the simplified essay does not accurately represent every single paragraph of every single policy accurately.
Fwiw, I think a complete from-scratch attempt at simplified reference document every few years, to be measured against whatever already exists, is a good thing. As people choose to direct new editors to one version or another, or as new editors opine on one or another, maybe something appears completely superior. Or not -- we have a bunch of independent ways of presenting the basic P&G. Currently you can choose to link from between 5 or more independent general editing tutorial portals for newbies (WP:NEWBIE, Help:Introduction, Wikipedia:GLAM/Beginner's_guide_to_Wikipedia, WP:MAN, etc.).
An explanatory essay is not new policy, and as long as it is in userspace it does not require consensus. I frankly think some of the behavior so far has been disappointing to the spirit of VP: when someone asks for feedback on a work in progress here, then we should at minimum be constructive. (And to be sure: any feedback with a tldr of "don't do this" or "nobody wants it" or "put your effort somewhere else" is the opposite of constructive.) SamuelRiv (talk) 20:59, 4 September 2024 (UTC)[reply]
Just for clarity, what I would mean by "simplified" in this case is not "this is the TLDR version" - you have pointed to enough of that but "this is the new comprehensive version, essentially same content, but we completely reviewed the text and made it clearer, shorter, neater, better organised etc.", with a dollop of advice from WP:POSA and a sprinkle of other advice about concise writing. Other than that, I agree. Szmenderowiecki (talk) 20:13, 7 September 2024 (UTC)[reply]
I guess I'd suggest to just keep your presentation delicate for a while. Presenting as an alternative/better tldr version might be received more openly, since you've seen the reaction here when talking about a total conceptual rules overhaul.
In evaluating the quality, since many P&G are separated into pages with separate Talk sections, you might take one section of your draft you think is pretty refined and present it to one of those pages to get feedback on whether it makes sense as a concise version, then make adjustments from there. Everyone here is aware of WP:Bloat, so after doing the refinement, go back to the section Talk page and say at some point, "what if this entire page were replaced with just this, would it break anything?", you might get a better feel for what's possible. SamuelRiv (talk) 21:58, 7 September 2024 (UTC)[reply]
The problem is, tl;drs are already there, and xkcd covers creating "this one tl;dr that solves everything" well. So I don't want to go that way.
As for your suggestions, I may be subjective in what I believe is refined, but let's try that. Just choose what you believe is the best summary out there. Just not the one that has cross-references to other policies in the text, because folks will cry wolf and claim that it's absolutely essential to understand the policy. Szmenderowiecki (talk) 22:25, 7 September 2024 (UTC)[reply]
In the news
I enjoy reading the news in the "in the news" section of the home page of Wikipedia. It has the kind of hard news I like: tornados, earthquakes, fires, hurricanes, etc. from around the world.
But new stories don't come out very often. The current "cycling" item is now 10 days old.
Can't we get a top story each day? Ifyoucrydon'tlose (talk) 20:06, 28 August 2024 (UTC)[reply]
There are some nominations in the queue (see WP:ITNC) but these haven't been posted as they either haven't found to be appropriate topics for ITN to feature, or the article lacks the quality needed to be featured on the main page. As WP is not a newspaper, ITN should not be considered as a news ticket and we don't have an obligation to keep fresh stories there. Of course, more nominations for stories that meet the criteria can always help, but it should be forewarned that there is usually a high bar related to significance of the stories to be posted. — Masem (t) 20:17, 28 August 2024 (UTC)[reply]
Discussions at In the news are largely composed of a group of regulars who have their own ideas about what is "significant" enough to be posted to the main page. I largely avoid ITN because my one experience attempting to nominate something there was extremely frustrating and I don't think it's worth wasting my time updating articles with breaking news stories that editors will randomly find "insignificant" for idiosyncratic reasons. voorts (talk/contributions) 21:42, 28 August 2024 (UTC)[reply]
Its primary purpose is to point readers to Wikipedia articles that discuss the people, places and events that are in the news. These articles will (ideally) give readers the background information to better contextualize and understand what they read/see in news media. Blueboar (talk) 12:30, 29 August 2024 (UTC)[reply]
That's a good description and I thank you for that.
One small note: If you hover over and click on "Ongoing", you can get a list of previous items.
It is highly subjective whether an event is considered significant enough, and ultimately each event should be discussed on its own merits. The consensus among those discussing the event is all that is necessary to decide if an event is significant enough for posting.
Anything else is subject to who shows up. If non-regulars chose to change the outcomes, there is no current guideline-based reason why present trends couldn't change. Until then, what you are seeing is the will of the "regulars". —Bagumba (talk) 10:29, 30 August 2024 (UTC)[reply]
Tags for this (fairly new) WikiProject are being mass-added to practically every article imaginable that is tangentially related to the 2010s — every sporting event in the 2010s; every film, TV show, and video game released in the 2010s; every Super Bowl, solar eclipse, election, notable death, and session of Congress during the 2010s, and so forth. Here's a sampling of the flood of edits that are flooding my watchlist (and likely others). Is this really necessary? To begin with, it's unclear whether a WikiProject should have a scope this large, or if this is attainable (if so, a bot should be assigned to handle mass-tagging). The WikiProject page explicitly states, The WikiProject is and will be involved in thousands of articles. There's no WikiProject equivalent for other decades or centuries, so we're in uncharted waters. InfiniteNexus (talk) 01:01, 1 September 2024 (UTC)[reply]
Apologies if my edits have been overbearing or troublesome, I'll make sure to stop with any further edits. To explain my reasoning, I found the concept of a WikiProject with goals like these to be interesting, so I thought it would help to participate by expanding its scope. I understand that there are countless articles that could qualify as relating to the 2010s, but it honestly made the challenge more enticing. Again I apologize for the flood of edits and clogging up your watchlists, I will make sure to end the expansion and mass edits and I wouldn't be opposed if the WikiProject ends up being removed. DukeOfDelTaco (talk) 01:31, 1 September 2024 (UTC)[reply]
To be clear, I am not targeting you specifically; you aren't the first and only person to mass-add these tags for WikiProject 2010s, but you are the most recent person to do so. InfiniteNexus (talk) 01:55, 1 September 2024 (UTC)[reply]
No worries. I think it's laudable to try to resurrect a WikiProject, but tagging random articles probably isn't the best way to do it. The best way to get the project up and running again would be to find some other editors (maybe @TrademarkedTWOrantula, who revamped the 2010s page a few months back) who are willing to help narrow the scope of the project and focus on crafting some initial tasks. voorts (talk/contributions) 02:03, 1 September 2024 (UTC)[reply]
Well, then ... if the project is inactive, then the tags should definitely not be mass-added to thousands of articles in a bot-like fashion. Even if the project weren't inactive, I still don't think a WikiProject should have a scope this broad. InfiniteNexus (talk) 19:08, 1 September 2024 (UTC)[reply]
I think given that it's inactive, and there's no prospect that participants in the project will come to a consensus regarding narrowing its scope, there would need to be some sort of higher level of consensus to deactivate it and avoid having people tag random articles with this WikiProject going forward. On the other hand, as long as mass tagging isn't occurring, I don't really see the harm with tagging this WikiProject inactive and moving on. voorts (talk/contributions) 19:11, 1 September 2024 (UTC)[reply]
In regards to plot summary
Works, from films to books, usually have a "plot" section, detailing its plot. However, I believe that they should be used only if there are reliable, secondary sources that summarize it. Without them, such sections become original research. So, we should make a policy where plot summary sections are only allowed in an article in the presence of reliable sources. 2804:14D:72B3:98F5:0:0:0:1F51 (talk) 19:55, 2 September 2024 (UTC)[reply]
I do not support this. Almost everything we do is summarizing or selecting from other sources. The work we have an article on is a reliable source for its own content. -- Nat Gertler (talk) 19:58, 2 September 2024 (UTC)[reply]
I'm not particularly fond of the practice, but it was already embedded in WP when I started editing 19 years ago. Not worth tilting at that windmill. Donald Albury21:31, 2 September 2024 (UTC)[reply]
Formatting of election pages - external links and pseudoheads
After noticing US election pages having potential issues with WP:LINKFARM/WP:NOTDIR and MOS:PSEUDOHEAD, I crafted some personal WP:AutoWikiBrowser find/replace rules to replace the semicolon pseudoheads with apostrophe-bolded versions and to switch the polling external links to wikilinks with references. I thought my edits were perhaps a bit WP:BOLD, but consistent with policies, provided readers with internal links to learn about the pollsters, and preempted expansion of columns when {{webarchive}} was placed directly into the tables to address dead links. A small subset of recent edits were reverted (e.g., [1]) and my attempt to discuss the issue with the reverting editor was met with my message being blanked from their talk page. I have found no guideline or policy to permit the types of pseuodoheads being used nor to include extensive tables of external links of polls, and this formatting may be more pervasive than I first realized. I had seen some of the election pages tagged with {{External links}} and I have since found that another editor brought up similar concerns about external links on WT:WikiProject Elections and Referendums. The RfC appears to have some support that extensive external linking is contrary to policy, but the discussion had few participants and several suggested to discuss at Village Pump, hence why I'm first posting here. I agree with User:Mikeblas's assessment in the RfC that "No explicit consensus has been discovered here, so the status quo is apparently just replicated behaviour counter to the site's policies." Is there consensus or guidance to allow such formatting of election (or other) pages? Is this the appropriate place to discuss this? Thanks, Ost (talk) 16:40, 4 September 2024 (UTC)[reply]
I think there are some issues with that user regarding Ownership of content, WP:COMMUNICATE, and civility. It seems like you're experiencing some of the same issues. There's no telling why your edits were reverted. I think they enhanced the article by replacing raw links to references (particularly to PDF files) and corrected formatting issues. Given the policy-breaking behavior issues, maybe WP:ANI is the next step.
Issues with link farms in election articles remain. As the article age, the links are rotting often becoming usurped to nefarious purposes. It's not hard to find articles where half of the campaign sites are dead links. I don't think the RfC was ever closed; it was just moved to an archive in the talk page of the project. (It is my first and only RfC, so maybe I was meant to do something differently.) -- mikeblas (talk) 18:47, 4 September 2024 (UTC)[reply]
WP:ELCITE says not to add extraneous information (e.g., archive dates).
As for how I know, I helped write WP:ELLIST. We talked specifically about the benefits of replacing campaign websites with archived copies. Mass replacement of US election websites, in articles of the "2024 [office] election in [place]" type, on the day after the election, was something we thought would be great. It shouldn't be anything fancy, just a simple link showing the campaign website as it was at the end of the campaign election. (@GreenC, perhaps you'd be interested?) WhatamIdoing (talk) 23:15, 4 September 2024 (UTC)[reply]
@WhatamIdoing: Bots like WP:IABOT are typically not updating links to the simple archive link; they generally use {{webarchive}} or similar formatting like your second link. I think it would require a change in bot behavior or manual cleanup to change them to the formatting that you indicate is preferred. It would probably also be good to list your examples in a policy or guideline. —Ost (talk) 22:11, 4 September 2024 (UTC)[reply]
@WhatamIdoing: Thank you for the reminder of that Noticeboard; I was following the suggestions at the RfC and did not consider that location to start the discussion, especially as there was also MOS concerns. However, this discussion can be moved there or split if it is more appropriate. —Ost (talk) 22:03, 4 September 2024 (UTC)[reply]
Thank you for also pointing out WP:ELLIST, though I don't believe that it answers the question because it states that "This section does not apply if the external link is serving as a citation to a reliable source for a stand-alone list entry that otherwise meets that list's inclusion criteria." That guidance may be valid for a minority of my edits that included links to debates (and I was open to further discussing those links and changing my edits), but the vast majority of the links are to polls which appear to be verifying the information in the table (i.e., serving as a citation). To me, the guidance also isn't clear on when it is permissible to include a list or table external links; it explains how they can be formatted and gives examples of political candidates, software, and websites, but it does not explain what makes a list acceptable to contain a links for entries (although the websites one may be self-evident). I don't think that most lists of movies, for instance, contain lists to the official websites for the movies. —Ost (talk) 22:03, 4 September 2024 (UTC)[reply]
@Ost316, keep reading that section until you get to the last paragraph:
In some cases, these links may serve as both official links and as inline citations to primary sources. In the case of elections or other one-time events, it may be desirable to replace the original links with links to archived copies when the event is over.
Polls should be formatted with <ref>...</ref> tags (or whatever system is used in that article, e.g., {{sfn}}).
What we recommend with ELLIST is that these be combined, e.g., through the addition of a column in the middle of the table adds something like "Official website" or "Campaign website" or even just [2]. Then most of the ==External links== section can be removed. After the election, a link to "ElectAlice2024.com" can be replaced with a simple archive link.
I add that we assumed that, for most articles, only the official websites for the main candidates would be appropriate, but there is no actual rule prohibiting editors from using their judgement to include more, if they really believe that would constitute an improvement for the article. I mention this because every country is a bit different, and we did not want to make a one-size-fits-all rule for such a diverse system. WhatamIdoing (talk) 23:28, 4 September 2024 (UTC)[reply]
Linking to archived copies of campaign websites for long-past elections (as opposed to live campaign websites in current elections) makes them essentially a historical primary document, appropriate for a bibliographic-style entry in a Further Reading section.
If it is the case, as others are implying, that every modern election page should have the archived campaign websites of all candidates linked, then perhaps a specific repeatable template should be used for that, such as within an infobox. But that should have some sense to it, and not just be fit into columns of whatever table is available. SamuelRiv (talk) 07:21, 5 September 2024 (UTC)[reply]
When the page has many WP:ELOFFICIAL links (e.g., defunct campaign websites), then it's more sensible to put them in a list with the candidates' names, instead of duplicating the list. The options are fundamentally like this:
Thank you for all your insight and explanations. I especially appreciate that polls should use the pages' referencing format, but the clarity over other ELLIST recommendations are also very good to know and understand. —Ost (talk) 18:21, 5 September 2024 (UTC)[reply]
A question on changing policies would be more suitable for policy over at the Village Pump, but I see no reason for this to have any effect on us here whatsoever. The case here was very specifically about controlled digital lending. CoffeeCrumbs (talk) 22:23, 5 September 2024 (UTC)[reply]
No. This judgement is completely irrelevant to the Wayback Machine, and not significant for any of the other ways we use the Internet Archive. In practice all that it will mean is that a small number of links in references/external links to books in their library might be broken. In the case of external links we'll just remove them if there is no other copy available. In the case of references then it doesn't affect the content at all, it just becomes slightly harder (but not impossible) to verify - we cite offline references all the time, and they are even explicitly allowed by policy. Thryduulf (talk) 15:14, 6 September 2024 (UTC)[reply]
+1 This is a legal determination for the WMF Office to make. This is not legal advice, but I agree with Thryduulf's reading of the case. As an aside, I'm not hopeful SCOTUS will take this case up. voorts (talk/contributions) 15:43, 6 September 2024 (UTC)[reply]
This has some slight relevence, at least to the degree that we cannot trust IA's own evaluation of the legality of their efforts (although that has been true for a while.)
One thing we should consider doing is altering the reference templates so that the Archived link only appears if the url-status is set to "dead". It seems to my not-a-lawyerly eyes to strain fair use claims when we are giving people that link to serve as a way around a paywall for commercially available copyrighted material.
Wikipedia for too long has treated IA as a sole good, without concern to copyright statuses, nor to the fact that they have been paying editors to skew Wikipedia toward them, in part to encourage used book sales. -- Nat Gertler (talk) 15:57, 6 September 2024 (UTC)[reply]
This has some slight relevence, at least to the degree that we cannot trust IA's own evaluation of the legality of their efforts ... The issue in this case was one of first impression and IA had a lot of amici briefs filed in support of their legal position, including the Wikimedia Foundation.
In any event, this case is solely related to IA's digital book lending program, and the court will likely order IA to remove the offending books. Wayback has been around for a long time and as far as I know none of the big media orgs have ever sued over it or indicated that they will sue over it. It's premature to start deprecating Wayback links or limiting their use. voorts (talk/contributions) 16:14, 6 September 2024 (UTC)[reply]
So should we rewrite WP:COPYVIOEL to say it's a-okay to be linking to sites that violate the copyrights of others, so long as they have not yet been specifically sued for the copyright violation we are linking to? IA is a confirmed piracy site, it just seems to be the one we pretend is okay because they put "Archive" in their name. -- Nat Gertler (talk) 17:44, 6 September 2024 (UTC)[reply]
Confirmed piracy according to whom? The US copyvio suit was resolved with a negotiated judgement, and there's an injunction on them lending these classes of books. Violating the injunction results in strictly defined penalties. If believe they are violating the injunction, you may wish to contact the parties' counsel to confirm -- I'd guess that'd be a faster and more reliable confirmation of copyvio than WMF counsel, since the original parties are motivated financially to enforce each potential violation.
With the injunction, we can be reasonably sure that book-lending that was considered to violate copyright in this judgement has all been removed. Furthermore, linking to the book does not violate copyright nor can it reasonably be considered to facilitate violating copyright (certainly now). The IA's action that was violating copyright in the NEL was controlled digital lending, which usually requires some kind of login to the site, and regardless can be (and is) deactivated site-wide. The NEL is gone, and our existing NEL book links should be fine as long as they continue go to some bibliographic info and are not otherwise broken.
Furthermore, even if IA admitted that its NEL was a "confirmed piracy site" or piracy operation (which they didn't, and keep in mind IA has not been charged criminally unlike something like megaupload), it does not make sources outside the NEL part of that operation (the scope of the lawsuit is only NEL book lending). SamuelRiv (talk) 18:06, 6 September 2024 (UTC)[reply]
According to both the court decision that their use was not fair use, and the appeals court confirmation.
With the injunction, I can confirm for you that they are still offering unauthorized electronic editions to which I own the copyright, so no, we cannot reasonably assume that the problem has been addressed.
The fact that IA hasn't admitted themselves to what they did does not obviate the rulings, nor should our standard be "avoid linking only to sites that have announced themselves to be pirates, yar har har." The idea that we should assume that even on a site that has already had identified piracy, we should assume that all their other files are okay is ludicrous. -- Nat Gertler (talk) 18:53, 6 September 2024 (UTC)[reply]
If your copyrighted materials are not now or were being offered in context of the NEL or controlled digital lending, then the case this past month has no relevance to you. If you have a direct copyright violation complaint, US law allows you to request removal from host websites, and you can see IA's procedure for it. Every major content-hosting site has DMCA takedown procedures, and every such site has had copyright-violating material be struck, legitimately, after such procedures were followed per applicable law. Such procedures, followed with such violating content, do not make such sites (like Youtube, Twitter, etc.) a "confirmed piracy site" in any meaningful manner. SamuelRiv (talk) 19:27, 6 September 2024 (UTC)[reply]
Yes, I know that the pirate site has a set of hoops they've put up in order to request that they stop one little piece of their piracy, and I've also seen them ignore that before. -- Nat Gertler (talk) 20:56, 6 September 2024 (UTC)[reply]
If they ignored your request to remove your copyrighted content, then speak to a lawyer, because you can cash in. But if this thread is no longer about NEL content then I don't think there's anything to discuss. SamuelRiv (talk) 23:45, 6 September 2024 (UTC)[reply]
But the copyright laws do themselves cover my works. If we want to remove all restriction from directing people to pirate sites, we should say so up front. -- Nat Gertler (talk) 20:53, 6 September 2024 (UTC)[reply]
Nobody is proposing removing all restrictions regarding pirate sites, but nobody, including you, has provided any evidence that IA is a pirate site. Thryduulf (talk) 21:00, 6 September 2024 (UTC)[reply]
If large groups of rightsholders suing them, and multiple court rulings against IA is not sufficient for you, here is them offering an electronic edition of a book that I hold the compilation copyright as well as publishing rights on, my name is right there on the cover, and I am telling you that I have not licensed them nor anyone else to create an electronic edition of that book. I've seen a lot of links deleted for WP:COPYVIOEL before, and I have trouble thinking of any for which the evidence was greater than court rulings and copyright holders objections. -- Nat Gertler (talk) 21:11, 6 September 2024 (UTC)[reply]
If you're a publisher you should be aware of, or have counsel to advise you on, the relevant laws in your jurisdiction on libraries, inter-library loans of ebooks, and something if you are a member of a class settlement (or else whether you are covered by the AAP). Wikipedia talk pages are not the place to seek legal relief. (Comic relief, on the other hand, ...) SamuelRiv (talk) 00:01, 7 September 2024 (UTC)[reply]
Wikipedia talk pages are, however, the place to discuss Wikipedia applying our policies and guidelines, which do include WP:COPYVIOEL, much as everyone seems to want to whistle and look the other way. Attempting to silence me seems rather inappropriate. Folks are erecting exceptions for IA that I do not recall them every erecting in other copyvioel concerns. But thank you for explaining to me how I should run the business I've been running for a quarter century, or how easy it is to take on legally a business that's hundreds of times one's size. -- Nat Gertler (talk) 18:19, 7 September 2024 (UTC)[reply]
I have not licensed them nor anyone else to create an electronic edition of that book. Institutions like Google and Internet Archive don't need a license to digitize the book so long as they are only displaying short passages and search results, it is considered Fair Use. This was established and reestablished in the Google and Publishers cases. -- GreenC21:41, 7 September 2024 (UTC)[reply]
According to them, they are not just displaying short passages and search results. They are telling people that they can log in and borrow the book for an hour, which would be their display of their complete electronic edition through a web browser. And I cannot point to any other WP:COPYVIOEL concern where we required a completed lawsuit to notice that copyrighted material is being offered without license, can you? -- Nat Gertler (talk) 06:35, 8 September 2024 (UTC)[reply]
If IA is making your book available contrary to the settlement then you contact their office as I linked above. If you are concerned that WP is facilitating copyright infringement on your material, then you contact admins per WP DMCA policy. The lawsuit on CDL is complete -- DMCA requests (or whatever your lawyer advises) are how you get it enforced. (And I imagine if you were to file a lawsuit, the very first question that will be asked is, "Did you send them a DMCA request?".) But please ask your lawyer first. (And when on the internet someone says "If you have personal legal concerns you should speak to your lawyer and our legal department", that's not them silencing you, that's just common sense.) SamuelRiv (talk) 16:34, 8 September 2024 (UTC)[reply]
No. (Put aside that the proposition as worded fundamentally breaks WP itself.) The negotiated settlement has been in force for nearly a month now, with an injunction on the books at issue (which is a small subset of the total books that IA has available.) Furthermore, in my editing here, I have seen a full book-edition-in-copyright linked on IA library as a reference maybe... a couple times at most? The vast majority is non-lending books out of copyright and/or out of print. That is reinforced by how citations work in WP, and how our citation template works, passively encouraging more openly accessible means of verification (e.g. searchable passages of books as opposed to limited-time lending of entire books). SamuelRiv (talk) 16:33, 6 September 2024 (UTC)[reply]
GreenC is a paid agent of the Internet Archive, something which he should probably raise whenever he journeys into conversations like this. (It can be verified down at the bottom of his user page.) -- Nat Gertler (talk) 18:56, 6 September 2024 (UTC)[reply]
The factuality of his statement (to whatever degree it has; it's not something they're backing up with a reliable third-party source) does not obviate that they are a paid agent of the organization and should identify themself as such in such a discussion. As you have a conflict of interest, you must ensure everyone with whom you interact is aware of your paid status, in all discussions on Wikipedia pages within any namespace. (WP:UPE) -- Nat Gertler (talk) 21:01, 6 September 2024 (UTC)[reply]
I've thought about it but my relation to the org is so far removed it gives the wrong impression to say "I work for IA", I'm certainly not an Agent, or posting on their behalf, I'm not technically an employee, or even been to their offices. My primary role here is as a 21-year Wikipedian posting for the benefit of other Wikipedia editors. Maybe in these discussions I could say something like "disclosed COI but not posting on their behalf", and leave it there. Also, feel free to reach out if you want help navigating the organization, possibly I could help, but not sure your situation. -- GreenC17:49, 7 September 2024 (UTC)[reply]
I think that would be appropriate; you are certainly welcome in these discussions, but such a disclosure would serve both those who don't know you have a WP:COI (and editing in discussions related to a client does indeed fit in that, even if it is not specifically what they are a client for) as well as those who do know that you have that link and may assume you are making statements at their behest. (And I'm saying that someone who tries to remember to note my own COIs even when all I'm doing is a very simple MOS fix.) -- Nat Gertler (talk) 18:08, 7 September 2024 (UTC)[reply]
You seem to have a much greater COI with regards to the IA than GreenC does, yet you are giving the impression that your contributions to this discussion are more objective than GreenC's are. Thryduulf (talk) 18:22, 7 September 2024 (UTC)[reply]
I'm sorry, I must've missed where having ones material copied by a site gives one a WP:COI; if that's the case, then basically everyone who has ever put anything on the web has that same conflict with IA. And can you point to anywhere where I state that GreenC has said anything not objective? The brief question of "factuality" is questioning at most the accuracy of a statement. Had he said "the sun is three feet across", that would be an objective statement, but not factual. If you have some concerns about impressions, you may want to deal with the impression you are creating trying to shout me down rather than addressing actual concerns. -- Nat Gertler (talk) 06:30, 8 September 2024 (UTC)[reply]
I was in no active dispute before posting on this thread that I was someone whose books they had pirated. Indeed, it was pulling up the examples to answer those in the thread who wanted to deny what was going on that drove me to send a letter requesting that they stop hosting their unauthorized editions. -- Nat Gertler (talk) 16:22, 8 September 2024 (UTC)[reply]
If the office (see WP:OFFICE) decided to ban linking to a site (regardless of which site and why) they would communicate that to us officially by posting on Meta (as I can't imagine such a ban applying to only one project) and cross-post it to various places on large projects. Editors would then disseminate that message elsewhere - you can guarantee that someone (whether the WMF or an editor) would post it to WP:AN for example. If the site is notable then it wont take long before the article is updated to reflect the ban and you'll see the decision discussed in countless internet forums and probably news publications too. Thryduulf (talk) 00:14, 7 September 2024 (UTC)[reply]
Agree with Thrydulf's assessment here. Wayback (normal archiving of URLs) isn't touched by this, and this only makes book copies on Internet Archive in question, which I've always felt was going to be a problem. Masem (t) 00:10, 7 September 2024 (UTC)[reply]
CSD X4 criterion proposal
Per WP:NSPORTS2022 Proposal 5 and the subsequent update to WP:SPORTSCRIT, there is consensus that sports biographies are not subject to WP:NEXIST and are automatically subject to deletion if they do not contain at least one source demonstrating significant coverage in the article. To this point, cleanup has been slow as a courtesy to AfD. I propose CSD X4 so the articles can be addressed without causing a significant backlog. X4 would only apply if there is unambiguously no source to demonstrate significant coverage in the article, meaning borderline sigcov would still need to go through AfD or PROD. Articles sourced entirely to databases or passing mentions would qualify for X4 deletion. X4 would be an alternative to mass AfD nominations, which will be the likely outcome if no action is taken. Thebiguglyalien (talk) 21:24, 6 September 2024 (UTC)[reply]
I don't read the close of NSPORTS2022 as saying that such articles must be deleted, but rather that for an article to be created it must have at least one source with SIGCOV. voorts (talk/contributions) 21:32, 6 September 2024 (UTC)[reply]
Thank you! I considered this the most "central" location and went to notify other places, but I got distracted after adding it to COIN. I have no objections if anyone thinks this should be moved to WT:CSD. Thebiguglyalien (talk) 21:51, 6 September 2024 (UTC)[reply]
(edit conflict) Firstly new CSD criteria should be proposed at Wikipedia talk:Criteria for speedy deletion (I'll notify them for you) and should demonstrate that they meet all four requirements listed at WP:NEWCSD. My first impression is that this would fail at least point 1 (objective) because what coverage counts as "significant" is subjective and whether coverage meets that standard is frequently a matter of disagreement at AfD. AIUI there is also frequent disagreement about what counts as a database and whether database entries are always non-trivial coverage. Thryduulf (talk) 21:52, 6 September 2024 (UTC)[reply]
Speedy deletions are for situations where the deletion criterion is clear and the deletion of articles meeting that criterion is uncontroversial. Past discussions of sports stubs have made it obvious that both of these conditions are not met here. —David Eppstein (talk) 21:57, 6 September 2024 (UTC)[reply]
I regularly see athlete articles prodded, in the list at WP:PRODSUM, often in large batches. I haven't been keeping track of how successful the prods are but I think it's a good thing to try first before resorting to an AfD. —David Eppstein (talk) 22:08, 6 September 2024 (UTC)[reply]
All right, thank you. I do feel a little silly now that the points above have been raised. I'm just working through the NPP backlog right now and trying to find some sort of way to make it more efficient when sorting the good from the bad. Thebiguglyalien (talk) 22:10, 6 September 2024 (UTC)[reply]
If your goal is efficiency or a minimum of drama, I think that you should not try to delete any "borderline" cases. Using WP:PROD on egregious examples, with a good explanation and a link to the requirements, isn't likely to earn you many wiki-enemies. However, trying to remove (by any means: AFD, PROD, Draft:, etc.) any subject for which SIGCOV is perhaps a matter of judgement is not likely to win friends and influence people. In particular, I suggest turning a blind eye towards any subject that someone could claim as SIGCOV under WP:100WORDS. WhatamIdoing (talk) 00:24, 7 September 2024 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
WP:INVOLVED policy regulates permissible conduct of Admins and editors performing non-admin closures. This policy was created before the existence of WP:Contentious topics. Inside the first sentence In general, editors should not act as administrators in disputes in which they have been involved. (bold emphasis mine) the term dispute is not well defined, despite the fact that some WP:Contentious topics are exceptionally well defined, e.g WP:ARBPIA while others like WP:BLP are not narrow in scope. Inspired by the larger discussion at Wikipedia:Administrators'_noticeboard#Possible_involvement_of_Admin_in_ARBPIA_area
My proposed re-wording (added text in green) of above sentence for minimal change would be:
In general, editors should not act as administrators in disputes in which they have been involved. When the editing area is covered under existing WP:Contentious topics, the definition of dispute scope may be broadened to include a larger subset of said contentious topic area to be defined by the Arbitration Committee.
This would allow us to avoid changing wording of WP:INVOLVED to litigate each individual contentious topic, while retaining flexibility. For example ARBCOM could clarify that ARBPIA could be envisioned as 'one dispute area', while WP:ARBAP2 might involve several (Trump, US voting rights etc..) and something like WP:BLP might not define any for purpose of WP:INVOLVED. ~ 🦝 Shushugah (he/him • talk) 10:53, 7 September 2024 (UTC)[reply]
I believe it is already covered by the "construed broadly" and "may be seen to be involved" portions of INVOLVED:
Involvement is construed broadly by the community to include current or past conflicts with an editor (or editors), and disputes on topics, regardless of the nature, age, or outcome of the dispute ... it is still the best practice in cases where an administrator may be seen to be involved to pass the matter to another administrator via the relevant noticeboards.
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Can we discourage indiscriminate automatic addition of Wayback archive links on all external links?
There are a bunch of Wikipedian meat-bots running around with an automated tool which indiscriminately adds Wayback Machine links to every external link in every reference on one Wikipedia article after another, either as an archive-url parameter for CS1 or CS2 citation templates, or using the {{Webarchive}} template for ordinary wiki-markup links.
While the Wayback Machine is a wonderful and invaluable resource that I use multiple times a week, and I am all in favor of adding archives for dead links (such as User:InternetArchiveBot currently does), adding a wayback link for every external link on Wikipedia, including all of the still live and publicly accessible URLs, seems to me extremely spammy and moderately reader-hostile. It wastes a lot of space, is confusing to readers, wastes time/attention and causes confusion for editors trying to verify claims in articles, and seems mostly like a way of turning Wikipedia into a massive advertisement for the Internet Archive. I personally think the Internet Archive is wonderful and well worth supporting with money and use, but this method feels really icky and unjustified to me, not that different in spirit from Wikipedia adding banner ads for third-party charities or individual Wikipedians indiscriminately spamming links to their own published papers. It feels abusive of Wikipedia as a platform and of the Wikipedia community, and as far as I know there was never any consensus for it.
Can we formalize some kind of policy discouraging indiscriminate automatic addition of archive links? If human editors want to deliberately add individual specific wayback backups for still-living pages for some good reason (e.g. a website changed their content, substantially changed their formatting, or put up a paywall, in a way that makes the original content difficult to use for verifying the claims in the article) I have no problem with that. And again, as I said above I am all in favor of adding wayback backups (including automatically) to dead links.
One thing that I suggested above is that rather than discourage the creation of the archive link (which is quite understandable at least when the person originally constructing the reference wants to make it bulletproof), we have the cite templates only display the archive if the link status is "dead" or some similar status that indicates that the original link is no longer appropriate. (I also question whether we need the statement archived at Internet Archive displayed on references even when the original URL is dead; anyone following the archive will see the site it's at, it doesn't really inform the reader about the quality of the source material, and as you say, it does come across as advertising.) -- Nat Gertler (talk) 06:14, 8 September 2024 (UTC)[reply]
This doesn't seem like a good solution to me. There are perfectly legitimate reasons for editors to manually and intentionally add archive backups for specific still-living pages, e.g. if the site is flaky and routinely goes offline, is notorious for regularly changing URLs, or has substantially changed the content of a specific linked page. However, for other links, a "just in case" backup in the article source serves no purpose. The action that is useful, for still living pages, is to explicitly ask the IA to crawl and archive the content of the page (e.g. by requesting that it crawl all pages linked from a particular Wikipedia article), so that there will be a backup in case the link ever rots. But that can be done from the IA site or some external script and shouldn't involve changing the source markup of a Wikipedia article. –jacobolus(t)06:30, 8 September 2024 (UTC)[reply]
I am aware that this is done, but can you link an example bot or script that is doing this? (As you note, IAbot does not.) The code people are using may just be hastily written without checks. I am opposed to adding such archive links indiscriminately to every citation:
Archive links added after the fact, when not for rescue/CPR purposes, should be dated as close as possible to the |access-date= parameter of the citation, and not to the date of the crawl (which may or may not be the case for a given userscript.) If the new |archive-date= parameter must be different, the cited text must be checked manually.
If no |access-date= parameter is given, the cited text must be checked manually. (In practice it may not be justified to date it to the day the original edit was made, and I doubt it's computationally feasible to back-trace a section of wikitext to its last edit in a bot.)
Some very few citation links might be explicitly meant to reference the live version of a website, such as a webapp or "current status of..." footnote.
However, if the |access-date= parameter is given in the citation, I don't see an issue with adding an archive link with |url-status=live as applicable. (Although we might consider querying more archiving sites than just IA when doing this.) SamuelRiv (talk) 16:51, 8 September 2024 (UTC)[reply]
Here's an example edit, special:diff/1243928783, edit summary "Rescuing 13 sources and tagging 0 as dead.) #IABot (v2.0.9.5 Tag: IABotManagementConsole [1.3]". (This one is a particularly annoying common variant that adds wayback links for stuff like Google Books pages, bibcode links, etc.) I'm not trying to call out specific Wikipedians or publicly shame anyone. There are a bunch of people doing this type of edit using the same automated tool, often to many pages in quick succession. I think these kinds of edits are done in good faith, but I think we should have a policy page discouraging them. –jacobolus(t)17:46, 8 September 2024 (UTC)[reply]
@Jacobolus could you clarify if your objection is to the use per-se of IA, or to the fact that people are doing it indiscriminately in a bot-like manner? I routinely run IABot on my own articles and tell it to add links to anything it archives. I hope you're not objecting to that. RoySmith(talk)17:33, 8 September 2024 (UTC)[reply]
Yes, I am objecting to adding archive links to "anything it archives". This is, in my opinion, a type of spam. Please use archive links (whether from the internet archive or some other site) for links where the original is dead, changed, or unreliable for some reason, not just for fluffing out the citations section with distracting and unnecessary clutter. –jacobolus(t)17:37, 8 September 2024 (UTC)[reply]
This isn't purely rhetorical, but one could plainly search for URLs of IAing Google Books and quite quickly get a sense of how common this indiscriminate archiving is and what it looks like. Remsense ‥ 论20:18, 8 September 2024 (UTC)[reply]
OK, I guess I'll have to respectfully disagree. The problem is that by the time a link goes dead, it's too late to archive it, and then it's lost. I wouldn't mind if the citation templates treated this in a less "fluffy" way, but I'd hate to see the archive information omitted completely. RoySmith(talk)17:45, 8 September 2024 (UTC)[reply]
Here's an example from RoySmith: special:diff/1232611207 to Big Duck. Most (all?) of the archive links being added here go to still-living pages which are publicly accessible on the open internet, so the archive links are nothing more than clutter. "by the time a link goes dead, it's too late to archive it" – People should directly ask the IA to crawl and backup pages linked from Wikipedia. It is completely unnecessary to change the markup source of Wikipedia articles to accomplish this task. But to be honest, I don't mind that strongly if one of the primary authors of an article wants to go ham on the wayback links. Discussion of that choice could be contained to individual article talk pages and hashed out locally. But there are also folks doing large numbers of these edits to one page after another in a bot-like fashion, and at scale it's impossible for someone who disagrees to meaningfully revert or contest those changes without spending an even greater amount of time. I don't think there's any established consensus that such archive links should be added site-wide, so adding them automatically at scale is a kind of fait accompli. –jacobolus(t)17:52, 8 September 2024 (UTC)[reply]
Adding the IA link into the citation template makes it much easier to find later should it be necessary. If it bothers you to see that, it's easy enough to add some custom CSS to hide those sections of the citation. I'd be happy to have the templates add some classes to the markup to make that easier to implement. RoySmith(talk)18:32, 8 September 2024 (UTC)[reply]
It bothers me that we are spamming editors and readers in a way that seems abusive of Wikipedia's platform and community. Hiding what I personally see does not at all address my concerns. "much easier to find later should it be necessary" – this seems like nonsense to me. We are talking about the result of a fully automated tool without human inspection or intervention beyond clicking a submit button; the IABot is currently automatically "rescuing" dead links across the site without any human involvement at all, and will presumably continue to do so. Speaking as a human who constantly uses the Wayback Machine to find archived pages, it is trivial to go to web.archive.org, type a URL in the box, and then click through to see the various archived versions of that URL. –jacobolus(t)18:47, 8 September 2024 (UTC)[reply]
In the source of pages, this cavalier archiving behavior manifests as either apparent negligence or obsessive compulsion far too often in certain situations. "Indiscriminate" is the key word here. Remsense ‥ 论20:20, 8 September 2024 (UTC)[reply]
@Jacobolus: I just want to express the exact opposite position to your proposal.
Clicking on a link vs. going to the Wayback page, copy/pasting the url, possibly comparing alternative archive copies ... yet you say you're concerned for everybody else rather than just yourself? That makes no sense to me. Fabrickator (talk) 19:13, 8 September 2024 (UTC)[reply]
@Fabrickator You are not understanding my point. Let me try to be clearer. The claim is that we need to defensively add archive links to every external link because otherwise it is not "easy" enough to find the archive link in the event that the link rots and it becomes "necessary". My responses are: (1) it doesn't get any harder to manually trigger an archive bot/script years down line in the possible case that some links rot, (2) there's a continuously running automated process scanning the web for dead links and "rescuing" Wikipedia citations by adding wayback archive links, requiring no human intervention at all in the general case, and (3) even if this bot somehow doesn't catch a very occasional stray dead link and a human editor tries to verify a claim but ends up at a 404 page or whatever, it is quite trivial for a human editor to use the wayback machine from their browser (it takes no more than a few minutes to manually find the wayback link and add it to an article, and we are talking about a tiny number of links at that point). People running this script certainly aren't comparing various archived versions of every link. I have no problem at all if editors carefully manually inspect and think about how best to present every citation link to readers, sometimes making the specific individual decision to add an archive link. –jacobolus(t)20:34, 8 September 2024 (UTC)[reply]
I very much agree with this. I used to be one of those editors that clicked the button and let IAbot run because I thought adding the archive links was an improvement to any article. I no longer think so, especially since I learned that Internet Archive archives all external links on Wikipedia anyway, so having the bot run doesn't actually archive the links, it just adds archive links to the citations, which is usually not helpful, unless the link is dead and IA has the full version (or to get around a paywall, but that's not really a kosher use). The archive links make citations harder to read and work with. It's even worse when the link being archived is useless, e.g. archiving Google Books pages because it's linked in a citation to the book (which doesn't archive the book!). Bottom line: I do not think the automatic addition of web archive links to citations is a good thing. I would support a change to IABot that it only adds archive links if |url-status=dead. I think I'm in the minority on this, though. Levivich (talk) 19:27, 8 September 2024 (UTC)[reply]
If what you say in your first bit of bolding is true (I have no reason to doubt it but don't have time to check now) then I am in the same minority, if it really is a minority. Phil Bridger (talk) 19:40, 8 September 2024 (UTC)[reply]
This being Wikipedia, I should cite my sources :-) IA in 2018: For more than 5 years, the Internet Archive has been archiving nearly every URL referenced in close to 300 wikipedia sites as soon as those links are added or changed at the rate of about 20 million URLs/week.WP:WAYBACK also says New URLs added to Wikipedia articles (but not other pages) are usually automatically archived by a bot. It also says Editors are encouraged to add an archive link as a part of each citation, which I think it should not say. BTW, another very easy solution to this would be to code the citation templates to not display archive links unless |url-status=dead. This could also probably be done as a CSS hack, so editors who didn't want to see those links for live URLs could turn them off as it were. Levivich (talk) 20:07, 8 September 2024 (UTC)[reply]
One of the reasons for linking to wayback is so that we can continue to cite webpages that are no longer available, or have been significantly changed. But this raises red flags for me… I want to know WHY the cited source is no longer available or has changed. This question should always be asked before we link to wayback. The answer may require us to reassess whether the information in our article is out of date, and thus no longer accurate and verifiable. Blueboar (talk) 21:19, 8 September 2024 (UTC)[reply]
In my experience, archive links for still-alive links could be useful, as the site may be temporarily down or region-blocked. I don't have a strong opinion on this, though, because for me personally it's not hard to manually open a link through the Web Archive. Levivich's solution seems good to me, but I also agree with jacobolus that there should be an option in IABot to archive all the links but not add them to the article. AstonishingTunesAdmirer連絡21:10, 8 September 2024 (UTC)[reply]
I just tested it, it's not that, it still adds archive links to the article. As far as I understand, the bot makes a list of all references in the selected article, then saves each link through the Web Archive, and then adds links to these archived pages to the article. What jacobolus was talking about is skipping that final part, so the bot would save all links through the Web Archive, but would not add them to the article. AstonishingTunesAdmirer連絡21:30, 8 September 2024 (UTC)[reply]
@Jacobolus: You wrote: "You are not understanding my point. Let me try to be clearer." I hear your point, but I think it's a bad one. I'm unclear whether you object to the archive link being visible, being present when you edit the article, or being stored in the wikitext. Certainly I don't object to it not showing up when you view an article, and the details of how this is stored is something I should like to see improved (e.g. along the lines of storing the data in Wikidata and accessing it using {{cite q}}).
But even the possibility that the live url is temporarily not working (or permanently not working) is good enough reason to have the archive link handy. It's a bonus that there are other scenarios where it's useful ... e.g. some "multi-page" articles (requiring a different url to get to subsequent pages) may also have a link that displays all pages with a single url. You might suppose this is neither here nor there, but as an editor, I make such a decision as to which is preferred. I am unhappy about the nuisance of all this, but I am happy that we are not stuck with what unintelligent bots choose to do.
I would long for a bot that was smart enough to make good decisions, but I see no evidence that we have the appropriate technology to develop sufficiently intelligent bots, so we have a fallback of manually adding or editing archive links, yet the existing system is useful in that it makes a passable selection at least most of the time, yet somehow you are annoyed about the presence of that selection. I throw up my hands. Fabrickator (talk) 21:51, 8 September 2024 (UTC)[reply]
"I'm unclear whether you object to the archive link being visible, being present when you edit the article, or being stored in the wikitext." – I am strongly opposed to the first, which seems like spam and is confusing to readers, and moderately opposed to the other two, which still add a lot of clutter to the markup for no practical benefit. "may also have a link that displays all pages with a single url" if you want to link the article title to one URL and also add a second URL to a consolidated version of the content, there's nothing stopping you. It would be extremely confusing to use the "archive-url" parameter for this, so please don't do that. "as an editor, I make such a decision" – again, I am mostly unhappy with automated tools imposing poor choices not backed by site consensus, not by human editors making specific decisions about individual links on single articles. The latter is entirely possible to discuss and work out in local talk pages. –jacobolus(t)22:03, 8 September 2024 (UTC)[reply]
I guess my response to this would be "you never know when a publication/company could go down". Just as a recent example, Game Informer went down this year and there was a mad scramble to archive all of their website links and making sure all that was saved because GameStop couldn't be bothered to keep GI's history up. I'd rather be preventative and avoid stuff like that from occurring rather than being reactionary and having to scramble to archive a source if it goes down. ♠JCW555(talk)♠ 22:22, 8 September 2024 (UTC)[reply]
"You never know" simply isn't a compelling enough argument to applied literally 100% of the time in favor of obvious clutter that has clear concrete disadvantages in the meanwhile. What is the aversion editors have against literally any discretion being applied here? Remsense ‥ 论22:52, 8 September 2024 (UTC)[reply]
"obvious clutter that has clear concrete disadvantages in the meanwhile" this is your opinion, which is fine to hold of course, but I (and others) don't feel that way so don't try and speak for everyone. "Discretion" in this case would be "editors should have the same opinion as I do". I'd rather be proactive in archiving sources than be reactive. ♠JCW555(talk)♠ 23:05, 8 September 2024 (UTC)[reply]
My opinion is putting emphasis on what are demonstrable, objective issues caused by the practice. You can have a different emphasis, but let's not pretend whether the issues even exist (which I've just elaborated upon below) are a matter of opinion themselves. Remsense ‥ 论23:08, 8 September 2024 (UTC)[reply]
"what are demonstrable, objective issues caused by the practice" again, according to you. I, and others in this conversation don't agree with you. You can think it's a problem, others can think it's not a problem. That doesn't make either of us right of course, but I don't say my opinion is 100% true and everyone must agree with me. I only speak for me, not every editor on the platform. So again, don't speak for me or everyone on here. ♠JCW555(talk)♠ 23:19, 8 September 2024 (UTC)[reply]
My browser crashing when I try to turn on syntax highlighting isn't a figment of my imagination or a mere aesthetic preference I have. In the general case it is a problem for me and for you for all intents and purposes, so you're not going to force me to mince words as such. Remsense ‥ 论23:20, 8 September 2024 (UTC)[reply]
I've read this whole discussion a couple of times now and I'm still not understanding what is problematic about including the archive links for active links. They are useful for temporary outages, region locking, verification of pages that have changed content, usurped domains (which are hard to detect automatically, which is why the WP:JUDI domains have to be tracked manually for example) and for other uses too. I also don't understand why some people in the discussion find the presentation of both live and archived links confusing - is this an actual problem that readers have noted or is it just a theoretical somebody might potentially be confused? I'm not attached to changing the display, but I am opposed to removing it without evidence that the current presentation is actually problematic and that the proposed alternative is actually an improvement. If anything, I would prefer to encourage the inclusion of archive links with every citation, because they are significantly valuable to maintaining the integrity of the encyclopaedia and allowing continued verification of our articles. I completely disagree that they are "clutter" and nobody has presented any arguments here that convince me that inclusion has any disadvantages at all, indeed quite the opposite. Thryduulf (talk) 22:57, 8 September 2024 (UTC)[reply]
When they are clearly addressing one of your stated issues then of course they are useful. Otherwise, wikitext length itself plus its associated visual and technical complexity simply isn't free or essentially free: the additional bundle of parameters indiscriminately added to every citation adds visual clutter for editors to scroll through, which does make it harder to factor articles and understand their wikitext, and even the rendered article if the archive is not serving any clear function. It is not controversial that it can also lag the editor, especially when syntax highlighting is enabled. I am dead serious when I say there are articles I cannot comfortably edit in their present state, whereas I would be able to if every Google Books url didn't add nearly 1kB to the article size instead of 100B. If we're supposed to have archives on literally every external URL, then that should be added to the backend or something so we don't have to deal with it this way. Let's not treat it technically like a matter of discretion when it's actually not editorially. Remsense ‥ 论23:05, 8 September 2024 (UTC)[reply]
When they are clearly addressing one of your stated issues they always address those stated issues, because it is not possible to predict when a site is down (temporarily or otherwise), whether any editors will be geolocked (e.g. many US news sites are blocked to editors in Europe but it is completely invisible to US readers which they are and which they aren't), etc. Thryduulf (talk) 23:15, 8 September 2024 (UTC)[reply]
But it is actually possible to weigh some of these factors based on context. Plus, why are we a priori able to assume the IA is perfectly reliable in this way, but any other site isn't? Remsense ‥ 论23:19, 8 September 2024 (UTC)[reply]
It is possible for a human' to weigh some of those factors in context, which means that as humans don't (and can't) evaluate every link in context in advance of every reader reading the article the links are always addressing the stated issues. We don't assume that IA is perfectly reliable, we know that the IA does not geoblock and is generally reliable, we also know that the combination of a link and an archive (IA isn't the only game in town, despite what this thread implies) is more reliable than a link alone. Thryduulf (talk) 00:03, 9 September 2024 (UTC)[reply]
Right—all I am arguing for is that discretion is possible, and that it is still expected in the use of automatic tools like with any other dimension of editing.
As a total tangent, I've always wondered why it isn't possible to collapse CS1 archiving into two parameters—date and liveness. Surely it's pretty feasible to derive |archive_url= from the |url= and |archive_date= (etc.) already given? Remsense ‥ 论00:11, 9 September 2024 (UTC)[reply]
Ah, that makes sense. Do you think it would be viable for the "default mode" to assume IA with no redirect, and other configurations could be further specified if needed? As strong as my opinion is here, reducing the wikitext footprint of archiving would make it essentially a nonissue! Remsense ‥ 论00:20, 9 September 2024 (UTC)[reply]
It's a good idea, in my opinion. I think combined with an option to disable rendering for archive links on live sites it should solve most of the complaints (wikicode would be less cluttered, there would be fewer archive links on screen). But I think this more of a question to people working on the citation templates, whether it's hard to implement, etc. Pinging @Trappist the monk and Izno: how hard would it be to generate an archive link for a URL, so instead of {{cite web|url=https://en.wikipedia.org|archive-url=https://web.archive.org/web/20240501005015/https://en.wikipedia.org|archive-date=May 1, 2024}} you could do just {{cite web|url=https://en.wikipedia.org|archive-date=May 1, 2024}}, but with an option to provide archive-url if it differs from url (or you need a specific snapshot, I guess)? AstonishingTunesAdmirer連絡00:49, 9 September 2024 (UTC)[reply]
You would need the full timestamp of the archive 20240501005015, so you need a separate parameter regardless |archive.org-id=20240501005015 or whatever. You would not be able to do it solely with a |archive-date=. Izno (talk) 01:02, 9 September 2024 (UTC)[reply]
@Thryduulf, I talked to the IA folks about this a while ago. The problem we have is that what the bot does violates our guideline at WP:ELCITE. The problem they have is that the bot is too simple-minded to know how to stay out of the ==External links== section. It takes an all-or-nothing approach to adding archive links in an article. (It also has had problems with incorrectly claiming that sites are dead.)
For clarity, in the ==External links== section, either of these is Y good (depending whether the link is live):
WP:ELDEAD agrees with you. We tend to keep archived copies of official links, and occasionally something that an editor thought was particularly valuable, but otherwise, they should usually be removed/replaced with something else. WhatamIdoing (talk) 23:55, 8 September 2024 (UTC)[reply]
@WhatamIdoing that's an issue with the implementation of the specific bot, not with the addition of archive links.
@JacobolusSome links should remain archived (e.g. official websites), some can (and should) be fixed by replacing them with an updated link the bot is not aware of, others should be removed. However that determination needs to be made by a human, and marking a link as dead is a very good way of letting humans know that a determination needs to be made. Thryduulf (talk) 00:07, 9 September 2024 (UTC)[reply]
Adding {{dead link}} is not usually a good idea for the ==External links== section. However, in the specific case of WP:ELOFFICIAL links for which you believe a working website to be reasonable (e.g., a company that is still in existence), it may occasionally be appropriate as a temporary measure (e.g., until someone can find the new corporate website). WhatamIdoing (talk) 01:05, 9 September 2024 (UTC)[reply]
Why is it not a good idea? It signifies that a human needs to make a decision about whether to remove the link, replace it with a working alternative or replace it with an archived version. Thryduulf (talk) 01:14, 9 September 2024 (UTC)[reply]
I too agree that we should discourage the blanket archiving of live links. It feels we're adding extraneous text to the references (and extraneous wikitext. Like jacobolus', my browser crashes when I turn on syntax highlighting on large pages; I wish it didn't) that are unlikely to be intentionally read or clicked on. Internet Archive is already doing us and our readers the great service of archiving pages linked to from our articles. If those links go dead, a bot is already doing the great service of linking to an IA snapshot of the page. I don't think the other much less common (I dare to assume) use cases merit so much text clutter. I agree with jacobolus that the scale of the linking feels like advertising for the service IA provides. Ajpolino (talk) 00:10, 9 September 2024 (UTC)[reply]
Hello. For many years, community members have requested an easy way to re-use references with different details. Now, a MediaWiki solution is coming: The new sub-referencing feature will work for wikitext and Visual Editor and will enhance the existing reference system. You can continue to use different ways of referencing, but you will probably encounter sub-references in articles written by other users. More information on the project page.
We want your feedback to make sure this feature works well for you:
Sign up here to get updates and/or invites to participate in user research activities.
We are aware that enwiki and other projects already use workarounds like {{sfn}} for referencing a source multiple times with different details. The new sub-referencing feature doesn’t change anything about existing approaches to referencing, so you can still use sfn. We have created sub-referencing, because existing workarounds don’t work well with Visual Editor and ReferencePreviews. We are looking forward to your feedback on how our solution compares to your existing methods of re-using references with different details.
Wikimedia Deutschland’s Technical Wishes team is planning to bring this feature to Wikimedia wikis later this year. We will reach out to creators/maintainers of tools and templates related to references beforehand.
This is a very important task to work on, but I am not sure how this proposal is an improvement for those of us who do not use the VisualEditor.
Compare:
<refname="Samer M. Ali">Samer M. Ali, 'Medieval Court Poetry', in ''The Oxford Encyclopedia of Islam and Women'', ed. by Natana J. Delong-Bas, 2 vols (Oxford: Oxford University Press, 2013), I 651-54.</ref>{{r|Samer M. Ali|p=653}}
or:
<refname="Samer M. Ali"/>{{rp|653}}
with:
<refname="Samer M. Ali">Samer M. Ali, 'Medieval Court Poetry', in ''The Oxford Encyclopedia of Islam and Women'', ed. by Natana J. Delong-Bas, 2 vols (Oxford: Oxford University Press, 2013), I 651-54.</ref><refextends="Samer M. Ali"name="Samer M. Ali, p. 653">p. 653</ref>
existing workarounds don’t work well with Visual Editor and ReferencePreviews OK, then VE and ReferencePreviews need to be fixed so that they work well with the existing ways of referencing.
Adding another competing standard (obligatory XKCD) is not very useful unless you want to disallow the others which will probably make people very mad (see WP:CITEVAR) and is not necessarily an improvement.
There is no reason why VE or RP would require a new standard, they could just as easily support one of the existing ones (and ideally all of em).
Sfn is routinely out of sync with its parent and requires the use of third party scripts to detect that it is so. Extended references do not i.e. the Cite extension will issue a warning when you have an extension without a parent.
And Rp is objectively subjectively ugly. Presenting it as a potential option is offensive. :)
In <refextends="Samer M. Ali"name="Samer M. Ali, p. 653">p. 653</ref>, a name for the subreference is not required (<refextends="Samer M. Ali">p. 653</ref> will be typical I suppose), and even when it is you can abbreviate since you know what the parent is (e.g. <refextends="Samer M. Ali"name="SMA653">p. 653</ref>).
Some other benefits:
Reference extensions work with reference previews to display the extension directly with the primary citation.
The extensions are grouped with the primary citation in the reference lists.
And the third, which you brushed aside: VE works well with reference extensions.
And as for OK, then VE and ReferencePreviews need to be fixed so that they work well with the existing ways of referencing., MediaWiki systems try to be agnostic about the specific things that wikis do around X or Y or Z. As a general design principle this helps to avoid maintaining systems that only some wikis use, and leaves the burden of localization and each wiki's design preferences to those wikis. Rp additionally has nothing to work with in regard to VE and ref previews. Izno (talk) 16:06, 19 August 2024 (UTC)[reply]
@Izno: Thank you. Gotta sell these things a bit, you know?
Is this style of referencing intended to replace all others? If its better, then lets just abandon all other variants.
The extends keyword is familiar to codemonkeys but perhaps not the most userfriendly for others. I am not sure why it would be harder to show an error when someone writes <refname="nonexistant"/>{{rp|653}} than when someone writes <refextends="nonexistant">p. 653</ref> but in theory this new system could auto-repair references (has that been considered?) Category:Pages_with_broken_reference_names contains 1300+ pages.
I agree with Izno—I'd rather have a syntax that integrates with the <ref>...</ref> syntax, rather than relying on templates, which mixes in a different syntax, and are wiki-specific. isaacl (talk) 16:28, 19 August 2024 (UTC)[reply]
If you control the parser you can make any string do anything you want so the currently chosen syntax is, in itself, no advantage or disadvantage. Polygnotus (talk) 16:31, 19 August 2024 (UTC)[reply]
You provided the wikitext for two examples and asked if one seemed to be an improvement, so I responded that in my opinion, the syntax of the sub-referencing feature under development is conceptually more cohesive to an editor than one where wikitext surrounded in braces follows the <ref.../> code, or uses solely wikitext surrounded by braces. Sure, any strings can be turned into any other strings, but there are still advantages of some input strings over others. I also prefer the resulting output of the reference list. isaacl (talk) 16:45, 19 August 2024 (UTC)[reply]
Agreed, but I assume that things are not set in stone yet. I don't mind the difference between [1]:635 and [1.1] or what exact wikicode is used. So I am trying to think about functionality (e.g. automatically repairing broken refs/automatically merging refs instead of how things get displayed/which wikicode is used). Polygnotus (talk) 16:47, 19 August 2024 (UTC)[reply]
I apologize as your first post seemed to be concerned about the wikitext markup being used by users of the wikitext editor. From a functionality perspective, I think as Izno alludes to, it will be easier to implement features such as detecting hanging references and merging them together with a syntax that is within the <ref> element, rather than relying on detecting templates and associating them with <ref> elements. That would require the MediaWiki software to treat some wikitext in double braces specially. (It would be easier if the extended information were flagged using triple braces, since it would avoid clashing with the extensible template system, but I don't see any advantages to that over extending the <ref> syntax.) isaacl (talk) 17:09, 19 August 2024 (UTC)[reply]
Please don't apologize to me (even if there would be a reason to do so, which there isn't), I am a very confused and confusing person and I understand myself roughly 4% of the time (and the world around me far less often than that). Polygnotus (talk) 17:14, 19 August 2024 (UTC)[reply]
Good to see this moving forward. My main interest was how it would look on the hover, rather than in the References section. I thought the ref extends might 'fill in' variable fields into the general ref, but it seems instead that it just created a new line below. How flexible is this below line, will it display any wikitext? Could we for example add chapters and quotes? (Which will need manual formatting I assume.) CMD (talk) 16:53, 19 August 2024 (UTC)[reply]
What parameters should be sub-referenced? It should be limited to page numbers, and quotes. Not, for example, multiple works, authors, volumes, issues, IDs, dates of publication, ISBN numbers, etc..
How is data in a sub-ref added? If it's free-form text, it's a step backwards from CS1|2's uniform |page=42 to a free-form text like "Page 42" or "(p) 42" or whatever free-form text people choose. Bots and tools need to be able to parse the page number(s). Free form text is not semantic. Templated text is semantic. Anything that moves from semantic to non-semnatic is bad design.
Before this is set loose, there must be consensus about how it should be used. It opens an entirely new dimension to citations that is going to impact every user, citation template, bot, bot library (PyWikiBot etc), tool, etc.. -- GreenC17:00, 19 August 2024 (UTC)[reply]
Yeah its also a bit weird to ask for feedback and then already have a proof of concept and say is planning to bring this feature to Wikimedia wikis later this year. You must ask for feedback before code is written and before any timeline exists. Polygnotus (talk) 17:05, 19 August 2024 (UTC)[reply]
At a minimum, it should not be added until there are clear guidelines for usage. More specifically, it should have a feature that issues a red error message if the sub-ref does not contain a special template for displaying page numbers and/or quotes ie. anything else in the sub-ref is disallowed. Then new parameters can be added once consensus is determined. We should have the ability to opt-in parameters, instead of retroactively playing cleanup removing disallowed parameters. -- GreenC17:18, 19 August 2024 (UTC)[reply]
@GreenC: So then you would get something like this, right?
<refextends="Samer M. Ali"page=""chapter=""quote=""anchor=""><refextends="Samer M. Ali">{{subref|page=""|chapter=""|quote=""|anchor=""}}</ref>
And then a form in VE where people can fill it in.
The former was deliberately not chosen during design work as being too inflexible for all the things one might want to make an extending reference. Izno (talk) 19:33, 19 August 2024 (UTC)[reply]
"All the things", which below you said was only page numbers, chapters and quotes. What else do you have in mind? -- GreenC20:04, 19 August 2024 (UTC)[reply]
There have been previous requests for support in CS1 for subsections of chapters of works. But that's beside the point: we don't need to lock this down out of some misbegotten idea of chaos. YAGNI. Izno (talk) 20:45, 19 August 2024 (UTC)[reply]
It will be chaos as currently proposed, though I never said "lock this down". Johannes asked for feedback. The two main issues I raised, Johannes already said, these are known issues. He said, make a guideline. So I suggested at a minimum, let's make a guideline. You and Johannes don't seem to be on the same page about that. You hinted that were part of the development team, is that correct? -- GreenC23:09, 19 August 2024 (UTC)[reply]
No, I am a volunteer interested in this work since when it was first discussed at WMDE Tech Wishes and/or the community wishlist and have been following it accordingly, working on a decade ago now.
Guidelines are descriptive also. "We usually use it for this, but there may be exceptions." is reasonable guideline text. "You are required to use it only for this." is another reason it's not going to fly. Izno (talk) 16:06, 20 August 2024 (UTC)[reply]
That's a shame, the former was precisely what I imagined and was excited for when I first read about the idea. CMD (talk) 02:36, 20 August 2024 (UTC)[reply]
@GreenC We don't do that with regular references. There's nothing in the software that produces a red error message if I do <ref>My cousin's roommate's friend told me</ref>, so why should subrefs be enforcing that? --Ahecht (TALK PAGE)19:37, 19 August 2024 (UTC)[reply]
@Polygnotus: This has been being discussed for many years now. m:WMDE Technical Wishes/Sub-referencing was created in 2018, and even then the idea had already been being discussed for a while. phab:T15127 was created in 2008. It's not odd that they're finally at the stage of having an implementation (or if it is, it's that it took so long to get here). Anomie⚔21:45, 19 August 2024 (UTC)[reply]
You should probably assume that's the situation for any MediaWiki change. A few years back, some user script authors were mad because a code change had been throwing error messages at them for "only" seven years(!), which was obviously too short a time frame for them to notice that anything needed to be adjusted. WhatamIdoing (talk) 23:06, 23 August 2024 (UTC)[reply]
I actually totally disagree and think you're making a mountain out of a molehill. My anticipation is that most people will use it for the obvious (page numbers). In some cases they may use chapters (a single long text with a single author or even for anthologies). Rarely do I anticipate them using anything else, but I think they should have the luxury of putting whatever they want in the reference.
As regards mandating some use like templates, that's not how it works, though I can imagine some sort of {{Cs1 subref}}... which is probably basically {{harvnb}} and some others.
One thing however that is sure not to occur is to have subreferences of subreferences. This should prevent the vast majority of pathological cases. Izno (talk) 19:32, 19 August 2024 (UTC)[reply]
Uh, yeah. People have successfully used our current mechanisms for extending a parent reference in many many ways which notably don't fit what you want. Izno (talk) 20:44, 19 August 2024 (UTC)[reply]
/me looks back 20+ years… sure is a good thing we wrote all those guidelines before making a wiki that was to become the most popular encyclopedia……. —TheDJ (talk • contribs) 07:20, 20 August 2024 (UTC)[reply]
No one's stopping you from writing some guidelines. There might not even be any opposition if you put sensible things in it. But as Izno says, the guidelines would be advisory rather than prescriptive. – SD0001 (talk) 14:03, 20 August 2024 (UTC)[reply]
When a document has a nested structure, e.g., chapters within sections, it is natural for an editor to want citations that match that structure. I would expect nested citations to include arbitrary combinations of author, editor, page, quote, title and URL, depending on the type of document. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:15, 19 August 2024 (UTC)[reply]
Does "will work for wikitext and Visual Editor" cover the list-defined references examples on the demo page? I'm testing right now and the Visual Editor still seems to have the same problems with list-defined references that have existed for some time.[6] Will this update fix any of those issues? Rjjiii (talk) 02:28, 20 August 2024 (UTC)[reply]
Hi, thanks for your feedback, questions and interest in sub-referencing! Given the large number of comments, I’ll try to provide answers to all of them at once:
replacing other referencing styles: We don’t intend to replace other citation styles. We are fulfilling an old community wish, creating a MediaWiki solution for citing a source multiple times with different details. Citation styles are a community matter and per WP:CITEVAR you can continue to use your preferred way of referencing. If the community wants certain referencing templates to be replaced by sub-referencing, they are of course free to do so, but that’s up to you.
Reference Previews are going to display both main- and sub-reference in one reference pop-up, showing the sub-reference’s details below the main information (example). There are still a couple of details going to be fixed in the next couple of months.
ReferenceTooltips (the gadget enabled by default at enwiki) will need an update. It currently only displays the sub-reference’s information (example), similar to the behavior with sfn (example). But different to sfn (example) it currently doesn’t show a pop-up on top of the first pop-up for the main information. Given that gadgets are community-owned, we won’t interfere with that, but we’ll try to assist communities in updating the gadget.
Yes it will be possible to display any wikitext in sub-references, just like it is possible to do so using normal references (without any templates). We’ve intentionally allowed this, because local communities prefer different citation styles (and even within communities users have different preferences), therefore our solution shouldn’t limit any of those. Citing sources with different book pages will probably be the main reason to use sub-referencing, but it’s also possible to use it for chapters, quotes or other details.
You’ll need to do the formatting (e.g. writing details in italic) yourself, except if the community creates a template for sub-references
List-defined references in VE: We are aware of the issues mentioned in phab:T356471, many of those also affect sub-references. As we are still defining some VE workflows (currently we’ve mostly worked on the citation dialog) we haven’t found a solution yet, but we might be able to resolve at least some of those issues while continuing our work on sub-referencing in Visual Editor.
As already mentioned on meta this should be up to local communities, given the many different referencing styles. It should also be up to them to decide if they want to use templates for sub-referencing or not. We’ve reached out to communities much in advance, so you should have enough time working out some guidelines if your community wants that.
But as Ahecht said: Users can already use references for all kinds of unintended stuff, sub-referencing is not different to that. It’s necessary to technically allow all kinds of details in sub-references, due to the many different citation styles within one community and across different communities.
From our user research we expect most people using sub-referencing for book pages. There will be a tracking category (example) which could be used to check if there is unintended usage of sub-referencing
Adding another referencing style isn’t really useful: We are fulfilling a wish which is more than 15 years old and has been requested many times in the past years. Existing template-based solutions for citing references with different details only work on those wikis who maintain such local templates – and most of those have issues with Visual Editor. That’s why a global MediaWiki solution was necessary. You can always continue to use your preferred citation style per WP:CITEVAR.
Doesn’t look like an improvement for Wikitext: If you compare it with template-based solutions like {{rp}} you are correct that those allow for simpler wikitext. But if you’re editing in multiple Wikimedia projects, your preferred template from one project might not exist on the other one. That’s why a MediaWiki solution will be beneficial to all users. And most current template-based solutions have the already mentioned disadvantages for Visual Editor users. Also readers will benefit from a more organized reference list by having all sub-references grouped below the main reference.
The attribute “extends” doesn’t seem user friendly for non-technical users: We’ve done several consultations with the global community and a lot of user testing in past years where we asked for feedback and ideas on the attribute name. One takeaway is that the name is less important for many users than we initially thought, as long as they can remember it. And our user tests showed a surprisingly large number of Wikitext users switching to VE in order to use the citation dialog (for referencing in general, not just for sub-referencing) – if you do that, you don’t need to deal with the attribute name at all. We didn’t see any major issues with “extends” for people exclusively using Wikitext in our user tests. But so far there is no final decision on the attribute name, so if you have any ideas let us know (we’ll make a final decision soon).
You should have asked for feedback earlier: We’ve been working on this feature (on and off) for almost 8 years and had a lot of community consultations (e.g. at Wikimania, WikiCite, discussions on metawiki where we invited communities via Mass Message) and many rounds of user testings – always with the involvement of enwiki users. And we are doing this big announcement now in order to make sure that really everyone knows in advance and can provide further feedback while we are finalizing our feature.
Perhaps it would be wise, in future, to make a list of predictable reactions/questions and incorporate the responses to those in the announcement. Highlighting the advantages of a change/addition, USPs if any, why decisions were made and perhaps even a short timeline can make the reception much warmer. Some people here (e.g. Polygnotus) don't know the 15 years worth of background information. The good news is that I think that it is an improvement (although it could be a bigger improvement). I assume others have also mentioned things like ensuring refs don't break and automatically merging refs (but I do not want to dig through 15 years of history to figure out why it wasn't implemented) and this is/was an opportunity to make something superior to the existing methods that could replace them. The OrphanReferenceFixer of AnomieBOT will need to be updated. Polygnotus (talk) 17:04, 20 August 2024 (UTC)[reply]
It's always difficult to write such announcements in a way that they answer the most important questions while also being short an concise so that people actually read the them ;) Some of the questions raised in this section have already been answered in meta:WMDE Technical Wishes/Sub-referencing#FAQ and we'll continue to add more frequently asked questions there, if we notice (e.g. in this village pump discussion) that certain questions come up again and again. Johannes Richter (WMDE) (talk) 17:16, 20 August 2024 (UTC)[reply]
Agreed, it is super difficult to strike the right balance. And even if you do, some will still be grumpy. But its also very important. Polygnotus (talk) 17:20, 20 August 2024 (UTC)[reply]
Thanks for the detailed response and the included screenshots. I was a bit glum following my comment above but I think I have a better grasp of the underlying concept now. If we are able to use citation templates in the sub-reference field, that may provide a way to fix at least some of the potential issues raised above. Is there a place to track changes to the reference pop-up (File:Sub-referencing refpreview.png)? My first impression is that's perhaps not a necessary large white space but I'm curious to read more discussion on the matter. CMD (talk) 17:25, 20 August 2024 (UTC)[reply]
@CMD depends on what you mean by "place to track changes"? There are several phabricator tags which might serve this purpose (although we've collected a lot of user feedback which is still under discussion and therefore not filed as a task yet). We want to use meta:WMDE Technical Wishes/Sub-referencing#Recent changes and next steps to document important changes on the current prototype and can certainly document further changes to Reference Previews for sub-referencing in this section as well, if that's what you imagined? Johannes Richter (WMDE) (talk) 15:43, 21 August 2024 (UTC)[reply]
Thanks for the lengthy reply! Can a template tell if it's being used in an extended reference?
If there is any probability of this all working in the Visual Editor, we should also aim to make templates that work in the Visual Editor. That would mean a template that slots inside of an extended reference, rather than a template that invokes one (the way that {{r}} or {{sfn}} work). There is already some discussion at Help talk:Citation Style 1 about building a template for consistency between the main named reference and the extended sub-references. I considered making a proof of concept template that would only handle pages, quotations, and so on, but folks have already mentioned citing named sections in a larger work and other broader ideas.
For a template to plug into this, I've checked the parameters currently available in major templates that cite locations within a longer work. If I've missed anything feel free to update this table:
In-source location parameters in existing templates
Also, regarding formatting, CS1 and sfn are based (to an extent) on APA and Harvard citation styles.
Also(B), regarding LDR, one of the issues with list-defined references in the Visual Editor is that removing all usage of a reference from an article's body text makes the reference become invisible in the VE and emits this error message on the rendered page, "Cite error: A list-defined reference named "Bloggs-1974" is not used in the content (see the help page)." To have an un-called reference isn't exactly an error, though. Editors move citations from the bibliography and standard references down to other sections (Further reading, External links, and so on); some articles still have general references at the bottom. Is there a way to push un-called references down to the bottom of the list and treat them as a maintenance issue rather than an outright error, like the below example with citations borrowed from Template:Cite book/doc(11-02-2024)
Can a template tell if it's being used in an extended reference? No, not currently. Lua experts feel free to correct me if I am wrong. Polygnotus (talk) 02:57, 21 August 2024 (UTC)[reply]
push un-called references down to the bottom of the list and treat them as a maintenance issue it isn't even a maintenance issue; it is useful if people name refs so that those names can be used later to refer to those refs. But if no one refers to em that is fine. Polygnotus (talk) 03:01, 21 August 2024 (UTC)[reply]
Indeed to best of our knowledge templates currently cannot tell if they are being used in a sub-reference. But it should be possible to make such changes. As templates are community-owned, we cannot do that ourselves, but we'll try to assist communities (e.g. by providing documentation or some examples) with the necessary changes to citation tools and templates. Johannes Richter (WMDE) (talk) 15:47, 21 August 2024 (UTC)[reply]
Yes, additional parameters might be needed on <ref>...</ref> and on citation templates to designate main and sub-references.
LDRs that are named but not cited are most definitley treated as errors; that doesn't mean that they should be treated as errors. There are other markup languages where uncited references are treated as legitimate. Admiitedly {{Refideas}} is a workaround, but it would be nice if {{Reflist}} could include incited references and if the LDRs were listed first. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:20, 21 August 2024 (UTC)[reply]
Strange short description - how to fix it?
I started typing "Space-Men" in the search bar and it suggested the Space-Men article with the strange short description of 1960 Italy?'"`UNIQ--ref-00000004-QINU`"'? film. It shows up in the page information page that way too, but not in the article's source/wikitext, so I'm not sure how to fix it. Any ideas? 28bytes (talk) 17:34, 26 August 2024 (UTC)[reply]
{{Infobox_film}} builds a shortdescription from the country. The country ends with a reference. A reference gets replaced by a strip marker, for technical reasons. But a short description doesn't have wikitext support, so the stripmarker is not automatically replaced/removed. The template that adds the automatic short description should be updated to strip the strip markers. —TheDJ (talk • contribs) 18:27, 26 August 2024 (UTC)[reply]
While my effort to fix it evidently didn't address the underlying issue, if you're going to slap my hand you could at least acknowledge that I made a good-faith effort to fix the most immediate problem that was presented in the OP, and that I made it clear in my own message that I wasn't sure that I'd really fixed it at all. I'm not sure what you're talking about with the second part of what you've said, unless you meant to say that I could have posted it there. Except that I couldn't have posted it there because I didn't know that the underlying issue was with the template, nor did the OP indicate that the issue lay with the template. DonIago (talk) 20:17, 26 August 2024 (UTC)[reply]
After thinking more on it, I agree. Fixing the broken case as a temporary measure seems fine, not different from CSS fixes people make. I do think VPT should try to find the root cause of problems, but I don't think DonIago's change should have been reverted while the problem is not fixed.
I'm unclear if the strip markers not being detected is a larger issue, or something that needs to be coded into Template:Infobox film/short description. Nthep and DJ's comments made it seem like an easy fix, so I restored Space-Men to using the auto-generated SD so it will be as it was prior to the issue and utilize that auto SD. But if it is not an easy fix, then yes, we can implement the workaround that Doniago did. - Favre1fan93 (talk) 16:10, 28 August 2024 (UTC)[reply]
The problem is fairly common where the infobox generates a short description from values found in the infobox. Often a country is expected, but the country name turns out to be a list of countries. Often (like here) a field is expected to be a simple piece of text, but has a reference appended or includes an extra formatting template. In this case, the reference should be moved into the article text – the infobox should be only a summary of details that are present in full in the article. Otherwise, just add a manual SD like DonIago did. The sandbox is well out of date, so I assume that nobody has signed up to fix the template? If not, can we please just fix the Space-Men article? It hurts — GhostInTheMachinetalk to me18:16, 30 August 2024 (UTC)[reply]
Ah. I would have first tried {{Strip tags}}. Is that too aggressive? However, us mortals make such changes. We need somebody with superpowers to fix the infobox template for us. So, for now, I just fix individual articles as I find them — GhostInTheMachinetalk to me21:41, 30 August 2024 (UTC)[reply]
I just tried to fix a few examples and it's taking way too long. As a busy practicing attorney, I don't have two hours to spare to clean up someone else's mistakes. I have better things to do with the Labor Day holiday weekend, like going through more of my photography library to identify more photos for upload to Commons.
One of the longest running debates among lawyers for many centuries is whether a trial court should be organized as a nationwide or statewide entity that merely happens to sit in multiple counties, districts, or circuits—or whether each county, district or circuit should be regarded as having an entirely separate trial court. There are strong public policy arguments for and against each position, resulting in worldwide gridlock on this issue.
California is among the majority of American jurisdictions that adhere to the latter position. In other words, it has 58 superior courts, not one superior court that happens to sit in 58 counties. Section 1 of Article 6 of the California Constitution refers to "superior courts" (notice the plural) and Section 4 starts with the following words: "In each county there is a superior court of one or more judges."
Unfortunately, User:Mliu92 created many articles for superior courts that imply that California adheres to the former position. For example, the article for Santa Cruz County Superior Court incorrectly states that the "Superior Court of California, County of Santa Cruz, is the branch of the California superior court with jurisdiction over Santa Cruz County."
We need a bot to go through the English Wikipedia and replace every instance of the phrase "is the branch of the California superior court" with the phrase "is the California superior court". How do I go about initiating that request? Coolcaesar (talk) 19:11, 31 August 2024 (UTC)[reply]
I'm a long time editor. Throughout my career, I have used Safari. I am not updated to the most recent OS because my computer cannot handle it. I have no problem editing in mainspace. However when I make an edit to a talk page (even this page), if I move my cursor, the next capital letter will jump the cursor to the first character of the edit box, meaning I have to go back to move all sentences through cut and paste. It's obnoxious. It makes it hard to concentrate when so many sentences now constructed in reverse order need to be moved.Trackinfo (talk) 19:40, 2 September 2024 (UTC)[reply]
@Rusalkii: Do you mean the box with the rows having differently-coloured backgrounds, or the list below the heading 'Pages in category "Wikipedia conflict of interest edit requests"'? They have different origins.
The second one is the primary list, it is driven directly by the use of the {{edit COI}} tag (with no parameters, or with certain param values) on a talk page, and it should update at the exact moment that you save an edit that adds e.g. |D or |answered=yes to the tag.
If you mean the box, it's transcluded from User:AnomieBOT/COIREQTable which is built periodically by AnomieBOT (talk·contribs). I would not expect this to update instantaneously, a delay of minutes or hours is not uncommon. If AnomieBOT is not updating the page, that's a matter for the bot operator, i.e. Anomie (talk·contribs), but please read the bot's User: and User talk: pages before raising what might be a duplicate complaint. --Redrose64 🌹 (talk) 07:26, 3 September 2024 (UTC)[reply]
Wanted to ask about a recurring problem I run into occasionally when working with Wikipedia:Database reports/Polluted categories to clean up userspace content in articlespace categories. When I use each category's "search user namespace" link in that report, I will either get a list of one or more userspace pages, or the text "There were no results matching the query" — the majority of the time, the latter means that the category has already been cleaned up, either by me via another query earlier in the batch (since pages are often in more than one category at the same time) or by somebody else before I even got to it. However, on occasion there are categories on a redirect in userspace, which the search link seems to fail to detect because it's a redirect instead of a straight sandbox "article", and thus tells me that the category is already clean when it actually isn't.
So because the link failed to detect the redirect and told me that the category was clean, I just move on, but because the category isn't actually clean, that redirect just stays in the category until I notice, on a future run of that report, that the search link was purple (meaning I've visited that exact search link before) and the category is still empty — meaning that I have to take the extra step of manually eyeballing the category to see if there's a userspace redirect in it. Examples: User:Upgov.in/sandbox, which had been in categories since August 19, and User:Luis Santos24/sandbox2, in categories since August 11, meaning they both survived multiple regenerations of the report before I finally caught them today.
TLDR, the polluted categories report does catch userspace redirects, but the search link fails to find them when I use it.
However, since the majority of "there were no results matching the query" categories are actually genuinely clean, it wouldn't be a productive use of my time to consistently double-check every category whose search link produces that result across the board — so my question is whether somebody can look into ensuring that the incategory search stops failing to detect redirects so they can be caught the first time instead of loitering around for multiple regenerations of the report. Bearcat (talk) 17:51, 3 September 2024 (UTC)[reply]
Well, then, is there any other way to solve the problem besides the total non-starter "just let userspace redirects survive multiple regenerations of the report before getting caught" or the total non-starter "manually double-check every single category that came up as already empty"? Bearcat (talk) 18:07, 3 September 2024 (UTC)[reply]
I feel like specifying formulas inline could be susceptible to subtle vandalism which would be undesirable. I'm also seeing mentions of eval, can you comment on how this calculations are being done ? (I'll note evaling user-generated content on Wikimedia sites should probably be a no-go from a security POV). Sohom (talk) 16:57, 5 September 2024 (UTC)[reply]
Everything on Wikipedia is susceptible to vandalism; it doesn't mean we stop mentioning people's birth dates and other details which can be subtly fabricated. The calculators could be made templates which can be protected if necessary. Evalling is fine if inputs are sanitised. – SD0001 (talk) 17:10, 5 September 2024 (UTC)[reply]
@SD0001 Wrt to the first point, my thought process was that manipulating birthdays would be a lesser issue than manipulating a BMI calculator that could be potentially be used by people to self-diagnose metabolism disorders. Regarding the rest, on looking further at the code, I agree that security shouldn't be a issue for it's current version, however, it would be nice to document the method the script uses anyway (as a comment) to make sure future editors of the script are aware of this consideration. Sohom (talk) 19:33, 5 September 2024 (UTC)[reply]
The tl;dr is that the formulas are parsed using a simple Recursive descent parser into an AST type structure. The AST is evaluated by walking through the tree. In the tree there are OP nodes that represent an operation from a fixed set of valid operations implemented in javascript. A dependency graph structure is also created in order to refresh any widgets that depend on a value that was changed with loop detection. Bawolff (talk) 19:41, 5 September 2024 (UTC)[reply]
@Sohom Datta this would serve the user some javascript, execution is client-side via browser. The script code itself could only be modified by interface admins. The current script would always be viewable by anyone, and is currently available to see at this link. — xaosfluxTalk19:30, 5 September 2024 (UTC)[reply]
See my comment just above regarding this, I agree that is probably safe, but it would make sense to document the security considerations in the code for future interface admins/script editors. Sohom (talk) 19:36, 5 September 2024 (UTC)[reply]
Map error
Over on the article Bagar region there's a big red error showing at the top of the article, "<mapframe>: The JSON content is not valid GeoJSON+simplestyle." I've never seen this before and don't know how to fix it, so I thought I'd put it here to bring it to the attention of anyone who does know how to fix it. Suntooooth, it/he (talk/contribs) 21:04, 4 September 2024 (UTC)[reply]
Figured this would be the place to see if anyone knows what's going on. Historically, Wikipedia:Redirects for discussion has been a rather expensive page, processing-wise, But what is currently going on has not happened at any point recently. The bottom-most sections are appearing as links instead of sections. This was not the case a few weeks ago. Does anyone know what's going on? Steel1943 (talk) 22:29, 4 September 2024 (UTC)[reply]
It's been categorized as >2,000,000 PEIS since 01:00, 2 September 2024 [8] and as >500 expensive parser calls since 02:28, 2 September 2024 [9]. Anything happen just over 3 days ago? SilverLocust💬02:38, 5 September 2024 (UTC)[reply]
Though the reason why the expensive parser function limit was hit is simple enough. There are >500 redirects currently nominated, and therefore >500 instances of
This happened to us a few years ago at TFD when we embarked on a project to delete a few thousand unused and redundant templates. We had to slow down our nominations and list some of them on subpages. – Jonesey95 (talk) 05:02, 5 September 2024 (UTC)[reply]
The inexpensive alternatives are (1) a non-redirecting link that doesn't turn red after the RfD is closed as "delete" (or it's otherwise deleted), or (2) a normal wikilink that doesn't prevent redirection once the RfD is closed as "keep" (or the RfD banner is removed). SilverLocust💬07:15, 5 September 2024 (UTC)[reply]
Unless {{No redirect}} gets updated in a way that prevents expensive parser calls, I think either Option 2 or weak Option 3 is the winner there. The redirection should be prevented when the discussion is in progress due to the substitution of {{Redirect for discussion}} on the nominated redirect(s), and the option also allows the link to be red on the RfD if the redirect ends up being deleted. I can see a reason to have both links though, so my "weak option 3", but I don't see that option incredibly user-friendly as option 2. Steel1943 (talk) 19:46, 6 September 2024 (UTC)[reply]
When searching for the article Faya Dayi, the short description that shows up is "2021 ?'"`UNIQ--templatestyles-00000002-QINU`"'? film". Does anyone know why that would happen? It looks like something on the page ({{Infobox film}}?) is supposed to set it to "2021 film" but ends up inserting some kind of markup in the middle of the text. hinnk (talk) 09:43, 5 September 2024 (UTC)[reply]
How do you add extra language links to an article these days? The link now says "No languages yet." (untrue) and gives options to "Translate this page" (not what I want) and "Open language settings" (not what I want). I used to just give an option to add another link. I can do this on the other languages but not on the English Wikipedia. Hawkeye7(discuss)09:57, 5 September 2024 (UTC)[reply]
Which article? I can see "Add languages" then "Edit interlanguage links" which goes to wikidata where can enter names of articles in other languages. If the article isn't linked to Wikidata yet can do it manually or wait for it to be linked. Indagate (talk) 10:15, 5 September 2024 (UTC)[reply]
I have never added languages in Vector 2022 so I don't know how it's supposed to work but I cannot find a way to do it if there are no languages or Wikidata item. I picked Mayank Vahia at Special:NewPages. The top right says "Add languages" but it only gives a search box which does nothing no matter what I try, and the options "Translate this page" and "Open language settings". They don't appear to have a way to add a language. Are you saying it's meant to not work for new pages? It would be awful design to give users an "Add languages" link which cannot add languages. PrimeHunter (talk) 11:47, 5 September 2024 (UTC)[reply]
I tried going to Wikidata ... but I should never have to go there. When you use the "Edit links" feature, you are always taken to Wikidata: that is the way that interlanguage links are always added, ever since Wikidata was launched in early 2013. --Redrose64 🌹 (talk) 17:39, 5 September 2024 (UTC)[reply]
Although your English Wikipedia account was created in June 2005, almost three years before WP:SUL came in, nowadays you should be automatically logged in on all other WMF wikis, including Wikidata. --Redrose64 🌹 (talk) 19:26, 5 September 2024 (UTC)[reply]
That stopped working a while ago. What I meant though, was that I opened a new tab, put in the URL of Wikidata, and logged in there to look at what was going on. I don't normally touch Wikidata because I lack expertise. Hawkeye7(discuss)07:07, 6 September 2024 (UTC)[reply]
Looking at other new articles, they have the same poor drop down box, but with a third option "Edit interlanguage links". Unfortunately, this takes you to Wikidata, which we don't want. In my case, it could not find the Wikidata item (although it existed), so (incorrectly) did not offer the option at all. Hawkeye7(discuss)11:59, 5 September 2024 (UTC)[reply]
I have recently noticed that, in navigation templates (both navboxes and sidebars), on an article, that article's entry appears clickable. The entry is correctly bold black (ie not a blue link) but when hovered over it displays as a clickable black link, ie, the I-cursor becomes a pointer, though no action occurs.
For example, on Sockeye salmon, see the horizontal Salmon nav box at bottom. The entry for Sockeye salmon is correctly appearing black but seems clickable.
Similarly, on Battle of Elands River (1900), see the Transvaal Front vertical side campaign box. The article's entry rightly appears black but seems clickable.
When logged out, in dark mode, at {{Soulfly}}, the actual link for Soulfly is an extremely dark grey that is difficult to see on a black background. It was not this way before. Does anyone know how to fix this? --Jax 0677 (talk) 15:47, 5 September 2024 (UTC)[reply]
I have a script that runs whenever I start up or shut down my laptop.
I created the script quite a while back to experiment with the Wikipedia API, and have generally ignored it since.
The script records in a log file, my Wikipedia edit count and the number of edits so far today.
It also checks the running total — does the edit count at the end of yesterday + the edits today = the edit count for the end of today?
When the total fails to match, it indicates that some edits have been "lost" because a page that I edited today was deleted during the day.
Fair enough, if I am motivated, I can look up the page for which the edits were lost — even if I now cannot see my own edit summaries.
Today, however, the script alerted me to a mismatch in the other direction.
At the end of 3 September, my edit count was 74,841
During 4 September I made 168 edits
My edit count at the end of 4 September was reported as 75,008
Now, call me picky, but I think the total should be 75,009.
Replag is zero, and edits today are being correctly counted (although the grand total is still out by one).
While inexact edit counts is not a cosmic catastrophe, I am offended when maths seems to break.
Increasing the edit count is a separate step after saving the edit, and occasionally it can fail. I had a look for related issues in Phabricator, and apparently there's an issue known as T369461 that occurs about 30 times per day, preventing some edits from being counted. Maybe one of your edits was among the unlucky ones.
There are also some actions that create edits, but don't increase an edit count. Moving a page with a redirect creates two revisions (one on each title), but only counts as one edit. Protecting a page creates a revision, but doesn't count as an edit. It doesn't seem like you moved any pages yesterday though: Special:Log/move/GhostInTheMachine (but you did today, so you might see a new discrepancy).
Also, revisions imported from another wiki will show up in your contributions, but won't be counted. Did you know that on German Wikipedia, you have 10 edits, but your edit count is 1? They usually import the history of pages when translating them. That's not what happened here, given Special:Log/import, just mentioning it as a curiosity.
Thanks for the info. So it is possible that anybody's overall edit count could be short by a small number of edits. I suspect that I could conjure a query to derive a "better" version of my count from the revision table (and the archive table?). Maybe a project for a rainy day ...
Using Firefox and Dark Reader with Light Mode on, the icons are the same hue as the background and are not visible.
Fix by using Wikipedia's new Dark Mode? Not so fast. The background is too dark and the text is too bright. My eyes hurt when looking at it, and they don't hurt when using Dark Reader. This issue has already been raised by multiple users,[11] and will no doubt be solved in a timely fashion. But until then it would be nice to hit the undo button on whatever happened this week to the icons.
As my account has now been "blocked" - I began to ponder, peacefully - if Wikipedia has a forum of experts who deliberate as a technical team to "block or not" or is it an individual who decides and activates a "block" on a fellow wikipedian?
I will patiently await a response or redirect to an article addressing my concerns. ZAWADI NPC (talk) 07:57, 6 September 2024 (UTC)[reply]
You were advertising on your page. Advertising is not allowed on Wikipedia, not even on your page. You don't own that page – it is only there to show people what kind of Wikipedia editor you are, not anything about your business. You may say something about hobbies or interests that you don't get money from, for example if you take great photographs and put them on Wikipedia (for free of course), then you can say so. TooManyFingers (talk) 19:23, 7 September 2024 (UTC)[reply]
Advanced Mode issues
I have been having this issue for a while now and would like some help solving it. I use Advanced Mode as a mobile user. Occasionally, going to some pages in the Wikipedia or User namespaces will show me the non-Advanced Mode UI. Going to another page typically fixes this, and going into Settings shows that Advanced Mode is still turned on. This seems to happen most often when clicking a link from one Wikipedia namespace page to another page in that namespace, but will sometimes also happen in other circumstances. There is no visible pattern to when it happens. Does anyone know why this happens or how it can be fixed? Thanks, QuicoleJR (talk) 14:42, 6 September 2024 (UTC)[reply]
@QuicoleJR thank you, was clarifying if you were using the browser or the Wikipedia App. For your browser, assuming you are using Safari? Are you using the current version of Safari? — xaosfluxTalk14:55, 6 September 2024 (UTC)[reply]
Actually, no, I do not use Safari. I use the Google app (not Google Chrome, Google itself). I am using the current version of Google AFAICT. QuicoleJR (talk) 15:01, 6 September 2024 (UTC)[reply]
Works for me. I null-edited the Infobox template. Editing the /doc template should, in a perfect world, immediately provide a null edit to the single page that transcludes it, but it rarely does so. – Jonesey95 (talk) 22:25, 7 September 2024 (UTC)[reply]
I was able to reproduce earlier in Firefox up to date, but no longer. Maybe indeed it was a question of needing a null edit. Izno (talk) 22:39, 7 September 2024 (UTC)[reply]
No search box for default skin
The search box at the top of the main page en.wikipedia.org is absent on the default skin, at least on certain browsers. There is an empty area where it would belong, but there's nothing visible or clickable there. This happens at least on some versions of Chrome. The default skin on mobile is still working fine. On desktop, switching skins fixes the problem. Could this be dark mode related? TooManyFingers (talk) 16:39, 7 September 2024 (UTC)[reply]
I found my problem.
1. Clicking the magnifying glass icon is now required, to use the search box.
Clicking the icon should be required only at smaller resolutions. But it should still be visible, so something there is weird. Izno (talk) 18:39, 7 September 2024 (UTC)[reply]
@Roastedbeanz1: Your post could refer to different situations. Describe what you did from the start, what you expected and what happened instead. Save and link an edit where it happened. If you tried to add templates using source code like {{...}}} in VisualEditor then it's not supposed to work. VisualEditor has its own way of adding templates. See Help:VisualEditor#Editing templates. PrimeHunter (talk) 09:20, 8 September 2024 (UTC)[reply]
I noticed that my userpage was in Category:Pages with image sizes containing extra px. As it turned out, this was because I had specified |widths=80px. Removing the px solved it. This appears to be a WP:PXPX issue.
Checking a random sample of a dozen pages of the currently 8k+ in the category, I found that, in all cases, the member pages had the exact same issue with |widths= and/or |heights= specifications. Paradoctor (talk) 10:25, 8 September 2024 (UTC)[reply]
This is phab:T374311. I think it has always been suggested to include px in gallery sizes but now it adds the new tracking category. I think the gallery tag or tracking code should be modifed to allow one px in gallery wikitext without triggering the category, rather than mass-removing old px from all wikis to avoid the category. The suggestion to include px was removed from mw:Gallery examples yesterday and today.[12]PrimeHunter (talk) 12:49, 8 September 2024 (UTC)[reply]
Auto-expand "Learn more about this page" on navigation to anchor
This is with reference to the trouble a user reported at Talk:Turkey#Extended-confirmed-protected edit request on 12 August 2024 and similar reports I've seen elsewhere. In mobile view, the tags at the top of a talk page are hidden under an expandable link reading "Learn more about this page". These tags may include, among other things, a FAQ tag. When, in a discussion on the page, we want to route an inquiring editor to the FAQ (such as to Talk:Turkey#FAQ), we can't do so for a mobile user because the link doesn't work and the user, even if they scroll to the top (which is now the second thing they've tried in their attempt to see the referenced material), don't see the FAQ and don't see the third thing, clicking "Learn more about this page" that they'd have to do to get there, or perhaps at that point they've already given up.
Is it possible through some feat of CSS and/or Javascript wizardry to cause the top material to expand automatically upon navigation to an anchor that's within it? Largoplazo (talk) 17:31, 8 September 2024 (UTC)[reply]
While attending Wikimania this year, Selena Deckelmann (User:SDeckelmann-WMF) demonstrated a new feature for Visual Editor, Edit Check in a session. Edit check introduces additional prompts in Visual Editor when an editor tries to insert a blacklisted URL as reference and also when they try to publish a revision without inserting a reference. This greatly helps with encouraging editors inserting references in their edits. If I recall correctly, the percentage of editors inserting references increased from 11% to 40% in their tests (do correct me if I am wrong as I am going off on my recollection).see #What's next? for corrected stats
There is certainly some benefits in enabling this, primarily on improving the verifiability and reliability of content that's on English Wikipedia. Most of the sister projects have already been deployed with this feature. English Wikipedia does not have this feature enabled yet. The only thing that is holding back this feature is that Visual Editor is not set as the default editor for anonymous and new editors.
Therefore, I would like to propose that:
Visual Editor be the default editor for anonymous and new editors.
The last time I checked, new editors are presented with a pop-up box that asks them to choose which editor they'd like to use, with the solid blue button pushing them a bit toward the VisualEditor.
This thread is rather underdeveloped. For a proposal of this magnitude, I think we should figure out relevant factual questions (like what the current default is) and then draw up a more formal survey that could be CENT-listed, etc. Sdkbtalk19:05, 9 August 2024 (UTC)[reply]
Another question is how does it work with edits that don't need references adding (e.g. creating redirects, adding links on disambiguation pages, fixing spellings, etc)? Thryduulf (talk) 19:08, 9 August 2024 (UTC)[reply]
In theory, this sounds like a great idea. I'm eager to try it out, but I think a first step would be to make it available as an opt-in on enwiki. Then after people have got some experience with it, let's come back and talk about making it the default. RoySmith(talk)20:09, 9 August 2024 (UTC)[reply]
There's a simpler option for userscripts that should work: window.MWVE_FORCE_EDIT_CHECK_ENABLED=true;
So long as that's there before VE loads, it should force you to have edit check. Either method also bypasses the account restrictions on edit check, so you're not quite getting the pure experience that people would if we just turned it on for enwiki. By default it only shows up for new users (defined as under 100 edits), and someone might want to edit the configuration on-wiki for that. DLynch (WMF) (talk) 21:26, 9 August 2024 (UTC)[reply]
The add-reference check is very conservative currently. You need to be a user with less than 100 edits who has added a whole new paragraph of at least 50 characters (configurable per-wiki) that contains no references before it'll pop up. This can all be loosened up in the future, whether by default or through community configuration, but we figured that those criteria had pretty low odds of being a false positive to start with.
It's quite interesting that this boosts the percentages so much, because I honestly thought that complete new-editors would be doing far more minor edits. But no, major new blocks of text are pretty popular.
It's actually turned on with the reference check everywhere but 8 of the wikipedias (bn, de, en, hi, id, nl, pl, ru), so it's pretty easy to try it out on another wiki if you don't want to jump through userscript hoops here. DLynch (WMF) (talk) 21:34, 9 August 2024 (UTC)[reply]
Not sure where ReplyTool will put this, but nothing I'm seeing in the documentation requires VE to be the default editing interface in order to deploy the new tool. So deployment doesn't seem contingent upon answering the larger question of whether VE should be default. Folly Mox (talk) 22:17, 9 August 2024 (UTC)[reply]
Unless things have changed in the last year, it doesn't need it to be the default, but editor does need to be in the visual editor, and that's somewhat more likely to happen (especially for the editor's first edit) when the visual editor is the default. WhatamIdoing (talk) 01:29, 10 August 2024 (UTC)[reply]
The functionality is targeted towards new editors and anonymous editors, therefore the need for Visual Editor to be the default before the deployment of the functionality is considered complete. Also there are on wiki configuration options that we may want to adjust. As stated by Dlynch (WMF) above, the tool is configured by default for an user with less than 100 edits and making revisions of more than 50 characters. – robertsky (talk) 04:15, 10 August 2024 (UTC)[reply]
Minor quibble: enwiki has already got the prompts about blacklisted URLs for references/links. We rolled those out everywhere on the logic that any edits involving them were going to get blocked-on-save anyway so it wasn't going to disrupt any workflows. :D
It's a bit fuzzy because we called the project "Edit check", and we're developing a specific system called edit check (of which the "add reference" check is the first example), but we're also doing smaller edit-enhancement features along the way that colloquially get called checks just because of the project.
Conduct a thorough analysis of the potential consequences of setting Visual Editor as the default for anonymous and new users. Consider factors such as user experience, editor retention, and overall editing patterns. If making Visual Editor the default is not feasible, investigate other strategies to increase Edit Check adoption. This could include targeted outreach to experienced editors, promoting the feature through in-editor messages, or developing incentives for reference usage. Regardless of the chosen approach, it's essential to closely monitor the impact of Edit Check on reference usage and article quality. This data will be crucial for refining the feature and measuring its overall effectiveness.
I'd support making Visual Editor the default, as long as they also leave wikitext editing as an option (which I'm sure they will). VE is much better nowadays than when it was first released. As a WYSIWYG editor, I suspect it is much more new editor friendly. It is unarguably better at things such as automatic citation generation and table editing (adding and removing columns and rows, moving columns and rows around). And for the few things it is bad at (such as complicated template syntax), power users can just switch to wikitext editing. Any logged in user can select their default at Special:Preferences (under "Editing mode"). –Novem Linguae (talk) 10:47, 10 August 2024 (UTC)[reply]
I totally agree that VE should be the default for new users. I use VE every day, and it's just fine for most stuff, and getting better incrementally. Folks who think VE should not be the default should go to edit-a-thons and try teaching new users. 20 years ago, wiki-markup was the new hotness and was miles ahead of editing raw HTML. Today it's just a barrier to entry for potential new editors. RoySmith(talk)12:24, 10 August 2024 (UTC)[reply]
When I first edited English Wikipedia as an IP editor, I found WikiText editing very difficult to understand. I’m sure that most new IP editors face this issue. I strongly support making the Visual Editor the default. New IP editors are often unfamiliar with Wikipedia and may not know how to cite a reference using the WikiText editor. They may also not know how to switch to Visual Editing. Frankly, I still have to check the preview before publishing edits using the WikiText editor because I sometimes make mistakes. GrabUp - Talk11:08, 10 August 2024 (UTC)[reply]
Potentially minor bugbear alert: The visual editor reference creator still hasn't figured out the basic functionality of allowing for an easily accessed and obvious use of an |author= field, instead forcing all authors into |last and |first. It's not a groundbreaking issue, but it's really disappointing that it's still around after so long, especially given the many words given over the years about attracting more diverse perspectives etc. The default reference tool that we are going to create a pop up asking all new editors to use should allow for sources from authors whose names don't fit into the common European name format. It may be hidden behind an additional field button, but at least the wikitext reference creator has the option. CMD (talk) 12:10, 10 August 2024 (UTC)[reply]
My biggest bugbear is the lack of ability to set a reference name. For example in this edit I switched from visual to source editing so I could reuse citations between prose and infobox. Although admittedly this is not something a brand new editor wants to do, being able to set a name other than ":0", ":1", etc would be rather handy. Thryduulf (talk) 12:28, 10 August 2024 (UTC)[reply]
Is naming references a policy? Or is it something you consider useful? I don't edit the code. I just reuse citations when I need them, directly from the citation insertion menu. Very convinient. 37.169.50.102 (talk) 12:52, 11 August 2024 (UTC)[reply]
I mostly work in VE; I'm not personally bothered by the opaque names (i.e. ":0") that VE invents because I never see them. But many people work in wikitext, where having human-friendly names is important. So, I agree that improving support for reference naming should be a high priority. RoySmith(talk)12:57, 11 August 2024 (UTC)[reply]
I just went looking, and I don't see a Phab ticket for this. I was a bit surprised there was no ticket, but then I thought about it a bit more. It's probably hard to come up with a wiki-agnostic way to generate good citation names. You'd have to program it with something very enwiki specific to get it to read our unique citation templates then extract the author last name and year from them. User:Nardog/RefRenamer is a good workaround though. –Novem Linguae (talk) 13:14, 11 August 2024 (UTC)[reply]
I thought we were talking about auto-generating good names. Those tickets are for something else. Maybe I am misreading this subsection though. Apologies if we are not actually talking about auto-generating good reference names. –Novem Linguae (talk) 13:20, 11 August 2024 (UTC)[reply]
When copy pasting named references to another page, you get false matches that are not obvious. If automatic named references were more unique (slugified title) this false collision would happen less often. I am all for hiding/abstract workflows where needed. ~ 🦝 Shushugah (he/him • talk) 13:03, 11 August 2024 (UTC)[reply]
All programmers should read Falsehoods Programmers Believe About Names, and then re-read it every few years to refresh their memory. People who design database schemas should re-read it every time they start a new project. I agree that it's not a showstopper for our purposes, but it is a surprising lack of cultural sensitivity from an organization which is so into i18n.
For me, the biggest bugbear is that there's no good way to convert a {{cite web}} into another template without basically starting from scratch. It really should be smart enough to figure out that if {{cite web}} has a "first=" field, it can safely map that into {{cite news}}'s "first=" and so on. It won't be perfect, but it'll get you most of the way there. RoySmith(talk)12:57, 10 August 2024 (UTC)[reply]
@Chipmunkdavis @RoySmith Visual editor follows the definition of the template parameters at Template:Cite web#TemplateData (and so on for other cite templates). I think the developers would also wish that you didn't require the name to be split into two fields; it's a chore to fill it out this way. If you think this can be changed, please edit it there. Matma Rextalk13:58, 10 August 2024 (UTC)[reply]
@Matma Rex you are entirely correct that VE gets its field definitions from the templates. The first part of my comment about first_name/last_name ethnocentricity applies equally well to template writers.
But, the part about being able to convert one type of citation to another really is a VE issue. The "automatic" feature of the VE template editor is very handy, but it often can't intuit the proper type of template (that's not VE's fault) and falls back to using {{cite web}}. It would be really handy if you could say, "Please make that into {{cite news}}, and do the best job you can converting the fields". RoySmith(talk)14:38, 10 August 2024 (UTC)[reply]
|author= is already present in the existing template parameters, even if just as an alias of |last. Not presenting the alias in VE is a choice of VE, the buck should not just be passed to blindly following a particular table. CMD (talk) 14:56, 10 August 2024 (UTC)[reply]
It might be controlled by the WP:TEMPLATEDATA in something like Template:Cite/doc. I think VE reads the template data to determine the parameters it displays. If a parameter is omitted or set as hidden, perhaps it is not displayed. Not 100% sure but that is probably worth checking. –Novem Linguae (talk) 15:08, 10 August 2024 (UTC)[reply]
Assuming it is, then it would be really useful to have some statistics of how often VE (I know, I should really be saying Citoid or Zotero, or something else, but I'll just keep saying VE because that's what the end user sees) gets it wrong. I'm not entirely sure how we would define "gets it wrong", but a first pass might be "VE initially calls it {{cite web}} which is later corrected to a different {{cite xxx}} variant". Some of that might require instrumentation inside VE to detect when the user abandons a constructed citation before saving it. Some of it might require analyzing revisions to the page to see when template types are corrected after the fact. But let's assume one way or another, we could build a log of incorrect categorizations.
Then what we would do is take the full log of these reports, group them by top-level domain, and sort by frequency. If it came out that "bxtimes.com" was the most frequently domain which got mis-categorized, then it would be the highest priority for a human to go figure out how to fix and add that knowledge to the VE (Citoid? zotero?) database. After enough iterations of fixing the highest priority ones, we'd end up with a better system. If (total SWAG here) we could find the 100 top problems that accounted for 50% of the total errors, with a very small amount of human work to fix them, we could have a major win.
It sounds like a reasonable stab at the misassignment-of-citation-templates issue.
Caveat up front: I'm a developer, but I've never actually touched the internals of Citoid+Zotero, so I might be wrong about details here. That said, I believe you're right that the classification part happens entirely in Zotero, and further that if you want to teach Zotero about how to classify a new site there's some guidelines we have for that over on mediawiki.org. This coming from Zotero is also why we have vastly more classifications than we actually use on-wiki -- check out the mapping for that.
It's possible that some of the incorrect template-usage you see could be at the level of those mappings, as well -- I note that the `statute` type is just hooked up to the generic `Citation` rather than to {{Cite_act}}, for instance, though that's probably far from the most common one to need.
As for the specifics of working that list-of-sources out...
We do have some instrumentation inside VE already that could probably be looked at to work out how often someone gets all the way to the "presented with a citation-template" step and then abandons it, which would give us an okay up-front guess at the rate where something is wrong with the generated citation. Ignoring the question of other types of failure for now, the next problem is that our VE usage-instrumentation is carefully ignorant of content for privacy reasons, so it doesn't know anything about what URL was looked up when that happened. Looking for revisions which consist of just a citation template being replaced with a different citation template sounds doable, albeit slow.
I wonder if we could approach it another way. Assuming that Zotero has some internal logging of the translator it used when we make a request to it, or that it can be persuaded to tell Citoid this, we could perhaps add some logging for requests that fall back to the default-translator for unknown pages. That's not a perfect match for the misclassifications, but it's much easier to find. It does leave out cases where the translator exists but is getting it wrong, of course. DLynch (WMF) (talk) 01:46, 11 August 2024 (UTC)[reply]
it doesn't know anything about what URL was looked up when that happened does it know/track what type of template it chose? If so we can possibly work out what proportion of e.g. cite-news vs cite-web generations were abandoned? I don't think, ottomh, there would be any privacy issues with that? Thryduulf (talk) 01:53, 11 August 2024 (UTC)[reply]
Unfortunately not. All it tracks is that a citoid request happened, and then either that the "insert" button was chosen or that something was done to move away from the citoid results list. It doesn't even track what type was chosen if you go to the "manual" tab and explicitly pick one of the templates listed there.
I do agree it seems very unlikely to be a privacy issue. I mostly mentioned that was the guiding principle to explain why the case for so many questions like this turns out to be "we never needed this actually-very-innocuous content-related data before, so we weren't collecting it". DLynch (WMF) (talk) 02:09, 11 August 2024 (UTC)[reply]
Superb Owl has been maintaining a table of domain names where mw:Citoid has trouble producing a correct citation at User:Superb Owl/Community Wishlist § Automatic Citation Tool. As I understand it, Citoid's problems are partially due to how it scrapes target pages, and if domains are not putting all the information we need in <meta> tags then our only recourse is to improve Zotero translators directly.However, Citoid is understandably geared towards internationalisation and extension to all Wikimedia projects. En.wp has a considerably more complicated / sophisticated / mature citation framework than probably anywhere else. Little things like an automated citation using {{cite web}} instead of {{cite news}} or {{cite periodical}} don't bother me: User:Citation bot converts these, and the only template type it really struggles with is conversion to {{cite book}}, which has a pretty different parameter set.What does bother me about the automated citations output by the Visual Editor (apart from all the <ref name=":0">) is how often it just dumps out obviously incorrect information with no message to the user. Things like |last=B.C. |first=Sima, Qian, approximately 145 B.C.-approximately 86 (1); |last=Company |first=Rand McNally and (2); |last=Feb. 1 |first=the Office of Communications on |last2=2019 |last3=P.m |first3=3:06 (3); |last=à 00h00 |first=Par Le 2 avril 2008 (4); |first=Government of Canada National Research Council|last=Canada (5), etc, etc, etc, bonus consequence.A few days ago, I floated the idea to add a layer of error-checking into the VE citation generation interface. That's really all we need, I think. It shouldn't be the responsibility of WMF staff to ensure that every citation generated by their tools somehow makes sense for our project. But if there could just be one extra step for editors using the interface, where they could see the errors their automated citations are causing our community-maintained modules to throw, maybe they'd take the steps necessary to compare the output against the source and correct the problems before publishing.This won't fix every problem, obviously: algorithmically generated citations are only perfect when they draw on structured metadata that maps properly and completely onto our template parameters. But being able to get feedback during the edit should help editors in the VE environment clean up some of their own messes before they hit mainspace, unreviewed at the bottom of the article. Folly Mox (talk) 12:37, 11 August 2024 (UTC)[reply]
@RoySmith, @DLynch (WMF), @Folly Mox, speaking from experience from creating Zotero translators for a couple websites that I frequently use for citations, errors like this are more often than not a byproduct of missing specific Zotero translator rather than anything else. The default translator will interpret og:type = article as itemType = 'webpage', therefore citiod will use {{Cite web}}. This is unfortunate as even in the default translator's own test cases, vox.com is expected to return as 'webpage' for itemType. However, I would agree with this output, as in Open Graph Protocol, the last object type specified is 'article', and I am assuming that that's the fallback for Facebook as Facebook would use the embedded preview for articles if there's no og:type in the header (i.e. Facebook debugger on wikimedia.sg).
Therefore, what's needed to be done is to either have another translation layer on citiod to map generated citations from identified websites to use {{Cite news}} instead of {{Cite web}}, or write a specific translator for bxmedia.com, or investigate if the default translator in Zotero can be extended further so that the rework for specific websites can be minimal. – robertsky (talk) 18:16, 11 August 2024 (UTC)[reply]
Actually, passing Citoid's output directly to Citation bot before returning it to the editing interface – one specific implementation of another translation layer – sounds like a minimally effortful solution using tools already deployed and currently maintained. Citation bot doesn't fix everything (and breaks some things) but it usually does a good job in selecting which template type to apply to a citation, and in mapping data to appropriate parameters. Folly Mox (talk) 18:35, 11 August 2024 (UTC)[reply]
Yes. I have it enabled as an user script. It just won the Coolest Tool Award for improving the quality of edits. While I appreciate the work there, I also wish there is an easy way to translate the JSON files to Zotero translator format so that the work can be enjoyed by those who cannot use it out of the box on Wikipedia and everyone else who is using Zotero in general. – robertsky (talk) 08:36, 12 August 2024 (UTC)[reply]
65, I had heard of that tool, but wasn't previously aware of its functionality. It looks like a great idea, but for the fact that it is presented as an option to Citoid's output rather than a replacement of it (community generated translators for domains Citoid struggles with should – by definition – always be superior).I'm not interested in apportioning blame for Citoid's output: generalised parsing of html meta elements across the entire set of domains is a hard problem and a big task, with a lot of people involved in every step. But it remains true that for a significant portion of domains lacking structured metadata, Citoid's output ranges from suboptimal to unusable.Any additional translation layer that can be configured by the community would be superior to none, and that functionality should exist in Visual Editor so as to improve the quality of citations generated and reduce the maintenance burden shouldered by script maintainers and experienced editors on this project. Folly Mox (talk) 11:29, 13 August 2024 (UTC)[reply]
Please post corresponding Phabricator tickets for all mentioned "bugbears". 1) Having tickets for these things and 2) making noise in them is the best way to move these fixes forward. –Novem Linguae (talk) 14:31, 10 August 2024 (UTC)[reply]
Thanks all who have participated in the discussion above. I wil admit that this is my first time opening a proposal. Apologies if it is lacking in some details. While early, it seems that at this juncture, there a large support among the participants to have Edit Check deployed and/or Visual Editor be set as the default editor, keeping in mind that there are still some bugbears, or wishes to have some citations related issues resolved (honestly, I think belongs to another thread, but I appreciate the discussion nonetheless). I would like help in bringing this proposal to the next step of having it as a CENT discussion, be it by opening another thread/discussion here or elseswhere, or reformating the current one.
Impact report
In the opening, I presented a wrong statistics from the test that the product team conducted. Upon further check, I found the impact report on reference checks. Short of reproducing the whole report, these are the key numbers:
The number of constructive edits from newcomers increased from 19% to 42% (2.2 times more. As defined by newcomers with less than 100 edits and not reverted within 48 hours).
Breaking down the above number, this is consistent across all wikis with the test on. And on mobile, the increase was 4.2 times more.
Contributors that are shown Reference Check and successfully save a non-reverted edit are 16 percent more likely to return to make a non-reverted edit in their second month (31-60 days after).
10% decrease in edit completion rate for edits where Reference Check was shown
1.8% false nagative
6.6% false positive
From the report, we can see that Edit Check, in particular the Reference Check functionality, helps with improving the content contribution of newcomers and helps to improve the retention of newcomers as well. The 6.6% false postive rate may be a concern, but in my opinion, a minor one. Details from the report indicates that some of the dismissal is essentially WP:SKYISBLUE. Additionally, further finetuning of the configuration for the Reference Check may be made as well to attempt to reduce the false postive rate.
Questions asked
The following are some questions and answers summarised from above (feel free to add more):
Qn: Is Visual Editor is the default editor for newcomers on enwiki?
No. Newcomers are presented with an option to use Visual Editor upon first edit. Declining it will let editors to use source editors instead.
Qn: how does it work with edits that don't need references adding (e.g. creating redirects, adding links on disambiguation pages, fixing spellings, etc)?
The default configuration of needing 50 characters or more before the Reference Check kicks in means that most of the edits asked in the question will not have the Reference Check triggered. Further more, it is for newcomers with <100 edits, therefore it won't be presented to a majority of registered editors.
Qn: Must Visual Editor be the default editor for this to be deployed?
While the functionality is available through a JavaScript switch or through a query parameter, Edit Check is meant for newcomers. If it is not set as default editor, the effacies of Edit Check will definitely be reduced.
Having the user pick whether they want to use visual editor or wikitext editor their first time editing a page (the status quo) seems reasonable and it wouldn't hurt to leave that alone. Perhaps we should just RFC deploying edit check, and leave the visual editor issue alone? The two issues don't seem as strongly linked as I first thought. –Novem Linguae (talk) 06:16, 12 August 2024 (UTC)[reply]
If Edit Check can be deployed without changing the default or not status of VE, it would probably sail through any approval process. If it works, then later someone will be able to pull up stats saying "New editors using VE put references in 80% of their edits but those using wikitext only put them in 15%" or similar to inform that second issue. CMD (talk) 06:45, 12 August 2024 (UTC)[reply]
I should also add that the other target audience is anonymous editors. Right now the experience is as screenshot. This may be a subpar outcome for Edit Check if the primary CTA button is 'Start editing', and the anon/new editors continue to edit in source editor.
As for the statistics of how many new editors are using Visual Editor now, this is one which Foundation staff can help to answer since we do not have the access to user data. – robertsky (talk) 09:54, 12 August 2024 (UTC)[reply]
That information could be gleaned from an appropriate query, since Visual Editor tags its edits. quarry:query/84486 has the first edit for accounts registered in the first half of 2024; something similar and significantly less complicated could probably check for the "Visual Edit" tag. It would be a bit more difficult to include unregistered editors, but a basic usage ratio should be possible to estimate using public data. Folly Mox (talk) 10:32, 12 August 2024 (UTC)[reply]
@DLynch (WMF), I believe these stats are on a Superset dashboard. Can you pull them? If memory serves, there's one query for the first five edits and another for the first 100, but I don't know if one is set up for the first edit alone. WhatamIdoing (talk) 22:40, 13 August 2024 (UTC)[reply]
Edit check will work the same way for VE editors whether or not VE is default. Either way, any usage stats will be within VE users. The message given to anonymous editors who click edit, and the default or not use of VE, do not affect Edit check outside of absolute usage numbers. Generally for new features we have adopted small trials rather than immediate maximal pushses, so in that respect the current VE setup is more a benefit than an issue. CMD (talk) 11:42, 12 August 2024 (UTC)[reply]
@Chipmunkdavis, if the community thinks that an intermediate step to trial out this among the newcomers who enable Visual Editor first is required, we should explore the idea. This may simply mean that window.MWVE_FORCE_EDIT_CHECK_ENABLED=true; or the query parameter should be set in MediaWiki:Common.js (and maybe MediaWiki:Mobile.js as well), of course with account restriction criteria being set to limit the force enablement to newcomers of <100 edits.
letuserEC=mw.config.values.wgUserEditCount// wgUserEditCount: null for anon editors and non null value for registered editorsif(userEC===null||(userEC!==null&&userEC<100){window.MWVE_FORCE_EDIT_CHECK_ENABLED=true;}
I don't see how enabling edit check is an intermediate step, unless the plan is to later expand it to <500 or <1000 edits? CMD (talk) 03:42, 15 August 2024 (UTC)[reply]
It is intermediate step to see if Edit Check on enwiki does encourage an uplift in new/anon editors who are using VE adding content with references. Dependent on the result, we then can determine if it is beneficial to have VE to be the default editor with respect to Edit Check. – robertsky (talk) 05:30, 15 August 2024 (UTC)[reply]
@Robertsky: respectfully, I understand you've personally operationalized Edit Check deployment as involving making VE the default (which it may be recalled I thought was already the case), but these are two separate things. Linking them muddies the proposal and gives the impression of an agenda.I'd love for Edit Check to be enabled on this project, not necessarily for the initial check of adding a reference to a chunk of sufficiently long text (which sounds like a fuzzy test), but for all the stretch goals we could add to it for giving immediate feedback about identified categories of problem edits.Very little opposition should be expected if you disentangle all the Visual Editor stuff from this proposal, and if you wait until more kinds of checks are implemented – the kinds that save experienced editors from making the same kinds of corrections to newbie mistakes over and over – I think you'll see strong support for making Visual Editor the default when that separate question is revisited sometime down the line. Folly Mox (talk) 10:47, 16 August 2024 (UTC)[reply]
@Folly Mox you are mistaken that I am involved in the operationalizing of Edit Check with VE. I simply come across the feature and think that it is a good idea to have it enabled. Of course, there is also a strong desire to set VE as the default, but I am pragmatic. The immediate personal aim is to have Edit Check enabled and then we see if it is really beneficial for the English community. – robertsky (talk) 14:21, 16 August 2024 (UTC)[reply]
I must not know how to use the word operationalized correctly, which is actually something of a relief 🙃 I was trying to describe a comment of yours above where you explained the need for Visual Editor to be the default before the deployment of the functionality is considered complete. Anyway, glad you're embracing the stepwise pragmatism. Should be an easy pass for the simpler "enable Edit Check" proposal. Often mistaken, Folly Mox (talk) 17:58, 16 August 2024 (UTC)[reply]
The likelihood that newcomers will include a reference the next time they add new content
And while we are confident that enabling the visual editor by default for people who are new will have a net positive impact on volunteers across experience levels, the idea @RoySmith, @FollyMox, and @Whatamidoing raised about decoupling the decisions to enable the Reference Check and VE for newcomers and people who are logged out seems wise. [i][ii]
Reason being: doing so, as I think @CMDput well, seems like a relatively lightweight and low-risk way for us to work together to:
Further, as @CMD, @Thryduulf, @RoySmith, @Novem Linguae, @Shushugah, @Folly Mox have mentioned [iv][v][vi][vii][viii][ix], it sounds like there are some facets of the reference experience that would be worth us talking together in more detail about.
The Link Check evaluates all external domains people attempt to link to against the globally-defined meta:Spam_blacklist and the locally defined, en:MediaWiki:BlockedExternalDomains.json and MediaWiki:Spam-blacklist lists.
The Reference Reliability Checks evaluates the references people attempt to cite against the same local and global lists mentioned above.
Zooming out, I think you all are in the best position to decide what you think the most effective deployment sequence here is. And please know: the Editing Team is ready to support you in what you decide.
Alright, I think this is a good place for me to pause.
Please ping me as new questions about Edit Check and/or VE emerge so that I, or another member of the Editing Team, can try to help.
In the meantime, we're going to continue following this conversation and will chime in when we think there is helpful information we can offer.
iii. We'll be able to filter Special:RecentChanges for edits made with Reference Check. You can see this in action at wikis like fr.wiki, es.wiki, and ar.wiki where Edit Check is already enabled.
x. Please boldly add tickets/issues as you see fit
xi. There is an open task the Editing Team will soon address to ensure each time the Link and Reference Reliability Checks are activated, a log entry is recorded in Special:Log/spamblacklistPPelberg (WMF) (talk) 21:11, 16 August 2024 (UTC)[reply]
@Robertsky, hi – would it be accurate for me to understand you as asking the following questions?
What steps would we (volunteers) need to take to activate the Reference Check at en.wiki?
How might we (volunteers) go about configuring the Reference Check? E.g. whose edits has the potential to activate Edit Check, where references are placed (before/after periods), the sections Reference Check should ignore edits to, etc.
Assuming the above are accurate, to activate reference check at en.wiki you all would need to:
Ask us to turn it on
Adjust the configuration on-wiki to reflect your preferences (e.g. example of frwiki’s ignoreSections)
And the Editing Team would need to then deploy a configuration-change patch to enable Reference Check on en.wiki.
Call me wary for a number of reasons. First off is the false claim (also posted at the linked Mediawiki page) that Visual Editor must be the default to deploy this, or the later made implication that it makes no sense to deploy this without making VE the default. If these are coupled in this way, with the bigger change used as a prerequisite for the smaller one, then it is a hard no.
Then there is my last (in a long line) experience with a tool that had been tested or even deployed elsewhere, and worked oh so well (makes me thing of Flow, may it rest in peace). A year ago, we were asked to help with a new tool for the Android App[13]. We were told that "During initial evaluation of the model, it was preferred more than 50% of the time over human generated article descriptions. Additionally, Descartes held a 91.3% accuracy rate in testing." and that it had been succesfully been tested in 15 languages already. When we actually tested, it turned out to be very, very buggy and not usable at all. The result was that in August they posted "We’ve officially received grades for all languages and are now finalizing analysis. We will share the outcomes in next month’s update as well as our recommendations for next steps based on the experiment." and then crickets. So from an A/B tested in 15 languages, successful tool with 91.3% accuracy rate to an abandoned project after one short test by enwiki.
And then I tried to test this new tool here. I added a paragraph of text without a source, published, and got the "add reference" pop-up. Choose "yes", got presented with the automatic reference option by adding a title, typed "Lord of the Rings", no luck, so tried "manual". Click on "Book", and get "thank you for adding a citation!" even though no citation is added. Same result if I manually try to add a website or anything. Perhaps it works in real life, perhaps not, but this certainly doesn't give much confidence. Fram (talk) 13:39, 13 August 2024 (UTC)[reply]
@Fram You may see it as a false claim, but it may simply that for the end goal of Edit Check to encourage better content submissions among all anon and newly registered editors can be met by having VE be the default editor.
Your experience in testing out new tools certainly tempers one's expectations on the viability of tools on the platform. With respect to using AI to generated short description, I would also have similar reservations (my cautious approach to/use of AI is known), and still I have to say that it is an unfair comparison given that we are not expecting 91.3% of the new editors to give references. The A/B test in the impact report shows a more modest uplift of ~x2 inputs. Of course, further detailed analysis on a roll-out (in whatever form) on a trial basis can be made if we can tap on the existing tags (i.e. possible unreferenced addition to BLP) or edit filters or even sorting through the raw data.
With respect to the patchdemo wiki, maybe a more updated wiki mirrors better the current real world setup? The demo was generated back in June 2023, more than a year ago. I would have expected bugs and issues between then and now. Furthermore, it might be a patchdemo for limited use? i.e. to show partially the progress of the work? When testing directly on here in enwiki (until before publishing the edit), the reference are being added as a citation be it automatic or manual mode. – robertsky (talk) 19:05, 14 August 2024 (UTC)[reply]
If you insist that statements that VE must be made the default for this isn't a false claim, then I think we're done discussing this. And I see no reason to trust the WMF on any test results, considering that coincidentally just now they posted the results of that other software thing I mentioned above:
" By the time most of you provided feedback the experiment was already completed, and we already received support from some of your fellow experienced editors of English Wikipedia ". Yeah, right, like you posted in the "January update" which you posted in, er, August. And which is completely unverifiable, is based on a very small number of edits apparently by unknown "experienced" editors. They claim on that page that "If users that see the treatment do not select a suggestion more than 50% of the time after viewing the suggestions, we will not expand the feature". Let's see:
How often were Machine Suggestions Accepted, Modified or Rejected?
Edit type
% of Total Machine Edits
Machine suggestion accepted
23.49%
Machine suggestion modified
14.49%
Machine suggestion rejected
62.02%
So why do they plan to continue with the feature anyway? Same as always, I guess, features aren't abandonded no matter how bad, no matter which promises were made, until after (usually) enwiki or dewiki find out how bad they really are, and even then only after an unnecessary, unwanted clash with WMF has been had and mutual distrust gets cemented for another 10 years. So yes, I don't trust WMF test results, I don't trust WMF promises, I don't trust WMF false claims and those defending them, and I don't support a rollout of such features without much better, verifiable (by us) testing or with added "requirements" which aren't needed but pushed by the WMF anyway. Fram (talk) 08:41, 16 August 2024 (UTC)[reply]
I don't support a rollout of such features without much better, verifiable (by us) testing sure. let's test Edit Check out, as what I have said in my previous replies to others. – robertsky (talk) 16:43, 16 August 2024 (UTC)[reply]
Let's test it by first providing us with a correct test environment. Sending editors to a test environment which doesn't reflect the actual environment is useless. Step 1: test if it is technically working. This should happen on a testwiki, not a live wiki. This is not an unnecessary step, there have been too many rollouts of supposedly ready new software addons which turned out to be very, very buggy and were not at the beta-stage but at some pre-alpha stage. Step 2: after approval from enwiki, do a limited test on enwiki completely reviewable by editors here, not a test where we just have to believe the results in good faith, and automatically shut down the test afterwards. Step 3: after approval, do a further rollout (larger test or full rollout). For this, we are not at step 1 yet. Fram (talk) 11:13, 19 August 2024 (UTC)[reply]
It wasn't until about five minutes ago. Beta was left with an extremely-restrictive configuration since about April as a result of some validation testing our QA was doing for that configuration process. Specifically, it would only activate the edit check if your account had less than three edits made -- though you could have tested it as an anonymous user to get around that.
I just reset the config file to the defaults, so right now it'd be fair to test it there. I can also adjust any of the values if you want to see what the experience is like.
One thing that's not obvious from the config if you want to test it is that the "add a reference" check will only trigger when you add a completely-unreferenced new paragraph. DLynch (WMF) (talk) 03:51, 29 August 2024 (UTC)[reply]
Besides Beta Wikipedia, if anyone prefers an English-based example can have a look at simple.wikipedia.org. It is already deployed there and anyone can monitor the changes made when References check is shown to the user, as all edits are tagged (including rejections).
Reference check is deployed at all Wikipedias but 8. It is not deployed at these wikis because we haven't yet informed them that it is an available option. Trizek_(WMF) (talk) 15:37, 29 August 2024 (UTC)[reply]
For an example at greater scale, I believe French Wikipedia is the biggest wiki with it enabled (#3 in edits). It's a bit trickier for native English speakers to judge the quality of the edits produced there, admittedly, but looking at the revert rates should be easy enough. DLynch (WMF) (talk) 06:05, 30 August 2024 (UTC)[reply]
Thanks. So, looking at the most recent 50 edits at Simple where editcheck was activated, it was declined 39 times, 4 times it was used but the edit reverted, and among the other edits where it was supposedly used we find cases without any reference either[14] or referencing Wikipedia[15], or of course a copyright violation from a Wordpress blog[16]. That's not really an impressive result... Fram (talk) 07:10, 30 August 2024 (UTC)[reply]
And at the French Wikipedia, 34 out of 50 were rejected, some others reverted (again e.g. for using Wikipedia as a source), others supposedly used the tool but didn't add a reference anyway[17][18]. This seems close to the results at Simple, and again shows no improvement over the baseline you gave at Mediawiki[19]: "Of all the new content edits newcomers make across Wikipedias, 12% of these edits include a reference." When this tool gives the same results, but also means that many more people are now confronted with a popup they don't want, it doesn't seem like a welcome change. Fram (talk) 07:22, 30 August 2024 (UTC)[reply]
Thank you for highlighting that 12% of users add a citation spontaneously, with no prompt to add one. When Edit Check is shown, you observed at Simple Wikipedia that 39 edits over 50 are declined. It means that 11 edits lead to a citation being added. If I'm not wrong, this sample shows that 22% of users now add a citation because we provide a reminder. I think +10 qualifies as an improvement.
Using recent changes and the current flows of edits, I took a larger sample set than the 50 last edits to find the number of Edit check declined edits. I also looked at more wikis. This gives me 309 declines over 500 edits at Simple, 267/500 at French, 197/500 at Spanish, 192/500 at Portuguese, 170/500 at Chinese, 175/500 at Arabic Wikipedia. The percentage of declines decreases, leading to more citations be added, respectively 38.2% (+26.2 points compared to the number given previous paragraph), 46.6%, 60.6%, 61.6%, 66% and 65%. What would be the percentage for English Wikipedia? Let's test it for a given period of time and figure out.
Regarding reverts, let's not forget that References check is an encouragement to add citations. We assume it is for good faith users. Users who have no intention of adding one will not add one. But we now have a good number of users who now add a citation, something never considered firsthand. References check will be improved and some minor issues identified will be fixed. I'm glad that you mention a copyright violation, because the Editing team is working on this as a new check.
Please read what I wrote. "When Edit Check is shown, you observed at Simple Wikipedia that 39 edits over 50 are declined. It means that 11 edits lead to a citation being added." No, as there were cases which weren't tagged as "declined" but didn't include a reference anyway. Of the 50 edits, I think 4 were actually acceptable additions of a reference (without checking in detail). That's 8% of acceptable reference additions with this tool, while 78% of edits confronted the editors with this popup and were declined, and the other 14% were either unacceptable edits or references, or people who didn't decline the popup but didn't add a reference anyway. Please, you can't simply look at the number of declines and think that the remainder is references being added, it's easy to check some of those to see that this isn't true[20][21][22]... Fram (talk) 11:17, 30 August 2024 (UTC)[reply]
In the case of this ABC News, there are hundreds of articles with broken links, such as LGBT rights in Afghanistan.
It is even more common for it to omit a link to the "work", either displaying it in plain Wikitext or not at all. This excludes important contextual information, and goes against MOS:UL which says that proper names that are likely to be unfamiliar to readers, which would include news sources as few have global recognition, should be linked.
In the case of this ABC News, there are thousands of articles with missing links, such as Joel Reddy.
Following a discussion with Robertsky, I proposed a bot that would be able to rectify one or both of these issues, as well as add additional information to the citation template that can be determined from the URL or other content already in the template, such as the publisher or publication location.
To minimize impact on watchlists, it can be configured so that only some errors or omissions will trigger an edit, with the rest being done only if the article is already being edited.
I am raising this in the community now to determine whether the community believes that this task is worth completing.
In addition, the bot uses a configuration file that I would need the communities help to expand. Currently, it addresses issues with the following sources:
Please provide details for the other sources that you wish to see corrected by leaving a comment on the configuration talk page, or if you are sufficiently familiar with JSON to understand the configuration file by editing it directly. BilledMammal (talk) 09:02, 25 August 2024 (UTC)[reply]
Overall, I support more frequently linking publication names. For an article that doesn't use them, though, it should be kept consistent. Sdkbtalk22:41, 25 August 2024 (UTC)[reply]
I’ve already touched on this, with the above reference to WP:UL, but to address it in a little more depth in regards to consistency:
First, I don’t think we want to follow the pattern of the majority of the article, as in most cases they will be unlinked solely because RefToolbar doesn’t add links rather than because of any deliberate editor choice.
Second, a sufficiently expansive configuration file will be able to switch from unlinked majority to linked majority.
However, I would be able to alter the program to not include links under certain circumstances if that is what the community would prefer. BilledMammal (talk) 23:19, 25 August 2024 (UTC)[reply]
add additional information [...] such as the publisher or publication location. If that's done, it should be VERY selective, erring on the side of omission. Cites for The New York Times do NOT need to show that the publisher is A. G. Sulzberger or that the publication location is New York City. Et cetera. Bots should reduce work for human editors, not create work for them; we have too much of the latter already. ―Mandruss☎22:44, 25 August 2024 (UTC)[reply]
New York Times is actually a very convenient example, as it is already in the configuration file.
Not only will it not add the publisher or publisher location, it will actually remove them if it is already editing a page, in accordance with the specifications at {{cite news}}BilledMammal (talk) 23:09, 25 August 2024 (UTC)[reply]
People keep becoming confused because they think clicking "Publish" means "Move my changes to article space". But they should think that! – that IS what "Publish" must mean to any reasonable person in their situation, and there's no good reason for them to think it might have the meaning it currently does. "Publish" means to make something generally available and accessible, to put it on public display – it doesn't mean "commit changes to upstream server" (or whatever is actually happening), and it certainly can't mean that to the average person editing Wikipedia.
The only potential good reason I can see to keep it as it is would be "We deliberately keep this process confusing" – and I don't agree with that kind of policy. TooManyFingers (talk) 17:09, 27 August 2024 (UTC)[reply]
I can see your point, but as far as editing Wikipedia goes, anything you 'publish' is both available and accessible by other people. Relabelling as 'save' could likewise be easily misunderstood. AndyTheGrump (talk) 17:17, 27 August 2024 (UTC)[reply]
Wikipedia's lawyers wanted the button changed to say "publish changes" to emphasize that all edits to any type of page are public. "Save" does not do that. 331dot (talk) 17:22, 27 August 2024 (UTC)[reply]
I think this is a case of 'fixing the wrong thing'. What is wrong is Drafts. It is an incomplete feature because it's just a public page in a public thing that isn't really 'public'. It could be fixed by making these particular cases "Publish draft" or something the like however, making every single control in MediaWiki super context specific is a bit difficult (it is designed on purpose to be a generic system after all). —TheDJ (talk • contribs) 19:00, 27 August 2024 (UTC)[reply]
Someone creating a draft has to grapple with several things...
Writing some text in their draft
Saving (which is published publicly; which means both legally it can be reused/edited/scrutinized)
Even with all that, they need to transclude {{subst:submit}} which is when it is really submitted for review...and still then it's not published in sense of being visible in Mainspace (not to be confused with Wikipedia namespace)
Every control being context specific, sure. But having the text for a few select UI elements being namespace-specific (or namespace-overridable) may not be the worst idea for a future WMF developer project. ― novov(tc)12:36, 28 August 2024 (UTC)[reply]
Just a general comment: even very common words do not mean the same thing to everybody. A change you think makes things clearer may make things more confusing for someone else. It's one of the areas where we have to find a rough consensus, using language that makes general sense to most users without leading too many astray. Discussions like this are how we figure it out. Donald Albury21:03, 27 August 2024 (UTC)[reply]
We're unlikely to find a word that can't be misinterpreted. "Save" is more ambiguous than "Publish", in my opinion. Perhaps "Commit". The absence of anything else that might mean "put this in the page" might be a clue. But, ultimately, any uncertainty lasts as long as it takes to try it and see what happens. Are we getting a lot of complaints from newbies who can't figure out what to do? If not, it's the proverbial solution in search of a problem. People keep becoming confused - Show me, please. Operative phrase is "a lot". A few is not enough. ―Mandruss☎23:07, 27 August 2024 (UTC)[reply]
But what you write is public, even in draft space. That's the whole thing. The only potential good reason I can see to keep it as it is would be "We deliberately keep this process confusing" – and I don't agree with that kind of policy. Come on, that's an obvious strawman. The fact that the WMF already weighed on it, and that people gave it many thoughts before making this choice, should tell you there is probably a less dishonest reason for it. Chaotic Enby (talk · contribs) 23:09, 27 August 2024 (UTC)[reply]
We do cause confusion when we say (accurately) that every edit is 'published' but also use the verb 'publish' to refer to moving drafts to mainspace. But as others have said, the problem lies with the drafts, which is a poor choice of words to begin with (people don't usually publish 'drafts'). I've never heard or been able to come up with a better phrase, though. – Joe (talk) 08:39, 28 August 2024 (UTC)[reply]
@Joe Roe A simpler change would be to change verb for move from Draft to Article as "Promote" to indicate it's a positive thing, without touching the thorny legal/technical side of publish. It's celebratory and fits other descriptions of being declined/rejected. The namespace bit is an implementation detail. ~ 🦝 Shushugah (he/him • talk) 11:55, 28 August 2024 (UTC)[reply]
I think it important that editors understand that when they click the button, they are “publishing” whatever they have written. Where it is published does not matter. It may be published in Mainspace, in Draftspace, in Talkspace, in P&G space, etc. … but it is all a form of “publication”. Blueboar (talk) 12:16, 28 August 2024 (UTC)[reply]
Long story short, it's gonna stay "Publish" - lots and lots and lots of prior arguments about this were already made, and the WMF is going to enforce that. The OP thesis is that editors are confused when editing in draft space. We could add additional guidance to Template:Editnotices/Namespace/Draft - which appears in the edit window for all pages in the Draft namespace if there is special guidance needed. — xaosfluxTalk13:33, 28 August 2024 (UTC)[reply]
And additionally... complicated processes will always cause confusion, not matter how much text you throw at the user. The whole process only exists because we didn't want Pending Changes/Flagged revisions in main space. Flagged revisions would have probably been simpler to understand for the users, even if it would have been more annoying to us editors. Its always a balance. —TheDJ (talk • contribs) 16:03, 29 August 2024 (UTC)[reply]
The Foundation has developed a new tool at Meta:CampaignEvents which is used by other editions of Wikipedia. Anyone who organizes an Edit-a-thon knows the event management tooling is quite limited and requires lot of behind-the-scene knowledge for promotion of events.
If you believe English Wikipedia should try this feature out, please support this proposal. It does not remove any existing options or require people to use this over other forms of event management. In order to set this up, we need to establish consensus to try it out and then file a Phabricator ticket request, which I am happy to do. See the recent talk from 2024 Wikimania about it here on Youtube and notes from the same session. Here are the slides.
In the past I organized edit-a-thons using the Outreach Dashboard which helped with tracking contributions, but not collaboration between editors (see here). I am also happy for English Wikipedia to try tooling that is used by other language editions of Wikipedia and contribute insightful feedback in order to make these tools useful. ~ 🦝 Shushugah (he/him • talk) 22:24, 29 August 2024 (UTC)[reply]
Has the support team been looped in on this? There are 3 projects using so far, and it would be useful to know any outstanding issues. Also note, this requires a permission group (c.f. meta:Meta:Event_organizers) that we'd have to determine how to deal with. (some options: WP:PERM, autopromote). — xaosfluxTalk22:44, 29 August 2024 (UTC)[reply]
The description says "enhance the management and visibility/discoverability of events within Wikimedia". That certainly sounds like a good thing.
But going off on a tangent, as a checkuser, one thing I'd love to see is some way for an event coordinator to register the IP address(s) which are going to be used at the event, and having that be visible in the checkuser tool (@Dreamy Jazz). One of my suckiest CU experiences was blocking a whole pile of socks only to discover after the fact that what I really did was stomp on a perfectly legitimate "Learn to use Wikipedia" event for 13 year olds. There would be much awesomeness if a notification about that could come up in the tool. RoySmith(talk)23:06, 29 August 2024 (UTC)[reply]
Thanks for bringing this up. Regarding this tool, what are the specific implications for en.wiki? Based on Meta:CampaignEvents, it currently has two tools, Registration and Event list. I would assume we would not want Registration here, as that seems to involve the creation of a new namespace (Event:) and is a task better suited for Meta. Conversely, the Event List seems like something people may want to casually have access to, and thus locking it behind the Wikipedia:Event coordinator perm (ie. at the same level as being able to generate unlimited new accounts on a single IP) feels limiting. CMD (talk) 06:28, 30 August 2024 (UTC)[reply]
You can directly edit as a user this event: Meta:Event:Sandbox/Shushugah/Testing without any special permissions on Meta. And same would be true for English Wikipedia if approved here
We should have the Event namespace in English Wikipedia. While only users with event creator can "register" the event, any editor can still edit the content and description with project updates. To-do lists etc..
Meta:Main might be better suited for multi-wiki events it also requires advanced knowledge of Help:Interwiki syntax and is not very new user friendly. Copying and pasting a list from enwp project page to Meta wouldn’t simply work and would require juggling two different accounts. ~ 🦝 Shushugah (he/him • talk) 15:00, 30 August 2024 (UTC)[reply]
Is there an advantage to adding the new namespace on en.wiki in the days of unified accounts when new users can post on meta too? CMD (talk) 13:57, 31 August 2024 (UTC)[reply]
I mentioned a few cons, namely that wikilink templates would break, templates are not usable across different Wikis, the watchlist is separate for each. For advanced users this might be acceptable but for new users explaining difference between Meta and enWP would be a very high hurdle and counterproductive. ~ 🦝 Shushugah (he/him • talk) 14:01, 31 August 2024 (UTC)[reply]
Hello, everyone! My name is Ilana, and I’m the product manager for the Campaigns team, which developed the CampaignEvents extension. Thanks for bringing up this topic, @Shushugah, and thank you for your responses and feedback, @Xaosflux, @Pppery, @RoySmith, and @Chipmunkdavis. I’ll respond to the questions and comments so far below, and I’m happy to respond to any other questions that come up:
Event Registration was first released to Meta-Wiki in November 2022. It has been used in 600+ events with over 10k participants. The Event List was released in April 2024, and we’re now expanding it to feature WikiProjects as well (see T368115). Invitation Lists is our newest feature. It is testable on the beta cluster (see video demo), and we’re planning to release to Igbo Wikipedia & Swahili Wikipedia soon.
The extension has two sides: an organizer side and participant side. The participant side requires no special rights for access. The organizer side requires the Event organizer right for access. Wiki admins set the criteria for and manage the right. We are open to comments on how the right can be configured or expanded. We love the idea of bundling it with the Event coordinator right.
The extension comes with two new namespaces: event and event talk. You can read our rationale for why the namespaces were created. Overall, we think that there are many advantages to keeping the two namespaces, but we’re open to other ways that communities may want to define event pages. So, we are curious to hear what others think on the topic!
In the near future, we are hoping to integrate Community Configuration (T370829). This way, wiki communities can choose to turn on the extension, and they can choose which tools to turn on and how they should be configured.
I have a question for you all: How do you feel about my team inviting some organizers and/or users of the CampaignEvents extension into the conversation? Perhaps they can provide some more context. Since the extension is enabled on Meta-Wiki, we already have users from many different wiki communities.
Is there a reason the invitation list is not listed as one of the features alongside the Event Registration and the Event list on the main meta page? Anyway, if the features are separately toggleable, it sounds like enabling the overall extension is only beneficial and separate discussions can be had on the existing and upcoming features. CMD (talk) 07:50, 1 September 2024 (UTC)[reply]
Invitation list is a very fresh feature with some tickets still being worked on so that would explain why it's not mentioned yet. In any case, with Community integration coming soon, it will be easier for admins to automatically activate/de-activate features based on our wishes. I am quite curious whether embedding/transcluding the Event list in different namespaces is possible, e.g a Wikipedia Talk namespace for a WikiProject talk page. @IFried (WMF) what would be best way to test this assuming it's approved? I guess Admins/Event Coordinators would be the subset of people who could create events. Can you envision this tool being useful for backlog-drives? Is there any paper/findings about how Events have been used/evolved? ~ 🦝 Shushugah (he/him • talk) 22:57, 1 September 2024 (UTC)[reply]
Hi @Shushugah & @CMD! Great questions, which I will respond to below:
Why isn’t Invitation Lists on the CampaignEvents page? We just updated the page with information on Invitation Lists. We previously didn’t include this information, since Invitation Lists was not yet available to any live wikis. However, we just released Invitation Lists to all wikis with the extension (T373041), which means all such wikis can opt to enable it. It has also been enabled on Swahili & Igbo Wikipedia (T372582). For these reasons, the page has been updated, and we’re open to any feedback on the tool or interest from communities that would like to enable it.
Can we transclude the Event List onto a page in a different namespace?: No, there is currently no ability to do this. However, we’re interested in learning more about this request on the project talk page or in Phabricator. We’re especially interested in learning what problems would be solved by developing such a feature improvement. Thank you for bringing this up, and we look forward to learning more!
Can the tools be used for backlog drives?:
Yes, we think all three tools in the extension can be useful for backlog drives. With Event Registration, organizers can set the infrastructure in place for managing participation in the backlog drive. They can register participants, collect optional demographic information, and communicate with participants via mass email. With Invitation Lists, organizers can find people to invite who have demonstrated interest in the topics covered in the drive. With the Event List, organizers can promote the backlog drive to a wider audience. Overall, Event Registration can be used for many different types of activities, and we encourage organizers to use the tools in ways that work for them.
My colleague, @Astinson (WMF), an experienced editor on English Wikipedia, shared another use case: He signs up for backlog drives, but then sometimes he forgets to come back and work on them (like the Wikipedia:New pages patrol/Backlog drives/September 2024). He shared with me that the Event Registration tool could help organizers remind participants like him to participate in collaborative work.
Are there any papers/findings for how events have been used or evolved?:
We do not have an official paper like you mentioned. However, our work was initially inspired by the findings from the Movement Organizers study, along with other studies (see Evidence). Since the launch of our team, we have conducted regular office hours to collect feedback on our work. We have also launched surveys (for example, V0 findings). In the case of Invitation Lists, we conducted an experiment on its potential efficacy and published our findings (see April 2024 update).
Event Registration is being used for a wide range of event types, such as campaigns (example), edit-a-thons (example), training sessions (example), hackathons (example), affiliate meetings (example), office hours (example), and conferences (example).
Both Event List and Invitation Lists are quite new, but they’re focused on making events more discoverable on the wikis. We look forward to seeing what we can learn from them.
We have a survey: On the topic of continually learning, we have a survey that is going on now. We’re exploring how the toolset could be expanded for other collaboration tactics (i.e. WikiProjects, collaboration groups, tasks forces, etc). We want to see if and how the infrastructural pipeline in the extension (i.e., discovery of potential participants, registration, and communication) could be helpful to WikiProjects and other forms of collaboration on the wikis. In that case, we encourage folks to take part in our survey, and we’ll share our findings once the survey is complete: https://docs.google.com/forms/d/e/1FAIpQLScKWHPjSjSqOmca8E-eQl1HHUxYRbB4QeEV3zR2bd1_tcwuMg/viewform?usp=sf_link
I have often wished that there was a feature in the page protection options to assign a different protection to an already-protected article for a short duration, and when that different protection expires, it falls back to the original protection level. Whatever the current protection level is, it resumes when the temporary override protection level (which could even be "none") expires.
Use cases:
Content dispute between editors on a semiprotected article: I'd like to override that for a week and apply a higher protection (ECP or full as appropriate), and when it expires, the semiprotection resumes and runs it course as usual.
The current behavior is for the article to become completely unprotected at expiration.
Experimental unprotection: RFPP requests to unprotect could have the new protection level (none) override the current protection on a trial basis for a finite duration, after which the original protection resumes. This might be related to a past discussion Wikipedia:Village pump (proposals)/Archive 38#Temporary lifting long-term semi-protection of featured articles, but I would like to see just a general temporary override feature available for any article.
We currently have a pseudo-situation like this with PCP. Any protection other than "none" overrides PCP and when that protection expires, PCP goes back into effect. I am asking for temporary overrides to any protection level regardless of what it is. ~Anachronist (talk) 05:49, 31 August 2024 (UTC)[reply]
Not sure how technically feasible this is, but the first use case definitely happens all the time, and often leads to articles becoming unprotected that really ought not to be. So this is at minimum seeking to address a real problem. Sdkbtalk05:53, 31 August 2024 (UTC)[reply]
That would work too, except for the case of experimentally unprotecting, but that is low-priority compared to the first use case I described. I wasn't aware of that bot. I hope it can be approved. ~Anachronist (talk) 17:06, 31 August 2024 (UTC)[reply]
This appears to be a software feature request, mostly covered by phab:T41038. As such, it is not something that we can implement directly here on the English Wikipedia. Workarounds with a bot as described above are the most we can try in the absence of new software. You are welcome to follow, comment, or provide patches related to T41038. — xaosfluxTalk12:29, 1 September 2024 (UTC)[reply]
I don't know where to ask this, but why is it when I logged into Phabricator as my username "Anachronist" to make a comment, the username appears as "Amatulic", which was my username many years ago? ~Anachronist (talk) 16:49, 1 September 2024 (UTC)[reply]
@Anachronist, Phabricator accounts are separate from Wikimedia accounts, although the login process is now unified with Wikimedia accounts. So you likely made a Phabricator account under your old username many years ago, and attached it to your Wikimedia account, but while you updated your Wikimedia username, the Phabricator username has stayed the same. You can probably update it there too to keep it in sync. Sdkbtalk19:37, 1 September 2024 (UTC)[reply]
I don't recall ever making a Phabricator account. Did Phabricator even exist in 2006? It isn't a problem, I just thought it was strange. My VRT account doesn't do that. ~Anachronist (talk) 19:44, 1 September 2024 (UTC)[reply]
Annual readership is currently used on 53,510 talk pages. The consensus on the TfD appears to be that the template should be kept, but noincluded and made invisible, pending a solution for the Graph extension.
In the same TfD, I proposed a "Page views" link in the tools menu as an alternative of sorts. See the included screenshots. Right now, the link to the page views tool is carefully hidden in: Tools -> Page information -> scroll all the way down -> External tools -> Page view statistics. Could we perhaps make the page view link appear more prominently?
For me, the length of the Tools menu makes it harder to find specific items that I'm looking for. Thus I prefer that the page view link remain grouped under the page information menu item. isaacl (talk) 21:18, 7 September 2024 (UTC)[reply]
I think the "Print/export" section of the the tools menu could be consolidated and be put on a page called "Print/export". So that would consolidate 3 lines in the tools menu to one link. That would leave room for a page views link on the tools menu. --Timeshifter (talk) 11:04, 8 September 2024 (UTC)[reply]
I don't feel that Page views is that much more important than the other external tools linked in page information and page history. Personally, I use Revision history statistics more. Obviously adding them all would be too much clutter though, so I wouldn't propose that as an alternative. ― novov(tc)03:12, 8 September 2024 (UTC)[reply]
So you feel that "page views" is a little more important? So then it should replace something less important.
Concerning revision history, I assume you are talking about the "View history" link at the top of nearly all pages? I agree that is very important. But we are not asking for the page views link to be put at the top of pages. --Timeshifter (talk) 10:54, 8 September 2024 (UTC)[reply]
Put page views link in talk header template too
I say do both. But if not in the tools menu, let's start here in the talk header template. We could remove {{annual readership}} from all talk pages, and use this location instead. This way the number of links to page views on talk pages goes from around 53,000 to 726,000 talk pages.
Invariably the first thing I want to do after landing at the Wikipedia home page is search for the article that I want to look at. I think it would be sensible to make the search field permanently visible. There is already room there at the top of the page, and although only a click away, it seems unnecessary to have to click on the magnifier. Why not just have the field there ready to type into? Am I right in thinking that it used to be that way? I wonder why it was changed. 2A00:23C8:7B0C:9A01:8A7:5D88:5F57:107E (talk) 19:53, 8 September 2024 (UTC)[reply]
I think the magnifying glass only appears when the window is narrower than some threshold (looks like about 1100 px). I'm not sure why they do that; there's plenty of space left at all but the most extremely narrow widths to allow for a full search box. But in any case, this is really a Vector 2022 skin issue, not something enwiki has any direct control over. Perhaps ask on meta:Talk:Reading/Web/Desktop Improvements? RoySmith(talk)20:04, 8 September 2024 (UTC)[reply]
You're right, it's dynamically controlled. I didn't realise that. When I lower the browser zoom level the search field becomes visible. It seems to me that all that needs to be done is adjust the "trigger" level at which it is displayed, so it is only suppressed when there is "obviously" not enough room to type a search query. 2A00:23C8:7B0C:9A01:8A7:5D88:5F57:107E (talk) 20:32, 8 September 2024 (UTC)[reply]
Merging mass-created village stubs into district articles
Initial ideas, village stubs
There are a lot of mostly formulaic (though that's not necessarily bad) stubs of villages with 60-100 people that will probably never be significantly expanded, at least beyond one or two events happening there. I know that under the the guideline on geographical features all inhabited places are considered to be notable, but what if very small villages were by default merged into district articles? I'm thinking of a section "Villages" or something similar with a subheading for each village and a few sentences with the population/location (what's already in the leads). Villages that had enough coverage to need their own article would be split; it could be done based on the categories "Rural localities in X district" that already exist.
For example, Basovo and Timonovo in Valuysky District, Russia. The second has 1 event happening there, and the 1st none listed; both are very small towns with a couple hundred people. It's possible Timonovo could be expanded with a description of the event, but that would be rather WP:1E-style and deserve its own article.
I'm posting this here because I don't know the history & policy details sufficiently to put it into proposals (or the 300-vote discussions), but I wanted to see what people thought and if this had been proposed before. Mrfoogles (talk) 04:00, 15 August 2024 (UTC)[reply]
It depends on what the guidelines are agreed to. I'd say if a location only cites census tables and maps (gonna use Hashemabad, Kerman as an example), they should be merged with the above-class subdivision. All these location articles only have maps and census tables, could possibly violate geographic feature Notability. Roasted (talk) 04:22, 15 August 2024 (UTC)[reply]
I would cautiously support this as long as it was done carefully so no information was lost, was explicitly without prejudice to later expansion and excluded places with significantly more extensive articles on another language wiki. Of the three places here, only Timonovo has more information elsewhere (ru:Тимоново (Белгородская область)) but that is borderline. My ballpark suggestion would be that any article with circa two paragraphs of prose of non-census information excluding a description of it's geographical location on any language edition of Wikipedia should not be merged in without an individual discussion. I'd also say that before any merge takes place there needs to be a list of all the merges proposed laid out in a fashion easy for humans to check (separate lists or separate sections for each destination article would probably work well). Thryduulf (talk) 10:25, 15 August 2024 (UTC)[reply]
Section break 1, village stubs
I support the concept… Wikipedia should continue to cover all noteworthy geo locations, but we can be more flexible in how we cover them. Not all locations require a stand alone article to be included. Blueboar (talk) 11:49, 15 August 2024 (UTC)[reply]
The ru.wiki versions of the villages are not much longer unfortunately, and the length of the longer one comes from quite generic information that would likely apply to the district. Your method of merging to the district article sounds like one in which no information would be lost, although I would leave room for a bit more than what is currently in the leads. CMD (talk) 12:00, 15 August 2024 (UTC)[reply]
I doubt anyone will stop you but I think it's a waste of time. For some reason some editors have strong feelings about the existence of stubs vs. redirects to entries in lists but, from the reader's perspective, they're pretty much the same. I can't tell anyone how to use their time but if all the collective hours we've wasted on merging or talking about merging stubs were instead put into expanding them, the encyclopaedia would certainly be better off. – Joe (talk) 07:13, 16 August 2024 (UTC)[reply]
There's the rest of what I wrote, and if your counter-proposal is to treat the nav boxes as great article content then I don't think that's very helpful to the reader either. CMD (talk) 12:31, 17 August 2024 (UTC)[reply]
I might come to the same conclusion ("As a reader, they are not the same") but in the opposite direction: Hunting through a merged-up page to try to glean which info is relevant and which is about other villages takes up time. With a stub like Timonovo (five sentences, 75 words, five sources, plus the infobox), you know that all the information is what you're looking for, and you know that's all there is. WhatamIdoing (talk) 22:19, 18 August 2024 (UTC)[reply]
List articles don't have to be tabular data with no prose, nor do they have to be internally consistent as to whether or not the list items they contain are bluelinks or not. The GA Infrastructure of the Brill Tramway is basically a list article that contextualises borderline notable information beautifully.I should disclose that I'm strongly in favour of contextualising stubs into their container topics wherever possible. Folly Mox (talk) 16:18, 16 August 2024 (UTC)[reply]
Somehow I doubt the result it this will be a load of GA-level lists. It'll be the existing stubs, pasted in one after the other. – Joe (talk) 05:49, 17 August 2024 (UTC)[reply]
I agree that the implementation of contextualisation is likely to resemble pure concatenation, and would prefer that outcome to the status quo. JMO. Folly Mox (talk) 15:59, 17 August 2024 (UTC)[reply]
I was more thinking of a policy allowing people to merge such things if they felt like it: because there are so many village articles it's never worth it for any one person to start a discussion about merging the villages of one district, because who cares about this one random district in particular. And no one has the hours and hours you refer to to just go do it for all of them. With a pre-consensus it could ideally happen piece by piece? If there was a policy on this I might merge the villages of that district just because I ran across them, but I wasn't planning to spend 900 hrs on trying to do all of them.
As for expanding them: 60 people live in most of these village, and it's unlikely someone's written a book about most of them. Not going to say it's not a little bit of a waste of time, but having a list of villages in a district in its article seems useful: it was helpful to me finding some village list in district articles on the German Wikipedia I think when I was trying to figure something out. I think name+whatever small details exist could be somewhat helpful, if not the most important task. Mrfoogles (talk) 18:54, 16 August 2024 (UTC)[reply]
@BilledMammal put together a sample of 10,000 articles so we could try to find out some basic information about what the community's actual practices are – the revealed preference, if you would like to use that language, rather than the aspirational goals. So far, we're finding facts like these:
90% of articles have between 2 and 95 sentences, heavily skewed towards shorter articles. The most common number of sentences in an article is two. Half of articles have 13 or fewer sentences. A quarter of them have 5 or fewer.
If you define a stub as having ≤10 sentences, then 43% of Wikipedia's articles are stubs. If you define is as ≤250 words, then 41% of articles are stubs.
Half of all articles have 4 or fewer (detectable) inline citations. A quarter have 2 or fewer. Only 21% have more than 10. Having more than 20 (about 10% of them) is a statistical outlier.
Compared to longer articles, stubs tend to have about twice as many citations per sentence.
The reason I bring this up is because when we compare articles against our ideals, it's very easy to think "What garbage. It 'only' has five sentences. It 'only' has five sources. It 'only' has 75 words." We ought to be thinking "Huh, that has more sentences than 25% of our articles. It has more refs than 60% of our articles. It has more words than 16% of our articles. Maybe it's not too different from normal, actually." WhatamIdoing (talk) 22:40, 18 August 2024 (UTC)[reply]
I recently ran a new scan, of 100,000 pages, where the talk page categories are also provided. I’m not sure how to upload it yet - it’s a far larger dataset than all the others I’ve uploaded put together - but it should be helpful as it will allow us to determine which topic areas have abnormal articles.
I suspect that the size of places will vary by location. Most US census places have longer than median articles (e.g., Mulberry, Kansas has 25 refs and almost 1,000 words) but were largely written by bot/script.
I totally support the idea to reduce village stubs. here is one possible way to do so; make articles consistently named "villages in ___ County", or "Villages in ___ Oblast," or "Villages in ____ Arrodinsement," and so on, and make these into list articles.
I think that the fact that these articles are close to the status quo doesn't necessarily mean they wouldn't be improved by merging them, though. The point is that they have very low potential (only have 50-200 people or so), which is not true of all stubs. Mrfoogles (talk) 17:20, 20 August 2024 (UTC)[reply]
Some time back (we're talking at least 15 years), I wanted to have an article on every inhabited place in Ethiopia. This aspiration was foiled by the fact that information on even sizable towns in that country can be hard to get ahold of -- at least at that time. In many cases all the information I had about the village was the population statistics. Moreover, at the time I was not interested in adding to the large number of stubs on Wikipedia; this is why you'll find a lot of red links in those articles.I considered addressing this problem exactly as proposed above: create a section in the article that provided the stats on those towns/villages. However by that point I was tired of working on Ethiopian topics & decided to move on. -- llywrch (talk) 18:18, 27 August 2024 (UTC)[reply]
Rename and/or Combine Content Assessment classes
Currently Content Assessment is named arbitrarily at Featured, A, Good, B, C, Start, Stub. Looking for ideas as to what A, B, and C classes should be renamed? And if B and C classes were combined into one, what would that be named?
I would merge B, C and Start together and call them all "start". Anything checking criteria of article like DYK would not solely rely on WikiProject content assessment anyways. ~ 🦝 Shushugah (he/him • talk) 21:51, 18 August 2024 (UTC)[reply]
I’d definitely be opposed to lumping B and Start into the same bucket, the resulting rating would cover a really wide range in quality. There is a difference between “often not used and superfluous in many cases” and “totally unnecessary”. ― novov(tc)01:57, 19 August 2024 (UTC)[reply]
The names aren't really arbitrary. They're basically American letter grades, plus two existing review processes (FA and GA), the separate {{stub}} system, and a squeamishness about rating anything with a "bad grade". C is a relatively recent innovation; back in the day, it was realistically Stub–Start–B, and anything else required extra effort. In 2008, editors basically decided to divide the Start class into two groups (C and Start).
As a first approximation, we started with:
Stub: Less than ~10 sentences.
Start: More than 10 sentences but not yet B-class.
B class: Meets all six specified criteria.
and we decided to have:
Stub: Less than ~10 sentences.
Start: More than 10 sentences but still kind of short and not B-class.
I would consider using something other than the A-B-C convention. I noticed that an inordinate number of editors were adding A class to India articles. Apparently people think it's like self-grading a homework assignment. I think A-class should either become a universal process like GAR or FAR, or go away entirely. That I know about, only WP:MILHIST, WP:USROADS and WP:HIGHWAYS have a process to review A-class articles. WP:WikiProject Biography and Wikiproject Cyclones had a process, but the latter turned out articles that in no way represented the best of Wikipedia. Schierbecker (talk) 02:40, 19 August 2024 (UTC)[reply]
Yeah I agree. Given how few WikiProjects actually have a process for reviewing A-Class articles and how difficult it would be to create them given how many of them are small and/or semi-inactive. Standardising it to a universal process or eliminating it would probably be better. Although there is always the idea that "it's there if people need it" DimensionalFusion(talk)09:04, 19 August 2024 (UTC)[reply]
What's A class? Why does it even exist? I always thought there's B class, better than that is Good Article, and the very best is Featured Article. A class seems to have no good place in this scheme of things. Gawaon (talk) 11:23, 19 August 2024 (UTC)[reply]
A class exists because there is a broad gap between GA (B class with a review by a single editor - a low grade) and FA (A class with a comprehensive review by at least three editors - a high grade). B class is the minimum acceptable standard, which is why it would be destructive to merge with lower classes. Starts and stubs are unacceptable quality. FA is not generally available. Our very best is A class (comprehensive review by at least three editors from the project). Hawkeye7(discuss)11:16, 21 August 2024 (UTC)[reply]
A class (comprehensive review by at least three editors from the project) isn't necessarily correct. The majority of WikiProjects don't have any specific assessment criteria for A-Class articles, and WP:Content assessment just lists some generic criteria. In contrast, GA gives much more solid criteria.
It may be because GA is a site-wide standard but A-Class criteria is handled by WikiProjects, though this is a bit confusing given the majority of articles have multiple WikiProjects. Am I missing something here? DimensionalFusion(talk)21:49, 22 August 2024 (UTC)[reply]
The majority of WikiProjects don't use A-class at all, so of course they haven't wasted their time setting up a process and criteria for using it. WhatamIdoing (talk) 04:19, 23 August 2024 (UTC)[reply]
Under the rubric suggested by Wikipedia:Content assessment/A-Class criteria, A-class reviews closed as successful by WikiProjects without a formal A-class review system should be supported by two uninvolved editors, with no significant opposes. The number of articles that were made A class using the informal process is basically zero. For a while WP:Cyclones was promoting subpar articles based on discussions held on IRC, but they were the rare exception. Schierbecker (talk) 21:38, 26 August 2024 (UTC)[reply]
Because as someone not involved with MILHIST, I am not familiar with A-review. I cannot name a single other WikiProject off top of my head that does A-reviews though they exist. On other hand, most editors understand what GA standard is, which isn't custom to any Wiki projects. If there was a proposal to introduce A-class as a universal standard, I would reconsider my position, but as it stands, it adds more confusion than anything else to rest of the project. This is why project banner shell has been simplified to rate class of an article on behalf of all WikiProjects. ~ 🦝 Shushugah (he/him • talk) 14:42, 31 August 2024 (UTC)[reply]
The problem here is that making A-Class a universal review like FA or GA is that GA already has a big backlog, but as A-Class is above GA it would make reviews take longer due to the higher quality requirements. Potentially leading to an even longer backlog.
@DimensionalFusion, do you mean why do WikiProjects generally prefer FA and GA? It's because they don't want to bother with A-class. Think about it: Either you can do a whole bunch of extra optional work for very little value, or you can just... not. WhatamIdoing (talk) 01:36, 1 September 2024 (UTC)[reply]
There definitely isn't a pressing problem here, but I do agree that we're being overly precise with content assessments, both in terms of the capacity of WikiProjects to review and re-review them (way, way down from 2008) and what they're actually used for (does the difference between C and start and B actually change anything, anywhere?) That the current situation works okay shouldn't stop us trying to refine it.
I like the simplicity of Stub > Start > GA > FA. A stub is a potential article, that might still end up being merged or redirected. GA and FA are well-defined standards with dedicated review processes. The GA criteria in particular are way lower than most people think: we could aim for most articles being GAs one day, and a lot of things that are being rated B or A are already there. I don't see the point in differentiating the mass in the middle---articles that have established themselves but that nobody has really whipped into shape---perhaps just call them something like "satisfactory" or "average" instead of "start" (which implies some deficiency). – Joe (talk) 07:29, 21 August 2024 (UTC)[reply]
I see a big difference between articles like for example Mode conversion (start) and Atom (B). Start class articles are short articles that probably cover the basics but there is a lot more they could say and improvements to writing style, referencing, etc are almost certainly possible. B class articles are (mostly) comprehensive and generally well written but haven't been through any formal processes. Whether there is a need to differentiate B and C is the only question in my mind, but retaining the distinction between them and start is useful.
When looking for examples though I did find MXenes which is tagged as start class but is clearly higher quality than that, especially if someone who understands the subject expands the lead. Thryduulf (talk) 10:28, 21 August 2024 (UTC)[reply]
There is absolutely a difference between Start articles and B-rated articles in the abstract, but the goal remains the same with either article; keep improving them. And at the same time, there are a ton of improperly classified articles, because editors are either too stringent or self conscious and either way, the energy should be focused on improving them. Heck, editors are reluctant to downgrade a B article to a Start article and prefer to fix issues (which is probably the right spirit), but makes the ratings exaggerated in their helpfulness across our 6 million articles here. ~ 🦝 Shushugah (he/him • talk) 00:36, 23 August 2024 (UTC)[reply]
The goal remains the same but the implied method is different. A Start article implies great adding work is needed, a B-class article implies curating and refinement is needed. This difference is why you don't really go from a B to a Start, as it's rare that much content leaves articles. CMD (talk) 04:19, 23 August 2024 (UTC)[reply]
> does the difference between C and start and B actually change anything, anywhere?
Is there a better way of assessing an editor's experience? This is something one might (should?) do before interacting with another editor. (And also something to apply to oneself, now and again.) At present we have (1) edit counts and (2) number of articles created (3) date of first edit (have I missed one?). It seems hard to get an opinion on how much of an editor's work is in writing new encyclopaedia content of articles – which is the job we are here to do (yes, just like, e.g., a car manufacturer being all about building cars, we do need a lot of support functions to achieve that job).
The problem with edit counts is that this includes:
lots of short edits because the editor does not prepare a considered piece, check it with a preview, and then add it.
interminable discussions/arguments on talk pages.
a focus on page curation (example:[23]) or other "maintenance" activity.
The problem with number of articles created is that an editor may be working in an area where most subjects have an article on them already. Some of these may need improvement (sometimes radical improvement), updating or simply expanding from a stub. So this measure favours those who edit in rapidly changing subjects where new topics arise frequently.
Date of first edit has some use, but there are still editors who started years ago who seem to be unaware of some of the basics, and quite new editors who seem to have got a real good grip of how everything works and produce quality article content.
In searching for a useful set of measures, I suggest something that looks at activity in main namespace (i.e. encyclopaedia content). This could be, as a single group of information:
the total number of characters added
the number of edits
the number of edits grouped in size bands
I feel this would give a more useful view of an editor's activity. What is important is that this should be easily visible to anyone (without needing knowledge of some little used method of getting this data).
My first thought is to back up a step and ask why you think we need a measure of editor "experience" in the first place? Anomie⚔11:19, 27 August 2024 (UTC)[reply]
Agree with Anomie, especially since "experience" doesn't really translate linearly, someone could be very experienced at writing content but not familiar with "backend" or administrative tasks. Or someone could be very good at writing templates and maintaining code. Or doing mostly WikiGnoming. Etc. Yes, one could say that only the first one is "pure" editing, but this doesn't mean they're inherently the only one doing valuable work, or that they should be higher in some kind of hierarchy of experience. Chaotic Enby (talk · contribs) 11:43, 27 August 2024 (UTC)[reply]
In addition to the points made by Anomie and Chaotic Enby (with which I agree), your proposed metrics are not reliable indicators of anything relevant: a highly skilled copyeditor will have fewer character additions to their name than someone who writes long, terrible prose. Which of these two edits of mine is the greater addition of encyclopaedic content +220,030 bytes or +759 bytes? Is making the same improvement in one edit better or worse than making it in twoedits? My recent gnoming contributions have ranged in size from -167 bytes to +220,030 bytes, almost entirely overlapping with my non-gnoming edits (other than deprodding and BLARing). The number of edits in each band tell you nothing about the sort of editor I am. Thryduulf (talk) 12:04, 27 August 2024 (UTC)[reply]
I thought the brief analogy (above) with a car factory was clear – sticking with that analogy, yes the main task may be building cars, but you still need accountants, cleaners, a marketing department, etc., etc. So I am well aware that Wikipedia would not function without lots of tasks other than "pure" editing. What I find a problem is that in the example I gave above, [24] the edit count (as the only readily available metric) does not make clear that the editor has done very little writing of encyclopaedia content, yet they are welcoming new editors, have offered themselves (on 11 July) for multiple feedback services and are active on approval of draft articles. There is very little editing of actual article content and even less of finding some sourced material and adding it to an article. So from this I conclude that the measure of edit count is misleading and that the editor in question does not really have the experience to be judging other editors' efforts. Hence the need for more better quality information. With that information available to all, it might make an editor ask themselves "am I the right person for this job?", so providing a self-policing element. ThoughtIdRetiredTIR12:42, 27 August 2024 (UTC)[reply]
On Wikipedia:Page Curation, we find Page Curation is a suite of tools developed between March and September 2012 by the Wikimedia Foundation, and greatly improved in 2018 in collaboration with the Wikipedia community, to help experienced editors review new pages on the English Wikipedia.[bold added] The thoughts here are all about determining what is an "experienced editor" – hopefully with that largely being self-policing if the right info is available. ThoughtIdRetiredTIR12:48, 27 August 2024 (UTC)[reply]
What is it about extensive writing of article content that makes someone uniquely qualified to welcome other editors, offer feedback on articles or determine the quality of a draft? In the passage you quote, "experienced" means "is familiar with Wikipedia's policies, guidelines and norms", someone who spends most of their time on Wikipedia reading a broad range of existing articles and discussions is very likely going to have a much better grasp of what page curation entails than someone who has spent twice that amount of time adding sourced content to a narrow topic area. Two people who spend the same amount of time making the same number, size and type of edits to the same type of articles can be very differently suited to page curation - for example if editor A's edits are almost all accepted as good by others while editor B's are reverted and/or require extensive fixing by others. Editor B is arguably more experienced because they will likely have been directed to read more policies and guidelines and had more talk page interaction regarding their editing than editor A (whose talk page may consist only of a welcome message). There is no simple metric that can capture this. Thryduulf (talk) 13:03, 27 August 2024 (UTC)[reply]
Large numbers of edits that welcome new users make a correspondingly large increase in the edit count of a user. These are not edits that increase an editor's knowledge of Wikipedia. This is something that devalues edit count as a useful measure of experience. ThoughtIdRetiredTIR16:25, 27 August 2024 (UTC)[reply]
Respectfully, I don't think we need more metrics and ratings and hierarchies of editors. I'll also note that the Wikipedia:New page reviewer user right (which gives access to the Page Curation tools) is only granted by administrators, most often at first for a short trial, so there is already every opportunity to check if the user has the experience needed.One does not simply walk in and start patrolling new pages. (Although NPP always needs more people!) Chaotic Enby (talk · contribs) 14:27, 27 August 2024 (UTC)[reply]
I think it’s helpful to know whether someone is a [[WP:Young editor]] when giving them feedback on potentially problematic edits. But when people are able to communicate adequately, none of the metrics about previous edit count, areas of expertise concern me. I can be convinced that having certain about edit count, user permissions can be helpful when looking at someone’s diff and to ascertain what kind of question to ask someone; but again with emphasis on being kind and effective communicators. In the past, I’ve been chided as a “new editor” when I had 500 edits by someone who was abusing their seniority status. Needless to say, they were also blocked frequently for problematic behaviours. ~ 🦝 Shushugah (he/him • talk) 14:46, 27 August 2024 (UTC)[reply]
From my experience (and I am talking about positive experiences) the most helpful of editors are those who have added a lot of encyclopaedia content. I attribute that to their understanding of some of the problems in sourcing and explaining an article, and also in how to interact with some of the more difficult people in this community. I suspect that many editors, whether they know it or not, have learnt most of their knowledge on Wikipedia from other editors with a substantial track record behind them. What worries me in this case is: who will a new editor go to for assistance/guidance? If they go to someone who was their new page reviewer, but that person does not have any depth of experience, that new editor is being short changed. In the example given, the editor in question apparently does not read the articles too closely – I have no idea what they are doing, but tagging a short article that says when some died (20 years ago, at a good age) with a BLP warning suggests a superficial approach, as does immediately sticking an orphan tag on everything that comes out of draft, which will obviously be the case on making that transition. To answer I don't think we need more metrics and ratings and hierarchies of editors: I think I am trying to make a closely related point, that the metrics we do have can mislead. Perhaps we just need a warning that the existing measures can mislead. ThoughtIdRetiredTIR16:14, 27 August 2024 (UTC)[reply]
On June 4, 2024, I moved the article Angela (enslaved woman) to Angela (slave), for homogenization. It was reverted by @CaroleHenson on July 3, in which they cite Slavery#Terminology. I attempted to reach them 6 days ago (as of August 30), but they are currently inactive.
The terminology section itself describes the naming as "dispute". I thought the (slave) disambiguator would be a better choice due to WP:NOTCENSORED, similarly to changing "passed away" to "died".
Also, I suggest reading WP:OTHERSTUFFEXISTS before writing your explanation for the requested move process. You will want to write something that doesn't sound like "It's more important for this article to match the others than to avoid language that I've been told is potentially offensive".
Wikipedia should generally avoid needlessly offending people. We want people who read that article to be thinking about the historical subject. We don't want them thinking about whether Wikipedia uses outdated or offensive language. WhatamIdoing (talk) 22:52, 30 August 2024 (UTC)[reply]
There was a recent discussion that, while not formally closed, basically came to the conclusion that both "slave" and "enslaved person" are acceptable ("slave" is not "outdated language") but that one might be preferable to the other depending on the specific context. In such situations it is almost always a bad idea to change from one to the other without consensus. Thryduulf (talk) 23:03, 30 August 2024 (UTC)[reply]
I don't think that (non-RFC) discussion needs a formal closing statement. We probably need to have multiple conversations like that, until more editors become familiar with the subject matter. A formal summary tends to discourage future discussions.
In particular, "both are acceptable" summaries tend to get misused this way: "The rules say that both are acceptable, so my preference is acceptable, and so the rules say we have to do it my way (and never, ever your way)".
As linguistic practices in scholarly and other high-quality sources have just started changing enough for editors to be noticing this, this is probably an area where we need people to keep their brains turned on instead of just trying to find a simplistic rule. I think the best approach will be more obvious in, say, five years. For now, we just need to avoid carving a rule in stone. WhatamIdoing (talk) 01:44, 1 September 2024 (UTC)[reply]
The policy requires Neutrality in article titles, so if editors decide that they have to match, they might need to make them match on the one that won't create an opportunity for complaints about offensiveness.
NB that I'm not saying anyone should be offended; I'm just saying that we already do get complaints about "slave" being offensive, so we can reasonably predict that we will get complaints about offensiveness if we choose the (slave) convention. Similarly, we currently don't get complaints about "enslaved person" being offensive, so I think we can reasonable predict that we won't get complaints about offensiveness if we choose the (enslaved person) convention. WhatamIdoing (talk) 01:50, 1 September 2024 (UTC)[reply]
But I do find substituting "enslaved person" for "slave" grating. Now, I was trained as a linguist and fully understand that a spoken language is a living thing and constantly evolving, but I am also an old fogey and have grown weary of euphemism churning. I have lived through several cases of a term being recognized as offensive, so we switched to some euphemism, which in a few years become offensive to some, so we switched again. In truth, we are just avoiding how the term is used offensively, and replacing one term with another that will also come to be used offensively. That said, I do not choose this as the "great wrong" to right. I will speak up, though, against the trend I've recently seen of changing "plantation" to "forced-labor cotton farm" and similar monstrosities. Saying that slaves were just "forced laborers" is hiding or dimishing the horrors of chattel slavery. Donald Albury17:05, 1 September 2024 (UTC)[reply]
These aren't exactly euphemisms, but I wonder sometimes whether the idea is to grab attention, in the way that an annoying advertisement for used cars is grating but effective at communicating the basic content. WhatamIdoing (talk) 19:47, 1 September 2024 (UTC)[reply]
Proposed temporary solution to the "remember me" function bug
Here is the thread on the bug -> Wikipedia:Village pump (technical)#"Remember me" not working as intended for me
Basically, "remember me" would forget about you sometimes, for whatever reason.
Now, I have no idea how wikipedia works under the hood, so this idea may be absurd or even stupid. I would like to suggest that a check is done every time an IP edits wikipedia to see if it is associated with an account, and a banner be displayed if the check returns a positive result, promoting to user to log back in before publishing their edit. —Mint Keyphase (Did I mess up?What have I done?) 02:57, 31 August 2024 (UTC)[reply]
A warning is displayed every time you edit with IP address about editing under an IP address. I would say that's already a warning enough if one has been editing while logging in. – robertsky (talk) 01:55, 1 September 2024 (UTC)[reply]
@Mint Keyphase, Wikipedia runs MediaWiki software under the hood, and if you are interested in that, please go to mw:How to contribute on our sister site (same username/password; it'll usually log you in automagically).
Robertsky is correct that we already post a warning for every IP. It's in a yellow box at the top of the page and says:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to a username, among other benefits.
Additionally, there are privacy problems around doing things with detecting logged-out editors. Here be dragons, or at least lawyers. This might be solvable, but it's not likely to be quick.
The practical problem is bigger. Imagine what would happen if we did this, and you were using a shared internet connection, e.g., at school. Everyone in the school building would get 'warned' because one person logged out. This is probably not solvable. WhatamIdoing (talk) 01:59, 1 September 2024 (UTC)[reply]
To stub an article
Should we put stub templates on articles that will never be able to be expanded to a start-class?
For example, John Settle (footballer) will very very very very very likely never be expanded to the 1500 character threshhold. It's stub category (Category:English football defender, 1890s birth stubs), could be used by editors to find short articles to be made longer, but is crowded by articles that are extremely unlikely to have more information to be added.
What would you call such articles? In any case, how can you tell that an article has no hope of being expanded beyond a stub? At least some editors feel that stub articles that have no hope of being expanded don't belong in Wikipedia as stand-alone articles, and any useful information in them should be merged into a higher level article. So, search for reliable sources on the topic; if you cannot find anything useful, explore merging the article into a more inclusive article, convert it to a redirect, or take it to AfD. Donald Albury13:30, 3 September 2024 (UTC)[reply]
A basic question, what OP asks, is what to do about historical biographies? For the example footballer above, I suppose you could make articles for each team he played in for each few seasons that include biographies of all footballers, but then you'd be duplicating all those biographies for the multitude of teams they play in. The alternative is a "list of 1890s footballers" type article, which in addition to being an arbitrary categorization, does not solve the GNG justification for the article, and is a list article, which I would argue is more difficult to maintain and generally of worse quality than a stub (especially when entries do not have main articles). SamuelRiv (talk) 14:46, 3 September 2024 (UTC)[reply]
Sports biographies have been a particular problem on Wikipedia where editors mass create them in the hundreds or thousands despite being asked to stop. It got to the point that a discussion in 2022 determined that sports biographies without significant coverage should be deleted. Feel free to WP:PROD or WP:AFD any sports biography like this that you see where it doesn't have any significant coverage in its listed sources. Thebiguglyalien (talk) 16:34, 8 September 2024 (UTC)[reply]
break up paragraphs
This is a practice request rather than a feature request.
When looking at diffs, it's a pain to scroll through a paragraph taller than my screen to find the one changed word (or comma), not to mention the similarly long paragraphs shown before and after it for context.
I would urge editors to insert single line breaks – which are invisible on the page – between sentences, especially after complex refs. Or at least not to go out of your way to remove such breaks! —Tamfang (talk) 19:10, 3 September 2024 (UTC)[reply]
It's fine to put linebreaks inside templates, such as the citation template. If one is really concerned about losing something in the underlying html, then one can enclose a linebreak within an html comment <!-- -->. These may or may not help with alleviating the diff display.
The html for a single line break in plain wikitext appears as a newline character within a <p> element, which is not rendered by default, but may be picked up accidentally by a bot (not sure for example if AWB's regexp tools default to stop at newlines, or else match "^" to newlines, but imo regexp is inherently a trial-and-error tool, and people who have been using it on WP for a while will have tested their code on newlines already).
As for whether it impacts something more important like commercial accessibility tools (like screen readers), I don't know. But OP's issue is an important accessibility issue as well, since as most of the emerging and young world is operating exclusively on mobile devices, we want to address their UX concerns. (I enjoyed the essay Wikipedia:Editing on mobile devices.) SamuelRiv (talk) 18:41, 6 September 2024 (UTC)[reply]
Length and complexity
I noticed the recent expansion of Mekosuchinae that evolved from this to its current form. Articles can sometimes become so large and complex, they exceed the average audience's time and interest. This is not to say the current article should be trimmed or split, it presumably does a good job. But it's very long and specialist. For example one sentence has:
"A later study focused on mekosuchines in general; examining material assigned to Kambara, Baru, the "Floraville Taxon" and what might have either been a juvenile Baru or Mekosuchus; suggests that the group as a whole had collumnar humeri than modern crocodylids with an elliptical rather than rounded crosssection."
One option is to feed it to ChapGPT and ask for a summary in the style of a museum brochure ie. for a "general audience", which is what I thought Wikipedia is supposed to be anyway. There is Simple Wikipedia, but that seems different. Anyway, there does seem to be a need for articles on complex topics that are geared to a casual general audience, that are approachable, readable, interesting without sacrificing accuracy. -- GreenC18:05, 6 September 2024 (UTC)[reply]
Nobody is expected to read a Wikipedia article, or any encyclopedia article, in its entirety from front to back. It's a reference book. (Wikipedia is many more things than that, but the encyclopedic style, the piecemeal improvements, the both narrow and wide audience scope, and the nature of citations, suggest you treat it more as that.) SamuelRiv (talk) 18:15, 6 September 2024 (UTC)[reply]
I am an occasional user of SWViewer, a vandalism patrolling tool that is (in my understanding) partly maintained by the Wikimedia Foundation. I generall like its interface and design, and I have found it to be a useful tool.
I do have one item that I would like to discuss though: I think it would be wise to add a checkbox for whether or not to mark an edit as minor. Currently, the interface allows users to tick a box for "Use undo" when rolling back an edit with a summary. This is good, but it only allows users to revert edits in a way that is marked as minor. I understand that certain wikis, such as the English Wikipedia, have a very narrow understanding of what constitutes a minor edit, and there are times when I want to undo an edit but it is not technically a minor edit. This makes me have to manually go to the English Wikipedia and click the "undo" button there rather than keeping all of this in the SWViewer interface.
Is there a way that the WMF could either:
Not automatically mark edits made while "Use undo" is ticked as minor (i.e. submit them to non-minor edits); or
Allow users to select whether or not their actions are considered to be minor edits (via a tick box)?
Hi, I'm not WMF staff (although I am the Wikimedian of the Year) but I noticed something I thought should have wider community input. Please keep in mind that as far as I'm aware this is in very early stages and there is no guarantee that it will actually be implemented. Also, please be nice. I anticipate that some people will be surprised by what it was being proposed here so I felt like this was an important reminder. Anyways: mw:Wikimedia Apps/Team/iOS/Fundraising Experiment in the iOS App. There is a feedback section towards the end of you wish to give it. I have already commented there. Clovermoss🍀(talk)17:47, 10 August 2024 (UTC)[reply]
This is an example of what is being proposed. Essentially, there would be a donation button near the top right of an article and these would kind of be like Reddit trophies. I think this needs way more visibility than being buried in the depths of mediawiki which is why I'm posting here. Clovermoss🍀(talk)18:52, 10 August 2024 (UTC)[reply]
Hi @Clovermoss, it’s Haley from the Mobile Apps team! You’re correct that the project is in very early stages. We just recently published the project page and had planned to start outreach after Wikimania—that’s why folks might not have heard about it yet. In short, the idea is that we want to try out other ways of fundraising beyond just banners – hopefully ways that make readers and editors feel more connected to each other. But we know that fundraising ideas have to be considered carefully, which is why our goal right now is just to be in conversation with the community on high level concepts. We hope people will join the discussion on the project page. P.S. Congratulations on Wikimedian of the Year! HNordeen (WMF) (talk) 16:01, 14 August 2024 (UTC)[reply]
This should have been mentioned at the fundraising brainstorming page as soon as it was published. I object to the "gamification" aspect of giving money to people. I'm not sure how "donating from an article" is an improvement over just having a discrete "donate" button, which we already have. In conclusion: I think this is unnecessary.
Also here – is it THAT HARD to say "introduce", which is a long-standing, universally recognized word, rather than "onboarding" which is today's #1 corporatese-jargon? These things always make the WMF look bad, bureaucratic, corporate, and out of touch. Cremastra (talk) 17:06, 14 August 2024 (UTC)[reply]
@HNordeen (WMF): This is what I meant when I said at the page itself that this is likely to cause a public relations disaster. Imagine a thousand comments like this. Please understand that I really don't think this is a good idea and I don't say this because I wish you to fail but I wish to see everyone suceed. Clovermoss🍀(talk)17:13, 14 August 2024 (UTC)[reply]
I'll also note that the phrase "Microinteraction and confirmation snackbar." was used without apparent embarrassment to mean "a notification/confirmation box". The thing is, phrases like this are inaccessible, and make these pages harder to understand. Cremastra (talk) 17:17, 14 August 2024 (UTC)[reply]
While "microinteraction" definitely should've been left out, that's not a "box". "Confirmation box" sounds like a dialog for you to confirm. A snackbar can only be a small message that pops up from the bottom to tell you that the operation has been a success (sometimes with an ündo" button to the right). Aaron Liu (talk) 18:17, 14 August 2024 (UTC)[reply]
Sorry, what I meant by confirmation box was a box confirming that the operation worked. That is, it's sending you a confirmation, not the other way around. Cremastra (talk) 18:19, 14 August 2024 (UTC)[reply]
That's an important distinction for developers, but I think if the page is targeted to the general public, "notification bar" should suffice. Cremastra (talk) 18:46, 14 August 2024 (UTC)[reply]
I don't mean to sound like a complete crank, but this is, I think, part of the reason some or many editors react badly to WMF pages like this: they're sometimes hard to understand and come off as a bit condescending. I've WP:BOLDly toned down the language so that it's easier to understand for non-developers. Cremastra (talk) 18:12, 14 August 2024 (UTC)[reply]
I appreciate that my comment prompted you to reflect and tone things down a little. [28] I also know that your heart is in the right place too and that a lot of the time these comments are caused by a series of frustrating events and not feeling like one has been listened to. Feel free to tell me if I'm putting words in your mouth, Cremastra. I just know that HNordeen (WMF) is relatively new to the foundation and I don't want her to feel like all of this was directed at her personally. Clovermoss🍀(talk)18:19, 14 August 2024 (UTC)[reply]
I guess I can put this here: I feel like calling this "mobile fundraising" is a little bit misleading. Do not misunderstand me: I sincerely appreciate Clovermoss bringing this here, regardless of the title. But this is not really about fundraising on mobile. That always has happened, and I doubt anyone will have feedback on that. This is about allowing people to donate to "support"/"champion"/"appreciate" a particular article. Would "allowing people to donate in appreciation of a particular article" be a neutral way to phrase what is being suggested? Best, HouseBlaster (talk · he/they) 18:32, 14 August 2024 (UTC)[reply]
I said mobile fundraising because I wasn't sure what else I could put without making it sound like I was canvassing and steering the discussion a certain way. Between here and CENT, I'm sure this will get enough eyes instead of being buried at mediawiki. If someone does change the title, I'd suggest that it's as clear and concise as possible. Clovermoss🍀(talk)18:42, 14 August 2024 (UTC)[reply]
@HouseBlaster: What would you think if we added "experiment" to the end of the current text? It'd make it more clear that what is being proposed is a bit different compared to a normal mobile fundraising. Clovermoss🍀(talk)21:01, 14 August 2024 (UTC)[reply]
I'm largely indifferent to the idea of mobile fundraising in general, and was surprised it wasn't already well established. I'm also mostly indifferent to the idea of donations tied to articles. What I have a quite strong opinion about is what happens when someone donates "to" an article. To the point: there should be no direct connection between donations and the appearance of a Wikipedia article for anyone other than the donor. No matter how it's framed (badges, stickers, sponsors, endorsements, pictures, text, etc.), if there's any way to affect the appearance of the article with money, there will emerge metacommunicative/signalling strategies to manipulate the system in unacceptable ways. On some level, I like the idea of audiences being better able to communicate appreciation to contributors, but it has to be divorced from money. — Rhododendritestalk \\ 18:59, 14 August 2024 (UTC)[reply]
To the point: there should be no direct connection between donations and the appearance of a Wikipedia article for anyone other than the donor.
Agreed. I also see that the WMF recognises at least some of issues this could cause, saying Safeguards should be added to prevent inappropriate usage of the feature on sensitive articles, but I don’t think they’ve thought through the complexity of accurately classifying articles as sensitive.
Alternatively, if they have already succeeded in doing so in a robust manner, can they please release the tool, as it will be very helpful in general? BilledMammal (talk) 00:23, 15 August 2024 (UTC)[reply]
I think the safeguards comment was in regards to the concerns that I and other people expressed at the page itself on why you wouldn't want something like this on controversial articles. As far as I'm aware, this is just an idea and nothing has actually been implemented. That would mean that there isn't a way to filter this content out yet either. Clovermoss🍀(talk)00:41, 15 August 2024 (UTC)[reply]
I encourage people to leave their feedback on the mediawiki page itself (see my initial comments at the top of the thread) so it isn't scattered across pages and projects. Clovermoss🍀(talk)00:45, 15 August 2024 (UTC)[reply]
Thank you to everyone who has spoken up here - I'll echo @Clovermoss's request to please leave thoughts and ideas on the mediawiki project page. The mediawiki page has been edited to make it more clear (thank you for suggestions on how to do that!) and in hopes to communicate that this is at an early stage, and we are not limited to this first idea that is on the page. I've also expanded the page to include risks that have been brought up so far. Thanks to everyone who has contributed, we have the capacity to try a new format of fundraising within the iOS app this year, and we're excited to work together with you to identify what form it could take. HNordeen (WMF) (talk) 21:04, 16 August 2024 (UTC)[reply]
Hi @Clovermoss, it's meant to communicate that we want to change direction to pursue alternate ideas in response to feedback and suggestions we receive. We want to work together with you to figure out ways of recognizing existing donors and creating pathways for potential donors, and we only want to proceed with ideas that we can all feel good about experimenting with. HNordeen (WMF) (talk) 16:16, 23 August 2024 (UTC)[reply]
Wikimedia Foundation banner fundraising campaign in India postponed to start on the 27th of August
Dear all,
As mentioned previously, the WMF is running its annual banner fundraising campaign for non logged in users in India. Initially, we planned the campaign to start tomorrow and run until the 10th of September. We have had some issues with our local payment provider in India and due to this we are postponing the campaign by a couple of weeks. Our new campaign dates are the 27th of August to the 24th of September.
You can find more information around the campaign, see example banners, and leave any questions or suggestions you might have, on the community collaboration page.
Generally, before and during the campaign, you can contact us:
The Open Conversation with the Trustees at Wikimania hosted breakout discussions about the Movement Charter, affiliate strategy and hubs, the proposal for a Global Resource Distribution Committee (hybrid table--had streaming and is available to watch back online), the Product/Tech Advisory Council & Product/Tech priorities, building a sustainable revenue strategy for the movement: online fundraising, Wikimedia Enterprise and the Wikimedia Endowment, and responding to emerging threats to free knowledge: litigation, censorship, disinformation, and trust in an election year.
Editor tools related to references & categories and more tech updates on the latest Tech News.
Outreachy (a paid, remote three-month internship to support underrepresented groups in tech) is open. Mentors should submit projects before September 11 at 16:00 UTC (more info).
The Campaign Events extension is now available on Meta-Wiki, Arabic Wikipedia, Igbo Wikipedia, and Swahili Wikipedia, and can be requested in other language wikis.
Editors using the iOS Wikipedia app who have more than 50 edits can now use the Add an Image feature. This feature presents opportunities for small but useful contributions to Wikipedia.
Some next steps on a movement charter: A message from Wikimedia Foundation CEO, Maryana Iskander, Chair of Board of Trustees, Nataliia Tymkiv, and Chair of Governance Committee, Dariusz Jemielniak.
Elections for four community-and-affiliate elected seats on the Board of Trustees of the Wikimedia Foundation will be held from September 3 to September 17. To learn more about the candidates, watch this short "Meet the Candidates" presentations.
A few minutes ago, shortly after midnight GMT, 3 September 2024, I saw a pop-up message saying that WMF Board of Trustees elections were open, and giving me a link to click. I right-clicked on the link to open a new page, and got a page saying that I was not eligible to vote because 300 edits were required, and I had 39 edits. I tried again, and got the same message. That page was on Meta:, and 39 is in fact my count of edits on Meta:. A few minutes later, that banner was no longer displayed at the top of my English Wikipedia pages. So I think I have at least four questions:
1. Where can I vote for WMF Trustees?
2. Is my analysis correct, that it was using the number of Meta: edits when it should have been using total edits?
Thank you. It now says that I am eligible to vote on English Wikipedia, although the number of edits that it says I have made is somewhat different from what CA shows, but still large. Robert McClenon (talk) 04:44, 3 September 2024 (UTC)[reply]
How does one get one of these invitations? From what's been said I'm sure I am eligible. Does one have to say nice things about the Foundation to be invited? DuncanHill (talk) 22:26, 3 September 2024 (UTC)[reply]
The problem was a bug in the setup; everyone eligible should now be able to vote and doesn't need an exemption. If you're not able to vote even now (and you are eligible please email the Elections Committee. Joe Sutherland (WMF) (talk) 22:48, 3 September 2024 (UTC)[reply]
I found out about the vote via a large WP:CentralNotice banner. If there is a bug, it would be worthwhile investigating, but being condescending makes me less inclined to want to investigate with you. ~ 🦝 Shushugah (he/him • talk) 22:55, 3 September 2024 (UTC)[reply]
I've reported it here. This is the page to communicate with WMF. Monobook, Win 11, Edge. I do not feel safe on Meta after previous experiences there. I am sure I'm not the only editor not to have received notification. People on en-Wiki need to know. DuncanHill (talk) 23:08, 3 September 2024 (UTC)[reply]
@User:the wub I have them all ticked. And even if I didn't, I would rather have assumed that "Certain platform notices, such as those relating to site maintenance and special notices considered necessary to all users, will always be displayed" would cover WMF trustee elections as "special notices considered necessary to all users". DuncanHill (talk) 23:44, 3 September 2024 (UTC)[reply]
Are you saying that you think that who has ultimate control over the Wikipedia servers is really "considered necessary to all users"? Maybe you and we think so, but maybe some people think that is an abstraction, or maybe they think that the "movement" and the servers are only incidentally related. And I haven't seen statements or questions that seem directly relevant to our servers anyway. Robert McClenon (talk) 21:24, 5 September 2024 (UTC)[reply]
FYI I received an email just now about being eligible to vote and containing a link to vote. Looks like WMF is doing a massive email blast today to eligible voters. Hopefully this addresses concerns farther up in the thread about folks not being sufficiently informed. –Novem Linguae (talk) 18:50, 6 September 2024 (UTC)[reply]
Miscellaneous
Less images being uploaded
Why are less images being uploaded today? It wasn't like that from 2006 to 2009, many images were uploaded at that time period. Is there a reason why the image uploads declined after that period of time? MJGTMKME123 (talk) 21:49, 25 August 2024 (UTC)[reply]
There is nothing preventing appropriate and policy-compliant images from being uploaded. As to when it is appropriate to replace an existing image with a new one, that will depend on the specifics: newer isn't necessarily better. AndyTheGrump (talk) 21:57, 25 August 2024 (UTC)[reply]
If someone finds it worth uploading in each particular instance? I have very little clue what sort of general rule you'd expect there to be. Remsense ‥ 论22:03, 25 August 2024 (UTC)[reply]
There is no general answer to this line of questioning. Improved media are uploaded if editors discover or create them; what constitutes an improvement depends entirely on the media in question. Remsense ‥ 论22:18, 25 August 2024 (UTC)[reply]
Do you have an image that you think would illustrate an article better than whatever is already there? Then upload it and add it to the article, replacing the old one. Then, when someone reverts, explain on the Talk page why yours is better. —Tamfang (talk) 17:56, 4 September 2024 (UTC)[reply]
@MJGTMKME123, what do you mean by "less images being uploaded today"?
Do you mean specifically what's being uploaded today, as in Sunday, the 25th of August? (If so, please go to Wikipedia:Village pump (technical) and sound the alarm, because a sudden downturn is probably technical in nature.) Or do you mean "in recent years"?
How much less? Is this like a long-term leveling off? Are you talking about uploads directly to the English Wikipedia, or at Commons? How are you counting the number of uploads? WhatamIdoing (talk) 22:20, 25 August 2024 (UTC)[reply]
We have made efforts to direct uploaders Wikimedia Commons whenever appropriate, so having less uploads here could be a good thing. — xaosfluxTalk22:32, 25 August 2024 (UTC)[reply]
Are you thinking about any images in particular? Again, we can't really answer your question because it's way too broad. Remsense ‥ 论22:38, 25 August 2024 (UTC)[reply]
I'm just asking about the trend of fewer image uploads in the recent years, but I understand if it's too broad. I was wondering if there are any topics where image uploads have noticeably declined. MJGTMKME123 (talk) 22:43, 25 August 2024 (UTC)[reply]
I didn't actually use a tool. I just noticed that most images were made around that time period by just analyzing the date of random images. MJGTMKME123 (talk) 22:59, 25 August 2024 (UTC)[reply]
@MJGTMKME123, I suggest looking at c:Commons:Statistics of uploads vs deletions, which gives the number of annual uploads from 2003 through 2022, and which does not support your hypothesis that there has been a multi-year decline in uploads.
If you know anything about SQL, you can run queries like this and get whatever numbers you want. I use the "check 10 pages in Special:Random" method a lot, but you've got to remember that it's really quite a crude estimate, and if your random images weren't actually random (e.g., they were images used in Wikipedia articles), then you'd be looking at a crude estimate of a biased sample, which is basically worthless. WhatamIdoing (talk) 23:07, 25 August 2024 (UTC)[reply]
That's way more useful data than what I found just below. So uploads to Commons have risen steadily if non-monotonically, and there is no year for which the number of files uploaded was less than any all of the three previous years. Folly Mox (talk) 23:19, 25 August 2024 (UTC)edited 10:16, 26 August 2024 (UTC)[reply]
This wouldn't account for which images are actually being used in articles (plenty of Commons images aren't), but I'd be very surprised if those are mostly pre-2009. ― novov(tc)10:10, 26 August 2024 (UTC)[reply]
What do you base that on? The number of articles in the English Wikipedia has more than doubled since 2009 (3,144,000 on 1 Jan 2010, 6,764,355 on 1 Jan 2024), and images in older articles are often replaced, so I suspect a large majority of images in articles have been added since 2009. For your claim to be valid, editors would have had to be preferencially using images uploaded before 2009 to add to articles. However, an analysis of the upload dates of a large enough sample of images currently in use in articles would be needed to support your claim. Frankly, I don't think that is worth pursuing, as I don't see its relevance to building a quality encyclopedia. Donald Albury13:49, 26 August 2024 (UTC)[reply]
On a related point, please consider looking through the popular articles for a favorite subject area – most WikiProjects have a page like Wikipedia:WikiProject Medicine/Popular pages – and seeing what new images could/should be added. Not having an adequate number of images in each article is a constant complaint from readers, and it even has benefits beyond the obvious value of the image itself (e.g., helping people with dyslexia keep their eyes on the right part of the article). WhatamIdoing (talk) 17:08, 26 August 2024 (UTC)[reply]
Another source for images (which I suspect has been under utilized) are family photos. For example, over his lifetime my Dad took approximately 4,000 photos which are in slide format. While some will be of little interest to Wikimedia in general -- I doubt anyone is eager to see photos of llywrch's first birthday -- there are a number of images that I know will be of interest, such as photos of his business trips to Sudan & Nigeria, photos Oregon from as far back as 1960, & so forth. (I have some of a railway train that ran between Banks & Vernonia back in the 1960s that no longer exists. The trackway has since then been converted to the Banks–Vernonia State Trail. I've already uploaded a few of these to Commons. I'd be far more along with sharing these on Commons except that for many I'm missing information. For example, he visited an agricultural station in a town in Western Sudan -- for which I'd be surprised if we had any photos -- however I don't remember/know the name of that town.I expect there are countless Wikipedians with older family members who were hobbyist photographers, so this is a resource begging to be exploited. (PS, I had discussed doing this with my father before he passed, so I definitely have permission to do this.) -- llywrch (talk) 22:43, 30 August 2024 (UTC)[reply]
There's a reasonably sized subcommunity who decide which news stories are linked at "In the news". The conversations are held at WP:ITN/C. You should be able to participate without an account, assuming some knowledge of Wikipedia policy. Folly Mox (talk) 11:53, 28 August 2024 (UTC)[reply]
I think you have a common misunderstanding of what this section actually is. It is not meant to be a continuously updated news ticker, it is a way of showcasing articles that have been updated to reflect recent events. --User:Khajidha (talk) (contributions) 12:42, 29 August 2024 (UTC)[reply]
Your thoughts are appreciated. If the main page had 138 million page views in the last 30 days, maybe the space could be used for something more intriguing or something that changes every day like the other sections on the main page? 2600:6C4A:4E7F:8D9D:F09D:D640:9B79:6F77 (talk) 18:14, 3 September 2024 (UTC)[reply]
We don't updated ITN particularly quickly compared to a normal news website. I think the normal cadence is a new news item in the ITN box every few days. And there's only around 4 bullets so not that many total news items either. I'm not sure the reasoning for this... maybe limited space, and the editor time it would take to do more voluminous or more frequent updates? –Novem Linguae (talk) 14:15, 29 August 2024 (UTC)[reply]
No, ITN does not have a formal overseer, unlike other mainpage sections which are either driven by a single key volunteer or elected coordinator. But it has plenty of editors who hang around and vote on nominations. Very little gets through this gauntlet and so the section often gets stale, as you have noticed. Most recently, ITN ran the same picture of a cyclist for ten straight days. There were plenty of other pictures that might have been run but no-one was accountable or responsible for making this happen.
The good news is that this doesn't much matter because our readers just go straight to topics which are in the news. For example, the top read article on Wikipedia yesterday was WWE Bash in Berlin. But you'd never see that at ITN because, for some reason, such combat sports get no love at ITN – InedibleHulk can perhaps explain why that is.
If you want to browse what's happening in the world, then the best place to look is Portal:Current_events, which seems to work much better because there's a crew of editors more focussed on posting items than arguing about them. For example, today it reports that "NASA announces discovery of Earth's subtle electric field, which contributes to the polar wind phenomenon." Such interesting science gets little love at ITN too.
I would say that if you want to browse “what is currently happening in the world”, the best place is a dedicated news outlet… not an encyclopedia. An encyclopedia is better for history than current events. Blueboar (talk) 22:21, 1 September 2024 (UTC)[reply]
Thanks for the info. What if that section rotated with fresh links like the other sections on the main page? Are there any current event links on the page? Or how about positive news items to balance the negative trends of the for profit media? If this is an encyclopedia, maybe in the news section might be better as something else? Just wondering. I have no agenda. Seems a waste of potential to me. 2600:6C4A:4E7F:8D9D:F09D:D640:9B79:6F77 (talk) 18:20, 3 September 2024 (UTC)[reply]
These are all good points. The first link above was to discuss ITN candidate articles, but you might also try Wikipedia talk:In the news, which is where to "discuss improvements to the In the news process", and where you'd get responses from the people who would actually make such reforms.
For my part, I'd note that it's not the popularity of the article (or event) that determines if it gets on the main page, but the article's quality (despite the fact that ITN and WP:DYK are made for new-and-improved articles). This could be expressed more clearly about ITN on the main page, but typically a major news story will attract a lot of old and new editors, and consequent quality control, regardless of its appearance on the main page or linking elsewhere. That said, I agree that the section could be more dynamic day by day (while still even restricting it to 4 or so quality items), just by rethinking that instead of being so exclusive about what is added, we be exclusive about what is kept on for more than a single day or two (regardless of whether a news event is considered ongoing). Rotation is a fine idea for a possible implementation. SamuelRiv (talk) 19:10, 3 September 2024 (UTC)[reply]
I see it as "In the news AND likely Wikipedia-notable". I don't say that's any kind of policy, because I don't know. I think Wikipedia should avoid making that section more like a normal news website, because that would force Wikipedia to hire full-time staff to keep it up to date; or if it continued to be done by volunteers, it would be "just like [news site] except incomplete and out of date". Nobody needs or wants a bad copy of what other sites do, to be put here.
What should be done to overhaul the {{dubious}} template? Literally every time I've seen it on an article, there is zero discussion on the talk page about what may be dubious in the article. I discussed this on the talk page a while back, but the discussion just went around in circles and fizzled out. Should a drive be done to remove drive-by instances of this tag where no discernible discussion exists? Ten Pound Hammer • (What did I screw up now?)19:40, 28 August 2024 (UTC)[reply]
I see that you have asked this exact same question at three different locations (here, and at the WP:V and WP:RS talk pages). That is not helpful, as the discussions may end up working at cross purposes. Please choose one location for us to discuss this, and close the other threads. Thanks. Blueboar (talk) 20:34, 28 August 2024 (UTC)[reply]
The position taken by Jason Quinn (pinging) in the discussion you linked, especially So rather than a red link for "discuss" appearing if the parameter is not used, the "discuss" link should only appear if it is used and emphasis on the tag as a marker of dubious content seems rather reasonable. Ifly6 (talk) 16:33, 30 August 2024 (UTC)[reply]
Nothing, users should at least fill out the reason =, and if that's not sufficiently obvious, start a discussion on talk like one would for any other tag. If not, some enterprising soul will likely revert the tag.Selfstudier (talk) 16:52, 30 August 2024 (UTC)[reply]
I think sometimes the |reason= is obvious enough that it doesn't need to be explained, too. I think that sometimes {{dubious}} gets used when the material really ought to have been removed instead, but the editor doesn't feel like it's okay to do that. WhatamIdoing (talk) 17:09, 30 August 2024 (UTC)[reply]
I thought after reading your first sentence, "if it's that obvious then surely the dubious claim should be removed", but then I read and agreed with your second sentence. Too many people are too diffident about removing things. I must say that I think I have used this template a few times, but, as far as I can remember, I have always started a discussion. Phil Bridger (talk) 19:57, 30 August 2024 (UTC)[reply]
Agree with this too. Re Should a drive be done to remove drive-by instances of this tag where no discernible discussion exists? – I don't think there's much of a need to remove dubious without parameters. There are a lot of cases where editors are fearful of stepping on others' toes by just removing it. Ifly6 (talk) 22:14, 30 August 2024 (UTC)[reply]
The {{POV}} templates generally require an active discussion. It's one of our defenses against using then as a badge of shame, since we've had problems with people adding that template as a sort of public protest for not getting their way. I've occasionally cleaned out some old undiscussed ones, but even in an anti-tag-bombing mood, there have been a few never-discussed tags that I thought were very obviously deserved. I expect that some of the {{dubious}} tags are the same: there's no discussion, but you don't need an explanation to know why that's doubted.
@WhatamIdoing: what do you suggest then? Seems every time I bring this up, it just turns into an endless cycle of "We should do something." "Should we do something?" "We should do something." "Should we do something?" and nothing ever gets done. Ten Pound Hammer • (What did I screw up now?)16:22, 1 September 2024 (UTC)[reply]
If you see such tag, it's not obvious why it's there and there is no talk page discussion, just remove it. Also can remove it if it's dated. Selfstudier (talk) 16:44, 1 September 2024 (UTC)[reply]
TPH, I don't think we should particularly worry about this. It's being used in about 0.1% of articles, which isn't much. The problem is sometimes obvious, so no discussion or reason needs to be given. In other cases, a discussion or reason has been given.
But just as we have a {{citation needed span}} template, we can and should have span templates for all inline content tagging. Imo this should be the default expected usage.
(Imo we also should have the inline citations themselves be placed in spans (which may help slow content drift) -- I drafted a template for this, but it's more of a VP proposal I think). SamuelRiv (talk) 23:15, 2 September 2024 (UTC)[reply]
Hard agree on the span question. It's sometimes insufficiently clear what the tag is tagging; moreover, the span is very useful for readers to be signalled as to why some matter might be insufficiently sourced or (here) dubious. Ifly6 (talk) 23:54, 2 September 2024 (UTC)[reply]
Seems a silly reason to delay if tl:c-n-span works acceptably enough. If the core issue is functionality with nesting, there are plenty of workarounds and alternative solutions, since the entire point of the "span" template is just so that editors see what is marked; it's not even necessary that the html span be explicitly encoded (any nested tl:fix-span template markup can just be converted to comments, for example). SamuelRiv (talk) 02:02, 3 September 2024 (UTC)[reply]
I don't regularly use VE, but testing, I don't see a problem editing a cns in a single layer as a template. To delete a template in VE, it seems one has to manually copy contents one wants to keep to a clipboard. The phabricator requests seems to also be about adding a citation to the enclosed text. In any case, there would be alternative solutions. One is that the VE can just keep the enclosed text and change the surrounding template to a custom maintenance template (to be cleaned up by AWB automatically), and the new citation is appended.
The impetus to implement workarounds like this comes if there's an ecosystem of span templates already. The VE has never been perfect; its improvements are incremental, and meanwhile all VE users have to dip into wikisource from time to time.
Another quick solution of course is to, instead of using text-enclosure templates, use html span tag substitution templates (one template to open, one to close, with the benefit that the closure template includes the maintenance tag, so it's more likely the editor leaves a dangling closure than opener). tldr: I still see no fundamental technical reason for not making every citation flag spannable, today. SamuelRiv (talk) 05:50, 3 September 2024 (UTC)[reply]
It's not about fundamental technical reasons. It's about user experience. We ought to make adding citations as easy as possible, especially for newbies, so they learn to add citations from their very first edits. The fact that I know some workarounds doesn't mean that it's a good idea. Not only do I have more experience than 99.995% of editors, I also wrote a good deal of the help pages for the visual editor. The visual editor should be designed to work for people on their first edits, not on their hundred thousandth edits. WhatamIdoing (talk) 06:02, 3 September 2024 (UTC)[reply]
?` for each symbol of string ` template ?
does such a template exist and/or is there some other way to achieve the effect of calling a template with the every symbol of a given string as the argument
also i apologize if this is the incorrect place to ask- if so please point me to the correct one so that i can ask any further questions about templates there
thanks in advance akizettalk20:41, 31 August 2024 (UTC)[reply]
not moving the discussion as it would result in the same question beïng in two places which seems undesirable what i meant was a {{for loop}}-like template such that e.g {{template name|key press|abc}} results in ` abc `
howëver i have since reälized i might not need it for what i'm doïng after all · still would be helpful though
I am pleased to announce the following individual as regional members of the U4C, who will fulfill a term until 15 June 2026:
North America (USA and Canada)
Ajraddatz
The following seats were not filled during this special election:
Latin America and Caribbean
Central and East Europe (CEE)
Sub-Saharan Africa
South Asia
The four remaining Community-At-Large seats
Thank you again to everyone who participated in this process and much appreciation to the candidates for your leadership and dedication to the Wikimedia movement and community.
Over the next few weeks, the U4C will begin meeting and planning the 2024-25 year in supporting the implementation and review of the UCoC and Enforcement Guidelines. You can follow their work on Meta-Wiki.
I'm thinking how to illustrate some different definitions in Pandemic. These can be hypothetical; the point is just to communicate that different definitions sometimes have different answers to the question of "Is this a pandemic?"
I've been thinking about a table that says something like this:
Fact
Required for definition #1
Required for definition #2
More than 1% of people infected
Y Yes
N No
Schools closed
N No
Y Yes
Limited population immunity
Y Yes
N No
Hospitals overwhelmed
N No
Y Yes
Affecting more than two countries
N No
Y Yes
Affecting more than 10% of world population
Y Yes
Y Yes
Rate of infection higher than normal
Y Yes
Y Yes
but then finds a way to present a couple of situations, and says "For story A, it's a pandemic according to definition #1 but not #2; for story B, it's a pandemic according to both definitions; for story C, it's not a pandemic according to definition #1 but it is according to definition #2". I'm not sure how to present this in a way that could be clear at a glance. WhatamIdoing (talk) 17:39, 4 September 2024 (UTC)[reply]
I'd do it with bullets rather than a table. (At first glance, "X No" might suggest to the reader that meeting this criterion positively disqualifies from meeting the definition.) Like this:
While I was working on the article I went on the article, Hōgyū Jizō expecting to add it to the list but the thing is that Hōgyū Jizō is a group of Buddha statues but like lots of Buddha statues (107 in total) so I don’t know if I should add all off them to the list, add them all collectively as a group to the list and add a note saying how it is a group of Buddha statues and not a singular statue or to just not add anything about it all together. Outlined Sandbox (talk) 18:27, 4 September 2024 (UTC)[reply]
My criteria for notability in the list is if the Buddha statue has a reference, its own article or section within an article.
The thing is that the statues as a group have their own article so as a group I would consider them notable but separately they are not notable so I don’t know whether to just not have anything about it in the draft or just to add it as a group collectively with a note about how it is a group. Outlined Sandbox (talk) 20:14, 4 September 2024 (UTC)[reply]
Lists that are mostly about single examples of a topic often include links to articles about a group. See, for examples, List of islands of Florida, in which several items are about groups of islands. Lists should be about helping readers find articles about a particular type of thing. Donald Albury22:00, 4 September 2024 (UTC)[reply]
Hi everybody. I was searching about a person named Geoffrey Duchet, but he doesn't have any biography in wikipedia. He was british explorer and he visited persepolis in 1569 AD. My source about him was a persian translated of 1 of books of Alfons Gabriel means Geographical research about Iran (unfortunately all of his books is in german language, and i don't know do any of you can read german books or not). Can somebody build Geoffrey Duchet's biography's page on english wikipedia? Hulu2024 (talk) 13:19, 6 September 2024 (UTC)[reply]
And i shall add that i don't have any access on printed books on Geoffrey Duchet's biography to build his page, on myself. please if someone have access to english books on 16 th century, please write his biography. i needed it strongly. Hulu2024 (talk) 13:23, 6 September 2024 (UTC)[reply]
I eager but i don't have access to academic and primary sources. It's odd that USA and UK have best universities with best storage of book (with monetary online access for western countries) and english wikipedia does the most editors in all languages, but nobody made this historical person's biography. Hulu2024 (talk) 13:43, 6 September 2024 (UTC)[reply]
@Hulu2024: Geoffrey Duchet may not have been notable in his day, hence the lack of coverage. I pretty much could only find modern day people by that name with a Google search.
The only mention that I found of his name in a Wikimedia article space was in Farsi, fa:ایرانشناسی (English version of the article is Iranian studies). At the end of the sentence mentioning him as جفری داکت, there is a footnote that points to a shortened footnote, موسوی، تخت جمشید، ۱۴. [Mousavi, Persepolis, 14], which then appears to point to a full citation of an encyclopedic text,موسوی، علی (۱۳۸۵). «تخت جمشید». دائرةالمعارف بزرگ اسلامی. ج. ۱۴. تهران: مرکز دائرةالمعارف بزرگ اسلامی. شابک ۹۶۴-۷۰۲۵-۵۴-۸. بایگانیشده از اصلی در ۷ اوت ۲۰۲۴. دریافتشده در ۷ اوت ۲۰۲۴. [Mousavi, Ali (1385). "Persepolis". The great Islamic encyclopedia. c. 14. Tehran: Center for the Great Islamic Encyclopedia. Shabak 964-7025-54-8. Archived from the original on August 7, 2024. Retrieved on August 7, 2024.]
@TooManyFingers Because he was traveler and he travels to persepolis in 1569 and his wrote about that at his memorial, i want to improve my article in persian wikipedia (iraian studies) to be choose as Featured articles, so i need enough information about him. Persepolis is one of iranian's historical monument, which european travelers had seen, and that was the motivation to start about iranology. Hulu2024 (talk) 21:11, 7 September 2024 (UTC)[reply]