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
Date redirects to portals?
16 August 2006 points to the current events portal as a result of this discussion. However, date redirects will continue to come up at RfD, some some wider community discussion and input is helpful on whether or not the current events portal is an appropriate target for mainspace redirects. See also: this ongoing discussion for some context.
The second question is easy: Yes, portals are part of the encyclopaedia. As to the first question, portals are reader-facing content and so I see no reason why they wouldn't be appropriate targets for mainspace redirects, given that uncontroversially target mainspace redirects to reader-facing templates and categories when they are the best target. Whether the port is the best target for a given date will depend on the specific date but in general the portal should always be an option to consider. Thryduulf (talk) 01:32, 30 October 2024 (UTC)[reply]
I agree with this. The portal is definitely not always the best option and it has its limitations, but, as I wrote at WP:RDATE it should be considered and assessed along with mainspace articles. Cremastra (u — c) 01:44, 30 October 2024 (UTC)[reply]
If a namespace doesn't have the same standards as mainspace, then the reader shouldn't be redirected there while possibly not realizing they are now outside of mainspace. Yes, there is more content at Portal:Current events/August 2006 than at 2006#August, but the reader is now facing a decades-old page with no quality control, where links to Breitbart are misleadingly labeled as (AP). Chaotic Enby (talk · contribs) 00:50, 6 November 2024 (UTC)[reply]
Portal does have the same standards as mainspace. That a portal is not up to those standards is no different to an article being in bad shape - fix it. Thryduulf (talk) 00:54, 6 November 2024 (UTC)[reply]
No, because they are not articles. Two things can be held to the same standard without being the same thing. Criterion P1 previously allowed that (indirectly) but it was repealed in 2023 due to lack of use. Thryduulf (talk) 19:42, 7 November 2024 (UTC)[reply]
Then they aren't held to the same standards... More in general, no, they obviously aren't held to the same standards, e.g. a portal page doesn't have to be a notable topic but may be purely decorative or (as is the case with the date pages) be a list of mainly non-notable things, failing WP:NOTNEWS and WP:LISTN. That some standards are the same (BLP, copyvio, ...) can also be said for e.g. user talk pages, and we don't redirect to these pages either. Fram (talk) 20:24, 7 November 2024 (UTC)[reply]
We don't redirect to user talk pages because they aren't reader-facing, so that's irrelevant. We don't hold reader-facing templates and categories to article content policies (because they aren't articles) but we do redirect to them. Don't conflate quality standards with inclusion policies, they are not the same thing. Thryduulf (talk) 21:15, 7 November 2024 (UTC)[reply]
I wasn´t aware that the standards we were talking about were solely quality standards, whatever these may be, and not content standards, sourcing standards, ... I´m sadly not amazed that you consider these irrelevant when deciding what to present to our readers. Fram (talk) 21:37, 7 November 2024 (UTC)[reply]
In theory, I think portals should be held to the same CSD criteria as articles. But of course the A criteria actually only apply to articles. Cremastra (u — c) 22:08, 7 November 2024 (UTC)[reply]
There's a lot of random junk in portalspace, but yes, it is part of the encyclopedia. Just like categories and templates, portals are reader-facing content. CFA💬
I didn't really have super strong opinions on portals until seeing this one link to Breitbart, twice, in a misleading way. This is not okay. I agree with Fram that clearly Portals are not being held up to the same standards as regular articles and it might be a bad idea to redirect readers to them. Toadspike[Talk]23:00, 7 November 2024 (UTC)[reply]
I saw this on CENT, and I am confused by the question. Portal:Current events/2006 August 16 is very different from something like Portal:Belgium, and it doesn't make sense to pretend they are the same to establish policy. And what does "part of the encyclopedia" even mean? "Interpreting a confusing phrase" is a terrible way to decide redirect targets. For the specific question of "Should dates redirect to the Current Events portal rather than to a page like August 2006 ... I don't know. I don't see a compelling reason why they can't, nor a compelling reason why they should. Walsh90210 (talk) 15:45, 8 November 2024 (UTC)[reply]
Hey, that's a nice Portal! Thank you for restoring my faith in portals. Clicking on "Random Portal" took me to Portal:Trees, which is also pretty nice. My opinion is now that yes, portals can be good, but it seems to me that we currently have no Ps and Gs to apply to their content or measure their quality, no consensus about how to direct readers to them, and a very checkered and controversial history of deletion. I really dunno what to do about them. Toadspike[Talk]16:49, 8 November 2024 (UTC)[reply]
No, we should not redirect dates to the current events portal subpages. It's a cross-namespace redirect that takes readers from somewhere they expect to be (an encyclopedia article on the topic "16 August 2006") to somewhere they don't expect to be (a navigational aid(?) that highlights some things that happened that day). I'm not 100% sure what the current events portal subpages are for, but they're not meant to stand in as pseudo-articles in places we lack real articles. Ajpolino (talk) 22:04, 8 November 2024 (UTC)[reply]
Cross-namespace redirects in and of themselves are not a problem. They only cause issues when they take someone expecting reader-facing content to "backroom" content (e.g. project space). Both article and portals are reader-facing content, so this is not an issue. Thryduulf (talk) 22:17, 8 November 2024 (UTC)[reply]
Is there another case where we link a reader from an article to a non-article without clearly denoting it? E.g. I have no problem with the {{Portal}} template folks often use in the See also section. Ajpolino (talk) 01:12, 9 November 2024 (UTC)[reply]
Thanks. Okay, Citeweb is a bad example, not something readers look for but something editors look for. The other 2 are among the 6 existing reader facing redirects to templates (from Category:Redirects to template namespace, the only ones which are from mainspace and not editor-related like the cite templates). Not quite the "lots" you seemed to be suggesting throughout this discussion, but extremely rare outliers which should probably all be RfD'ed. Fram (talk) 11:42, 10 November 2024 (UTC)[reply]
Yes, the current events portals are valid redirect targets for dates and preferred in this case of the best article redirect for a specific date being the month section of an article on an entire year. I agree with Fram that portals are not held to the same standards as articles, but I disagree with Ajpolino's stance that a cross-namespace redirect is so disruptive that they are prohibited in all cases, given that WP:Portal says "portals are meant primarily for readers." ViridianPenguin 🐧 ( 💬 ) 23:46, 8 November 2024 (UTC)[reply]
Commenting strictly on the "are portals part of the encyclopedia" question, yes it is. Unfortunately there was one extremely loud, disruptive voice who kept making portals less useful and suffocating any discussions that would make it more beneficial to readers. Plenty of willing portal contributors, including myself, left this space and readers are still reaping the seeds of what that disruptive user planted even after they have been ArbCom banned over a year ago. So it may given some people an illusion that portals aren't doing much towards the encyclopedic goal, because the current status is handicapped by its history. I'm reserving my views on the redirect part of the discussion. OhanaUnitedTalk page07:29, 9 November 2024 (UTC)[reply]
Not, portals are not held to the standards of articles, and if something for whatever reason shouldn't be or can't be an enwiki article, this shouldn't be circumvented by having it in portalspace. Either these date pages are acceptable, and then they should be in mainspace. Or they are not what we want as articles, and then we shouldn't present them to our readers anyway. Fram (talk) 11:42, 10 November 2024 (UTC)[reply]
These current events pages differ from articles in many respects, but the referencing standards are similar. Whether they happen to be prefixed by "Portal:" or not is not reflective of their quality. J947 ‡ edits23:18, 11 November 2024 (UTC)[reply]
The current events portal example listed seems encyclopedic enough, in that apart from some formatting differences it might as well be a list article, but I've seen other portals that have editor-facing content that is more dubiously appropriate for mainspace. Consider, for example, Portal:Schools § Wikiprojects (capitalization [sic]) and Portal:Schools § Things you can do, and the similar modules at many other portals. Sdkbtalk18:27, 13 November 2024 (UTC)[reply]
Yes, speaking as a recognized portalista, portals have not yet been excised from the pedia. In this case, User:J947 makes the essential point. I'm not convinced that even incomplete, out-of-date portals are any less encyclopedic than the 2 million or so Wikipedia articles nobody bothered to edit last year. BusterD (talk) 14:53, 19 November 2024 (UTC)[reply]
Issues with antiquated guideline for WP:NBAND that essentially cause run of the mill non-notable items to be kept
5.) Has released two or more albums on a major record label or on one of the more important indie labels (i.e., an independent label with a history of more than a few years, and with a roster of performers, many of whom are independently notable).
6.) Is an ensemble that contains two or more independently notable musicians, or is a musician who has been a reasonably prominent member of two or more independently notable ensembles. This should be adapted appropriately for musical genre; for example, having performed two lead roles at major opera houses. Note that this criterion needs to be interpreted with caution, as there have been instances where this criterion was cited in a circular manner to create a self-fulfilling notability loop (e.g., musicians who were "notable" only for having been in two bands, of which one or both were "notable" only because those musicians had been in them.)
These appear to have been put together by a very small number of editors over a decade ago and hasn't seen much change since then and I feel it's much more lenient than just about anything else. This SNG defines a "label" that has been around for over "a few years" that has a roster of performers as "important". So, any group of people who have released two albums through ANY verifiable label that has exited for more than a few year can end up being kept and this isn't exactly in line with GNG. I believe a discussion needs to be held in order to bring it to GNG expectations of now.
Especially given how broadly the various criteria have been "interpreted" in deletion discussions, the best way to go about it is just to deprecate the whole thing. Rely on the GNG for band notability, and if that results in a heap of articles on ephemeral outfits, garage bands and local acts vanishing, huzzah. Ravenswing 09:07, 30 October 2024 (UTC)[reply]
The SNG isn't workable in the age of digital distribution. It's very easy to create "an independent label with a history of more than a few years". If someone wants to suggest a way to reform the SNG, I am open to solutions. But deprecation is a simple alternative if we can't. The GNG is always a good standard because it guarantees we have quality sources to write an article. Shooterwalker (talk) 14:22, 30 October 2024 (UTC)[reply]
I was active in AfD discussions when NBAND was pretty new, and it was useful for dealing with a flood of articles about garage bands and such, but I think our standards in general have tightened up since then, and I agree it is time to review it. There is the possibility, however, that revising NBAND may require as much discussion as revising NSPORT did. Donald Albury17:49, 30 October 2024 (UTC)[reply]
I guess the underlying question is: Is there actual harm in having a permastub about a band that proves to be borderline in GNG terms? Consider this:
"Alice and Bob are a musical duo in the science fiction genre.[1] They released their first album, Foo, in 2019 and their second, Bar, in 2020. Both albums were released by Record Label.[2] They are primarily known for singing during a minor event.[3]"
I'm asking this because I think that the nature of sources has changed, particularly for pop culture, since NBAND and the GNG were written. We now have subjects that get "attention from the world at large", but which aren't the Right™ kind of sources and, while these Wrong™ sources definitely provide "attention", some of that attention might not provide biographical information (which means we're looking at a short article).
For example, instead of getting attention in the arts section of a daily newspaper, they're getting attention from Anthony Fantano on YouTube. He's an important music critic,[1] but I suspect that our knee-jerk reaction is "Pffft, just some YouTuber, totally unreliable". Consequently, we might rate a band that we theoretically intend to include ("attention from the world at large") as not meeting the GNG (because the whole field relies on the Wrong™ style of sources). WhatamIdoing (talk) 19:02, 30 October 2024 (UTC)[reply]
Keep in mind that like most other notability guidelines, it is a presumed assumption that a topic is notable if it meets these criteria. If you do an exhaustive Before and demonstrate there is no significant coverage beyond the sourcing to satisfy there criteria, the article should still be deleted. None of the SNGs are geared towards preventing this type of challenge. — Masem (t) 19:30, 30 October 2024 (UTC)[reply]
If we had to yield to presumptive notability about some random band because it released two albums with Backyard Trampoline Recordings established few years ago and had to do exhaustive search to disprove notability, we're getting setup for a situation where removal is 10x more challenging than article creation. So.. I see a great value in scrapping NBAND 5, and 6. Graywalls (talk) 00:47, 31 October 2024 (UTC)[reply]
Welcome to WP:SNGs. As Masem said, they're supposed to be a rough idea of gauging notability before exhaustively searching for sources. But pretty much all of them have ended up being used as means to keep articles about trivial or run-of-the-mill subjects. Thebiguglyalien (talk) 19:37, 30 October 2024 (UTC)[reply]
Graywalls listed two criteria but the main discussion seems to be about the 1st (#5). I agree with Graywalls on that. With the evolution of the industry, the label criteria is no longer a useful indicator as it once was and IMO #5 should be removed or modified. Sincerely, North8000 (talk) 19:13, 30 October 2024 (UTC)[reply]
I've noticed that as well. I think #6 has some value still, while #5 is like saying an author who has published two or more books by a major publishing house is presumed notable. Way too low a bar without requiring some level of reception of those albums/books. (WP:NAUTHOR doesn't have that 2-book criteria, of course, just seems like parallel benchmarks.) Schazjmd(talk)13:25, 31 October 2024 (UTC)[reply]
On the other hand, in this case, I suspect that an artist that "has released two or more albums on a major record label or on one of the more important indie labels" will in 99% of cases have enough coverage to clear the GNG bar. I'd like to see an example of one that doesn't. Black Kite (talk)13:29, 31 October 2024 (UTC)[reply]
The definition of important as said in #5 is "history of more than a few years, and with a roster of performers, many of whom are independently notable". This would mean that a garage band is notable, because they've released two CD-R albums on Rotten Peach Recordings which has been around for 3 1/2 years, has a roster of performers and some of whom have a Wikipedia page on them. Often time "notable" is determined by the presence of a stand alone Wikipedia page. When you look at the page, many band member pages are hopelessly non-notable, but removal takes an AfD. So a simple deletion can become a time consuming multi-step AfD. Graywalls (talk) 19:18, 31 October 2024 (UTC)[reply]
Not opining on that band's notability, but Metal Blade is a famous independent label that has existed for 42 years, has released material by very high-profile bands, and is distributed by Sony - it's not some one-person imprint operating out of their garage. Black Kite (talk)11:28, 1 November 2024 (UTC)[reply]
I concur regarding that particular example. Metal Blade is a big label, and not surprisingly notability was quickly demonstrated in the deletion discussion through citing reliable source coverage. And that's how #5 should work - artist is on a significant label, which suggests coverage exists. And then coverage is found.--3family6 (Talk to me | See what I have done) 12:08, 16 November 2024 (UTC)[reply]
The elephant in the room here is that entertainment journalism is in crisis mode right now, publications are operating on skeleton crews, and the range of coverage has narrowed dramatically. I encourage everyone taking part in this discussion to read the article I linked, there are a lot of assumptions being made about the way things work that aren't true. Gnomingstuff (talk) 20:30, 19 November 2024 (UTC)[reply]
One suggestion I would add is to make these two criteria apply only to bands before a specific year, that year being where physical releases still dominated over digital sales. I don't know the exact year but I am thinking it's like around 2000 to 2010. There may still be older groups during the time of physical releases that don't yet have articles that would fall into one of these criteria. Masem (t) 20:02, 31 October 2024 (UTC)[reply]
As someone who's had WP:DSMUSIC watchlisted for most of their editing history, and who tends towards deletion at that, I actually don't see much of a problem with these criterions. It certainly seems true that the majority of musicians who are signed to a label or a member of multiple bands with two other musicians who meet WP:GNG themselves meet GNG. I do think it is sometimes justified to accept less-than-GNG sourcing in articles where a SNG is met (see Wikipedia:Articles for deletion/John LeCompt for this as it applies to c6 specifically) and more importantly, NMUSIC contains language that allows deleting articles even where it is technically met (see Wikipedia:Articles for deletion/Rouzbeh Rafie for an extended argument about that. Mach6123:29, 31 October 2024 (UTC)[reply]
I've understood these criterion to be supplementing GNG, that is, that if a band or individual artist meets one or more of these criterion, they *likely* are notable. However, in the past when I was a younger and less experienced editor, I think I did understand these as being additions or alternatives to GNG. So I think that should be clarified. This has come up on the deletion discussion for Jayson Sherlock. He is a member or former member of several very notable bands, and for that reason I presumed that he would easily have independent coverage about him specifically. However, to my surprise, there's only one interview of him in a reliable source that would provide notability (there's some interviews on personal blogs or minor sites that wouldn't be RS except for him making statements about himself). But at least one editor has used the above criterion to argue that the article should be kept.--3family6 (Talk to me | See what I have done) 12:20, 1 November 2024 (UTC)[reply]
Just as an aside, interviews do not contribute to GNG unless they include secondary independent SIGCOV (such as a substantial background introduction by the interviewer). JoelleJay (talk) 15:39, 1 November 2024 (UTC)[reply]
That's how I see most SNGs (and the outliers ought to follow their lead). At the very least, we can clarify that NBAND is meant as an indicator for the GNG, and not a substitute. Shooterwalker (talk) 02:04, 2 November 2024 (UTC)[reply]
As someone who thought the old NSPORTS was wildly overinclusive and needed cleanup... these NBAND guidelines don't seem that bad? If two plainly notable musicians were discovered to have done some obscure team-up in the 1970s, that does indeed seem to be a notable topic and useful to have linked somewhere, even if there isn't tons of info on this collaboration. It's worth mentioning because minor subtopics are often merged to the overarching topic (e.g. songs to the album), but there may not be a clear merge location for this if both parties were equal contributors, and a short separate article is an acceptable compromise. Similarly, the complaint about #5 seems to be about just how "indie" the hypothetical label is, but this seems like a solvable problem. If a band fails GNG, that implies that either their two albums really were from a very obscure indie outfit and thus also fail NBAND, or else that we have some sort of non-English sources issue where we may consider keeping on WP:CSB grounds (i.e. that sources probably do exist to pass GNG, but they're difficult to find, and we can trust they exist because this was a major and notable label releasing the band's work). About the only suggestion I can offer is that the comment in 6 about avoiding circular notability could probably be phrased in the sense of GNG, i.e. that the two notable musicians need to both meet GNG and then this will create a new, safe NBAND notability for their collaboration. SnowFire (talk) 17:36, 4 November 2024 (UTC)[reply]
Agreed with deprecation; "Rely on the GNG for band notability" is the correct answer. And is the correct answer for many other things about which we have SNGs that attempt to be alternatives to GNG. Perhaps the only justifiable one is WP:NACADEMIC, because special considerations apply in that sphere (academics and other journal-publishing researchers are generally unknown the public and the public-facing media coverage like newspapers but may have major impacts in particular fields and on the world; what determines their influence level is primilar the frequency of citation of their work by other academics). No such special considerations apply with regard to bands or most other categories. We have some SNGs that are helpful because they are written to comply with GNG, to explain predictively what is most likely or unlikely to pass a GNG test at ANI, rather than trying to be an end-run around GNG. If we actually needed an SNG for bands and musicians, then the current SNG for them could be replaced by something like that. However, we don't actually need an SNG for bands and musicians.
PS: The ideas in the current NBAND SNG are daft. Lots of musical acts have multiple albums (i.e. tracks released at the same time under a grouping title) and lots of indie labels (which may just be some dude in his bedroom) exist with multiple acts, some of them nominally notable [because of NBAND's issues, making this a vicious cycle!], but that doesn't actually make every band on that notional label (nor the label itself) enclopedia-worthy. Some of these are farcically obscure acts [not a denigration – I'm probably buying their stuff]. This is not 1977; you do not need a vinyl pressing plant to be a music label. You just need to figure out how to fill in a web form at Bandcamp and Spotify, and have enough of a clue about how the present music industry works (often just within a narrow subculture) that you can convince some acts (probably your friends in the same scene) that you can help them if they agree to be on your roster. PPS: A side issue is that "albums" isn't a good metric anyway, since several genres are not album-driven at all, and the entire notion of albums is being increasingly questioned in the era of on-demand music. — SMcCandlish☏¢ 😼 21:59, 15 November 2024 (UTC)[reply]
See WP:NPLACE, which presumes populated legally recognized places are notable. So, all it takes is prove the legal recognition and presence of people and it's assumed to be notable, unless refuted.
A legally recognized city is presumed, but not guaranteed notable. If it doesn't meet GNG, then the presumed notability can be refuted. It does essentially "override" GNG though a short cut, but is subject to removal by presenting failure to meet GNG.
Such presumption is not present for most things. For example, simply quoting a local paper about a gas station opening up and operating demonstrates existence of that gas station, but there's no presumed notability for businesses.
NBAND 5 and 6 qualifies bands and albums into Wikipedia far easier than they should and they stand as a burden to article deletion due to presumed notability under tenuously defined importance, such as having released two albums through an important indie label Four Legged Octopus, which is "important" because the MailBox Etc based label has been around for five years and has a roster. Graywalls (talk) 16:55, 18 November 2024 (UTC)[reply]
Not speaking to this issue directly, but the trend in subject specific guidelines, IMHO, has been to reduce the influence of SNGs relative to GNG, not override. When we started these projects 20 years ago, almost every article was low hanging fruit, almost bound to be found notable eventually. As an example, Military History Wikiproject adopted and modified WP:SOLDIER, a set of specific and non-subjective criteria which if met gave an indication of presumption of reliable sources being found somewhere eventually. This was intended to screen out a lot of "dead veteran I know" articles, not become the floor for inclusion. When it finally came up for discussion it was made clear SOLDIER was just a project thing and wasn't itself an approved SNG. It was quickly decommissioned, but SOLDIER criteria was for many years a frequently mentioned keep argument at AfD. As another example, WP:SPORTSPERSON is another project related shorthand (but consensus-approved SNG), which made it more difficult to create and keep articles about athletes without at least one source with significant coverage, which still seems a low bar indeed. IMHO the original intent of such SNGs was to screen article candidates, but as the pedia grew, we started using SNGs to keep them. Adjusting SNGs to meet the modern usage era seems the practical and accepted path. The medical SNGs are still used as exclusionary, and for the best reasons. BusterD (talk) 15:21, 19 November 2024 (UTC)[reply]
Blind enforcement of 1RR/3RR does not serve the project. The question should not be whether one violated the rule, but whether they violated the rule in a way that does not benefit the article. If there is no objection to the violation, we can reasonably assume that they are benefiting the article, or at least causing no harm. The decision should be left in the hands of other editors. Could this be used as a weapon? Would there be editors who claim harm where none exists? Certainly, but that's preferable to what we have now.
The problem, no doubt familiar to editors reading this, is that there are often not enough "good" editors around to protect an article from "bad" editors (malicious or merely inexperienced) while staying within 1RR/3RR. There is no restriction on the number of BOLD edits by a given editor, or on the number of editors performing BOLD edits. ―Mandruss☎00:09, 10 November 2024 (UTC)[reply]
If someone is repeatedly reverting reverts, then there is objection to the violation by definition. That's what edit warring is. If someone is making the same BOLD edit that needs to be reverted multiple times, then they are also edit warring. There are already exceptions with these rules for patent nonsense or obvious vandalism. If there's routine disruption, then it only makes the problem worse to revert over and over instead of taking it to WP:RFPP. If you feel the need to make more than one or two reverts in a content dispute, then it's time to either consider other options or step away from the article. Thebiguglyalien (talk) 01:31, 10 November 2024 (UTC)[reply]
It's not about edit warring or re-reverts; the problem exists without a single re-revert. Editor A does ten BOLD edits, five of which are detrimental to the article because they are too inexperienced (this stuff takes years to master, so that's far from uncommon). Editors B, C, D, and E contribute an additional twenty detrimental edits (along with any number of good ones, that number being irrelevant for our purposes here). Meanwhile, competent editors F, G, and H are limited to a total of nine reverts, leaving 21 detrimental edits in the article. I say F, G, and H should be allowed to revert until someone claims they are doing harm. ―Mandruss☎02:04, 10 November 2024 (UTC)[reply]
Where are you seeing thirty detrimental edits to an article in every day? Why isn't this article protected? Why aren't editors F, G, and H starting a discussion? Why are they reverting Editor A's edits individually instead of rolling them back? Why is it so urgent that these edits need to be reverted right this moment? Even on the off chance that they encounter such an article that exists, F, G, and H would not need to engage in tag-team reverting (which is still edit warring) if they knew what they were doing. Thebiguglyalien (talk) 02:07, 10 November 2024 (UTC)[reply]
You are welcome to reduce the numbers as you please; the problem exists regardless. The article is protected, even with ECP, and there is no shortage of registered editors who have 30 days and 500 edits and still have years to go before they are editing with any reasonable level of competence. Some never reach that point. Why aren't editors F, G, and H starting a discussion? Seriously? Why are they reverting Editor A's edits individually instead of rolling them back? Because (1) they may not have the rollback right, and the rollback right should not be required to function as an editor, (2) they would be rolling back five good edits, and (3) it's impossible if Editor A's edits are interleaved with those of any other editor(s). Why is it so urgent that these edits need to be reverted right this moment? Because (particularly in large and very active articles) the bad edits can easily be missed if not caught immediately. Then they stay in the article for some unknown amount of time until noticed by a competent editor and corrected with a BOLD edit. Could be months or even years. Is that good for the article? ―Mandruss☎02:27, 10 November 2024 (UTC)[reply]
Could you give an example or two where this has caused a problem? And I note that you have answered the two most important questions inadequately: if an article is subject to edit-warring it should be fully protected, and you dismissed "Why aren't editors F, G, and H starting a discussion?" with "Seriously?". Yes, of course it's a serious question. Starting a discussion is the best way of defusing an edit war. Phil Bridger (talk) 09:20, 10 November 2024 (UTC)[reply]
"Seriously?", while counter to the WP:DR policy, might be an honest response. I often get page protection or block requests, where my first response is often "where's the discussion?" —Bagumba (talk) 10:02, 10 November 2024 (UTC)[reply]
Unless Mandruss is extremely lazy, for which I have no evidence, I don't see how that response can be honest. It only takes a few seconds to start a discussion, no longer than it took to start this one, and the person who starts it wins some extra points. Phil Bridger (talk) 17:08, 10 November 2024 (UTC)[reply]
extremely lazy, for which I have no evidence Thank you! I have my share of faults and shortcomings, but I don't think extreme laziness is one of them. So there should be new discussions for each of the bad edits (separately for the sake of efficiency and organization), and the bad edits should remain in the article until enough editors have the time, interest, and attention span to form consensuses against them while attending to other important matters. This, at an ATP where we're struggling to keep the ToC at a manageable size even without such discussions. I don't know what articles you're editing, but I want to work there. ―Mandruss☎03:51, 11 November 2024 (UTC)[reply]
I gather the Donald Trump article is a rare anomaly where bad content is something we have to live with because the current rules are incapable of preventing it. After all, it's just one article. I would oppose that reasoning. I'd say article quality is at least as important there as anywhere else. ―Mandruss☎04:33, 11 November 2024 (UTC)[reply]
So there should be new discussions for each of the bad edits ...: Yes, or what is an alternative? Your suggestion to favor "good" edits over "bad" is problematic when everyone says their's are the "good" ones. Polarizing topics can be difficult for patrolling admins to WP:AGF determine "good" v. "bad" edits if they are not subject matter experts.—Bagumba (talk) 05:43, 11 November 2024 (UTC)[reply]
Remember that consecutive edits by a single editor are treated as a single revert for WP:3RR purposes. So, in your case, editor H can go back and revert the various bad edits and, even if they mechanically break it out into multiple edits, they still have done one revert... Until someone goes back and re-reverts. Simonm223 (talk) 19:58, 20 November 2024 (UTC)[reply]
What do you mean, who said? I said something about repeated edits :-) If the rule were "do not repeat edits without consensus" 1x or 3x in 24 hours, instead of "do not revert" 1x or 3x in 24 hours (which leads to the whole "what exactly counts as a revert?" issue), the problem you are describing would not happen. The 'bad' editor can make 10 bad edits, and the 'good' editor can revert all 10 edits without violating do-not-repeat-3RR, and the 'bad' editor would be able to repeat 3 of those 10 edits without crossing do-not-repeat-3RR, and the 'good' editor can revert all 3 of those without crossing do-not-repeat-3RR, et voila: equilibrium. The problem is we focus on "revert" instead of "repeat." To tamp down on edit warring, we should prohibit people from repeating their edits, not from "reverting" (whatever that means, exactly) edits. Levivich (talk) 04:50, 10 November 2024 (UTC)[reply]
Blind enforcement of 1RR/3RR does not serve the project: Are you referring to page protection or blocks? On contentious topics or any subject? —Bagumba (talk) 05:11, 10 November 2024 (UTC)[reply]
This appears to be a Verifiability policy issue, not an evaluation of specific sources. Why are we holding the discussion on a noticeboard? Why not here or at WT:V? BusterD (talk) 16:11, 10 November 2024 (UTC)[reply]
Wiki-policy about Bibliography List in an article about a famous person.
User: Walter Tau and user: Yngvadottir can not agree whether a list of publications about a singer is appropriate in the article about this singer Orville Peck. I placed this list “Bibliography: publications about Orville Peck” after section “Filmography”. She keeps deleting it without citing a specific wiki-policy. Thriley explained the deletion with “This is excessive” again without citing a specific wiki-policy. Can someone explain to us what wiki-policy regulates Bibliographic Lists in an article?— Preceding unsigned comment added by Walter Tau (talk • contribs) 16:06, 11 November 2024 (UTC)[reply]
@Walter Tau: Policies and guidelines define what is allowed in articles, They do not mandate the addition of anything. Whether or not content is due in an article is an editorial decision reflecting the consensus of the interested community. FWIW, I agree that a Bibliography section that large is excessive. Take it to the talk page and gain consensus there for how large a bibliography, if any, to include in the article. (I am ignoring the edit warring that has been going on, but be aware that any future edit warring can lead to sanctions on your editing.) - Donald Albury16:28, 11 November 2024 (UTC)[reply]
Citing a paper in a journal versus citing the journal itself
I wanted to publicize this discussion about the proper interpretation of the WP:NJOURNALS essay. In essence, the issue is whether a journal that publishes frequently cited papers counts as "frequently cited" or if the journal itself has to be frequently cited. Though the essay is just an essay, it is often used in AfD discussions and assumptions about its meaning have been the basis of closing decisions, so there is a material issue here. Botterweg (talk)00:25, 15 November 2024 (UTC)[reply]
This probably isn't something that needs to be advertised here. WT:N would have been a better place. In any event, it appears your question has basically been answered by others. I'm not sure what more there is to add. voorts (talk/contributions) 01:21, 15 November 2024 (UTC)[reply]
Thanks, I'm still learning my way around these behind-the-scenes pages. What I'm looking for is just a clear consensus one way or the other. So nothing fancy, just "I (dis)agree with so-and-so"-type comments. Botterweg (talk)01:51, 15 November 2024 (UTC)[reply]
Protect sockpuppet tags?
Should sockpuppet user pages with tags be protected to extended confirmed only or admin only. This is to prevent removal or modification as the edit filter only prevents users less than 4 days old and have made less than 10 edits. 125.63.140.154 (talk) 00:04, 16 November 2024 (UTC)[reply]
This ArbCom resolution established that "Where there is a global consensus to edit in a certain way, it should be respected and cannot be overruled by a local consensus."
I would like to ask what is the standard for defining that there is global consensus. If the top 100 articles in a certain category all are written in a certain way, is this considered sufficient for global consensus?
If a 100 articles are not enough, what is the threshold? Is it proportional to the number articles in that category?
Should then this warrant that all articles in that category be written in that way (unless very clearly harmful to the specific article)?
I believe that "global consensus" refers to policies and guidelines in particular, and to generally accepted practices across the whole of the English Wikipedia. A consensus that applies to just 100 articles out of the almost 7 million article in the English Wikipedia is a local consensus. Donald Albury16:14, 17 November 2024 (UTC)[reply]
Milo8505, you asked this question in a way that can't be answered. Consensus does not depend on categories, and Wikipedia does not deal in abstract quantities but in concrete articles. Is this about whether to have an infobox on Gustav Mahler? If so then please say so, to provide some context to your question. Phil Bridger (talk) 17:34, 17 November 2024 (UTC)[reply]
@Phil Bridger Yes, it is about that topic. I believe that there is sufficient global consensus about the inclusion of infoboxes on biographies. I am well aware that the official policy is "no policy defined", but I see a clear trend, by looking at the most read articles, that all biographies - of musicians and non musicians alike - have an infobox, except a select few classical music composers.
I do not currently have the whole information regarding exactly how many of all biographies have an infobox, and that is why I was asking what is usually considered consensus.
However, given that I'm very aware that a hundred articles out of seven million is not precisely consensus, I will attempt, when I have the time, to go through every single biography to determine an exact percentage.
If you want to spend your time doing that then I can't stop you, but I warn you that you will be wasting your time. That is not how consensus is measured. Phil Bridger (talk) 19:10, 17 November 2024 (UTC)[reply]
Obviously I will not count by hand, I have some idea of how to use an automated tool to do that.
But then, how is consensus measured?
I'm under the impression that there is a group of very determined and very vocal editors that fiercely oppose infoboxes on classical composers' articles (which leads to most of them having discussions about infoboxes, citing each other as examples of articles without infobox), separate from the majority of biographies, which have an infobox.
I see no better way of proving (or maybe disproving) my point than this, because my earlier points of infoboxes being a great thing for Gustav Mahler's article, and the fact that numerous non-classical musicians have infoboxes, and lengthy ones at that, seem to have fallen on deaf ears.
And I would like to state, for the record, that I'm not doing this out of spite, or out of a personal interest (I'm actually losing my time by arguing about this), but because I truly, wholeheartedly believe that an infobox on each and every biography, and in general, on every article where there could be one (this excludes abstract topics such as existencialism) would make Wikipedia a truly better place.
I would have to search the archives, but we actually held an RFC (one of the ways in which we determine GLOBAL consensus) that was focused on whether to mandate infoboxes on articles about composers… which determined that there were valid reasons not to require them (I suppose you could say that global consensus was to defer to local consensus on this specific issue). Remember WP:Other Stuff Exists is not an accepted argument here at WP. And that “standard practice” often has exceptions. Blueboar (talk) 22:06, 17 November 2024 (UTC)[reply]
I understand, but that is not my sole argument. I have provided other arguments in favor, which you can read at the aforementioned talk page which basically boil down to:
in my opinion,
Infoboxes make standardized information more easily accessible, and
They do not harm the rest of the article, as they do not displace the lead paragraph.
However, in the linked talk page, I see that opponents of infoboxes rely somewhat on the loosely established precedent/consensus that composers shouldn't have infoboxes.
That is why I wanted to bring forth a new argument, using the, as I see it, very established consensus for infoboxes in biographies, and what I want to know here is whether this consensus can be proven to exist (or what is it required for this consensus to exist). Milo8505(talk)07:30, 18 November 2024 (UTC)[reply]
This whole thing about "global" and "local" consensus seems to confuse everyone, and consequently folks make up whatever seems plausible to them. Let me give you a potted history and the usual claims, and perhaps that will help you understand the principle.
'Way back in the day, infoboxes didn't exist. AIUI the first widely used infobox template was {{taxobox}} in 2004, and the general concept appeared soon after. However, through the end of 2007, Template:Infobox didn't look like what we're used to. Originally, an 'infobox template' was literally a wikitext table that you could copy and fill in however you wanted.[1]
While infoboxes were being developed, the editors at Wikipedia:WikiProject Composers decided that infoboxes were a bad idea specifically for articles about classical composers, so after a series of disputes and discussions, in April 2007 they wrote a note that said, basically, "BTW, the sitewide rules don't apply to the articles we WP:OWN."[2]
The conflict between this group and the rest of the community eventually resulted in the 2010 Wikipedia talk:WikiProject Composers/Infoboxes RfC. The result of this years-long dispute is memorialized in the example given in what is now the Wikipedia:Consensus#Levels of consensus section of the policy: "Consensus among a limited group of editors, at one place and time, cannot override community consensus on a wider scale. For instance, unless they can convince the broader community that such action is right, participants in a WikiProject cannot decide that some generally accepted policy or guideline does not apply to articles within its scope."
Or, to be rather more pointy-headed about it: WikiProject Composers doesn't get to decide that "their" articles are exempt from MOS:INFOBOXUSE.
What was then a statement about the "Purpose of consensus" or, before then, one of several "Exceptions" to forming a consensus on a talk page has since been renamed ==Levels of consensus==. Also, ArbCom (and consequently part of the community) has started talking about "global" consensus. I think that has confused people about the point.
"Levels" of consensus could mean the strength of the consensus ("This is just a weak consensus, so..."). It could mean something about the process used ("My CENT-listed RFC trumps your Village pump post"). It could mean whether the consensus applies to the whole site ("We formed a consensus at Talk:Article about the first sentence of Article, so now I need to make 500 other articles match this one"). And it could tell us something about how likely it is that the decision matches the overall view of the community.
It's supposed to be that last one. We don't want a handful of people getting together on some page and saying "Let's reject this rule. This article needs to be censored. Copyvio restrictions are inconvenient. Bold-face text helps people see the important points. And we know this POV is correct, so it should dominate." We want quite the opposite: "The community says that this is usually the best thing, so let's do this."
AFAICT, the overall view of The Community™ is that we think that there should not be any Official™ Rule saying that any subset of articles should have an infobox. We're probably doing this mostly for social reasons, rather than article reasons. For example, every single article about a US President, or atomic elements, or any number of other subjects, has an infobox – but we refuse to write any rule saying they should, or even that they usually should, even though we know the popularity is ever-increasing. For example, at the moment, Georgina Sutton is the only biography linked on the Main Page that doesn't have an infobox.
I suspect that the closest we will come to such a rule during the next few years is a note about how popular they are. It should be possible to see how many articles (overall, or in particular subsets) already use infoboxes, and to add that information to MOS:INFOBOXUSE. For now, we could add a statement that "most" articles have an infobox.
^Being able to do this in wikitext was was considered an improvement, because originally, you had to code tables in raw HTML.
^This was not as unreasonable back then as it sounds now. WikiProjects were a significant source of subject-specific advice back then, and the rule-making systems were quite informal. WP:PROPOSAL didn't exist until late 2008. Before then, most guidelines and even policies acquired their labels merely because someone decided to slap the tag on it, and if nobody objected, then that was the consensus for what to call it.
From what you have said, given that WikiProject composers have to follow MOS:INFOBOXUSE, there should be a discussion on each and every composer's talk page to determine whether an infobox is warranted.
I see this as a bit of a, difficult and fruitless endeavor, as the arguments presented, for either case, are always the same, and they all usually result in stalemates (like the one about Mahler).
What I propose is to change the policy, to, at least, recommend infoboxes on certain categories, given that, as you said, they are very popular. Or at the very least, as you suggest, acknowledge the fact that they are very popular.
When I have time to gather more data on the use of infoboxes, I will propose a new RfC to try to commit this change to the policy.
I am very well aware that my chances of success are slim, but, I'll do what I can do.
Well, if "they all usually result in stalemates", then that represents a change, because the last complaint I saw about this subject said that the RFCs on whether to add an infobox almost always resulted in an infobox being added. Perhaps it varies by subject, however.
Acknowledging that they're popular shouldn't require a proposal for a change. It should only require getting some decent numbers. Check the archives of WP:RAQ; they probably can't query it directly, but if there's been a request, you'll see what could be done. It might also be possible to create a hidden category for "All articles with infoboxes", automagically transcluded, to get a count on the number of infoboxes. WhatamIdoing (talk) 06:45, 20 November 2024 (UTC)[reply]
First of all, thank you again very much for your continued interest.
The discussions around infoboxes (not RfCs, discussions on talk pages) as far as I have seen usually go something like:
- I propose adding an infobox
+ We have talked a lot about that and there are good reasonstm for which it should not be added
- But I also have good reasonstm for which it should be added.
(no comments for 4 years, then it begins again).
I thought a bit about counting links, and I realized maybe getting this data is easier than I thought, see:
For counting the number of transclusions to a given page, this tool is very useful, and says that there are around 3.2 million infoboxes in total, and 460 thousand infoboxes about people. (on the (Article) namespace).
This seems to suggest that only around a quarter of all biographies have an infobox? Maybe I was wrong all along in my observation that infoboxes are very popular.
I am however not too sure that the two million links to Template:Wikiproject Biography on the Talk namespace actually corresponds to two million unique biographies.
Maybe another way of getting this data would be better, I'll have to look at it on some other occasion that I have more time.
An article was deleted, but it seems that it was incorrectly deleted. It was based on a composer and notability was questioned in an earlier version of the article. However, I was able to re-write a new version of the previously deleted article with the song the person composed that is clearly notable. The song has its own article here on Wikipedia. The article was about William Lawrence Hansen. Starlighsky (talk) 01:28, 18 November 2024 (UTC)[reply]
If you'd like a copy of it, ask an admin to put a WP:REFUND copy into your personal sandbox first (i.e., User:Starlighsky/sandbox). Once you think you've got it in good shape, I'd suggest first asking at a relevant WikiProject to see if you can get an extra set of eyes on it.
One thing you should know… writing a notable song does not automatically mean the song writer/composer will be considered notable. It certainly helps, but what you really need to find are a few sources that discuss this composer in some depth. Hope you find them. Blueboar (talk) 02:25, 18 November 2024 (UTC)[reply]
If preparation for the event is not already in progress, speculation about it must be well documented. Examples of appropriate topics include the [[{{#expr: {{CURRENTYEAR}} + 4 + ({{CURRENTYEAR}} * -1)mod4 }} United States presidential election|{{#expr: {{CURRENTYEAR}} + 4 + ({{CURRENTYEAR}} * -1)mod4 }} U.S. presidential election]] and [[{{#expr: {{CURRENTYEAR}} + (2*4) - ({{CURRENTYEAR}}mod4)}} Summer Olympics]]. By comparison, the [[{{#expr: {{CURRENTYEAR}} + (5*4) + ({{CURRENTYEAR}} * -1)mod4 }} United States presidential election|{{#expr: {{CURRENTYEAR}} + (5*4) + ({{CURRENTYEAR}} * -1)mod4 }} U.S. presidential election]] and [[{{#expr: {{CURRENTYEAR}} + (6*4) - ({{CURRENTYEAR}}mod4)}} Summer Olympics]] are not appropriate article topics if nothing can be said about them that is verifiable and not original research.
According to this, the 2028 election and 2032 Olympics automatically became valid articles on January 1, 2024, although it is not really clear why that exact date matters. Should this be clarified, and if so, how? ypn^219:44, 18 November 2024 (UTC)[reply]
The relevant question IMO is why do we need an article on the 2028 or 2032 presidential elections? Any "significant coverage" is just speculation at this point. Until candidates declare, I don't see how articles on either is useful to readers. voorts (talk/contributions) 19:53, 18 November 2024 (UTC)[reply]
Encyclopaedic coverage of predictions and speculation about and preparations for the 2028 presidential election that appear in reliable sources is possible and (in at least some cases) due. Similarly things like whether (and if so what) changes to electoral collage allocations will happen, etc should also be easily found by someone searching. Whether that should be on its own article yet or as part of a broader article will depend entirely on the volume of encyclopaedic material there is. Similarly for the Olympics. As soon as we have coverage about the next and next+1 US presidential elections and Olympic games there should be blue links from the titles those articles will reside at when they have articles (e.g. 2036 Summer Olympics was kept at AfD (although moved to Bids for the 2036 Summer Olympics) in November 2022 due to there being significant sourcing about the preparations). I don't think the dates in WP:CRYSTAL should be taken as "there must be an article" but as loose guidelines along the lines of "significantly before this time sufficient information to justify a standalone article is unlikely; it is unlikely there will not be sufficient information for a standalone article significantly after this time." i.e. those dates are the approximate midpoint in the range when sufficient information for a standlone article existing changes from very unlikely to very likely. Thryduulf (talk) 20:36, 18 November 2024 (UTC)[reply]
Right now only "recall" votes count, and those opposing recall don't count for anything, nor do any points made in the discussion. So 25 quick group-think / mob thumbs-down votes and even be best admmin can get booted. And the best (= the most active) are the ones most likely to get booted. An admin that does near zero will get zero votes to recall. And with a single regular RFA currently the only way back in (which we've seen, very few want to go through) "booted" is "booted". The fix would be to have a discussion period pror to voting, with both "recall" and "don't recall" choices. And then say that the recall has occurred (thus requiring rfa) if over 50% or 60% of those voting said "recall".
Thanks. I looked for something like that but I guess I didn't look hard enough. I hope others look harder than me. :-) North8000 (talk) 21:58, 19 November 2024 (UTC)[reply]
I don't think you understand how recall works. An admin is only desysopped after the RRFA, not after the 25 signatures, unless they choose to resign on their own. You're asking to hold a vote on whether or not a vote should be held. ~~ Jessintime (talk) 20:55, 19 November 2024 (UTC)[reply]
Yes, I understood that and that is integrated into my comment above. Unless they go through and succeed at an RFA they are gone. North8000 (talk) 21:54, 19 November 2024 (UTC)[reply]
I've never heard of a petition that lets people sign because they don't support it. And I'll add that between the two recall petitions that were enacted to this point, both were preceded by many, many attempts to get the admin to correct course over the years despite egregious misconduct. Thebiguglyalien (talk) 21:03, 19 November 2024 (UTC)[reply]
The process at the moment does have a certain level of redundancy, with the recall and reconfirmation RFA being separate things. The reconfirmation RFA is even a standard RFA, as it has different criteria for success.
I'm not sure if anything should be done yet, as it's still very early in its adoption. However if the situation occurs that a petition is successful but the reconfirmation RFA SNOWs, it could indicate that adjustments needs to be made so that community time isn't wasted. That speculative at the moment though. -- LCU ActivelyDisinterested«@» °∆t°23:53, 19 November 2024 (UTC)[reply]
The recall petition threshold is not the recall discussion - it is just a check to prevent the most frivolous recall discussions from being held. — xaosfluxTalk00:56, 20 November 2024 (UTC)[reply]
The optics of this look alltogether terrible from my observation. I don't edit much, but I like reading a lot. Every criticism of the recall process i've seen so far just looks like old established admins thinking they might be next and having anxiety about that.
The problem of something like this is that the optics are terrible. If anyone who doesn't know you reads that, the conclusion they will draw will likely not be "this recall process is terrible" and more likely go along the lines of "wow this is a lot of admins who don't have the community's trust anymore and want to dodge accountability".
By being so vocally against any form of community led accountability, you're strenghtening the case for easy recalls and low thresholds, not weakening it.
Specifically regarding Fastily, I'll make no comment on whether or not he deserves to still be an admin or not, I don't know him well enough for that and haven't reviewed enough of his contributions, but the arguments of "ANI agreed that no sanctions were appropriate" sound a lot like "our police department has investigated itself and found nothing was wrong". You have to see how this comes across, it's eroding trust in Admins on the whole project right now. Magischtalk to me09:24, 20 November 2024 (UTC)[reply]
Specifically, if RFA is so toxic that nobody wants to do it, that needs to be reformed. But the recent amount of vitriol towards a process that only kickstarts having to prove that you retain community trust has me convinced that there should be automatic mandatory RRFAs for every admin every 2 years or so.
If, as of today, you don't believe the community would entrust you with admin tools, why do you think you should still have them? The criteria for losing them should not be "has clearly abused them", it should be "wouldn't be trusted with them if asked today". Magischtalk to me09:33, 20 November 2024 (UTC)[reply]
As an admin actively working to improve the recall process, my goal is to make it as fair as possible to all parties. That means it should not be possible to subject an admin to the process frivolously while equally making it possible to recall administrators who have lost the trust of the community, and it needs to be as non-toxic as possible, because even administrators who are actively abusing their tools are people and nobody deserves 1-2 months of abuse. It's also incorrect to describe ANI as a police department investigating itself - everybody engaging in good faith is welcome to comment there, regardless of whether they are an admin or not. Thryduulf (talk) 11:15, 20 November 2024 (UTC)[reply]
@Thryduulf It's the Administrator's Noticeboard, naturally the vast majority of participants will be either admins or people who are involved in the same work.
I don't think asking an admin to confirm they still retain the trust of the community (the whole basis of giving out admin tools to begin with) is ever really frivolous. The current process allows that at most once a year. If an admin had to stand for RFA every year, that might be a bit too much long term, but really, if any admin thinks they would not pass RRFA today, why should they retain their tools.
Also, the sheer optics of it being mostly (from what i've seen) established admins calling this process toxic are terrible. Anyone who doesn't know anything about this process will see this as some kind of thin blue line mentality in the admin corps - and might conclude that it is time to desysop the majority of old admins to dissolve the clique.
I took the stats from the first RRfA to test this theory:
1st RRfA votes
Support
Oppose
Total
Administrators
48
29
77
Non-admins
71
116
187
Total
119
145
264
Administrators made up 29% of the voters. If being an admin doesn't influence anyone's vote, then we can expect admins to make up roughly 29% of the supporters and 29% of the opposers. But this didn't happen. In the final results, administrators made up 40% of the supporters and 20% of the opposers. We can also look at the individual odds of supporting/opposing depending on user rights. It ended at 45% support, so you'd expect admins to have a 45% chance of supporting and a 55% chance of opposing. But this also didn't happen. If you choose any admin at random, they had a 62% chance of supporting and a 38% chance of opposing (ignoring neutrals). Non-admins were the opposite: they had a 38% chance of supporting and a 62% chance of opposing.
So our next question should be why it was so much more likely for an admin to support the RRfA relative to a non-admin. The obvious answer is of course as you said: admins have a perverse incentive to support here, especially if they're not-so-great admins who know they probably don't have the trust of the community anymore. Also suggested during the RRfA is the comradery that comes from working alongside a fellow admin for so long. I'd be interested in seeing how account age affects likelihood of supporting, but that's not something that can be counted up in a few minutes like admin status. Thebiguglyalien (talk) 17:48, 20 November 2024 (UTC)[reply]
I believe it may be centered on the idea that we all make mistakes, and many of us like to think we'd be given a chance to grow and learn from said mistake, instead of being forced through the RfA process again. But I recognize I may be being overly optimistic on that, and that others may not have the same thoughts on the matter that I do. Many admins I've spoken to would simply choose to give up their tools as opposed to go through an RfA again, something I've also considered despite my relatively smooth RfA. I'm also not sure Graham is the best representation of that. I voted support, recognizing that Graham87 has made mistakes, but also recognizing the significant contributions they've made and their pledge to do better. Bluntly, I did so expecting the vote to fail, and wanting to show some moral support and appreciation for their work. There's certainly a psychological aspect involved in it, but I don't think that, generally speaking, those of us who voted support or have issues with the current process are doing so out of self preservation.
There's a lot of numbers that could be analyzed, such as the history of those admins who vote at RfA (whether they often vote support or don't vote at all), but it's hard to draw meaningful conclusions from this small of a dataset. Hey man im josh (talk) 19:14, 20 November 2024 (UTC)[reply]
On paper, I get that. The thing is, I don't know whether you saw Levivich's comment or bradv's comment, but you'd be hard-pressed to find a less appropriate time to test the "chance to grow" theory than the absolutely deplorable behavior that we saw from Graham for many years with far too many chances to improve. If it were down to me, this should have been a block in 2023 rather than a desysop in 2024. Thebiguglyalien (talk) 19:32, 20 November 2024 (UTC)[reply]
Well, I'm not an admin and I started this thread. I'm all for having an admin recall process by the community in place. I'm also also for a process for course correction by the community in areas where and admin has drifted off course but where the problem is fixable. Administrative Action Review has the potential to become this but that has been stymied by various things. Sincerely, North8000 (talk) 14:24, 20 November 2024 (UTC)[reply]
I think, fundamentally, the problem is that admins have a direct and concrete conflict of interest in this discussion. Of course an admin would be naturally opposed to more mechanisms that might make them lose their permissions, especially since desysops are very rare at the moment.
I also don't really agree that the current recall process is all that toxic. You could get rid of the discussion section, as the recall is only a petition, not a consensus discussion, but that's about it. Magischtalk to me18:33, 20 November 2024 (UTC)[reply]
Of course an admin would be naturally opposed to more mechanisms that might make them lose their permissions – I wholeheartedly disagree with this assertion. There's a number of us that fully support a recall process, including quite a few people who have historically been open to recalls. This is an over simplification of the motives of a large group of experienced editors, many of which have legitimate and reasonable concerns about the process in its current form. Hey man im josh (talk) 19:15, 20 November 2024 (UTC)[reply]
Substantially all criticism i've seen so far of the process have boiled down to "RFA is abusive and it's unreasonable to make people go through that again". And yet, instead of attempting to change that, the only suggestions seem to be to support older admin's rights to have their permissions continue being grandfathered in. Magischtalk to me19:27, 20 November 2024 (UTC)[reply]
I'm sorry that that's all you've taken away from the vast amounts of criticism given by people. Perhaps consider focusing on whether the process, in its current state, makes sense instead of focusing on older admins. I'm a relatively new admin and I don't support the current iteration of the process. Hey man im josh (talk) 19:30, 20 November 2024 (UTC)[reply]
I think it's eminently sensible to have adminship not be a lifetime appointment, both by the fact that norms change even when people dont, and that I see people in every RFA expressing reluctance over granting lifetime tools. I also think that assuming RFA isn't a big deal regular reconfirmations make sense. IFF RFA is a big deal, then the focus should be on fixing that.
It seems to me that existing admins being immune to having to suffer RFA again has created a lack of pressure to actually make it into a functional, nontoxic process.
Attempting to improve RFA is a very hard problem that people have been working on since before you joined Wikipedia, and are still working on it. I would also say that it is unreasonable to make people go through that again is a mischaracterisation of the views expressed, which are it is unreasonable to make people go through that again unnecessarily, which is significantly different. Thryduulf (talk) 19:31, 20 November 2024 (UTC)[reply]
I just found out about this discussion, and it looks to me like the same or similar things are being discussed in way too many different places. Anyway, I'm someone who has stated repeatedly and strongly in multiple places that I think the recall process is a disaster, and is beyond repair. And, contra some statements above, here are some other facts about me. I'm not an admin. I opposed Graham's re-RfA. And I played a central role in WP:CDARFC. --Tryptofish (talk) 20:12, 20 November 2024 (UTC)[reply]
I would be against it for a different reason: if we allow both supports and opposes, then the recall petition becomes a mini-RfA with the same amount of pressure as the RRfA itself (especially since, given the identical threshold, the recall's result would be indicative of the RRfA's subsequent result). Since anyone can start the recall petition, it functionally means that anyone can force an admin to re-RfA, which is clearly worse. On the other hand, having a set number of supports needed provides for a "thresholding" of who can open a RRfA, while not necessarily being as stressful. If anything, I would say the recall should become more petition-like (and thus less stressful for the recalled admin), rather than more RfA-like. Chaotic Enby (talk · contribs) 20:01, 20 November 2024 (UTC)[reply]
The ones most likely to be booted are bad admins who are abusive toward the editor community and who negatively represent themselves as admins. Both of the recalls thus far were just exact examples of that and worked perfectly as designed and needed. The process worked exactly as desired and removed bad admins who deserved to be desysopped. Though I do think the discussion section of the petitions should be more regulated. Discussion should be about the admin's actions and conduct and nothing else. Any extraneous commentary should be removed. SilverserenC00:23, 21 November 2024 (UTC)[reply]
When I first started editing Wikipedia almost 20 years ago, I was struck by what, to me at least, appeared to be widespread incivility. Among a number of things which have changed for the better IMHO is an all round expectation that everyone's standards of behaviour should rise (and they have). The admin role breeds a certain "culture" (for lack of a better term) akin to a conservationist, the role is to "protect" Wikipedia from "harm" and I can certainly see why being an admin could be a deeply frustrating experience. However, what has happened, I think, in the attrition of the admin corps, and the turnover in the non-admin corps, is that the generalised culture of "regular" non-admin editors has moved further forward towards less acceptance of a culture prevalent 10-15 years ago. I think also the rise in editors from non-English speaking backgrounds and from the Global South has caused complexities for those with limited experience outside the anglosphere. The statistics above on the vote for G87's RRFA show an interesting split between admins and non-admins, and within admins. Non-admins were almost overwhelmingly (close to 2/3) of the view that G87 had been given an almost exceptionaly long period to improve, had not, and no longer held their trust. 5/8s of admins, appeared (and comments here also seem to confirm this) split between solidarity for one of their own and displeasure with the recall process. 3/8s admins were in alignment with the majority of non-admins. FWIW, I'm not trying to point to some grand schism; A 38/62 admin split on these numbers is not that profound - if just 9 admins had changed their vote from support to oppose it would have been a 50/50 split. To reiterate, I'm not suggesting that there is a great gap between admins and non-admins, but there does appear to be some gap when it comes to generalised views around the expected behaviour of admins. Regards, Goldsztajn (talk) 01:01, 21 November 2024 (UTC)[reply]
I don't disagree, and in effect I was sort of saying the same thing in terms of the attrition of the admin corps and turnover in non-admin corps. FWIW, I do think there are some generalised feelings about admins among non-admins; for example, admins are less likely to face sanction than non-admins. How true that actually is I'm not sure and the point would be that a group of people already tested in commnuity trust (ie RFA) are less likely to breach that trust. However, comments in the G87 RRFA and the strength of the vote suggest there are (wrongly or rightly) widely felt perceptions of disparity. Regards, Goldsztajn (talk) 01:53, 21 November 2024 (UTC)[reply]
I'm currently compiling the data to get some statistics about voters in Graham's re-RFA. I'm a bit less than halfway through so it might be a couple of days before I can present any results. However among the first 113 support voters the maximum account age (on the day the re-RFA started) was 7919 days (21 years), the minimum was 212 days and the average was 4785 days (13 years). I have no data yet for neutral or oppose voters so cannot say how that compares. Thryduulf (talk) 02:03, 21 November 2024 (UTC)[reply]
Do you have a handy list of all voters for RFA? It should be simple enough to use a WP:QUARRY to find out all details about the voters if someone finds an easy enough scrape of who each user is Soni (talk) 05:51, 21 November 2024 (UTC)[reply]
I think about 6 editors were missed by the tool you linked, but it should not change overall patterns much so we can just use this as is. Soni (talk) 07:24, 21 November 2024 (UTC)[reply]
At a quick glance, it seemed like editors with more edits were more likely to support while editors with fewer edits (with one exception) were more likely to oppose. - Enos733 (talk) 07:54, 21 November 2024 (UTC)[reply]
the REGIME test
That any news outlet or source that refers to a government as a "regime" be considered not reliable for facts about that regime, except for attributed statements.
This would, for example, rule out using a significant proportion of reliable sources covering contemporary North Korea, Afghanistan, Cuba and Iran as well as countless historical governments (e.g. Saddam Hussein's Iraq, Franco's Spain, Gaddafi's Libya, etc). This is clearly hasn't been fully thought through. Thryduulf (talk) 04:17, 20 November 2024 (UTC)[reply]
I think this does get at something which is a problem in Wikipedia. It just doesn't quite hit the mark. And that is that there is a core assumption in Wikipedia's handling of news media sources that they are largely independent and that a deviation from editorial independence represents a deviation from best practices. However this often leads to Wikipedia simply assuming the biases of the New York Times and other major media outlets. But there has been an accumulation of multitudinous issues - one of the most recent being accounts of Jeff Bezos influencing the Washington Post to withhold an endorsement of Kamala Harris - that demonstrate that the idea of editorial independence is frankly quaint.
This, of course, then creates problems with adjudicating those sources that have previously been demonstrated to be non-independent (see for example WP:XINHUA) as the rationale on Wikipedia for treating Xinhua differently from, let's say, the BBC or Al Jazeera for that matter largely depends upon the assumption of independence of those outlets that are not aligned with enemy states of the US/UK hegemony.
My personal opinion is that the use of news sources on an encyclopedia should be far more limited than it presently is as, in my case, it's not that I trust Xinhua (I don't) but that I don't trust any media outlet to produce material appropriate for a neutral encyclopedia. I don't think a "regime" test is going to improve the quality of pages that over-rely on news media. But I would suggest that it's another indication that Wikipedia needs to be far more critical of what news sources we depend on and in what contexts. Simonm223 (talk) 19:54, 20 November 2024 (UTC)[reply]
No, editorial independence is not the reason for a source being considered reliable or not. Many sources are biased, or influenced by specific governments/interest groups, and are still considered reliable for topics other than the groups influencing them (in which case, by definition, they would not be an independent source). A history of disinformation (actually making up stuff, not just reporting it in a biased way) pushes the source towards being considered unreliable.WP:XINHUA, which you link, demonstrates this clearly, stating There is consensus that Xinhua is generally reliable for factual reporting except in areas where the government of China may have a reason to use it for propaganda or disinformation. In the same way, we shouldn't rely on the Washington Post for topics related to Jeff Bezos. Chaotic Enby (talk · contribs) 20:07, 20 November 2024 (UTC)[reply]
The example I gave wasn't one of a story about Jeff Bezos or a topic related to Jeff Bezos unless one contends (which, I will grant there's a case to be made) that anything to do with a US election is ultimately about the interests of the Billionaire class. But, you see, that's my point. Pretty much any media outlet will distort truth, spread disinformation or, at the most basic, bury stories that aren't to the interests of their handlers. And I do want to stress that the stories that are not covered is a key method through which media occludes truth. The only real question is whether the handler is a politbureau or a rich guy. I don't think one of those is better than the other. Simonm223 (talk) 20:12, 20 November 2024 (UTC)[reply]
The fact that a news media is influenced to not publish a story makes it biased, but not unreliable. Having a point of view when reporting (or choosing not to report) stories is what every media does, and is different from outright making up disinformation. And that is the difference between bias and unreliability. It's not about who the handler is, rich guys can also own unreliable news sources. Chaotic Enby (talk · contribs) 20:16, 20 November 2024 (UTC)[reply]
I mean we certainly agree about that rich guy. I just think Wikipedia is too fast to treat news sources as reliable out of convenience rather than any real confidence in the quality of information. Simonm223 (talk) 20:20, 20 November 2024 (UTC)[reply]
I agree with Simonm223. I just can't understand why an encyclopedia should be largely based on news sources rather than peer-reviewed academic articles or books. For a start most of them are primary sources, by any definition other than Wikipedia's. This is dumbing-down at its worst. Phil Bridger (talk) 21:09, 20 November 2024 (UTC)[reply]
See the definition (specifically 2(c) and 2(d)). Regime is a synonym for "administration" or "government" (when used to describe, as example, the Biden administration or the Tory government). It makes zero sense whatsoever to block sources who use a synonym for administration just because one person feels it has negative connotations. Wikipedia is not the place to practice redefining words or limiting their use based on their worst definitions or connotations. -bɜ:ʳkənhɪmez | me | talk to me!05:03, 21 November 2024 (UTC)[reply]
Prescriptivism is dead. See examples. There is zero percent usage in modern times that isn't derogatory; literally no one says unironically "our regime", "the regimes of our allies", or "regimes we'd like to do business with". Skullers (talk) 08:29, 21 November 2024 (UTC)[reply]
Technical
question about partial blocking and page creation
There's a discussion at ANI right now that is heading in the direction of banning a user from creating new articles, a sub-proposal has emerged to allow them to use WP:AFC instead. My question would be this: if you check the "Creating new pages and uploading new files" is that sitewide or will it only apply to the namespace selected for the partial block? Or would we have to just consider it an traditional topic ban with no technical implementation? Just Step Sidewaysfrom this world ..... today22:22, 10 November 2024 (UTC)[reply]
@Novem Linguae will trout me for suggesting this: Edit Filter to stop that editor from creating new articles in the mainspace. (But no, don't please. If the editor has no self-control after the consensus to topic ban them, they might just earn a ticket to being blocked.) – robertsky (talk) 14:11, 13 November 2024 (UTC)[reply]
Edit filters are expensive in terms of performance when submitting an edit, and of maintaining them, so should not typically be written to stop a single user from doing something. So yes, probably better to have the user just exercise some self-control :) –Novem Linguae (talk) 14:15, 13 November 2024 (UTC)[reply]
+3, though I have no idea which user you're referring to (I don't frequent AN/ANI). Presumably the solution to this is just to tell the user to stop creating articles in mainspace, enforced via a block of sitewide page creation if they continue in spite of a ban. A bit more than the ban would be covered, but it would undoubtedly enforce the ban. EggRoll97(talk) 01:44, 15 November 2024 (UTC)[reply]
The page looks great to me in dark mode (Brave browser on Mac OS). Can you give a specific example of one part of the article that does not display as expected? What part of the article, what is it doing, and what were you hoping it would do? – Jonesey95 (talk) 20:29, 12 November 2024 (UTC)[reply]
Actually, it occurred to me earlier (when I was already too late to work to type it out) that since most of these storm insensity colours are realised as bgcolor="#{{storm colour|value}}", someone could modify {{Storm colour}} to output after the hex string retrieved from Module:Storm categories/categories" class="mw-no-invert. Of course, this is bad design, and will probably break (or at least upset the linter about) some subset of transclusions called without enclosing quotes, or which already contain a |class= parameter in the table cell style. Should alter all the articles in one go, though. Folly Mox (talk) 17:16, 14 November 2024 (UTC)[reply]
Way to enforce a ban from article creation using the software?
Looking at this ANI case, I wonder if there is a way to enforce a ban from creating pages from the software, as if the user under sanction had lost their autoconfirmation (but without losing the ability to edit semi-protected pages). This could also be extended to other namespaces, such as the Draft: or User: namespace if necessary. FMecha (to talk|to see log) 18:22, 14 November 2024 (UTC)[reply]
It is technically possible to partial block from creating any type of page. It is technically possible to partial block from editing the entire article namespace. Anything else could be done only using an edit filter, which is generally not done in this situation. Restrictions that are so simple a computer could (even in theory) enforce them are rare - the community tends to rely on topic bans which are inherently subjective in nature, so I don't think it's worth spending time coding up any new MediaWiki features to implement this. * Pppery *it has begun...18:27, 14 November 2024 (UTC)[reply]
Creating a new set of templates for STV elections
Hi folks. I am currently trying to put together a new set of templates for STV elections.
The templates would be primarily intended for use in Northern Ireland elections, where there are three blocs (unionist, nationalist and 'other'), but they could be adapted to other contexts.
By way of illustration, here is the 2022 Assembly election result for the West Tyrone constituency, as it appears on Wikipedia currently.
Note that I would also want party colour and bloc colour to display in the 'Results by party', 'Results by bloc', and summary pane at the bottom-right also, and I'd probably prefer that the abbreviations for each party display, rather than each party's short name (I've free-typed the abbreviations in the middle panel, but the actual abbreviations differ).
Note the following additions:
Each candidate and party would have its bloc listed (unionist, nationalist or 'other'). There would also be an 'unclassified' option (denoted by an X), intended for obscure independents whose alignment cannot be determined through any sources.
Total first preference vote count and vote share, and change thereof from the last election, would be shown for each party and each bloc, rather than only explicitly showing vote count/vote share for each individual candidate.
'Party majority' and 'bloc majority' would show the margin between the largest party/bloc in the constituency.
'Swing' between the two largest parties, and also between the two largest blocs, is also shown.
The panels note the largest party and largest bloc, and whether they have a plurality or a majority, respectively.
A summary of electors, turnout, valid votes, etc is shown, with full percentage breakdowns and numerical/percentage change between that election and the previous one.
A summary results panel at the bottom right would indicate whether there have been any changes in seats between parties/blocs, and change in the elected MLAs within each party compared to the previous election.
So far, I've made the templates for the leftmost panel, but not for any of the other panels yet.
To be clear, I'd like to be able to put something together using Lua/the templates, which takes the first preference vote counts from the leftmost table, sums these for each party (and also for independents of each bloc - I do not want independents of different blocs summed collectively), and automatically outputs total vote count and vote share for each party, and also for each bloc, on the relevant panels.
It'd also be cool if the candidate first preference votes can be summed to produce the valid vote, and if the numerical input for electors, turnout, spoilt votes, valid votes etc could be automatically displayed as percentages of the electors figure, and if the quota can automatically be calculated based on the number of seats and valid vote.
I'd appreciate any guidance on this, and any constructive feedback on proposed design - I've done the best I can based on what I know but there may be a way to make it look better. Many thanks! PointUnderstander (talk) 18:59, 14 November 2024 (UTC)[reply]
Change the table around the tables "2022 Assembly election – West Tyrone: 5 seats", "Results by party" and "Results by bloc" to use a div. That way, mobile can throw the tables down the page, whereas there is not available width on mobile for all three. Snævar (talk) 23:56, 14 November 2024 (UTC)[reply]
Many of these questions about how it looks, what columns should be kept, if new ones should be added is more of a question for Wikipedia talk:WikiProject Elections and Referendums. This forum is more for how to achive this layout. There is one or more templates that sum up numbers, I am not keeping enough track of them to know which ones. Snævar (talk) 10:49, 16 November 2024 (UTC)[reply]
There are some issues with the templates in the header of the page. No clear idea of what the issues could be, but some templates don't seem to exist, or some parameters are wrong.
I'm going to ping @Trappist the monk here to double check, but I am pretty sure the issue is that the parameter was never supported. I don't really understand how it wasn't caught before today, which is perhaps the more interesting question I would have. Izno (talk) 21:17, 14 November 2024 (UTC)[reply]
|translit-standard= is not a supported parameter; use |translit-std=. Not caught before today because only today did I update Module:Lang to catch these kinds of unknown parameters.
I've recently tried to search a few things, and noticed that if I press arrow down on the autocomplete results, it selects a random result, rather than the expected outcome of it selecting the first in the list (then going down one if pressed again, etcetera). For example, to test this, I typed in "AS" into the search bar, which displayed "AS", "Association football", "Associated Press", "Assassination of John F. Kennedy", among others. I pressed the arrow down, and it highlighted the last result, "ASEAN". I pressed it again, and it highlighted "Asperger syndrome", which is the 6th result in the list, and 4 results up from "ASEAN". This continues for some time, but it generally jumps through the list at random intervals. I checked that I had safemode on before trying this, and I am on the latest version of 64-bit Chrome, version 131.0.6778.70. EggRoll97(talk) 01:11, 15 November 2024 (UTC)[reply]
Me too, Windows 10 version 22H2, Firefox 132.0.2 (recent upgrade), all skins except Vector-2022 and Minerva Neue, logged in and logged out. The main symptom seems to be that in the search box, the functions of the up and down arrows are exchanged. Also affects commons:. --Redrose64 🌹 (talk) 01:22, 15 November 2024 (UTC)[reply]
I'm facing the same issue, on Vivaldi (7.0.3495.11 (64-bit)) on Windows 11 Home 23H2. Are you on Wikipedia's 2010 Vector legacy skin (the old default GUI) by any chance? I have this issue on that skin but not on Wikipedia's new Vector skin. Tube·of·Light11:21, 15 November 2024 (UTC)[reply]
The {{Text diff}} template is causing some Linter misnested tag errors that do not appear to be fixable locally in pages. This is not a new problem, but we have fixed most of the high-priority fixable Linter problems and are trying to clean up the last few stubborn cases. I am looking for people with Lua knowledge to help over at Template talk:Text diff#Lint errors. Any clues will be appreciated. Thanks in advance. – Jonesey95 (talk) 01:57, 15 November 2024 (UTC)[reply]
Radware sells anti DDoS software, I would guess that these editors were using an automated tool to fill in citations (i.e. the automatic citation tool in visual editor), which Radware's software detected as bot traffic and blocked. 86.23.109.101 (talk) 17:53, 15 November 2024 (UTC)[reply]
Pages with reference errors that trigger visual diffs
There's a redlinked category, Category:Pages with reference errors that trigger visual diffs, suddenly appearing out of nowhere on over 2,000 pages and growing — I came across it with an unrelated edit to another page which didn't have that on it when I started to edit the page, but suddenly did have that on it as soon as I saved my edit, and attempting to "expand templates" on the page failed to identify where it was coming from.
The last time something like this happened, a couple of weeks ago, it was an utterly unhelpful and unwanted Category:Pages using the JsonConfig extension that got created and then speedy-deleted within days as unhelpful and unwanted.
But, of course, pages can't be left sitting in redlinked categories, so this has to either get created or go away. So could somebody look into this, and either create the category right away if it's actually desired or figure out how to make it go away if it isn't? Thanks. Bearcat (talk) 21:53, 15 November 2024 (UTC)[reply]
Fished out one page, Brisbane Airport, which has a group reference without a reference list. I suspect that will be a majority of the cases. In the current parser, that note appears not to render in any list, instead an error renders at the bottom of the page. In Parsoid, both it and the error render at the bottom. Izno (talk) 22:28, 15 November 2024 (UTC)[reply]
But here's what happened (all these diffs are sequentially uninterrupted BTW): while WP:HD was under PC protection (LTA disruption), T=00 I reply to a thread. T+02 minutes, PrimeHunterreplies. T+17 minutes, OP replies to my reply, removing PrimeHunter's reply with no edit summary (edit tagged as "2017 wikitext editor"). A bit later, I notice this and enter the source editor within Minerva to restore PrimeHunter's edit without automatically adding my sig. T+44 PrimeHunter restores the edit. T+46 I do too. Despite the edit summary of my immediate self-revert, I was never shown an edit conflict error (these do work in Minerva: I had three recently at heavily trafficked pages, all in ns4).
My interpretation of this sequence is that since FlaggedRevs are "automatically accepted" when the editor permissions allow, checking for edit conflicts is disabled or hampered in some way, at least in some editing interfaces. Can anyone confirm this? Folly Mox (talk) 18:13, 16 November 2024 (UTC)[reply]
Well, PrimeHunter restored text above the 2 lines :I think this was [...] and :: I haven't had this [...], while you restored it below those 2 lines, that's why there was no edit conflict. I actually don't know the exact logic, though something is mentioned at mw:Help:Edit conflict#Preventing edit conflicts - I've always assumed that it's the same logic that governs if you can still undo a revision after new revisions have been made (which from experience is when the diff of that revision would not have revealed lines that changed in later revisions). – 2804:F1...C6:3070 (::/32) (talk) 22:46, 16 November 2024 (UTC)[reply]
Interesting. That certainly looks like what I need, but for some reason, this PDF isn't showing up as a thumbnail at all. See my original post in this thread and also Special:Diff/1257813566. In both of those, "File:More Public Parks (booklet).pdf" just gets run in with the text. RoySmith(talk)19:41, 16 November 2024 (UTC)[reply]
Doing a quick Wikisource version, even if incomplete, sounds like what you want here. Could link directly to the one page / section you want, that way. (Or if you just want the image, then extracting the image to a separate file on Commons, and showing that.) SnowFire (talk) 20:14, 16 November 2024 (UTC)[reply]
Wikisource has the same issue - can't start a transcription there because the "local" version Wikisource sees is empty with 0 pages. Definitely something funky afoot here. SnowFire (talk) 20:46, 16 November 2024 (UTC)[reply]
The thumbnail generating slowly sounds like a thumbor issue to me. At the time of upload pdfs where generating thumbnails in 1.67 seconds. Images do consistently generate faster than pdfs, djvus and tiffs. Some thumbnail sizes are generated immediately, regardless of whether they are in use, 320px is one of those.
This comes up from time to time - with merged cells there is often a huge size difference in the default-sort view (where they are merged) and after sorting (which unmerged all merged cells). This leads to the situation where you have to decide between either putting in a very terse / abbreviated, which avoids the table blowing up in size during sorting, but is less clear to readers and wastes the space you gain from merged cells in the first place; or you use the space provided by a merged cell, but then sorting the table might increase the size a lot.
In the default sort the "DX (APS-C)" and "FX (full frame)" provides useful information. But if you sort the table, this increases the row height a ton and it would be better to just make it say "DX" or "FX" (for example).
Probably has to do with the string replacement on the |change= parameter. Probably the easiest is to create a |change_note= parameter so it doesn't clash with that. Gonnym (talk) 23:27, 17 November 2024 (UTC)[reply]
{{Election box candidate with party link}} says {{#invoke:String|replace|source={{{change|}}}|-|−}} to change a hyphen to a minus sign in a negative number. If the parameter has a reference then its strip marker code has four hyphens which are also changed and this breaks the code. I suggest {{#invoke:String|replace|source={{{change|}}}|^-|−|plain=false}} to only change a hyphen if it's the first character. Then the articles don't need a new parameter for a note. Before editing a template used in 29,000 pages, does anyone have objections or a better solution? The bad cell in 1970 Florida Attorney General election#Results uses {{Election box winning candidate with party link}} which would need the same fix. PrimeHunter (talk) 00:08, 18 November 2024 (UTC)[reply]
Hello my friends. I am a New Page Patroller and use the excellent page curation tool. Masterhatch kindly alerted me to the fact that, when I add an "uncategorised" or "improve categories" tag, the curation tool automatically adds a space at the top of the article above the SD. I am now having to manually close the space at the top. Is anyone else having this problem? Is there a solution? Apologies if I have brought this to the wrong discussion page. Best regards, BoyTheKingCanDance (talk) 06:16, 18 November 2024 (UTC)[reply]
Identifying duplicate named refs with identical body content
The current software does not flag duplicate named refs with identical body content, as this is not considered a significant problem. However:
It wastes wikitext space.
It adds visual clutter in an edit window.
If an editor changes the body content of one of the duplicates in any way, we now have a big red cite error that is visible to readers but may go unnoticed by editors for some time. Few editors have the time to frequently scan the entire References section for such errors.
Thanks. The first cat is for duplicate refs with different content. That's not what I'm talking about, hence my italics emphasis above. Regardless, no category is going to identify the duplicates. ―Mandruss☎18:04, 18 November 2024 (UTC)[reply]
I'm not looking for automated fix; I can do that manually and I actually prefer that. I just want to identify what I need to fix manually, within a single specific article—and without a big learning curve. ―Mandruss☎18:04, 18 November 2024 (UTC)[reply]
The toollabs checkwiki tool does list what to fix, a code exerpt of the reference that is duplicated. It is just a matter of doing the edit manually and clicking the done link to the entry you fixed. The latter sentance in my first sentance on AWB is not what you are looking for. Snævar (talk) 21:19, 18 November 2024 (UTC)[reply]
@Mandruss: You'll need a script, and examine each article on a case-by-case basis. This is because if a suitable category did exist, it would contain many of these articles - the {{sfn}} template relies on the fact that it is not an error (or even a warning) for two refs to have the same content. --Redrose64 🌹 (talk) 09:05, 19 November 2024 (UTC)[reply]
Thanks.
You'll need a script - I assumed as much. I was hoping:
Such a script already existed. Or,
A script-qualified editor could be persuaded to create such a script with a barnstar and personal satisfaction as their rewards. Obviously the script would then benefit others in the same way, forever. That would be a significant contribution to the project, probably more than spending the same amount of time editing articles. (I'd certainly do it if I were script-qualified.)
I'm only interested in one article at this point, so I have no need for categories.
Wouldn't it be helpful if the email received when a page on our watchlist is updated, to have a link to the page history as well?
Current it shows the following:
Dear Bunnypranav
The Wikipedia page Wikipedia:Articles for creation/Redirects has been
changed on 18 November 2024 by anonymous user 122.43.189.14, see
<https://wiki.riteme.site/wiki/Wikipedia:Articles_for_creation/Redirects>
for the current revision.
To view this change, see
https://wiki.riteme.site/w/index.php?title=Wikipedia:Articles_for_creation/Redirects&diff=next&oldid=1258162746
For all changes since your last visit, see
https://wiki.riteme.site/w/index.php?title=Wikipedia:Articles_for_creation/Redirects&diff=0&oldid=1258162746
Can an interface admin please remove this weird css that seemingly makes my pages narrow (even on old vector)? I want to read in full width instead TheWikipedetalk19:58, 18 November 2024 (UTC)[reply]
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Updates for editors
Users of Wikimedia sites will now be warned when they create a redirect to a page that doesn't exist. This will reduce the number of broken redirects to red links in our projects. [3]
View all 42 community-submitted tasks that were resolved last week. For example, Pywikibot, which automates work on MediaWiki sites, was upgraded to 9.5.0 on Toolforge. [4]
Updates for technical contributors
On wikis that use the FlaggedRevs extension, pages created or moved by users with the appropriate permissions are marked as flagged automatically. This feature has not been working recently, and changes fixing it should be deployed this week. Thanks to Daniel and Wargo for working on this. [5][6]
In depth
There is a new Diff post about Temporary Accounts, available in more than 15 languages. Read it to learn about what Temporary Accounts are, their impact on different groups of users, and the plan to introduce the change on all wikis.
Meetings and events
Technical volunteers can now register for the 2025 Wikimedia Hackathon, which will take place in Istanbul, Turkey. Application for travel and accommodation scholarships is open from November 12 to December 10 2024. The registration for the event will close in mid-April 2025. The Wikimedia Hackathon is an annual gathering that unites the global technical community to collaborate on existing projects and explore new ideas.
Join the Wikimedia Commons community calls this week to help prioritize support for Commons which will be planned for 2025–2026. The theme will be how content should be organised on Wikimedia Commons. This is an opportunity for volunteers who work on different things to come together and talk about what matters for the future of the project. The calls will take place November 21, 2024, 8:00 UTC and 16:00 UTC.
A Language community meeting will take place November 29, 16:00 UTC to discuss updates and technical problem-solving.
As of yesterday, I am seeing an unexpected much more compact format in Diffs that is much more difficult than the traditional one for me to work from. Is there any way to get back to the old format? I am using "Vector legacy (2010)" skin. Wtmitchell(talk) (earlier Boracay Bill) 02:01, 19 November 2024 (UTC)[reply]
That toggle is on the top right, below the right end of "Browse history interactively". There is also a triangle in the middle of the page (slightly left and above the right-side "Line X" statement) which turns on/off a similar smaller preview. CMD (talk) 03:03, 19 November 2024 (UTC)[reply]
There's a discussion over at Template talk:Tweet#Post template about creating a new social media post template, that would look an act the same as the current {{Tweet}} template but extended for other social sites. A result of this was {{SocialMediaPost}}, but this seems like a very manual solution, liable to breaking and inconsistencies. I was wondering if something could be created which could, given a "website" param, automatically select the correct "site logo", "article Link", "reference format" and "prefix", similar to the way {{Political party}}s or {{Infobox legislation}} are done. Or if I'm other thinking it and the manual method is fine. Cakelot1 ☞️ talk09:50, 19 November 2024 (UTC)[reply]
Hi! Sorry for kind of jumping the gun on moving this to the template space. I'm not the best at templates, but I'll definitely take a look at those ones you linked and see if i can do anything to automate the process. It's been a bit since I've actually used Lua, but I'll try. Generating that information off of a 'website' parameter seems doable, and i'll let y'all know if i manage to make progress. Tantomile (talk) 19:41, 19 November 2024 (UTC)[reply]
In-line citation tag
Helo! I have spent way too much time trying to find the template which askes for more in-line citations in the sourcing of an article. Wading through page after page hasn't done the trick. Can anyone here please help me find it? SergeWoodzing (talk) 13:09, 19 November 2024 (UTC)[reply]
It looks like Lee imported a load of templates and modules from the English wikipedia which are designed to take English language inputs. The "time errors" for example, are because si:Module:YMD to ISO converts English date strings to an ISO formatted date, but you are giving it Sinhala month names (because the output of {{#time: depends upon the language of your wiki). You either need to go through and localise all the templates that were imported, or make new ones for your wiki. 86.23.109.101 (talk) 17:49, 19 November 2024 (UTC)[reply]
@VihirLak007 It would probably be amount the same amount of work to start from scratch rather than getting that module to work. The module takes input in the form 19 November 2024 or 19 Nov 2024, i.e. two numbers followed by the month name or abbreviation, followed by four numbers. The output of {{#time: on your wiki seems to be 2 Sinhala numerals (I think? I don't speak Sinhala) followed by the month in Sinhala, and the year. At a minimum you would need to translate the month names, add new logic to convert the Sinhala numerals to Arabic numerals, re-write all the input checks to account for the difference in format, possibly remove the logic for the month name abbreviations ... 86.23.109.101 (talk) 19:02, 19 November 2024 (UTC)[reply]
in sinhala, the numerals are same, arabic numerals. i think if i add sinhala month names alongside where it takes english names, it might work? The thing is i've no idea where to edit VihirLak007hmu!/duh.19:05, 19 November 2024 (UTC)[reply]
@VihirLak007 In that case you would need to add the Sinhala names alongside the English ones, and also change the pattern matching checks at the bottom (the bit that goes arg1:match('^%d%d%d%d %a%a%a%a?%.?%a?%a?%a?%a?%a?%a? *%d%d?$')) to allow the new date formats. 86.23.109.101 (talk) 19:09, 19 November 2024 (UTC)[reply]
The Sinhala names would just replace the English ones in the months_full variable. I'm not sure what you'd need to do to update the pattern matching, sorry. 86.23.109.101 (talk) 19:20, 19 November 2024 (UTC)[reply]
Thank you for pointing out some things I missed, can you link to exactly which article? That further reading link doesn't go anywhere. ~ฅ(ↀωↀ=)neko-channyan16:14, 20 November 2024 (UTC)[reply]
Oh, it's still pretty early in my time zone and I misread. Maybe I should get some coffee.
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.
Re-instating this proposal, I want to make the icons look more clear and sleek; I will eventually add on more to the icons (such as good articles, audio articles, etc.) I also want to add region-based letter shackles, so for example 拡 (拡張, Kakuchō) would be the Japanese extended-protection icon, same with 満 (満杯, Manpai) for full-protection.
Agree with others that these new icons look dated. However, if we are discussing changes to lock icons, then I must say the the purple for upload protected is incongruously gaudy. Cremastra — talk — c20:23, 17 October 2024 (UTC)[reply]
Oppose. I think the gradients or bevels make these icons less clear and sleek, at least in their current iteration. The icons also become less readable at smaller resolutions since the shackle part of the padlocks takes up more space, making the actual symbol inside smaller.
Pretty strong oppose trying to run a geolocation script on every load to try to make dynamic labels here. If anything (which I also don't like) labels should follow user interface language. — xaosfluxTalk17:39, 16 October 2024 (UTC)[reply]
I understand the differences, I was just suggesting (because I don't really speak any other language you could propose a specific version) Also, I will later add the letters on the shackles.
Oppose making the primary (only) differentiation be color, as that gives out less information then the current scheme and is useless for those without color viewing abilities. — xaosfluxTalk17:41, 16 October 2024 (UTC)[reply]
Agree with Xaosflux on this one. Furthermore, the two issues of the old icon scheme (color and "realistic" shading that doesn't look great on small icons), which were the reasons for the change to begin with, are present on this one too.Regarding the region-based symbols, it would make more sense to display them based on the language edition, and, since each language edition already sets its own standards for this stuff, there isn't much more we can do. Chaotic Enby (talk · contribs) 18:13, 16 October 2024 (UTC)[reply]
Agree, but only slightly. If you added the letters, it would be better. Also, a solution to your region-basing could be to do a Language-based (like "O" for "Office" would become "S" for "Schoolhouse" in a theoretical "Reversed English") The Master of Hedgehogs(converse)(hedgehogs)14:33, 17 October 2024 (UTC)[reply]
I thought we were using "shackle" as the word to describe a thing by a single aspect for the purposes of avoiding conflation with protecting/locking editing. Aaron Liu (talk) 18:13, 2 November 2024 (UTC)[reply]
Well, we shouldn't, because as @WhatamIdoing noted, the shackle is one part of a padlock. And simply using the word "padlock" avoids conflation, without calling things the wrong thing. (It's even the exact same number of letters.) FeRDNYC (talk) 03:55, 3 November 2024 (UTC)[reply]
Per WP:WIKICLICHE we've been asked to not say this quite as much, due to supply chain issues – if we use them too much we could see a huge shortage down the road. But I hope I'm not generating more heat than light with this comment, or throwing the baby out with the bathwater. Cremastra — talk — c20:22, 17 October 2024 (UTC)[reply]
Never throw the baby out with the bathwater. This will contaminate your greywater collection system. Like other meats, babies are not compostable, so they should be sorted into the landfill waste stream unless otherwise advised by your municipal waste management authority. Folly Mox (talk) Folly Mox (talk) 20:46, 17 October 2024 (UTC)[reply]
The pseudo-3D shading looks dated compared to the current flat icons. Most modern design systems (including codex, which is the new design system for Wikimedia wikis) are built around flat icons. --Ahecht (TALK PAGE)18:36, 17 October 2024 (UTC)[reply]
Just for funStill feel like a step backwards. The current "Good article" icon, on top of having less of a distracting shading and being more readable, is in a consistent style with a lot of our other icons. The current "Featured article" icon, although not consistent with the others, is pretty unique and recognizable in design, while this one looks like a generic star.Just for fun, I did once make a "Good article" star in the style of the FA one – not meant for any official implementation beyond my personal script of course, but it's neat to see how it would look like. Chaotic Enby (talk · contribs) 22:14, 17 October 2024 (UTC)[reply]
Have you ever looked at the Featured Article icon, full-size? (If not, check it out at File:Cscr-featured.png. I'll wait.) ...Like or lump @Chaotic Enby's GA star, it's actually of a fairly harmonious style with the current FA star, which is (as noted) currently not consistent with anything else anywhere. Arguably it's well-known/recognizable — Chaotic makes that argument, anyway — but TBH I have a feeling the great majority of readers never see it larger than head-of-a-pin-scaled, and wouldn't even recognize the actual, full-sized image AS our FA icon. FeRDNYC (talk) 04:10, 3 November 2024 (UTC)[reply]
I have seen the full FA icon; the GA star is just straight out of Cthulhu (...positively). It is fun, but I think GA should be more inline with the rest of the article-rating icons because of the kinda lesser rigor. Aaron Liu (talk) 13:26, 3 November 2024 (UTC)[reply]
To be fair, it's definitely a concept design rather than an actual proposal. If anything, I far prefer having the current GA icon as our official one, as it is more harmonious with basically anything that isn't the FA star. Chaotic Enby (talk · contribs) 22:18, 4 November 2024 (UTC)[reply]
These are not visual improvements whatsoever, unfortunately. They are clear regressions in design, and the current icons are fine. Our system is particular to the English Wikipedia, so it's perfectly appropriate for their design to be relative to the English language.Remsense ‥ 论19:29, 17 October 2024 (UTC)[reply]
Color me baffled. By starting with Re-instating this proposal, you make me think you want to reinvigorate some failed proposal. But then I follow your link and see that the proposal led to the implementation of new padlock icons, which; I guess, you mean to reverse. I also fail to understand what you mean by region-based letter shackles; do you mean for articles about, e.g., Japan? Or articles viewed by somebody we're supposed to have guessed might be in Japan? Or somebody with the Japanese language listed in a userbox on their User page? It's English Wikipedia, so I can't see the last two being useful options, and the first one will only lead to arguments and confusion and we've got that already. The current icons seem clear enough to me, although I don't know how to measure "sleek", I guess. In summary: baffled. — JohnFromPinckney (talk / edits)12:15, 18 October 2024 (UTC)[reply]
I mean region-based letter shackles basically like the letters on shackles but different regional translations. (This'll probably not work because of @Chaotic Enby's post.)
So (just to see if I understand it finally), you're proposing on English Wikipedia that Japanese Wikipedia use icons with Japanese symbology, and Spanish Wikipedia use some Spanish-language indicator on the padlock, etc. Yes? — JohnFromPinckney (talk / edits)22:30, 18 October 2024 (UTC)[reply]
Oppose for now. Status quo is fine. It's really cool that you're contributing your graphics skills to the movement though. I'm sure there's some less high profile areas that could really benefit from your skills. –Novem Linguae (talk) 03:55, 23 October 2024 (UTC)[reply]
Oppose: New proposals are nice but I personally like the style of the old ones better, and flat icons also seem more up-to-date to me. Regional shackles sound like a good idea, but don't appear to be in this proposal, so I'll just say I support those (maybe in the old design-style in my preference). Mrfoogles (talk) 20:22, 23 October 2024 (UTC)[reply]
Oppose per Remsense. The new 3D icons look like something from the early days of the internet. Plus the shadowing makes the icons appear unnecessarily "bulky" (not sure how to say this). Nythar (💬-🍀) 22:33, 25 October 2024 (UTC)[reply]
Oppose here as well. It's not about status quo or resistance to change, I vastly prefer the current icons to the proposed replacements. (Admittedly subjective) points in favor of the current icons over the new ones:
The flatter look will render better at small sizes (since these icons are actually shown at a fraction of the size they're displayed in this thread)
Ditto the blockier font
Ditto the thicker shackle arcs
The skinny shackles and rectangular body give the proposed replacements the appearance of handbags, not padlocks
The letter placement is more uniform and precise in the current icons; the proposed replacements appear to have been "eyeballed". IMHO SVG art of this sort is best hand-coded (if not from scratch, then at least as a finalization pass to clean up the code), with all of the dimensions precise and uniform.
I appreciate the effort, and I'm sorry to be critical, but I'm just not into them at all. The current set, OTOH, are actually fairly well-designed and optimized for their purpose, which is an important consideration in designing functional artwork of this sort. It's puzzling to me that anyone would be looking to replace them, as there's surprisingly little room for improvement IMHO. FeRDNYC (talk) 13:19, 26 October 2024 (UTC)[reply]
I think the proposed sets may been cool at the time of the previous proposal. Those locks would be more appropriate for something like in 2008. It's for the same reason why traffic lights are always (from top to bottom) red yellow green. And why train doors on British trains need doors to have sufficient contrast to the rest (see PRM TSI). In other words, using colour alone for distinguishing isn't enough.
Oppose - not a fan of the proposed icons (see also Nythar's comment), and the current locks work quite well. however, I would be supportive of a redesign of the GA/FA icons (/the various icons of the same style) in a style similar to the current locks. Rexo (talk | contributions) 20:30, 29 October 2024 (UTC)[reply]
What if we kept the shackles and good icon, get a new featured icon, and make a built-in feature that allows shackles to be compatible with dark mode? 2I3I3 (talk) 03:07, 2 November 2024 (UTC)[reply]
(to clarify: the style used by a lot of icons across the wiki (including FA/GA) feels dated, and the locks have a cleaner look that I think could be used as a basis for further redesigns. I don't think that would inherently lead to the quality symbols implying protection.) Rexo (talk | contributions) 13:54, 4 November 2024 (UTC)[reply]
I don't think the Norro or FA icons are dated, and using padlocks to indicate quality just makes no semantic sense. We adopted padlocks because it showed that the article was locked from editing. Aaron Liu (talk) 14:07, 4 November 2024 (UTC)[reply]
Our article Shackle says "A shackle is also the similarly shaped piece of metal used with a locking mechanism in padlocks.[1]". Some here seem confused, but anyone using "shackle" to refer to the handle part of the handbag-looking icon is correct. Anomie⚔21:18, 2 November 2024 (UTC)[reply]
I've updated the section heading to not be confusing (except, I guess, to one person whose idiolect equates locks and shackles, which is rather like calling your door a "handle" or "knob". — SMcCandlish☏¢ 😼 21:21, 15 November 2024 (UTC)[reply]
Ah yes, because when people want to cause trouble on Wikipedia, they immediately think "I'm going to change the wikipedia article for Shackles so that anyone who wants to know anything about them will be confused! Archer87643 (talk) 00:27, 20 November 2024 (UTC)[reply]
Oppose. While I personally favor skeuomorphism in electronic interface design and am not fan of the last decade or so's fashion for making everything flat and same-looking, we cannot sensibly re-inject a cluster of skeuomorphic design elements and leave the rest anti-skeuomorphic. Design and user-experience do not work like that. PS: The actually-named-a-shackle part of the lock depicted in the proposed new icons looks farcically thin and weak, like those on the pretend-security of luggage locks, so even if WP went with a skeuomorphic design (for everything) again, these icons in particular should not be used. — SMcCandlish☏¢ 😼 21:33, 15 November 2024 (UTC)[reply]
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.
When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.
Should a new pending changes protection level - extended confirmed pending changes (hereby abbreviated as PCECP) - be added to Wikipedia? AwesomeAasim19:58, 5 November 2024 (UTC)[reply]
Background
WP:ARBECR (from my understanding) encourages liberal use of EC protection in topic areas authorized by the community or the arbitration committee. However, some administrators refuse to protect pages unless if there is recent disruption. Extended confirmed pending changes would allow non-XCON users to propose changes for them to be approved by someone extended confirmed, and can be applied preemptively to these topic areas.
It is assumed that it is technically possible to have PCECP. That is, we can have PCECP as "[auto-accept=extended confirmed users] [review=extended confirmed users]" Right now it might not be possible to have extended confirmed users review pending changes with this protection with the current iteration of FlaggedRevs, but maybe in the future.
Survey (PCECP)
Support (PCECP)
Support for multiple reasons: WP:ARBECR only applies to contentious topics. Correcting typos is not a contentious topic. Second, WP:ARBECR encourages the use of pending changes when protection is not used. Third, pending changes effectively serves to allow uncontroversial edit requests without needing to create a new talk page discussion. And lastly, this is within line of our protection policy, which states that protection should not be applied preemptively in most cases. AwesomeAasim19:58, 5 November 2024 (UTC)[reply]
It's better than EC, which already restricts being the free encyclopedia more. As I've said below, the VisualEditor allows much more editing from new people than edit requesting, which forces people to use the source editor. Aaron Liu (talk) 03:52, 6 November 2024 (UTC)[reply]
This is not somehow less or more restrictive as ECR. It's exactly the same level of protection, just implemented in a different way. I do not get the !votes from either side who either claim that this will be more restriction or more bureaucracy. I understand neither, and urge them to explain their rationales. Aaron Liu (talk) 12:32, 12 November 2024 (UTC)[reply]
By creating a difference between what non logged-in readers (that is, the vast majority of them) see versus logged-in users, there is an extra layer of difficulty for non-confirmed and non-autoconfirmed editors, who won't see the actual page they're editing until they start the editing process. Confirmed and autoconfirmed editors may also be confused that their edits are not being seen by non-logged in readers. Because pending changes are already submitted into the linear history of the article, unwinding a rejected edit is potentially more complicated than applying successive edit requests made on the talk page. (This isn't a significant issue when there aren't many pending changes queued, which is part of the reason why one of the recommended criteria for applying pending changes protection is that the page be infrequently edited.) For better or worse, there is no deadline to process edit requests, which helps mitigate issues with merging multiple requests, but there is pressure to deal with all pending changes expediently, to reduce complications in editing. isaacl (talk) 19:54, 12 November 2024 (UTC)[reply]
Do you think this would be fixed with "branching" (similar to GitHub branches)? In other words, instead of PC giving the latest edit, PC just gives the edit of the stable revision and when "Publish changes" is clicked it does something like put the revision in a separate namespace (something like Review:PAGENAME/#######) where ####### is the revision ID. If the edit is accepted, then that page is merged and the review deleted. If the edit is rejected the review is deleted, but can always be restored by a Pending Changes Reviewer or administrator. AwesomeAasim21:01, 12 November 2024 (UTC)[reply]
There are a lot of programmers who struggle with branching; I'm not certain it's a great idea to make it an integral part of Wikipedia editing, at least not in a hidden, implicit manner. If an edit to an article always proceeded from the last reviewed version, editors wouldn't be able to build changes on top of their previous edits. I think at a minimum, an editor would have to be able to do the equivalent of creating a personal working branch. For example, this could be done by working on the change as a subpage of the user's page (or possibly somewhere else (perhaps in the Draft namespace?), using some standard naming hierarchy), and then submitting an edit request. That would be more like how git was designed to enable de-centralized collaboration: everyone works in their own repository, rebasing from a central repository (*), and asks an integrator to pull changes that they publish in their public repository.
(*) Anyone's public repository can act as a central repository. It just has to be one that all the collaborators agree upon using, and thus agree with the decisions made by the integrator(s) merging changes into that repository. isaacl (talk) 23:22, 12 November 2024 (UTC)[reply]
That makes sense. This has influenced me to amend my Q2 answer slightly, but I still support the existence of this protection and the preemptive PC protecting of low-traffic pages. (Plus, it's still not more restriction.) Aaron Liu (talk) 23:20, 12 November 2024 (UTC)[reply]
Support, functionally a more efficient form of edit requests. The volume of pending changes is still low enough for this to be dealt with, and it could encourage the pending changes reviewer right to be given to more people currently reviewing edit requests, especially in contentious topics. Chaotic Enby (talk · contribs) 20:25, 5 November 2024 (UTC)[reply]
Support having this as an option. I particularly value the effect it has on attribution (because the change gets directly attributed to the individual who wanted it, not to the editor who processed the edit request). WhatamIdoing (talk) 20:36, 5 November 2024 (UTC)[reply]
Support: better and more direct system than preemptive extended-confirmed protection followed by edit requests on the talk page. Cremastra (u — c) 20:42, 5 November 2024 (UTC)[reply]
Support, Pending Changes has the capacity to take on this new task. PC is much better than the edit request system for both new editors and reviewers. It also removes the downsides of slapping ECP on everything within contentious topic areas. Toadspike[Talk]20:53, 5 November 2024 (UTC)[reply]
I've read the opposes below and completely disagree that this would lead to more gatekeeping. The current edit request system is extremely complicated and inaccessible to new users. I've been here for half a decade and I still don't really know how it works. The edit requests we do get are a tiny fraction of the edits people want to make to ECP pages but can't. PCECP would allow them to make those edits. And many (most?) edit requests are formatted in a way that they can't be accepted (not clear what change should be made, where, based on what souce), a huge issue which would be entirely resolved by PCECP.
The automatic EC protection of all pages in certain CTOPs is not the point of this proposal. Whether disruption is a prerequisite to protection is not altered by the existence of PCECP and has to be decided in anther RfC at another venue, or by ArbCom. PCECP is solely about expanding accessibility to editing ECP pages for new and unregistered editors, which is certainly a positive move.
I, too, hate the PC system at dewiki, and I appreciate that Kusma mentioned it. However, what we're looking at here is lowering protection levels and reducing barriers to editing, which is the opposite of dewiki's PC barriers. Toadspike[Talk]10:24, 16 November 2024 (UTC)[reply]
Support Agree with JPxG's principle that it is better to "have drama on a living project than peace on a dead one," but this is far less restrictive than preemptively setting EC protection for all WP:ARBECR pages. From a new editor's perspective, they experience a delay in the positive experience of seeing their edit implemented, but as long as pending changes reviewers are equipped to minimize this delay, then this oversight seems like a net benefit. New users will get feedback from experienced editors on how to operate in Wikipedia's toughest content areas, rather than stumbling through. ViridianPenguin 🐧 ( 💬 ) 08:57, 8 November 2024 (UTC)[reply]
Support Idk what it's like in other areas but in mine, of edit requests that I see, a lot, maybe even most of them are POV/not actionable/nonsense/insults so if it is already ECR only, then yea, more filtering is a good thing.Selfstudier (talk) 18:17, 11 November 2024 (UTC)[reply]
Support assuming this is technically possible (which I'm not entirely sure it is), it seems like a good idea, and would definitely make pending changes more useful from my eyes. Zippybonzo | talk | contribs (they/them) 20:00, 12 November 2024 (UTC)[reply]
Strong support per @JPxG:'s reasoning—I think it's wild that we're willing to close off so many articles to so many potential editors, and even incremental liberalization of editing restrictions on these articles should be welcomed. This change would substantially expand the number of potential editors by letting non-EC contributors easily suggest edits to controversial topic areas. It would be a huge win for contributions if we managed to replace most ECP locks with this new PCECP.– Closed Limelike Curves (talk) 02:07, 14 November 2024 (UTC)[reply]
Support in principle. Edit requests are a really bad interface for new users; if discouraging people from editing is the goal, we've succeeded. Flagged revisions aren't the best, but they are better than edit request templates. Toadspike's reasoning hasn't been refuted. Right now, it seems like opposers aren't aware that the status quo for many Palestine-Israel related articles is ECP. Both Israeli cuisine and Palestinian cuisine are indefinitely under WP:ECP due to gastronationalist arguments about the politics of food in the Arab–Israeli conflict (a page not protected), so editors without 500/30 status cannot add information about falafels to Wikipedia. That being said, this proposal would benefit from more detail. For example, the current edit request policy requires the proposed change to be uncontroversial and puts the burden on the proposer to show that it is uncontroversial. On the other hand, the current review policy assumes a change is correct unless it's obvious vandalism or the like, which would be a big change to the edit request workflow. Likewise, what counts as WP:INVOLVED for reviewers? Right now, there's a big firewall between editors involved in content in an area like Israel-Palestine and admins using their powers in that area. Can reviewers edit in the area and use their tools? This needs to be clarified, as it seems like editing in PIA doesn't disqualify one from answering edit requests. Chess (talk) (please mention me on reply)21:06, 18 November 2024 (UTC)[reply]
the current review policy assumes a change is correct unless it's obvious vandalism or the like
@Chess That's true, but reviewers are also currently expected to accept and revert if the change is correct but also irky for a revert. Below, Aasim clarified that reviewers should only reject edits that fail the existing PC review guidelines plus edits made in violation of an already well-established consensus. As for Involved, since there's no guidance about edit request reviewers yet either, I think that should be asked in a separate RfC. Aaron Liu (talk) 21:35, 18 November 2024 (UTC)[reply]
Support. The number of sysops is ever decreasing and so we will need to take drastic action to ensure maintenance and vandalism prevention can keep up. Stifle (talk) 17:29, 19 November 2024 (UTC)[reply]
Oppose (PCECP)
Oppose There's a lot of history here, and I've opposed WP:FPPR/FlaggedRevs consistently since ~2011. Without reopening the old wounds over how the initial trial was implemented/ended, nothing that's happened since has changed my position. I believe that proceeding with an expansion of FlaggedRevs would be a further step away from our commitment to being the free encyclopedia that anyone can edit without actually solving any critical problems that our existing tools aren't already handling. While the proposal includes However, some administrators refuse to protect pages unless if there is recent disruption as a problem, I see that as a positive. In fact that's the entire point; protection should be preventative and there should be evidence of recent disruption. If a page is experiencing disruption, protection can handle it. If not, there's no need to limit anyone's ability to edit. The WordsmithTalk to me03:45, 6 November 2024 (UTC)[reply]
The Wordsmith, regarding "However, some administrators refuse to protect pages unless if there is recent disruption as a problem, I see that as a positive.", for interest, I see it as a negative for a number of reasons, at least in the WP:PIA topic area, mostly because it is subjective/non-deterministic.
The WP:ARBECR rules have no dependency on subjective assessments of the quality of edits. Non-EC editors are only allowed to make edit requests. That is what we tell them.
If it is the case that non-EC editors are only allowed to make edit requests, there is no reason to leave pages unprotected.
If it is not the case that non-EC editors can only allowed to make edit requests, then we should not be telling them that via talk page headers and standard notification messages.
There appears to be culture based on an optimistic faith-based belief that the community can see ARBECR violations, make reliable subjective judgements based on some value system and deal with them appropriately through action or inaction. This is inconsistent with my observations.
Many disruptive violations are missed when there are hundreds of thousands of revisions by tens of thousands of actors.
The population size of editors/admins who try to address ARBECR violations is very small, and their sampling of the space is inevitably an example of the streetlight effect.
The PIA topic area is largely unprotected and there are thousands of articles, templates, categories, talk pages etc. Randomness plays a large part in ARBECR enforcement for all sorts of reasons (and maybe that is good to some extent, hard to tell).
Wikipedia's lack of tools to effectively address ban evasion in contentious topic areas means that it is not currently possible to tell whether a revision by a non-EC registered account or IP violating WP:ARBECR that resembles an okay edit (to me personally with all of my biases and unreliable subjectivity) is the product of a helpful person or a ban evading recidivist/member of an off-site activist group exploiting a backdoor.
Oppose, I hate pending changes. Using them widely will break the wiki. We need to be as welcoming as possible to new editors, and the instant gratification of wiki editing should be there on as many pages as possible. —Kusma (talk) 21:47, 6 November 2024 (UTC)[reply]
We already have a similar and larger backlog at CAT:EEP. All this does is move the backlog into an interface handled by server software that allows newcomers to use VE for their "edit requests", where currently they must use the source editor due to being confined to talk pages. Aaron Liu (talk) 23:06, 6 November 2024 (UTC)[reply]
... if the number of protected pages does not increase. I expect an increase in protected pages from the proposal, even if the terrifying proposal to protect large classes of articles preemptively does not pass. —Kusma (talk) 13:08, 7 November 2024 (UTC)[reply]
Most PCECP pages should be ECP pages (downgraded?) as they have lesser traffic/disruption. So, the number of pages that will be increase should not be that much. ~/Bunnypranav:<ping>13:35, 7 November 2024 (UTC)[reply]
@Kusma Isn't the loss of instant gratification of editing better than creating a request on the talk page of an ECP page, and having no idea by when will it be reviewed and implemented. ~/Bunnypranav:<ping>11:25, 7 November 2024 (UTC)[reply]
Oppose — Feels unnecessary and will only prevent other good faith editors from editing, not to mention the community effort required to monitor and review pending changes requests given that some areas like ARBIPA apply to hundreds of thousands of pages. Ratnahastin(talk)01:42, 7 November 2024 (UTC)[reply]
There is a very good reason I reference Community Resources Against Street Hoodlums in my preferred name for the protection scheme, and the answer is generally no since the topic area we are primarily talking about is an ethno-political contentious topic, which tend to draw partisans interested only in "winning the war" on Wikipedia. This is not limited to just new users coming in, but also established editors who have strong opinions on the topic and who may be put into the position of reviewing these edits, as a read of any random Eastern Europe- or Palestine-Israel-focused Arbitration case would make clear just from a quick skim. —Jéské Courianov^_^vthreadscritiques18:21, 7 November 2024 (UTC)[reply]
Except that is how pull requests work on GitHub. You make the edit, and someone with reviewer permissions approves it to complete the merge. Here, the "commit" happens, but the revision is not visible until reviewed and approved. Edit requests are not pull requests, they are the equivalent of "issues" on GitHub. AwesomeAasim19:03, 11 November 2024 (UTC)[reply]
It may come as a surprise, but Wikipedia is not GitHub. While they are both collaborative projects, they are very different in most other respects. Thryduulf (talk) 19:20, 11 November 2024 (UTC)[reply]
With Git, submitters make a change in their own branch (which can even be in their own repository), and then request that an integrator pull that change into the main branch. So the main branch history remains clean: it only has changes that were merged in. (It's one of the guiding principles of Git: allow the history tree of any branch to be simplified to improve clarity and performance.) isaacl (talk) 22:18, 11 November 2024 (UTC)[reply]
Edit requests are supposed to be pull requests.
Clearly indicate which sections or phrases should be replaced or added to, and what they should be replaced with or have added. — WP:ChangeXY
Yeah that is what they are supposed to be but in practice they are not. As anyone who has answered edit requests before, there are often messages that look like this:
This template must be followed by a complete and specific description of the request, that is, specify what text should be removed and a verbatim copy of the text that should replace it. "Please change X" is not acceptable and will be rejected; the request must be of the form "please change X to Y".
The edit may be made by any extended confirmed user. Remember to change the |answered=no parameter to "yes" when the request has been accepted, rejected or on hold awaiting user input. This is so that inactive or completed requests don't needlessly fill up the edit requests category. You may also wish to use the {{EEp}} template in the response. To request that a page be protected or unprotected, make a protection request.
Oppose, per what JSS has said. I am a little uncomfortable at the extent to which we've seemingly accepted preemptive protection of articles in contentious areas. It may be a convenient way of reducing the drama us admins and power users have to deal with... but only at the cost of giving up on the core principle that anybody can edit. I would rather have drama on a living project than peace on a dead one. jp×g🗯️18:16, 7 November 2024 (UTC)[reply]
Oppose as unnecessary, seems like a solution in search of a problem. Furthermore, this *is* Wikipedia, the encyclopedia anyone can edit; preemptively protecting pages discourages contributions from new editors. -Fastily22:36, 8 November 2024 (UTC)[reply]
Weak Oppose I do understand where this protection would be helpful. But I just think something is EC-protectable or not. Don't necessarily think adding another level of bureaucracy is particularly helpful. --Takipoint123 (talk) 05:14, 11 November 2024 (UTC)[reply]
Oppose. I'm inclined to agree that the scenarios where this tool would work a benefit as technical solution would be exceedingly niche, and that such slim benefit would probably be outweighed by the impact of having yet one more tool to further nibble away at the edges of the open spaces of the project which are available to new editors. Frankly, in the last few years we have already had an absurdly aggressive trend towards community (and ArbCom fiat) decisions which have increasingly insulated anything remotely in the vain of controversy from new editors--with predictable consequences for editor recruitment and retention past the period of early involvement, further exacerbating our workloads and other systemic issues. We honestly need to be rolling back some of these changes, not adding yet one more layer (however thin and contextual) to the bureaucratic fabric/new user obstacle course. SnowRise let's rap11:23, 12 November 2024 (UTC)[reply]
Oppose. The more I read this discussion, the more it seems like this wouldn't solve the majority of what it sets out to solve but would create more problems while doing so, making it on balance a net negative to the project. Thryduulf (talk) 21:43, 12 November 2024 (UTC)[reply]
Oppose and Point of Order Oppose because pending changes is already too complicated and not very useful. I'm a pending changes reviewer and I've never rejected one on PC grounds (basically vandalism). But I often revert on normal editor grounds after accepting on PC grounds. (I suspect that many PC rejections are done for non-PC reasons instead of doing this) "Point of Order" is because the RFC is unclear on what exactly is being opposed. Sincerely, North8000 (talk) 22:15, 12 November 2024 (UTC)[reply]
Pretty sure that what happens is that when vandals realize they will have to submit their edit for review before it goes live, that takes all the fun out of it for them because it will obviously be rejected, and they don't bother. That's pretty much how it was supposed to work. Just Step Sidewaysfrom this world ..... today22:22, 12 November 2024 (UTC)[reply]
This is a very good point, and I ask for @Awesome Aasim's clarification on whether reviewers will be able to reject edits on grounds for normal reverts combined with the EC restriction. I think there's enough rationale to apply this here beyond the initial rationale for PC as explained by JSS above. Aaron Liu (talk) 23:24, 12 November 2024 (UTC)[reply]
Reviewers are given specific reasons for accepting edits (see Wikipedia:Pending changes § Reviewing pending edits) to avoid overloading them with work while processing pending changes expeditiously. If the reasons are opened up to greater evaluation of the quality of edits, then expectations may shift towards this being a norm. Thus some users are concerned this will create a hierarchy of editors, where edits by non-reviewers are gated by reviewers. isaacl (talk) 23:44, 12 November 2024 (UTC)[reply]
I understand that and wonder how the reviewer proposes to address this. I would still support this proposal if having reviewers reject according to whether they'd revert and "ostensibly" to enforce EC is to be the norm, albeit to a lesser extent for the reasons you mentioned (though I'd replaced "non-reviewers" with "all non–auto-accepted"). Aaron Liu (talk) 00:13, 13 November 2024 (UTC)[reply]
I'm not sure to whom you are referring when you say "the reviewer" – you're the one suggesting there's a rationale to support more reasons for rejecting a pending change beyond the current set. Since any pending change in the queue will prevent subsequent changes by non-reviewers from being visible to most readers, their edits too will get evaluated by a single reviewer before being generally visible. isaacl (talk) 00:59, 13 November 2024 (UTC)[reply]
Sorry, I meant Aasim, the nominator. I made a thinko. Currently, reviewers can undo just the edits that aren't good and then approve the revision of their own revert. I thought that was what we were supposed to do. Aaron Liu (talk) 02:13, 13 November 2024 (UTC)[reply]
Yes. Anything that is obvious vandalism or a violation of existing Wikipedia's policies can still be rejected. However, for edits where there is no other problem, the edit can still be accepted. In other words, a user not being extended confirmed shall not be sufficient grounds for rejecting an edit under PCECP, since the extended confirmed user takes responsibility for the edit. If the extended confirmed user accepts a bad edit, it is on them, not whoever made it. That is the whole idea.
Of course obviously helpful changes such as fixing typos and adding up-to-date information should be accepted sooner, while more controversial changes should be discussed first. AwesomeAasim17:37, 13 November 2024 (UTC)[reply]
Yeah, but also edits made in violation of an already well-established consensus. Edits that enforce a clearly-established consensus (proven by previous talk page discussion), are, from my understanding, exempt from all WP:EW restrictions. AwesomeAasim18:38, 13 November 2024 (UTC)[reply]
Oppose per Thryduulf and SnowRose. Also regardless of whether this is a good idea as a policy, FlaggedRevs has a large amount of technical debt, to the extent that deployment to any additional WMF wikis is prohibited, so it seems unwise to expand its usage. novovtalkedits19:05, 13 November 2024 (UTC)[reply]
Oppose the more productive approach would be to reduce the overuse of extended-confirmed protection. We have come to rely on it too much. This would be technically difficult and complex for little real gain. —Ganesha811 (talk) 18:30, 16 November 2024 (UTC)[reply]
Oppose. How can we know that the 72,742 extended-confirmed users are capable of reviewing pending changes? I assume this is a step above normal PCP (eg. pcp is preferred over pcecp), how can reviewing semi-protected pending changes have a higher bar (requiring a request at WP:PERM) than reviewing extended-protected pending changes? Doesn't make much sense to me. — BerryForPerpetuity(talk)14:15, 20 November 2024 (UTC)[reply]
Sure, but assuming this will work the same as PCR, isn't it possible that an extended-confirmed user who doesn't want to review edits, will try to edit a PCECP page, and be required to review edits beforehand? They're not actively seeking out to review edits in the same way that a PCR or someone who handles edit requests does. Will their review be on par with the scrutiny required for this level of protection? — BerryForPerpetuity(talk)14:55, 20 November 2024 (UTC)[reply]
You do not need to review edits to edit the pending version of the page, which is what happens when you press save on a page with pending edits. Aaron Liu (talk) 15:02, 20 November 2024 (UTC)[reply]
Is it not the case that reviewers need to check a page's pending changes to edit a page? Either way, the point of "what would constitute a revert" needs to be discussed and decided on before we start to implement this, which I appreciate you discussing above. — BerryForPerpetuity(talk)15:38, 20 November 2024 (UTC)[reply]
How can we know that the 72,734 extended-confirmed users are capable of reviewing pending changes? This isn't about pending changes level 1. This is about pending changes as applied to enforce ECP, with the level [auto-accept=extendedconfirmed] [review=extendedconfirmed]. As this is only intended to be used for WP:ARBECR restricted pages, it shouldn't be used for anything else.
What might need to happen for this to work is there are ways to configure who can auto-accept and review changes individually (rather than bundled as is right now) with the FlaggedRevs extension. Something like this for these drop-downs:
Auto-accept:
All users
Autoconfirmed
Extended confirmed
Template editor
Administrators
Review:
Autoconfirmed
Extended confirmed and reviewers
Template editors and reviewers
Administrators
Of course, autoreview will have auto-accept perms regardless of these settings, and review will have review perms regardless of these settings. AwesomeAasim16:36, 20 November 2024 (UTC)[reply]
Someone who is an expert at configuring mw:Extension:FlaggedRevs will need to confirm that it is possible to simultaneously have our current type of pending changes protection plus this new type of pending changes protection. The current enwiki FlaggedRevs config looks something like the below and may not be easy to configure. You may want to ping Ladsgroup or post at WP:VPT for assistance.
Extended content
// enwiki// InitializeSettings.php$wgFlaggedRevsOverride=false;$wgFlaggedRevsProtection=true;$wgSimpleFlaggedRevsUI=true;$wgFlaggedRevsHandleIncludes=0;$wgFlaggedRevsAutoReview=3;$wgFlaggedRevsLowProfile=true;// CommonSettings.php$wgAvailableRights[]='autoreview';$wgAvailableRights[]='autoreviewrestore';$wgAvailableRights[]='movestable';$wgAvailableRights[]='review';$wgAvailableRights[]='stablesettings';$wgAvailableRights[]='unreviewedpages';$wgAvailableRights[]='validate';$wgGrantPermissions['editprotected']['movestable']=true;// flaggedrevs.phpwfLoadExtension('FlaggedRevs');$wgFlaggedRevsAutopromote=false;$wgHooks['MediaWikiServices'][]=staticfunction(){global$wgAddGroups,$wgDBname,$wgDefaultUserOptions,$wgFlaggedRevsNamespaces,$wgFlaggedRevsRestrictionLevels,$wgFlaggedRevsTags,$wgFlaggedRevsTagsRestrictions,$wgGroupPermissions,$wgRemoveGroups;$wgFlaggedRevsNamespaces[]=828;// NS_MODULE$wgFlaggedRevsTags=['accuracy'=>['levels'=>2]];$wgFlaggedRevsTagsRestrictions=['accuracy'=>['review'=>1,'autoreview'=>1],];$wgGroupPermissions['autoconfirmed']['movestable']=true;// T16166$wgGroupPermissions['sysop']['stablesettings']=false;// -aaron 3/20/10$allowSysopsAssignEditor=true;$wgFlaggedRevsNamespaces=[NS_MAIN,NS_PROJECT];# We have only one tag with one level$wgFlaggedRevsTags=['status'=>['levels'=>1]];# Restrict autoconfirmed to flagging semi-protected$wgFlaggedRevsTagsRestrictions=['status'=>['review'=>1,'autoreview'=>1],];# Restriction levels for auto-review/review rights$wgFlaggedRevsRestrictionLevels=['autoconfirmed'];# Group permissions for autoconfirmed$wgGroupPermissions['autoconfirmed']['autoreview']=true;# Group permissions for sysops$wgGroupPermissions['sysop']['review']=true;$wgGroupPermissions['sysop']['stablesettings']=true;# Use 'reviewer' group$wgAddGroups['sysop'][]='reviewer';$wgRemoveGroups['sysop'][]='reviewer';# Remove 'editor' and 'autoreview' (T91934) user groupsunset($wgGroupPermissions['editor'],$wgGroupPermissions['autoreview']);# Rights for Bureaucrats (b/c)if(isset($wgGroupPermissions['reviewer'])){if(!in_array('reviewer',$wgAddGroups['bureaucrat']??[])){// promote to full reviewers$wgAddGroups['bureaucrat'][]='reviewer';}if(!in_array('reviewer',$wgRemoveGroups['bureaucrat']??[])){// demote from full reviewers$wgRemoveGroups['bureaucrat'][]='reviewer';}}# Rights for Sysopsif(isset($wgGroupPermissions['editor'])&&$allowSysopsAssignEditor){if(!in_array('editor',$wgAddGroups['sysop'])){// promote to basic reviewer (established editors)$wgAddGroups['sysop'][]='editor';}if(!in_array('editor',$wgRemoveGroups['sysop'])){// demote from basic reviewer (established editors)$wgRemoveGroups['sysop'][]='editor';}}if(isset($wgGroupPermissions['autoreview'])){if(!in_array('autoreview',$wgAddGroups['sysop'])){// promote to basic auto-reviewer (semi-trusted users)$wgAddGroups['sysop'][]='autoreview';}if(!in_array('autoreview',$wgRemoveGroups['sysop'])){// demote from basic auto-reviewer (semi-trusted users)$wgRemoveGroups['sysop'][]='autoreview';}}};
I basically came here to ask if this is even possible or if it would need WMMF devs involvement or whatever.
For those unfamiliar, pending changes is not the same thing as the flagged revisions used on de.wp. PC was developed by the foundation specifically for this project after we asked for it. We also used to have WP:PC2 but nobody really knew what that was supposed to be and how to use it and it was discontinued. Just Step Sidewaysfrom this world ..... today21:21, 6 November 2024 (UTC)[reply]
Depends on what exactly is meant by "implementation". A configuration where edits by non-extendedconfirmed users need review by reviewers would probably be similar to what was removed in gerrit:/r/334511 to implement T156448 (removal of PC2). I don't know whether a configuration where edits by non-extendedconfirmed users can be reviewed by any extendedconfirmed user while normal PC still can only be reviewed by reviewers is possible or not. Anomie⚔13:32, 7 November 2024 (UTC)[reply]
Looking at the MediaWiki documentation, it is not possible atm. That said, currently the proposal assumes that it is possible and we should work with that (though I would also support allowing all extended-confirmed to review all pending changes). Aaron Liu (talk) 13:56, 7 November 2024 (UTC)[reply]
I think the RfC summary statement is a bit incomplete. My understanding is that the pending changes feature introduces a set of rights which can be assigned to corresponding user groups. I believe all the logic is based on the user rights, so there's no way to designate that one article can be autoreviewed by one user group while another article can be autoreviewed by a different user group. Thus unless the proposal is to replace autoconfirmed pending changes with extended confirmed pending changes, I don't think saying "enabled" in the summary is an adequate description. And if the proposal is to replace autoconfirmed pending changes, I think that should be explicitly stated. isaacl (talk) 22:06, 6 November 2024 (UTC)[reply]
The proposal did not specify if it assumed co-existence is possible, or enabling it is possible, which could mean replacement. Thus I feel the summary statement (before the timestamp, which is what shows up in the central RfC list) is incomplete. isaacl (talk) 22:31, 6 November 2024 (UTC)[reply]
While on a re-read, It is assumed that it is technically possible to have PCECP does not explicitly imply co-existence, that is how I interpreted it. Anyways, it would be wonderful to hear from @Awesome Aasim about this. Aaron Liu (talk) 22:42, 6 November 2024 (UTC)[reply]
The key question that ought to be clarified is if the proposal is to have both, or to replace the current one with a new version. (That ties back to the question of whether or not the arbitration committee's involvement is required.) Additionally, it would be more accurate not to use a word in the summary that implies the only cost is turning on a switch. isaacl (talk) 22:49, 6 November 2024 (UTC)[reply]
It is assuming that we can have PC1 where only reviewers can approve edits and PCECP where only extended confirmed users can approve edits AND make edits without requiring approval. With the current iteration I don't know if it is technically possible. If it requires an extension rewrite or replacement, that is fine. If something is still unclear, please let me know. AwesomeAasim23:06, 6 November 2024 (UTC)[reply]
I suggest changing the summary statement to something like, "Should a new pending changes protection level be added to Wikipedia – extended confirmed pending changes (hereby abbreviated as PCECP)?". The subsequent paragraph can provide the further explanation on who would be autoreviewed and who would serve as reviewers with the new proposed level. isaacl (talk) 23:19, 6 November 2024 (UTC)[reply]
I think inclusion of the preemptive-protection part in the background statement is causing confusion. AFAIK preemptive protection and whether we should use PCECP over ECP are separate questions. Aaron Liu (talk) 19:11, 7 November 2024 (UTC)[reply]
Q2: If this proposal passes, should PCECP be applied preemptively to WP:ARBECR topics?
Also to add on there needs to be some enforcement measure for WP:ARBECR. No technical enforcement measures on WP:ARBECR is akin to site-banning an editor and then refusing to block them because "blocks should be preventative". AwesomeAasim19:42, 13 November 2024 (UTC)[reply]
Blocking a site-banned user is preventative, because if we didn't need to prevent them from editing they wouldn't have been site banned. Thryduulf (talk) 21:16, 13 November 2024 (UTC)[reply]
Support, including on talk pages. With edit requests mostly dealt with through pending changes, protecting the talk pages too should limit the disruption and unconstructive comments that are often commonplace there. (Changing my mind, I don't think applying PCECP on all pages would be a constructive solution. The rules of ARBECR limit participation to extended-confirmed editors, but the spirit of the rules has been to only enforce that on pages with actual disruption, not preemptively. 20:49, 7 November 2024 (UTC)) Chaotic Enby (talk · contribs) 20:21, 5 November 2024 (UTC)[reply]
Support I'm going to disagree with the "no" argument entirely - we should be preemptively ECPing (even without pending changes). It's a perversion of logic to say "you can't (per policy) do push this button", and then refuse to actually technically stop you from pushing the button even though we know you could. * Pppery *it has begun...20:52, 5 November 2024 (UTC)[reply]
Support (Summoned by bot): While I disagree with ECR in general, this is a better way of enforcing it as long as it exists. Constructive "edit requests" can be accepted, and edits that people disagree with can be easily reverted. I'm slightly concerned with how this could affect the pending changes backlog (which has a fairly small number of active reviewers at the moment), but I'm sure that can be figured out. CFA💬23:41, 5 November 2024 (UTC)[reply]
Oppose (Preemptive PCECP)
No, I don't think this is necessary at this time. I think it should be usable there, but I don't feel like this is a necessary step at this time. We could revisit it later. WhatamIdoing (talk) 20:37, 5 November 2024 (UTC)[reply]
No, we still shouldn't be protecting preemptively. Wait until there's disruption, and then choose between PCXC or regular XC protection (I would strongly favour the former for the reasons I gave above). Cremastra (u — c) 20:43, 5 November 2024 (UTC)[reply]
No, I feel this would be a bad idea. Critics of Wikipedia already use the idea that it's controlled by a select group, this would only make that misconception more common. -- LCU ActivelyDisinterested«@» °∆t°14:36, 6 November 2024 (UTC)[reply]
Absolutely not. No need for protection if there is no disruption. The number of protected pages should be kept low, and the number of pages that cry out "look at me!" on your watchlist (anything under pending changes) should be as close to zero as possible. —Kusma (talk) 21:44, 6 November 2024 (UTC)[reply]
No need for protection if there is no disruption. Trouble is, the ECR restriction is enacted in response to widespread disruption, this time to the entire topic area as a whole. Disregard for POV, blatant inclusion of unverifiable or false (unreliable) information, and more all pose serious threats of disruption to the project. If WP:ARBECR was applied broadly without any protection I would agree, but WP:ARBECR is applied in response to disruption (or a serious threat of), not preemptively. Take this one for example, which is a long winded ANI discussion that ended in the WP:GS for the Russo-Ukranian War (and the ECR restrictions). And as for Arbitration Committee, ArbCom is a last resort when all other attempts to resolve disruption fail. See WP:ARBPIAWP:ARBPIA2WP:ARBPIA3WP:ARBPIA4. The earliest reference to the precursor to ARBECR in this case is on the third ArbCom case. Not protecting within a topic area that has a high risk of disruption is akin to having a high-risk template unprotected. The only difference is that carelessly editing a high-risk template creates technical problems, while carelessly editing a high-risk topic area creates content problems.
Either the page is protected technically (which enforces a community or ArbCom decision that only specific editors are allowed in topic areas) or the page is not protected technically but protected socially (which then gives a chance of evasion). I see this situation no different from banning an editor sitewide and then refusing to block them on the grounds that "blocks should only be used to prevent disruption" while ignoring the circumstances leading up to the site ban.
What PCECP would do is allow for better enforcement of the community aspect. New editors won't be bitten, if they find something that needs fixing like a typo, they can make an edit and it can get approved. More controversial edits will get relegated to the talk page where editors not banned from that topic area can discuss that topic. And blatant POV pushing and whatnot would get reverted and would never even be seen by readers.
The workflow would look like this: new/anon user make an edit → edit gets held for review → extended confirmed user approves the edit. Rather than the current workflow (and the reason why preemptive ECP is unpopular): new/anon user makes an edit → user is greeted with a "this page is protected" message → user describes what they would like to be changed but in a badly formulated way → edit request gets closed as "unclear" or something similar. AwesomeAasim14:21, 11 November 2024 (UTC)[reply]
No. We should be quicker to apply protection in these topics than we would elsewhere, but not preemptively except on highly visible pages (which, in these topics, are probably ECP-protected anyway). Animal lover|666|17:18, 11 November 2024 (UTC)[reply]
I'm not saying such a discussion exists, but changes to Arbitration remedies/discretionary sanctions are something they would want to weigh in on. Arbitration policy (which includes WP:Contentious topics) is in their wheelhouse and this would have serious implications for WP:CT/A-I and any further instances where ArbCom (rather than individual editors, as a discretionary sanction) would need to resort to a 500/30 rule as an explicit remedy. —Jéské Courianov^_^vthreadscritiques04:58, 6 November 2024 (UTC)[reply]
That is not my reading of WP:ARBECR. Specifically, On any page where the restriction is not enforced through extended confirmed protection, this restriction may be enforced by...the use of pending changes... (bold added by me for emphasis). But if there is consensus not to use this preemptively so be it. AwesomeAasim05:13, 6 November 2024 (UTC)[reply]
While I appreciate the forward thinking that PCECP may want to be used in Arb areas, this feels like a considerable muddying of the delineation between the Committee's role and the community's role. Traditionally, Contentious Topics have been the realm of ArbCom, and General Sanctions have been the realm of the Community. Part of the logic comes down to who takes the blame when things go wrong. The Community shouldn't take the blame when ArbCom makes a decision, and vice versa. Part of the logic is separation of powers. If the community wants to say "ArbCom, you will enforce this so help you God," then that should be done by amending ArbPol. Part of the logic is practical. If the community creates a process that adds to an existing Arb process, what happens when the Arbs want to change that process? Or even end it altogether? Bottomline: Adopting PCECP for ARBECR is certainly something ArbCom could do. But I'd ask the community to consider the broader structural problems that would arise if the community adopted it on behalf of ArbCom. CaptainEekEdits Ho Cap'n!⚓05:18, 7 November 2024 (UTC)[reply]
Interesting. I'd say ArbCom should be able to override the community if they truly see such action fit and worthy of potential backlash. Aaron Liu (talk) 12:30, 7 November 2024 (UTC)[reply]
Just a terminology note, although I appreciate many think of general sanctions in that way, it's defined on the Wikipedia:General sanctions page as ... a type of Wikipedia sanctions that apply to all editors working in a particular topic area. ... General sanctions are measures used by the community or the Arbitration Committee ("ArbCom") to improve the editing atmosphere of an article or topic area.. Thus the contentious topics framework is a form of general sanctions. isaacl (talk) 15:22, 7 November 2024 (UTC)[reply]
Regarding the general point: I agree that it is cumbersome for the community to impose a general sanction that is added on top of a specific arbitration remedy. I would prefer that the community work with the arbitration committee to amend its remedy, which would facilitate keeping the description of the sanction and logging of its enforcement together, instead of split. (I appreciate that for this specific proposal, logging of enforcement is not an issue.) isaacl (talk) 15:30, 7 November 2024 (UTC)[reply]
Extended confirmed started off as an arbcom concept - 500 edits/30 days - which the community then choose to adopt. ArbCom then decided to make its remedy match the community's version - such that if the community were to decide extended confirmed were 1000 edits/90 days all ArbCom restrictions would update. I find this a healthy feedback loop between ArbCom and the community. The community could clearly choose (at least on a policy level, given some technical concerns) to enact PCECP. It could choose to apply this to some/all pages. If it is comfortable saying that it wants to delegate some of which pages this applies to the Arbitration Committee I think it can do so without amending ArbPol. However, I think ArbCom could could decide that PCECP would not apply in some/all CTOP areas given that the Committee is exempt from consensus for areas with-in its scope. And so it might ultimately make more sense to do what isaacl suggests. Best, Barkeep49 (talk) 16:02, 7 November 2024 (UTC)[reply]
The "contentious topics" procedure does seem like something that the community should absolutely mirror and that ultimately both the community and ArbCom should work out of. If one diverges, there is probably a good reason why it diverged.
As for the broader structural problems that would arise if the community adopted it on behalf of ArbCom, there are already structural problems with general sanctions because of the community's failure to adopt the new CTOP procedure for new contentious topics. Although the community has adopted the contents of WP:ARBECR for other topic areas like WP:RUSUKR, they don't adopt it by reference but by copying the whole text verbatim. AwesomeAasim17:13, 7 November 2024 (UTC)[reply]
That's not the same structural problem. The community hasn't had a lot of discussion about adopting the contentious topic framework for its own use (in my opinion, because it's a very process-wonky discussion that doesn't interest enough editors to generate a consensus), but that doesn't interfere with how the arbitration committee uses the contentious topic framework. This proposal is suggesting that the community automatically layer on its own general sanction on top of any time the arbitration committee decides to enact a specific sanction. Thus the committee would have to consider each time whether or not to override the community add-on, and amendment requests might have to be made both to the committee and the community. isaacl (talk) 17:33, 7 November 2024 (UTC)[reply]
Prior to contentious topics there were discretionary sanctions. Those became very muddled and so the committee created Contentious topics to help clarify the line between community and committee (disclosure: I help draft much of that work). As part of that the committee also established ways for the community to tie-in to contentious topics if it wanted. So for the community hasn't made that choice which is fine. But I do this is an area that, in general, ArbCom does better than the community because there is more attention paid to having consistency across areas and when a problem arises I have found (in basically this one area only) ArbCom to be more agile at addressing it. But the community is also more willing to pass a GS than ArbCom is to designate something a CT (which I think is a good hting all around) and so having the community come to consensus about how, if at all, it wants to tie in to CT (and its evolutions) or if it would prefer to do its own thing (including just mirroring whatever happens to be in CT at the time but not subsequent changes) would probably be a good meta discussion to have. But it also doesn't seem necessary for this particular proposal. Best, Barkeep49 (talk) 17:41, 7 November 2024 (UTC)[reply]
Q3: If this proposal does not pass, should ECP be applied preemptively to articles under WP:ARBECR topics?
Support (preemptive ECP)
Support as a second option, but only to articles. Talk pages can be enforced solely through reverts and short protections so I see little reason why those should be protected. AwesomeAasim19:58, 5 November 2024 (UTC)[reply]
Support for articles per Aasim. Talk pages still need to be open for edit requests. (Also changing my mind, per above. If anything, we should clarify ARBECR so that the 500-30 limit is only applied in cases where it is needed, not automatically, to resolve the ambiguity. 20:52, 7 November 2024 (UTC)) Chaotic Enby (talk · contribs) 20:20, 5 November 2024 (UTC)[reply]
I agree with Chaotic Enby and Pppery above and think all CT articles should be protected. I am generally not a fan of protecting Talk pages, but it's true that many CT Talk pages are cesspools of hate, so I am not sure where I sit on protecting Talk pages. Toadspike[Talk]20:57, 5 November 2024 (UTC)[reply]
Under the current wording of ARBECR, When such a restriction is in effect in a topic area, only extended-confirmed editors may make edits related to the topic area. We should protect pages, rather than letting new editors edit and then reverting them for basically no reason. This is a waste of their time and very BITEy.
I am not opposed to changing the wording of ARBECR to forbid reverting solely because an editor is not extended confirmed, which is a silly reason to revert otherwise good edits. However, until ArbCom changes ARBECR, we are stuck with the rules we have. We ought to make these rules clear to editors before they edit, by page protection, instead of after they edit, by reversion. Toadspike[Talk]10:55, 16 November 2024 (UTC)[reply]
Support preemptive ECP without PCECP (for article space only). If we have a strict policy (or ArbCom ruling) that a class of user is forbidden to edit a class of page, there is no downside whatever to implementing that policy by technical means. All it does is stop prohibited edits. The consequences would all be positive, such as removing the need for constant monitoring, reducing IP vandalism to zero, and reducing the need to template new editors who haven't learned the rules yet. What I'd like with regard to the last one, is that a non-EC editor sees an "edit" button on an ECP page but clicking it diverts them to a page that explains EC and how to get it. Zerotalk05:53, 17 November 2024 (UTC)[reply]
Oppose (preemptive ECP)
Oppose because I think this is a bad idea. For one thing, just making a list of all the covered articles could produce disputes that we don't need. (This article might be covered, but is it truly covered? Reasonable people could easily disagree about whether some articles are "mostly" about the restricted area vs "partly", and therefore about whether the rule applies.) Second, where a serious and obvious problem, such as blatant vandalism, is concerned, it would be better to have an IP revert it than to mindlessly follow the rules. It is important to remember that our rules exist as a means to an end. We follow them because, and to the extent that, they help overall. We expect admins and other editors to exercise discretion. It is our policy that Wikipedia:If a rule prevents you from improving or maintaining Wikipedia, ignore it. This is a proposal to declare that the IAR policy never applies to the rule about who should normally be editing these articles, and that exercising discretion is not allowed. WhatamIdoing (talk) 20:42, 5 November 2024 (UTC)[reply]
I am neither Arb nor admin, but I think the words "broadly construed" are specifically chosen so that if a topic is "partly" about the restricted area, it is included in the CTOP. @WhatamIdoing, could you please show me an example of a case where CTOP designation or ECP was disputed? Toadspike[Talk]10:59, 16 November 2024 (UTC)[reply]
I avoid most of those articles, but consider "the entire set of Arab-Israeli conflict-related articles, broadly interpreted": Does that include BLPs who come from Israel/Palestine? What about BLPs who are in the news because of what they said about the Israel–Hamas war? IMO reasonable people could disagree about whether "every person living in the affected area" or "every person talking about the conflict" is part of "the entire set of Arab-Israeli conflict-related articles, broadly interpreted". WhatamIdoing (talk) 19:54, 16 November 2024 (UTC)[reply]
David Miller is what we call a "partial" Arbpia. So while it's a BLP in general, parts of it are subject to Arbpia/CT, not a particularly unusual situation. The talkpage and edit notices should, but don't always, tell you whether it is or isn't, part of. Selfstudier (talk) 20:59, 16 November 2024 (UTC)[reply]
IAR stands for IgnoreAllRules. The latter two cannot be claimed valid based on IgnoreAllRules because they don't have strong IgnoreAllRules arguments for what they did, not because IgnoreAllRules somehow only applies to content. Aaron Liu (talk) 16:07, 16 November 2024 (UTC)[reply]
I agree that "ignore all rules" applies to rules – including rules about behavior. ARBPIA is a rule about behavior. IAR therefore applies to ARBPIA.
Of course, if breaking the rule doesn't prove helpful to Wikipedia in some way, then no matter what type of rule it is, you shouldn't break the rule. We have a rule against bad grammar in articles, and you should not break that rule. But when two rules conflict – say, the style rule of "No bad grammar" and the behavioral rule of "No editing this ARBPIA article while logged out, even if it's because you're on a public computer and can't remember your password" – IAR says you can choose to ignore the rule that prevents you from improving Wikipedia. WhatamIdoing (talk) 21:34, 16 November 2024 (UTC)[reply]
While there's already precedent for preemptive protection at e.g. RFPP, I do not like this. For one, as talk pages (and, by extension, edit requests) cannot use the visual editor, this makes it much harder for newcomers to contribute edits, often unnecessarily on articles where there are no disruption. Aaron Liu (talk) 23:47, 5 November 2024 (UTC)[reply]
Mu - This is basically my reading of the 500/30 rule as writ. Anything that would fall into the 500/30'd topic should be XCP'd on discovery. It's worth noting I don't view this as anywhere close to ideal but then neither did ArbCom, and given the circumstances of the real-world ethnopolitical conflict only escalating as of late (which in turn feeds the disruption) the only other - even worse - option would be full-protection across the board everywhere in the area. So why am I not arguing Support? Because just like the question above, this is putting the cart before the horse and this is better off being discussed after this RfC ends, not same time as. —Jéské Courianov^_^vthreadscritiques02:47, 6 November 2024 (UTC)[reply]
Absolutely not, pages that do not experience disruption should be open to edit. Pending changes should never become widely used to avoid situations like dewiki's utterly absurd 53-day backlog. —Kusma (talk) 21:53, 6 November 2024 (UTC)[reply]
Very strong oppose, again Kusma puts it excellently. Protection should always be the exception, not the norm. Even in the Israel-Palestine topic area most articles do not experience disruption. Thryduulf (talk) 13:50, 7 November 2024 (UTC)[reply]
WP:RUNAWAY sums up some of the tactics used by disruptive editors: namely Their edits are limited to a small number of pages that very few people watch and Conversely, their edits may be distributed over a wide range of articles to make it less likely that any given user watches a sufficient number of affected articles to notice the disruptions. If a user is really insistent on pushing their agenda, they might not be able to push it on the big pages, they may push it on some of the smaller pages where their edits may get unwatched for months if not years. Then, researchers digging up information will come across the POV article and blindly cite it. Although Wikipedia should never be cited as a source, it still happens. AwesomeAasim14:35, 11 November 2024 (UTC)[reply]
Comment - The number of revisions within the PIA topic area that violate the ARBECR rule is not measured. It is not currently possible to say anything meaningful about the amount of 'disruption' in the topic area by non-EC IPs and accounts. And the way people estimate the amount of 'disruption' subjectively depends on the timescale they choose to measure it. Nobody can see all of the revisions and the number of people looking is small. Since the ARBECR rule was introduced around the start of 2020, there have been over 71,000 revisions by IPs to articles and talk pages within the subset of the PIA topic, about 11,000 pages, used to gather statistical data (ARBPIA templated articles and articles that are members of both wikiproject Israel and wikiproject Palestine). Nobody has any idea how many of those were constructive, how many were disruptive, how many involved ban-evading disposable accounts etc. And yet, this incomplete information situation apparently has little to no impact on the credence we all assign to our views about what would work best for the PIA topic area. I personally think it is better to dispense with non-evidence-based beliefs about the state of the topic area at any given time and simply let the servers enforce the rule as written in WP:ARBECR, "only extended-confirmed editors may make edits related to the topic area, subject to the following provisions...". Sean.hoyland (talk) 17:22, 16 November 2024 (UTC)[reply]
Make sense, but I am not sure if this is meant to be an oppose. Personally, since there hasn't been much big outrage not solved by a simple RfPP, anecdotally I see no problem with the status quo on this question. Aaron Liu (talk) 01:24, 17 November 2024 (UTC)[reply]
Since we're assuming that PCECP is possible and the last two questions definitely deal with policy, I feel like maybe this should go to VPP instead, with the header edited to something like "Extended-confirmed pending changes and preemptive protection in contentious topics" to reflect the slightly−larger-than-advertised scope? Aaron Liu (talk) 23:53, 5 November 2024 (UTC)[reply]
I think policy proposals are also okay here, though I see your point. There is definitely overlap, though. This is both a request for a technical change as well as establishing policy/guidelines around that technical change (or lack thereof). AwesomeAasim00:26, 6 November 2024 (UTC)[reply]
If this proposal is accepted, my assumption is that we'd bring back the ORANGELOCK which was used for the original incarnation of Pending Changes Level 2. There's a proposed lock already at File:Pending_Changes_Protected_Level_2.svg, though it needs fixes in terms of name (should probably be something like Pending-level-2-protection-shackle.png or Extended-pending-protection-shackle.png), SVG code (the top curve is a bit cut off), and color (should probably be darker but still clearly distinguishable from REDLOCK). —pythoncoder (talk | contribs)21:43, 8 November 2024 (UTC)[reply]
I think light blue is a better color for this. But in any case we will probably need a lock with a checkmark and the letter "E" for extended confirmed. AwesomeAasim22:22, 8 November 2024 (UTC)[reply]
I am actually starting to wonder if "protection" is a bit of a misnomer, because technically pages under pending changes are not really "protected". Yeah the edits are subject to review, but there are no technical measures to prevent a user from editing. It is just like recent changes on many wikis; those hold edits for review until they are approved, but they do not "protect" the entire wiki. AwesomeAasim23:40, 11 November 2024 (UTC)[reply]
Add AI translation option for translating from English to non-English article.
AI certainly improved a lot by now. It can translate to many non-english language better than traditional translators . My suggestion is to add AI translation option for translating from English to non-English article. User will review the AI translation to see if its correct. It will increase the translation quality. I dont suggest using AI for English article, that could have a devastating impact. Dark1618 (talk) 18:50, 7 November 2024 (UTC)[reply]
That's out of scope here, and would need to be asked on each and every individual language-edition of Wikipedia, as those would be the ones dictating policy for translations into their respective languages. —Jéské Courianov^_^vthreadscritiques19:10, 7 November 2024 (UTC)[reply]
Why would a translation into English be devastating, but a translation from English into any other language be acceptable? English just happens to be that most used language in the world by some measures: beyond that it has no special status. Anyway, we can not decide here what is appropriate for other language Wikipedias. Phil Bridger (talk) 19:33, 7 November 2024 (UTC)[reply]
Good Idea! That’s actually what I was going to propose but you took it. To add to your amazing proposal, I suggest that every wiki translation must be approved by a speaker. Like If someone translated an article from English to Arabic, the translated article goes to an Arab speaker, by algorithm when the person would press a button that says “send for approval” or something like that, and the Arab person who gets the translated article will read the Wikipedia page and look for any errors, then the Arab corrects it and it gets published to the world. And why can’t the opposite happen, when an article gets translated to say french To English the same thing happens the French person machine translates the article, it gets sent to approval, a fluent English speaker goes and corrects it, then it gets published. If it is an extinct language, a person who is a professional in the language will correct it, and as for rates, I mean Wikipedia has at least 1 person who knows the language. Anyway have a good day! Cheers! Datawikiperson (talk) 10:10, 10 November 2024 (UTC)[reply]
I'm not sure of the technical backend for that tool, but I do see at English Wikipedia a constant inflow of articles translated from sister projects, usually without proper attribution, sometimes with broken templates.Some of these translations are pretty good, up to idiomatic phrasing; others have the appearance of raw machine translation, with errors no one fluent in the target language would leave in.As to the original proposal / idea, a flow of machine translations from this project to sister Wikipediae, that is indeed out of scope here, and would have to be brought up individually at each language project. Except maybe Cebuano Wikipedia. Folly Mox (talk) 14:49, 10 November 2024 (UTC)[reply]
I occasionally translate from English to Chinese and vice versa, and take on some bits from Japanese and Korea projects to be translated on to here if the information and sources can be used on here. And I strongly discourage automated AI translations from English to other languages, which you are proposing, without further inputs from the targeted language projects. AI translations to other languages from English are not perfect and can have the same devastating impact you don't want to see on English Wikipedia. – robertsky (talk) 14:30, 11 November 2024 (UTC)[reply]
Machine translation from English to most other languages is already enabled (and where it isn't it is a choice of the to project, not of the English Wikipedia). I don't think there is anything for us to do about this proposal? — xaosfluxTalk10:33, 16 November 2024 (UTC)[reply]
Authors should provide size of objects
The cliche is “Size doesn’t matter," but it does in many things — paintings, sculptures, jewelry, crystals, anything larger or small than usual and even if it’s the usual size if readers don’t know what that it. It makes a difference if a painting is 2” by 3” or 2’ by 3’. Especially in TPOD, because more people will see it, but really everywhere. I suggest that writers be encouraged to provide the relevant size in the text or caption of every photo where it’s necessary and that the editors working on TPOD be strongly encouraged to give the size whenever possible. If the size is not given in the text being referenced, that information is often in the photo's "details," in addition to the editing history. Wis2fan (talk) 04:51, 9 November 2024 (UTC)[reply]
Firstly, excuse my ignorance, but what is TPOD? Secondly, I don't see any clear proposal here. Yes, size is often important, but what do you think we should do about it? We can cajole editors into providing size, but we shouldn't reject images without it. Phil Bridger (talk) 13:48, 9 November 2024 (UTC)[reply]
Sorry I got the abbreviation wrong — POTD. Today’s (11/10/2024) POTD is an example of what I’m talking about. The reader knows a bark beetle is tiny, but why not give the actual size? It’s not that the information isn’t available. I clicked on the photo, then on "details." The description of the photo says the adult male is 4.0 mm to 5.5 mm long. I came back to the post and clicked on the name. The linked article includes the same information. The information is there this time. I agree, it’s not always either place. But when it is, it should be provided to be complete. Wis2fan (talk) 04:54, 10 November 2024 (UTC)[reply]
A picture caption is finite, it does not need to (and indeed in most cases cannot) include every detail about an image and its subject. Therefore it should only include information that is most relevant, and that will not always include the size. For example the POTD for 8 November was an 1860 photograph of John Tarleton (Royal Navy officer), is the size of the print really the most relevant information or is it the size of the subject what you want to know? It's fine to encourage people to put the size of the image and/or subject in the caption where that is relevant, but it is not always going to be, so a one-size-fits all rule is not going to be appropriate. If you want to know, just look at the extra details. Thryduulf (talk) 14:37, 10 November 2024 (UTC)[reply]
Thryduulf is absolutely correct, the size of the object in a photo is unimportant when it is a human. The size isn’t necessary for today’s POTD (11/11/2024). But I still think it is important when it is a bark beatle. And many other things. I also think that a writer should anticipate a reader’s questions and provide the answers. Suggesting that if a reader wants the size of an object they should look at the extra details is not helpful. I’d bet most readers don’t know how to find them. Wis2fan (talk) 04:29, 11 November 2024 (UTC)[reply]
I vaguely remember I suggested something similar at commons once, requesting that more people who post photos consider including a scale-bar if it's the sort of subject that would benefit from one (biological specimens, museum artefacts whose size is likely to be unclear to a general reader). I think I got shot down in flames for general naivete. My opinion is: In any situation where a reference book would use a scale bar, or indicate prominently by caption or other means, the size of an illustrated object, we should do the same, so far as we can. This would probably include articles about most species (birds, insects etc.) and articles about things where the size is central to the article (an article on miniaturisation of transistors, for example, should show the size of the transistors in its photos). Elemimele (talk) 13:52, 12 November 2024 (UTC)[reply]
Artist collective infobox
Hello! I have made an infobox for artist collectives (inspired by my own frustration trying to use the regular artist one for graffiti crews) and would like feedback from the community before publishing it. The old infobox proposal page is now defunct and suggests posting here instead.
Personally, I'd much rather not see this, or anything like it, used. Almost everything in it will be disputable or disputed, or is really vague. It seems a classic example of where an infobox is just unhelpful clutter, and will displace or make too small an image that would be more helpful. Are you asking at the VA project, & if not, why not? It's not really for here. Johnbod (talk) 05:03, 12 November 2024 (UTC)[reply]
Heya, I noticed a couple of weeks ago that while interface administrators and central notice administrators need 2FA, bureaucrats, who can grant interface admin don't need 2FA. To me this seems a bit weird, because if you wanted to compromise an account with access to interface admin tools, bureaucrats may not all have 2FA. Hence, I'm proposing requiring all enwiki bureaucrats to enable 2FA as a precaution. Zippybonzo | talk | contribs (they/them) 09:24, 12 November 2024 (UTC)[reply]
I see non-restricted adjacent bugs T242553 and T242556 were both created on 12 Jan 2020. Would it be accurate to describe this as an evaluation which has been unresolved for about 5 years? -- zzuuzz(talk)13:58, 12 November 2024 (UTC)[reply]
Support per pppery and zippybonzo - should be a requirement locally. Waiting for phab tickets could take years while I imagine a RFC would pass pretty quickly. BugGhost🦗👻19:44, 12 November 2024 (UTC)[reply]
The fact that 'crats can assign interface admin (a role which requires 2FA) but are not required to have 2FA personally enabled is wild. Support a local rule (and hopefully the largest WMF project implementing such a rule will encourage others to make such a change). HouseBlaster (talk • he/they) 00:43, 15 November 2024 (UTC)[reply]
Definite support. I am personally in favor of a 2FA requirement for any privileged group, but it is something I doubt will happen anytime soon. Crats should absolutely have it enabled. EggRoll97(talk) 01:51, 15 November 2024 (UTC)[reply]
Question. How are you going to check whether the user enabled 2FA or not? This information is not public. Only WMF can confirm this. Ruslik_Zero20:02, 15 November 2024 (UTC)[reply]
Yes, stewards can check this, and we periodically audit this for compliance on projects. Also, 'crats will very likely soon be able to check this as well - just some paperwork in that way right now (primarily so they can check it before assigning intadmin to others). — xaosfluxTalk10:29, 16 November 2024 (UTC)[reply]
Oppose, because the last time I checked, WMF's self-developed version of 2FA was not really fit for purpose. It's not like they're using Duo or Google or something. If anything, I'd support removing it from the roles requiring it now. --Floquenbeam (talk) 20:16, 15 November 2024 (UTC)[reply]
It works OK, but is certainly not ready for large-scale deployment due to the support model and capacity. Staff is generally responsive to recovery requests for those that WMF requires enrollment though. — xaosfluxTalk10:30, 16 November 2024 (UTC)[reply]
Support in theory - I use 2FA as a crat. Makes all the sense to me. As Xaos says above it's not ideal how it's setup. If it was just a "should this user group use 2FA", then I think yes. And, I'd argue administrators should as well. I can't support the technical solution we currently have being rolled out further without more Dev time. Lee Vilenski(talk • contribs)13:37, 16 November 2024 (UTC)[reply]
Support now. This is an security oversight. Regardless of the issues with WMF's 2FA this is still a flaw in the current security model since an attacker could gain interface admin without bypassing 2FA Chess (talk) (please mention me on reply)00:44, 19 November 2024 (UTC)[reply]
Oppose per Floq, plus it's not clear how we're enforcing this: either we're revoking permissions (in which case several crats will lose the bit on inactivity alone) or we're not (in which case we're no more secure than before). A much better solution would be to just put the stewards in charge of adding/removing intadmin. Extraordinary Writ (talk) 06:13, 21 November 2024 (UTC)[reply]
RfC: Should a blackout be organized in protest of the Wikimedia Foundation's actions?
I think we should have infoboxes for rituals and cultural practices, as studied in anthropology and religious studies. Parameters like associated culture, associated religion, purpose, origin, place, whether or not it is extinct, and when it is observed could be included. Examples of articles that could benefit are Akazehe, Savika, Sikidy, Haka, Bar Mitzvah, Quinceañera, Nggàm, and Hajj. ꧁Zanahary꧂19:17, 14 November 2024 (UTC)[reply]
I agree, there’s not really enough fields they’d have in common. Although I personally believe that every article that has an applicable infobox should use it, there’s also many articles that work best without them. novovtalkedits10:38, 15 November 2024 (UTC)[reply]
Yes, infoboxes work best when there are a number of basic uncontroversial factual characteristics that are shared by a group of articles. That's very far from the case here. Johnbod (talk) 14:06, 15 November 2024 (UTC)[reply]
@Lee Vilenski Even the most diehard of infobox supporters recognise that infoboxes don't work on every page (broad, abstract concepts like Love and Existence for example) and that is one reason why we don't have (and never will have) any requirement for every article to have an infobox. That doesn't in any way preclude setting a policy that specific subsets of articles where they are uncontroversially useful (e.g. countries and NFL teams) must have an infobox if we wanted to. Some of the types of articles mentioned could have useful infoboxes (Hajj already does for example) not all of them can, so the OP's suggestion would not be a good set for such a policy, but that's not an argument against any set being appropriate. Thryduulf (talk) 20:58, 16 November 2024 (UTC)[reply]
A recent attempt to impose an all-infobox policy failed emphatically, reinforcing the long-standing position the they are not compulsory. And in many areas, the approach using a specific template will not be suitable, for the reasons I gave above. If many "helpful" editors see a template with blank fields, they will attempt to fill them, regardless of appropriateness. Johnbod (talk) 17:22, 17 November 2024 (UTC)[reply]
In re "editors see a template with blank fields, they will attempt to fill them": I think I see less of that these days than I used to. I'm not sure why (infoboxes are less empty? Fewer stray fields are listed? The visual editor hides the 'missing' lines from new editors? I dunno, but it's been a long while since I noticed someone filling in all the blanks on any article in my watchlist.) WhatamIdoing (talk) 00:43, 18 November 2024 (UTC)[reply]
Possibly. Or even if they're not filled in the wikitext, I think there's a certain amount of content that feels "normal", and if it displays some low but still normal-ish amount when reading, then people don't think that something's missing, so they don't try to "improve" it. WhatamIdoing (talk) 01:48, 18 November 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.
I propose that extended confirmed users should be allowed to get users from the IP address that they are currently logged onto because to see and disclose on Template:User shared IP address. Extended confirmed users are trusted (30 days and 500 edits) and the CheckUsers can see the log to see who's outing. 1.144.109.84 (talk) 21:08, 15 November 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Proposal to update WP:NBAND to be explicitly constrained by WP:GNG
A single discussion where somebody argues something that does not gain consensus is not evidence of a problem, let alone evidence that the proposed change would solve that problem. Thryduulf (talk) 16:26, 18 November 2024 (UTC)[reply]
This is a feature, not a bug; "or" does not mean "and". That WP:BAND currently circumvents WP:GNG is either trivially true (as creating subject-specific notability guidance outside of the GNG is the whole point of a WP:SNG) or arises from a fundamental misunderstanding of the purpose of the subject-specific notability guidelines. — Red-tailed hawk(nest)16:50, 19 November 2024 (UTC)[reply]
or arises from a fundamental misunderstanding of the purpose of the subject-specific notability guidelines. That might actually be what is at issue - there seem to be two different understandings of what SNG's are - supporting GNG or an alternative to it.--3family6 (Talk to me | See what I have done) 18:17, 19 November 2024 (UTC)[reply]
I posted this in the other village pump thread, but while I'm generally fine with this proposal, I don't think it's coming from a place of understanding.
Basically, there's an assumption happening that record labels work off some kind of predictable tier system, where the Big 3 labels are home to the most famous artists, indie labels are home to the semi-famous ones, and everyone else is a non-notable bottom feeder. That's not how it works. One of the more notable albums of the year is Cindy Lee's Diamond Jubilee, which was self-released. Meanwhile, there are artists on the Big 3 who I would guess probably don't have significant coverage. This is because music journalism is dying, no one has staff and no one has money, and the range of artists being covered has shrunk dramatically. See this Columbia Journalism Review article for further on that.
So in other words, I don't think criterion 5 in NBAND is good or useful, but for the opposite reasons that this proposal suggests. The problem is not that people's random garage bands will be considered a "label." The problem is there is less and less correlation between being signed to a label and having significant coverage. (Ironically, the "albums" criterion is probably the more stringent one, because labels are less and less likely to put out a full-length album by an artist that isn't already established via singles and streaming tracks.)
I don't know what to do with that. (I honestly think the collapse of journalism and the shrinking scope of what gets reported on is a ticking time bomb for notability criteria across the board, but that's a whole other topic.) The most straightforward solution is to use WP:GNG, but I think it's important to have a correct understanding of exactly what musicians we're talking about here. The bar is way, way, way higher than "run of the mill non-notable items" now. The bar is one or two tiers below Sabrina Carpenter. Gnomingstuff (talk) 21:26, 19 November 2024 (UTC)[reply]
Addendum: One way that this criterion could have value is to serve as a reminder that one Google search is not a sufficient WP:BEFORE check, because artists on notable labels are likely to have received coverage in print. (Another way this proposal is misinformed
I'd love to make BEFORE specifically include looking where sources are most likely to be found and explicitly state that looking at the first few pages of Google do not constitute a proper check. This always gets shot down in howls of protest at how dare I require people nominating pages for deletion to do more work than they imagine it took to create a three line sub-stub. I don't know how we get past this. Thryduulf (talk) 21:45, 19 November 2024 (UTC)[reply]
I mean, it already does: The minimum search expected is a normal Google search, a Google Books search, a Google News search, and a Google News archive search; Google Scholar is suggested for academic subjects. The problem is that WP:BEFORE is not considered binding so there are no consequences to ignoring it. Gnomingstuff (talk) 21:51, 19 November 2024 (UTC)[reply]
Your proposal operatively eliminates the SNG for bands. And also creates an even tougher GNG requirement than GNG by requiring that GNG compliance be demonstrated. I would like there to be some at least partial demonstration requirement added to GNG, but that's a whole 'nother issue and a secondary one in this case.
It also sort of misses the main point discussed at the linked pump discussion which was eliminating one or two items / "ways in" in the SNG.Sincerely, North8000 (talk) 18:04, 18 November 2024 (UTC)[reply]
in line with this, NBAND can be eeaily fixed to makes sure that the idea that the criteria are a presumption of notability is added. I do not see any language like this though the intent seems to be there. That would quickly resolve one conflict. Mind you, deprecating or time gating criteria that do not make sense in modern music distribution is also a reasonable step though I would not remove them outright for historical purposes. Masem (t) 19:02, 18 November 2024 (UTC)[reply]
I was amazed by how much our guidelines were written with Western popular musicians in mind when I started editing 17 years ago and it seems that nothing has changed since. It is so much easier for such a person to have an article about them than for other types or nationalities of musician. This is so obviously caused by Wikipedia's demographics that I hesitate to say anything further. Phil Bridger (talk) 19:18, 18 November 2024 (UTC)[reply]
I wonder what effect imposing GNG would have on that. I've heard from some African editors that much of the real news for music and pop culture is posted on social media (i.e., actually posted on Facebook itself, not some website that's sorta kinda social media-like). So if you take away an objective but non-source-oriented criteria and substitute 'must have the kind of sources that are usual enough in the US and UK but are unusual in Nigeria', will that tip even further towards overrepresenting Western popular musicians?
My impression of the two albums/two films kinds of rules from back in the day is that the advice had more to do with WP:Build the web than with writing full articles. The expectation was that (if there weren't significant sources to justify writing more), the articles would usually be very brief ("Joe Film is an American actor who appeared in Film and Example" or "The Band is a British band who released Album in 1998 and Cover album in 2001") but that we'd still be able to provide non-red links in related pages and still not have to duplicate information. Consequently, I think the traditional thinking is closer to how we think of spinning off a list or splitting a long article, than about trying to justify the subject as "worthy" of a full, stand-alone article via extensive sourcing.
I could imagine people opposing this merely for fear of the resulting red links, and of course the idea of going beyond the GNG to require "demonstrating" it will turn off other editors. WhatamIdoing (talk) 19:36, 18 November 2024 (UTC)[reply]
If it is established that reliable third party sources covering African music are going to include posts on social media rather than print or web publishing, then we should work to accomodate that so that we are more inclusive, rather than expect the more traditional forms of media. Masem (t) 20:05, 18 November 2024 (UTC)[reply]
speaking for myself, I never had issues with using a third party posting via something like Facebook. I've always considered that to be a statement by that third party, they're just using Facebook as the medium. Am I understanding this example correctly?--3family6 (Talk to me | See what I have done) 20:18, 18 November 2024 (UTC)[reply]
A statement by the band('s representatives) on the band's official facebook page is no more user-generated content and no less reliable than if that same statement was made by the same people was posted on the band's official website or quoted verbatim in a newspaper. Thryduulf (talk) 20:55, 18 November 2024 (UTC)[reply]
Yes, Thryduulf, that's partly what I'm referring to. Schazjmd, I am indeed familiar with that guideline. In fact, my first edit on Wikipedia was removing content that I had generated as a user on another site. I'm referring to established media outlets posting something on Facebook. Like, say, Salon posted a story on Facebook rather than on their official site. It's gone through an editorial process, they just are using Facebook as a publishing medium.--3family6 (Talk to me | See what I have done) 21:00, 18 November 2024 (UTC)[reply]
There isn't a wiki-requirement for the type of source that sources used, or even that they have sources. Of course such things still matter regarding regarding actual/ real world reliability of of the source. North8000 (talk) 21:36, 18 November 2024 (UTC)[reply]
So keeping in mind that I have never had a Facebook account and have no experience with social media, my impression from these editors was that when they say they get news on Facebook, it's not necessarily the band that's posting (which wouldn't be Wikipedia:Independent sources) or even news articles being shared. Instead, it could be an ordinary comment by someone whom their followers believe is knowledgeable but who is not necessarily "official". For example – and I completely make this example up; the African editors who told me about this dilemma two years ago are welcome to disavow and correct anything I say – imagine a post by a professional DJ: They'll know things about music and bands, and they'll probably know more than a magazine writer assigned to do a piece on pop music in that city/country. They are "reliable" in the sense that people "rely on" them every day of the year. But it's outside the kinds of formal structures that we use to evaluate official sources: no editor, no publisher, no fact-checker, no peer review, etc. WhatamIdoing (talk) 05:33, 20 November 2024 (UTC)[reply]
Comment I am interpreting this section as an RfCBEFORE, and contributing in that spirit.
Having briefly reviewed the linked discussions, I do not see a problem with NBAND itself that would justify deprecation (rather than revision). And turning NBAND into a predictor of GNG rather than a standalone SNG seems to me essentially akin to deprecation. Fixing specific criteria seems much more appropriate to me, given the issues raised to date.
There are what seem to me to be evident reasons why NBAND operates according to the same logic as NCREATIVE, which is explicitly excluded from WP:NOTINHERITED. These SNGs reflect the reality that creative people produce creative works, and that therefore the people creating those works gain encyclopedic relevance directly from having created them.
In addition, it seems to me that there are practical, navigational reasons (having to do with the affordances of hypertext, Wikipedia's list system, and Wikipedia's category system) to offer more consistent treatment rather than leaving each individual musician, each musical group and each album up to the vagaries of WP:NBASIC, WP:NORG and the WP:GNG.
There may be problems with specific NBAND criteria and the way they are sometimes used at AfD, but it seems entirely incommensurate to deprecate the whole SNG based on such marginal concerns. Newimpartial (talk) 20:31, 18 November 2024 (UTC)[reply]
IMO the Wikipedia norm for a "just barely made it" band has sourcing that meets a slightly lenient interpretation of GNG, and the decision is influenced by somewhat meeting an SNG criteria, thus being more conducive to artists than for example a for-profit corporation. And the "norm" means that is is how Wikipedia as a whole wants it. There are folks out there who are at the extreme deletionist end of the spectrum and they will typically say that the above is not the case and piece together an unusually strignent "letter of the law" demand, even adding some things from essays saying that three sources that 100% meet GNG is the expectation. And so while I really think that the burden should shift to providing some GNG-ish sources (vs. just saying "they are out there" without actually supplying any) I'm loath to shift the balance too much, keeping the folks at the deletionist end of the spectrum in mind.
The pump discussion started with talking about how being signed by a label is no longer as indicative as it used to be and to remove it as being a key to the city of SNG compliance. I think there was support for that.
I agree with everyone else above that this proposal would gut WP:BAND, which I am not okay with. If you want to remove some criteria of WP:BAND, like #5, which I agree is a little opaque and outdated, fine. But this seems like a sneaky way of demolishing WP:BAND without openly saying so. Toadspike[Talk]21:36, 18 November 2024 (UTC)[reply]
I like the point North made, that our notability rules are set up to be more conducive to artists than for example a for-profit corporation. I've never thought of our guidelines on artists as particularly lax, but I know that NCORP is purposely stringent and that is the way things should be. Toadspike[Talk]21:41, 18 November 2024 (UTC)[reply]
I'm not disappointed at the consensus emerging here, and hopefully it might help clarify discussions. there does seem to be some consensus to ditch criterion 5. I'm happy to amend it to that particular criterion disappearing and everything else stays.--3family6 (Talk to me | See what I have done) 21:48, 18 November 2024 (UTC)[reply]
I wonder if the most practical thing with criterion 5 (the one about releasing two albums on a label) would be to give it an end date. It was a useful criterion in the pre-streaming music world, so why not say "two albums on a label before 2010", or at whatever point editors decide that labels became less relevant? WhatamIdoing (talk) 16:42, 19 November 2024 (UTC)[reply]
I think this is a good idea but the cutoff should be earlier. The iTunes music store was founded in 2003, Spotify was founded in 2006, sometime around there would make more sense. Gnomingstuff (talk) 21:39, 19 November 2024 (UTC)[reply]
Yeah, why not; I didn't really see the point back then, I'm not sure, honestly, that I do now, but enough people have said it's useful work that who am I to deny it? And Graham87's obviously both good at it and committed to it. Support this proposal. SerialNumber5412912:42, 20 November 2024 (UTC)[reply]
(edit conflict) Support. Importers are editors who are highly trusted to undertake a very specialised role and it makes sense that they be given the rights needed to fully do the job properly. Thryduulf (talk) 13:09, 20 November 2024 (UTC)[reply]
Support obviously – thanks, wow, did not expect this and I didn't know this would be feasible. As I said at my RRFA, I have my own issues with this tool (which explain why I didn't use it so much), but access to it is way better than no history-merge access at all. Graham87 (talk) 13:25, 20 November 2024 (UTC)[reply]
Support if technically feasible. I really opposed the RRFA because Graham87 was asking for a role we didn't have. If they can do their importing/merging work without being able to block users, I would support that. (Normally I wouldn't support a one-off solution like this but, given the rareness of this, I think it makes sense here.) Note that I would also favor further unbundling admin powers beyond this nom. - RevelationDirect (talk) 13:35, 20 November 2024 (UTC)[reply]
Support sure. This is super niche, but basically: if someone can be trusted to be able to do an xmlimport, this is related and much less dangerous. If we're going to touch it I'm find also adding it to transwiki importers as well (even though we don't have any currenty) for parity. transwiki import is less dangerous, and most of the WP:RFPI items are able to be done that way -- in case any non-admins were looking to work in that area. — xaosfluxTalk13:44, 20 November 2024 (UTC)[reply]
Support If somebody is a importer, they can be trusted with not messing up the databases any further while apply (merge-history). Sohom (talk) 13:58, 20 November 2024 (UTC)[reply]
Support. This seems like a bit of an exceptional case, but I do think that it's worthwhile to allow importers to merge histories for practical reasons. And the role is so restricted that I don't have trust issues here. — Red-tailed hawk(nest)15:53, 20 November 2024 (UTC)[reply]
I got to support Graham's importer request once upon a time. Pleased to support this request as well. Even setting aside the direct impetus, this is a logical bundling of the tools that does not raise the required trust level for this small user group. -- Tamzin[cetacean needed] (they|xe) 17:53, 20 November 2024 (UTC)[reply]
Because importing is importing a bunch of revisions into the history of the page. It's quite similar and often needed. Those two users are the only ones who maintain this area critical to Wikipedia, and that's the system, which has persisted due to their being able to merge history; now that Graham's been stripped of history merging, half of his duty and thus a quarter of this system, we need to rectify it or risk destabilizing of the system. Aaron Liu (talk) 16:37, 20 November 2024 (UTC)[reply]
The system is only two people doing this work, and we're otherwise taking away half of what one of them does. I don't see any reason not to do this. Aaron Liu (talk) 20:36, 20 November 2024 (UTC)[reply]
@RevelationDirect yes, criteria is basically a user-specific RFC. This is a super niche area; though I'd be open to expanding this permission to the less dangersour transwiki-importer group -- which also requires a per-user rfc to add too, but with a lower bar to entry. — xaosfluxTalk13:46, 20 November 2024 (UTC)[reply]
@Graham87: Since the topic has come up, I've actually wanted to jump into importing for a while (I'll be quite honest, probably transwiki importing, given it seems like a better place to start out at than XML import), but how does one really get into that line of work? I presume the common answer would probably be the direction of WP:RFA, but that seems like a bit much given a right already exists that is outside of the sysop group. EggRoll97(talk) 20:54, 20 November 2024 (UTC)[reply]
It is, and no. The only way we can assign permissions is to add the permissions to a group, then users can be added to the group. It would be possible to create an entirely new group that has this permission - but that seems overkill here unless it was going to do a whole lot more (like a "technician" group that had a bunch of other sub-admin permissions). — xaosfluxTalk13:49, 20 November 2024 (UTC)[reply]
@Compassionate727 those are certainly case-by-case. Sometimes historymerge is the right tool for the job. Any complicated merge/imports that require deletion are going to have to be handled by admins unless we want to make some new sub-admin technician group in the future (the community has repeatedly rejected such proposals though) which could have extra tools (like delete/undelete and others) but only be permitted to use them for certain purposes. — xaosfluxTalk14:09, 20 November 2024 (UTC)[reply]
Graham believes that the MergeHistory tool is inferior simply because it doesn't log a merge on the target page. I see no problem with this view. Aaron Liu (talk) 14:11, 20 November 2024 (UTC)[reply]
When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.
Currently, there are open phabtickets proposing that the use of the HistMerge tool be logged at the target article in addition to the source article. Several proposals have been made:
Option 1a: When using Special:MergeHistory, a null edit should be placed in both the merge target and merge source's page's histories stating that a history merge took place.
Option 1b: When using Special:MergeHistory, add a a log entry recorded for the articles at the both HistMerge target and source that records the existence of a history merge.
Option 2: Do not log the use of the Special:MergeHistory tool at the merge target, maintaining the current status quo.
Should the use of the HistMerge tool be explicitly logged? If so, should the use be logged via an entry in the page history or should it instead be held in a dedicated log? — Red-tailed hawk(nest)15:51, 20 November 2024 (UTC)[reply]
Option 1a/b. I am in principle in support of adding this logging functionality, since people don't typically have access to the source article title (where the histmerge is currently logged) when viewing an article in the wild. There have been several times I can think of when I've been going diff hunting or browsing page history and where some explicit note of a histmerge having occurred would have been useful. As for whether this is logged directly in the page history (as is done currently with page protection) or if this is merely in a separate log file, I don't have particularly strong feelings, but I do think that adding functionality to log histmerges at the target article would improve clarity in page histories. — Red-tailed hawk(nest)15:51, 20 November 2024 (UTC)[reply]
Option 1a/b. No strong feelings on which way is best (I'll let the experienced histmergers comment on this), but logging a history merge definitely seems like a useful feature. Chaotic Enby (talk · contribs) 16:02, 20 November 2024 (UTC)[reply]
1b would be most important to me but but 1a would be nice too. But this is really not the place for this sort of discussion, as noted below. Graham87 (talk) 16:28, 20 November 2024 (UTC)[reply]
Option 2 History merging done right should be seamless, leaving the page indistinguishable from if the copy-paste move being repaired had never happened. Adding extra annotations everywhere runs counter to that goal. Prefer 1b to 1a if we have to do one of them, as the extra null edits could easily interfere with the history merge being done in more complicated situations. * Pppery *it has begun...16:49, 20 November 2024 (UTC)[reply]
Could you expound on why they should be indistinguishable? I don't see how this could harm any utility. A log action at the target page would not show up in the history anyways, and a null edit would have no effect on comparing revisions. Aaron Liu (talk) 17:29, 20 November 2024 (UTC)[reply]
2 History merges are already logged, so this survey name is somewhat off the mark. As someone who does this work: I do not think these should be displayed at either location. It would cause a lot of noise in history pages that people probably would not fundamentally understand (2 revisions for "please process this" and "remove tag" and a 3rd revision for the suggested log), and it would be "out of order" in that you will have merged a bunch of revisions but none of those revisions would be nearby the entry in the history page itself. I also find protections noisy in this way as well, and when moves end up causing a need for history merging, you end up with doubled move entries in the merged history, which also is confusing. Adding history merges to that case? No thanks. History merges are more like deletions and undeletions, which already do not add displayed content to the history view. Izno (talk) 16:54, 20 November 2024 (UTC)[reply]
They presently are logged, but only at the source article. Take for example this entry. When I search for the merge target, I get nothing. It's only when I search the merge source that I'm able to get a result, but there isn't a way to know the merge source.
If I don't know when or if the histmerge took place, and I don't know what article the history was merged from, I'd have to look through the entirety of the merge log manually to figure that out—and that's suboptimal. — Red-tailed hawk(nest)17:05, 20 November 2024 (UTC)[reply]
... Page moves do the same thing, only log the move source. Yet this is not seen as an issue? :)
But ignoring that, why is it valuable to know this information? What do you gain? And is what you gain actually valuable to your end objective? For example, let's take your There have been several times I can think of when I've been going diff hunting or browsing page history and where some explicit note of a histmerge having occurred would have been useful. Is not the revisions left behind in the page history by both the person requesting and the person performing the histmerge not enough (see {{histmerge}})? There are history merges done that don't have that request format such as the WikiProject history merge format, but those are almost always ancient revisions, so what are you gaining there? And where they are not ancient revisions, they are trivial kinds of the form "draft x -> page y, I hate that I even had to interact with this history merge it was so trivial (but also these are great because I don't have to spend significant time on them)". Izno (talk) 17:32, 20 November 2024 (UTC)[reply]
... Page moves do the same thing, only log the move source. Yet this is not seen as an issue? :)
Page moves do leave a null edit on the page that describes where the page was moved from and was moved to. And it's easy to work backwards from there to figure out the page move history. The same cannot be said of the Special:MergeHistory tool, which doesn't make it easy to re-construct what the heck went on unless we start diving naïvely through the logs. — Red-tailed hawk(nest)17:50, 20 November 2024 (UTC)[reply]
It can be *possible* to find the original history merge source page without looking through the merge log, but the method for doing so is very brittle and extremeley hacky. Basically, look for redirects to the page using "What links here", and find the redirect whose first edit has an unusual byte difference. This relies on the redirect being stable and not deleted or retargetted. There is also another way that relies on byte difference bugs as described in the above-linked discussion by wbm1058. Both of those are ... particularly awful. Graham87 (talk) 03:48, 21 November 2024 (UTC)[reply]
In the given example, the history-merge occurred here. Your "log" is the edit summaries. "Created page with '..." is the edit summary left by a normal page creation. But wait, there is page history before the edit that created the page. How did it get there? Hmm, the previous edit summary "Declining submission: v - Submission is improperly sourced (AFCH)" tips you off to look for the same title in draft: namespace. Voila! Anyone looking for help with understanding a particular merge may ask me and I'll probably be able to figure it out for you. – wbm1058 (talk) 05:51, 21 November 2024 (UTC)[reply]
Support 1b (log only), oppose 1a (null edit). I defer to the experienced histmergers on this, and if they say that adding null edits everywhere would be inconvenient, I believe them. However, I haven't seen any arguments against logging the histmerge at both articles, so I'll support it as a sensible idea. (On a similar note, it bothers me that page moves are only logged at one title, not both.) Toadspike[Talk]17:10, 20 November 2024 (UTC)[reply]
Option 2. The merges are already logged, so there’s no reason to add it to page histories. While it may be useful for habitual editors, it will just confuse readers who are looking for an old revision and occasional editors. Ships & Space(Edits)18:33, 20 November 2024 (UTC)[reply]
But only the source page is logged as the "target". IIRC it currently can be a bit hard to find out when and who merged history into a page if you don't know the source page and the mergeperson didn't leave any editing indication that they merged something. Aaron Liu (talk) 18:40, 20 November 2024 (UTC)[reply]
1B. The present situation of the action being only logged at one page is confusing and unhelpful. But so would be injecting null-edits all over the place. — SMcCandlish☏¢ 😼 01:38, 21 November 2024 (UTC)[reply]
Option 2. This exercise is dependent on finding a volunteer MediaWiki developer willing to work on this. Good luck with that. Maybe you'll find one a decade from now. – wbm1058 (talk) 05:51, 21 November 2024 (UTC)[reply]
And, more importantly, someone in the MediaWiki group to review it. I suspect there are many people, possibly including myself, who would code this if they didn't think they were wasting their time shuffling things from one queue to another. * Pppery *it has begun...06:03, 21 November 2024 (UTC)[reply]
I'm noticing some commentary in the above RfC (on widening importer rights) as to whether or not this might be useful going forward. I do think that having the community weigh in one way or another here would be helpful in terms of deciding whether or not this functionality is worth building. — Red-tailed hawk(nest)15:51, 20 November 2024 (UTC)[reply]
Idea to reduce issue with user pages being used for hosting a vanity page or advertisement
Some of the recent discussion on AN/I regarding Fastily and U5 closures centered on the challenges of properly addressing misuse of user pages. I believe the high volume of apparent misuse is causing difficulty in balancing protecting Wikipedia and taking due care in deletions. Anything that would reduce misuse (or reduce the consequences of misuse) should help relieve some of the pressure.
Thus my half-baked proposal below. The goal of this proposal is to reduce the attractiveness of putting up fake Wikipedia pages and holding yourself out to the world as having a page about you.
Proposal
The primary user page will automatically have the output of {{User page}} displayed at the top. Once a user becomes extended confirmed, they will have the ability to suppress display of the template. Extended confirmed users who abuse this by making an inappropriate user page can have the right to suppress display taken away by an admin. When first enacting this change, all current extended confirmed users will have the display suppressed, though they can enable the display if desired.
This is a Wikipediauser page. This is not an encyclopedia article or the talk page for an encyclopedia article. If you find this page on any site other than Wikipedia, you are viewing a mirror site. Be aware that the page may be outdated and that the user whom this page is about may have no personal affiliation with any site other than Wikipedia. The original page is located at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(all).
Above is the output of the template, for those unfamiliar with it.
That could be a good idea. For new users who might not know it, a message could also be added to inform them that drafts should ideally not be written on their main userpage, with a link to automatically move it to their user sandbox. Chaotic Enby (talk · contribs) 20:16, 5 November 2024 (UTC)[reply]
I don't have any objection to this in principle. I think the application of this is likely to get pretty hairy, though. And I think most people write promo drafts on their userpage because they don't know they're promo and don't know that's not the place for drafts - so I don't think this would really help. But if I woke up tomorrow and this was the status quo, I wouldn't be mad about it or anything. -- asilvering (talk) 20:35, 5 November 2024 (UTC)[reply]
After giving it more thought, one objection I can see is that enforcing a banner on people's userpages might not be well-received, especially since the target demographic (non-ECP editors) likely won't overlap much with the people who will take the decision. I agree with your explanation for why people write promo drafts on their userpage, and a way to gently inform them that that isn't the place might be better.Now that I think about it, we need an equivalent of U5 that isn't "speedy deletion" but "speedy move to sandbox" (with a message informing the user of what happened, of course). Now that would be helpful. Chaotic Enby (talk · contribs) 20:40, 5 November 2024 (UTC)[reply]
The main issues with user pages seem to be promotional drafts and non-Wikipedia uses (like fake election articles for alternate history forums). It's non merely an enwiki issue - while userspace pages aren't prominently visible, images uploaded for them are. It's a big problem for Commons to have spam and hoaxes mixed in with other images. I'm not sure there's actually a common problem with userspace pages being passed off as real articles; I don't object to this proposal, but I think other changes might be more effective. In particular, I would propose stricter rules and other changes for userspace, with the primary aim of reducing incorrect userspace usage to reduce admin work:
Edit filters disallowing commonly misused elements like external links, images, and infoboxes for new users in userspace. This would essentially kill userspace for fake articles and make promotional userpages less attractive. Maybe even have a fairly strict character limit for new users - that would allow them to have a bluelinked user page introducing themselves, but not enough space for their CV or fake article.
Prominent edit notices for userspace explaining restrictions and directing users to draftspace
Disable the "upload file" link in userspace. The vast, vast majority of crosswiki uploads from userspace are junk.
Better bot patrolling of userspace. This could include creating lists of new userspace pages for easier patrolling, or even automatic moves of likely drafts to draftspace.
Partial blocks from userspace for those who misuse it. This should be more akin in seriousness to an edit filter than a mainspace block.
Formally expand U5 to include any clearly non-Wikipedia usage, regardless of whether the user has mainspace edits, after other interventions reduce userspace usage overall. Obvious junk shouldn't have to go to MfD just because the creator has mainspace edits.
As to passing off user pages as Wikipedia articles, I have encountered it once in real life, and everyone in that conversation was convinced it was real until I started reading the URL more carefully. Admittedly, this was a while ago, and perhaps people are more sophisticated now, but I suspect it is still a bit of an issue, and one that would be easily stomped out with this change. — rsjaffe🗣️22:21, 5 November 2024 (UTC)[reply]
I do agree that there's lots more things that should/could be done and appreciate your list. Perhaps the discussants here could put together a package of changes to improve the situation, though approval of each one would be independent, as some items in the package may be more of an issue than others. — rsjaffe🗣️22:23, 5 November 2024 (UTC)[reply]
I particularly like the edit filter preventing links idea. A plaintext page without through links is (generally) essentially harmless. I don't like the idea of a character limit unless it could be just applied to the top-level user page, rather than subpages which can legitimately be used for draft development. Espresso Addict (talk) 06:35, 6 November 2024 (UTC)[reply]
This is mostly in response to the first point. When creating a new article in mainspace, the little popup on the side always invites me to create the article in my userspace instead. Help:Your first article#Where to start writing also recommends placing drafts in a user subpage. I could very easily see a new editor not understanding the difference between their main userpage and a user subpage. If we block things such as infoboxes, external links, or set word limits, we will be sending a very mixed message to new users. Maybe an edit filter to block new editors from adding external links to commercial/social media sites? (LinkedIn, YouTube, blogspot, what have you). There's very valid reasons why we don't block these types of links in general, but if we're thinking about userspace spam from non-contributors, then maybe? Lots of good faith users do end up adding links to these sorts of websites, but I also think discouraging them from doing that until they've been around long enough to learn the intricacies of WP:SPS isn't a bad idea. I don't really know edit filters, however, so I have no idea how practical this would be. I also don't have enough data to throw myself behind this suggestion just yet.
Not a fan of expanding u5. But maybe, for abandoned SPAs with a spammy vibe, a process similar to PROD? A user tags something as obviously unencyclopedic, and the creator has a month or so to return to their account and contest it, or else an admin reads the userpage, confirms it's never likely to be useful, and either a)declines the tag (so it can never be tagged again) or b) bins it on the understanding that should the creator return, they can request undeletion. MfD doesn't get clogged up with long-abandoned quasi-spam, and it limits the risk of biting newer contributors since it wouldn't work on them. This won't do anything for active spam-like users, but neither does U5, seeing as they can just re-create the page as many times as they'd like before getting inevitably blocked. (And then we go back to userspace prod). There's probably flaws with this idea. I could absolutely see somebody trying to abuse it in the way U5 is abused. The most obvious way is if two editors get into a dispute, one of them is blocked, and the other tries to delete their userspace now that their "enemy" is gone. I like to think that would be noticeable, however. Also, admins would still be required, and thus required to read the pages before deleting them. If the admin fails to do so, that would be very bad.
I like the idea of removing the "upload file" link in userspace. I also think we should remove it in draftspace. I also think we should make the "upload to commons!" link less prominent. A few gours ago, I nearly accidentally uploaded a non-free book file to commons; it was only once I got to the second page when I realised I'd mistakenly clicked the giant blue box as opposed to the tiny grey one. If I'm doing that, then goodness knows what a new user who doesn't understand the difference between their own work and a screenshot is thinking. (And that's just talking about good-faith newbies who are still hunting for clues. Commons does not need anymore copyvio spam than it already puts up with.) This also would not stop users from adding images to their userspace. They would still have other ways. It would merely slow them down, force them to ask questions, and hopefully learn about copyright. GreenLipstickLesbian (talk) 09:46, 7 November 2024 (UTC)[reply]
This isn't a good template for this use. The header is harmless, but of the main text only the first sentence (to the effect of "this is not an encyclopedia article") is relevant. That sentence is needed, though, as well as a statement that this page hasn't been reviewed or quality-checked (even to the extent that normal Wikipedia articles are).Also, we don't need the option to let the page owner turn it off for everybody else, just a handy gadget to hide it for logged-in users who don't know to edit their own css. Without that, we could do this right now without the proposed software changes, which probably would never happen anyway. —Cryptic22:29, 5 November 2024 (UTC)[reply]
Oh, and I see no reason at all to limit it to the primary user page. I don't think I've seen anybody passing off a main user page in their "now read our article on Wikipedia!" link, but have to sandboxes and other subpages a couple times. —Cryptic22:34, 5 November 2024 (UTC)[reply]
Is there any way to get the software to display the namespace in User: and User talk: the way it shows up for every other namespace? Seems like that would be a step towards the goal here. Folly Mox (talk) 00:49, 6 November 2024 (UTC)[reply]
What is the onboarding (or whatever it's called) doing in the way of suggesting very new editors start user pages by the way? I did wonder if we were inadvertently inviting users to make a profile in their first or second edit, and then immediately deleting it U5 with unfriendly messages. Espresso Addict (talk) 06:59, 6 November 2024 (UTC)[reply]
Unless things have changed in the twelve months since I tested the new user signup flow, accounts are presented with a couple messages about Suggested Edits, then land at Special:Homepage. I don't remember there being (and definitely didn't screencap) anything related to creating a userpage. Folly Mox (talk) 11:19, 7 November 2024 (UTC)[reply]
It is, however, a pretty normal impulse to have, creating a userpage. Social media and various apps outright make you do it before being able to do anything else, and many newcomers will have been trained on that kind of behaviour. Also, if you're nervous, userspace edits feel safe, like you're not disturbing anybody while you're mucking around. -- asilvering (talk) 14:18, 7 November 2024 (UTC)[reply]
It's something that is encouraged in in-person training for new editors. A new editor with a userpage tends to be treated less harshly by some new page patrollers than one whose name is a redlink. Thryduulf (talk) 19:00, 7 November 2024 (UTC)[reply]
@Folly Mox, Asilvering, and Thryduulf: Thanks, Folly Mox. I think we need more advice on what the top-level user page may be used for, aimed both at new editors trying to create a profile and, perhaps more importantly, at patrollers. I've seen user pages that were entirely appropriate even for an editor with no other edits ("Hello world, my name is EA, I'm excited to edit Wikipedia!" sort of thing) being tagged G11/U5 by patrollers. (As far as I can tell, some patrollers think U5 is for anything created by a user with few non-userspace edits.) Asilvering writes, "if you're nervous, userspace edits feel safe", and I've found new patrollers think the same, it's a safe space to patrol without offending anyone who knows how to complain. And the flipside to Thrydulf's "A new editor with a userpage tends to be treated less harshly by some new page patrollers than one whose name is a redlink" is that patrollers are suspicious that a blue-linked user page is just the first step in a campaign of terror spam. Espresso Addict (talk) 23:09, 7 November 2024 (UTC)[reply]
Is there an editnotice for new users when they go to edit their userpage? I don't think there is. I don't see one when I try to edit mine, at any rate. -- asilvering (talk) 23:27, 7 November 2024 (UTC)[reply]
I'm getting the impression that some don't speak English at all and have used AI to draft something. Certainly that's true of promotional autobios submitted to draftspace in perfect American Marketing Speak, where I sometimes find it is impossible to communicate with the creator because they don't speak plain-old (British) English (and I don't speak their language). Espresso Addict (talk) 02:14, 8 November 2024 (UTC)[reply]
Having started some Wikipedia articles and added to others, I have the following questions and suggestions:
Why are there four different reference templates, when they all have roughly the same content?
Why does one template call it “Journal”, and another call it “Work”?
Why does there need to be a Page slot and a Pages slot? (printer drivers handle both together)
Should there not be one uniform format for all references when published? (see "Notes", David Graham Phillips: six different references, six different formats)
I suggest there be one reference template that has places for all necessary content, and that all references follow the same format when published:
Template
Title of source _________________ URL ___________________
Last name of source creator _________________ First name ________________________
News agency _____________________ Website name ___________________________
Name of journal, magazine, newspaper, etc. ___________________________ Volume _____ Issue _________ Page(s) ________
Name of publisher ________________________________ Location of publisher _________________________
Date source published __________________ Date source accessed____________________
Ref name ________________ Ref group __________________ Ref ID for anchor ___________________
There are quite a few more citation templates, it is just the four most commonly used that are available in the tool bar. All of the citation templates use the same set of fields, and you can build a citation from scratch using Template:Citation. The four citation formats available in the tool bar just start you with the fields most commonly used for each type of citation. You can leave fields empty, and you can add other fields as needed, as is needed when citing a chapter in a book, for instance. Donald Albury18:53, 7 November 2024 (UTC)[reply]
As a minor correction, not all of the CS1|2 templates support the same parameter set. For example, as of 2023, calling {{Cite book}} with the parameter |website= (or any of its aliases, like |work=, |journal=, |periodical=, |magazine=) will cause a template error, and add the article to Category:CS1 errors: periodical ignored (23,166).To address the substance of the OP, that there is any consistency among the most commonly used citation templates is the result of years of effort and discussion. The multiplicity of display formattings is a feature, not a drawback. There will never be just one single citation template, uniform in formatting across all sources and transclusions.Pbergerd, if you want the input fields in whatever editor you're using (not clear from tags in your contribs) to match the displayed format of those templates, that would best be addressed to whomever maintains your editing interface of choice (if anyone). The formatting will not be changed in the other direction (i.e. display matches input field ordering). Additionally, to my knowledge no citation template display leads with the title when the author is known, so I doubt you'll find consensus for your specific implementation proposal anywhere. All the best, Folly Mox (talk) 18:39, 9 November 2024 (UTC)[reply]
As a less gloomy follow up, our editing guideline WP:CITEVAR allows for articles to maintain the style used by the first major contributor or adopted by the consensus of editors already working on the page. So if you feel strongly about title-headed citations, you can implement your preferred formatting on articles you create, or unreferenced articles you provide the first citations for. But don't be surprised if bots come along and change it.With respect to your specific example David Graham Phillips § Notes: three two of the six citations – Fellow, Mencken, and Ravitz – are manually formatted (not the result of any citation template) and shouldn't be used as examples of a surfeit of citation formats. Two of the three four sources used in citation templates do not provide any authorial or editorial attribution (verified in sources), so naturally the format will differ from that of sources where the author is known.Tangentially, it is somewhat common for articles to use a mixture of Shortened footnotes and regular "defined in place" citations. Usually this is unintentional, as editors new to an article will almost never add citations in shortened format, except improperly, adding to Category:Harv and Sfn no-target errors (4,728). Converting all the new sources to shortened footnote form happens very irregularly. Sometimes articles will intentionally adopt a mixed style, where "main sources", multiply cited sources, or sources cited at more than one in-source location (a subset of the previous criterion) will be formatted in shortened form, and the remainder in the standard fashion. Folly Mox (talk) 19:22, 9 November 2024 (UTC)corrected per below 20:38, 10 November 2024 (UTC)[reply]
There are plenty of reasons not to use shortened footnote templates, and the lack of support for extra parameters is a feature (the footnotes, after all, are supposed to be short).I'm wondering why |access-date= in particular would ever be helpful to support: it's one of the cruftiest parameters, displaying rather a lot of text for information only really needed during archive snapshot hunting; it's not useful for print sources, which have a stable form per publication date, and are the most common types of sources where shortened footnotes are used; and why would you have different access dates for different sections of the source? Can't it just be added to the full citation template the shortened footnote links to?Quotes are another matter, but are easily included within the <ref>...</ref> tags following a harv family template like {{harvp}} or {{harvnb}}, which can be embedded within ref tags. Folly Mox (talk) 15:51, 10 November 2024 (UTC)[reply]
The attributes I mentioned were just random examples, but, e.g., |sectionlink= certainly seems important, and lots of printed sources are also available as PDF. Placing detail as free text in <ref>{{harvnb}}...</ref> does not create the proper metadata, so while it might work for |quote= it does not for other attributes. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:40, 11 November 2024 (UTC)[reply]
I agree with the OP that it's silly to have lots of different templates for citations – {{cite book}}, {{cite journal}}, etc. But there is a generic template for this and it's {{citation}}.
I usually use {{citation}} so that if, for example, I'm citing the Times using a URL, I don't have to worry about whether it's a web site or a newspaper when it's obviously both.
The main problem nowadays is that the Visual Editor generates the more specific templates rather than the generic one. I usually switch to the text editor to correct it but that's a nuisance.
"The article cites more than one reliable source and is better developed in style, structure, and quality than Start-Class, but it fails one or more of the criteria for B-Class. It may have some gaps or missing elements, or need editing for clarity, balance, or flow."
The heuristic for C-class is "substantial but is still missing important content". The heuristic for Start-class is, similarly "developing but still quite incomplete": not very different. As an alternative, you can try to determine whether the article is "Useful to a casual reader, but would not provide a complete picture for even a moderately detailed study" or "Provides some meaningful content, but most readers will need more."
And here's the military history version of C-class:
"The article meets B1 or B2 as well as B3 and B4 and B5 of the B-Class criteria.
Here, rather than having to make a difficult heuristic judgement between C-class and start-class, clear criteria determine whether an article is start-class and other clear criteria determine whether it is C-class. It seems to me to be a reasonable formalization of the two heuristics (referencing and completeness) used to determine C versus Start class anyways. I think if Wikipedia adopted this generally, it would make rating articles much faster and simpler and less confusing given that the criteria for distinguishing C-class articles are formalized rather than subject to essentially how complete the article feels. When I rate articles, I usually spend a good bit of time worrying about whether it is C-class or Start-class -- a major part of the decision making currently is informed by observing other people's decisions. WP:MILHIST has basically solved that and added a FAQ.
Has anybody ever proposed using the MILHIST criteria before? I do remember seeing proposals (not successful) to merge C and Start class, but not this specifically. Mrfoogles (talk) 08:55, 11 November 2024 (UTC)[reply]
Making the assessment process any more formalized than it is is a non-starter when we have hundreds of thousands of articles that aren't assessed at all. PARAKANYAA (talk) 15:32, 12 November 2024 (UTC)[reply]
My experience is that any article ratings other than those which are part of a formal process (i.e. all those except GA, A, and FA) tend to be assigned based on vibes rather than any strict concern with the criteria, and mostly are not updated when the article changes. If assessments are largely made without reference to the criteria, I'm not sure that changing the criteria will have much effect. Even assuming for the sake of argument that people are carefully rating articles based on the assessment criteria, ratings are updated so infrequently that there's no guarantee that they are still appropriate at any given time. I don't object to clearer criteria for what is a start/C/B class article, but I also don't know that I really see the point: at this point in Wikipedia's development, what if anything do people actually use these ratings for? Generally I agree with the view which has been expressed by various people in the past (I know Iridescent used to make this point, as in this thread) that the distinctions between start/C/B class are pretty pointless and we'd be just as well off scrapping them entirely and ending up with a scale which goes stub/standard/good/featured or even unassessed/good/featured. (You mention proposals to merge start- and C-class, but I cannot find them in the archives of Wikipedia talk:Content assessment or WP:VP) Caeciliusinhorto-public (talk) 12:58, 13 November 2024 (UTC)[reply]
I'd pretty much agree with this, adding that in my experience most ratings are assigned almost entirely on article length, and also that nearly all our readers and most of our editors never look at them. Johnbod (talk) 13:37, 13 November 2024 (UTC)[reply]
They are pointless, generally speaking, other than that it's nice to say you've improved the quality of X article to Y, which can be a nice achievement. You might be right than eliminating the distinctions might be a good idea -- stub/start/C are very difficult to distinguish meaningfully, and checking that everything is cited correctly in B requires a mini-GA review level of work for long articles. Mrfoogles (talk) 02:58, 14 November 2024 (UTC)[reply]
Given the reception, probably not going to propose this. What the system really needs is a reform based on determining what purposes it actually serves. Mrfoogles (talk) 02:59, 14 November 2024 (UTC)[reply]
The rating system was created by, belongs to, and primarily benefits the Wikipedia:Version 1.0 Editorial Team. This group is still active, even though they do most of their work via specialized off-wiki tools these days (so don't be fooled if you look at the page history and don't see any recent edits; that's not where the action is). AFAICT it serves their purpose (i.e., selecting articles for offline distribution based on a multi-factor calculation that reflects centrality [most internal links work], popularity [students want to read it], and quality [via ratings]) well. WhatamIdoing (talk) 20:57, 17 November 2024 (UTC)[reply]
My impression is that the ratings are associated with the projects such as Milhist but the project templates seem to be placed in an indiscriminate and rote way.
It would be good to rationalise the ratings in a functional way. For example, what I notice is that DYK and ITN perform their own independent quality assessments without regard to the project assessments. The {{article history}} attempts to pull all these things together but is only used on 50,000 pages. There ought to be a standard talk page template to unify these things.
One of the edits I most often do is to use author link to wiklink names in citations, including in citations that use templates like Template:Cite book. This works great if the author already has an article in English Wikipedia.
Unfortunately, when the author only has an article about him in some other language, this cannot be taken advantage of. Interlanguage links do not work in cite templates. I think Wikipedia does not allow one set of braces or curly brackets {{}} to be inside another set {{}}; in other words does not permit nested layers of templates.
Proposal
I propose that Wikipedia, via some way (whether or not that means allowing nested layers of curly-bracketed templates), enable interlanguage links in citations that use cite templates.
Eberhard Straub (2011). Eine kleine Geschichte Preußens. Klett-Cotta. p. 17.
The wiki markup for the citation reads:
{{cite book|title=Eine kleine Geschichte Preußens|author=Eberhard Straub|year= 2011|pages=17|publisher=Klett-Cotta}}
To make the author's name in the citation be a wikilink to his article, one would insert a new field in the citation like this:
|author-link=Eberhard Straub
but that would create a red link in English Wikipedia, because Eberhard Straub does not currently have an article in English Wikipedia.
However, he does in German Wikipedia, making it preferable for such a link to be an interlanguage link, thus empowering readers who want to know more about the cited author to at least be able to look at the article about him in German, and also inviting readers to be editors and create a new English-language article about him. If and when that English-language article is posted, then the red link to his name and the smaller bracketed blue link to the German article disappear from view and the link appears to readers to be an ordinary blue link to the new English language article.
How?
I don't know how to accomplish this.
I don't know if it's technically feasible to change the Wiki software to allow for a nested layer of curly-bracketed template to be used within another curly-bracketed template, using the already-existing author-link field, like this:
{{cite book|title=Eine kleine Geschichte Preußens|author=Eberhard Straub|author-link={{interlanguage link|Eberhard Straub|de}}|year= 2011|pages=17|publisher=Klett-Cotta}}
Or if a new interlanguage author-link field in the citation template needs to be created instead, like
{{cite book|title=Eine kleine Geschichte Preußens|author=Eberhard Straub|ill-author-link-de=Eberhard Straub|year= 2011|pages=17|publisher=Klett-Cotta}}
just put :de:Eberhard StraubEberhard Straub[in German] (2011). Eine kleine Geschichte Preußens. Klett-Cotta. p. 17.The real reason it didn't work is because the template already generated a [[]], so the parameter tries to linkify a link and render "[[[[:de:Eberhard Straub]]]]], causing it to fail. You can nest templates easily.
Doe, John (1 April 2020). [I witnessed Tom Hanks admitting to actually being born one year earlier, faking his age to enlist in the scouts] (Dream). Lucid. Recurring Tom Hanks scouts dream number 8. Doe's bedroom, 412 Example Street, Suburbiaville, London: REM stage R.
Thanks for your feedback, but the main problem with your suggestion is that it doesn't work with author links, which can draw from separately provided surnames and given names, and then display the results as surname first, then comma, then given name, hyperlinking to the article about the author. I didn't mention this in my original comment for reasons of space and focus.
In other words, what I really want to be able to do is to do something like
{{cite book|title=Eine kleine Geschichte Preußens|author-first=Eberhard author-last=Straub |ill-author-link-de=Eberhard Straub|year= 2011|pages=17|ill-publisher-de=Klett-Cotta}}
If you want to suggest something to do with with the citation templates I suggest you post it to Help talk:Citation Style 1. This, and similar ideas, have been discussed before. The solution is to use: {{cite book |title=Eine kleine Geschichte Preußens |author-first=Eberhard |author-last=Straub |author-link=:de:Eberhard Straub |year= 2011 |pages=17 |publisher=[[:de:Klett-Cotta|Klett-Cotta]]}} which produces: Straub, Eberhard[in German] (2011). Eine kleine Geschichte Preußens. Klett-Cotta. p. 17.
Disclosure: I hate {{ill}} since it breaks title display in non-ASCII scripts on Firefox; i.e. you have to click through and load the sister Wikipedia page just to retrieve the title instead of a bunch of percent escaped garbage numbers for unicode codepoints. Folly Mox (talk) 14:08, 14 November 2024 (UTC)[reply]
In principle, one could set up a disambiguation page (thereby allowing for multiple languages) for the target and use {{interlanguage link}} on the disambiguation page. Of course, there may be a mild "surprise" for the user, but there can be sufficient explanatory text on the disambiguation page to explain the situation.
A side-effect of this (unless there's some provision to suppress this behavior), is that the page will be recognized as a valid "local wiki" page for other purposes as well, but IMO, that's not necessarily a bad thing ... and we can always include a qualifier in the title of the disambiguation page to help address that concern. Also, this is a little more work, but I think it's an improvement over the current practice of not providing the link. Fabrickator (talk) 15:26, 14 November 2024 (UTC)[reply]
Another option would be to create a stub/start article, link it to wikidata to get the language links, and tag it with the relevant "Expand language" template EdwardUK (talk) 17:49, 14 November 2024 (UTC)[reply]
I'm not sure a bunch of transwiki dabpages or nearly content-free stubs are the solution to this unproblem. {{ill}} formatting aside, what's wrong with linking an article on a sister project? We do it with Wikisource, Wiktionary, and Wikidata all the time. Folly Mox (talk) 21:44, 14 November 2024 (UTC)[reply]
In the context of citations, the actual target is only visible when you mouse over it (assuming the user bothers to examine the link preview), so it will typically be a surprise when a non-English page is displayed. Also, the general intent is to let the user select their preferred language, if multiple languages are available. (Of course, there will be a list of all available languages when you go to any language version of the article.) As a fairly minor point, the existing use of {{ill}} provides for the replacement of {{ill}} when a local link becomes available. Fabrickator (talk) 02:16, 15 November 2024 (UTC)[reply]
Favoriting articles for logged-out and IP users
Hi. Before i joined Wikipedia, i always wanted a way to save my favorite articles somehow. When i logged in, i was excited to see a star button on a article (which signaled it was a sort of a favorite button) but to my disappointment it just made articles go on the watchlist. So what if there was a way to save certain articles to, say, read later or gather a collection for a school assignment. This would be very useful to both logged-out and in users. This could mean good for Wikipedia editing too! If you favorite a article, there should be a way to easily come back too it. This would make more efficient editing, rather then a confusing “watch list” of articles. Another way to implete this idea is to add it to a group, where you can come back to later. But either way, there should be a way to save articles to a dedicated area, logged in or not. Edit: I apologize if this is the wrong area,i couldn’t quite figure out if i should out this in Proposals or here.K.O.518 (talk) 06:49, 15 November 2024 (UTC)[reply]
Note that the “View and edit watchlist” tab of the watchlist has a list of all your watched articles in alphabetic order, which could be used as a favourites list. novovtalkedits10:44, 15 November 2024 (UTC)[reply]
It's been nearly two years since I brought this up here, but I've done some more work on articles about years since then and could use more feedback. I've just finished working on 2002. To ensure WP:WEIGHT/WP:PROPORTION, the information in the body of the article is based on sources that cover the year as a whole, such as Britannica Book of the Year and The Annual Register as well as more subject-specific sources. The timeline then reflects what's in the body, with sources like newspapers to verify the specific dates. I want to get more opinions to see if this is a good approach for other year articles going forward and whether there are any other ideas that should be considered. Thebiguglyalien (talk) 00:30, 17 November 2024 (UTC)[reply]
Toward helping readers understand what Wiki is/isn’t
I’ve often noticed confusion on the part of both general readers and editors about what Wikipedia articles are AND aren’t. Truth be told, I suspect all of us editors probably had it not only before becoming editors but also well into our Wiki work.
So I got thinking that perhaps a cute (but not overly so!) little information box that would fly in or otherwise attract attention upon accessing a new article could help halt some common misunderstandings or lack of awareness of general readers. Because I think most editors here at the Pump would be aware of many such examples, I hope you’ll forgive my not providing e.g.’s.
(Of course if such an info box were put in place, there’d also need to be a way for readers not to see it again if they so wish.)
I started to check elsewhere at the Pump to see if a similar idea had ever been submitted before, but I couldn’t figure out a relevant search term. And I didn’t want to suggest an outright proposal if anything similar had in fact ever been proposed. So IDEA LAB just seemed a good place to start the ball rolling. Looking forward to seeing where it leads. Augnablik (talk) 10:58, 17 November 2024 (UTC)[reply]
I'm a strong supporter of providing more information about how Wikipedia works for readers, especially if it helps them get more comfortable with the idea of editing. Readers are editors and editors are readers—this line should be intentionally blurred. I don't know if a pop up or anything similar to that is the right way to go, but I do think there's something worth considering here. One thing I've floated before was an information panel featured prominently on the main page that briefly explains how every reader is an editor and gives some basic resources. Thebiguglyalien (talk) 17:49, 17 November 2024 (UTC)[reply]
The problem with putting stuff on the main page is that many (probably most) readers get to Wikipedia articles from a search engine, rather than via the main page. Phil Bridger (talk) 17:57, 17 November 2024 (UTC)[reply]
The main page gets 4 to 5 million page views each day. And even so, I would guess that people who go out of their way to read the main page are better candidates to become frequent editors than people who treat Wikipedia like it's part of Google. Thebiguglyalien (talk) 15:12, 18 November 2024 (UTC)[reply]
I wasn't thinking of the main page. What I had in mind was that whenever someone requests to go to an article — irrespective of how he or she entered Wikipedia — the information box would fly in or otherwise appear. Augnablik (talk) 17:30, 18 November 2024 (UTC)[reply]
@Khajidha, i don't see the box as ONLY to dispel confusion but ALSO to point out some strengths of Wikipedia that probably readers wouldn't have been aware of.
A few things that came to my mind: although Wikipedia is now one of the world's most consulted information sources, articles should be considered works in progress because ... however, there are stringent requirements for articles to be published, including the use of strong sources to back up information and seasoned editors to eagle-eye them; writing that is objective and transparent about any connection between writers and subjects of articles ... and (this last could be controversial but I think it would be helpful for readers in academia) although not all universities and academic circles accept Wiki articles as references, they can serve as excellent pointers toward other sources.
if the idea of presenting an information box including the above (and more) is adopted, a project team could work on exactly what it would say and look like. Augnablik (talk) 18:58, 18 November 2024 (UTC)[reply]
I think that considerably overstates reality (the requirements are not stringent, sources do not have to be strong, many things are not checked by anyone, much less by seasoned editors, hiding COIs is moderately common...).
Ooops. Well, if stringent requirements, etc., overstate reality, then official Wiki guidance and many Teahouse discussions are needlessly scaring many a fledgling editor! 😱 Augnablik (talk) 19:40, 18 November 2024 (UTC)[reply]
All of these points also fall into the "well, DUH!" category. I did, however, want to respond to your statement that "not all universities and academic circles accept Wiki articles as references". I would be very surprised if any university or serious academic project would accept Wikipedia as a reference. Tertiary sources like encyclopedias have always been considered inappropriate at that level, as far as I know. --User:Khajidha (talk) (contributions) 19:38, 18 November 2024 (UTC)[reply]
Point taken about encyclopedias being generally unacceptable in academic writing.
But as we’re having this discussion in an idea lab, this is the perfect place to toss the ball back to you, Khajidha, and ask how you would describe Wikipedia for new readers so they know how it can be advantageous and how it can’t?
As I see it, that sort of information is a real need for those who consult Wikipedia — just as customers appreciate quick summaries or reviews of products they’re considering purchasing — to get a better handle on “what’s in it for me.” Augnablik (talk) 20:05, 18 November 2024 (UTC)[reply]
I think the logo at the top left already does a pretty good job: "Wikipedia: The Free Encyclopedia". Especially if you look at the expanded form we use elsewhere: "Welcome to Wikipedia, the free encyclopedia that anyone can edit."--User:Khajidha (talk) (contributions) 12:39, 19 November 2024 (UTC)[reply]
@Khajidha, a mere tag saying "The Free Encyclopedia" seems to me just a start in the right direction. The addition of "that anyone can edit" adds a little more specificity, although you didn't mention anything about writing as well as editing. Still, I think these tags are too vague as far as what readers need more insight about.
I'm working on a list of things I'd like to bring to readers' attention, but I'd like to put it away tonight and finish tomorrow. At that point, I'll humbly request you to "de-DUH" your evaluation of my idea. Augnablik (talk) 17:01, 20 November 2024 (UTC)[reply]
Seems to me the problem is that people don't understand what an encyclopedia is. That's a "them" problem, not an "us" problem. And what exactly do these readers think editing the encyclopedia would be that doesn't incude writing it? User:Khajidha (talk) (contributions) 17:45, 20 November 2024 (UTC)[reply]
Wikipedia is very different from the historical concept of encyclopedia. The open editing expands the pool of editors, at the expense of accuracy. -- Shmuel (Seymour J.) Metz Username:Chatul (talk)
Wikipedia may have put traditional general encyclopedias out of business, or at least made them change their business model drastically, but it does not define what an encyclopedia is. One example is that Wikipedia relies largely on secondary sources, but traditional encyclopedias, at least for the most important articles, employed subject matter experts who wrote largely on the basis of primary sources. It is our job to explain the difference. Phil Bridger (talk) 20:03, 20 November 2024 (UTC)[reply]
I would happily pay 25 cents per query if Wikipedia had its own AI chat interface. I use the Co-Star app (astrology) in this way already. I find the cost is worth the value. Free AI summaries available in search engines suffer from having too much garbage input (aka, the unrestrained data of the internet) to produce viable output. I would find it useful to have an AI interface built into Wikipedia. I already trust the information here and all "training data" for the hypothetical bot would effectively be open source. I would trust an AI bot managed by Wikipedia much more than I would trust an AI bot managed by any other entity. And I would be willing to pay for the service more often than I would be able to continue supporting the site through donation. 2603:6080:9F00:B05D:6205:4DF2:8C83:4343 (talk) 22:14, 18 November 2024 (UTC)[reply]
Well, Wikipedia is free and open-source, so we won't be implementing a paid AI chatbot on principle. Regarding the idea of an AI chatbot in general, they are often prone to hallucinations and not necessarily as accurate as they are confident. And they can't be edited by individual users in case they were trained on factual errors, which again goes against Wikipedia's principles. Chaotic Enby (talk · contribs) 22:22, 18 November 2024 (UTC)[reply]
New users, lack of citation on significant expansion popup confirmation before publishing
There are many edits often made where a large amount of information is added without citations. For new users, wouldn't it be good if it was detected when they go to publish an edit lacking citations with a large amount of text, and came up with a popup of some sort directing them to WP:NOR, and asking them to confirm if they wish to make the edit? I think you should be able to then turn it off easily (as in ticking don't remind me again within the popup), but my impression is that many make edits without being familiar with the concept of rules such as WP:NOR. 𝙏𝙚𝙧𝙧𝙖𝙞𝙣𝙢𝙖𝙣地形人 (talk) 01:36, 19 November 2024 (UTC)[reply]
If I'm thinking of the right tool, there was a discussion (at one one of the village pumps I think) that saw significant opposition to deployment here, although I can't immediately find it. I seem to remember the opposition was a combination of errors and it being bundled with VE? I think Fram and WhatamIdoing were vocal in that discussion so may remember where it was (or alternatively what I'm mixing it up with). Thryduulf (talk) 15:21, 19 November 2024 (UTC)[reply]
@Aaron Liu, Edit check is available on the visual editor. Having it on wikitext won't make sense as the goal is to teach users to add citations, not to teach them both about citations and wikitext. Let's reduce complexity. :)
And the visual editor is still not the default editor at de.wp or en.wp. I advised to work on deploying both in parallel so that newcomers would have a better editing experience all at once (less wikitext, more guidance). Why am I not working on it now? Because it would take time. Now that the visual editor was used for years at all other wikis to make millions of edits, we should consider making it the default editor at English Wikipedia for new accounts. It could be a progressive deployment. I've not yet explored past reasons why English Wikipedia didn't wanted to have the visual editor being deployed, again for time reasons. But we would support any community initiative regarding VE deployment for sure.
We could deploy Edit check without VE, but I'm afraid of a low impact on newcomers: they are less likely to be helped as long as VE remains the second editor.
@Thryduulf, there were a discussion about Edit check in the past, you are correct. It covered multiple topics actually. I let you re-read it if you like; I didn't found "significant opposition" there, more questions about Edit Check, VE, citations and more, concerns on Edit Check and VE integration, and support for a better experience for newcomers (as long as it doesn't impact existing personal experiences).
If you didn't see "significant oppo sition" there, then perhaps reread it? The tool you deployed elsewhere had no measurable positive impact (when tested on Simple or French Wikipedia). As for past reasons why enwiki didn't want VE deployed, let's give you one: because when VE was deployed here, it was extremely buggy (as in, making most articles worse when used, not better), but the WMF refused to undo their installation here (despite previous assurances) and used enwiki as a testing ground, wasting tons of editor hours and creating lots of frustration and distrust towards the WMF. This was only strengthened by later issues (Flow, Gather, Wikidata short descriptions) which all followed the same pattern, although in those cases we eventually, after lots of acrimonious debates and broken WMF promises, succeeded in getting them shut down). As shown in the linked discussion, here again we have two instances of WMF deployments supported by test results where in the first instance reality showed that these were probably fabricated or completely misunderstood, as in reality the results were disastrous; and in the second instance, Edit Check, reality showed that the tool wasn't an improvement over the current situation, but even when spelled out this was "misread" by the WMF. Please stop it. Fram (talk) 15:50, 19 November 2024 (UTC)[reply]
Could you provide a couple of links to comments from people other than yourself, and which specifically opposed EditCheck (not the 'make the visual editor the default' or 'Citoid has some problems' sub-threads)? I just skimmed through the 81 comments from 19 editors in the proposal that Robertsky made, and while I might have missed something, your first comment, which was the 69th comment in the list, was the first one to oppose the idea of using software to recommend that new editors add more citations.
Most of the discussion is not about EditCheck or encouraging refs. Most of it is about whether first-time editors should be put straight into the visual editor vs asking them to choose. The responses there begin this way:
"I thought Visual Editor is already the default for new accounts and unregistered editors?" [7]
"In theory, this sounds like a great idea. I'm eager to try it out..." [8]
"I'd support making Visual Editor the default..." [9]
"I totally agree that VE should be the default for new users." [11]
which is mostly not about whether to use software to encourage newbies to add more citations (the second quotation is directly about EditCheck; not quoted are comments, including mine, about whether it's technically necessary to make the visual editor 'the default' before deploying EditCheck [answer: no]).
Then the thread shifts to @Chipmunkdavis wanting the citation templates to have "an easily accessed and obvious use of an |author= field, instead forcing all authors into |last and |first", which is about how the English Wikipedia chooses to organize its CS1 templates, and @Thryduulf wanting automatic ref names that are "human-friendly" (to take the wording RoySmith used), both of which entirely unrelated to whether to use software to encourage new editors to add more citations.
I see some opposition to putting new editors into the visual editor, and I see lots of complaints about automated refs, but I don't see any opposition from anyone except you to EditCheck itself. Please provide a couple of examples, so I can see what I missed? WhatamIdoing (talk) 17:57, 19 November 2024 (UTC)[reply]
"which is about how the English Wikipedia chooses to organize its CS1 templates" is perhaps one way to say that the VE has no functionality to accept the synonyms, which I discovered in a few disparate conversations following that thread. I still have a tab open to remind me to put a note about phab on this, it's really not ideal have VE editors shackled with the inability to properly record author names. CMD (talk) 01:42, 20 November 2024 (UTC)[reply]
VisualEditor is perfectly capable of accepting actual aliases such as |author=, and even non-existent parameters such as |fljstu249= if you want (though I believe the citation templates, unlike most templates, will emit error messages for unknown parameters). It just isn't going to "suggest" them when the CS1 maintainers have told it not to do so. WhatamIdoing (talk) 05:12, 20 November 2024 (UTC)[reply]
If you know how to solve the problem, please solve the problem. Per Help talk:Citation Style 1/Archive 95, "The solution to the ve-can't/won't-use-already-existing-alias-list problem lies with MediaWiki, not with editors adding yet more parameters to TemplateData". As it stands, VE doesn't do it, and I've seen no indication that they consider it an issue. CMD (talk) 12:00, 20 November 2024 (UTC)[reply]
If you want this wikitext:
{{cite news |author=Alice Expert |date=November 20, 2024 |title=This is the title of my news story |work=The Daily Whatever}}
which will produce this citation:
Alice Expert (November 20, 2024). "This is the title of my news story". The Daily Whatever.
then (a) I just did that in the Reply tool's visual mode, so it obviously can be done without any further coding in MediaWiki, VisualEditor, or anything else, and (b) you need to convince editors that they want "Alice Expert" at the start instead of "Expert, Alice" of citations. WhatamIdoing (talk) 21:07, 20 November 2024 (UTC)[reply]
No, I don't have to convince editors that they want "Alice Expert" instead of "Expert, Alice". The issue is, as covered in the original discussion with some good input from others, non-western name formats. It is a cultural blindspot to assume all names fall into "Expert, Alice" configurations, and it seems that it is a blindspot perpetuated by the current VE expectations. CMD (talk) 01:39, 21 November 2024 (UTC)[reply]
1. How did you do that? 2. The author parameter is useful and used iff the author has no last name; e.g., byline being an organization, mononymous person, no author stated, etc. This is documented at the citation-style help pages. Aaron Liu (talk) 22:11, 20 November 2024 (UTC)[reply]
The |author= parameter behaves the same as the |last= parameter, so there's little point in changing the wikitext to say |author=.
(In this case, I took the quick and dirty approach of typing out the template by hand, and pasting it in. The Reply tool's visual mode normally won't let you insert a template at all, because block-formatted templates completely screw up the discussion format. Normally, if there's no TemplateData to provide you with the options, then you'd click on the "+Add undocumented parameter" button and type in whatever you wanted. If there is TemplateData, then see my earlier comment that "It just isn't going to "suggest" them when the CS1 maintainers have told it not to do so.") WhatamIdoing (talk) 23:08, 20 November 2024 (UTC)[reply]
It's semantically different, like the em tag vs italicizing and whatnot. And as I've said before, the documentation doesn't suggest it so that the clueless will not use both |last and |author. Aaron Liu (talk) 23:57, 20 November 2024 (UTC)[reply]
If someone adds |authorn= as a separate parameter, I fear that we will see an increase in the number of articles that populate Category:CS1 errors: redundant parameter because OMG!-there's-an-empty-box-in-the-form;-I-must-fill-it. This is why I suggested radio buttons for aliases; something that MediaWiki would needs implement.
You missed that none of them tested it or checked it on other wikipedia versions, and that no support came along after I had tested it and posted my results? No surprise here... Fram (talk) 19:17, 19 November 2024 (UTC)[reply]
There's a big gap between "The discussion stopped" and "There was significant opposition in this discussion".
In terms of EditCheck, I found most of the discussion to be off-topic, but I can honestly only find one editor (you) who opposed it in that discussion. I assume your failure to provide links to any other statement of opposition means you also honestly can't find a single comment in that discussion from anyone who agreed with you – just an absence of further comments, and an unprovable assumption on your part that its due to everyone agreeing with you. WhatamIdoing (talk) 19:28, 19 November 2024 (UTC)[reply]
Didn't stop you from making any assumptions or presentings things in the most WMF-favorable light. Seems like VE all over again, only then you had the excuse of being paid by the WMF. Fram (talk) 19:45, 19 November 2024 (UTC)[reply]
I don't think I presented the discussion in the most WMF-favorable light. The discussion started off pretty enthusiastic, but it was mostly enthusiastic about something other than EditCheck itself. It then turned into a long digression into something completely unrelated.
(My own contributions to that discussion were technical in nature: It doesn't require the visual editor as the default; code may already exist for an unrelated change that someone wants; stats may already exist for something close to the numbers someone else wants.) WhatamIdoing (talk) 19:56, 19 November 2024 (UTC)[reply]
(ec) Fram, this is precisely because I reread the conversation that I wrote my previous message. We have the right to disagree, but it should remain civil and not convey accusations of bad faith. The way you try to depict me as a dishonest person is not acceptable at all.
I let other participants have a look at the previous discussion we linked, also take a look at the data we provided, and make their own opinion. We aren't the two people who will decide of a deployment here: I'm just the messenger, and you are not the person who has the final word on behalf of everyone. Trizek_(WMF) (talk) 18:00, 19 November 2024 (UTC)[reply]
Tough luck. You posted a dishonest reply last time we had this discussion. If it had been a genuine error in that previous discussion, you should have just said so. Instead, you not only let your error stand, but then come here and claim that there was no significant opposition to Edit Check in that previous discussion, ignoring the one person who tested it and posted results. And like I said in that discussion, the data the WMF provides is not to be trusted at all, as seen from other deployments. Which I already stated and you again ignore completely. But, like I said, the WMF (and previous WMF employees like Whatamidoing) are very good at civil bullshit, while I am not so good at the civil part but rather good at cutting through the bullshit. Fram (talk) 19:17, 19 November 2024 (UTC)[reply]
Since there are non-native English speakers in this discussion, I'd like to clarify that "dishonest", in English, means that the person deliberately told the opposite of the truth. For example, it is dishonest to say "I love Windows ME", when you actually hate it.
However:
Having incorrect or outdated information is not "dishonest".
Caring about a particular benefit more than a different problem is not "dishonest".
Disagreeing with you, or with a hypothetical average reasonable person, is not "dishonest".
There's a reason that English has an idiom about an "honest mistake": It's because it's possible to be factually wrong without being dishonest. For example, if you say "Oh, User:Example said something yesterday", but upon further inspection, it was a different user, or a different day. Or even if you say "The previous discussion shows significant opposition to EditCheck", but upon further inspection, nobody except you publicly opposed it. Such a sentence is only dishonest if the speaker believes, at the time of speaking, that the statement is factually wrong. Unless the speaker believes themselves to be speaking falsehoods, it's not actually dishonest; it's only a mistake or an error.
"Using someone's affiliations as an ad hominem means of dismissing or discrediting their views" – Claiming, or even implying, that WMF staff have a tendency to be dishonest is probably a violation of this point in the policy.
"Insulting or disparaging an editor is a personal attack regardless of the manner in which it is done." – Claiming that anyone is "dishonest", especially when the difference between your view and theirs is a matter of opinion, is very likely a violation of this policy. It doesn't officially matter if the manner in which you say this is "you are dishonest" or "your replies are dishonest"; it's still insulting and disparaging another editor.
Like I said, one can post all distruths one wants as long as one does it civilly. Reminds me of the discussions we had about VE when it was disastrously deployed but all you did as a liaison was defend the WMF no matter what. And I didn't say their replies were dishonest because they are a WMF employee, just that it is typical behaviour for many of them apparently. Perhaps reread the breakdown of the Gather discussions I gave below, or reread the countless discussions about Flow, VE, descriptions, ... There are some good apples among them, but not too many. Fram (talk) 19:51, 19 November 2024 (UTC)[reply]
2013, not 2023. July was early days in VE testing, when I still thought you were helpful. A few months later I had become wiser. Fram (talk) 20:20, 19 November 2024 (UTC)[reply]
For what its worth, I do think a RfC can be made once the proposed details of the deployment is firmed up:
Do we make VE as the default for new editors?
Do we enable EditCheck as it is?
Current pop-up for new editorsAside, if we retain the current arrangement, i.e. letting new/anon editors selecting their preferred editor, can we change the buttons to be more balanced in colours and sizing? These do affect one's preference in choosing which button to click. – robertsky (talk) 18:16, 19 November 2024 (UTC)[reply]
robertsky, that's two RFCs, and – respectfully – conflating the two questions was a primary contributor to how far off the rails this conversation got last time.The UX alterations are probably best brought up at meta or mw for the skins devs to consider. Folly Mox (talk) 18:55, 19 November 2024 (UTC)[reply]
Gather was dropped after 3 months (without any "broken WMF promises" nor any time for them to have given such promises or to have acrimoniously debated), and Wikidata SDs seem to be deployed and working completely fine. Aaron Liu (talk) 18:25, 19 November 2024 (UTC)[reply]
Gather was deployed in March 2015 and immediately got severe backlash at the announcement: Wikipedia:Administrators' noticeboard/Archive270#Extension:Gather launching on beta. No good answers followed. So three weeks later we get Wikipedia:Administrators' noticeboard/Archive270#Moderation of Collections?, where we get (laughable) promises of what the WMF will do to solve some of the most basic problems of this tool they rolled out on enwiki but hadn't really thought about at all it seems. Instead, they created a new Flow page on enwiki for this tool (Wikipedia:Miscellany for deletion/Wikipedia:Gather/User Feedback) despite Flow being removed from enwiki long before this. So in January 2016 (hey, that's already 10 months, not 3), Wikipedia:Village pump (proposals)/Archive 130#Disabling Gather? was started. On 22 Januuary 2016, an answer was promised by the WMF "next week" (section "A WMF reply next week"): "by next week, the Gather team will have a major update to share about the feature". Things escalated, so another WMF person came along 6 days later to promise "we will be putting together this analysis starting now with the intention of sharing publicly next week with a decision the week after." (section "A Response from the WMF"). So instead of some great announcement after 1 week, we are now 6 days further and will get big news 2 weeks later... So, more than 2 weeks later, 12 February, we get "the analysis has taken longer than I anticipated. I'll post the results as soon as I can." So, on the 19th, they posted a "proposal" to which others replied "that proposal is an insult to the community." and "his smacks of yet more stalling tactics and an attempt to save face". Only when the RfC was closed with truly overwhelming supprt to disable it did they finally relent.
Do you really need a similar runthrough of Wikidata short descriptions, which are (or should be) disabled everywhere on enwiki and replaced by local descriptions instead? Or will you admit that perhaps you didn't remember details correctly? Fram (talk) 19:41, 19 November 2024 (UTC)[reply]
Yeah man I don't remember anything well, I wasn't there. I'm just reading random things I can find to see what you're talking about, such as the MediaWiki page that states development was suspended by July 2015, but as you've pointed out, that is different from disabling, and thank you for helping me to find. Thanks for your links on Gather. By no fault of its own, Shortdesc helper made me conflate WD descriptions and SDs. Aaron Liu (talk) 20:42, 19 November 2024 (UTC)[reply]
I never suggested deploying it on the source editor. Having not fully read the above discussion yet, it currently seems unreasonable that it's not deployed in the visual editor on enwiki and dewiki (while preserving the current "level of defaultness" of the visual editor itself instead of increasing the defaultness). Aaron Liu (talk) 16:30, 19 November 2024 (UTC)[reply]
@Aaron Liu, I never implied you suggested it, I was just one step ahead telling you that it is not available on source editor. :) We can deploy Edit check without changing the "level of defaultness" of the visual editor itself, but the impact might not be the same. Trizek_(WMF) (talk) 18:09, 19 November 2024 (UTC)[reply]
(ec) Probably Wikipedia:Village pump (proposals)/Archive_213#Deploying_Edit Check on this wiki. Having reread that thread, it combines all WMF rollout issues into one it seems, from starting with false requirements over a testing environment which isn't up-to-date at all to completely misreading everything that is said into something supposedly positive, ignoring the stuff that contradicts their "this must be pushed no matter what" view. But all in a very civil way, there's that I suppose... Fram (talk) 15:39, 19 November 2024 (UTC)[reply]
What an utterly weird objective for that tool "Newcomers and Junior Contributors from Sub-Saharan Africa will feel safe and confident enough while editing to publish changes they are proud of and that experienced volunteers consider useful." Very neocolonial. Fram (talk) 15:25, 19 November 2024 (UTC)[reply]
Different parts of the world have different responses to UX changes. A change that is encouraging in a high-resource setting (or an individualistic culture, or various other things) may be discouraging in others. It is therefore important to test different regions separately. The Editing team, with the strong encouragement of several affiliates, decided to test sub-Saharan Africa first. WhatamIdoing (talk) 19:50, 19 November 2024 (UTC)[reply]
I can't help it if you don't see how insulting and patronizing it is to write "Junior Contributors from Sub-Saharan Africa will feel safe and confident enough while editing". Fram (talk) 20:26, 19 November 2024 (UTC)[reply]
Redone my check at Simple wiki, looking at the most recent edits which automatically triggered this tool[12]. 39 instances were automatically indicated as "declined", the other 11 contain 3 edits which don't add a reference anyway[13][14][15] and 6 edits which actually add a reference[16][17][18][19][20][21] (though 3 of these 6 are fandom, youtube and enwiki). And then there is this and this, which technically add a source as well I suppose... Still, 3 probably good ones, 3 probably good faith bad ones, 3 false positives, and 2 vandal ref additions. Amazingly, this is almost the exact same result as during the previous discussion[22]. Fram (talk) 16:21, 19 November 2024 (UTC)[reply]
I think just creating one good source addition is enough cause for deployment (without making VE the default editor), especially since it doesn't appear to be causing additional harm. Aaron Liu (talk) 16:59, 19 November 2024 (UTC)[reply]
If it doesn't create more good source additions than we had before the tool, then there is no reason to deploy something which adds a popup which people usually don't use anyway. Without the popup, there also were new editors adding sources, it's not as if we came from zero. No benefit + additional "noise" for new editors => additional harm. Fram (talk) 17:10, 19 November 2024 (UTC)[reply]
I'm not sure what that has to do with my reply. Fram was disputing that the source additions were good and useful, and I was replying to him that some of them were good, hence edit check should be deployed (plus I'm fairly sure there's another check in the works to check reference URLs against the local RSP) Aaron Liu (talk) 18:21, 19 November 2024 (UTC)[reply]
What you observed (Editors who got a popup did not originally give a source when attempting to publish) is shown in the data we shared.
We already deployed checks to verify if a link added is not listed in rejection lists and make it more actionable by newcomers. Some users at other wikis expressed a need to have a list of accepted links (the ones that match RSP), but other said that it could prevent new good sources from being added. Thoughts?
Isn't that the programmed heuristic for when the popup appears? I don't get what this has to do with any stats.Only URLs in the spamlist are blocked. Edit check should strongly warn against adding sources found generally unreliable by consensus summarized at RSP. Aaron Liu (talk) 18:59, 19 November 2024 (UTC)[reply]
I'm not sure to understand, sorry. Stats are about users adding a citation when asked compared from where not asked. It is not connected to RSP.
Like I said, of the 11 supposed additions, 5 need reverting (as far as the source goes) and 3 didn't add a source. I don't trust WMF numbers at all, but 5/8 needing a revert is hardly an overwhelming success. Even assuming that the 3 good ones wouldn't have added a source otherwise, one then has to make the same conclusion for the others, and the 5 bad ones wouldn't have been included otherwise either. So where is the net benefit and the no harm? Fram (talk) 19:54, 19 November 2024 (UTC)[reply]
I don't trust WMF numbers at all
I'm new to all this, could you elaborate on why?
the 5 bad ones wouldn't have been included otherwise either
The 5 bad ones would have included no source at all if Edit Check wasn't there. I don't see how adding a blatantly terrible source is worse than adding text without a source at all. Both are checked the exact same way: eye-scanning. So there you go, net benefit and no harm. Aaron Liu (talk) 20:11, 19 November 2024 (UTC)[reply]
No. I explained it already in the previous discussion. You have made false claims about Gather and so on, but can't be bothered to reply when I take the time to give a detailed answer; but now you are apparently "new to all this" suddenly and want me to again take some time to enlighten you. No. And an unsourced statement is obvious to see, a statement sourced to a bad source is much less obvious. Fram (talk) 20:24, 19 November 2024 (UTC)[reply]
@Aaron Liu, I think this is a "reasonable people can disagree" thing. Some RecentChanges patrollers just revert any new unsourced claim, so if it's unsourced, it's quick to get out of the queue. Faster reverting means success to them, whereas encouraging people to add sources is like whispering a reminder to someone during a game of Mother, May I?: It removes an easy 'win' for the reverter.
OTOH, having a source attached to bad information has other advantages. It's easy to determine whether it's a copyvio if you have the source, and if you're looking at an article you know something about (e.g., your own watchlist rather than the flood in Special:RecentChanges), then having the source often means that you can evaluate it that much faster ("This is a superficially plausible claim, but I wouldn't trust that website if it said the Sun usually rises in the East").
For content that shouldn't be reverted, then IMO encouraging a source is always a good thing. For content that should be reverted, there are tradeoffs. WhatamIdoing (talk) 21:22, 19 November 2024 (UTC)[reply]
I miss things, especially on a workday. Sorry about that. I think the mobile short-descriptions thing is believable, as users . This is a case of the methodology being technically correct but misleading, which I don't see for the edit check study, unless you're willing to provide an argument.
an unsourced statement is obvious to see, a statement sourced to a bad source is much less obvious.
IMO, only slightly. Often, only users of experience patrol pages when reading them. (The unacquainted are also sometimes able to realize something's probably wrong with a swath of unsourced text, hence they make up part of the aforementioned "slightly".) And blatantly bad sources jump out to those experienced from the references section. Sources in the middle ground can often link to good sources, though there is a debate on how good it is to have both additionally middle-ground and bad sources vs. no sources at all. Personally, I think it's better. Aaron Liu (talk) 21:47, 19 November 2024 (UTC)[reply]
It would save time to have a true template but what would the word list be; y/Y/yes/Yes/YES n/N/no/No/NO t/T/true/True/TRUE f/F/false/False/FALSE? Anthony2106 (talk) 05:21, 19 November 2024 (UTC)[reply]
In templates like plot and AUD they have an option for "true" e.g {{AUD|10,000|link=yes}} putting "True" in place of "yes" does not work, so this functionality could be added into the AUD template or AUD could use a istrue template - a global template that has all the yeses and no's, so AUD would have a template in a template. This way each template that needed a yes/no could use this global template. Anthony2106 (talk) 07:32, 19 November 2024 (UTC)[reply]
Don’t put up Ip addresses for those who are not signed in.
You see, if someone edits Wikipedia and they are not signed in, their IP address is exposed. That means one could track where they live and dox them further. So yeah, don’t put the Ip adrees. But what if the person does an edit that ruins the page, or something bad? you see Wikipedia will have the ip address, and all what they have to do is report the anonymous person, Who will have a name, like not logged in or something, then Wikipedia will block it. Have a good day. Bye bye! Datawikiperson (talk) 09:46, 19 November 2024 (UTC)[reply]
IP addresses will give the location of the ISP node, or if the router has a location recorded with the ISP it will show that, most private routers do not show their location and will just show the ISP node. Try it yourself on a website like https://www.iplocation.net/. But you're right, sometimes it can that's true. 𝙏𝙚𝙧𝙧𝙖𝙞𝙣𝙢𝙖𝙣地形人 (talk) 18:12, 19 November 2024 (UTC)[reply]
While I'm not the most versed on that technical issue, one of the important points raised during Graham's RRfA was that admin tools were needed for him to do history merges and deal with more complex imports. Since Graham will no longer have these tools as an administrator, would there be a way to add these capabilities to the importer role? It could also help make the latter more accessible for non-admins potentially interested in helping out with this. Chaotic Enby (talk · contribs) 11:26, 20 November 2024 (UTC)[reply]
Yes, it would be possible. Need (a) a community discussion that supports adding the (mergehistory) permission to the import group, here on the English Wikipedia. Then (b) a configuration request can be made to add such. — xaosfluxTalk11:29, 20 November 2024 (UTC)[reply]
In light of the fact that we now have an additional public court disclosure seeming to overwhelmingly indicate that the WMF will imminently be disclosing the personally identifying information of at least the three volunteers that ANI has identified as defendants in its suite, I am proposing we have as broad a community discussion as possible on what further response (up to and including large organized protest actions aimed to challenge the WMF's intended course of action) might be appropriate and feasible in the circumstances. Please see here, for further details. SnowRise let's rap16:13, 14 November 2024 (UTC)[reply]
Journal article about coverage of native American topics in English-language Wikipedia
Given that it's recent (May 2024) and it has suggestions directed at Wikimedia Foundation, I was just wondering if Wikimedia Foundation is aware of this article. And I am not asking with respect to editor conduct, but with respect to any potential initiatives (such as partnerships with potential volunteer experts to audit few articles). Bogazicili (talk) 19:12, 4 November 2024 (UTC)[reply]
Here is a quick overview of highlights from the Wikimedia Foundation over the first half of November 2024. Please help translate.
WikiCelebrate Mārtiņš Bruņenieks
Upcoming and current events and conversations Talking: 2024 continues
Commons Community Call: The first community call with Wikimedia Commons volunteers and stakeholders to help prioritize support efforts for 2025-2026 Fiscal Year will take place on November 21. The theme of this call will be about how content should be organised on Wikimedia Commons. The call will be hosted by Chief Product and Technology Officer Selena Deckelmann.
Wikifunctions: The Abstract Wikipedia team is working toward a rewrite of our backend services in a different programming language, likely Rust. More status updates.
Temporary accounts: Logged-out editors on 12 wikis, including Norwegian, Romanian, Serbian, Danish, and Cantonese Wikipedia, receive temporary accounts now. This new account type enhances the privacy of logged-out editors and makes it easier for community members to communicate with them. Read the new Diff post to learn more about temporary accounts.
Mobile apps: The Mobile Apps team has released an update to the iOS app’s navigation, now available in the latest App store version.
Admin Retention: A survey on Wikipedia Administrator Recruitment, Retention, and Attrition is open until November 11. As part of the Foundation's 2024-2025 Annual Plan, the research team and collaborators are studying recruitment, retention, and attrition patterns among long-tenured community members in official moderation and administration roles.
Knowledge is Human: The campaign web page, which educates visitors on Wikipedia’s model and why it’s trustworthy, has earned over 140,000 clicks. The campaign has increased pageviews on WikimediaFoundation.org by more than 50%.
Annual Goals Progress on Equity See also a list of all movement events: on Meta-Wiki
WikiCelebrate: From making a minor maintenance edit in 2005 to being one of the most appreciated Wikimedians in the Central Eastern European (CEE) region: this month we celebrate Mārtiņš Bruņenieks.
Future of Language Incubation: As part of a new Future of Language Incubation initiative to support language onboarding, Wikipedia is now live for five languages: Pannonian Rusyn, Tai Nüa, Iban, Obolo, and Southern Ndebele.
Global Advocacy: Reflecting on the anniversary of the EU’s Digital Service Act (DSA), Wikimedians share successes and public policy priorities at digital rights Global Gathering event, and more global advocacy updates.
Fundraising Report: Our annual fundraising report for the 2023-2024 fiscal year is published. Last year, we had over 8 million donors giving an average donation of m:Fundraising/2023-24 Report0.58. We ran campaigns in 33 countries, 18 languages, and received donations from over 200 countries.
We would prefer not to deploy on English Wikipedia at that time, though. A knee jerk reaction would be requesting otherwise and have enwiki be onboard as early as possible. – robertsky (talk) 08:48, 9 November 2024 (UTC)[reply]
It makes sense to fine-tune implementation on smaller wikis before rolling out to larger ones, but I am a lot more comfortable about this implementation than I was with earlier reports, which merely talked of hiding IP addresses, with all the worries over how we then handle IP vandalism, and did not provide any benefits to the (logged-in) community of editors. Espresso Addict (talk) 08:57, 9 November 2024 (UTC)[reply]
Indeed, I was very pleased that the ability to look at IPs had been extended to patrollers. Is there somewhere better that we can highlight this useful update, which allayed many of my concerns as an administrator about the upcoming change, as I fear the WMF page is not much read? Espresso Addict (talk) 09:33, 9 November 2024 (UTC)[reply]
How will this change the WP:OUTING policy? For example can I include the IP address or cidr range of a temporary account in the suspected sock list? Would that be considered outing? Because anyone(logged out editors too) can see a SPI report.Ratnahastin (talk) 09:38, 9 November 2024 (UTC)[reply]
Most likely not, as you're required to agree to certain terms when opting in to view IPs (as you already are on this wiki when enabling IP info). It would be a violation of not only local policy but ToS. Nardog (talk) 11:51, 9 November 2024 (UTC)[reply]
I think there should not be a need to include the IP address or the CIDR range in SPI report. Just the list of temporary accounts will do. Any CU, clerks, or patrolling admins will to have updated their checking processes to account for temporary accounts. – robertsky (talk) 12:02, 9 November 2024 (UTC)[reply]
Has anyone seen an indication of how many buttons you have to click to see IP info? In the past, people might post half-a dozen IPs at ANI and someone else would point out that that was a /64 that should be blocked with no collateral damage. At least one template ({{blockcalc}}) can extract IPs from wikitext and show the ranges involved. We will have to see how much hassle will be involved with the new system. Johnuniq (talk) 02:02, 10 November 2024 (UTC)[reply]
@Johnuniq: I have the global version of edit filter helper, so I have access on the wikis where it's just been rolled out (plus testwiki). If I recall correctly, it's just one button agreeing to the IP information policy to reveal IPs, but there are more boxes in Special:Preferences that allow for things like revealing IPs in the edit filter and using IP information on contribution pages. There's also a global preference available to CU/OS and certain global groups (global rollback/sysop, and global abuse filter helper/maintainer) to enable IP information cross-wiki. EggRoll97(talk) 23:32, 10 November 2024 (UTC)[reply]
Temporary accounts can be changed if one clears cookies or uses a different browser, not the same case with a cidr IP range. This will certainly make it a bit of a hassle to list out every temporary account associated with the IP range, anyway let's see how this feature is implemented first. Ratnahastin (talk) 02:06, 10 November 2024 (UTC)[reply]
Open letter about Asian News International vs. Wikimedia Foundation
Do you mean the users or a part of the body of wikipedia itself? As in, could Trump take over the website or otherwise exert significant pressure that would otherwise be alleviated by relocation? If not, then I guess no action necessary.
Are the servers located in the United States? It's looking like the answer is no, and I'm sorry for being paranoid, it's just that he has done things in this country that we didn't anticipate because we didn't expect anyone to have the sort of character that it would be a problem in that position. 75.142.254.3 (talk) 20:01, 10 November 2024 (UTC)[reply]
The primary Wikimedia data centers are located in the U.S., with caching centers distributed around the globe. I think you'd be hard pressed to find a country with better legal protections for online free speech, but as you note, it shouldn't be taken for granted. Legoktm (talk) 20:13, 10 November 2024 (UTC)[reply]
Yeah, the 1st amendment provides stronger protections than almost all countries have; even if Trump tried he'd be hard pressed to find a court that would agree with Wikipedia censorship (unlike in India...). Galobtter (talk) 04:34, 11 November 2024 (UTC)[reply]
You are correct about the strength of free speech protections in the US being more robust than just about anywhere else in the world, from a perspective of well-enshrined constitutional protections and the historical jurisprudence and respect from institutions. That said, if there were to be a concerted push by the incoming president and his allies to suppress certain information streams and target free speech that aligns against him, it would not be the first time that he sent shockwaves through the legal world by finding success in overturning long-established doctrines that were until recently thought iron-clad and inviolable, by appearing before a federal judiciary that is now showing the influence of decades of concerted efforts by the GOP and the Federalist Society to pack those courts to the gills with ideologically-aligned and personally loyal jurists. In short, nothing is certain in the current political and institutional landscape. I just don't think a whole-sale move of the organization and its technical infrastructure is either feasible or likely to substantially obviate the risks. The only answer is to take up the fight when and where it occurs. SnowRise let's rap20:19, 17 November 2024 (UTC)[reply]
The Wikimedia Foundation, which hosts Wikipedia, is based in the United States, and has to comply with US laws. Unless a relevant law is passed or legal action is taken, there isn't much Trump can do. ARandomName123 (talk)Ping me!20:17, 10 November 2024 (UTC)[reply]
If Trump goes authoritarian, which at this point I'm not going to rule out, US Law could be changed on a whim. But, I'm going to try to not be paranoid as much on this and WMF may already have evaluated appropriate courses of action given how they've managed to handle a wide variety of different kinds of disruption already. 75.142.254.3 (talk) 20:20, 10 November 2024 (UTC)[reply]
The bottom line is, we just don't know. I'm sure the WMF has contingencies in place for if US law ever becomes prejudicial to the project. Until he actually becomes president, we don't know what will happen. We just have to wait and see. TheLegendofGanon (talk) 20:22, 10 November 2024 (UTC)[reply]
I might have agreed with you a month ago, but considering the current crisis over the ANI matter, I am not at all confident that the WMF does have a proper contingency plan for a concerted litigation campaign from a Trump presidential administration or aligned parties. And actually, in that case, I could forgive their not having one: in that case, it's hard to predict for once bedrock civil and constitutional principles flying out the window, or know the exact combination of legal angle of attack and political pressure which may lead to such outcomes. Unlike certain other recent scenarios where the manner in which things have played out was mostly predictable, there is a lot that could very much be up in the air. The Justice Department will certainly be headed by a political loyalist for the next four years, and SCOTUS and many of the other federal courts are incredibly friendly to right wing causes, but the MAGA movement as a whole has not tended to attract the sharpest of legal minds for advocates, and not withstanding the election results, there is a lot of cultural attachment remaining in the U.S. for robust free speech protections--which afterall, conservative politicians are typically as happy to invoke and benefit from as anyone. So it's very difficult to know how concerned to be or what angle to expect the erosion of expression rights to set in from, if it does occur. In this case, I would sympathize if the WMF felt as much ina holding pattern as the rest of us. SnowRise let's rap20:34, 17 November 2024 (UTC)[reply]
As a basic precaution there should be a Wikipedia mirror with daily backups hosted on a server geolocated in a country with a higher democracy index and a higher internet freedom index than the US. I'd suggest Iceland, personally.—S MarshallT/C04:23, 13 November 2024 (UTC)[reply]
Honestly, it's unneeded. Look, I get worrying about this situation but I doubt the situation will get so bad where wikipedia needs to move overseas. As stsated above, wikimedia also likely already has a plan for if this happens. Gaismagorm(talk)11:40, 13 November 2024 (UTC)[reply]
In any event, I do believe the backups at least are already quite robust in that respect. I'm less certain about the current situation for the mirrors, but I'm sure that information is probably transparently located somewhere on-site or on Meta. SnowRise let's rap20:39, 17 November 2024 (UTC)[reply]
What’s so great about Iceland? I don’t like the idea of being subject to the whims of a country with the population of a small city that’s floated the idea of banning internet pornography at least once. The most obvious choice would be Switzerland. Dronebogus (talk) 01:04, 20 November 2024 (UTC)[reply]
Iceland's a fantastic place, and everyone needs to go on a night out in Reykjavik before they die, although some people might need to extend their mortgages to do it. It's true that pornography is technically illegal in Iceland, so in that scenario, if the worst should happen, some of your more worrisome drawings on Wikimedia Commons might be lost; but I understand that the antipornography laws are rarely enforced.—S MarshallT/C17:05, 20 November 2024 (UTC)[reply]
I have spent a night in Reykjavik (well, it was aboard ship, but we did stay overnight), but I will note that Iceland has no army or navy and only a small coast guard. I'm not sure how well the country could resist pressure from the US (or Russia, for that matter, if the US were looking the other way) to interfere with any entity operating there. I used to have hopes that the EU would get its collective defense act together, but even if it did, Iceland hasn't joined, yet. Donald Albury18:26, 20 November 2024 (UTC)[reply]
But since we’re pretending like this actually a viable idea Switzerland has a formidable military for the express purpose of defending its neutrality. Dronebogus (talk) 06:26, 21 November 2024 (UTC)[reply]
@S Marshall: I’m actually thinking of stuff like the Internet Watch Foundation and Wikipedia or Seedfeeder. Plus a country with a tiny, homogeneous population (even a very friendly one) is more likely and able to legally force its weird idiosyncratic opinions onto Wikimedia, especially if it thinks the biggest nonprofit website on Earth has done something to damage its reputation (because in this hypothetical scenario Wikimedia would quickly become synonymous with Iceland by virtue of being its biggest export besides maybe Bjork) Dronebogus (talk) 06:39, 21 November 2024 (UTC)[reply]
Just a thought, but if the WMF does have or in the future creates contingency plans for moving operations in response to political developments, publicly revealing such plans in advance might make it harder to carry them out. It would be like a business announcing that they will build a factory in a given location without having at least an option to buy the land they will build on. Donald Albury16:11, 13 November 2024 (UTC)[reply]
Stop worrying to much, I doubt Trump is going to do anything against Wikipedia. Attacking and threatening to block Wikipedia will only infuriate the centrist voters, which I didn't think anyone would want to do. Some of the editors here are Trump supporters as well! What is concerning for Wikipedia today is the above case in India, where WMF HAD agreed to disclose the editor's information because of a defamation suit. ✠ SunDawn ✠(contact)06:01, 14 November 2024 (UTC)[reply]
This is also an important part of the analysis: we are hardly the most vulnerable collective entity in existence: for obvious reasons, we are meant to be apolitical, unaligned, and disinterested in directly influencing public perception of any matter (beyond the core mission of providing information, of course). But the one time this community was willing to flex its muscles to head off a legislative outcome that it felt was a danger to the fundamental viability of the project, the latent power of the project's reach, through the site/encyclopedia was made pretty obvious--and that strength was not trivial, utterly crushing legislation that had been sailing through congress. If pushed into a corner and forced to abandon its apolitical role, this movement is capable of coming back with potent counter-punches in terms of grassroots mobilization, and I think there is some perception of that fact out there now.
There's also the massive legal warchest of the WMF to contend with (which so many on this project have groused about over recent years, but which was well-advised to build up, for exactly this moment in time). Of course, the current ANI situation raises significant concerns about the ability of the WMF and the community to row together, which is one of the most concerning things about that situation. But the WMF will not have the same onerous sub judice principles giving it both legitimate and illegitimate reasons not to communicate clearly with us (at least nowhere near to the same degree) with regard to suits before U.S. courts. SnowRise let's rap20:51, 17 November 2024 (UTC)[reply]
Realistically, I doubt anything in particular will happen to Wikipedia. But if you want to prepare for the worst, as it were, and you have a machine with some extra disk space, consider periodically keeping an updated copy of the Wikipedia database dump. I get one periodically, just in case, since I've got plenty of spare space on this machine anyway. If worst ever came to worst, plenty of volunteers have the technical skill to get a DB dump up and working on a MediaWiki instance elsewhere, and run it at least while things are sorted out. I doubt it'll ever come to that, but if you want to be prepared just in case, well, the more widely copies of those are available, the better. Just remember that Wikipedia was completely run by volunteers once, from software development to sysadmins, and we could do it again if we had to. SeraphimbladeTalk to me06:12, 14 November 2024 (UTC)[reply]
The biggest problem would be providing sufficient server capacity to handle the traffic. Anybody can put up a static mirror of WP as it was on the download date (Lord knowns there are a lot of those on the Internet), but providing an editable version that would be used by a large proportion of current editors would be pretty expensive. And if there were more than one editable version out there, it would be very difficult to ever merge the changes back into a single database, with some clones becoming permanent forks, perhaps sponsored by governments and other large entities. Donald Albury18:19, 14 November 2024 (UTC)[reply]
I've thought of the technical feasibility of a forked encyclopedia more the last few weeks than I have in the last ten years. Not as a serious exercise in making any plans, but just as a consequences of thinking about the relationship between the project and the WMF and what actually keep volunteers invested in this particular, traditional and only mode of building the encyclopedia. Aside from the obvious organizational and cultural ties, there's the obvious cost of maintaining ongoing access and development that you talk about, but then there's also the liabilities and legal fees. If circumstances were drastic enough to take Wikipedia itself down, it would be hard to shield any project with a big enough profile to be able to afford the access and tools for readers and editors from whatever legal forces had compromised Wikipedia's viability in the first place. Even redundancy different jurisdictions wouldn't necessarily obviate the kinds of threats that would be sufficient to take the original Wikipedia out of the picture. SnowRise let's rap07:49, 18 November 2024 (UTC)[reply]
I hadn't thought about the legal side. Trying to fork Wikipedia may well cause more problems than it could ever solve. I think the best chance of preserving Wikipedia is anything like its current form is to let the foundation do its job. If the foundation cannot protect Wikipedia in the US, there is little hope of Wikipedia surviving somewhere else. Donald Albury15:08, 18 November 2024 (UTC)[reply]
To be frank, I am greatly surprised by the faith you put in the US Constitution. Many of you seem unaware that the threats you are facing are unprecedented. Trump attempted a coup in 2020 and during his campaign he actually said he wants to be a dictator. Or how else are we to interpret such things as "If you vote for me, you don't have to vote at all in four years"? He didn't say all this back in 2016. Neither did he employ such rascals in his government as he is planning to do know. Therefore I find the argument that we lived through Trump's first presidency unharmed very unconvincing.
He and his loyal servants have expressed their contempt of science on numerous occasions, most recently J.D. Vance by saying "professors are the enemy". With both houses of the Congress and the Supreme Court in Republican hands, checks and balances aren't worth much, especially since the party has shown an unfaltering loyalty for its Great Leader over the past few years. A major Gleichschaltung operation is to be expected. What matters most in situations like this is not the law but the sentiment of the people. And that sentiment seems to be strongly in favour of an authoritarian dictatorship. Under such conditions, laws are easily explained the way that best fits the regime.
So for goodness' sake, move! Not just the servers, but also the WMF as a legal entity. I am well aware that no country on Earth is entirely safe of a populist threat, but the situation isn't as dire everywhere as it is in the US. Canada could be an option. Or Spain, one of the few European countries that still welcomes immigration of some sort. Do it, before it's too late! Don't let yourselves and our work be ground among the cogwheels of this vile, narcissistic despotism! Steinbach (talk) 10:56, 17 November 2024 (UTC)[reply]
Steinbach, you write that the sentiment of the people seems to be strongly in favour of an authoritarian dictatorship and yet the current popular vote count has Trump at 50.1% and dropping as California votes continue to be counted. So, the sentiment is not as strong as you portray it. I too am deeply concerned about the path that the United States is on, but we should not overstate public sentiment for dictatorship. Cullen328 (talk) 22:55, 17 November 2024 (UTC)[reply]
Billions of people rely on Wikipedia. Trump won't be able to do anything without the world going against him. Tons of his very voters shame his fake news big lie narrative. Aaron Liu (talk) 17:20, 17 November 2024 (UTC)[reply]
What you are urging is not really feasible, at least not in the short term, and if the fight you fear is coming, it will go best for the movement on the ground that a U.S. base provides. If you think that moving to Spain and putting the project even further under the auspices of EU law will lead to greater free speech protections, I have bad news for you: a substantial portion of the content on this site would be much more amenable to exclusion and state interference under petition by private parties under GDPR principles than it would under U.S. jurisprudence. This is one area of civil and human rights where the EU is much more laissez-faire about suppression than is the U.S., especially when you consider "right to be forgotten" stances. SnowRise let's rap21:02, 17 November 2024 (UTC)[reply]
Last I heard the WMF keeps both the main site and the backup site in the US. Now might be a good time to reevaluate this and move one of them to another country. The WMF is quite good at employing a diverse multinational workforce scattered across the planet, but it is very centralised when it comes to fundraising, a more distributed model where funds raised in particular countries were controlled by affiliate charities or chapters in those countries would in my view be stronger. At least it wouldn't have a single point of failure. ϢereSpielChequers15:02, 18 November 2024 (UTC)[reply]
Miscellaneous
Fictional flag used in multiple places
This problem is not unique to the English-language Wikipedia, but I'm starting here because this is my native language. I'm bringing this to an explicit discussion here rather than just editing so that we can build an explicit consensus that I can then show the other Wikipedias.
I think this is a more general case of Commons is not a reliable source. I often see people take images in commons completely at face value, including them in articles without any real source. Commons has very different rules than enwiki. They are mostly concerned with copyright and licensing, and (intentionally) make no attempt to verify that images are "real" or that the descriptions are factually correct. That's just not their job. But it is our job when we use one of their images in an enwiki article. RoySmith(talk)16:21, 7 November 2024 (UTC)[reply]
I belong to an organization which has a flag. The design is described in exquisite detail in our charter ("white stripe, whose width is one-sixth of the hoist", that kind of thing). I sat down one day and carefully drew an example in a drawing app, taking pains to get the geometry exactly as described. The charter (long) predates things like Pantone, but I did consult with a commercial artist to get their input on the correct RGB values to use for the colors and attempted to get all the people who produce material for us to use these "official" versions. Eventually I gave up and accepted that people will just copy-paste from whatever is handy. Now I just amuse myself by tracing the lineage of various bits of marketing material by which version of the flag they've got. But, yeah, we should do better than that. RoySmith(talk)17:25, 7 November 2024 (UTC)[reply]
@WhatamIdoing: please feel more than free to pursue that.
I am glad to see there appears to be consensus to remove this from all articles. I will do so, or at least attempt to (some may be tricky because of templates). - Jmabel | Talk17:03, 10 November 2024 (UTC)[reply]
I suspect there will be few objections to bold removal of any fictional flags. Commons has a real issue with their flag galleries, unfortunately. CMD (talk) 11:06, 11 November 2024 (UTC)[reply]
1) Deals with user behavior problems that our normal consensus process at WP:ANI can't handle. 2) Deals with administrator behavior problems. 3) Deals with anything related to private, off-wiki information. 4) Deals with certain unblock requests. –Novem Linguae (talk) 02:56, 10 November 2024 (UTC)[reply]
I'm just wondering how others feel about this, without immediately starting an RfC or deletion discussion. @Hughbe98: as the one who created this example (but discussion is not about editor, but about edits).
Is this excessive, and if so how to reduce this? Removing the uppercase / lowercase variations would halve this already... Do we have guidance on a best approach for redirect creators? In total we now have already 448 redirects to this one article[25]. Fram (talk) 17:48, 12 November 2024 (UTC)[reply]
Ugh. This is what search engines are for. In the deep dark old days, we used to create these kinds of redirects because search wasn't very good. It's much better now (where "now" means the better part of 20 years) so we should just let it do its job. RoySmith(talk)17:59, 12 November 2024 (UTC)[reply]
I see no problem here to be addressed. None of these individual redirects is so wrong as to merit deletion, so I don't see how the quantity much matters. BD2412T19:07, 12 November 2024 (UTC)[reply]
Oh, storage space wasn't my concern. More things like issues with "what links here" being harder to navigate, more redirects to watchlist for vandalism, more work when the target gets changed (e.g. in the list above, the target is a potential article apparently, so when it gets created all the redirects need updating), more potential "wrong" results in searches (to take the most recent creation, is 13 W. 3 significantly different from 13W3, which has a different target), ...? But if people see no issue, then my question is answered and no action is needed. Fram (talk) 20:00, 12 November 2024 (UTC)[reply]
I think you are right to question this. The problems you mention are small but not zero. Exhaustively redirecting variations of words is not something I would want to catch on as a normal practice. Barnards.tar.gz (talk) 14:58, 14 November 2024 (UTC)[reply]
Redirects are cheap and usually uncontentious. Just occasionally an unambiguous redirect can become ambiguous as a new meaning arises for it. I suspect that only fixing redirects when they have become ambiguous would save a lot of unnecessary distraction and pointless make work. I used to spend quite a lot of time resolving multiple redlinks, and yes some of the redirects set up to do this would now be resolved by search. But improved search doesn't on its own resolve redlinks. ϢereSpielChequers09:04, 13 November 2024 (UTC)[reply]
This is one of those situations where WP:CHEAP conflicts with a desire not to keep/hoard useless things. The question is: are these redirects actually useless? For most cases, I would suggest waiting at least six months, better a year, as long as the redirect is not linked from anywhere, and see if it gets any pageviews. If it doesn't, it can probably be deleted. Cremastra ‹ u — c › 13:31, 14 November 2024 (UTC)[reply]
Another way of thinking about it is, is the effort to check whether anyone uses a redirect worth less than the value of the resources freed up by deleting the redirect? My understanding was that the overhead of holding a redirect was so low that it meant any review of redirects, however cursory, was going to waste more effort than it could possibly save. ϢereSpielChequers22:27, 14 November 2024 (UTC)[reply]
I agree with RoySmith that would should let search engines do their job, and I don't feel it's necessary to have a redirect for every variation that someone might write in an article. I don't think that does our readers any favours; having a common style helps them become familiar with it and thus more quickly recognize a citation. I agree with Fram that there are maintenance costs, and an increased risk of overlapping topics. For this particular case, is there a standard style that is generally used? isaacl (talk) 18:11, 14 November 2024 (UTC)[reply]
With legal citations, standards change over time. Any of the above variations for the particularly ancient statute in question may have been the most correct at a particular time. Even the ones that were never the most correct may have been used enough to show up in legal writings, such that a reader might see and want to look up the specific variation they have come across. Again, this is an unusually old statute. I don't see the case for deleting any specific one of these variations, and I doubt it's worth the effort to investigate whether there are some particularly low-value variations in the group. BD2412T02:39, 15 November 2024 (UTC)[reply]
Sure, but as Wikipedia's prose is being written now, I feel it's reasonable to standardize on something in common use today. Plus removing some of the variations wouldn't stop them from being used; it would just would mean that a wikilink target would have to be specified. I'll agree that there are more important maintenance tasks that could be done, but if someone wants to do it, I have no objection to it. isaacl (talk) 04:56, 15 November 2024 (UTC)[reply]
From the reader/searcher POV, I don't see a need for someone to spend time creating redirects from slight variations on modern names, but:
From the editor POV, if we're going to link to this in a variety of different articles (or, in this case, the refs therein), each of which might have its own WP:STYLEVAR or WP:CITEVAR, then any of these might actually be wanted.
Once the time has already been spent making the redirects, I agree with what WSC said: The cost of debating it is likely higher than the cost of ignoring it. If and when any given instance ever becomes an actual problem, we should address it at that point, but not before.
Why was Real Clear Politics deleted prior to the election and then put back in to 2024 Poll averages afterward? It turns out they were the most accurate of the aggregaters. Ticketmand (talk) 23:05, 15 November 2024 (UTC)[reply]
Welcome to Wikipedia, @Ticketmand. Have you figured out how to read the article's history page yet? If not, then Help:Page history might be useful. Looking through the history of the page, it looks like several different editors added or removed that particular poll multiple times, so whether it was in the article or not depends on when you were looking.
I don't think it is a reliable source. See WP:RSNP which has it yellow, "There is no consensus as to RealClearPolitics's reliability. They appear to have the trappings of a reliable source, but their tactics in news reporting suggest they may be publishing non-factual or misleading information. Use as a source in a Wikipedia article should probably only be done with caution, and better yet should be avoided." Doug Wellertalk16:45, 17 November 2024 (UTC)[reply]
My personal take: the goal of any poll is to statistically reflect opinion. As such, reliability is the wrong metric to use when deciding whether to mention a specific poll. Instead, we should judge it based on DUE/UNDUE weight (as we would other forms of opinion reporting). How often is the specific poll cited in sources? Is it “noteworthy” or not? Blueboar (talk) 17:17, 17 November 2024 (UTC)[reply]
I agree with Blueboar. In that article, they're all being used as primary sources. They are reliable for the claim being supported (which is "This poll said this on this date", not "This candidate is going to win" or "This poll is correct"). Editors should use their judgment about which ones to include, and they should take into account factors such as how much attention this or that poll is getting in independent sources. Overall, I think a certain amount of back-and-forth is just to be expected, as different polls will get more or less attention over time. WhatamIdoing (talk) 19:59, 17 November 2024 (UTC)[reply]
Donation season again
“The internet we were promised. 21 November: An important update for readers in Australia. You deserve an explanation, so please don't skip this 1-minute read. It's Thursday, 21 November, and this message will be up for only a few hours.”
The same damn message I saw 2 weeks ago. Seriously, do they put it up for a few hours the turn it off for a few hours in alternation?
Or is there a timestamp such that each cookie-bearing individual only sees the message for a few hours (or until the Cookie Monster visits and clears their tokens)?
I deserve an explanation.
At least now it is “we ask you, sincerely” instead of “we ask you, humbly”. The fake humility used to grind my gears.
Pre-GivingTuesday, I understand that the main US-focused campaign often runs for a few hours here and there, or perhaps a whole day, depending on what they need to test.
That said, the timing varies by country, though, so I'm not sure whether you're seeing testing at the moment or if this is the 'normal' campaign for your location. US donors often prefer to make their donations towards the end of the calendar year, but other places have other patterns. (I've heard that US editors, who are a minority of donors, tend to donate quite early in the campaign.)
Resolved
There is currently a discussion at Wikipedia:Village pump (proposals) regarding the logging functionality of the Special:MergeHistory tool. The thread is RfC: Log the use of the HistMerge tool at both the merge target and merge source. Thank you. — Red-tailed hawk (nest) 16:00, 20 November 2024 (UTC)
White
Silver
Blue
Pink
Gold
Red
Green
Skyblue
Purple
Turquoise
Black
Agree, but only slightly. If you added the letters, it would be better. Also, a solution to your region-basing could be to do a Language-based (like "O" for "Office" would become "S" for "Schoolhouse" in a theoretical "Reversed English") The Master of Hedgehogs (converse) (hedgehogs) 14:33, 17 October 2024 (UTC)
) Myrealnamm (💬Let's talk · 📜My work) 21:38, 14 November 2024 (UTC)
_2024-11-16.png){kind=link}
wikimedia.org know if you have any feedback or suggestions for improvement!
