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
Taking the temperature on NACs in CTs
This is not a formal proposal, but may be a precursor to one. WP:NAC is generally cited as the roadmap for non-admin closures. It cautions non-admins against closing potentially contentious discussions, but does not prohibit them. It is also only an essay; but the relevant policy pages that I skimmed do not appear to make distinctions between admin and non-admin closures.
We have a good few experienced non-admin closers. Their decisions are, best as I can tell, not inferior to admin ones. However, based on the caution against contentious closures by non-admins in WP:NAC, I believe they are challenged far more frequently, and consequently their closures often end up costing, rather than saving, the community time (if this comes to a formal proposal, I will do the archival research needed to show this).
I'd like thoughts on a) whether we should prohibit non-admin closures in contentious topics, as a means of saving community time on close reviews; and b) what the best way to do this would be, given that WP:NAC does not currently carry formal weight. Regards, Vanamonde93 (talk) 21:57, 18 July 2024 (UTC)[reply]
First, there are levels of contentiousness, with ARBPIA at one end and ARBBLP at the other. While non-admin closures may be more likely to be challenged for the former to the point of costing community time, I am certain that is not true of the latter.
Second, I am certain this does not apply to request moves. As a NAC, I close a lot of RM's, and as expected given the volume a number are challenged. I haven't found it any more likely that those I close within contentious topics are challenged than those outside, and given the number closed to the number contested I am certain that these closures have saved community time. BilledMammal (talk) 22:11, 18 July 2024 (UTC)[reply]
I generally think we should be offloading bureaucratic workload from admins, not piling more on. If there are specific subject areas that become magnets for poor NACs, existing processes are sufficient to curtail those without instruction creep. VQuakr (talk) 22:17, 18 July 2024 (UTC)[reply]
As a regular NAC, I'm not sure NACs are challenged more often than admin closures; even if they were, close reviews are relatively rare (for example, as of December 2023, there was an average of 2 close reviews per month as discussed here). More importantly, we shouldn't be taking editor's powers away just because some editors spuriously choose to challenge closures solely on the grounds that they were done by non-admins. As for NAC, I read that just as you do—as a word of caution, not as a command. voorts (talk/contributions) 22:35, 18 July 2024 (UTC)[reply]
Thinking out loud, but if NACs are costing the community time in contentious areas, I think it would be better to have a new "userright" (for want of a better term) called "discussion closer" that gives users who have it no extra tools but the same weight in closing discussions as an admin has. Such a right would need to be conferred in a process only slightly heavier weight than file mover - I'm thinking something like request open 2-5 days, consensus in a discussion that has at least 5 supports from admins and/or discussion closers (no consensus after 5 days = not granted). We would then recommend that discussions that are or which are likely to be contentious be closed by admins or discussion closers.
NAC would be explicitly not a permissible ground on which to challenge a closure by a discussion closer - if that's the only reason given the challenge would be speedily declined, if it was accompanied by other reasons then the portion of the statement relating to being an NAC would be struck.
Actually, even without the discussion closer status, speedily declining any review request where NAC is the only ground would be a good thing. Thryduulf (talk) 22:44, 18 July 2024 (UTC)[reply]
speedily declining any review request where NAC is the only ground would be a good thing – This, 100%. As Vanamonde noted, there's no actual policy or guideline that says we give admin closures more weight. Indeed, per WP:NOBIGDEAL and WP:ANOT, being an admin doesn't give anyone special authority over content decisions or determing consensus. To the extent that people read WP:NAC as implying that admin closes are better than NACs just because the closers have a mop, it ought to be clarified. I'm against the new "userright" because I don't like the idea that some editors determinations of consensus are weightier than others. voorts (talk/contributions) 22:55, 18 July 2024 (UTC)[reply]
@Voorts: I agree with you about the admin-non-admin distinction, but in general, there most certainly are editors who shouldn't be doing NACs. We need to allow genuinely bad closures to be reversed: we also don't want the closer's status as a non-admin to become a distraction. I'm open to other ideas on how to achieve that. Vanamonde93 (talk) 01:04, 19 July 2024 (UTC)[reply]
In such cases, the review request needs to say "this summary does not accurately/fully represent the outcome of the discussion" rather than saying "the wrong kind of person wrote this". WhatamIdoing (talk) 21:41, 19 July 2024 (UTC)[reply]
We do allow genuinely bad closures to be reversed through close reviews. If the close is so egregious, the close review will likely be a snow overturn. voorts (talk/contributions) 23:31, 26 July 2024 (UTC)[reply]
And, while this is not a great outcome, it's also not something we should fear. People learn by making mistakes, at least to the extent that they're willing to learn. Some people are resistant to learning from their mistakes; they are the ones to fear. RoySmith(talk)23:58, 26 July 2024 (UTC)[reply]
I've suggested a flag like this in the past, and I still think it's a good idea. We don't even need to say it gives "the same weight that an admin has"; we could just say that closing especially contentious or WP:CTOP discussions requires (or recommends) the discussioncloser right and bundle it into the sysop flag in addition to making it available at WP:RFPERM. The WordsmithTalk to me18:46, 1 August 2024 (UTC)[reply]
I think making it clear that only very experienced closers should close complicated or contentious discussions is sufficient. Relatedly, one of the things I look for at RFA is difficult closes the candidate has made. ScottishFinnishRadish (talk) 23:35, 18 July 2024 (UTC)[reply]
I think the type of discussion being closed plays a substantial role. For RMs and some RfCs in CTs I don't think NACs are per se a problem, but at AfD, where non-admins literally cannot close in favor of the most common outcome, we really do need to retain the current guidance. AfD NACs can become experienced at closing debates that have a relatively clear keep or ATD outcome, but they are perpetually lacking in the skill of finding consensus for deletion. A non-delete outcome is also necessarily predetermined when a NAC decides to close an AfD, which means in close cases where either a keep or a delete outcome would be within discretion they will always go for keep. And that's on top of the already strong selection bias towards inclusionism among current NACs, which would skew things even further. JoelleJay (talk) 05:11, 26 July 2024 (UTC)[reply]
they are perpetually lacking in the skill of finding consensus for deletion I think that's a bit unfair to NACs. After all, we can't close as delete, so how would you know if we can't find consensus for it. In my experience, when I see a discussion where the discussion could reasonably be closed as delete, I add it to my watchlist, skip it, and when it's closed I can see if I agree with the admin closure. voorts (talk/contributions) 13:32, 26 July 2024 (UTC)[reply]
NACs can be plenty competent at assessing discussions, but as they are not supposed to close anything where deletion would be remotely reasonable they can't develop the practical skills needed for both reading nuanced consensus and communicating that consensus. JoelleJay (talk) 22:06, 26 July 2024 (UTC)[reply]
I don't see why assessing/communicating that consensus is any different than assessing/communicating any other form of consensus. Plus, most AfDs appear to be closed without a written rationale anyways. voorts (talk/contributions) 22:09, 26 July 2024 (UTC)[reply]
But the point is that the AfDs closed by NACs should, by definition, not need a close summary because the outcome is uncontroversial. So if NACs have been following the current guidance, they could not have developed experience in closing AfDs where deletion is on the table, and especially not the ones where they would need to provide a close summary explaining why they didn't see consensus to delete. They just literally cannot cultivate that skillset. JoelleJay (talk) 22:44, 26 July 2024 (UTC)[reply]
I disagree. In an AFD with one or two good rationals for delete (e.g. "the sources do not meet GNG") but there are (many) more editors who say that that there are sufficient sources or who come after the first delete comments, I think a close summary is helpful. - Enos733 (talk) 22:50, 26 July 2024 (UTC)[reply]
I agree and I wish close summaries (and relisting comments) were a lot more common, but I think it's still true that they're not expected for uncontroversial outcomes. JoelleJay (talk) 23:00, 26 July 2024 (UTC)[reply]
As a somewhat irregular NAC-er focussed on AfDs, I can appreciate where this is coming from - although my (purely anecdotal) observations of DRV would say this is not, relatively speaking, a problem in that sphere. I think the question is less about status (admin or not) and rather experience; I wouldn't necessarily be opposed to setting some thresholds (edit count, participation etc) for NAC on CTOPs, but I don't see a strong enough case yet for exclusion. Regards,--Goldsztajn (talk) 23:29, 18 July 2024 (UTC)[reply]
Like anything else on the wiki, the qualification to do most things is that you know how to do it, and having a mop is no promise that you do. I'm sure most of the regulars at WP:AfD, admin or not, know the details of our notability guidelines better than I do; it's absurd to suggest that I'm better qualified to close a complicated AfD just because 19 years ago, 27 people thought I'd be an OK admin. Our current NAC mindset is an anachronism and should be done away with. RoySmith(talk)23:54, 18 July 2024 (UTC)[reply]
We should root out and destroy every suggestion that discussion closure is an admin task. It makes sense for the admin noticeboards, and is vestigial in most other places. I like Thryduulf's user right suggestion (I know others have suggested something similar in the past) and speedy close suggestion, though I've rarely seen a situation where NAC is the only objection. We should guide newer closers to less controversial discussions, and we should explicitly indicate that experience multiple discussions is necessary for closing contentious, major discussions. We should still allow for challenges based (in part) on lack of experience, it's just that many non-admin closers are much more experienced than almost all admins. Firefangledfeathers (talk / contribs) 01:14, 19 July 2024 (UTC)[reply]
This isn't any different from any other process. I spend a lot of time at DYK. For all the chaos that goes on there, there's an effective culture of new people being groomed to take on greater responsibility. You start out by doing your obligatory initial reviews and move on to more complicated things like building prep sets. People inevitably make mistakes, the mistakes get fixed, experience is gained, and the cycle continues. WP:GA works the same way. And WP:FA. And dozens of other nooks and crannies of the wiki where just plain editors sans mop keep everything going. As it should be. When somebody's been working in an area for a long time, they become an expert at it. The idea that some random admin who's never worked in that area could possibly do a better job is absurd. RoySmith(talk)01:37, 19 July 2024 (UTC)[reply]
I agree with Roy.
@Firefangledfeathers, even a "major" discussion on an officially Contentious Topic™ can sometimes be easy and uncontentious to summarize. The ideal result of an RFC is that everyone already knows what the outcome is. A given participant might be inclined to privately summarize that outcome as "The community is a bunch of jerks who'll be the first up against the wall when the revolution comes", but even the most passionate editor on the "losing" side can often recognize when a consensus has been reached for the "wrong" result. In such cases, we don't necessarily need a highly experienced editor to state the obvious. WhatamIdoing (talk) 21:53, 19 July 2024 (UTC)[reply]
Outside of deletion discussions and other outcomes that need an admin to carry out (where it absolutely does make sense), I view invoking BADNAC as essentially scope creep. You don't need to be an admin to close RfCs, at all. But I don't think it's fair to dismiss people who bring it up as baseless wikilawyers either. Usually what they're trying to allude to is that contentious discussions are hard to close and therefore that the community expects someone with experience in making successful closes to do it. This is a good and widely agreed upon principle, but it's not written down with a handy shortcut, so BADNAC gets invoked instead. If we articulate that broader principle somewhere, I think we'll see BADNAC cited less often. – Joe (talk) 07:32, 19 July 2024 (UTC)[reply]
Outside of deletion discussions and other outcomes that need an admin to carry out (where it absolutely does make sense). There's no fundamental reason why a non-admin can't close an AfD as "delete" and then find an admin to actually push the button. In fact, it looks like {{Db-xfd}} covers exactly this use case. This is similar to how non-admin SPI clerks can determine that an account is a sock and should be blocked and then have to go find an admin to do it for them. RoySmith(talk)14:57, 19 July 2024 (UTC)[reply]
No fundamental reason, no, but why create the extra work and complexity when we have no shortage of admins willing to close AfDs? Any process that requires admin intervention should be left to admins unless and until it becomes obvious they need the extra help (as with SPI), as matter of efficiency if nothing else. – Joe (talk) 15:04, 19 July 2024 (UTC)[reply]
I think that's over-broad. I think you shouldn't have to be a sysop to close an RfC that's about making a change to a fully-protected page, for example.—S MarshallT/C18:11, 19 July 2024 (UTC)[reply]
Pressing delete from a closed AfD feels like a situation where an admin would need to verify consensus in the first place and so now you've spent the time of two editors where one could have done. Beyond that, I am pretty staunchly opposed to admin close creep in places like RfCs. When I was a regular at AfD, I found non-admin work to be far less "right" than with RfCs; I think it attracts a different kind of non-admin. Best, Barkeep49 (talk) 04:02, 20 July 2024 (UTC)[reply]
@Barkeep49 your point about the button-pusher needing to verify the result is valid, and indeed I've made similar arguments myself. But a good close can make that job a lot easier. A good close won't just say "Consensus to delete". It'll summarize the main points made on both sides, list the minority opinions, and talk about which arguments were rejected by other discussants (or by the closer) and for what reasons. With a good analysis like that, you can get your head around the discussion without having to read every word. And, yes, the button-pusher is ultimately responsible for their actions, and I assume all responsible button-pushers will dig as far as they feel is necessary to validate the summary. RoySmith(talk)15:55, 21 July 2024 (UTC)[reply]
Most AfDs don't require a long closing statement or often don't require any closing statement. This lack of need for closing statements is a way that AfD is different from RfCs. This also doesn't change my point - it's not a good use of editor time to close something which will require substantial re-verification to implement (outside of processes like DYK which are designed to have these multiple levels of checking). Best, Barkeep49 (talk) 17:15, 21 July 2024 (UTC)[reply]
It's true that "Consensus to delete" is an adequate close for many AfDs. I would expect somebody to write the kind of detailed analysis I outlined above only for discussions that warranted it due to their complexity. RoySmith(talk)13:35, 22 July 2024 (UTC)[reply]
now you've spent the time of two editors where one could have done is true, but we don't stop people from wasting their own time. The admin would have to spend time to process the deletion regardless of whether it was NAC'd first or not. So in the NAC scenario, the only person who's time is arguably wasted is the NAC who volunteered their time to do this, and if that's how people want to spend their time, I don't see why policy should prohibit them from doing so. Arguably, two sets of eyes is a benefit anyway, so it's not necessarily wasted time at all. Levivich (talk) 23:51, 21 July 2024 (UTC)[reply]
I would distinguish between a discussion close that's a content decision, and one that's a conduct or technical decision. There are philosophical and principled reasons why we absolutely must not give sysops special authority to make content decisions. Conduct decisions in CT areas, on the other hand, are best reserved for sysops even where an unelected person could make them.—S MarshallT/C07:58, 19 July 2024 (UTC)[reply]
There are non-admins (like S Marshall) who would be in the top 10% of admins regarding closures (even if I disagree with one) if they were one. And vice versa. It's just that the odds and optics are better when it's an admin. I think that the current guidance on this is about right. North8000 (talk) 15:46, 19 July 2024 (UTC)[reply]
There a many inherent reasons for people not to close long, complicated, or contentious discussions, so I see the lessening of the pool of willing closers as throwing the baby out with the bathwater, so to speak. Alanscottwalker (talk) 16:06, 19 July 2024 (UTC)[reply]
It cautions non-admins against closing potentially contentious discussions, but does not prohibit them. WP:NAC should do more than caution, but still should not prohibit. It should advise against NAC closes of contentious discussions where consensus is not abundantly clear.
We have a good few experienced non-admin closers. Absolutely. Adminship is not a requirement for being a good closer, but being a good closer is something tested at RfA, or at least, not being a bad closer and knowing your own strengths is tested at RfA.
Some challenges to NAC closes may be unfair, but this depends on perspective. It is a fact that many ordinary Wikipedians do not consider a non admin close of a contentious discussion to be a satisfactory close. This is not a reason to slap down ordinary wikipedians, but for non admins engaging in advances functions to do it more conservatively. A good skillful close should make a contentious-looking discussion look no longer contentious.
If a non admin's close of a discussion produces another, longer, more contentious discussion, then their close was not a net positive contribution, and they should not do such closes.
We should advise non admins to not close contentious discussions unless they are very confident that they will explain their close to the satisfaction of all the participants. Alternatively put: If an admin is confident that they can close a discussion to the satisfaction of all participants, then they should be encouraged to do so. Despite being very confident, non admins are allowed to be wrong, sometimes. Don't make a habit of it. If a challenge to their close surprises them in any way, then strongly consider reverting the close and listing it at Wikipedia:Closure requests. Then, sit back and see if someone else closes it the same way.
In any discussion, the closer should be the least important person, not the most important person.
All of the above should apply equally to XfDs, RM, and RfCs. It should apply moreso to closes at AN, DRV, MRV and XRV.
Spurious challenges should not be feared. Spurious challenges are characterised by a SNOW endorse at review.
I don't think a special user-right for closing is warranted. If credentials are wanted, I suggest a category of barnstars for good closes.
If a non admin's close of a discussion produces another, longer, more contentious discussion, then their close was not a net positive contribution, and they should not do such closes. Sometimes admin closes are bad and result in additional contentious discussions. Admins aren't magically better at analytical thinking.
We should advise non admins to not close contentious discussions unless they are very confident that they will explain their close to the satisfaction of all the participants. I agree. The guidance should be "to each according to his ability". But, per my first bullet above, the same should be said for admins. If an admin doesn't feel confident that they have the chops to close a particular discussion, they shouldn't feel like their status gives them license to bite off more than they can chew.
Don't make a habit of it. If a challenge to their close surprises them in any way, then strongly consider reverting the close and listing it at Wikipedia:Closure requests. Unless a close is clearly vandalism or extremely incoherent, we shouldn't be reverting closes absent a close review. Otherwise, we invite random editors to revert closes because they think it's inadequate, leading to even more bickering and bad feelings.
I agree that Admins aren't magically better at analytical thinking, but it is a trait that we select for at RFA, so a random admin will usually do better in this area than a random non-admin. WhatamIdoing (talk) 02:58, 28 July 2024 (UTC)[reply]
Amending BADNAC?
I want to be very clear that when I opened this it wasn't because I felt some NACs were inappropriate, but because I wanted to avoid spurious challenges, or challenges where non-admin status was muddying the waters. It's fairly clear that there is strong support for not limiting NACs; so what do folks think of an alternative approach to address the problem I mention, and making BADNAC contingent strictly on experience rather than admin status: that is, essentially striking BADNAC#2, and perhaps strengthening the reference to experience in BADNAC#3? Vanamonde93 (talk) 02:45, 20 July 2024 (UTC)[reply]
I am in favor of striking #2. I think #3 could be struck too; if somebody inexperienced is really good at evaluating consensus and has read Wikipedia's PAGs, I don't see why the close ought to be overturned on those grounds alone. But, I can live with #3 as it's currently if there's consensus that that kind of limitation should be in BADNAC. Also, I've notified WT:NAC of this discussion. voorts (talk/contributions) 03:04, 20 July 2024 (UTC)[reply]
The likelihood that someone using an account with few edits will do a passable job on anything except the most obvious cases is low. Also, it gives anyone on the "losing" side an opportunity to suggest that the newbie is a bad-hand sock, which is more drama that we would like to avoid.
BTW, "experienced editor" appears to be a label that there are different views about. @Levivich and I were chatting about this at Wikipedia talk:Wikipedians#Higher volume: Can someone who has "only" been editing for a year (the median account activity is one day), with "only" 500 edits total (more than 99.25% of accounts that have ever made a first edit), averaging "only" one edit per day during the last month (less than 10% of currently active accounts), be truly considered "an experienced editor"? If you'd like to provide a third opinion (or fourth, or fifth), please share your idea of what the minimum standard for "an experienced editor" could be over there. WhatamIdoing (talk) 05:14, 20 July 2024 (UTC)[reply]
It sounds like we need to temper our expectations regarding how we treat newcomers on Wikipedia, instead of limiting them because others might have bad faith objections.
As for a rare but pertinent counterexample, I noticed Chrhns's close of an RFC within their first 50 edits. It was well reasoned, not "exceptionally obvious" and pretty much the exact close I would make too. I did end up suggesting they edit other parts of the Wiki first, simply because I know how contentious challenges can get. But should they (or editors like them but with 500 more edits) be restricted from one part of the encyclopedia just because they read the rules before they start editing?
I think it's far more important that close challenges cite an actual policy being broken instead of just BADNAC. If a close is flawed, it will be flawed on multiple grounds. Soni (talk) 11:23, 20 July 2024 (UTC)[reply]
Agree in general, CTs excepted, non EC editors cannot close or even participate in internal project discussions. Otherwise I don't object to NACs in principle, if they are messed up, as some will be, we have the procedures to deal with that. Learning by doing is not a bad thing. Selfstudier (talk) 11:30, 20 July 2024 (UTC)[reply]
Your observation that they get challenged more often could be right and a reason to advise non-admin to be careful (thus keeping it included as advice at NAC) without doing the wrong thing of making that advise a prohibition, which is what people are objecting to here. I think some data more than than the philosophical discussion above could be useful in making this kind of decision. Best, Barkeep49 (talk) 04:04, 20 July 2024 (UTC)[reply]
I will attempt to compile data in a few days. I think the problem exists regardless of frequency, however. A close challenge in which the closer's admin/non-admin status has become a factor is, I think, a priori a bad use of the community's time. Evaluations of closures need to focus on other things. Vanamonde93 (talk) 01:33, 21 July 2024 (UTC)[reply]
I oppose simply striking #2 ("The outcome is a close call (especially where there are several valid outcomes) or likely to be controversial") but suggest instead rewording it. As it reads, I don't think it is very good. I suggest, it get ideas started,
"The discussion is contentious and your close is likely to be controversial."
I think it is a good idea to put the judgement of the appropriateness of the NAC in the control of the NAC-er, and point to "the close" as the thing that will be judged. (The number of valid outcomes parenthetical is wordy verbosity)
"#3 The non-admin has little or no experience editing Wikipedia generally or has little or no previous participation in discussions." is good and important. It doesn't require touching. It is important for newbies. To make it easier for newbies to understand, I would suggest closers should have one year experience editing Wikipedia, and 500 edits in projectspace, and 100 AfDs participated before closing AfDs.
Critique or criticise the close, not the closer, absolutely yes, start there. Where the same closer repeated has their closes criticised, maybe there is a pattern of evidence to suggest a change in behaviour.
NAC-ers should be advised to be cautious in closing, not prohibited in closing. NAC-ers should be advised on how the can best help. On a quick review of old-admin closes, I think you'll find they tend to be terse. A newcomer may think that a good close is a terse close. SmokeyJoe (talk) 00:50, 22 July 2024 (UTC)[reply]
nobody can ever know in advance if their close will be controversial? Nonsense. Wrong. If you can't tell that the discussion is contested, with heated participants, and that your close does not address their positions, then you should not be closing. SomeoneTM getting upset over something silly is life, not controversy. SmokeyJoe (talk) 00:45, 22 July 2024 (UTC)[reply]
I think this is the better path. I'd oppose striking #2 entirely, but I think we can make some more room in it for places where NACs are fine by modifying that first clause which seems to be the more objectionable one. I think a small improvement would be The discussion is contentious, (especially if it falls within a Contentious Topic), and your close is likely to be controversial. While it is true that nobody can know for sure if the close will be controversial (occasionally there's an editor who just can't let go), we're only assessing the likelihood which is usually common sense. A high-profile RFC over a controversial WP:ARBPIA issue or certain parts of the MOS, for example, have a high likelihood of being controversial while a merge discussion about insects where basically everyone is on the same page is not. If a closer is unable to see the difference, they probably don't have the judgement to assess consensus anyway. The WordsmithTalk to me18:37, 1 August 2024 (UTC)[reply]
I am in favor of striking #2 and strengthening the reference to experience in #3. I think experience, not the admin bit, is the strongest predictor of good closes. Levivich (talk) 23:56, 21 July 2024 (UTC)[reply]
As I see it, BADNAC serves a couple of purposes. Preventing bad quality closes by telling editors when they might not be appropriate before they attempt to close. Providing the outcome of a close a degree of "authority" against challenges from without or within by setting some minimum standards and allowing closes procedurally to be set aside regardless content. I see the second as being less important than the quality of the close but in terms of optics, if the DAILYMAIL close was made by a 2 day account it would not have had the same weight. Therefore I do see some value in retaining a version of the current #2 somehere in BADNAC which sets a higher bar in terms of required experience for something controversial or complex than a simple snowclose. In terms of how that experience is defined, it should be related to actually closing discussions, not just general editing, and admin status should not be relevant. Scribolt (talk) 08:26, 22 July 2024 (UTC)[reply]
Just throwing this out there: there should be some sort of statement that BADNAC is not itself a grounds to challenge a close, and that challengers should focus on the assessment of consensus, not who assessed it. voorts (talk/contributions) 23:34, 26 July 2024 (UTC)[reply]
I agree with this suggestion.
That section currently ends with ...or could result in a request to redo the process at Wikipedia:Deletion review, and a footnote saying Discuss with the closing editor first before starting a deletion review. We could change it to say:
...or could result in a request to redo the process at Wikipedia:Deletion review. Discuss with the closing editor first before starting a deletion review. If you need to pursue deletion review, your explanation should focus on content. Reviews that only complain that the discussion was summarized by a non-admin, without identifying at least one substantive error in the result, can be removed without warning by any editor.WhatamIdoing (talk) 03:07, 28 July 2024 (UTC)[reply]
I'd oppose at least the last sentence of this. DRV already comes down like a ton of bricks on arguments based solely on the lack of admin privileges, and nominations based solely on that are rare enough that I can't remember the last time it happened. Advising early closes there is already dangerous, since DRVs are themselves overturned so rarely that it's only barely inaccurate to say "it never happens", and so it's important that it's gotten right the first time; simply reverting nominations is even worse, and seems very likely to me to raise the heat in what we try very hard to keep a drama-free zone. —Cryptic03:32, 28 July 2024 (UTC)[reply]
"DRV already comes down like a ton of bricks on arguments based solely on the lack of admin privileges"... so you don't think we should warn folks not to make "arguments based solely on the lack of admin privileges"? WhatamIdoing (talk) 04:08, 31 July 2024 (UTC)[reply]
I mostly object to the rest of the sentence, about removing requests. DRV doesn't even speedy close nominations consisting mostly or entirely of accusations of bias or other personal attacks anymore (despite its own instructions), let alone just blank them. I've got no problem with your suggested text up to and including the WP:FOC link; maybe add something to the effect of ", not just complain that the discussion was summarized by a non-admin." to the end. —Cryptic04:21, 31 July 2024 (UTC)[reply]
I wasn't just speaking to deletion discussions, but also using BADNAC solely as a means to challenge an RfC closure, for example, so I think we need some broader proposed language. Also, the last sentence of BADNAC is odd because it purports to apply only to "inappropriate early closures of deletion debates" (emphasis added), which doesn't really have much to do with the rest of BADNAC. voorts (talk/contributions) 06:16, 28 July 2024 (UTC)[reply]
I think the issue, if there is one, is with bad closes, not specifically with bad non-admin closes. Yes, there is a pretty strong correlation between being an admin and being a good closer, because for both it is usually best to be an "experienced editor" (I'm deliberately avoiding defining that), but correlation is not causation. Phil Bridger (talk) 09:02, 11 August 2024 (UTC)[reply]
I agree that there are many non-admins who are good at closing controversial discussions. The issue is that there are many more non-admins who are bad at closing controversial discussions than admins who are bad at the same thing. So the norm of having admins close discussions does improve the quality of closes.
Because of this, I support something like Thryduulf's discussion-closer userright but wouldn't really support weakening #2 in the meantime. Bad closures are hard to fix and even if the process goes perfectly they waste way more time and effort than just waiting for a better closer, so I'd really rather err on the side of caution here. Loki (talk) 02:37, 13 August 2024 (UTC)[reply]
Templates and WP:MOS
I thought that templates (and modules) used in articles must produce output consistent with WP:MOS. In particular, automatic calculations and unit conversions should use established output formats instead of inventing their own (especially if they are explicitly marked as "unacceptable" in MOS:NUM). Is this always true, or there might be some exceptions? And if such exceptions exist, how they should be established?
My question is general, but the confusion arose from Module talk:Age § abbr=on violates MOS in particular. I was told there (by the WP administrator maintaining the module) that "more than a mention of a guideline is needed to effect a change" and that "it would be good to get opinions from editors currently interested in affected articles rather than rely on a guideline", although without any explanations where these opinions are supposed to be collected and why they should override WP:CONLEVEL. — Mikhail Ryazanov (talk) 00:37, 1 August 2024 (UTC)[reply]
Some easy-to-see cases are at Brazilian currency#Historical currencies. This is not the right place to discuss the details but examples can be helpful to save time:
The issue is that MOS:UNITSYMBOLS says there should be a non-breaking space before the units. Another issue is that m is used as the abbreviation for month (as above) but also for minute, as in the next example from Expedition 59#Uncrewed spaceflights to the ISS.
The manual of style is a guideline, and like all guidelines should be followed unless there is a good reason not to. That is not something that can be discussed at a level higher than either the individual template or a group of closely related templates, because that is the highest level at which it can be determined whether or not there is a good reason for doing something contrary to the guidelines (and that is because the answer is always context dependent).
In the linked discussion there is the additional question of whether the specific guidance in the manual of style is correct on the specific point. Thryduulf (talk) 10:03, 3 August 2024 (UTC)[reply]
It only seems that way if you don't understand what a guideline is. Guidelines are standards that should usually be followed but must be interpreted with common sense and exceptions will apply. This means that the answer to the question "should templates obey the MOS?" is "Usually." However that isn't the question you actually want to know the answer to, which is "should this specific template follow the manual of style?" and that is something that can only be answered in the context of the individual template and so is best discussed at that template's talk page. 01:32, 5 August 2024 (UTC) Thryduulf (talk) 01:32, 5 August 2024 (UTC)[reply]
I am interested in the community consensus, not in your personal interpretation, unsupported by any references (and contradicting the fact that WP:MOS does include many exceptions for specific cases, which would be unnecessary if your ideas about ignoring general guidelines in local contexts were correct). — Mikhail Ryazanov (talk) 03:01, 8 August 2024 (UTC)[reply]
See WP:GUIDES: "Guidelines are sets of best practices supported by consensus. Editors should attempt to follow guidelines, though they are best treated with common sense, and occasional exceptions may apply.
See also the header of each guideline, which says something like "This page documents an English Wikipedia content guideline. Editors should generally follow it, though exceptions may apply." The header varies depending on the type of guideline, but they're all pretty close to that. Firefangledfeathers (talk / contribs) 03:34, 8 August 2024 (UTC)[reply]
Now we need an expert on "common sense"... WP:COMMONSENSE says: "When advancing a position or justifying an action, base your argument on existing agreements, community foundation issues, and the interests of the encyclopedia, not your own common sense. Exhorting another editor to 'just use common sense' is likely to be taken as insulting, for good reasons." And Wikipedia:Ignore all rules linked from "normally"/"occasional exceptions" explains what it actually means: "If a rule prevents you from improving or maintaining Wikipedia, ignore it." I don't think that designing a general-purpose module/template such that it systematically violates the rules without any explanations (or even mentioning the discrepancy) can be called "common sense". I also don't think that broadly using nonstandard formatting, especially if the MOS explicitly calls it "unacceptable", can be considered an "improvement" (otherwise, if this "exception" is really an improvement and is so common, it must be included in the MOS). — Mikhail Ryazanov (talk) 03:18, 9 August 2024 (UTC)[reply]
The point is that if someone claims an exception applies because it improves the encyclopaedia and another person disagrees because they think it doesn't, then what happens next is discussion. That discussion needs to take place in the place relevant to that exception so it has the benefit of full context and is visible to editors who are involved with the relevant article/template/whatever. The consensus of that discussion will determine whether the exception is justified or not.
In this case you need to participate in the linked discussion and make your case there about why you think the the exception is not justified in this particular case. Refusing to engage and just repeating that you don't think there should be exceptions is just wasting your and others' time. Thryduulf (talk) 08:40, 9 August 2024 (UTC)[reply]
Files in content categories
When evaluating the botworthiness of the task of adding the NOGALLERY tag to categories that contain non-free files, I realized that we don't have clear guidelines on when locally hosted files (non-free or otherwise) should be placed in content categories.
Is there a problem with media and articles being in the same category?
If we have a lot of local media about a given topic then it makes sense to have a dedicated category for that, but if we only have a one or two (as I guess will be the case for most topics illustrated by non-free files) then it doesn't seem useful to have a separate category, but also potentially useful for e.g. File:2 Tone Records.png to be in Category:2 Tone Records. Thryduulf (talk) 09:56, 3 August 2024 (UTC)[reply]
Why do we need exact rules? If a media file is relevant to a content category then it can go in that category, unless there is a more specific sub-category in which it fits. Create subcategories if and when there are enough pages to justify one. If there is a disagreement, discuss it. This seems to work for all other pages in categories so I don't understand why it won't work here? Thryduulf (talk) 00:04, 4 August 2024 (UTC)[reply]
The TL;DR of the bot request seems to be this: WP:NFCC doesn't allow non-free images to show in Category-namespace galleries. If a non-free image is added to a category that doesn't already have __NOGALLERY__, and editor might either revert the addition of the image to the category or add __NOGALLERY__ to the category description to suppress the gallery (I see you, Thryduulf, suggested a third alternative there that would require a new magic word be added to MediaWiki). As things currently stand, that decision would fall under WP:CONTEXTBOT as which to choose depends on human judgement as to whether the category should contain non-free images or not. LaundryPizza03 is hoping for exact-enough rules that would make it not be WP:CONTEXTBOT, since he want a bot to handle this rather than having humans work off of a database report. Anomie⚔13:46, 4 August 2024 (UTC)[reply]
"British" may refer to the island of Great Britain, or to the British Isles (which, I might add, is a controversial name in some circles), but "U.K." is short for the United Kingdom of Great Britain and Northern Ireland, which doesn't really match either meaning of "British". Donald Albury21:38, 4 August 2024 (UTC)[reply]
Many/most Irish people with enetitlements to British citizenship who live in areas governed by the UK would generally not call themselves British. Most people living in the six counties, would not consider that they live in Britain, but rather live in the UK (the legal entity) or Ireland (the geogrpahic entity). See Terminology of the British Isles for more detail. Regards, Goldsztajn (talk) 22:39, 4 August 2024 (UTC)[reply]
Until recently, my impression was de-orphaning can sometimes be beneficial (I did a bit when I was starting to edit) but, in most cases, isn't hugely significant because decent search engines are widespread. Additionally, many orphans cover naturally obscure topics which just aren't going to get many readers or improvements even if they were linked elsewhere.
However, I've been coming across cases where de-orphaning has actually made things worse, generally by giving too much weight to a subject we might not even want to have an article on in the first place. For example, I recently cleaned out a large number of dubiously-notable companies whose establishments were listed as nationally prominent events on pages like 2000 in the United States because of systematic de-orphaning.
It's become increasingly unclear to me whether de-orphaning efforts, as currently practised, are doing more good than harm. But this is based on my impressions, not detailed analysis. So I'm interested to hear others' thoughts.
It probably depends on exactly what is meant by deorphaning. Adding links to relevant articles is good, in that it provides readers a path to find new information. Search cannot help someone find something they don't know they are looking for. The 2017 and 2019 discussions however make a good point that deorphaning as an end in itself is obsolete.Stepping back slightly, is there more information on what the de-orphaning efforts as currently practised are? The adding of links where they are not beneficial is not great, but how much of it is a problem, and is it a systemic issue or a relatively occasional occurrence? CMD (talk) 06:54, 5 August 2024 (UTC)[reply]
The issue with de-orphaning is that it tends to be rather black-and-white. WikiProject Orphanage has the singular objective of reducing the backlog of orphaned articles, which can result in articles that may not meet GNG being given undue weight. Something like the introduction of an 'Orphan-Notability' template, alongside the 'Orphan' template, might help. When de-orphaning a particular article, the option of replacing the 'Orphan' template with 'Orphan-Notability' would create two lists: one for orphaned articles and another for orphaned articles requiring a notability check before they are de-orphaned. Svampesky (talk) 09:15, 5 August 2024 (UTC)[reply]
I've seen good things happen from good links. If an article has no inbound article links it gets very few page views, and thus very few edits. With meaningful links from other articles it is now being seen by readers interested in related topics, and someone reading an article on one topic is probably just the person to make good edits to a related article they click through to. It's true that low-quality links, like linking to a dubiously notable company in a large city article because the company is based there, tend to lower the quality of the established article. Cluttering it up without adding useful information for readers.
I think if meaningful, good article links can't be created to an article, that's a strong sign that the article subject is not notable. It's not a criteria for deletion of course, just an indication that a topic might not be encyclopedic, if no other encyclopedia articles should even mention it. Here2rewrite (talk) 11:29, 5 August 2024 (UTC)[reply]
+1 for I think if meaningful, good article links can't be created to an article, that's a strong sign that the article subject is not notable.. CapitalSasha ~ talk11:33, 5 August 2024 (UTC)[reply]
As an "Orphanologist" working on oldest orphan articles (beginning with 2014 backlog articles), I have seen much progress. At one point the backlog was over 120,000 articles and now about 55,000. And millions more of non-orphan articles. Prior to my involvement, the consensus is to make orphan tag "invisible" after two months. My suggestion would be to show all orphan tags. Regards, JoeNMLC (talk) 13:11, 5 August 2024 (UTC)[reply]
It always seems odd to me if an article can't reasonably be linked to other articles. This could of course mean that those other articles are missing rather than that our orphan is not notable. As for whether we use visible or invisible tags, it rather depends on whether we think the task is something we want to invite our readers to do. In its early days, yes I assume most new orphans can easily be linked into the project. After some time it ceases to be a newbie task and it requires a bit more experience of the project - does this link improve the pedia or is it visual clutter? I'm not sure whether two months is the right time and if not whether it should be increased to three or more or reduced to one. But if we were going to change the interval I'd like it done with some data as to the relative ease of deorphaning articles after one, two or three months. Ideally the link should become invisible at the point where deorphaning becomes a task we don't want to promote to newbies. ϢereSpielChequers13:33, 5 August 2024 (UTC)[reply]
I don't find this odd at all, and being an orphan isn't the end of the world. Of course some articles are crying out to be linked to (creators of new articles are often very poor at looking for links to add). I'm strongly against WP:UNDUE adding the name and a link just for the sake of de-orphaning. Johnbod (talk) 15:08, 5 August 2024 (UTC)[reply]
When this was discussed in 2017, I left rather lengthy comment. Although I no longer de-orphan to the same extent that I once did, I still think the tag is valuable as a diagnostic that signals that an article should be looked at. As I said back then, I have found plenty of instances where investigating why something is tagged as orphaned has helped me improve Wikipedia - merging duplicate articles, upmerging stubs to parent articles, creating new articles in a taxonomic chain, fixing broken links, and initiating the deletion of junk that no one has laid eyes on in years. Issues can arise when people focus more on the idea of removing the tag at all costs rather than figuring out what to do with the article, but that can happen with any maintenance backlog. Think of someone who mass-redirects unsourced articles rather than improving sourcing. Is the problem the tag, or the behavior? Let's not throw the baby out with the bathwater if we can solve the crap-links problem by dealing with whoever is doing it. ♠PMC♠ (talk)08:00, 6 August 2024 (UTC)[reply]
I agree. Even if someone deorphans by mechanically adding a See also link to a more prominent article, the watchers of that more prominent article will then be alerted to the lesser article and it then has an opportunity to be improved. ~Kvng (talk) 14:20, 8 August 2024 (UTC)[reply]
As is often the case when editing WP, de-orphaning requires a degree of editorial judgement. The problems almost always occur when people edit without discernment - adding links just for the sake of linking. The reality is that some de-orphaning links are very beneficial, while others are not. Blueboar (talk) 14:44, 8 August 2024 (UTC)[reply]
The relevant policy/guideline is actually already there:
It may be the case that some articles currently just cannot be de-orphaned. If this is the case then please do not try to 'force-fit' by adding unrelated links to articles where they don't belong just for the sake of de-orphaning. Always keep in mind that our primary goal is to improve the reader's experience, not satisfy the editor's indulgence in statistical achievements. Your priority when adding links should be to maintain article quality by adding relevant and useful links wherever possible — WP:CANTDEORPHAN
So, unnecessary links can always be removed. But it's not always bad, and the inclusion or non-inclusion criteria of certain articles in general articles such as "X year" may not be straightforward; what "degree" of notability (if a person has an article on Wikipedia that person is already notable) a person has to have to be included in "Births"?
Companies can be included in some lists by location or something else. What to put in "See also" is also covered by a guideline.
But do some articles even need to exist? I somewhat agree with other users regarding the (probable) lack of notability (though it may require changes in some notability policies). The other important thing here is the size of the article. Members of the state legislatures are presumed notable, but what if the fact that a person was a member is almost the only thing we know about them? Example. Named natural features are often notable, provided information beyond statistics and coordinates is known to exist. But for some very small streams, this "information beyond" is the etymology and what bodies of water they flow into (sometimes another small stream). Example, Example. The same doubts arise regarding small unidentified villages (that may not even exist), very small neighbourhoods or just "areas".
Finally, there are some interesting guidelines about orphans: Editors may also remove the tag from any article if they believe that de-orphaning is unlikely to be successful, or if they have attempted to provide incoming links-//-However, if you are certain the article is unlikely to ever be de-orphaned then simply remove the tag. Can this also be the answer sometimes? It can also be elaborated. For example, after some time and/or a number of attempts an article may be declared "hopeless" and the tag may be removed.
The reality is that some de-orphaning links are very beneficial, while others are not. A lot of those that "are not" are not harmful either. Oloddin (talk) 05:53, 10 August 2024 (UTC)[reply]
Let's go a bit deeper here. So far, a fair few editors have said something along the lines of "well, sometimes de-orphaning is beneficial and sometimes not", with varying emphasis on "sometimes beneficial" and "sometimes not". But what proportion of de-orphaning, in practice, is beneficial? Is it 90% beneficial, 10% not so much? 70–30? 40–60? 20–80? And where is the threshold for "this benefits Wikipedia on net"? – Teratix₵02:59, 13 August 2024 (UTC)[reply]
To go a bit broader, I would estimate that 90% of good-faith edits are beneficial. The deorphaning edits I have reviewed have about the same level of quality as the other edits I review on my watchlist. ~Kvng (talk) 13:42, 13 August 2024 (UTC)[reply]
Ukrainians in the United Kingdom vs Ukrainian diaspora in the United Kingdom
I had this big plan where I'd intentfully draft my case before even making a post here and it would have robust sourcing and all that, but I realized I should just go for it and if there's any agreement other editors will chime in.
The key summary is: the scholarly field of palaeogenetics (or archaeogenetics) has exploded in the past decade-plus. The data we can collect from the DNA of millennia-old human remains is a shocking new advancement. However, scholarly sources often use ethnic labels for the historical genetic populations they are studying. This creates friction with the universal understanding among serious people since the end of World War II that ethnicity is a social and cultural category, not a genetic one; one's ethnicity is the result of human choices and not amino acid pairs. As such, the distinct field of ethnography generally shies from ascribing ethnic identity to almost any individual that isn't the author or focus of direct literary analysis. To wit, speaking of "Lombard DNA" (etc.) is completely inane if we're to take it as face value; it is best defended as a shorthand for lack of better language to use in these papers.
That said: if one has pages for historical people groups or demographics on their watchlist, they will notice a lot of tertiary analysis of these studies being added to articles, which often transparently conflate the actual subject of the article with genetic populations analysed in a distinct manner, sometimes because that's what those sources themselves do. I think we should consider some guideline regarding the correct representation of what this information is actually saying and how it relates to the universal notion of ethnicity otherwise described in articles about them. Remsense诉07:10, 7 August 2024 (UTC)[reply]
There should be agreement in principle, the discussions on the topics I've seen (and been involved in) tend to land on ensuring that such genetic studies are not over-emphasised in relevant articles. The biggest risk is that detailed coverage of X or Y genetic study, which will use shorthands out of necessity (often explaining so in the paper), gets added to an otherwise underdeveloped article and thus turns the paper output from perhaps an academically interesting note about a certain group of people that comes with a lot of interpretative caveats, to coming off in the article as a defining trait of said group of people. I haven't seen an academic paper suggest that the genetic studies overturn ideas of ethnicity, however unfortunately the papers do get entangled with the many complex issues surrounding defining ethnicity on individual and group levels. I would support a broad guideline noting the principles of understanding the limitations and limited meaning of such studies. CMD (talk) 08:25, 7 August 2024 (UTC)[reply]
The issue isn't that academics suggest genetic studies overturn ideas of ethnicity (particularly the broadly accepted social-constuction one). Rather, the issue is that that the people doing the genetic work have a tendency to use labels as shorthands and these labels frequently coincide with ethnic terms, but they do not mean the same thing in the two contexts. Remsense is onto a for-real problem, one that I've noticed myself, but which WP hasn't really tackled. We have a general "follow the sources" habit of using whatever terminology the source material does, but we have a central purpose and principle to not confuse and even directly mislead readers, especially in a way that promotes pseudo-science (even by inference/assumption/misunderstanding). So, this is the sort of case in which we need to diverge from the (sloppy) practice of some of the specialist literature in a particular field that has mis-borrowed terminology from another, broader, and much better-established field. Exactly how to do that is open to some question. We're not in a positition to make up alternative terminology (WP:NOR), but we are probably in a position to "scare-quote" any ethno-cultural terms that are misused by geneticists and explain (perhaps in a footnote, maybe a standardized templated one) that the term in this context does not equate to an ethnic, racial, linguistic, cultural, politico-national, or other socially defined grouping, and is being used as convenience label that simply refers to a haplogroup's primary geographic locus (often by reference to a social group associated with that area). — SMcCandlish☏¢ 😼 10:33, 12 August 2024 (UTC)[reply]
The issue I mention is not with the academics, it's with the interpretation of the work of the academics here. The easiest way to not mislead readers is not to use the sources where they shouldn't be used, as has been done at various times. Talk:Colombia#RfC: Genetic ancestry of Colombians is the most recent discussion that comes to my mind. CMD (talk) 11:36, 12 August 2024 (UTC)[reply]
More the use than the interpretation. The problem can be alleviated if we:
Include |quote= in the citations.
Include a nomenclature section near the beginning of the article, explaining the variations in nomenclature and the specific nomenclature used in the article.
What I perceived to be the best solution was simply to (make it a guideline to) change the terminology used in the article—e.g. Lombard DNA → DNA of populations in modern Lombardy c. 600 AD or what have you—reflecting a responsible tertiary analysis in the context of the article as a whole. Remsense诉01:06, 13 August 2024 (UTC)[reply]
I can't help but think this is going in circles. The name "Lombardy" derives from the name of the people who lived there c. 600 AD, so how much distinction is there really between "Lombards" and "populations in modern Lombardy c. 600 AD"? How often did a group of people have limited enough exogamy to have both a distinct genetic profile and a distinct culture, so both paleogeneticists and ethnologists would be reasonably correct to use the name of the group? Anomie⚔02:09, 13 August 2024 (UTC)[reply]
The etymology of the toponym is irrelevant—it's just the modern geographical area where the modern extractions were made, as an example. Swap out with whatever name for the studied political, topographical, or geological area as appropriate/given in the source. There's obvious distinctions made between ethnic groups in a given area even in antiquity—esp. given the historical migrations of Germanic groups like the Lombards versus "native" Italians. Hence why it was a particularly illustrative example, another would be between groupings of Anglo-Saxons, Britons, and others in early medieval Britain.Remsense诉02:11, 13 August 2024 (UTC)[reply]
(edit conflict × 2) The etymology of the toponym is relevant since you're proposing saying "the people who lived in Lombardy c. 600 AD" is somehow obviously distinct from "Lombards" when "Lombardy" means "the region where the Lombards lived c. 600 AD". Or, with the attempted "clarification" in the (edit conflict), are you sure the paleogeneticists are really that sloppy that they're assuming everyone currently living in Lombardy is a decendent of the people who lived there 1400 years ago or something like that? As for the rest, you're ignoring my question and going off on an irrelevant tangent. Anomie⚔02:27, 13 August 2024 (UTC)[reply]
No, Lombardy here is meant as Lombardy, the modern region of the modern nation-state of Italy. (Sorry for the post-hoc editing.) And yes, many papers use ethnic labels as shorthand when ethnic groups are not what is being studied. Remsense诉02:30, 13 August 2024 (UTC)[reply]
Thank you for the elucidation here: I really should have picked some real-life examples from articles but I really didn't want to embarrass anyone in particular and felt the practice was ubiquitous enough that anyone with the inclination would likely know what I'm talking about. Remsense诉18:57, 12 August 2024 (UTC)[reply]
In a section above, Oloddin asked "the inclusion or non-inclusion criteria of certain articles in general articles such as "X year" may not be straightforward; what "degree" of notability (if a person has an article on Wikipedia that person is already notable) a person has to have to be included in "Births"?" I think this is a very good question, and on a quick look I couldn't find any guidelines that answered it (please let me know if I've missed it). Should the article 2000 in the United States include everyone in Category:2000 births born in the US? If no, who should it include/exclude? Nikkimaria (talk) 02:58, 11 August 2024 (UTC)[reply]
So long as a person is notable in Wikipedia terms, I would say they should be included. General year lists include everyone born in those years. I don't see why year in X nation lists should be any different.voorts (talk/contributions) 03:15, 11 August 2024 (UTC)[reply]
Shortly after that discussion, I took this "consensus" to the Village Pump and then ANI, where it was found to be a false consensus and one of the editors enforcing it was topic banned. Thebiguglyalien (talk) 06:57, 11 August 2024 (UTC)[reply]
I agree that we ought to have some inclusion criteria. International and national notability for year and year by nation articles respectively seems to be one workable guideline, although I'm not wedded to it.voorts (talk/contributions) 04:04, 11 August 2024 (UTC)[reply]
Per the RfC linked above long lists of births should be removed. Most birth inclusions also seem questionable weight-wise in general; most notable individuals were not notable at their births, and their births would not have had a significant impact on X year. CMD (talk) 07:28, 11 August 2024 (UTC)[reply]
The RfC you both mentioned was (as I understand it) about splitting rather than removing births/deaths and didn't establish a consensus where these removed births/deaths should go. It's also stated that most participants do not favor total deletion of deaths and no agreement about births. I think it's technically possible to break down "complex" year births/deaths articles into smaller articles "births/deaths in X year", "births/deaths in XX month in X year" or even "in XXX days" to cover all people (especially if we classify them further by location/nationality, occupation etc.) in an organized way. The question is whether we should do it. Regarding impact, there are some articles from time to time like "<someone famous> born this day" or "<someone famous> born 10/25/50/100 years ago". --Oloddin (talk) 02:25, 12 August 2024 (UTC)[reply]
– This RfC existed in two places. That's bad. Editors were commenting at both venues, causing the discussions to fall out of sync with each other. I have no position on which venue is appropriate, but there should not be two. I have defaulted to the original venue. If it turns out it should be here, revert me, unless that would end up recreating the problem. – Teratix₵09:57, 12 August 2024 (UTC)[reply]
Technical
XTools Edit Count down?
Since yesterday, when I bring up my Edit Count from XTools, nothing has updated in two days. Specifically, the Actrion, Patrol figure. On the Basic information, it says "Latest edit 2024-08-03 03:11" which is in error. It also lists "Latest logged action" as 2024-08-03 03:06. Something on the stats end not working? — Maile (talk) 18:48, 4 August 2024 (UTC)[reply]
Yes, there has been a high replag on both English Wikipedia and the Commons for two days now. It seems to have something to do with this. It's lasting longer than it was expected to take. LizRead!Talk!00:21, 5 August 2024 (UTC)[reply]
Actually, it seems to happen fairly frequently, I'd guess monthly or every other month. It usually happens on Thursdays or Fridays. It becomes very evident if your editing relies on bot reports. They seem the most directly affected by these system lags. LizRead!Talk!01:50, 5 August 2024 (UTC)[reply]
So the replication lag has reached three and a half days. Is this situation normal or has something gone wrong and needs to be attended to? Can an end date be predicted or is it indeterminate? Nurg (talk) 22:25, 6 August 2024 (UTC)[reply]
I poked around and was unable to find a phabricator bug report, but my searching on phabricator does not work well. It looks T367856 accounts for this outage, but there has been no communication from WMF explaining why it is taking longer than the expected 26 hours and when it might be over. Maybe there is chatter on an e-mail list. Does anyone know if the WMF has uptime targets for their servers, including replag? With this one outage, currently at 92 hours, they will be below 99% uptime for the year. We had a 3+ hour outage in May 2024, a 4+ hour outage in June 2024, a 4+ hour outage in September 2023, and probably more. That's a good four and a half days of known downtime in the last twelve months for this valuable service. Not ideal. – Jonesey95 (talk) 06:34, 7 August 2024 (UTC)[reply]
There is no guarantees for replag. It is a best effort. We are seeing a lot of this over the last 2 years because Wikimedia are doing major rearchitecting of various database tables to enable them to keep scaling, and unlike the production environment the tools environment does not have the same level of support that would allow to execute these changes without impact. —TheDJ (talk • contribs) 09:32, 7 August 2024 (UTC)[reply]
Hooray, we are over 168 hours (one full week)! (175 hours at this writing.) That's more than a full week of database reports being out of date. It's going to be fun to mop up over a week's worth of mess when this outage finally gets sorted. – Jonesey95 (talk) 17:15, 10 August 2024 (UTC)[reply]
I'm assuming that WP:PETSCAN is affected by the same problem as well, because articles that I fixed a few days ago are still showing in the search results. - X201 (talk) 08:05, 8 August 2024 (UTC)[reply]
Template:Efn used with basic parameters would usually be displayed as [a][b] etc. But, in the recent days it's being displayed as [lower-alpha 1][lower-alpha 2] etc. Why is it? Vestrian24Bio (TALK) 01:20, 5 August 2024 (UTC)[reply]
I see no problem with any of these articles, logged-in or logged-out. If no problem is apparent when logged-out, but you have a problem when logged-in, that tells me that there's something unusual about your custom settings. --Redrose64 🌹 (talk) 17:39, 5 August 2024 (UTC)[reply]
I don't see how that happens. According to mw:Parsoid, it's something to do with converting Wikitext to HTML. So, as all of our pages are written using Wikitext, and all of our readers are served HTML, the conversion process should be the same for everybody, and Parsoid must be that process. So why do I get something different from Vestrian24Bio? Has one of us turned off Parsoid, and if so, how and why? --Redrose64 🌹 (talk) 20:21, 5 August 2024 (UTC)[reply]
Yes, that would fix it, just a specificity issue it looks like. And the change looks deliberate, but 1) I'm not sure the impact was considered, and 2) I'm not sure that [style~="mw-Ref"] particularly is a nice selector for sundry reasons. Izno (talk) 01:11, 6 August 2024 (UTC)[reply]
𝕲𝕵𝕺𝕭𝕬𝕵 𝕺𝕽𝕯𝕰𝕶 𝕺𝕱 𝕾𝕬𝕿𝕬𝕹's account is global locked, even though their name is in title blacklist for only on English Wikipedia.[1] Also, why was their account even given the permission to be created, so that they can make three edits and then get globally locked? Thanks, ExclusiveEditorNotify Me!16:11, 6 August 2024 (UTC)[reply]
^.*[^\0-\x{FFFF}].* <casesensitive> in # Very few characters outside the Basic Multilingual Plane are useful in titles on local
Adding transparency to make templates more dark-mode friendly
As someone who has witnessed the transition to Fandom Desktop which had a dark mode included, I want to suggest something that might actually be good for templates, and that is adding transparency to backgrounds (not to the font, just to backgrounds using rgba or hex codes) This could be done automatically but it might be better to do so in wikitext and may be a good addition to the manual of style. This would allow the text to be colored white (or whatever) and we would not have to auto-color stuff with backgrounds black. I wonder what level of transparency would be good for this. I was thinking 0.1 but there isn't a good way to check. Maybe this could be done as a bot task for inline styles and by interface admins for CSS sheets. AwesomeAasim19:34, 6 August 2024 (UTC)[reply]
Wait that is so weird. Why is the text color being changed to this black color when background tags are used? I am just testing with safe mode and it is happening. Thoughts? AwesomeAasim22:48, 11 August 2024 (UTC)[reply]
@Awesome Aasim: The text color is changed to black because a CSS rule was put into MediaWiki that automatically sets the text color to #202122 in dark mode if no text color is specified locally. If you don't want this to happen, you can simply add color:inherit; like this: Green. Andumé (talk) 01:06, 12 August 2024 (UTC)[reply]
I am still confused why was that task implemented? They probably should have just consulted with communities first as to how they would like templates and whatnot to be implemented. Using a light/dark mode switch would be ideal but having partial transparency would be easier to implement for template designers. Especially for the number of templates that use a combination of inline styles and TemplateStyles. I think there should probably be a task for adding transparency to inline elements. AwesomeAasim16:09, 12 August 2024 (UTC)[reply]
Adding 'display:transparent' is a later stage thing and too soon to do now. Since you are mentioning templates and templatestyles, pages in the template namespace that are not redirects or subpages are 3047 and number of "styles.css" pages in the template namespace are 570. Disabling night mode styles from Wikimedia Messages needs to be done with other changes that make the whole stylesheet unnecessary. Snævar (talk) 02:27, 13 August 2024 (UTC)[reply]
Excessive "link added" notices
When a link to an article someone has created is added to a navbox, and someone subsequently edits any page in such navbox, regardless of the content of that edit, the user who created said article which was added to the navbox gets a notice that a "link was added" to that article, when that is not the case. I'm guessing the reason as to why mediawiki doesn't "register" that a link was added to a navbox in each transclusion of it has to do with the page not being purged until the next edit is made to it, but is there a way this can be fixed for link added notices? I'm aware one could just turn these off, but it does nevertheless seem like a bug. Flemmish Nietzsche (talk) 08:44, 7 August 2024 (UTC)[reply]
Not currently. From the perspective of Mediawiki, there is no difference between a link included in a page vs included via a templat, or rather what u describe a specific subset of templates. —TheDJ (talk • contribs) 09:15, 7 August 2024 (UTC)[reply]
I'm having a similar problem; I got two notifications earlier today,
A link was made from 2027 Cricket World Cup qualification to 2027 Cricket World Cup Qualifier Play-off. [3]
A link was made from 2027 Cricket World Cup Qualifier to 2027 Cricket World Cup Qualifier Play-off. [4]
I'm also confused because whenever a new notification arrives its also sent as a mail notification (only to those who preferred it). But, no mail notification is received when "A link was made" notification arrives... Vestrian24Bio (TALK) 10:06, 9 August 2024 (UTC)[reply]
Hi. For about four days I have been unable to edit articles. When I click on either the edit tab at the top of a page or the section edit tags to the right of section headings, an edit box appears to open, but a blue progress bar appears at the top which stops about three-quarters of the way across the page. As a result, I have an edit box where I can work, but no way to save my changes. Exceptions that do work are: 1. on pages like this one, the tab at the top that opens a new section; 2. clicking on "reply" on a talk page; and 3. clicking on "undo" in an article history. Those open functional edit boxes (hence I can write this). But regular editing is effectively blocked. Does anyone have an idea what the problem might be? (Incidentally, for the last year I have successfully been using the 2017 wikitext editor. I don't know if that is the problem, but I can't find any way to access it to switch it off.) Doric Loon (talk) 00:25, 8 August 2024 (UTC)[reply]
The blue progress bar you describe is probably the loading animation for the Visual Editor. In your Preferences you can uncheck the checkbox named "Enable the visual editor". Then Save the changes with the Save button near the bottom of the page.
I am not sure what could cause this problem, and I never use the Visual Editor. Programmers often, but not always, put error messages in the Javascript console when something goes wrong. Depending on which browser you have you could try pressing F12 to open the Developer tools, and then clicking on "Console" and then loading a webpage with the Visual Editor enabled (which will fail) to see if it generates any error messages. If there are any error messages this may be useful to whoever tries to diagnose the problem. Polygnotus (talk) 12:34, 8 August 2024 (UTC)[reply]
OK, I seem to have solved it by unclicking "Use the wikitext mode inside the visual editor, instead of a different wikitext editor This is sometimes called the '2017 wikitext editor'" in Preferences. Perhaps this plug-in is no longer working. Shame, I did find it helpful, how it marked coding in different colours. Anyway, problem solved, thanks. Doric Loon (talk) 15:56, 8 August 2024 (UTC)[reply]
Exactly as title. The checkbox states that it would last a year, yet sometimes I would find myself not logged in even though I am using the same device, same browser, etc. It is just a mild annoyance, but can someone give me pointers on how to fix this? Thanks in advance. —Mint Keyphase (Did I mess up?What have I done?) 01:26, 8 August 2024 (UTC)[reply]
Anything that clears or blocks your local storage (cookies) can invalidate your saved logon. Some browser or browser extension updates can cause this. — xaosfluxTalk15:10, 8 August 2024 (UTC)[reply]
FWIW I was logged out unexpectedly under similar circumstances on the day this was posted as well. I use Windows primarily with Chrome; if you also have a similar configuration, that *could* be an explanation. Graham87 (talk) 04:26, 9 August 2024 (UTC)[reply]
@Mint Keyphase: Do you use uBlock Origin like me? That's the only thing I think we could have in common. But even that would be a pretty common combination .... it could've just been bad luck. I suspect a lot of people wouldn't report being unexpectedly logged out, because it's a relatively minor inconvenience; I certainly didn't think to. Graham87 (talk) 12:10, 13 August 2024 (UTC)[reply]
The obvious method is to make a long list of all the templates, and all redirect to those templates (and filter out those that are not used in mainspace), that should appear above the maintenance templates. But that quickly turns into a giant list and a lot of work. Isn't there a smarter way to do this? Is there some kind of Javascript library I can import? Polygnotus (talk) 16:09, 8 August 2024 (UTC)[reply]
Figured it out (somewhat) by stealing getting inspiration from Twinkle's code. [5] which uses morebits [6]
It sounds like the next step is to set this up to be a default gadget, and we should work out the details for that. In one discussion, MusikAnimal also suggested that this gadget only be loaded for pages that need it, and that this could be done using categories.
With these parameters in mind, is this how we should set up the MediaWiki:Gadgets-definition? Is everyone OK with moving forward?
Prior discussion was that perhaps these should be un-opt-out-able (i.e. hidden gadgets), primarily to not pollute the gadget list. I'm not sure that is needed though, and could always be revisited after this goes live. — xaosfluxTalk15:01, 8 August 2024 (UTC)[reply]
So barring any objections, the next steps are: update the pages to somehow include the category; move the gadget from test to template-gadgets with updated parameters. — xaosfluxTalk15:07, 8 August 2024 (UTC)[reply]
Using a consistent template-gadget category naming convention isn't strictly necessary but I think it has benefits (in this case, just change the included trigger category, or add an additional cat, in Template:ImageStackPopup). — xaosfluxTalk15:13, 8 August 2024 (UTC)[reply]
I am unsure which talk page is the intended place to ask for this since most redirect to WT:RFPP (which, if it was the intended place, is protected), but is there any way to change the form (the Request protection button), so that it does this automatically? – 2804:F1...20:147 (talk) 20:26, 8 August 2024 (UTC)[reply]
Is there any side effect to just adding the colon in the section titles there? It seems like that's what the pagelinks template already does (and many others).
Add A Fact experimental tool from Future Audiences
The Future Audiences team at the foundation is launching Add A Fact, an experimental tool for adding information to English Wikipedia from outside the website. You can download the extension from the Chrome store here: Add A Fact. For now, an (auto)confirmed English Wikipedia account is required to submit facts with this extension.
The idea was developed and workshopped with Wikipedians at WCNA 2023, demoed and tested with Wikipedia community members as part of our team’s regular monthly community calls.
Here is a short demo video on the extension:
A quick how-to —
While reading any secondary source on the web (a news item, a scholarly article, etc.), you can open Add A Fact and highlight a short claim that you may want to add to Wikipedia.
An LLM will check if the selected claim is related to any existing Wikipedia articles, and will present information about whether the fact is fully, partially, or not present in these articles. You may also search for an article of your choosing.
Once you select a Wikipedia article to add your fact to, Add A Fact will give you the option of sending a pre-filled template message to the talk page of the article, which includes the selected text, any additional comments you’d like to add, and a structured citation. This message will be signed under your Wikipedia username.
If the URL of the source you are on appears on WP:Reliable_sources/Perennial_sources, you will receive a warning message about your source’s reliability (but will still be able to add a suggested fact from this source). If the URL of the source you are on appears on the spam blocklist, you will not be able to add a suggested fact from this source.
To limit any potential misuse/spam, Add A Fact users will be limited to sending a maximum of 10 facts per day during this early experimental period.
Add A Fact seeks to prove or disprove a hypothesis about how we might continue to sustain and grow Wikimedia projects in a changing online knowledge landscape. In this case, we’re seeking to understand how people can make editorial contributions off-platform (that is, without going directly to Wikipedia.org), and if generative AI can support or hinder this process.
If it's a a chrome extension, it will work on Vivaldi, which is better than all previously mentioned browsers, imho. Another possibility is Opera, which can also use the extension, but Vivaldi is better. (We can take this offline to my UTP, or yours, if you wish to go into more detail about browsers.) Mathglot (talk) 00:01, 13 August 2024 (UTC)[reply]
That's a good point. We tried to have the tool warn you about unacceptable sources but encoding all the nuances of the rules is hard. But doing this better is something we should look more into. DErenrich-WMF (talk) 23:05, 9 August 2024 (UTC)[reply]
Having the demo advertise a kind of edit that should never be done is hardly a "nuance". Wikipedia got a good reputation for how it handled the COVID crisis precisely because editors stuck to standards that your demo tells people to avoid. XOR'easter (talk) 21:11, 11 August 2024 (UTC)[reply]
The message left on the talk page, will that include some template or tracking category, so that editors can easily find a list of facts to be added, and act upon them? Otherwise, especially if the facts are posted on lesser-watched talkpages, it'll be like shouting into the void. --rchard2scout (talk) 06:30, 10 August 2024 (UTC)[reply]
Will we be able to find out how many facts posted to talk pages have been reviewed and used in articles, as opposed to rejected, and how many have not been considered at all (eg because of being on a less-watched page)? In what other ways will this tool be evaluated? For example, how might we detect an increase in, as the close of Wikipedia:Administrators' noticeboard/IncidentArchive1160#User:Drbogdan, persistent low-quality editing, and WP:NOTSOCIALNETWORK issues put it, mass-adding content based on low-quality popular science churnalism to our science articles, expecting that other editors will review it and determine whether to improve or remove it, leading to an indefinite community block? NebY (talk) 01:56, 11 August 2024 (UTC)[reply]
Once the experiment is complete (probably in a few months) we will put together a report with our findings. See for example the report for the last project we did. The metrics we're looking at are the kind of things you'd expect: number of users, number of edits, number of reverts, etc. But probably more importantly we're also collecting qualitative evidence (e.g. discussions like this one, feedback forms or by manually looking at the edits being made). DErenrich-WMF (talk) 04:09, 11 August 2024 (UTC)[reply]
@DErenrich-WMF Reverts aren't a meaningful metric for this tool. The tool will post on the talk page and talk page posts are rarely reverted. The only revert metric that would be useful would be the number of resulting additions to the article that are reverted, but that would be very difficult to collect.
Instead, a viable metric would be the proportions of talk page facts that were implemented, rejected, or not acted on. If tool postings used a format similar to {{Edit semi-protected}}, this might be feasible. It would also be immediately helpful to reviewing editors.
It is a bit surprising that the experiment hasn't been designed to allow meaningful reporting and evaluation. Is there some need to to start the experiment regardless, or can you build suitable metrics into it before release? NebY (talk) 14:45, 13 August 2024 (UTC)[reply]
Let's please find a way to make this tool avoid good and featured articles. The last thing we need is to be experimenting with new users and our content that has actually gone through some sort of content peer review. Hog FarmTalk21:21, 11 August 2024 (UTC)[reply]
Yes, that's interesting; I have it installed (on Vivaldi) and will be trying it out.
But I have a proposal for you, that imho, would be far more useful that I would like to bring to your attention. Basically, it means flipping the script on Find-A-Fact and doing it in the other direction. That is, finding an assertion on Wikipedia (possibly with the aid of the Category populated by {{cn}} tags), highlighting it, opening your next extension, which goes to AI and tries to find a reliable source to verify it. (It would possibly use WikiProjects listed on the Talk page to better target its search, and would be aware of perennial sources, as well as the WP blacklist, WP mirror sites, and other helpful exclude- or include-criteria.) It would read the source(s) (up to max-sources maybe?) and then pop up or fill a box with the citations, optionally augmented with better wording (Reword (y/n)?) for the assertion that currently exists in the article. At that point, there could be two paths (Talk or Article?): if user wants to go the Talk page route (default) then you do something similar to what Find-a-Fact does, and compose something for the talk page. If they want to go the Article page route, then you open the article in Preview mode, add the citation(s), optionally replace the existing assertion if AI was able to compose a better one and user selected that option, and show a Diff of the new version you are proposing, along with a canned edit summary. (Note that this flow, i.e., OpenPage-AddChanges-Preview-Diff-and-Wait, is similar to what some user scripts do currently, such as Nardog's RefRenamer script.) Then, user either accepts the change, optionally modifies the edit summary, and hits Publish, or they Cancel, or they go back to the extension box, altering options and checkboxes and hit Apply to try again with a different set of options. How does that sound? Mathglot (talk) 00:35, 13 August 2024 (UTC)[reply]
Getting Cite errors and CS1/CS2 errors for an article via the API
I want to get information about Cite errors and CS1/2 errors via the API. The input should be the title of a Wikipedia article and the output should be either a list of cite errors or a list of CS1/2 errors (or a combination).
On this article I can see that the API reports that there is a CS1 error, but not what the actual problem is. I have added the CSS found here so I can see the specific CS1 error when viewing the article in my browser. But how can I get this information via the API? It looks to me like Module:Citation/CS1/Configuration generates the error messages; does the fact that the error is generated by this Lua script mean I can't get this information via the API? Or do I have to get the rendered page to get the actual HTML and search that for error messages?
Is it possible to detect (via the API) if an edit causes a CS1/CS2 error before actually making the edit?
There are roundabout ways, but otherwise, the answer to does the fact that the error is generated by this Lua script mean I can't get this information via the API is yes. Each error emits a category but you will only know which categories go with which citations by using something like the mw:API:Expandtemplates on the source wikitext. If you don't care about knowing which templates have which issues, you can use the categories API. Another solution is to get the HTML and then search for the relevant classes with e.g. mw:API:REST API though I think there are other APIs one could use (even ignoring screen scraping).
Is it possible to detect (via the API) if an edit causes a CS1/CS2 error before actually making the edit? Only with something like the above. Izno (talk) 02:27, 10 August 2024 (UTC)[reply]
Cite error
On Brainwashing I see a cite error on ref 87: Cite error: The named reference they-never-said-it was invoked but never defined (see the help page). Which API call should I make to get this information? I assumed it was this (Sandbox).
Is this also handled by a Lua script somewhere? What is the URL? It looks like its using MediaWiki:Cite error references no text but I can't seem to find a Lua module referencing that. Is it in a MediaWiki extension written in PHP?
Do I have to get the rendered page to get the actual HTML and search that for error messages?
How would I detect (via the API) if an edit causes a cite error before actually making the edit?
It looks like I am at least able to find errors before they happen with action=parse, but those are warnings from the parser, not the Lua script(s). Is that correct?
These errors originate from mw:Extension:Cite. You can explore the documentation there, but I do not think there is anything to indicate errors in an API. Besides whatever categories are emitted, as discussed above, but that would not tell you which references caused an error I believe. Izno (talk) 02:30, 10 August 2024 (UTC)[reply]
I have noticed a problem with accessing all of the tag options when using Twinkle.
I switch between mobile to desktop when I need to use Twinkle, in most instances the full drop down menu is fine, I can scroll up or down to find the correct message I need. When trying to add a welcome message for new users the scroll doesn't work though. I can only access the initial few welcome messages but that's it.
I also have the same problem with tagging articles in the mainspace. I've found an article published to the mainspace and it doesn't have any references. I wanted to tag it as such but I am unable to scroll down the menu to the correct option.
Most of the Twinkle options are fine, such as CSD, I can scroll down to view all the options. It seems to be a problem with Welcome messages and article tagging. Am I doing something wrong? Thanks in advance, Knitsey (talk) 15:42, 10 August 2024 (UTC)[reply]
Polygnotus, I completely missed the OS bit! Android, version 14 if that makes a difference. The scroll down options always used to work. I've been on a Wikipedia break for about 8 months, come back and those two sections no longer scroll. Knitsey (talk) 02:13, 11 August 2024 (UTC)[reply]
I use my mobile. Switch to desktop to use Twinkle. It is just those two menus that I can't scroll down... Welcome messages for new users and the tag menu on articles.
The Twinkle menu for vandalism warnings is fine, I can scroll down on that. The same for CSD, I can scroll down on that too.
With Welcome messages, I can always go back to using templates for now. I'm just curious as to why those two drop downs and whether it cwn be fixed. Knitsey (talk) 03:01, 11 August 2024 (UTC)[reply]
Can someone take a look at the Warburg Institute article? The title is being italicized (when it should not be); it uses {{infobox journal}} later in the article, which auto-italicizes, but it's set to "no" as the template says so presumably this should not be happening. Aza24 (talk)01:35, 11 August 2024 (UTC)[reply]
Some of the entries are referring to historic/stale accounts. It's hard to gauge. I was thinking add a column, "Page last edited". Is this information available somehow, given the name of a page, return the date of last edit? It's not a perfect solution but some information is better than none, recent activity will be more visible. -- GreenC04:19, 11 August 2024 (UTC)[reply]
What's the technical or by design reason for the limitations of the editing tools on the mobile version? Many of the tools that you can add through code particularly don't seem to show up in any form in the mobile format. Is there any features pipeline to introducing this functionality? Iskandar323 (talk) 10:47, 11 August 2024 (UTC)[reply]
Countervandalism, Twinkle and a few other tools work recently on mobile. I would recommend making a wish entry at Meta:Community Wishlist/Wishes. In short I agree that mobile lags behind desktop which is concerning considering the future of editors is mobile. ~ 🦝 Shushugah (he/him • talk) 12:18, 11 August 2024 (UTC)[reply]
In large degree this is due to having to make very conscious decisions about where to provide such options, as space per page is limited. As very few people think about this, there is also very little progress on it. —TheDJ (talk • contribs) 09:02, 12 August 2024 (UTC)[reply]
Strange behaviour for en embedded infobox
I just copy-edited the article on Philip Noel-Baker, which had a separate infobox (actually the {{MedalTableTop}}) with Olympic medals, which I embedded into the main infobox.
It's possible to embed a medal table in an infobox without using those templates but there were other problems. A separate medal table looks OK to me. PrimeHunter (talk) 21:26, 11 August 2024 (UTC)[reply]
There isn't bad code in MedalTableTop as far as I know, you just used it wrong. It was never intended for infoboxes but for stand-alone tables. It adds a table start {| but an infobox is already a table. PrimeHunter (talk) 01:33, 12 August 2024 (UTC)[reply]
@HandsomeFella: OK, I worked it out. In this edit, you were trying to stuff the whole medal table into the caption of an embedded infobox, viz. the |name= parameter of the {{infobox sportsperson}}, and a <caption>...</caption> element may not contain tables as descendants. Instead, you should have used the |medaltemplates= parameter, and omitted the {{MedalTableTop}}, as in
| awards = [[Nobel Peace Prize]]
| module = {{infobox sportsperson| embed = y
| name = Philip Baker
| medaltemplates ={{Medal|Sport|[[Athletics (sport)|Athletics]]}}{{Medal|Country|{{GBN}}}}{{Medal|Competition|[[Athletics at the Summer Olympics|Olympic Games]]}}{{Medal|Silver|[[1920 Summer Olympics|1920 Antwerp]]|[[Athletics at the 1920 Summer Olympics – Men's 1500 metres|1500 m]]}}}}
}}
'''Philip John Noel-Baker, Baron Noel-Baker''', {{post-nominals|country=GBR|PC}} (1 November 1889 – 8 October 1982),
Thanks. That fixed the problem that I mentioned below. Now my problem is that the sportsperson box ignores the name= parameter. Like so many other people, peers included, he competed under another name, so it's needed. HandsomeFella (talk) 17:46, 12 August 2024 (UTC)[reply]
The main name parameter is for display above the infobox but that doesn't work for an embedded infobox so it's omitted there. The other name parameters can be used but the field label displays as Native name, Birth name, Full name, or Nickname. The label cannot be changed and none of them apply here. I see no good option and would just omit it. PrimeHunter (talk) 18:04, 12 August 2024 (UTC)[reply]
Thanks. But if the Native name, Birth name, Full name, and Nickname parameters are available in embedded mode, surely the Name parameter could be made available too, couldn't it? HandsomeFella (talk) 19:04, 12 August 2024 (UTC)[reply]
It could be suggested at Template talk:Infobox sportsperson. Native name, Birth name, Full name, and Nickname are treated the same in embedded and non-embedded: As fields inside the infobox. Name is outside the box in non-embedded so it's not possible to treat it the same in embedded. It would be possible to place it inside the box instead of skipping it, or to introduce another parameter. What should the field label be? I think "Name" alone is a little confusing when the whole infobox is already named. Is there any common term like "Athlete name", "Competing as", or something? What if they competed under two names, e.g. new surname after marrying? And if the name is a variation of an already shown name then is it really necessary to show it? Your example article is called Philip Noel-Baker, the infobox says "Born Philip John Baker", and you want to add "Philip Baker" to his sports career in the infobox. That seems a little redundant to me. PrimeHunter (talk) 02:52, 13 August 2024 (UTC)[reply]
Thank you. I have tested it now (in preview), and it seems that the "sportsbox"
1) does not "fill out" the main infobox – in this case infobox officeholder – to its full width, and
2) aligns to the right within the main infobox.
Is there any way to fix that? I found no align parameter in either infobox. In the sportsperson box, the width parameter goes to the image. The double-border situation feels like a minor problem. HandsomeFella (talk) 17:43, 12 August 2024 (UTC)[reply]
How are you searching? If you search a viewed page with a browser menu or a shortcut like Ctrl+f then you are using a browser feature and not a MediaWiki feature. The browser will determine what happens. I get the same result in Firefox. If you search a source edit box with the magnifying glass icon to the far right after clicking "Advanced" in the default toolbar then it's a MediaWiki feature. It works for me, e.g. when editing Linear B. There are also other tools which can make searches. PrimeHunter (talk) 01:25, 12 August 2024 (UTC)[reply]
Reba McEntire has 13 "Harv warnings" in its references. (I have Wikipedia:User_scripts/Requests/Archive_4#HarvErrors.js installed.) All the warnings are coming from the multi-reference sources - Ref #205, #210, #211, #214, #216, #222, and #224. The sfn/Harvard cite system can be tricky to get the coding right...
I have run into this issue before on another article and I still cannot figure out how to fix it. Could some of you technical/referencing/wikicoding wizards take a look at the article and respond here with what is wrong and how to fix it. I would very much appreciate learning 1) exactly what is going wrong and 2)learning (and then remembering) how to fix the issue so 3) please let me fix the problem at the Reba article myself. Thanks, Shearonink (talk) 16:28, 12 August 2024 (UTC)[reply]
It appears to have been the asterisk (*) inside <ref>...</ref>. I removed the asterisks and added a line break between the two cites in one place, which cleared the problem. See the Medley citation. I didn't fix the other cases. Donald Albury17:05, 12 August 2024 (UTC)[reply]
That is not the correct fix. The warning message is telling you that the citation is notlinked from an {{sfn}} or {{harv}}-family template. If you want to suppress the messages, in the cs1|2 template set |ref=none:
But why then is "ref=none" necessary for the second citation below, but not for the first?
*Reba in Concert (1992)Sources for 1992 tour:
*{{cite magazine|date=February 22, 1992|title=Reba in Concert|magazine=Billboard|volume=104|issue=8|page=31|location=Nashville, Tennessee|publisher=BPI Communications|issn=0006-2510|access-date=October 23, 2020|url=https://worldradiohistory.com/Archive-Billboard/90s/1992/Billboard-1992-02-22.pdf|archive-url=https://web.archive.org/web/20200808083051/https://worldradiohistory.com/Archive-Billboard/90s/1992/Billboard-1992-02-22.pdf|archive-date=August 8, 2020}}
:::*{{cite news |last1=Pareles |first1=Jon | title=Taking the Country Out of the Country Singer |url=https://www.nytimes.com/1992/10/26/news/review-music-taking-the-country-out-of-the-country-singer.html |newspaper=[[The New York Times]] |location=[[New York City]], [[New York (state)|New York]] |date=October 26, 1992 |access-date=October 23, 2020|archive-url=https://archive.today/20201023023153/https://www.nytimes.com/1992/10/26/news/review-music-taking-the-country-out-of-the-country-singer.html |archive-date=October 23, 2020|ref=none}}
Each cs1|2 template creates a CITEREF anchor id as a link target for {{sfn}} etc templates. The anchor id is listed in the warning message, for example, the anchor id for your second example is: CITEREFPareles1992. The CITEREF anchor id is created from author names (only the first four) and the year portion of the date. The Billboard template does not have any authors so a CITEREF anchor id is not created. The warning script is smart enough to recognize that nothing can link to a cs1|2 template that does not have a CITEREF anchor id. Because there is no CITEREF anchor id, it is not necessary to suppress it with |ref=none.
OK. So there are fixes that will take care of the "Harv warning" issues. I'll puzzle my way through and fix stuff. But can someone again explain, as if to a non-coder - lol which I certainly *am* - 1) exactly why the bundled cites are not working as intended and 2)why this issue isn't discussed and explained as if to a non-coder in the Help:References and page numbers#Shortened footnotes & in Help:Shortened footnotes#Bundling citations & in Wikipedia:Citing sources#Bundling citations. If I've noticed - and I am certainly not one of the most prolific editors around here - at least 2 instances where the bundled citations are throwing Harv warnings then there have to be many, many more. Thanks, Shearonink (talk) 01:38, 13 August 2024 (UTC)[reply]
What do you mean by: the bundled cites are not working as intended? What about those cites is not working? Are you claiming that they don't work because the user script is marking them with warning messages? (this version (permalink) of the article)
Likely because these messages are only available to those editors who have included a user script in their common.js that emits such messages. In your common.js you have installed User:Trappist the monk/HarvErrors.js. That script has a documentation page (current version not authored by me so perhaps more understandable than what I might write).
When the warning message appears, it is generally not necessary to do anything except to look for typos in the surnames and dates. If {{sfn|Green|2024}} is supposed to link to {{cite book|last=Greene |date=2024 |title=...}} and these are the only pair for Green(e) 2024 you will get three messages:
For the sfn: sfn error: no target: CITEREFGreen2024 (help)Harv error: link from CITEREFGreen2024 doesn't point to any citation.
For the full citation: Harv warning: There is no link pointing to this citation. The anchor is named CITEREFGreene2024.
All because of a simple misspelling. When there really isn't Greene 2024 (with an 'e') short-form citation linking to a long-form citation, the script doesn't know that so it prompts editors to check. This same applies to the date; Green 2023 will cause the script to emit the same basic messages. If a short-form is not needed, editors can set |ref=none to suppress the warning message. It is not necessary, but is a courtesy to editors coming after you so they don't waste their time trying to find a matching short-form citation.
First, you removed the article title when you hover a link, now when you click a link while previewing or close a tab/window when editing there's no more warning message. Can they please be restored? Nearly but not perfect (talk) 20:01, 12 August 2024 (UTC)[reply]
For the first, try: Appearance > Reading preferences > Enable page previews. Or, are you talking about the page url appearing in the status bar of your browser (often at the bottom border)? That would be a browser preference, I believe. Mathglot (talk) 20:32, 12 August 2024 (UTC)[reply]
(edit conflict) I don't quite understand the other question, about closing a tab. It sounds like it might be a browser question, but I don't know for sure what you are seeing. Can you explain step-by-step what you are doing, using a concrete example? E.g.: 1. open the NameOfArticle article in (name of my browser) on (type of my device). 2. (do this) 3. (then do that) 4. ... . RESULTS: Expected: (what you expected to happen) Result: (what happened instead). Thanks, Mathglot (talk) 21:01, 12 August 2024 (UTC)[reply]
For some years now, Windows has had a feature where the taskbar shows icons for currently-running applications, and if you hover over one of them it shows you what is currently displayed by that application, in miniature - scaled at a ratio of approx. 6:1.
The latest release of Firefox (129.0) has added a similar feature: if you have two or more tabs open, and hover over a tab that doesn't have the current focus, it shows you what is currently in that tab - but scaled at approx. 4:1. --Redrose64 🌹 (talk) 22:45, 12 August 2024 (UTC)[reply]
If "Enable page previews" is enabled at Special:Preferences#mw-prefsection-rendering or "Navigation popups" is enabled at Special:Preferences#mw-prefsection-gadgets then you are supposed to get a preview of the page content when you hover over a link to an article. If they are both disabled then you are supposed to see the page name. Or more accurately, the html for the link has a title attribute which is the page name, and most browsers will display the title attribute when you hover over a link. Are both preview preferences disabled? If you still don't see the page name then what is your browser? PrimeHunter (talk) 22:56, 12 August 2024 (UTC)[reply]
@Mathglot: When I'm editing something, I would make a change. Before I save it, especially when I'm previewing, when I close the tab, there used to be a warning on Chrome (I'm using Chrome on Windows 10) "Leave page? Changes may not be saved" or something. That disappeared. Nearly but not perfect (talk) 04:23, 13 August 2024 (UTC)[reply]
193.133.134.xxx (talk·contribs) – couple hundred edits, 2001–2002; but if you click that contribs link, no edits are listed
The anomalies/question:
why is CIDR search even picking up the second one, if that's just a normal, registered username, which to my understanding, it should be?
Otoh, maybe it isn't, because the link User:193.133.134.xxx doesn't do what I expect, namely going to a user page or to a create-page preview, but it does neither, instead going to the Contributions page. Huh??
Clicking the contribs link Special:Contributions/193.133.134.xxx shows an empty page, but the CIDR/24 link shows a couple hundred edits; wtf? Following any of the links shows they really did make early edits to those pages, such as:
rev. 427352463 at Motorcycle on 15:06, 8 October 2001 (-43,537b, ok, but that anomaly I'm aware of)
Bonus question: that rev id for Motorcycle above has a lot more digits than I would expect for an early edit. What's up with that?
If you go to the contribs link for 193.133.134.xxx and click Search (link) the result shows a red warning complaining about invalid username. But if you replace 'xxx' with 'yyy' and Search, it is valid. udpated to add #6; by Mathglot (talk) 22:09, 12 August 2024 (UTC)[reply]
Some very old versions of the software stored IP addresses with the last octet replaced by .xxx, and the current software still recognizes them as IP addresses. I don't know why they aren't showing up in contributions, though. The reason the Motorcycle revision has so many digits is because it was manually imported in 2011. * Pppery *it has begun...20:42, 12 August 2024 (UTC)[reply]
Thanks. Either someone fixed #2 super-quick, or something else is going on, because now the red link in #2 goes to a create-page preview, as I expect, but it didn't before. Mathglot (talk) 20:51, 12 August 2024 (UTC)[reply]
Redacted addition point #6 might support that, as IP-xxx seems to be supported in some places (CIDR contribs) but not others (point 6). Mathglot (talk) 22:12, 12 August 2024 (UTC)[reply]
@Graham87: Thanks. The CIDR/24 link will show, if you go to Preferences > Gadgets > Advanced, and check "Allow /16, /24 and /27 – /32 CIDR ranges on Special:Contributions forms". Mathglot (talk) 07:23, 13 August 2024 (UTC)[reply]
So, you do see the contributions for the range, now? If not, maybe this is a case where the native support doesn't match the gadget in one circumstance? Mathglot (talk) 07:55, 13 August 2024 (UTC)[reply]
How does that gadget work? Perhaps it is just doing a prefix search? If so, it would find 193.133.134.xxx and that would be a problem in the gadget. Johnuniq (talk) 08:22, 13 August 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.
Stewards can now specify if global blocks should prevent account creation. Before this change by the Trust and Safety Product Team, all global blocks would prevent account creation. This will allow stewards to reduce the unintended side-effects of global blocks on IP addresses.
Do you mean when viewing Special:Watchlist? Here's a CSS rule that hides both:
/* hide edits to redirects and redlinked pages from watchlist */li.mw-changeslist-line:has(a.mw-redirect),li.mw-changeslist-line:has(a.mw-changeslist-title.new){display:none;}
I know this must be an extremely dumb question, but please bear with me.
I have just finished drafting a long article (7,000 words readable prose) in my User space. I asked a friend for comments and was told there is no Table of Contents (TOC). This seems to be the case: unless you are logged in (which my friend wasn't), an article displays with no TOC. This seems to hold for any article, in mainspace or otherwise.
Can this really be true? It makes long articles very difficult to read for readers who are not logged in (i.e. most of them). I have tried forcing a Table of Contents with but it makes no difference.
It seems kind of difficult to believe that the average, casual reader of Wikipedia articles doesn't see a Table of Contents (unless he/she knows to force the display).
Thank you, I believe you are right that it has to do with the default vector-2022 skiin. That said, it doesn't fix the basic problem i.e. the Average Joe doesn't get to see a TOC. My friend has a big, wide laptop. Ttocserp23:37, 13 August 2024 (UTC)[reply]
Ok, I now see that the problem is not what I thought it was. A TOC does display down the left-hand side, but only a rudimentary one (only level 2 headings). So I guess to fix that I have some learning to do.Ttocserp00:36, 14 August 2024 (UTC)[reply]
Some of the headings, for example the one for Add A Fact experimental tool from Future Audiences on this page, should have > symbols beside them. Clicking the symbol opens the further levels. NebY (talk) 00:47, 14 August 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.
Back in 2017, the community decided in this RfC that moved pages should be unpatrolled. The feature was stuck in Phabricator purgatory and was never actually implemented.
I'm really surprised so many people supported that: it would create a substantial added burden for patrollers in exchange for maybe making a very rare problem slightly easier to detect. (Redirects from page moves already go into the queue, and even if they're retargeted elsewhere, a good reviewer should notice the suspicious history.) Unless this is a much larger-scale issue than I'm aware of, I don't think that proposal should be implemented. Extraordinary Writ (talk) 08:00, 21 July 2024 (UTC)[reply]
I have seen cases (e.g. recently at AT CBS This Morning) where a long-standing patrolled page becomes unpatrolled because a non-autopatrolled user moved the page - like from vandalism being reverted like CBS This Morning, or from requested moves like (709487) 2013 BL76. There can be quite a lot of these cases. Is this scenario also part of this discussion? thanks. Aszx5000 (talk) 09:36, 21 July 2024 (UTC)[reply]
@Aszx5000 That specific behavior is part of a bug that started happening recently and will be probably reverted. It's being tracked in T370593. The default behaviour is to not unpatrol page that are moved. Sohom (talk) 10:00, 21 July 2024 (UTC)[reply]
I think the RfC should be respected. Yes, WP:CCC but we really shouldn't overturn an RfC without an new RfC. Besides, this will help with detecting move vandalism in some cases so it is a useful change. Nickps (talk) 12:32, 21 July 2024 (UTC)[reply]
Oppose: If the RfC hasn't been implemented in 7 years, and it was only recently implemented by accident, it makes sense to revisit the discussion instead of implementing it by surprise so much later on in time. As one of the more active patrollers, I absolutely hate the idea of adding to the workload / massive backlog by adding pages to the queue just for being renamed. Really we'd want to just mark it as patrolled 99% of the time anyways. Hey man im josh (talk) 14:49, 21 July 2024 (UTC)[reply]
FWIW, I attempted to figure out how much moving and patrolling actually goes on so I could see if making it necessary to re-patrol moves would indeed add a significant workload. I came up with 916 moves and 1225 patrols yesterday. My SQL is weak (and my understanding of the MediaWiki schema even weaker) so I don't know if these numbers are accurate or not. If they are, then it looks like this would almost double the patrolling workload. RoySmith(talk)15:33, 21 July 2024 (UTC)[reply]
Though, as usual, raw statistics are misleading. Neither of our queries, for instance, try not to count page moves by autopatrolled users, or pages moved out of the main namespace without leaving a redirect or where the redirect was later deleted. I can at least compensate for the small sample size by showing stats for all of July up to now, which are better: 7068 page moves starting in mainspace, 13519 mainspace page curations. —Cryptic16:55, 21 July 2024 (UTC)[reply]
Oppose. I don't see much of a point in implementing this as it would unnecessarily double the workload of the NPP team. Redirects left behind from moves are already placed in the redirect queue (except for users in the page mover, autopatrolled, and redirect autopatrolled groups, including administrators). DannyS712 bot then automatically reviews a portion of them if the changes fit certain criteria, and the rest are reviewed manually. I feel like this system works just fine; it's not like we have a runaway page-move vandalism issue on our hands. —TechnoSquirrel69 (sigh) 17:50, 21 July 2024 (UTC)[reply]
Oppose. To quote myself from 2017: Oppose pending more information. I'm concerned about rushing into something that will potentially hugely increase the load at the already hugely-backlogged WP:NPP. How many pages are moved per day? How many more reviewers would we need to handle the extra load? What's the scale of this problem? Are there other solutions we could explore (e.g. marking pages that have {{disambig}} removed as unpatrolled)? We have the answers to some of those questions above, and it's not looking good. Doing this would double the NPP workload in order to close a loophole that is apparently so small that nobody noticed it had been accidentally left open for the last seven years. Really bad idea. – Joe (talk) 21:35, 21 July 2024 (UTC)[reply]
Comment: the proposal as it developed in the 2017 RfC was not for all article moves but for those by non-EC users which I think was 40 a day at the time. Cenarium's comment is not clear to me but search for "40" (not pinging them because they have not edited since April). Pinging @Ivanvector: who initiated the proposal for their comments. We don't know if this is still a concern or if other mechanisms were put in place. S0091 (talk) 19:39, 22 July 2024 (UTC)[reply]
not for all article moves but for those by non-EC users which I think was 40 a day at the time. This somehow ended up not reflected in the 2017 RFC close and not reflected in the 2017 Phabricator ticket. We could go off on a tangent about whether that RFC was closed correctly or not, but I think it's a non-issue because we'll get a fresh consensus in this RFC that will override any lack of clarity about the previous close. –Novem Linguae (talk) 23:58, 28 July 2024 (UTC)[reply]
??? I don't know that area that well because that not normally where I do my NPP work but I thought this was already happening. For example Extracorporeal procedure was in the cue. The community really needs for fix some things to help with the disaster at NPP but worrying about easy stuff like this really isn't it. North8000 (talk) 20:28, 22 July 2024 (UTC)[reply]
Oppose: Unnecessary. They will almost always be marked as reviewed immediately, so this just adds a pointless burden to the NPP queue. CFA💬22:15, 28 July 2024 (UTC)[reply]
Blame and Wikiblame have the same goal, but they're separate tools/separate software code. Someone might want to have access to both tools, but they should be side by side in the list.
On the other hand, Wikiblame should not be in the list with Wikidata, Wikinews, Wikibooks, and other sister projects. But Commons and Wiktionary should be in the list of sister projects, and I don't see them. WhatamIdoing (talk) 05:24, 27 July 2024 (UTC)[reply]
@WhatamIdoing. Hopefully I haven't given off the impression that I am offering an exhaustive overview. Commons and Wiktionary are just as welcome. My main focus was on getting some relatively hidden tools to be accessible via 'Analysis'. Infogiraffic (talk) 08:32, 29 July 2024 (UTC)[reply]
As a proof of concept, I think it's fine. I wouldn't personally find it very useful, because I'd rather type than look for anything in a menu. But others, especially those less familiar with MediaWiki software, likely have the opposite preference. WhatamIdoing (talk) 16:29, 29 July 2024 (UTC)[reply]
Both tools serve the same purpose (revision history tracking) but have separate codebases. Ideally, they should be grouped together under a single, clear label like "Revision History." While some users prefer keyboard shortcuts, menus can be helpful for those less familiar with MediaWiki. Perhaps a balance can be struck? We could consider a hybrid approach with both keyboard shortcuts and a more intuitive menu structure. What about submenus for categories like "Analysis Tools" (where "Revision History" would reside) and "Sister Projects"? BlackOrchidd (talk) 08:46, 7 August 2024 (UTC)[reply]
Afd to Prn/Pcn
Can we rename Articles for deletion to Articles for checking/Reviewing notability which will give a positive impression than the present one. 103.66.169.3 (talk) 19:36, 26 July 2024 (UTC)[reply]
I think this is one of the perennial proposals, and the answer is "not necessary" (at any rate, it would require rewriting thousands of lines of active software, and moving half a million pages). jp×g🗯️22:15, 26 July 2024 (UTC)[reply]
The French Wikipedia did this, perhaps two years ago. AIUI they thought the communicative value (e.g., that we are here to check notability, not necessarily to delete the page) outweighed the one-time hassle. (Also, you don't have to move the prior pages; you can just move a few key pages, like Wikipedia:Articles for deletion itself, and leave the old ones alone.) WhatamIdoing (talk) 05:39, 27 July 2024 (UTC)[reply]
It was indeed a huge undertaking; no, we do have to move a huge amount of pages (as my major work 'bot did); and as JPxG points out there is more in place nowadays that is hardwired to the page prefix (from the templates that we invented at the same time, to people's private add-in scripts) than there was back then. Moreover we are not checking notability. We are deciding whether an administrator hits a delete button on an article, for those cases where it isn't obvious on sight that the article should be deleted and 1 person alone can safely make the decision to press that button. It's a very clear name for the very single purpose that it is there for. Stuff outwith the decision about whether an administrator hits a delete button or not is intentionally left to the editorship at large. Uncle G (talk) 02:08, 28 July 2024 (UTC)[reply]
I'm also old enough to remember the VfD days. Anyway, AfD has its problems. What it's called is not one of them. Let's worry about stuff that matters. RoySmith(talk)02:25, 28 July 2024 (UTC)[reply]
@Uncle G I appreciate the clarfication that this tool is focused on assisting administrators with clear cut deletion decisions, leaving broader editorial judgments to the communiity. Maybe having a name that reflects this purpose, like "Rapid Deletion Assist" or something similar, could be helpful. BlackOrchidd (talk) 09:15, 7 August 2024 (UTC)[reply]
"Rapid Deletion Assist"? Did you mean Category:Expired proposed deletions? Or perhaps WP:CSD? Or perhaps Special:Nuke? Also AfD is a venue and a process, but not a tool (those are pieces of code).Maybe we should leave the name as is, so we don't have to rewrite thousands of scripts and move a half million pages. If there's one deeply embedded major nomenclature failure on the project, it's Notability. The amount of confusion about / discomfort with AfD would need to increase by two orders of magnitude before it would be worth renaming at this point.Apologies for the grumpiness. My keyboard keeps crashing, which I hate is a thing that is possible. Folly Mox (talk) 10:12, 7 August 2024 (UTC)[reply]
I agree with Uncle G, the current name has a clarity that said replacements would not have. Even if the new name is somewhat less intimidating to newcomers, it's better to be upfront about what's happening. ― novov(tc)06:14, 28 July 2024 (UTC)[reply]
Rename to Articles for Discussion?, in line with the other XFDs. I had a similar query and sometimes feel uncertain about nominating articles when I'm on the fence if they should be deleted/merged/redirected. The 'AfD' acronym is also maintained. Svampesky (talk) 23:11, 30 July 2024 (UTC)[reply]
Currently if a user clicks "Add a topic" on an article talk page, a box appears which prompts them for a "Subject" and a "Description".
"Description" is somewhat cryptic in that context, and seems like a placeholder string that was never reassessed. A talk page message or question isn't really a description of anything. In some contexts (like Talk:ChatGPT and Talk:Google, talk pages which ended up locked in response to so many people mistaking "Add a topic" for a direct query to those services) asking for a "Description" may, to some users, look more like a prompt to communicate privately with a generative AI or web service, rather than the start of a human conversation with Wikipedia editors.
I raised the suggestion more broadly at the idea lab earlier in the year and was told that, regarding a change to this specific interface message, altering these strings will affect all pages. This change has to be very carefully considered. So here's a concrete proposal to change it. Will "Your talk page comment" make sense in all contexts where this string is displayed, and would we agree that it was an improvement on "Description"? Belbury (talk) 14:06, 8 August 2024 (UTC)[reply]
We can certainly improve on "description", and "Your talk page comment" would be such an improvement although I am not immediately certain it is the best we can do - especially if this appears anywhere other than talk pages? Perhaps something as simple as "Your message" would work? Thryduulf (talk) 14:13, 8 August 2024 (UTC)[reply]
I think our motivation behind keeping it so aggressively-generic was that we weren't sure what places were using the "new section" form that this takes over, and we wanted to avoid something like "start a new discussion thread" as being too specific to only talk-page workflows. (The thing to watch out for is places outside the talk namespaces, that use __NEWSECTIONLINK__ to get that behavior...) DLynch (WMF) (talk) 17:12, 12 August 2024 (UTC)[reply]
Thryduulf, oops, looks like the URL contained NEWSECTIONLINK, which caused it to be parsed as the prop and not as a URL. I've edited it to add "deletethis" — follow the link and delete those words and then it'll work, or just use Anomie's better method below. Sdkbtalk02:20, 13 August 2024 (UTC)[reply]
I don't know how to use the API or run db queries, but the special page worked. I've not got time right now to look in detail, but that reports there are a lot more uses in non-talk namespaces than I expected:
Many of these are going to be appropriate (e.g. on this page, the portal page titles suggest they are nomination spaces) but I wonder especially about the articles. Thryduulf (talk) 02:17, 13 August 2024 (UTC)[reply]
I suspect the articles will turn out to be either vandals being weird or people not knowing what stuff does and throwing a bunch of magic words on the page trying to get Google to index a new article. Of the handful I spot-checked, I saw one that seems like the former and a bunch that seem like the latter. Anomie⚔02:36, 13 August 2024 (UTC)[reply]
This is a smart suggestion; thanks for raising, Belbury! I'm inclined to support "Your message" for conciseness and to be on the safe side given Thryduulf's concern that it might be used outside of talk pages. Sdkbtalk15:15, 8 August 2024 (UTC)[reply]
I agree with the idea, but would be inclined to suggest "Your comment", given that "Your message" might still be mistaken for a ChatGPT/Google/etc. prompt query. Chaotic Enby (talk · contribs) 18:06, 9 August 2024 (UTC)[reply]
"Your comment". Just based on widespread, almost universal Wikipedia terminology. Messages are for emails and texts—things that are sent, not posted. ―Mandruss☎18:22, 9 August 2024 (UTC)[reply]
Deploying Edit Check on this wiki
While attending Wikimania this year, Selena Deckelmann (User:SDeckelmann-WMF) demonstrated a new feature for Visual Editor, Edit Check in a session. Edit check introduces additional prompts in Visual Editor when an editor tries to insert a blacklisted URL as reference and also when they try to publish a revision without inserting a reference. This greatly helps with encouraging editors inserting references in their edits. If I recall correctly, the percentage of editors inserting references increased from 11% to 40% in their tests (do correct me if I am wrong as I am going off on my recollection).see #What's next? for corrected stats
There is certainly some benefits in enabling this, primarily on improving the verifiability and reliability of content that's on English Wikipedia. Most of the sister projects have already been deployed with this feature. English Wikipedia does not have this feature enabled yet. The only thing that is holding back this feature is that Visual Editor is not set as the default editor for anonymous and new editors.
Therefore, I would like to propose that:
Visual Editor be the default editor for anonymous and new editors.
The last time I checked, new editors are presented with a pop-up box that asks them to choose which editor they'd like to use, with the solid blue button pushing them a bit toward the VisualEditor.
This thread is rather underdeveloped. For a proposal of this magnitude, I think we should figure out relevant factual questions (like what the current default is) and then draw up a more formal survey that could be CENT-listed, etc. Sdkbtalk19:05, 9 August 2024 (UTC)[reply]
Another question is how does it work with edits that don't need references adding (e.g. creating redirects, adding links on disambiguation pages, fixing spellings, etc)? Thryduulf (talk) 19:08, 9 August 2024 (UTC)[reply]
In theory, this sounds like a great idea. I'm eager to try it out, but I think a first step would be to make it available as an opt-in on enwiki. Then after people have got some experience with it, let's come back and talk about making it the default. RoySmith(talk)20:09, 9 August 2024 (UTC)[reply]
There's a simpler option for userscripts that should work: window.MWVE_FORCE_EDIT_CHECK_ENABLED=true;
So long as that's there before VE loads, it should force you to have edit check. Either method also bypasses the account restrictions on edit check, so you're not quite getting the pure experience that people would if we just turned it on for enwiki. By default it only shows up for new users (defined as under 100 edits), and someone might want to edit the configuration on-wiki for that. DLynch (WMF) (talk) 21:26, 9 August 2024 (UTC)[reply]
The add-reference check is very conservative currently. You need to be a user with less than 100 edits who has added a whole new paragraph of at least 50 characters (configurable per-wiki) that contains no references before it'll pop up. This can all be loosened up in the future, whether by default or through community configuration, but we figured that those criteria had pretty low odds of being a false positive to start with.
It's quite interesting that this boosts the percentages so much, because I honestly thought that complete new-editors would be doing far more minor edits. But no, major new blocks of text are pretty popular.
It's actually turned on with the reference check everywhere but 8 of the wikipedias (bn, de, en, hi, id, nl, pl, ru), so it's pretty easy to try it out on another wiki if you don't want to jump through userscript hoops here. DLynch (WMF) (talk) 21:34, 9 August 2024 (UTC)[reply]
Not sure where ReplyTool will put this, but nothing I'm seeing in the documentation requires VE to be the default editing interface in order to deploy the new tool. So deployment doesn't seem contingent upon answering the larger question of whether VE should be default. Folly Mox (talk) 22:17, 9 August 2024 (UTC)[reply]
Unless things have changed in the last year, it doesn't need it to be the default, but editor does need to be in the visual editor, and that's somewhat more likely to happen (especially for the editor's first edit) when the visual editor is the default. WhatamIdoing (talk) 01:29, 10 August 2024 (UTC)[reply]
The functionality is targeted towards new editors and anonymous editors, therefore the need for Visual Editor to be the default before the deployment of the functionality is considered complete. Also there are on wiki configuration options that we may want to adjust. As stated by Dlynch (WMF) above, the tool is configured by default for an user with less than 100 edits and making revisions of more than 50 characters. – robertsky (talk) 04:15, 10 August 2024 (UTC)[reply]
Minor quibble: enwiki has already got the prompts about blacklisted URLs for references/links. We rolled those out everywhere on the logic that any edits involving them were going to get blocked-on-save anyway so it wasn't going to disrupt any workflows. :D
It's a bit fuzzy because we called the project "Edit check", and we're developing a specific system called edit check (of which the "add reference" check is the first example), but we're also doing smaller edit-enhancement features along the way that colloquially get called checks just because of the project.
Conduct a thorough analysis of the potential consequences of setting Visual Editor as the default for anonymous and new users. Consider factors such as user experience, editor retention, and overall editing patterns. If making Visual Editor the default is not feasible, investigate other strategies to increase Edit Check adoption. This could include targeted outreach to experienced editors, promoting the feature through in-editor messages, or developing incentives for reference usage. Regardless of the chosen approach, it's essential to closely monitor the impact of Edit Check on reference usage and article quality. This data will be crucial for refining the feature and measuring its overall effectiveness.
I'd support making Visual Editor the default, as long as they also leave wikitext editing as an option (which I'm sure they will). VE is much better nowadays than when it was first released. As a WYSIWYG editor, I suspect it is much more new editor friendly. It is unarguably better at things such as automatic citation generation and table editing (adding and removing columns and rows, moving columns and rows around). And for the few things it is bad at (such as complicated template syntax), power users can just switch to wikitext editing. Any logged in user can select their default at Special:Preferences (under "Editing mode"). –Novem Linguae (talk) 10:47, 10 August 2024 (UTC)[reply]
I totally agree that VE should be the default for new users. I use VE every day, and it's just fine for most stuff, and getting better incrementally. Folks who think VE should not be the default should go to edit-a-thons and try teaching new users. 20 years ago, wiki-markup was the new hotness and was miles ahead of editing raw HTML. Today it's just a barrier to entry for potential new editors. RoySmith(talk)12:24, 10 August 2024 (UTC)[reply]
When I first edited English Wikipedia as an IP editor, I found WikiText editing very difficult to understand. I’m sure that most new IP editors face this issue. I strongly support making the Visual Editor the default. New IP editors are often unfamiliar with Wikipedia and may not know how to cite a reference using the WikiText editor. They may also not know how to switch to Visual Editing. Frankly, I still have to check the preview before publishing edits using the WikiText editor because I sometimes make mistakes. GrabUp - Talk11:08, 10 August 2024 (UTC)[reply]
Potentially minor bugbear alert: The visual editor reference creator still hasn't figured out the basic functionality of allowing for an easily accessed and obvious use of an |author= field, instead forcing all authors into |last and |first. It's not a groundbreaking issue, but it's really disappointing that it's still around after so long, especially given the many words given over the years about attracting more diverse perspectives etc. The default reference tool that we are going to create a pop up asking all new editors to use should allow for sources from authors whose names don't fit into the common European name format. It may be hidden behind an additional field button, but at least the wikitext reference creator has the option. CMD (talk) 12:10, 10 August 2024 (UTC)[reply]
My biggest bugbear is the lack of ability to set a reference name. For example in this edit I switched from visual to source editing so I could reuse citations between prose and infobox. Although admittedly this is not something a brand new editor wants to do, being able to set a name other than ":0", ":1", etc would be rather handy. Thryduulf (talk) 12:28, 10 August 2024 (UTC)[reply]
Is naming references a policy? Or is it something you consider useful? I don't edit the code. I just reuse citations when I need them, directly from the citation insertion menu. Very convinient. 37.169.50.102 (talk) 12:52, 11 August 2024 (UTC)[reply]
I mostly work in VE; I'm not personally bothered by the opaque names (i.e. ":0") that VE invents because I never see them. But many people work in wikitext, where having human-friendly names is important. So, I agree that improving support for reference naming should be a high priority. RoySmith(talk)12:57, 11 August 2024 (UTC)[reply]
I just went looking, and I don't see a Phab ticket for this. I was a bit surprised there was no ticket, but then I thought about it a bit more. It's probably hard to come up with a wiki-agnostic way to generate good citation names. You'd have to program it with something very enwiki specific to get it to read our unique citation templates then extract the author last name and year from them. User:Nardog/RefRenamer is a good workaround though. –Novem Linguae (talk) 13:14, 11 August 2024 (UTC)[reply]
I thought we were talking about auto-generating good names. Those tickets are for something else. Maybe I am misreading this subsection though. Apologies if we are not actually talking about auto-generating good reference names. –Novem Linguae (talk) 13:20, 11 August 2024 (UTC)[reply]
When copy pasting named references to another page, you get false matches that are not obvious. If automatic named references were more unique (slugified title) this false collision would happen less often. I am all for hiding/abstract workflows where needed. ~ 🦝 Shushugah (he/him • talk) 13:03, 11 August 2024 (UTC)[reply]
All programmers should read Falsehoods Programmers Believe About Names, and then re-read it every few years to refresh their memory. People who design database schemas should re-read it every time they start a new project. I agree that it's not a showstopper for our purposes, but it is a surprising lack of cultural sensitivity from an organization which is so into i18n.
For me, the biggest bugbear is that there's no good way to convert a {{cite web}} into another template without basically starting from scratch. It really should be smart enough to figure out that if {{cite web}} has a "first=" field, it can safely map that into {{cite news}}'s "first=" and so on. It won't be perfect, but it'll get you most of the way there. RoySmith(talk)12:57, 10 August 2024 (UTC)[reply]
@Chipmunkdavis @RoySmith Visual editor follows the definition of the template parameters at Template:Cite web#TemplateData (and so on for other cite templates). I think the developers would also wish that you didn't require the name to be split into two fields; it's a chore to fill it out this way. If you think this can be changed, please edit it there. Matma Rextalk13:58, 10 August 2024 (UTC)[reply]
@Matma Rex you are entirely correct that VE gets its field definitions from the templates. The first part of my comment about first_name/last_name ethnocentricity applies equally well to template writers.
But, the part about being able to convert one type of citation to another really is a VE issue. The "automatic" feature of the VE template editor is very handy, but it often can't intuit the proper type of template (that's not VE's fault) and falls back to using {{cite web}}. It would be really handy if you could say, "Please make that into {{cite news}}, and do the best job you can converting the fields". RoySmith(talk)14:38, 10 August 2024 (UTC)[reply]
|author= is already present in the existing template parameters, even if just as an alias of |last. Not presenting the alias in VE is a choice of VE, the buck should not just be passed to blindly following a particular table. CMD (talk) 14:56, 10 August 2024 (UTC)[reply]
It might be controlled by the WP:TEMPLATEDATA in something like Template:Cite/doc. I think VE reads the template data to determine the parameters it displays. If a parameter is omitted or set as hidden, perhaps it is not displayed. Not 100% sure but that is probably worth checking. –Novem Linguae (talk) 15:08, 10 August 2024 (UTC)[reply]
Assuming it is, then it would be really useful to have some statistics of how often VE (I know, I should really be saying Citoid or Zotero, or something else, but I'll just keep saying VE because that's what the end user sees) gets it wrong. I'm not entirely sure how we would define "gets it wrong", but a first pass might be "VE initially calls it {{cite web}} which is later corrected to a different {{cite xxx}} variant". Some of that might require instrumentation inside VE to detect when the user abandons a constructed citation before saving it. Some of it might require analyzing revisions to the page to see when template types are corrected after the fact. But let's assume one way or another, we could build a log of incorrect categorizations.
Then what we would do is take the full log of these reports, group them by top-level domain, and sort by frequency. If it came out that "bxtimes.com" was the most frequently domain which got mis-categorized, then it would be the highest priority for a human to go figure out how to fix and add that knowledge to the VE (Citoid? zotero?) database. After enough iterations of fixing the highest priority ones, we'd end up with a better system. If (total SWAG here) we could find the 100 top problems that accounted for 50% of the total errors, with a very small amount of human work to fix them, we could have a major win.
It sounds like a reasonable stab at the misassignment-of-citation-templates issue.
Caveat up front: I'm a developer, but I've never actually touched the internals of Citoid+Zotero, so I might be wrong about details here. That said, I believe you're right that the classification part happens entirely in Zotero, and further that if you want to teach Zotero about how to classify a new site there's some guidelines we have for that over on mediawiki.org. This coming from Zotero is also why we have vastly more classifications than we actually use on-wiki -- check out the mapping for that.
It's possible that some of the incorrect template-usage you see could be at the level of those mappings, as well -- I note that the `statute` type is just hooked up to the generic `Citation` rather than to {{Cite_act}}, for instance, though that's probably far from the most common one to need.
As for the specifics of working that list-of-sources out...
We do have some instrumentation inside VE already that could probably be looked at to work out how often someone gets all the way to the "presented with a citation-template" step and then abandons it, which would give us an okay up-front guess at the rate where something is wrong with the generated citation. Ignoring the question of other types of failure for now, the next problem is that our VE usage-instrumentation is carefully ignorant of content for privacy reasons, so it doesn't know anything about what URL was looked up when that happened. Looking for revisions which consist of just a citation template being replaced with a different citation template sounds doable, albeit slow.
I wonder if we could approach it another way. Assuming that Zotero has some internal logging of the translator it used when we make a request to it, or that it can be persuaded to tell Citoid this, we could perhaps add some logging for requests that fall back to the default-translator for unknown pages. That's not a perfect match for the misclassifications, but it's much easier to find. It does leave out cases where the translator exists but is getting it wrong, of course. DLynch (WMF) (talk) 01:46, 11 August 2024 (UTC)[reply]
it doesn't know anything about what URL was looked up when that happened does it know/track what type of template it chose? If so we can possibly work out what proportion of e.g. cite-news vs cite-web generations were abandoned? I don't think, ottomh, there would be any privacy issues with that? Thryduulf (talk) 01:53, 11 August 2024 (UTC)[reply]
Unfortunately not. All it tracks is that a citoid request happened, and then either that the "insert" button was chosen or that something was done to move away from the citoid results list. It doesn't even track what type was chosen if you go to the "manual" tab and explicitly pick one of the templates listed there.
I do agree it seems very unlikely to be a privacy issue. I mostly mentioned that was the guiding principle to explain why the case for so many questions like this turns out to be "we never needed this actually-very-innocuous content-related data before, so we weren't collecting it". DLynch (WMF) (talk) 02:09, 11 August 2024 (UTC)[reply]
Superb Owl has been maintaining a table of domain names where mw:Citoid has trouble producing a correct citation at User:Superb Owl/Community Wishlist § Automatic Citation Tool. As I understand it, Citoid's problems are partially due to how it scrapes target pages, and if domains are not putting all the information we need in <meta> tags then our only recourse is to improve Zotero translators directly.However, Citoid is understandably geared towards internationalisation and extension to all Wikimedia projects. En.wp has a considerably more complicated / sophisticated / mature citation framework than probably anywhere else. Little things like an automated citation using {{cite web}} instead of {{cite news}} or {{cite periodical}} don't bother me: User:Citation bot converts these, and the only template type it really struggles with is conversion to {{cite book}}, which has a pretty different parameter set.What does bother me about the automated citations output by the Visual Editor (apart from all the <ref name=":0">) is how often it just dumps out obviously incorrect information with no message to the user. Things like |last=B.C. |first=Sima, Qian, approximately 145 B.C.-approximately 86 (1); |last=Company |first=Rand McNally and (2); |last=Feb. 1 |first=the Office of Communications on |last2=2019 |last3=P.m |first3=3:06 (3); |last=à 00h00 |first=Par Le 2 avril 2008 (4); |first=Government of Canada National Research Council|last=Canada (5), etc, etc, etc, bonus consequence.A few days ago, I floated the idea to add a layer of error-checking into the VE citation generation interface. That's really all we need, I think. It shouldn't be the responsibility of WMF staff to ensure that every citation generated by their tools somehow makes sense for our project. But if there could just be one extra step for editors using the interface, where they could see the errors their automated citations are causing our community-maintained modules to throw, maybe they'd take the steps necessary to compare the output against the source and correct the problems before publishing.This won't fix every problem, obviously: algorithmically generated citations are only perfect when they draw on structured metadata that maps properly and completely onto our template parameters. But being able to get feedback during the edit should help editors in the VE environment clean up some of their own messes before they hit mainspace, unreviewed at the bottom of the article. Folly Mox (talk) 12:37, 11 August 2024 (UTC)[reply]
@RoySmith, @DLynch (WMF), @Folly Mox, speaking from experience from creating Zotero translators for a couple websites that I frequently use for citations, errors like this are more often than not a byproduct of missing specific Zotero translator rather than anything else. The default translator will interpret og:type = article as itemType = 'webpage', therefore citiod will use {{Cite web}}. This is unfortunate as even in the default translator's own test cases, vox.com is expected to return as 'webpage' for itemType. However, I would agree with this output, as in Open Graph Protocol, the last object type specified is 'article', and I am assuming that that's the fallback for Facebook as Facebook would use the embedded preview for articles if there's no og:type in the header (i.e. Facebook debugger on wikimedia.sg).
Therefore, what's needed to be done is to either have another translation layer on citiod to map generated citations from identified websites to use {{Cite news}} instead of {{Cite web}}, or write a specific translator for bxmedia.com, or investigate if the default translator in Zotero can be extended further so that the rework for specific websites can be minimal. – robertsky (talk) 18:16, 11 August 2024 (UTC)[reply]
Actually, passing Citoid's output directly to Citation bot before returning it to the editing interface – one specific implementation of another translation layer – sounds like a minimally effortful solution using tools already deployed and currently maintained. Citation bot doesn't fix everything (and breaks some things) but it usually does a good job in selecting which template type to apply to a citation, and in mapping data to appropriate parameters. Folly Mox (talk) 18:35, 11 August 2024 (UTC)[reply]
Yes. I have it enabled as an user script. It just won the Coolest Tool Award for improving the quality of edits. While I appreciate the work there, I also wish there is an easy way to translate the JSON files to Zotero translator format so that the work can be enjoyed by those who cannot use it out of the box on Wikipedia and everyone else who is using Zotero in general. – robertsky (talk) 08:36, 12 August 2024 (UTC)[reply]
65, I had heard of that tool, but wasn't previously aware of its functionality. It looks like a great idea, but for the fact that it is presented as an option to Citoid's output rather than a replacement of it (community generated translators for domains Citoid struggles with should – by definition – always be superior).I'm not interested in apportioning blame for Citoid's output: generalised parsing of html meta elements across the entire set of domains is a hard problem and a big task, with a lot of people involved in every step. But it remains true that for a significant portion of domains lacking structured metadata, Citoid's output ranges from suboptimal to unusable.Any additional translation layer that can be configured by the community would be superior to none, and that functionality should exist in Visual Editor so as to improve the quality of citations generated and reduce the maintenance burden shouldered by script maintainers and experienced editors on this project. Folly Mox (talk) 11:29, 13 August 2024 (UTC)[reply]
Please post corresponding Phabricator tickets for all mentioned "bugbears". 1) Having tickets for these things and 2) making noise in them is the best way to move these fixes forward. –Novem Linguae (talk) 14:31, 10 August 2024 (UTC)[reply]
Thanks all who have participated in the discussion above. I wil admit that this is my first time opening a proposal. Apologies if it is lacking in some details. While early, it seems that at this juncture, there a large support among the participants to have Edit Check deployed and/or Visual Editor be set as the default editor, keeping in mind that there are still some bugbears, or wishes to have some citations related issues resolved (honestly, I think belongs to another thread, but I appreciate the discussion nonetheless). I would like help in bringing this proposal to the next step of having it as a CENT discussion, be it by opening another thread/discussion here or elseswhere, or reformating the current one.
Impact report
In the opening, I presented a wrong statistics from the test that the product team conducted. Upon further check, I found the impact report on reference checks. Short of reproducing the whole report, these are the key numbers:
The number of constructive edits from newcomers increased from 19% to 42% (2.2 times more. As defined by newcomers with less than 100 edits and not reverted within 48 hours).
Breaking down the above number, this is consistent across all wikis with the test on. And on mobile, the increase was 4.2 times more.
Contributors that are shown Reference Check and successfully save a non-reverted edit are 16 percent more likely to return to make a non-reverted edit in their second month (31-60 days after).
10% decrease in edit completion rate for edits where Reference Check was shown
1.8% false nagative
6.6% false positive
From the report, we can see that Edit Check, in particular the Reference Check functionality, helps with improving the content contribution of newcomers and helps to improve the retention of newcomers as well. The 6.6% false postive rate may be a concern, but in my opinion, a minor one. Details from the report indicates that some of the dismissal is essentially WP:SKYISBLUE. Additionally, further finetuning of the configuration for the Reference Check may be made as well to attempt to reduce the false postive rate.
Questions asked
The following are some questions and answers summarised from above (feel free to add more):
Qn: Is Visual Editor is the default editor for newcomers on enwiki?
No. Newcomers are presented with an option to use Visual Editor upon first edit. Declining it will let editors to use source editors instead.
Qn: how does it work with edits that don't need references adding (e.g. creating redirects, adding links on disambiguation pages, fixing spellings, etc)?
The default configuration of needing 50 characters or more before the Reference Check kicks in means that most of the edits asked in the question will not have the Reference Check triggered. Further more, it is for newcomers with <100 edits, therefore it won't be presented to a majority of registered editors.
Qn: Must Visual Editor be the default editor for this to be deployed?
While the functionality is available through a JavaScript switch or through a query parameter, Edit Check is meant for newcomers. If it is not set as default editor, the effacies of Edit Check will definitely be reduced.
Having the user pick whether they want to use visual editor or wikitext editor their first time editing a page (the status quo) seems reasonable and it wouldn't hurt to leave that alone. Perhaps we should just RFC deploying edit check, and leave the visual editor issue alone? The two issues don't seem as strongly linked as I first thought. –Novem Linguae (talk) 06:16, 12 August 2024 (UTC)[reply]
If Edit Check can be deployed without changing the default or not status of VE, it would probably sail through any approval process. If it works, then later someone will be able to pull up stats saying "New editors using VE put references in 80% of their edits but those using wikitext only put them in 15%" or similar to inform that second issue. CMD (talk) 06:45, 12 August 2024 (UTC)[reply]
I should also add that the other target audience is anonymous editors. Right now the experience is as screenshot. This may be a subpar outcome for Edit Check if the primary CTA button is 'Start editing', and the anon/new editors continue to edit in source editor.
As for the statistics of how many new editors are using Visual Editor now, this is one which Foundation staff can help to answer since we do not have the access to user data. – robertsky (talk) 09:54, 12 August 2024 (UTC)[reply]
That information could be gleaned from an appropriate query, since Visual Editor tags its edits. quarry:query/84486 has the first edit for accounts registered in the first half of 2024; something similar and significantly less complicated could probably check for the "Visual Edit" tag. It would be a bit more difficult to include unregistered editors, but a basic usage ratio should be possible to estimate using public data. Folly Mox (talk) 10:32, 12 August 2024 (UTC)[reply]
@DLynch (WMF), I believe these stats are on a Superset dashboard. Can you pull them? If memory serves, there's one query for the first five edits and another for the first 100, but I don't know if one is set up for the first edit alone. WhatamIdoing (talk) 22:40, 13 August 2024 (UTC)[reply]
Edit check will work the same way for VE editors whether or not VE is default. Either way, any usage stats will be within VE users. The message given to anonymous editors who click edit, and the default or not use of VE, do not affect Edit check outside of absolute usage numbers. Generally for new features we have adopted small trials rather than immediate maximal pushses, so in that respect the current VE setup is more a benefit than an issue. CMD (talk) 11:42, 12 August 2024 (UTC)[reply]
Call me wary for a number of reasons. First off is the false claim (also posted at the linked Mediawiki page) that Visual Editor must be the default to deploy this, or the later made implication that it makes no sense to deploy this without making VE the default. If these are coupled in this way, with the bigger change used as a prerequisite for the smaller one, then it is a hard no.
Then there is my last (in a long line) experience with a tool that had been tested or even deployed elsewhere, and worked oh so well (makes me thing of Flow, may it rest in peace). A year ago, we were asked to help with a new tool for the Android App[9]. We were told that "During initial evaluation of the model, it was preferred more than 50% of the time over human generated article descriptions. Additionally, Descartes held a 91.3% accuracy rate in testing." and that it had been succesfully been tested in 15 languages already. When we actually tested, it turned out to be very, very buggy and not usable at all. The result was that in August they posted "We’ve officially received grades for all languages and are now finalizing analysis. We will share the outcomes in next month’s update as well as our recommendations for next steps based on the experiment." and then crickets. So from an A/B tested in 15 languages, successful tool with 91.3% accuracy rate to an abandoned project after one short test by enwiki.
And then I tried to test this new tool here. I added a paragraph of text without a source, published, and got the "add reference" pop-up. Choose "yes", got presented with the automatic reference option by adding a title, typed "Lord of the Rings", no luck, so tried "manual". Click on "Book", and get "thank you for adding a citation!" even though no citation is added. Same result if I manually try to add a website or anything. Perhaps it works in real life, perhaps not, but this certainly doesn't give much confidence. Fram (talk) 13:39, 13 August 2024 (UTC)[reply]
I’ve always been disappointed that Wikipedia doesn’t offer this feature and would love for it to be put in to Wikipedia. Since we have AI around, we can easily create quiz questions on a larger scale for the most popular articles. We could start by implementing quizzes on the main page and going from there. I understand that Wikipedia is an encyclopedia, but the question I came here to answer is that is it just an encyclopedia or is it more than an encyclopedia that includes features that are not just for encyclopedias as a general learning site. Britannica has something similar and I think it would be great not to copy everything it does, but have it as inspiration for creating quizzes. I would like to discuss if Wikipedia should have extra features that make the website more enjoyable rather than just reading and editing. I hope you will consider this suggestion. Interstellarity (talk) 21:33, 10 August 2024 (UTC)[reply]
The NY Times runs a weekly quiz, with questions about the previous week's news stories. It's kind of fun (even if I rarely score above 50%). My guess is if you pitched this to WP:SIGNPOST they'd be happy to run it. On the other hand, there's absolutely nothing stopping you from doing it in your own userspace and announcing it on WP:VP. If people like it, they'll vote with their mouse clicks.
I'm not too on board with including quizzes and other gadgets like this, that are a pretty heavy weight to maintain (especially with having to review all the AI-generated quiz questions), while not really being encyclopedic and probably being an uncomfortable distraction for a lot of readers (including me). However, having them on the Signpost would be cool, although I don't think them being AI-generated is a good thing. On a larger scale, I'm afraid of "feature bloat" where the core thing (here, the encyclopedia) gets buried under layers of gimmicks, ultimately making it much less convenient and not necessarily more enjoyable. Adding more for the sake of adding more isn't necessarily a good thing. Chaotic Enby (talk · contribs) 22:43, 10 August 2024 (UTC)[reply]
The idea of quizzes was discussed in June 2022 and by you in March 2022. As I said in those discussions, anyone should feel free to start quizzes on a project page to establish a track record of being able to produce them regularly, and to figure out what audience exists for this feature. isaacl (talk) 04:03, 11 August 2024 (UTC)[reply]
Heh, I just looked up the March 2022 discussion (which I had long since forgotten about) and discovered that I said almost exactly what I said here :-) RoySmith(talk)14:45, 11 August 2024 (UTC)[reply]
I don't get why we need things like extensions and AI to run quizzes. Quizzes existed long before Mediawiki and AI. Just take a couple of minutes to ask a few questions each day/week/month in your user space and advertise it on one of the village pumps and/or Signpost. If the feature is popular then it can be formalised to the main page etc. Nothing will happen unless someone (most likely you) volunteers to do it. Phil Bridger (talk) 08:40, 11 August 2024 (UTC)[reply]
Wikipedia already has loads of extra features that make it more enjoyable, most of which are dramaboards 😉 The true "extra feature" that makes Wikipedia so great is how lightweight and on-mission it is. Even on a bad connection, on a slow device with an old browser, I can navigate to a Wikipedia article, and it will load the whole thing for me to read (certain restrictions apply).I don't have to stop the page loading before stylesheets are applied because it can't reach an advertising partner, I don't have to leave the tab open two minutes and go do something else while my phone wearily executes javascript routines, I just open the page and read the page, like how the internet used to be before it became total capitalism garbage.Any extra interactive features added to the default experience reduce our availability and usability for people on the lower end of computing resource / network infrastructure privilege. It feels important to preserve that equity.So I guess my position is: no, Wikipedia isn't just an encyclopaedia— it's also an online community; but also no, Wikipedia isn't a general pedagogical resource— it's pretty much just an encyclopaedia with an active editing community. Folly Mox (talk) 13:27, 11 August 2024 (UTC)[reply]
For sure! I probably could have done a better job in selecting a qualifier than the term "general" in general pedagogical resource, or maybe should have chosen different words altogether. I was attempting to communicate my personal opinion on the OP's question on whether Wikipedia is just an encyclopedia or is it more than an encyclopedia that includes features that are not just for encyclopedias as a general learning site.Folly Mox (talk) 09:47, 13 August 2024 (UTC)[reply]
Sure, why not! It's an education website. This is something many loose track of, we are in the business of a non-profit education resource. The best way to do this is start a Project and run the quizzes in project space. Once it has a following and support, which might take years and press exposure, then consider something on the front page. -- GreenC20:37, 12 August 2024 (UTC)[reply]
It would surprise most outsiders viewing our non-article space, as well as new editors, that civility is a required as a matter of policy, and is so theoretically important that it is one of the project's Five Pillars. The section on civility in the Five Pillars has an almost quaint sound to it, like something preached in church that no one actually observes. In certain project areas, a kind of "toxic workplace" atmosphere exists, in which low levels of hostility are the norm, are taken for granted, and as a practical matter are not subject to sanction.
We used to have an informal sounding board to deal with civility, WP:Wikiquette assistance. When WQA was shut down in 2012 in a discussion on this board, the community found that WQA "did more harm than good," but there was "also a consensus that there needs to be an intermediary process between the talkpage and ANI, now that WQA is closed." No such intermediary board was ever created, and as far as I can see, perhaps I missed it, but searching through the archives of this board I see no discussion of creating such a board since 2012. I think we need to revisit the topic and create an intermediary civility board. Perhaps just simply revive WQA. Figureofnine (talk • contribs) 13:43, 13 August 2024 (UTC)[reply]
I very much agree that something is needed to avoid the toxic workplace atmosphere while not having to drag people to ANI for every civility issue (which often creates even more drama, on top of needing a pretty high bar for some remedy to actually be enacted). Not sure whether WQA itself is the best, but we definitely need to have an intermediate process for that matter. Chaotic Enby (talk · contribs) 13:58, 13 August 2024 (UTC)[reply]
I just wanted to add (EC) that while the "more harm than good" verdict may have been correct in 2012 (personally I think it was a mistake) it would not be true today, and that an intermediary board is urgently needed if WP:CIVIL is to be taken seriously. Figureofnine (talk • contribs) 14:01, 13 August 2024 (UTC)[reply]
There have been discussions over the years on venues to discuss editor behaviour (such as a noticeboard focused on civility, or a return of the request for comment process for user behaviour). The most recent one I could find is Wikipedia:Village pump (policy)/Archive 167 § A page to report violations of WP:Civility policy. The key question is can a process be created that avoids the pitfalls of the past processes and the incidents' noticeboard, while also being more effective. Many of those who weigh in on this matter want a process that has a feedback process without automatically enacting a sanction, but that only works when the person in question is receptive, and when unfounded inquiries can be swiftly filtered out. English Wikipedia's consensus-based decision-making traditions aren't very good for analyzing behavioural issues in a sympathetic manner: large public, unmoderated group conversations are the opposite of how most organizations provide feedback to its members. Until the English Wikipedia community is willing to look at other decision-making methods in this situation, the root problem can't be addressed. isaacl (talk) 14:57, 13 August 2024 (UTC)[reply]
Maybe we could have a group of users elected by the community to provide feedback on these issues? A sort of mini-ArbCom, but without the gravitas, that will still make the discussions more manageable. We could adopt a format similar to moderated discussion for resolving such issues. Chaotic Enby (talk · contribs) 15:05, 13 August 2024 (UTC)[reply]
Historically, the editors who like to weigh on these matters have been wary of delegating decision-making to a sub-group. An election process is additional overhead, and its results are decided by a self-selected sampling of interested editors. Editors are thus concerned that the sub-group won't adequately represent the community (and from a partisan perspective, that their viewpoint won't be adequately enforced). Personally, I think there will have to be some form of hierarchy introduced to be able to sustain a community of this size (though I think it would better to focus on managing content-related decisions more effectively, which would in turn forestall many behavioural issues, as they become losing strategies for influencing content). But it's not clear to me when the community might reach this conclusion. Moderated discussion might be a form of hierarchy to which the community is more receptive, but at present, it's still more concerned about moderation unduly restricting editors from saying whatever they want. isaacl (talk) 15:34, 13 August 2024 (UTC)[reply]
"Somehow" is the wildcard. Right now, a small number of vocal editors can stop actions from occurring, because the community genuinely seeks approaches that satisfy as many people as possible, in accordance with consensus. Such editors could be considering themselves as holding the line against a devolution into more biased editing, where sheer numbers of editors with an agenda are swamping a given page or topic area, or they could be the ones trying to give an outsized amount of weight to a minority view. If we can find a way to pull the content-decision out of the fray, with a result that remains in force until there are specific reasons to revisit it (*), then we can avoid re-litigating the decision endlessly, and thus remove incentive to be stubborn, aggressive, and repetitive.
But we're not talking about actions, but rather an area where the broader community can make input into specific alleged violations of WP:CIVILITY. The worst that can happen is what currently happens, which is nothing. However it gives a complainant the ability to vent their concerns about the behavior of specific editors or groups of editors. Figureofnine (talk • contribs) 16:44, 13 August 2024 (UTC)[reply]
It seems like this proposal, along with another proposal by Bon courage to shut down WP:DRN as ineffective and Kovcszaln6's comments in that thread, point to a need for an infernal internal forum where disputes are referred to for input by uninvolved editors with the goal of either a) quickly defusing the situation with relevant policy/guideline advice or b) referring it to a more appropriate forum or process. signed, Rosguilltalk19:37, 13 August 2024 (UTC)[reply]
I used "actions" generically to mean anything that the community agrees upon. With English Wikipedia's consensus-based decision-making traditions, many editors don't want to reach an agreement on something that they know several people disagree with. Editors will even try to make accommodations for a single editor objecting.
Regarding a venue to vent, I disagree that this should be a goal of a new noticeboard. There are plenty of places for venting. The community needs effective discussion. isaacl (talk) 20:51, 13 August 2024 (UTC)[reply]
"Vent" was not meant to mean "venting" in the sense of "getting stuff off your chest." "Express" would have been more precise. Yes I agree that we want a mechanism that will do more than give people a place to blow off steam.
I agree with the comments above re an informal forum. I had forgotten about DRN even though I guess I used to participate, as a DRN userbox is on my user page. Figureofnine (talk • contribs) 21:25, 13 August 2024 (UTC)[reply]
The preceding comments seem to be about an internal forum, not an informal one. The dispute resolution noticeboard, as it states at the top, was created to resolve small disputes and help redirect to more appropriate forums. I'm not clear how a new forum with the same purpose would be more effective. isaacl (talk) 02:14, 14 August 2024 (UTC)[reply]
A few thoughts:
Ask four editors to define civility, and you'll get at least five mutually incompatible answers.
The Robustness principle gets applied backwards. What it says is: Ignore the fact that the other guy is dumping profanity on you, but don't ever use profanity yourself. What we see on wiki is: "I'm allowed to use profanity, and you're not allowed to be upset about it!"
Anyone who thinks this is easy has never thought about this.
In particular, anyone who has never considered how to get two people, both upset, to agree on how to treat each other during a hot-button dispute that is important to both of them, when one of them is from a hierarchical face-saving culture and the other is from an egalitarian guilt/sin culture, probably has no idea how impossible it is. The latter person is probably insulting the first person left and right without even realizing it. Now toss in English as a second or third language (anyone else remember the Indian students trying to be friendly by saying "Hi, buddy"?).
We could impose a default culture (which actually will end up being the manners of US white-person middle-class males, no matter what anyone says or wants), but supporting and including all the cultures equally is really, really, really hard. Like "mediator charges US$1,000 an hour" hard, not "we'll all have to think nice thoughts" hard.
Changing all values of the Hebrew language, from Yeshu(ישו), Yeshua(ישוע)
Hello Wikimedia Foundation, my name is Jack from Israel and I would like to talk to you about a very important topic that has never been mentioned almost at all.
In the United States they say the name Jesus, the "J" becomes a "Y" and thus the name Yesus or "Jesus" was created.
Anti-Christian elements criticize his imposition on his name and omitted the last letter in the name of Yeshua and turned it into the name "Yeshu" as a derogatory word, when the word Yeshu becomes an initials and its meaning becomes the phrase "yimakh shemo v'zikhro",
This was mentioned in all the Hebrew scriptures and also in the wikipedia.
In my opinion it is not even necessary to explain why this topic is so important and most importantly to change the value of his name from "Yeshu (ישו)" to "Yeshua (ישוע)".
But here are some explanations from my own why it is so important;
First, changing a person's name can damage history, also changing Napoleon's name can damage the future reporters and also lead to the end of the being Napoleon, we would not want to erase a person like this from our history and forget him on the other hand, today it can be seen that 80% of the people of the State of Israel do not know His real name and they even call him in the derogatory word "yimakh shemo v'zikhro" Wikipedia should tell us (the people), Correct information, up-to-date, and true information! And a person who doesn't understand what a certain entry means, like for example "Yeshua" is welcome to do Wikipedia, that's what you were created for, right?
When a person does not know what Yeshua word means, he can do Wikipedia and understand.
Secondly, the moral and social level involved, changing a person's name and turning it into a derogatory word looks like this ("yimakh shemo v'zikhro") an injury to Christianity as a whole, disrespects the person (Jesus) and humanity, which colludes with deranged Messianic rabbis who devote their entire lives to inventing lies about Christianity . Does Wikipedia, are you members of the Wikimedia Foundation, agree with these values?
In this way, it is like taking the name of something and changing or removing or adding a letter to its name, this can lead to complete oblivion of the person. As can lead to the future bringing of precious Hebrew reporters, and even the rewriting of the New Testament and changing its future name from Yeshua to Yeshu.
We don't see it now, but in the course of the years and the progress of evolution, where books will become digital material and thus bring Wikipedia as the most authoritative source on the Internet; What will be created by this is an injury to the name of Jesus and also an injury to the values of history.
In addition, here is an article that was written on Wikipedia in 2017 but did not receive much attention:
"As a free encyclopedia, we are supposed to meet certain standards. These standards should on the one hand be professional and on the other hand take into account the reading public. I will point out facts: regardless of the name, the entry is currently one of the poorest in Wikipedia on the subject when it includes a list of sources that is so sparse on one of the entities (Note that I did not use the word people so as not to offend, of course) the important ones in humanity history. In addition, in my humble opinion, the Hebrew Wikipedia is the only one that uses a historical derogatory word. I understand that for a large part of you it is not perceived as a derogatory word, but it is certainly possible that a large part of the population does. In fact, it is so unfortunate because it is also about "gypsies", one of the most common derogatory words in connection with peoples in the world that people use without noticing. On the one hand, Wikipedia should champion the professional name, which is Yeshua, and on the other hand, it should champion the non-blatant name, which surprisingly ( cynicism) is also Yeshu. In fact, every time a discussion about the name of the entry comes up, we must reject the request, which comes up again and again, and it changes the name of the entry. The fact that we as Wikipedians receive these complaints over and over again only exacerbates the situation and presents us in a negative light My hypothesis is that it will not offend a person if the name of the entry is Yeshua, but indeed it will be if it is the name Yeshu. We, as Wikipedians, allow the name of the entry to continue, so it is possible that we are actually hurting other people's feelings, even if unintentionally..."
In conclusion, changing the name of Yeshua(ישוע) to Yeshu(ישו) is not only an injury to Christianity as a whole, to human dignity, it is also an injury to history itself and can even cause major problems from this issue.
Therefore I ask the Christians who are reading this, will you allow the people to blaspheme the name of Jesus?
Will Wikipedia give priority to such a disgrace?
That's why I ask in every language of request,
to change the word "Yeshu" to the word "Yeshua" in the Hebrew values
I would love it if you read and contact me, many thanks Jack 87.71.160.172 (talk) 22:51, 20 July 2024 (UTC)[reply]
From what I have been able to gather, you have a problem with the way the Hebrew (or transliterated Hebrew) for Jesus of Nazareth is written in at least some (all?) articles? From what I can see (MOS:JESUS) we don't have a site-wide consensus on how the name should be presented in Hebrew. As such, how it is referred to in any particular article will depend on the sources being used for the information - if the sources use one transliteration then that's fine to use. That said, I appreciate that this IP believes one spelling of it (in Hebrew or transliterated Hebrew) to be offensive to some at least. I can't tell if the IP is complaining about something solely present on Hebrew Wikipedia (if so we can't really do much), but it may be a good idea to add something to MOS:JESUS as to how we refer to the person - do we always use the English name "Jesus (of Nazareth)", do we sometimes use the Hebrew name, and if the second, what spelling/transliteration do we use? I'll be leaving a note on the IP's talkpage to ask them to clarify their issue. -bɜ:ʳkənhɪmez (User/say hi!) 07:42, 21 July 2024 (UTC)[reply]
It looks like there is some related information in Yeshu. It appears that this set of letters was used in one (i.e., a single) medieval-era Masekhet as an acronym rather than/as a pun on the name, and a 17th-century German man, Johann Andreas Eisenmenger pushed the idea that this spelling is always insulting, along with quite a lot of errors, bigotry, and nonsense.
Some modern writers use the difference between Yeshua and Yeshu to distinguish between Jesus of Nazareth and all of the (many) other people with the same given name ("Joshua" being the most common English spelling). If that is the widely accepted convention in Hebrew, then I would expect that not following it would be confusing to readers. WhatamIdoing (talk) 09:05, 21 July 2024 (UTC)[reply]
According to your opinion, the two main reasons why you do not want to change the name from Yeshu to Yeshua are:
The first was that the use of the name Joshua can cause confusion with other names in history, many rabbis who use this claim as a cover for changing his name Yeshua to Jesus (yimakh shemo v'zikhro).
This claim is completely absurd and can be refuted in several ways.
The first, the most well-known example (which occurs mainly among the rabbis), is the change of the name Yeshu to Yeshua, so that they do not get confused between the name *Joshua* and Yeshua, which is completely absurd in the English language and also in the Hebrew language, it does not come out or sound the same, the addition of the letter " The "in the King of God" can change the spelling completely, (Yeshua - *Yehósua*), another example, changing a name, dropping a letter changes the name completely, for example Jack-Jacek, one can understand the essential difference between the two names, thus expanding the claim. Of course there are other examples in this regard, but I will not list them...
Second claim, "Israeli society is already used to the word "Yeshu", and this is also a rather absurd claim, as if a society decides to change the name of something (and something else very important throughout history) collectively, it does not really change its name, like this friend that everyone calls him by a nickname, but finally his original name will appear on his ID card. And so is Wikipedia, which is supposed to serve as an identity card of values; And the kind of value and also Yeshua.
In addition, if any company decides to boycott any country, and even create a political conflict against it-
A. This does not mean that it is impossible to change the situation and bring it to a better two-state situation.
B. The mere fact that one country decides to ignore another country does not make the other country non-existent.
And likewise his name, if a company of people decides to reverse the name of Yeshua and become the word "Yeshu" it did not reduce his name to Yeshu!
Also, Wikipedia must adhere to the correct values and provide correct and reliable information.
In addition, you wrote "there is not much to be done if this"
I am personally ready to sit down and change all the values in which the word Yeshu appears, and I also recommend to the members of the Wikimedia Foundation in Israel to make an effort to correct the values.
Second, This was mentioned in all the Hebrew scriptures is anachronistic; the Hebrew scripture were closed long before his time. As for the Talmud, the date that I have seen for the early part, the Mishna, is 200 CE, surely a bit late to have influenced the spelling in the Christian scriptures.
Third, if there are surviving Aramaic copies of the Christian scriptures then the name written there should be used. Otherwise, the Greek transliteration now accepted in Christianity should be used.
My intention is that it could lead to the rewriting of the New Testament, in the name of technological progress... What could be written by a Jew who does not know the true name of Yeshua and will therefore call his false name Yeshu Appspame (talk) 20:38, 21 July 2024 (UTC)[reply]
In Judaism there is such a thing called the Ark of the Covenant where every rabbi can add more and more and more books the Hebrew Scriptures do not close they continue. The very fact that you say such a thing means that you know nothing and a half about Judaism or about the State of Israel itself. You can ask any rabbi and he will answer it for you. (cf. Sifrei Kodesh entry) Appspame (talk) 08:11, 22 July 2024 (UTC)[reply]
Here is another example of a book written in the last 500 years Shulchan Aruch is a very important book for Judaism! So much so that it even entered part of it into the Pesach legend! Appspame (talk) 08:14, 22 July 2024 (UTC)[reply]
In general, the very thought that they took the name of a historical figure and simply changed his name definitively does not excite you, the use of the wrong name can lead to historical disruptions and surely the website Wikipedia, which should lead to one of the most authoritative sites for learning on the Internet, gives the wrong name of some person throughout history ? If the name Napoleon was written incorrectly you would correct it correctly and if any other name was written incorrectly you would correct it.! But when it comes to this name, suddenly there is a problem, right?! Appspame (talk) 20:44, 21 July 2024 (UTC)[reply]
I specifically turned to you because I know that you are people with logical considerations, people who know some logic in their lives. You can admit that you simply do not have the strength to change all the names on Wikipedia to their true value. I actually did not address the Israeli community because the Israeli community does not understand the value of the importance of such a thing, but you who live in the United States should know the value of the importance of such a thing! This is not only a disruption of history, it is also an injury to the person's name. Appspame (talk) 20:47, 21 July 2024 (UTC)[reply]
Respectfully, there is no "true value" to which we should change everything on Wikipedia. Names have been transliterated and written different ways in various languages throughout the centuries, and Wikipedia relies on verifiability, not truth. If you want this change to be made, claiming that it is the "true" spelling isn't enough, you need to provide us with sources actually using it as the Hebrew spelling. Chaotic Enby (talk · contribs) 21:35, 21 July 2024 (UTC)[reply]
Isn't the New Testament the most correct spelling for Jesus' name? The rest of the inscriptions are actually under the inscriptions of rabbis or rabbis that were written after the New Testament. The oldest inscription in which the name Jesus was mentioned was the New Testament. Appspame (talk) 21:41, 21 July 2024 (UTC)[reply]
In my opinion, it is absolutely absurd that you need to bring evidence for the name of Jesus, that you can simply go to the place where he mentioned his name for the first time in the New Testament! This is the oldest source that mentions his name, and also it should be brought to the most authoritative place regarding his name, and also an attribution of a name change written about 500 after his death, should not be attributed any meaning to it. If so, can you bring me a Hebrew source older than the New Testament that attributes his name, and also says that his name is Yeshu...? Appspame (talk) 21:47, 21 July 2024 (UTC)[reply]
There are many editions of the New Testament, some of which use one spelling. Even if you took the oldest edition, that one would have several words spelt according to the conventions of the time instead of modern Hebrew. Aaron Liu (talk) 21:54, 21 July 2024 (UTC)[reply]
In Hebrew we have two types of new house, the first is modern Hebrew and in biblical Hebrew the word Yeshu does not appear in both of them Appspame (talk) 22:06, 21 July 2024 (UTC)[reply]
You say that there are other versions of the New Testament in an older way in Hebrew, I want you to find me an older New Testament in which the word Yeshu is written, if you do not find it, this makes the most recent existing New Testament the oldest place where his name was mentioned. Any claim that is not a counterquote is considered to be evasion Appspame (talk) 22:11, 21 July 2024 (UTC)[reply]
I can also invent that there is an older inscription past the life of Alexander the Great and it says his name Mordechai Reuveni. That doesn't make it right! Appspame (talk) 22:14, 21 July 2024 (UTC)[reply]
Matthew 1:16... (and Jacob the father of Joseph, the husband of Mary, and Mary was the mother of Jesus who is called the Messiah.)
> If the name Napoleon was written incorrectly you would correct it
True, but we'd have to talk about what "correct" is. We write about Napoleon, even though his name was Napoléon in French and Napoleone at his birth. Which one is "correct"? WhatamIdoing (talk) 02:08, 31 July 2024 (UTC)[reply]
In the United States they say the name Jesus, the "J" becomes a "Y" and thus the name Yesus or "Jesus" was created. What?? —Tamfang (talk) 06:06, 23 July 2024 (UTC)[reply]
A lot of languages share the Latin root Iēsūs. Learned borrowing, the proper way of inheriting words, changes the spelling to be more in line with a language's phonetical spelling. Way back when, the J was the proper way to spell Y. I think that's what it means. Aaron Liu (talk) 02:37, 31 July 2024 (UTC)[reply]
But I'm not looking for the value in Greek, I'm looking for it in Hebrew, in Hebrew they write Yeshua, according to the oldest inscription the New Home in Hebrew! Appspame (talk) 22:28, 21 July 2024 (UTC)[reply]
Why do you insist so much on not changing the name of the entry, and admitting mistakes?, I suggest you also research the issue and go to the Igod.com website, which explains some important topics in the Bible and the New Testament! Appspame (talk) 22:35, 21 July 2024 (UTC)[reply]
Appspame, nobody can tell from your overly lengthy commentary which specific articles here on the English Wikipedia you propose to change and which reliable sources you propose to cite. We cannot help you with any other language version of Wikipedia. You need to be far more concise and clear. Cullen328 (talk) 01:33, 22 July 2024 (UTC)[reply]
Ok, I'll try it, the oldest Hebrew source in which the name Jesus appears is found in the New Testament. The New Testament is not found in the entire state of Israel where the word Yeshu appears, Wikipedia relies on older writings written about 500 years after Jesus and 1500 years written by Rabbis. I am personally ready to change the values in which this disgrace appears and change his real name from Yeshu to Yeshua all I need you to do is to approve me thank you! Appspame (talk) 08:01, 22 July 2024 (UTC)[reply]
Appspame, I guess that I need to repeat my questions since you failed to answer the first time. Which specific articles here on the English Wikipedia do you propose to change and which specific reliable sources do you propose to cite? Vague, sweeping claims are worthless here. Please produce the specifics, or move on to something else. Cullen328 (talk) 08:56, 22 July 2024 (UTC)[reply]
No, I'd love to talk about it a little more I want to really understand what is the point where you don't want to change his name to his real name? the New Testament because it is a faithful place, and if you don't want to take the New Testament it is a faithful place, the place after which it was written was the Koran, also in the Koran his name is mentioned and guess what his name is Yeshua, my first point is that it is forbidden to change a historical detail, to come and say that there is not enough evidence to prove that it is a historical detail whose name Was Yeshua it's like coming and saying that there is not enough historical evidence of Napoleon's name was Napoleon. The books of the New Testament are not only "books of stories" but also historical books that tell us about the First Temple period here in Jerusalem. My second point is that if a society is used to something it doesn't mean that you can't just change it, for example if South Africa is used to massacres and genocide, doesn't that mean you can't change it and just leave it as it is? So you can also change! I'm trying to understand why you are so opposed to this question mark I brought proofs I brought points for thought but you decide to ignore them why?! It's about my English, I'm very sorry, it's my English, after all, I live in Israel, be patient with me, thank you. And once again, it's important for me to point out that I don't come from a place of anger, I come from a place of disappointment, disappointment that I even have to come and say such a thing to come and wake up people's eyes and explain to them that my name is my name, and my name is not what changed it, that's why it gives me a feeling of disappointment Towards myself, towards humanity and towards Wikipedia which cooperates with unreal and incorrect values! More than that, you take values that were written exclusively in Hebrew by messianic rabbis and not by people who actually knew Christianity and who knew who Jesus is, so I think that your faithful source are not instructive, but because they were written by people who hate the New Testament and hate Jesus and that's how they are Let his name be known. In the same scripture where the name Yeshu was written, there were also lies written about him and lies also about the New Testament by those people who did not even dare to open the New Testament or read from it or understand it. And you call them a faithful source? Appspame (talk) 09:20, 22 July 2024 (UTC)[reply]
Btw, this is not the Wikimedia Foundation (you wrote "Hello Wikimedia Foundation" in your OP), this is more like the en-WP Wikipedia community, or at least the parts of it that noticed this thread and decided to write a reply.
My understanding so far is that you want every Wikipedia-article, in any language, that includes a Hebrew spelling of Jesus, to use the Hebrew spelling you prefer. That is not something en-WP can decide, and while you can try to contact the Wikimedia Foundation, it's not an issue I think they'll consider their business, they generally leave Wikipedia content to the various Wikipedia communities. Hope this helps some. Gråbergs Gråa Sång (talk) 11:43, 22 July 2024 (UTC)[reply]
Wikipedia is written by thousands of volunteers. The Wikimedia Foundation maintains its infrastructure, not its content. —Tamfang (talk) 06:01, 23 July 2024 (UTC)[reply]
We are not the Wikimedia Foundation. We are the volunteers who actually do the work. The Wikimedia Foundation just handles funding and legal issues; it doesn't actually control the content of Wikipedia at all. You're talking to the right people if you want to change something, but Wikipedia makes changes by WP:CONSENSUS, not by a few people who are in charge. This means we will argue about something for a long time before doing anything about it. Cremastra (talk) 07:18, 25 July 2024 (UTC)[reply]
Addendum: An Israeli citizen could hypothetically lobby the Israeli government to change the name of its public holiday "עליית ישו השמיימה". If -- and only if -- that effort were successful, then Public holidays in Israel could and should be modified. Getting the Israel Museum in Jerusalem to modify the Ossuary shown in The Lost Tomb of Jesus so that its caption could reflect the change is another task that a local could likewise hypothetically attempt. (TL;DR: Don't) ~Hydronium~Hydroxide~(Talk)~12:44, 22 July 2024 (UTC)[reply]
Nonsense! In Israel, according to the Hebrew Language Academy, Yeshu's real name is Yeshua and you can ask the Hebrew Language Academy, they are responsible for the Hebrew language, not Wikipedia! So that Wikipedia does not only dishonor the name of the person, it also dishonors the historical value, also dishonors the Hebrew language and the Hebrew Language Academy. Appspame (talk) 14:20, 22 July 2024 (UTC)[reply]
You take the names of the Catholic Christian holidays that were translated by non-Catholics and these names were never approved by the Hebrew Language Academy and you give them as an example?! What kind of example is this? You show some examples and you say, here is the name that appears here and here and only on this holiday does this name appear, perhaps only because only this holiday has been approved and translated by the academy and qualified Christian authorities! Appspame (talk) 14:24, 22 July 2024 (UTC)[reply]
By the way, I actually chose to talk to you because I thought you were more reasonable people who know facts and live in the sand and should understand the essence of the matter! Appspame (talk) 14:26, 22 July 2024 (UTC)[reply]
And once again you never answered me why you are so, so opposed to changing the name to his real name? Are there internal factors that tell you not to do such a thing, is it only because I am Israeli and you are anti-Semitic? Is it because you are against Christianity and in favor of desecrating the name of Jesus? Tell me what the real reason is that you are so opposed!? Appspame , (talk) 14:28, 22 July 2024 (UTC)[reply]
Stop with the absurd personal attacks, Appspame. Your proposal is failing to gain support because you do not understand English Wikipedia's policies and guidelines, have not brought forward any reliable sources, and show no sign of taking on board the feedback you are receiving. You are an anonymous person and your claimed personal expertise is of no value here. Cullen328 (talk) 15:52, 22 July 2024 (UTC)[reply]
I rewrote the guideline Wikipedia:Please do not bite the newcomers to be more concise and readable in this rewrite. The current version contains many duplicated guidance, irrelevant information, and painfully common-sense recommendations (I don't think I need to provide any examples). It contains one outdated guidance (draftication is now more common than userification), and poor accessibility decisions like long bullet points as well as linking non-specific words like "here". Concise writing leads more people to actually read the guideline. How do you feel about this rewrite? Should I add/remove/change anything? Catalk to me!14:41, 27 July 2024 (UTC)[reply]
The rewrite is the diff posted above; your minor copyediting is this one. I did compare the current rewrite to the last revision of WP:BITE prior to your edits there, to show the totality of your changes, and then forgot to mention it after I figured out I had to reverse the parameter values in {{Diff4}} to get it to produce the effect I wanted. Apologies for the confusion. (Also I like the rewrite. Have you seen shameless plug?) Folly Mox (talk) 15:27, 27 July 2024 (UTC)[reply]
No worries! I didn't realize that diff viewing between two pages were possible. I do like HouseBlaster's YFA rewrite over the current version. Catalk to me!17:41, 27 July 2024 (UTC)[reply]
While I like most of this, I feel like some of the removed points should be kept. For example, the "what to do" section feels like it would make people pointed to the guideline less aggravated, and "Common newcomer errors" offers examples of situations to apply the guideline. A lot of rationale was removed: for example, the point that newcomers contribute most substantial content was pretty poignant and the part about "be bold" feels like it should be included in the "it's okay" section. I'll see if I can change some of this.Also, I personally have an intense dislike of punctuation right after an external link; the icon stands out a lot and looks unpleasant. Should the Stackoverflow link be converted to a footnote? Aaron Liu (talk) 22:38, 27 July 2024 (UTC)[reply]
Much thanks for ironing out awkward prose! I am not a native speaker of English so copyediting takes effort for me.
I relegated the result of 2006 informal study into an efn since it is outdated by nearly two decade. I am not sure if the finding still applies today. I'll try to find up-to-date sources.
I removed the section What to do if you feel you have "bitten" since it felt like the standard life advice when you have hurt somebody/made a mistake, and isn't specific to bite cases.
I like the bit you added about WP:AGF/Hanlon's razor. AGF should be mentioned as a strategy to not bite. However, I feel as if the paragraph could be reduced to a simple bullet point/sentence, since much of it is just restating the first and second paragraph. Catalk to me!16:39, 28 July 2024 (UTC)[reply]
Yeah, I'd go the efn route as well.For the razor, one of the other points I felt was missing was the part about teaching. The paragraph seemed like the best way to incorporate that. It also includes stuff about not assuming malice. Aaron Liu (talk) 16:45, 28 July 2024 (UTC)[reply]
We're more trying to see if the "anons and newbies contribute most substantial content" can be sourced with recent, "published" data. Aaron Liu (talk) 14:36, 29 July 2024 (UTC)[reply]
t felt like the standard life advice when you have hurt somebody/made a mistake A lot of life advice applies to Wikipedia. Common sense isn't as prevalent as it once was, and being a section near the bottom (we could even move it to the very bottom) it really shouldn't hurt to include it. Aaron Liu (talk) 14:44, 29 July 2024 (UTC)[reply]
I understand your point; but if someone doesn't know a interpersonal skill as basic as this, they shouldn't be editing Wikipedia in my opinion.
Maybe the section could be condensed to these three bullet points:
A lot of us here are on the autism spectrum (I am) and interpersonal skills aren't necessarily our forté. Also, people can react very differently towards conflict, irrespective of neurodivergence. A lot of other websites thrive on unkind interactions like sarcasm and cutting remarks. We can assume neither an editor's interpersonal skills nor their learnt behaviours from other online communities. Attempting to educate is worthwhile. Folly Mox (talk) 16:16, 29 July 2024 (UTC)[reply]
I should have realized that my comment can be inconsiderate, I am sorry for the insensitive remark. I agree with your reasoning behind keeping the section, though I do think the current version of the section has room for concision-ing. Catalk to me!16:29, 29 July 2024 (UTC)[reply]
Agree that discoverability and participation are issues that affect much of the Wikipedia talk: namespace, but I don't think the solution is to start creating new Villages Pump for individual WikiProjects. Folly Mox (talk) 21:41, 29 July 2024 (UTC)[reply]
@Bogazicili, do you find that those ~10 editors are making bad decisions? If not, then you've already got enough people involved.
I understand the idea of wanting "more", on the emotional side. If I think something is important, then why isn't everyone else showing up? Having a lot of participants validates my belief that this is important. It's like getting a lot of 'likes' on social media: my discussion has 50 people in it, so that means it's important.
However, the point of those discussions is to make decisions, not to help us feel like we're involved in work that other people find important. Google used to put prospective candidates through 12 interviews. However, the answer rarely changed after the fourth interview. [2][3][4] The opinion of just four interviewers was enough in 95% of cases. Eventually, they decided that it was silly to have three times as many people involved as they actually needed, even if those people wanted to feel important. Their hiring process is no longer so burdensome, and is just as likely to make the right choice.
So I ask: Do you really think that we truly need more editors to answer a question about which subject to list? Or are the folks there already doing a fine job and already able to make good decisions? WhatamIdoing (talk) 02:50, 31 July 2024 (UTC)[reply]
I don't think those are unreasonable choices. Car and Ship are level 3, so Train probably should be level 3, too. That's what they chose. I understand your desire to have Climate change be level 2, on par with Earth, Climate, and Geology, but I also understand their decision to keep it on level 3, on par with Weather, Earth science, Atmosphere of Earth, and Pollution. It was not an unreasonable choice, even though it's not the one you wanted. I'm not convinced that involving more people would have changed the outcome. WhatamIdoing (talk) 17:45, 1 August 2024 (UTC)[reply]
Solar system and moon are both level 2, so sometimes something that would be in a subcategory is on the same level with a parent article. I also didn't say involving more people would change the outcome. I am not sure why you felt the need to say that. What I am saying is this: as a principle, core Wikipedia-wide discussions should involve as many people as possible, and should be done on more frequently used places like the Village Pump. Bogazicili (talk) 17:52, 1 August 2024 (UTC)[reply]
Just to give a contrarian (and personal) opinion… I really don’t give a rat’s ass about the various article rating systems. I pay no attention to them.
Now, I do understand that there are editors who LOVE rating articles. I have no problem with that. You do you. I think you are waiting your time, but it’s no skin off my teeth. Just don’t waist MY time with it.
So… I would be very annoyed if the Village Pump was suddenly cluttered up with discussions about article ratings. That wastes my time. Better to have these discussions take place out of sight, on a dedicated page where I can ignore them. End rant. 😉 Blueboar (talk) 20:25, 1 August 2024 (UTC)[reply]
I don't disagree with the principle that many editors should involve themselves in core Wikipedia-wide discussions, but would not characterise as such the importance shuffling within WikiProject Vital articles. Folly Mox (talk) 22:56, 1 August 2024 (UTC)[reply]
I was looking around some pages, and found the now defunct WP:ADCO. I thought that this would be a great idea to bring back in a way, as the amount of RFAs is dwindling, and I believe there is many Wikipedians who would want to start a RFA, but would find it too daunting. I am aware of programs such as WP:RFAPOLL, but believe we need something more. Now I don’t believe we can revive WP:ADCO in its entirety, but I think we can come up with something similar. Thanks, Lordseriouspig05:06, 31 July 2024 (UTC)[reply]
My take on this is that anyone who needs coaching will not make a good admin. The quality needed (besides honesty, which I hope goes without question) is to "get" Wikipedia, which is very difficult to teach someone. The problem that we have with RfA goes much deeper than this. Phil Bridger (talk) 17:27, 11 August 2024 (UTC)[reply]
Since new editors very often start out by directing their primary attention toward the lead and infobox—on some articles sometimes receiving almost all their attention—I wonder if it wouldn't be worthwhile to mention very briefly that most information one puts there should be mentioned in the body of the article itself also. I feel bad reverting for this often, and if a chunk of new editors notice this before making their first edits, they may feel better able to continue contributing as they'll get bonked less by moody folks like yours truly.
Even so, I'm not quite sure we can justify it. For one thing, many (most?) will not immediately know what an infobox or lead section are. One would have to write it as a short addendum to
More generally, if someone adds good information to the infobox, and that material should also be in the article (because, no matter what INFOBOXPURPOSE says, that's not always the case), why do you choose to revert it, instead of copying the material to the body of the article? WhatamIdoing (talk) 20:56, 1 August 2024 (UTC)[reply]
I wasn't listing all possible remedies since we all know how editing works here in the lab—I could've just said this but I mostly just meant to say "requires additional work and interference by other editors, whether reverting or revising." Remsense诉21:47, 1 August 2024 (UTC)[reply]
As a regular, I find the UI honestly dull. In an age where the Olympics has a webpage for the purpose of quizzes and games. I find that maybe Wikipedia would be touted as a technological marvel in 2015, but the year is 2024 and, in all honesty, Wikipedia is quite uninspiring. — Preceding unsigned comment added by Usernamesenior (talk • contribs) 19:02, 3 August 2024 (UTC)[reply]
So, your title is "Make the UI more user-friendly", but your actual interest is "make the website something other than an encyclopedia"? Remsense诉19:06, 3 August 2024 (UTC)[reply]
It is a marvel that in 2024 there is a high-profile mainstream website that isn’t filled with ads, flashy junk, and trendy design churn. Well, as long as you think Vector 2022 was an improvement… Barnards.tar.gz (talk) 16:28, 5 August 2024 (UTC)[reply]
There is a great deal of potential in the notion of supporting a quiz/game interface with Wikipedia. It would not be part of Wikipedia per se, but would draw on and depend upon wikipedia. This could be, potentially, the 21st Century Trivial Pursuits. --03:09, 6 August 2024 (UTC) — Preceding unsigned comment added by Ceyockey (talk • contribs) 03:09, 6 August 2024 (UTC)[reply]
There is also a potential for interfacing generative AI into article enhancements in the following way ... Given Wikipedia Article X and Source Y, what propositions would be suitable to pursue for enhancement of the Wikipedia article (X) based on the newly propositioned citation (Y)? The beauty of this is that it provides suggestions to editors about how to contribute rather than working toward AI-based article revisions. Thoughts? --03:16, 6 August 2024 (UTC) — Preceding unsigned comment added by Ceyockey (talk • contribs) 03:16, 6 August 2024 (UTC)[reply]
This is a nice idea. I suppose people can already do this albeit in a clumsy, high friction way now that LLM context windows are large enough to cope with the entire contents of Article X and Source Y. Sean.hoyland (talk) 13:26, 6 August 2024 (UTC)[reply]
But that's not that hard for a human to do. I think the effort of building that infrastructure for mediawiki would outweigh the total effort of doing it the way we do now. Cremastra (talk) 14:06, 6 August 2024 (UTC)[reply]
Bot to block Proxy/VPN IPs (ST47ProxyBot replacement)
Hey folks, I'd like to get some thoughts on an adminbot that monitors RecentChanges and reactively blocks VPN/open proxy IPs it encounters. We used to have ST47ProxyBot which preemptively blocked such IPs, however the bot's operator, ST47, has indicated that they are no longer interested in running this bot. Long story short, there is a plethora of VPN/open proxies on the internet with new operators coming online every day; it has become technically unfeasible to identify and block all of these. Bad actors have been attacking our admin noticeboards with these VPNs/open proxies which has resulted in them being semi-protected for extended durations of time. That said, I'm interested in building an adminbot that monitors RecentChanges (or just the administrator noticeboards) for edits from VPN/open proxy IPs and blocks them (can optionally revert the most recent edit made by these IPs too). Noting for the record that some discussion on this has occurred here (permalink). Courtesy ping for @Robertsky. -Fastily21:25, 8 August 2024 (UTC)[reply]
I don’t have strong feelings against this one way or another. I share the concerns of others that, especially with developments in internet infrastructure over the past decade or two, it is much less simple to block open proxies now. But if an admin bot can accurately evaluate (with a sufficient level of accuracy) and block/revert, so what if it only catches 1% of the actual open proxies? I also think this should be evaluated as a “continuation” of the prior adminbot - even if it has slightly different code, from what I can see there was consensus for this type of adminbot before so absent significant new concerns about the stability/false positives now, should be fine for Fastily or another admin to take over the *task* even if doing it with different code. -bɜ:ʳkənhɪmez | me | talk to me!21:35, 8 August 2024 (UTC)[reply]
Thus far the disruptive IP addresses that have been blocked on the admin boards has proxy-like behaviours stated in the user information tool (that can be seen on the Contributions page). That can be a likely reliable signal/condition to revert and block such IP addresses if they touch on the admin boards. – robertsky (talk) 10:52, 9 August 2024 (UTC)[reply]
Agree with Berchanhimez that this task doesn't seem like it should require a second consensus for approval, but if it does I support it. Folly Mox (talk) 11:28, 9 August 2024 (UTC)[reply]
A bot that monitors recent changes and reactively blocks VPN/open proxy IPs rather than preemptively may be a useful compromise. We already have a bot that monitors recent changes and logs VPNs/proxies at WP:OPD; it seems to log very many but perhaps not all, that will be dependent on the database. As an aside, I’ve never see so many blocked 'anonymizers' on that log, which is almost entirely due to the current disruption.
The current disruption is using a very particular anonymizing network so perhaps a focus on blocking that one preemptively would be helpful in the short term. -- Malcolmxl5 (talk) 18:38, 9 August 2024 (UTC)[reply]
I think we may need to look at some possible ways to fix WP:OR. Apparently, one editor thinks it means you can't use any news media coverage for articles. i think their point is maybe that you can only use peer-reviewed articles to cover current events, since those are published findings? i think.
this whole thing kind of doesn't make a whole lot of sense, to me. anyway, I am trying to decide what to add to WP:OR. i have a few possible drafts, but i wanted to get this section started now. i hope to work on some possible drafts, and then post them soon. However, please feel free to comment now. Sm8900 (talk) 14:01, 9 August 2024 (UTC)[reply]
If the issue is just one editor misunderstanding the existing content then the solution is to explain to them what it actually means. If they cannot or will not understand that then the solution is to take action against that user to prevent their misunderstanding disrupting the encyclopaedia. Only if the misunderstanding is widespread is a rewrite of WP:OR likely to be needed. Thryduulf (talk) 14:09, 9 August 2024 (UTC)[reply]
@Thryduulf, that sounds pretty good. i could use a little heelp, actually. would you be willing to please add some input? you can find the article talk page easily, in my contribs history today. Sm8900 (talk) 14:52, 9 August 2024 (UTC)[reply]
If we want a misinterpretation that's so wide-spread it has been written into the policy, how about we get rid of most of Wikipedia:No original research#Primary, secondary and tertiary sources? As far as I've ever seen, the distinction between "primary" and "secondary" is often unclear and seldom actually useful versus the nutshell of WP:OR itself, Articles must not contain any new analysis or synthesis of published material that reaches or implies a conclusion not clearly stated by the sources themselves. Even much of what's said in the PSTS section is just as true if you only read "source", ignoring the adjectives. Mostly the section seems a vehicle for people to reject a source for being "primary" (i.e. the opposite of the essay Wikipedia:Primary does not mean bad) instead of having a harder discussion about WP:RS and WP:DUE and the other parts of WP:OR. But I doubt this will go anywhere, too many people value exactly that vehicle. Anomie⚔15:02, 9 August 2024 (UTC)[reply]
@Anomie I agree too. I've lost count of the times that I've had to argue that for objective facts primary sources are often the most reliable sources. Thryduulf (talk) 16:06, 9 August 2024 (UTC)[reply]
I agree too. Secondary sources are fine when we have them, but the current wording seems to disfavour primary ones more than they deserve. Gawaon (talk) 16:45, 9 August 2024 (UTC
here is the kind of comment i have to deal with in opposiition to using perfectly good factual data, from perfectly reliable good sources from newspapers: The text that would be added makes no coherent case or argument. It has no clear theme, thesis or point. It does not show an analysis. This would require secondary sources - preferably of good quality. That would then be encyclopedic content. Research is the analysis of primary material. Drawing together the data is the first step in research. The added text alludes to a thesis, which, if stated, would be OR (where the thesis does not exist in sources). But without this, the text lacks the cohesion and substance that would make it encyclopedic. If the thesis is not presented in sources, it probably isn't noteworthy - or perhaps it hasn't been found. Either way, the addition as made isn't supported.
so this comment is saying that absolutely no data can be gleaned from primary sources such as newspaper accounts, firsthand accounts, etc. really!! this is unbelievable!! is there anything we can do???!!! Sm8900 (talk) 01:59, 10 August 2024 (UTC)[reply]
so by this logic, even a published book would not be able to serve as valid source for self-efident objective facts, such as the book plot etc!!! this doesnt seem reasonable!!! Sm8900 (talk) 02:01, 10 August 2024 (UTC)[reply]
Without more context, that's a discussion that probably needs to happen on the page where it's happening rather than here. "The text that would be added makes no coherent case or argument" is something one cannot judge without knowing the text in question. Gawaon (talk) 06:39, 10 August 2024 (UTC)[reply]
@Gawaon, the talk page is at Talk:Iraq War. they are simply refusing to let me use newspaper articls that clearly show that major national leaders expressed opposition to the war years later. the question of whether that topic is needed is not the focus of the comment above; they are literally rejecting any use of newspaper articles, as clearly shown in the comment above. Sm8900 (talk) 11:12, 10 August 2024 (UTC)[reply]
Instead of "getting rid of" PSTS, I suggested splitting it to its own policy page a while ago (1, 2, 3, probably others). It did not go well. We had really fundamental I-can't-believe-we-are-all-native-English-speakers-here levels of failure in communication. The most frustrating was trying to convince people that if we put the PSTS ==section== on a different page ►with a {{policy}} tag at the top, it would still be a policy. Editors thought that giving PSTS its very own {{policy}} page would be a demotion that would somehow make it stop being a policy. WhatamIdoing (talk) 21:13, 12 August 2024 (UTC)[reply]
Wow, yeah. Looks like you had two people there who had things absolutely backwards, seemingly convinced that whether a source is "primary" or "secondary" is critical to determining whether something is WP:OR or not rather than that WP:OR#PSTS is a (somewhat poor) heuristic for "source that will probably have the kind of analysis we need for a good article". Anomie⚔01:42, 13 August 2024 (UTC)[reply]
really fundamental I-can't-believe-we-are-all-native-English-speakers-here levels of failure in communication
I believe that news sources are good for basic facts, but their use should mostly end there. It's not that you should never use news articles as sources, but at a practical level the key is contemporary versus retrospective coverage. Real time contemporary sources definitely shouldn't be used to determine notability, provide analysis, explain effects or significance, etc. They lack the scope and context to make that possible. To avoid bogging down discussions every time this comes up, I wrote my full thoughts at User:Thebiguglyalien/Avoid contemporary sources. Thebiguglyalien (talk) 07:31, 10 August 2024 (UTC)[reply]
by this logic, you would never be able to write articles about opinions of major public figures at all. you would not be able to use a newspaper article to glean a public figure's opinions on anything, and you would need to someohow search for some complex thesis article when writing even about the most minor issues. Sm8900 (talk) 11:20, 10 August 2024 (UTC)[reply]
Well, that's kinda the point? If no one else has ever written about the views of some major public figure on some topic in e.g. a book about the topic or the public figure, and the only place we can find that information is in some contemporary news article, then it's probably not important enough to include in an encyclopaedia article. Folly Mox (talk) 13:28, 10 August 2024 (UTC)[reply]
on the contrary, most historical statements get completely missed by secondary soruces. this is wikipedia. the historical coverage here is ten times more broad and more complete than any other reference works that are published. Sm8900 (talk) 23:10, 11 August 2024 (UTC)[reply]
Your impression of our historical coverage is roughly the reciprocal of my impression, ± a few orders of magnitude. And I'd posit that most historical statements are deliberately unmentioned by secondary sources, not "missed" during the research phase. Folly Mox (talk) 09:29, 13 August 2024 (UTC)[reply]
ok, so then wikipedia is the repository for such statements, which most historical works and journal articles would otherwise miss entirely. Sm8900 (talk) 14:36, 13 August 2024 (UTC)[reply]
This is a fundamental misunderstanding of what Wikipedia is and is WP:NOT. In all these years, has no one ever nudged you in the right direction and told you that you're supposed to be summarizing information from reliable secondary sources, proportional to how it appears in these sources? That you can't string together primary sources to support an argument? The historical works and journal articles have already decided what's significant enough to cover. We don't get to act like we know better than them; that would be original research and it would deviate from a neutral point of view. Surely at some point your work has seen scrutiny through a process like GAN or PR where a problem like this should have been noticed? Thebiguglyalien (talk) 15:20, 13 August 2024 (UTC)[reply]
ok sorry, i truly don't understand. so if a natural disaster, or an election, or a major coup, or a major government appointment occured within the last week or so, what sources should be used, other than newspaper articles? could you please clarify?
I think this discussion will go much better if we are simply open to asking questions, or expressing constructive ideas and opinions, and getting useful information. ok, so please feel free to clarify. thanks. Sm8900 (talk) 15:28, 13 August 2024 (UTC)[reply]
If a simple fact needs updating like who holds a government office, then yes, a news article is fine to verify that. News articles might also be useful for basic facts, like if one mentions someone's date of birth for example. It's not that primary sources can never be used. It's that they don't dictate content. Like I said under section break 2, WP:PROPORTION lays it out plainly. An event or an opinion simply appearing in the news on its own isn't enough to say it needs to be in an article (let alone have its own article); millions of things appear in the news. But if a subject matter expert includes it in a journal, a book, or any sort of analysis, that's an indication that it might be WP:DUE. Thebiguglyalien (talk) 15:53, 13 August 2024 (UTC)[reply]
ok. thats a valid reply. but then, why do we have articles on elections , coups, natural disasters, new laws, changes in government, etc? if no secondary soruces exist for such event when they are only two or three weeks in the past, then how can such articles exist? Sm8900 (talk) 16:12, 13 August 2024 (UTC)[reply]
Political stuff like elections and coups get analyzed pretty much right away. There's already extensive analysis of the upcoming U.S. elections, and those are still months away. But in my opinion, people often jump the gun on creating articles about events like disasters or crimes, and they often have to get deleted eventually. Thebiguglyalien (talk) 16:18, 13 August 2024 (UTC)[reply]
ok, so now wait a second friend. the title of this is maybe we need to fix wp:or, remember? so now maybe we are finally coming around to the actual topic here. ok, so you vote in the column for not using newspapers as sources too often. ok, fair enough. now can we discuss the fact that we already do use them, and then maybe consider what would be some logical constraints or ideas, for how to actually do so properly? Sm8900 (talk) 16:28, 13 August 2024 (UTC)[reply]
I would actually say that they are often secondary. Sometimes they are primary sources, like if you wanted to source an editorial for someone's opinion. Loki (talk) 17:06, 13 August 2024 (UTC)[reply]
Gawaon This is a common misconception, but it makes a huge difference when it comes to OR and NPOV. When we're considering newly reported content like we are here, they are primary sources. This is the case both in academic historiography and on Wikipedia. Per WP:RSBREAKING: All breaking news stories, without exception, are primary sources, and must be treated with caution. WP:PRIMARYNEWS also gives a little explainer. Thebiguglyalien (talk) 17:19, 13 August 2024 (UTC)[reply]
ok, but "breaking news stories" are totally different from articles pblished in an actual print newspaper. "breaking news" refers to stories that can only exist online, as they would need appear immediately after the event. and also, to quote that page: Just because most newspaper articles are primary sources does not mean that these articles are not reliable and often highly desirable independent sources.Sm8900 (talk) 17:44, 13 August 2024 (UTC)[reply]
Breaking news comes out of radio and television: they would "break into" normal programming (e.g., interrupt a soap opera) to make an announcement. The older equivalent is a Newspaper extra (if you have enough to fill a page) or just a last-second article added at press time (or after it, in the case of a stop press order). WhatamIdoing (talk) 20:40, 13 August 2024 (UTC)[reply]
@Folly Mox, if the only place we can find that information is in some contemporary news article, then thats why we would use the news article as the source for that, actually. Sm8900 (talk) 21:18, 12 August 2024 (UTC)[reply]
Sm8900, I took a Quick Look at the text you would like to add, and immediately saw why other editors are saying that it violates WP:OR. The text starts with a sweeping statement about the world’s view of the war and then attempts to support that statement by giving examples of politicians sharing that view. The examples are individually (and appropriately) supported by citing news sources, but… what is missing is a source that sums up these examples to reach the initial sweeping statement (a conclusion, even though it is written first).
This is classic original research. We can not take examples A+B+C and state conclusion D … unless we have a source that explicitly states A+B+C=D. This is precisely why WP:PSTS warns that primary sources must be used with caution. It is very easy to misuse them to inappropriately support original research. Blueboar (talk) 12:45, 10 August 2024 (UTC)[reply]
That does not resolve the Original research… the problem is that you (a Wikipedia editor) are the one combining these individual statements by various politicians to form a conclusion. What you need is a reliable secondary source that combines the statements by various politicians to reach some form of conclusion.
Weasle wording “some” also introduces DUE WEIGHT issues: why were the statements by these specific politicians chosen? Do they represent the majority view or are they cherry-picked outliers? Are there politicians who have contrary views?
Again… what you need to look for is a secondary source that notes what various politicians have said about the war, puts what they said into context and sums it up. Doing it yourself (even hedged by weasel wording) is where you engage in the original part of NOR. Blueboar (talk) 13:40, 10 August 2024 (UTC)[reply]
Those kinds of secondary sources don't always exist, depending on the topic. And when reporting politicians positions and views, then published news articles seem totally acceptable as sources. Sm8900 (talk) 22:35, 10 August 2024 (UTC)[reply]
That's the point. If those secondary sources don't exist, then it should not be in the article. To quote WP:PROPORTION from the NPOV policy: An article should not give undue weight to minor aspects of its subject but should strive to treat each aspect with a weight proportional to its treatment in the body of reliable, published material on the subject. For example, a description of isolated events, quotes, criticisms, or news reports related to one subject may be verifiable and impartial, but still disproportionate to their overall significance to the article topic. This is a concern especially for recent events that may be in the news.Thebiguglyalien (talk) 22:50, 10 August 2024 (UTC)[reply]
That sounds vastly exaggerated and non-proportional. Especially for recent events, it'll take years, if not decades, until they (maybe) get reliable coverage in secondary (later insertion: academic) ssources. Academics don't work so fast. Plus many films, series etc. may well get next to no coverage in secondary sources at all, despite meeting our notability criteria. If there are secondary sources, it's best to chiefly rely on them. If not, primary and tertiary sources may well come to the rescue, and that's a good thing. Gawaon (talk) 06:58, 11 August 2024 (UTC), edited 07:25, 11 August 2024 (UTC)[reply]
If there's next to no coverage in secondary sources at all, then it is not notable. Per WP:GNG: "Sources" should be secondary sources, as those provide the most objective evidence of notability. There is no fixed number of sources required since sources vary in quality and depth of coverage, but multiple sources are generally expected. If you think that means Wikipedia would have to ignore most current events, then you're correct. Wikipedia doesn't exist to document news. Thebiguglyalien (talk) 07:08, 11 August 2024 (UTC)[reply]
Okay, I got confused a little bit. Generally I tend to think of secondary sources as academic sources, and I'd say those are indeed among the best sources we have. But I had somehow mentally classified newspaper coverage and such as tertiary sources. However, it seems they are generally considered secondary too. WP:NOR#Reliable sources even says that "magazines, journals ... published by respected publishing houses" as well as "mainstream newspapers" are among "the most reliable sources". So sure, a topic needs sufficient coverage in secondary sources, newspapers included, to get its own article, per WP:GNG. I absolutely agree on that. But note that the GNG is about whether a topic gets its own article, it's not about the article content at all. See WP:NNC. Here we're mostly talking about content, so the GNG doesn't apply. Gawaon (talk) 07:42, 11 August 2024 (UTC)[reply]
While some changes might be needed, I think I would be against "getting rid of most of Wikipedia:No original research#Primary, secondary and tertiary sources." In editing historical topics, I have found WP:PRIMARY useful. Users have, for example, tried to argue that Nathan Bedford Forrest wasn't actually racist or involved with the KKK, tried to argue that Mehmed II committed rape on the floor of the Hagia Sophia, etc., using primary sources. If accounts like these (memoirs, diaries, travel literature, ancient histories, etc.) aren't reinforced or repeated by scholars, they usually don't belong in there. I am definitely not arguing for a blanket ban on journalistic sources; the user you're telling about was clearly misinterpreting it. I am just saying how it has been useful for me.--MattMauler (talk) 14:24, 10 August 2024 (UTC)[reply]
@MattMauler, thats very useful input. your statement here is very useful: I am definitely not arguing for a blanket ban on journalistic sources; the user you're telling about was clearly misinterpreting it.Sm8900 (talk) 23:09, 11 August 2024 (UTC)[reply]
I would make two points. Firstly many editors seem to think that the distinction between primary and secondary sources is something that was made up by Wikipedians. It was not. It has long been used by historians and rather more recently by scientists. And secondly I get the impression that there is a generational divide here between us oldies, who grew up in the days before Wikipedia (and even the World Wide Web) existed, and remember encyclopedias that existed before Wikipedia supplanted them and that were nothing like newspapers, and the youngsters who seem to think that every web site has to be up-to-the-minute with breaking news. Phil Bridger (talk) 20:01, 11 August 2024 (UTC)[reply]
I'm finding it completely baffling to understand the objection to secondary sources. where is the secondary, non-journalistic source to tell you who is the Secretary of Agriculture? who is the governor of Maine? who is the director of budget for the city of Norfolk, Virginia? what is the current status of the Iraqi government? what is the current nature of the Q train in Brooklyn, New York? what are current plans for the BQE expressway in New York?
furthermore, if an article is decribing any recent current event, then what source would they use other than news articles? there are dozens of examples, obviously. for example, if the article is covering the US withdrawal from Afghanistan, or the 2024 US presidential election, or the accession of King Charles of the UK, what sources would exist at all, other than news articles? I'm truly baffled by this. Sm8900 (talk) 03:37, 12 August 2024 (UTC)[reply]
we already have an article on the recent tragic plane crash in brazil. i don't want to detail it too much in this venue, out of respect for the human tragedy here. however, there would not be any source to use for details on this, other than newspapers. Sm8900 (talk) 04:52, 12 August 2024 (UTC)[reply]
The relevant guideline is WP:PRIMARY. Generally speaking a primary source trumps a secondary when it is authoritative. In other words, the Secretary of Agriculture is whoever the Department of Agriculture says it is. When it comes to news sources, they can be primary sources and sometimes not. For current events, news sources may be the only sources available. However... primary sources must always be used with great care. It is fine to use them for facts, but you cannot draw conclusions from them. (WP:No original research) For this, secondary sources are required. Hawkeye7(discuss)05:13, 12 August 2024 (UTC)[reply]
@Hawkeye7, I Agree !! please note, my key point of agreement is with this statement of yours. please note, I'm saying this with sincere assent, as your statement on this seems fully valid to me!! For current events, news sources may be the only sources available. ....primary sources must always be used with great care. It is fine to use them for facts... [etc]Sm8900 (talk) 15:51, 12 August 2024 (UTC)[reply]
Last night I was reading Death in Yellowstone and the author talked about the dilemma of using newspapers: Newspapers, as every historian knows, must be used with care, most often as a supplement to more reliable sources. Unfortunately, with all of their potential inaccuracies, caused by deadlines, distance, and other factors, newspapers are sometimes our only sources for fleeting bits of history, pieces that get too easily lost in the forward march of time, and pieces of strictly local history that get published nowhere else. It caught my attention because of this ongoing discussion. Schazjmd(talk)13:16, 12 August 2024 (UTC)[reply]
can we make a rule against excluding newspapers as sources??!!
there seems to be some contradictory rhetoric going on, above on this page. we Wikipedia has articles such as 2024_United_Kingdom_riots#10_August, yet we have people in the section above stating outright that newspapers should not be used as sources. can we simply make it clear there is no basis for excluding newspapers as sources? this simply seems ridiculous. --Sm8900 (talk) 20:25, 12 August 2024 (UTC)[reply]
Newspapers need to satisfy WP:RS requirements and be weighted accordingly with the claim made. There is extensive and nuanced discussion in WP:RSN to resolve disputes over reliability of said newspapers. Happy verifying! ~ 🦝 Shushugah (he/him • talk) 20:29, 12 August 2024 (UTC)[reply]
further example(s) below, of articles requiring newspapers as sources. this whole issue seems self-evident to me.
I think we can make a blanket rule that no source should be excluded based solely on what type of source it is. Sometimes using a newspaper is appropriate, sometimes using a newspaper is in appropriate - but in neither case is that because it's a newspaper it's because of the combination of the context of the Wikipedia article and the context of the specific source article. Indeed WP:MEDPOP explicitly says the quality of press coverage of medicine ranges from excellent to irresponsible. An excellent newspaper article about a treatment that explains it in appropriate context without oversimplification etc might be the best available for the topic, conversely articles in peer review journals get retracted and those should not be used (other than for WP:ABOUTSELF and similar purposes).
One I've seen a few times is editors rejecting a youtube video as a source because it's a youtube video. Some youtube videos are top quality reliable sources, some are active disinformation. Thryduulf (talk) 00:16, 13 August 2024 (UTC)[reply]
yes, I agree with @Thryduulf on their comments on this, as stated above.
I think we can make a blanket rule that no source should be excluded based solely on what type of source it is.
One [problem] I've seen a few times is editors rejecting a youtube video as a source because it's a youtube video. Some youtube videos are top quality reliable sources, some are active disinformation.
I agree that we can not (and should not) “ban” citing news media… however, I do think that we often cite news sources inappropriately. There is a more nuanced discussion that needs to take place: When is it appropriate to cite news media, and (perhaps more importantly) when is it inappropriate to do so?Blueboar (talk) 15:07, 13 August 2024 (UTC)[reply]
@Blueboar, awesome insight and idea. i'm hoping discussion can proceed, and address the possible refinement that you have helpfully added and expressed above. thanks!!! Sm8900 (talk) 15:10, 13 August 2024 (UTC)[reply]
I don't think we really need any more rules about newspaper sources. We already have WP:PRIMARYNEWS, which qualifies when newspapers should be treated as primary sources, and WP:MEDRS, which state that newspapers aren't usually appropriate for medical topics. It really depends on the context and the reliability of each specific source though. Even generally high quality sources like the NYT may not be reliable for high-level scientific discussion, whereas a local newspapers that gets all the facts right can sometimes be used as a source for a complex topic. Epicgenius (talk) 23:52, 13 August 2024 (UTC)[reply]
OR is working well and as intended, actually
This discussion wasn't making much sense to me until I read Talk:Iraq War#suggest we need a section on "political impact", and then everything fell into place. Sm8900 is trying to add a section on the war's political impact which synthesises quotes he's selected from various American politicians into sweeping statements like By 2016, the public consensus in both major parties of the United States was that the Iraq War was based on invalid reasons, did not accomplish anything positive, and was highly detrimental. Other editors are correctly pushing back on this because this is a conclusion he has drawn himself rather than a conclusion drawn from a source. This is good. There is no problem here. – Teratix₵06:37, 13 August 2024 (UTC)[reply]
it is not good, and your dismissal of this topic shows your approach.
and there is absolutely nothing wrong with adding a section to describe politicians' opinions on any particular policy issue, using newspaper accounts and articles as sources. it is entirely possible that my own draft on that specific topic needs to be changed or improved, or perhaps discarded if it does not have consensus. that does not change the larger issue here.
your obvious goal is to cause some degree of personal upset here. by the way, @Teratix, all that's needed for WP:Civil to be needed here, is for one of us to state that the other one is acting discourteously. that is it. I will be glad to show you basic courtesy, and ask only the same thing in return. Sm8900 (talk) 14:41, 13 August 2024 (UTC)[reply]
re the public consensus on the Iraq War, when Jeb Bush did not express strong opposition to the Iraq War during the 2016 campaign, he was widely criticized, both by major candidates and also by major media outlets, so in the end he did need to reverse his approach.
and newspaper articles which provide broad overviews of a major societal consensus or reaction, are indeed valid sources in this regard. maybe we need to open a section to address the larger issues here? oh wait, thats right, that's precisely what this section is. Sm8900 (talk) 14:44, 13 August 2024 (UTC)[reply]
in short, your objections above may indeed be valid re my own proposed text for that specific article. with that said, the topics of this discussion here at village pump are entirely different. editors here are entirely free to agree or disagree with my ideas here on the topic of WP:OR, as they see fit.
however i think it is obvious that any editor would find it somewhat demeaning to see their own ideas on one article brought into the discussion as an absolutely non-relevant tangent, in a page section which relates to other issues entirely. i am trying to indeed grant the validity of anyone's views who may wish to disagree with my approach for the proposal at that specific article as you cite above. Sm8900 (talk) 14:59, 13 August 2024 (UTC)[reply]
any editor would find it somewhat demeaning to see their own ideas on one article brought into the discussion as an absolutely non-relevant tangent. By your own account, the pushback you received from other editors regarding your proposed addition on Talk:Iraq War was the impetus for starting this discussion in the first place. You, yourself, have quoted and mentioned the discussion in the above sections. Why would you do that if you didn't think it to be relevant?
there is absolutely nothing wrong with adding a section to describe politicians' opinions on any particular policy issue, using newspaper accounts and articles as sources There is a problem when you draw conclusions that the sources do not reach themselves, when the section gives certain perspectives undue weight or when there are higher-quality sources available that could be used instead. These problems were why your proposed Iraq War section was rejected.
that does not change the larger issue here. The point is, despite what you think, there is no larger issue here. Editors applied the policy exactly how they are supposed to, they got the right result, Wikipedia is better off than it would have been. Changing the policy would make things worse.
I'm not out to upset you. I just think your ideas about how Wikipedia works, and how it ought to work, are badly, badly wrong. It's not personal. – Teratix₵15:55, 13 August 2024 (UTC)[reply]
You, yourself, have quoted and mentioned the discussion in the above sections. Why would you do that if you didn't think it to be relevant? correct, i mentioned the specific views on the question of what sources can be used, since thats the topic of this section here at village pump. i did not belittle any of the replies that disagreed with me on the specific proposal for that specific article.
There is a problem when you draw conclusions that the sources do not reach themselves, when the section gives certain perspectives undue weight .. these problems were why your proposed Iraq War section was rejected. i'm completely ok that there may be flaws or problems with my proposed text for that article, and that the community may choose to disagree or indeed reject the proposed text for that article, if it chooses.
The point is, despite what you think, there is no larger issue here. Editors applied the policy exactly how they are supposed to, they got the right result, with respect, pelase read the mutilple replies i have received above, that agree with my views on the larger issue here. thats the whole point of opening this question for wider discussion here, where the community can comment.
I'm not out to upset you..... It's not personal. ok, noted. I'm fully willing to accept your reply on that, as helpful, and as constructive, and as responsive to my concerns. i do appreciate your reply, on that note. thanks.
Sm8900… WP:NOR is less about which sources we use than it is about how we use them. Wikipedia is a tertiary source. Our job is to summarize what others have said, and not to say original things. When we give examples to support a conclusion, we need to show that at least one reliable source reaches the same conclusion using those same examples. Otherwise, we are stating something original. Teratix is correct in saying that the policy is working as intended. Blueboar (talk) 16:47, 13 August 2024 (UTC)[reply]
Like was pointed out above, newspapers usually are secondary sources. The issue here is that you're using them to cite something they don't technically say.
My suggestion is to just be very precise in your phrasing. To draw a sweeping conclusion you need a direct source for that, but you can definitely source "Many prominent politicians regarded the war as ..., such as X, Y, and Z" with sources quoting X, Y, and Z. Loki (talk) 17:11, 13 August 2024 (UTC)[reply]
I think news articles are usually primary sources. Most news articles, if you actually pick up a paper copy and count them up, are very short and say little more than "An event has been planned" or "Someone got arrested for drunk driving" or "A routine government meeting happened". WhatamIdoing (talk) 20:45, 13 August 2024 (UTC)[reply]
What's more important here is to say that newspapers are usually reliable sources – they're just not appropriate for picking random quotes out of (or cherry-picking quotes that support a preferred POV). As WP:RS says, " Each source must be carefully weighed to judge whether it is reliable for the statement being made in the Wikipedia article and is an appropriate source for that content." An appropriate source for the views of various countries or groups for a war that started more than 20 years ago is going to be a book or a scholarly work. WhatamIdoing (talk) 20:49, 13 August 2024 (UTC)[reply]
A book or scholarly work is usually going to be more appropriate. That's very different to a different type of source always being inappropriate. It depends on the specific claim that the source is being used to support. Thryduulf (talk) 21:23, 13 August 2024 (UTC)[reply]
Again… The NOR policy is not about whether we can use newspapers (or any other type of source), but about how we use them. A source can be used appropriately in one context, but be used inappropriately (in a way that violates this policy) in a different context. Blueboar (talk) 17:52, 13 August 2024 (UTC)[reply]
if you mean my proposal for that specific article is flawed and needs some work, point taken, and no argument there. thanks! Sm8900 (talk) 17:07, 13 August 2024 UTC)
Thank you, User:Teratix, for the clarification. Having read the Talk:Iraq War discussion I couldn't understand the reactions of the other participants in this Village Pump discussion. Even after Sm8900 basically told on themselves. Schierbecker (talk) 20:17, 13 August 2024 (UTC)[reply]
Content assessment tweaks
Since Content assessment was decoupled from individual WikiProjects, I'd like to develop an idea regarding how it can be tweaked. Currently assessments for Stub-class to B-class can be placed on a talk page by any editor, but the manner in which reassessment is done can be a little tricky. If an editor wants to have their article reassessed (such as moved up from Start to C class), where to do this is currently a little convolluted.
This can be asked on the article talk page, but most talk pages on Wikipedia are will not yield a result, as they are either empty or inactive or both. Or it can be asked on a WikiProject page, which is still not a guarantee of getting it answered (also, might defeat the point of unlinking content assessment from WikiProjects in the first place). Or it can be asked on Wikipedia:WikiProject Wikipedia/Assessment – which doesn't make sense technically. Surely WikiProject Wikipedia/Assessment should be about articles relating to Wikipedia, instead of acting as a general catch-all page as it currently does.
My question is – how could this be optimised? For example, should assessment requests be moved to one centralised location? If so, where? Hope village pump can help me here DimensionalFusion(talk)15:44, 10 August 2024 (UTC)[reply]
Other than promotion to GA or FA status, very few editors pay attention to article assessments… so we don’t actually need clear cut criteria or a process for assessment. We can rely on editorial judgement.
If you think an article should be assessed as being in a certain “class”, feel free to mark it so. If someone else disagrees, discuss it on the article’s talk page. Blueboar (talk) 16:11, 10 August 2024 (UTC)[reply]
Yes, and marking an assessment totally independently, without any input from others is and would remain a valid way to assess an article. However, some people may not wish to do this and may want to have an uninvolved editor look at the page. This is the problem I would like to address DimensionalFusion(talk)16:17, 10 August 2024 (UTC)[reply]
(edit conflict) If there is benefit in an editor being able to request someone else take a look at an article and seeing whether they think the quality assessment is correct then I can think of two approaches that might work:
A central location in which to ask.
A template that can put on an article talk page that populates a category.
In both cases WikiProject article alerts should be generated to aid discoverability by editors interested in the relevant topic area.
Whether there is benefit in such a system is a different question, but I think the answer is yes. Even if it's optional in most cases, someone who was heavily involved in rewriting the article or who has a COI with regard to the subject or who is a declared paid editor may want to (in the latter two cases probably should) ask for another editor's opinion. Thryduulf (talk) 16:20, 10 August 2024 (UTC)[reply]
If I come across an assessment that is clearly wrong on an article I am involved with, I simply edit out the assessment. By means that are completely mysterious to me someone eventually comes along and (re)assesses it. Thincat (talk) 10:17, 11 August 2024 (UTC)[reply]
@DimensionalFusion I think @Thincat is saying that if an article they are involved with is rated as e.g. start class but they believe that is clearly wrong they will simply remove the assessment rank, meaning the formerly start class article is now unassessed class. In their experience these articles then get a new rating (that presumably more closely matches their opinion) from somebody else without any additional input from them (i.e. they make no requests anywhere). They don't know how the people who do the new assessment become aware that this needs doing (although my guess is that they're patrolling e.g. Category:Unassessed United Kingdom articles). Thryduulf (talk) 10:39, 11 August 2024 (UTC)[reply]
In my experience that doesn’t tend to lead to articles being reviewed, either because it is a broad topic (leading to a huge backlog) or because it has a very inactive wikiproject DimensionalFusion(talk)10:51, 11 August 2024 (UTC)[reply]
DimensionalFusion, content assessment between "stub" and "GA" is meaningless. No one is likely to respond to a request to reassess article quality unless you're taking it through a formalised peer review process, and editors interested enough in the topic would likely respond better at any centralised venue to a generic hey I just created / expanded Topic; improvements welcome than to a request for reassessment.If you're not comfortable changing the assessment rating yourself on articles you've significantly contributed to, turn on WP:Rater in Special:Preferences, and use whatever it suggests with the default edit summary. If you want other editors to take a serious look at your work, take it through WP:GA. Folly Mox (talk) 14:52, 11 August 2024 (UTC)[reply]
If content assessment between "stub" and "GA" is meaningless then why does it exist at all?
Anyway, for people who know that an article does not meet GA standards but want it to be looked at/rated by another editor, if only for 15 seconds, would create a massive waste of time in taking it to GAN as you suggest, which already has a massive backlog. One of the ways to reduce that backlog would be to improve the process for content assessment, no?
As someone mentioned below, they're mostly an historical artefact, leftovers from the days when WikiProjects roamed still. I don't know why we still have them. My apologies if it seemed like I was recommending taking a known sub–GA-quality article through GA. I miscommunicate sometimes. What I meant is that other editors are not likely to invest significant time reviewing work that the primary contributors have not already invested significant time into.We might not be seeing eye to eye on this because I'm experiencing disagreement with your problem statement. To me, reassessment has never felt tricky: if I've improved an article and notice its rating feeling out of sync, I'll update it. Also the notion of a venue where someone might be guaranteed a response doesn't feel in alignment with the state or ethos of the project.I suppose you could just remove the rating on articles you've recently improved, which should lead to someone else assessing them eventually. Folly Mox (talk) 18:29, 11 August 2024 (UTC)[reply]
How soon will eventually be though? As far as I'm aware, the Citation needed category for example hasn't led to many articles having citations added
Recent backlog drives at WikiProject Unreferenced articles and WikiProject Reliability have used maintenance categories to improve the project, but it really does seem like that kind of organised effort is what it takes to budge the needle even a little bit on highly populated maintenance categories.At some point last year WikiProject Stub improvement was reactivated to expand stub-class articles, which didn't last long since there were an overabundance of false stubs. I blame myself for rating some of these upwards out of the stub categories without significant expansion.I don't have good anecdata for routes to GA, but I don't think I've ever heard of anyone taking an article there on the basis that it was already B-class. I have seen B-class used in guidance once or twice, like at H:YFA, where newcomers modeling their first article on existing examples are advised to make sure their model is at least B-class.As to my eventually above, that's difficult to predict, and I don't have time at the moment to look into how long articles remain unassessed, nor even how to formulate a method of checking. Late for work, Folly Mox (talk) 11:34, 12 August 2024 (UTC)[reply]
Given the amount of outrage declared paid editors doing anything that could be seen as advancing the interests of their employer (regardless of whether this aligns with Wikipedia's interests) causes among some sections of the community, I think some method of requesting an independent assessment is warranted. Personally I don't see them doing this as an issue at all, but I recognise my views regarding paid editing are a lot more relaxed than the average. Thryduulf (talk) 12:05, 11 August 2024 (UTC)[reply]
If a paid editor has contributed significantly to an article, should they be allowed to change the rating of that article themselves? As I say I don't have a problem with that (as long as it's not to GA/A/FA, but that applies to everyone) but given how controversial paid editing is I suspect some people will have a problem with it. Thryduulf (talk) 12:48, 11 August 2024 (UTC)[reply]
Given that there is absolutely NO BENEFIT to be gained from changing an article assessment from “Start” to “C” (or even “B”)… why would it matter if the changer was paid to do so? Blueboar (talk) 13:19, 11 August 2024 (UTC)[reply]
@Blueboar If there is "absolutely no benefit" why do we have three different ratings? Is telling a client you improved their article from "C" to "B" not a benefit?
@Gawaon neither paid editing or content assessment is a "problem", I think you're misunderstanding this discussion. The question being asked in this discussion is "Should there be some central location or other method for editors to request a different editor re-assess the quality of a given article?" This cannot be answered without answering the question "Is there a reason and/or benefit to requesting another editor do this rather than just doing it themself?". My view is that the answer to the second question is "yes", giving a paid editor as one example scenario of when it would/might be better for another editor to do it. Paid editing is controversial (imo way more controversial than it should be, but that's beside the point) but it is not, in and of itself, a problem. Content assessment is not a problem, but an individual editor reassessing the quality of their own work might be a problem in some circumstances. Given that such circumstances exist, I see benefit in their being a way to avoid the problem. Thryduulf (talk) 13:33, 11 August 2024 (UTC)[reply]
It's like Blueboar says: Ratings are a hint to other editors, our readers will in general neither see nor care about them, and the payer probably won't either. Gawaon (talk) 13:44, 11 August 2024 (UTC)[reply]
Thryduulf- To be blunt, we don’t need all these ratings. The original intent was to help wikiprojects figure out which articles needed the most collaboration (we would focus on high “importance”, low “quality” assessments first).
However, as more and more wikiprojects became moribund, the ratings system became increasingly irrelevant. They are now little more than an ego boost (it’s nice to think that you improved an article to a “higher” level). Blueboar (talk) 15:00, 11 August 2024 (UTC)[reply]
I don’t care enough either way but if I could; I would simplify assessments to Stubs, Start, GA, FA. I have never ever used B, C, A classes. If an article can be improved, then do it! These debates about their classes could be better spent on improving the content however much or little. ~ 🦝 Shushugah (he/him • talk) 15:40, 11 August 2024 (UTC)[reply]
Folly, thanks for the link. I note that the 2021 discussion focused on GA and FA… while this discussion seems focused on the lower assessments (Mostly “c” and “b” class). Blueboar (talk) 16:25, 11 August 2024 (UTC)[reply]
Only big and active WikiProjects like MILHIST use class A. IMO it's good that B-class exists as it has actual, tighter criteria, and the banners always give tick marks for which specific criteria need improvement. I do agree that there need not be a centralized, stringent discussion forum for these ratings. They are not supposed to be formal, and I agree with Blueboar. The assessments are working as they should. Aaron Liu (talk) 17:20, 11 August 2024 (UTC)[reply]
I agree that assessments in their current form are not working as they should. Rating an article as GA or FA gets that article more recognition as they get a topicon, and can be featured in DYK or today's featured article.
Rating an article as A-Class, B, C, Start, or Stub does... nothing. Originally they alerted WikiProjects as to how much an article needs improving but since WikiProjects are no longer giving out ratings this seems irrelevant. Which leads to the obvious question – what is the point of content assessment? But that discussion is most likely out of the scope of this idea lab.
The ratings provide the exact same information regarding article quality to Wikiprojects as they did before. The change to a single rating did not affect their Wikiproject functionality, all the categories etc. still work. CMD (talk) 16:44, 11 August 2024 (UTC)[reply]
The big question is – does content assessment, through wikiprojects or otherwise, help improve Wikipedia? Because from personal experience, lots of wikiprojects seem to not actually undertake coordinated efforts to improve articles, much less using content assessment to do so.
It certainly helps at the upper end (GA and FA)… I don’t think the lower end (from Start through B class) is of much use. However, it doesn’t harm anything to have these levels… so… meh. Blueboar (talk) 17:17, 11 August 2024 (UTC)[reply]
Right, it's not a big question as we know the answer already. They're there if someone wants to use them; if they don't want to use them, no harm done. CMD (talk) 17:19, 11 August 2024 (UTC)[reply]
We have a single long-standing set of criteria defining each assessment rank that has been pretty consistent over time. Editors apply these based on their best interpretation, up to and more or less also including GA. CMD (talk) 17:49, 11 August 2024 (UTC)[reply]
For the people who don't know about our content assessment processes:
The most important level is B class This is implicitly the minimum requirement for DYK and ITN.
GA is B class with a review It is, like Start, C and B, a low level. Since the review is conducted by only one editor, YMMV.
Our highest level is A class This involves reviews by multiple editors from a project.
FA is similar to A class, but reviewers are drawn from all projects. However, unlike all the other levels, there are limits on the articles that can be submitted.
DYK requires Start-class (because their minimum length exceeds a stub).
@Folly Mox (and others), these ratings are primarily for the WP:1.0 team, which uses them for offline/curated releases. The difference between Stub and GA is important to their algorithm. They consider factors like popularity, centrality (=incoming links), and WikiProject ratings (i.e., to identify articles that humans say are important but that otherwise might be skipped). All else being equal, an article with higher ratings in terms of either quality or importance/priority is more likely to make the cutoff. Most of that group's work is coordinated off wiki these days, but AIUI they are still active.
Most of the time, anything well-cited is gonna be B-class, though it could be C-class or start-class if it's short. While ITN doesn't have this criterion, DYK's length criterion means it's usually B-class. Aaron Liu (talk) 01:18, 13 August 2024 (UTC)[reply]
Redirects to Film categories
For context, I am primarily an editor in the Simple Wikipedia, although I occasionally edit here. Many Wikipedia readers and editors switch to Simple Wikipedia by changing the domain from "en" to "simple", and back. This works well until you get into categories involving films. In simple wikipedia, "films" are referred to as "movies". In English Wikipedia, the only redirect that redirects you from "movies" to "films" is Category:Movies. I wonder if it would be possible or even a good idea to create every related Film category and create a Movie redirect page for it. For example, Category:1942 movies would redirect to Category:1942 films. This would also go for any templates, articles, etc., that would be related. I think this would be a good idea since this is an often enough redirect target, and the words are basically synonyms. I would also wonder if there is a way to automate this. Thank you. MrMeAndMrMeTalk04:14, 11 August 2024 (UTC)[reply]
From anecdotal experience, most people do not know how to edit the URL bar. To go to a site like YouTube.com, they'd Google YouTube even though there's a YouTube suggestion that pops up before they hit enter. I doubt that changing the domain is the primary way of switching against Simple Wikipedia.I'd recommend using the language switcher (文A at the top of the screen) to switch between these wikis; after a while of switching with it, the switcher will pick up that you primarily switch between these wikis and put the targets under "suggested languages". Aaron Liu (talk) 13:50, 11 August 2024 (UTC)[reply]
While this may be true in some aspects, that is a very broad and unreasonable assumption of many It is still a very common and reasonable way to switch between wikis. In any case, “movie” is a reasonable redirect for anybody to search up. MrMeAndMrMeTalk14:53, 11 August 2024 (UTC)[reply]
Naming convention for Uzbek names
Although thirty years have passed since the government of Uzbekistan decided to switch to the Latin script, the use of Cyrillic remains widespread, and the Latin script in use is widely considered inadequate to say the least. There's growing pressure to change it, particularly the letters Oʻ/oʻ and Gʻ/gʻ which are particularly problematic. However, so far no political will has materialized.
On Wikipedia, Uzbek names present many challenges, which I discuss in some detail below. Maybe this discussion will lead to a naming convention, which would be quite helpful. I can't start drafting one yet, as I don't have all the answers. Maybe after discussing the issue here, a task force could be put together to start drafting a proposal.
Distinct characters
Google's Uzbek keyboard uses U+02BB ʻ / U+02BC ʼ
The letters Oʻ/oʻ and Gʻ/gʻ (and the tutuq belgisi ʼ denoting a glottal stop or a long vowel) are a nightmare (See Uzbek alphabet#Distinct_characters). Basically, while it's clear that the straight English apostrophe should not be used, there is no official guidance on whether U+02BBʻMODIFIER LETTER TURNED COMMA / U+02BCʼMODIFIER LETTER APOSTROPHE or U+2018‘LEFT SINGLE QUOTATION MARK / U+2019’RIGHT SINGLE QUOTATION MARK should be used to properly render these two letters and the tutuq belgisi.Unicode.org states the former should be used. The Uzbek Wikipedia also favors U+02BB/U+02BC, and Google's Uzbek keyboard uses these characters.
However, Uzbek sources often use both—sometimes within the same text—and some do not distinguish between the modifier letter turned comma and the modifier letter apostrophe, instead opting for the straight English apostrophe, which is incorrect. Here's an example of an unfortunate Uzbek name that contains both problematic characters:
The question is: should we, like on the Uzbek Wikipedia, formally agree on which pair of characters to use in Uzbek words? I've been using U+02BB ʻ / U+02BC ʼ, but other editors might be using, or may have already used, U+2018 ‘ / U+2019 ’ instead.
On a related note, when a new page is created here on enwiki, the U+02BB/U+02BC pair poses no challenges. However, if the article is misspelled, as in the case of Yodgor Sa'diyev, moving it becomes impossible. "Yodgor Sa'diyev" is clearly wrong: reliable Uzbek sources use both U+02BC (Kknew, Zamin; Ministry of Internal Affairs) and U+2019 (Daryo, RFE/RL's Uzbek Service, Xabar), but not the English apostrophe. The handful of English sources that I could find on Yodgor Saʼdiyev use the Romanization of his name in Russian (Yodgor Sagdiev: Uz Daily) or a mix of his Uzbek + Romanized Russian name (Yodgor Sagdiyev: President.uz)! Since there is no single variant used in English sources, I decided to move the article to the Uzbek Latin spelling. (Although, as mentioned above, there isn't one standard Uzbek spelling, but this still seemed the best option.). However, when I tried to move the page to Yodgor Sa’diyev (with U+02BC), the following error popped up:
The page "Yodgor Sa'diyev" cannot be moved to "Yodgor Saʼdiyev" because the title "Yodgor Saʼdiyev" matches an entry (?!(User|Wikipedia)( talk)?:|Talk:)\P{L}*\p{Latin}.*[^\p{Latin}\P{L}ʻ].* <moveonly> # Latin + non-Latin on the local or global blacklists. If you believe that this move is valid, please consider requesting the move first.
When I tried to move it to Yodgor Sa’diyev (with U+2019), I got the following error:
The page title that you have attempted to create contains a right single quotation mark (’) Unicode character. Per MOS:STRAIGHT, such characters should not normally be used in page titles. Please replace it with a standard apostrophe, or a modifier letter turned comma (ʻ) or modifier letter apostrophe (ʼ) character if appropriate, and try again. If you got here by clicking on a red link in an article, you should go back and fix the link first.
Talk about a Catch-22! When there are no English sources and it's appropriate to use the Uzbek spelling, what should I do if I cannot move a misspelled page name due to the technical issues mentioned above? Should I request a name change every time I encounter an Uzbek word wrongly spelled with the English apostrophe, or can we make an exception for Uzbek names to facilitate moving articles?
As a page mover, I should be able to move over the title blacklist, so asking at WP:RM/TR could be an option. However, I notice the page has already been moved in the past, so maybe it is best to discuss it first. On that note, if you end up having a lot of them to request and consensus is that they should indeed be moved to the modifier letters turned commas/apostrophe, asking for the page mover right yourself could also be an option. Chaotic Enby (talk · contribs) 20:00, 11 August 2024 (UTC)[reply]
Romanization through Russian
Since Soviet times, Uzbek names have tended to be crudely transliterated into Russian, especially in official documents such as passports. As you can see in the table above, Йўлдош Аъзамов (Yoʻldosh Aʼzamov in the modern Latin script) was written as Юлдаш Агзамов in Russian, and English sources relying on Russian transliterate it as Yuldash Agzamov (see the table above for sources).
Per WP:COMMONNAME, we should generally use the most commonly used English spelling ("as determined by its prevalence in a significant majority of independent, reliable, English-language sources"). Are sources in broken English, like the ones mentioned above, sufficient for this purpose? While the current policy states "When there is no single, obvious name that is demonstrably the most frequently used for the topic by these sources, editors should reach a consensus as to which title is best by considering these criteria directly", it would be helpful to have a general policy for such cases, as most Uzbeks have multiple names, and the Romanization of Uzbek names through Russian is unlikely to stop any time soon.
Listing all the different spelling variants
When a given entity has many different names, it's helpful to list them in the relevant entry. Over the years, I've variously formulated the existence of different spellings while creating content here on enwiki. For instance, in Yoʻldosh Aʼzamov, I wrote:
Yoʻldosh Aʼzamov (sometimes spelled Yuldash Agzamov in English) (Uzbek: Yoʻldosh Aʼzamov, Йўлдош Аъзамов; Russian: Юлдаш Агзамов; May 10, 1909 – June 16, 1985) was...
In the recent entry on Olim Xoʻjayev, I added the following footnote:
Uzbek Cyrillic: Олим Хўжаев; Russian: Алим Ходжаев, romanized Alim Khodzhaev.
There are also Uzbeks like Hamza Hakimzade Niyazi who almost exclusively wrote their name in the Arabic script, and there are many reliable sources that use his name in the Arabic script. This complicates things even further. Is it best to specify all the various spellings in the lead section, or is it better to list them in a footnote? Either way, how should I word it so that it doesn't get too clunky but at the same time lets the reader know that multiple spelling variants exist? It would be really helpful to have some sort of rule of thumb for such cases.
P.S. I create redirects from all the known spellings to the main entry whenever I can. While I haven't encountered any issues on this, a future naming convention should probably have some guidance on redirects as well. Nataevtalk19:18, 11 August 2024 (UTC)[reply]
Central hub for WikiProjects
I think there should be a central hub for WikiProjects which would provide a space for editors to collaborate on all topics (yes vanilla wikipedia is a collaborative project but note that some editors are more open to collaboration whilst others prefer to work independently, this taps into the former). At the moment WPs are isolated from one another, and collaboration is often limited to within a single WP, when most articles have multiple WP banners and scopes overlap. This central hub could be called something like WP:WikiProject Hub and incorporate the directory (unsure whether WP:WikiProject Council would be best kept technically separate). It could have a resource that people could submit articles to that they would like to collaborate on (eg. most recent at the top, off the list after 2 weeks) and users could filter out/in WikiProjects technically based on the WP banners. I'm sure there's lots of other resources and uses it could provide that I can't think of right now Kowal2701 (talk) 20:08, 12 August 2024 (UTC)[reply]
I would suggest you could call it "WikiProject Cafe." that's a word which easily lends itself to this use, and yet has not been used for actual items here, so far. Sm8900 (talk) 20:19, 12 August 2024 (UTC)[reply]
It'd be like an actual WikiProject, and other WikiProjects would sort of be sub projects of it. I don't know whether WP:WikiProject Council would be best kept separate as a sort of regulator and help hub while this would strictly be for collaboration on articles etc. Kowal2701 (talk) 20:25, 12 August 2024 (UTC)[reply]
oh. well ok, but sorry that sounds overly broad. i don't really see a role for that. sorry.if you want to see why an overly generalized wikiproject might not work, please look at WikiProject History. let me know what you think, if you want. Sm8900 (talk) 20:27, 12 August 2024 (UTC)[reply]
all WP:HIST needs is taskforces for different regions and periods. I really think the lack of collaboration between projects hurts wikipedia and there's a lot of potential here Kowal2701 (talk) 20:31, 12 August 2024 (UTC)[reply]
I'd be happy to, although not sure about the best approach and I'm wary of wasting people's time. Do we immediately ping people to a discussion about taskforces with minimal initial comment or do we make a fleshed out proposal and then ping everyone? Kowal2701 (talk) 20:36, 12 August 2024 (UTC)[reply]
in general, it's neither. you simply create the task force with like-minded editors, in areas that you yourself would be interested in editing. that's not an official rule or method, in any way; it is simply my own personal opinion. Sm8900 (talk) 21:07, 12 August 2024 (UTC)[reply]
there're already taskforces for each continent, is it not just about reviving those and maybe merging WP:WikiProject European history into a taskforce? If people support it, we should probably discuss it with the people at WP Council, they've expressed similar ideas Kowal2701 (talk) 21:12, 12 August 2024 (UTC)[reply]
It's got over 300 members, if it were to be reorganised all could be pinged to a post which lists the taskforces, and hopefully enough would engage with them to keep them all sustainable Kowal2701 (talk) 21:30, 12 August 2024 (UTC)[reply]
@Kowal2701, sorry but there is no practical benefit to doing so. editors generaly edit whatever topics inteest them at the moment. there is little to be gained by organizing a whole lot of task forces which no one is already showing an interest in, actually. Sm8900 (talk) 21:32, 12 August 2024 (UTC)[reply]
I disagree, editors often have narrower interests than just history, which makes WP:HIST too broad like you said. If there was a push to organise the project around taskforces I think enough people might be inclined to engage with them especially considering only a small proportion of the large membership would be needed. I think it's worth a go rather than leaving it semi-active/inactive Kowal2701 (talk) 21:42, 12 August 2024 (UTC)[reply]
I’d assume 150, but with the taskforces that don’t get off the ground we could just message contributors. Idk, it entirely depends on whether there’s appetite for it Kowal2701 (talk) 06:42, 13 August 2024 (UTC)[reply]
@Kowal2701, can you describe your idea in concrete terms, with examples?
I can't tell if this is "I want one group of editors to be in charge of all the other groups of editors" (a WP:WikiProject is a group of editors) or if this is "I want a multidisciplinary group of editors". WhatamIdoing (talk) 21:24, 12 August 2024 (UTC)[reply]
No this is nothing to do with authority or even a group of editors necessarily. It's a restructuring of the wikiproject system. Think of a tree diagram where you have
To serve as a central place for collaboration on Wikipedia. Where people can collaborate on topics without a WikiProject. A place where WikiProjects can collaborate with one another. To macro manage WP’s coverage. Where WikiProjects can notify people of initiatives etc. To foster collaboration and make a healthier culture. I’m sure there are other uses. I think the resource mentioned in the initial post might be a good core idea. Kowal2701 (talk) 06:36, 13 August 2024 (UTC)[reply]
There are basically no topics that don't fall within the scope of an existing WikiProject.
If "macro manage" means "tell people that we need more articles about X or fewer about Y", then it's doomed because we're WP:VOLUNTEERS, but the Village pumps serve that purpose. The Village pumps are also where groups can notify others of their initiatives; WP:VPM is usually the most popular for routine announcements.
Creating yet another forum for communication is not usually helpful. See https://xkcd.com/1810/ ("Chat systems") and think about the problem of walled gardens (a handful of pages/people end up isolated from everyone else, leading to drift) and local consensus (e.g., we declare our group to be the One True™ group for deciding whether Our™ articles get an infobox, and we make sure that nobody else gets notified about or invited to participate in these conversations, because Those Other Editors might disagree with us). WhatamIdoing (talk) 06:57, 13 August 2024 (UTC)[reply]
That makes sense, I think there’s some merit to it but there’s too many ways it could fail and it’d take a lot of community resources and time which might not be worthwhile. Tbh with you I just really like the resource mentioned in the initial post, if that could be incorporated into an existing page I’d be satisfied. People really like serendipity and this could provide that, and bypass the isolation of WPs. It is also entirely voluntary, people can submit articles they’re working on that they’d like more input in and others can choose anything that intrigues them. It sort of serves to direct people I guess Kowal2701 (talk) 07:09, 13 August 2024 (UTC)[reply]
That’s really great. Maybe another list/page with a list could be added which didn’t have nominations so anyone can add an article regardless of importance or page views and it stays on the list for a month and people can filter by WP banners? Kowal2701 (talk) 07:36, 13 August 2024 (UTC)[reply]
WikiProjects are groups of people, and you probably don't want to filter by "WhatamIdoing and her wiki-friends". If you'd like to be able to filter by topic area, then the WMF did some research a few years back, and found that articles could almost always be classified into a couple dozen categories under four main headings of Culture (includes biographies), Geography, History/Society, and STEM. See mw:ORES/Articletopic#Taxonomy for the full list.
It’s more you filter by topic area, so you if you’re interested in say 5 topics, you just filter for them, it’s not necessarily about collaborating with those WikiProjects but with people on the articles for improvement page. Those groups are good, but I imagine it’d be a lot easier technically to use WP banners as identifiers for which topics the article is a part of Kowal2701 (talk) 15:28, 13 August 2024 (UTC)[reply]
One of our most important tools, Earwig's Copyvio Detector, depends on access to Google. According to the tool's creator and operator, The Earwig, the WMF has kindly been paying for this Google access. Unfortunately, we've been hampered by a strict limit on the number of searches allowed per day. The Earwig mentioned that there might be a way to work out a special arrangement with Google to increase the cap. Would someone at the WMF be able to pursue this?
In case it helps, this is a vital tool to a number of English Wikipedia processes, and it would surprise me to learn that the sister projects aren't using it as well. We use the tool routinely as part of our new page patrol, articles for creation, contributor copyright investigations, did you know, good article, and featured article processes. Historically, the WMF has taken a special interest in supporting volunteer work that focuses on our legal responsibilities, of which compliance with copyright law is an obvious example. Firefangledfeathers (talk / contribs) 01:34, 31 July 2024 (UTC)[reply]
My understanding is that Google has a hard daily limit of 10,000 API accesses per day for absolutely everyone across the board, without exception. User:Novem Linguae/Essays/Copyvio detectors#Earwig copyvio detector. My impression is that an exception wasn't possible because Google doesn't provide an exception to anyone. Earwig would know best though.
Earwig didn't ask me to do anything on his behalf. He mentioned that "the WMF pays for it, but Google's API terms limit our usage without some kind of special arrangement that I have been unable to get." This was at a discussion at his user talk. I wasn't sure who might be able to negotiate a special arrangement, and I'm not sure it's a possibility, but this was the best place I could think to ask. Firefangledfeathers (talk / contribs) 04:26, 31 July 2024 (UTC)[reply]
A bit odd that Earwig isn't doing the advocating himself, but on the linked user talk page, it does sound like he's asking for some help with this. Would The Earwig be willing to share his contacts at WMF that have helped with this in the past? Sounds like WMF pays for the tool, so there's some accounting/finance/grants contact that knows a little about it. And we also have partnerships people like NPerry (WMF) that I believe has worked with Google before. –Novem Linguae (talk) 04:43, 31 July 2024 (UTC)[reply]
From what I've heard, the WMF contact that Earwig had has since left the Foundation and wouldn't be able to help in this case. You are correct that WMF pays for the tool. I had mentioned this at the Hackathon with staff and it seems there's some resistance in getting the cost of extra tokens funded, although I'm unsure of exactly how the WMF's budgeting process works, so no clue on the impact it has in this situation (considering we don't have a Google liaison to begin with). Chlod (say hi!) 05:20, 31 July 2024 (UTC)[reply]
Even the name of a former WMF employee contact would be helpful. Let's get all this documented so we can start figuring out what WMF departments/teams have assisted in the past. –Novem Linguae (talk) 05:26, 31 July 2024 (UTC)[reply]
Hi all. Firefangledfeathers, thanks for starting the discussion. Novem, sorry if this thread came up a bit strangely. In truth, I struggle a little with motivation these days, so I really appreciate others' help getting the ball rolling. I am still here, though—it comes in waves. (It's also good to involve the community in the tool so the institutional knowledge isn't stuck with me.)
BTW, I am working on more effectively managing automated/excessive tool usage and will soon require OAuth to run searches (see this active thread on my talk). Right now the tool really doesn't have any usage guards or a way to limit individual users' activity, which isn't good when our resources are so limited. It's possible doing that will free up our resources a lot if a substantial fraction of our current usage is coming from malicious crawlers, despite Chlod and I's attempts at blocking them (the tool has been running for over a decade and it's never been this bad, though I have a theory what this is about). Even so, finding a way to increase our search quota will enable us to support some requested features that are current nonstarters, even if the tool's entire current quota could be devoted to it, like checking all new pages.
My main point of contact with the WMF in the past was Kaldari. The last time we spoke about the tool was 2020; since then, the situation has been unclear. (MusikAnimal, do you remember if we've spoken about this?) Last year Runab WMF and DTankersley (WMF) reached out to me to discuss the tool in the context of WMF efforts "to find ways to reduce single points of failure for tools that require a third party API", but after an initial conversation I haven't heard back aside from being told that Deb was moved to another project, so I'm not sure what happened with those efforts.
Frequently we've discussed adding an alternate search backend aside from Google. While Google is really the gold standard for breadth of search coverage, as far as I'm aware—and this is really what the copyvio detector needs, not necessarily quality/intelligence; people have suggested services like DuckDuckGo, but they're really unsuitable because they just republish raw results from Bing with some additional flair that is basically useless for us—something like Bing itself might work as an (automatic) fallback if we exhaust our Google credits for the day. I believe Bing has roughly equivalent pricing/usage limits as Google, but it's been a while since I've looked into it. And we/the WMF would need to establish a relationship with Bing for that to work; I don't know if that's a better idea than attempting to negotiate our Google limits. There are also other options like Yandex (which the tool did use one dark time in the past before the Google relationship and after Yahoo ended their free service... it wasn't great, at least for English results, but it's something that could be looked into for some other language projects, perhaps). Finally, there was a discussion on my talk earlier this year with Samwalton9 (WMF) about adding The Wikipedia Library as another search backend, and I did correspond briefly with someone at EBSCO about this, but again, I haven't heard from either of them about this in several months. — The Earwig (talk) 06:51, 31 July 2024 (UTC)[reply]
So the Google API proxy and the Google account it runs on are wholly part of Community Tech's budget. Kaldari was the contact in the past when they were my manager on CommTech. So the good news is Community Tech is still here, and we are actively maintaining this proxy (I just migrated it to a newer Debian a few days ago). The part that hasn't changed is our quota from Google, and sadly I doubt it will change. We are already paying hefty fines for the quota we have now, but I believe it is also correct that 10K is a strict limit from Google. I can see from the graphs in the API console that we almost always hit that limit within the first 12 hours of each day.
I am working on more effectively managing automated/excessive tool usage and will soon require OAuth to run searches … – that is most certainly the best immediate recourse for addressing this problem. From my years of shielding XTools from web crawlers, I can say with confidence that putting up a login wall by itself should make a big difference. I also think mitigating excessive and automated use is something that would probably be required before we could consider dishing out more money to Google. However again, I don't think such negotiations would get us anywhere anyway :(
As a general note, such "negotiations" are typically done these days via the Partnerships team. I went though them recently when we solidified our partnership with Turnitin. Speaking of which… do others find the "Use Turnitin" option of Copyvios at all useful? Because that's using the old Turnitin account (the new one can't be used outside CopyPatrol), and the last I checked there were still a few million credits left. — MusikAnimaltalk20:52, 1 August 2024 (UTC)[reply]
The Google API Proxy (docs at wikitech:Nova Resource:Google-api-proxy) exists solely to anonymize requests to the Google APIs, should they be used in a fashion that sends personal data such as your IP or user agent. As far as I know, Copyvios has always accessed Google APIs through this proxy.
I'm not aware of any sort of sliding scale as far as pricing goes, and my use of the word "hefty" was relative to my team. However since I made my reply above, I have been informed that the budget is actually not solely from Community Tech, as it was in the past (but we do still maintain the proxy). I don't have any details about internal accounting, I'm afraid. My apologies for any confusion caused. — MusikAnimaltalk19:48, 2 August 2024 (UTC)[reply]
Wouldn't the Toolforge tool itself serve as an anonymizing proxy as long as the Google API requests are being sent via a backend rather than via browser JavaScript? But that's a bit of a tangent :) –Novem Linguae (talk) 22:18, 2 August 2024 (UTC)[reply]
I'm willing to entertain alternate methods for anonymous users to access the tool. I do need some way to attribute usage to a human, though. Any suggestions? I might present a challenge page where you have to answer some question (essentially a CAPTCHA, but one that works without JS). Or I can require anonymous users request a token (that would be saved as a cookie so does not need to be entered with each request). — The Earwig (talk) 00:00, 10 August 2024 (UTC)[reply]
That's a good question, but I can't tell from the documentation whether temporary accounts are able to use OAuth. I would need to test it. (And we may need some other solution in the meantime, before that's deployed.) — The Earwig (talk) 14:25, 10 August 2024 (UTC)[reply]
I know nothing about what the "modern" methods are of telling bots and humans apart these days (besides knowing that CAPTCHAs are apparently broken: e.g. Table 3 in [13]), so I probably won't be able to provide many helpful suggestions. If we need to request a token from you, I for one would be okay with that if it's a one-time process, but would that be handled by an automatic system or by asking you for one manually—and if the latter, is there any indication how many anonymous editors (legitimately) use the tool so you won't be potentially flooded with hundreds of requests?
Another idea I had is making sure the requesting IP address' /64 range (if IPv6, or the address alone if IPv4) has made at least one edit to the Wikimedia site the Earwig request is for. I could easily be assuming wrong, but I would think there wouldn't be many cases where an anonymous user would want to check for copyright violations on a site they've never even edited before. This would admittedly require anonymous users to be on the same device they edit from to use the tool, but so would requiring a browser token. ...however, I don't know how technically feasible that is, and obviously someone malicious could just manually change their IP address (but would someone running hundreds of web crawlers go to that effort for every single one of them?). 2603:8001:4542:28FB:9566:5D77:1AC4:CB78 (talk) 18:47, 12 August 2024 (UTC) (Actual talk)[reply]
@The Earwig: OAuth is not available for temporary accounts. The T&S Product Team aims to make the experience with temporary accounts very similar to what IPs have now, which includes not having access to OAuth or user groups. @2603:*: For IPs, we don't have access to IP addresses on Toolforge, so we can't check on wikis if a specific Toolforge visitor's IP has made an edit on the wikis. Requesting a special token, as you've mentioned, is probably a better option to go for if we want to have anonymous editors keep their access. Since there aren't that many editors who do all of their edits on an IP, we shouldn't get too many requests for this. What should be decided is the minimum requirements for giving this access, and the criteria for revoking it (should we find out that an editor has been using a token maliciously). Chlod (say hi!) 05:44, 13 August 2024 (UTC)[reply]
Given IP addresses (and thus contributions) can't be measured by Toolforge, what prerequisites could even be measured? Or would the token-giving occur on a different site?
In terms of revoking, my knee-jerk thought is more than M requests in a minute or N requests in a day could cause the token to get revoked until the anonymous user interacts with a human to request it back. But A. I don't know if that's how things work with tokens and Toolforge, and B. I'd be curious to know what the already-established practice and limits for e.g. the Wikipedia API and whatnot are, to have some sort of a benchmark. 2603:8001:4542:28FB:C10F:60AC:578A:3F8 (talk) 22:48, 13 August 2024 (UTC) (Actual talk)[reply]
more than M requests in a minute ... could cause the token to get revoked You need to be careful with that. When I'm checking DYK queues, I check a whole set at a time, which means opening nine (or more) Earwig windows in a few seconds. RoySmith(talk)23:25, 13 August 2024 (UTC)[reply]
Feature updates from the Tech News: Stewards can now globally block accounts; Wikimedia site users can now submit account vanishing requests via GlobalVanishRequest; and interface of FlaggedRevs (also known as “Pending Changes”) is improved.
This month’s Wikimedia Research Showcase highlighted the impact machine translation has on both content and readers of Wikipedia and provided interesting insights on how to overcome related challenges. Watch the recording.
The Charts project officially kicked off. The goal of this new initiative is to restore basic data visualization capabilities to the wikis. Check out the project page and follow our progress on Phabricator.
The CampaignEvents extension is now available on Meta-wiki, Arabic Wikipedia, Igbo Wikipedia, and Swahili Wikipedia, and can be requested on other wikis. This extension helps manage and make events more visible. Learn about how to request this extension.
The Campaigns Product & Programs teams have launched a consultation on WikiProjects and other forms of collaboration on the wikis. They want to understand why they work (or don’t work) for some Wikimedia communities, and they want to learn what can be done to improve the experience. Everyone is encouraged to share their feedback.
The Board of Trustees selection pre-onboarding and campaign period is open from July 25 to August 26.
Foundation Trustee Dariusz Jemelniak was appointed to the Governing Board of the European Institute of Innovation and Technology, established as part of the EU’s key funding program for research and innovation.
I am an occasional user of SWViewer, a vandalism patrolling tool that is (in my understanding) partly maintained by the Wikimedia Foundation. I generall like its interface and design, and I have found it to be a useful tool.
I do have one item that I would like to discuss though: I think it would be wise to add a checkbox for whether or not to mark an edit as minor. Currently, the interface allows users to tick a box for "Use undo" when rolling back an edit with a summary. This is good, but it only allows users to revert edits in a way that is marked as minor. I understand that certain wikis, such as the English Wikipedia, have a very narrow understanding of what constitutes a minor edit, and there are times when I want to undo an edit but it is not technically a minor edit. This makes me have to manually go to the English Wikipedia and click the "undo" button there rather than keeping all of this in the SWViewer interface.
Is there a way that the WMF could either:
Not automatically mark edits made while "Use undo" is ticked as minor (i.e. submit them to non-minor edits); or
Allow users to select whether or not their actions are considered to be minor edits (via a tick box)?
Hi, I'm not WMF staff (although I am the Wikimedian of the Year) but I noticed something I thought should have wider community input. Please keep in mind that as far as I'm aware this is in very early stages and there is no guarantee that it will actually be implemented. Also, please be nice. I anticipate that some people will be surprised by what it was being proposed here so I felt like this was an important reminder. Anyways: mw:Wikimedia Apps/Team/iOS/Fundraising Experiment in the iOS App. There is a feedback section towards the end of you wish to give it. I have already commented there. Clovermoss🍀(talk)17:47, 10 August 2024 (UTC)[reply]
This is an example of what is being proposed. Essentially, there would be a donation button near the top right of an article and these would kind of be like Reddit trophies. I think this needs way more visibility than being buried in the depths of mediawiki which is why I'm posting here. Clovermoss🍀(talk)18:52, 10 August 2024 (UTC)[reply]
Wikimedia Foundation banner fundraising campaign in India postponed to start on the 27th of August
Dear all,
As mentioned previously, the WMF is running its annual banner fundraising campaign for non logged in users in India. Initially, we planned the campaign to start tomorrow and run until the 10th of September. We have had some issues with our local payment provider in India and due to this we are postponing the campaign by a couple of weeks. Our new campaign dates are the 27th of August to the 24th of September.
You can find more information around the campaign, see example banners, and leave any questions or suggestions you might have, on the community collaboration page.
Generally, before and during the campaign, you can contact us:
I would also say it should be reverted to maintain the original intent, but there will also be sources to support the current version of the article, as the new version is literally for another town. The telugu page (te:పోరండ్ల (జగిత్యాల)) has always been about the current (Jagtial) Porandla, as has the associated Wikidata item (wikidata:Q13003257). The original (Ranga Reddy) Porandla is at te:పోరండ్ల (మహేశ్వరం)/wikidata:Q16340753.If the original wording is restored, the thing to do here would be to revert, split off Jagtial Porandla, disambiguate Ranga Reddy Porandla, and then switch the relevant Wikidata entries.(As an aside, the one-up division, te:జగిత్యాల గ్రామీణ మండలం is one of the few Jagtial district#Mandals without an en.wiki article.) CMD (talk) 04:15, 26 July 2024 (UTC)[reply]
How do you determine the "size" of a list (or merging / splitting purposes)?
Ok, this may be a silly and redundant question. So, WP:SIZERULE gives good guidelines for when articles should be trimmed or merged. However, WP:SIZE states that readable prose size only includes "the amount of viewable text in the main sections of the article, not including tables, lists, or footer sections." For the purpose of merging lists, and with the removal of the kb limits (which I had previously used to judge list size) on WP:SIZEhow do you determine the size of a list (as related to existing guidelines stated on WP:SIZERULE) if you wish to merge or split a page? Historyday01 (talk) 13:17, 5 August 2024 (UTC)[reply]
The kb limits on WP:SIZE also applied only to readable prose, nothing has changed in that respect. List splits likely come down to editorial judgement, what best helps a reader. Some lists do still end up breaking other limits like WP:PEIS, but that's not common. CMD (talk) 01:25, 6 August 2024 (UTC)[reply]
Low standards for references on the English Wikipedia
Why does the English Wikipedia allow the creation of articles without reliable sources? For example, if you look at the references for "El amor de mi bohío," you will find databases, blogs and other wikis. The same with Mira que eres linda, the sources are blogspot and Brito EcuRed. That's why many editors whose articles are deleted on the Spanish Wikipedia come to create them here, because the requirements for reliable sources are minimal. I don't think this does any good for Wikipedia's reputation. KokuyoKoychi (talk) 22:25, 5 August 2024 (UTC)[reply]
@KokuyoKoychi, the requirements aren't minimal but enforcement is difficult. Hundreds (or more) articles are created every day. There aren't enough editors to screen each one (although the New Page Patrol makes a valiant effort at doing so). Schazjmd(talk)23:41, 5 August 2024 (UTC)[reply]
You are welcome to improve the sourcing. There are many potential sources for the former here and here and for the latter here and here. I would do it myself but my Spanish is rather rudimentary. The article creator does not own an article on English Wikipedia. Phil Bridger (talk) 20:34, 11 August 2024 (UTC)[reply]
Reminder! Vote closing soon to fill vacancies of the first U4C
The voting period for the Universal Code of Conduct Coordinating Committee (U4C) is closing soon. It is open through 10 August 2024. Read the information on the voting page on Meta-wiki to learn more about voting and voter eligibility. If you are eligible to vote and have not voted in this special election, it is important that you vote now.
Why should you vote? The U4C is a global group dedicated to providing an equitable and consistent implementation of the UCoC. Community input into the committee membership is critical to the success of the UCoC.
Please share this message with members of your community so they can participate as well.
Normally it is not possible to full-text search through the Wayback Machine. However, they do make available certain collections for full-text search, such as the US Government docs collection has 403 million pages. The list of collections currently available for searching:
This is a beta service. There is currently a bug in the interface sometimes it redirects to the home page. If this happens, go to a collection search that is working (such as the US govt docs link above) and use the pull-down menu to navigate the collections. You can also search via URL such as:
The technical village pump is a good place to discuss the implementation details of a design. However to discuss the design itself, this village pump page would be more suitable. isaacl (talk) 21:48, 9 August 2024 (UTC)[reply]
Ban in Azerbaijani Wikipedia
Hello, I would like to complain about the administrators of the Azerbaijani Wikipedia.
The fact is that when I added az:Yenisey (Yenisei) in parentheses to the article its name in the Yenisei language in addition to the Russian term (and of course wrote the source from the 1899 book), I was banned by the Nemoralis administrator. To the question “what Wikipedia rule did I break,” he answered in an arrogant manner, “your account will not be unblocked.” I wrote this message here because I don’t know where to write. I also wrote the message to the Azerbaijani section, but Azerbaijani administrators support each other since for several years in a row these are basically the same people.
Please help me in this situation. At least express your opinion, please.
To make it clearer, I write the difference between the articles:
Normally the standard reply is enwiki has no powers over azwiki (and azwiki over enwiki). But you could try to find an azwiki admin who is active on enwiki. You could ask them about it here, in a neutral ground, maybe also try to find a neutral person on enwiki not from azwiki, to help moderate the dispute. It seems extreme to ban someone over what you describe so either they are bad amins or there is more to the story. -- GreenC19:35, 9 August 2024 (UTC)[reply]
"bad admins" is surprisingly plausible. There are four azwiki admins indefinitely blocked here (Solavirum, Nemoralis, Wertuose, Atakhanli), including the admin who blocked Sebirkhan on azwiki. But Google Translate of the azwiki discussion linked to paints a different picture than an admin cabal supporting each other. * Pppery *it has begun...19:59, 9 August 2024 (UTC)[reply]
Indeed, this editor appears to have continuously ignored advice regarding using old sources for names in article leads and received a one-month block in response. I don't see any indication of foul play, and I say that as the admin who blocked 2/4 of the az.wiki admins listed above from en.wiki. signed, Rosguilltalk20:22, 9 August 2024 (UTC)[reply]
However, I do not understand why I cannot add the name of the Yenisei River in the Yenisei language in brackets, while the name of this river in other languages is added at the beginning (Maybe then we should delete all the names and leave only the official one - Russian). Where should I add this name if not in this Wikipedia article? I consider it important for preserving history. After all, I did not come up with this name. But the administrator deleted it and blocked my account and my IP Sebirkhan (talk) 20:35, 9 August 2024 (UTC)[reply]
As the admin of AzViki, I can say that the user presents the situation differently. The user constantly adds words in the old Azerbaijani language or the old Turkish language to the beginning of the articles, changes the names of the articles. We have repeatedly warned him to use only modern Azerbaijani words, not archaic words. As a result, he was blocked at the very end. And now he allegedly says that he added the word in Yenisei language to the beginning of the article, while he added the version in ancient Turkic language, which is unrelated to the topic. However, the Yenisei language has nothing to do with the ancient Turkic language. And the user does such things many times. The user even once wrote that the word "shogun" is a Turkish word in the Shogun article on AzWiki. Cosmic Bardutora!20:32, 9 August 2024 (UTC)[reply]
It is not true because, A regular azwiki user does not have the technical ability to change article titles. Also I do not use Turkish language in Azerbaijani section.
Everything you write is far-fetched, because I have never written in my life that shogun is a Turkish word or comes from a Turkish word. However, thanks to me, the administrators eventually changed the name of the page Syoqun to Şoqun (which is correct from the point of view of the Azerbaijani language and Japanese language, and also others) and this is a fact if you look at the history of the article. Sebirkhan (talk) 20:41, 9 August 2024 (UTC)[reply]
In the edit Cosmic Bard identifies, you added [[Qədim_türk_dili|Əski türkcə]]: 𐱁𐰭𐰆𐰣, /şöŋün/, which would indeed suggest that the origin of shogun is Old Turkic. signed, Rosguilltalk20:52, 9 August 2024 (UTC)[reply]
You are right, however (even though this is a word written in dictionaries), I thereby pointed out the inconsistency of using the Russian form Syoqun in the Azerbaijani language, in the end we came to a compromise Şoqun. I was not banned for this reason. The azwiki administrator is simply trying to direct the conversation in a different direction. While not banned for this, specifically I received a message about blocking after changing the Yenisei page and the administrator canceled my edits. Sebirkhan (talk) 20:58, 9 August 2024 (UTC)[reply]
You are not blocked just because of the Yenisei River article. Everyone can do something wrong. A user cannot be blocked for one edit. You are blocked because you keep doing things like this. Before that, you wrote the Dnepr River as "Ozü River" in a article, and I warned you about this, that this river is not called Özü River in any source in the modern Azerbaijani language. I will not comment further on this issue here, because it is not EnViki's issue, but AzViki's issue. Cosmic Bardutora!21:08, 9 August 2024 (UTC)[reply]
I have no idea who is right or wrong in this case, but I think you have been badly advised above. There is indeed nothing that can be done at the English Wikipedia about the Azerbaijani. The place to go if you are dissatisfied with the response you get at the Azerbaijani Wikipedia is Meta: . Phil Bridger (talk) 20:45, 11 August 2024 (UTC)[reply]
References
^В. В. Радлов, Опыт словаря тюркских наречий, том второй, Санкт-Петербург, 1899 (s. 1202)
Works for me Specific examples please. --Redrose64 🌹 (talk) 06:47, 5 August 2024 (UTC)
Done @Novem Linguae: I've promoted this from test to template-gadget; please validate and ping me if any issues. — xaosflux Talk 15:29, 9 August 2024 (UTC)
Polygnotus (talk) 00:30, 10 August 2024 (UTC)
Moved from Wikipedia talk:Village pump
Resolved
Agree Sm8900 (talk) 15:39, 9 August 2024 (UTC)
_en_el_Palacio_de_Nymphenburg,_M%C3%BAnich,_Alemania35.JPG)
wikimedia.org know if you have any feedback or suggestions for improvement!
![[5]](https://imgs.xkcd.com/comics/wisdom_of_the_ancients.png){kind=link}
