Wikipedia:Village pump (all)

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.

(to see recent changes on Village pump subpages)

Village pump sections

Policy

post, watch, search
Discuss existing and proposed policies

Technical

post, watch, search
Discuss technical issues about Wikipedia

Proposals

post, watch, search
Discuss new proposals that are not policy-related

Idea lab

post, watch, search
Incubate new ideas before formally proposing them

WMF

post, watch, search
Discuss issues involving the Wikimedia Foundation

Miscellaneous

post, watch, search
Post messages that do not fit into any other category

View all village pump sections at once

Other help and discussion locations

I want...	Then go to...
...help using or editing Wikipedia	Teahouse (for newer users) or Help desk (for experienced users)
...to find my way around Wikipedia	Department directory
...specific facts (e.g. Who was the first pope?)	Reference desk
...constructive criticism from others for a specific article	Peer review
...help resolving a specific article edit dispute	Requests for comment
...to comment on a specific article	Article's talk page
...to view and discuss other Wikimedia projects	Wikimedia Meta-Wiki
...to learn about citing Wikipedia in a bibliography	Citing Wikipedia
...to report sites that copy Wikipedia content	Mirrors and forks
...to ask questions or make comments	Questions

Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).

Policy

Unnecessary delay in publishing articles translated for $$ by an NGO

So, I just stumbled upon Wikipedia:WikiProject Intertranswiki/OKA. TL;DR, there is an NGO sponsoring translating high quality articles between Wikipedias. But on EN due to our COI/PAID policies they are required to use AfC, which means that their articles, which usually are very good, are delayed through AfC backlog, to which they also contribute. I think this is an excellent initative that however needlessly clutters AfC due to our current rules, and I'd like to suggest we consider giving it exception from the COI requirement to use AfC. It makes sense to direct paid-for spammers to AfC, as their articles are often problematic (notability, etc.) but what we have here is very different (translations of good quality articles from other wikis - ex. current drafts include Draft:Renaissance in Ferrara, Draft:Spa Conference (2-3 July 1918), Draft:Formal procedure law in Switzerland, etc.), yet this stuff is caught in the same "COI" net. (See project page linked above for links of articles already published, links to drafts waiting for review, and their instructions to translators) Thoughts? (Courstesy ping project founder @7804j). PS. A question to 7804j - how are articles chosen for translation? How is the system designed not to be abused by spammers? Perhaps if an exception is granted on en wiki, it should not apply to articles about companies, products or living persons? _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 02:27, 22 June 2024 (UTC)

I would dispute that "this is an excellent initative" or "that their articles, which usually are very good". They have caused a lot of work; mostly these are machine translations by people whose English is rather poor. The titles chosen are often completely ungrammatical (Greek Classicism Sculpture was a typical one) or inappropriate, & in the past they have chosen often subjects we already have. The texts are just whatever the language taken - usually Portuguese, Spanish, French or Italian, has on their wiki, & the quality of the original is often poor, & errors introduced by machine translation go uncorrrected. There have been numerous complaints. They have got slightly better, but I think still don't publish a full list of articles they have paid for, whicgh they should. The Open Knowledge Association isn't really "an NGO" - as far as I can see it's a single Swiss guy with a bit of money to spend, who you have rashly decided to endorse. Johnbod (talk) 02:51, 22 June 2024 (UTC)

I think that the principle is sound: high-quality articles can and should be translated into languages where they're missing. Doc James ran a similar program for certain medical articles a few years ago (e.g., during the Ebola and Zika outbreaks), to public acclaim. However, he was working with pre-screened professional translators, and OKA seems to have struggled with quality control. WhatamIdoing (talk) 04:19, 22 June 2024 (UTC)

Unfortunately the ODA model makes absolutely no attempt at quality control. As will be clear to anyone who reads one of them, they are just machine translations dumped onto en:wp with no aftercare. Many that were forks were just turned into redirects, which the ODA doesn't appear to have noticed. The ones that are left take a lot of cleaning up, when some regular editor can be bothered. Johnbod (talk) 01:52, 23 June 2024 (UTC)

I am afraid that your anecdotal analysis above is different from mine. The articles from OKA I've seen seem pretty decent, at start+ class, and would survive AfD if nominated. Can you recall which articles were redirected - and prove that they are a rule, and not an exception? _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 02:50, 23 June 2024 (UTC)

Whether they would survive Afd is almost all about the notability of the subject, and that is not usually an issue - the quality is. In fact the worst issues arise when they tackle very prominent subjects. I never claimed that redirected ones were the "rule" - I make no attempt to search out OKA efforts, but then clearly neither do you. Draft:Crow-stepped gable is a recent creation, objected to, for which we have a redirect already in place. Not much of it will survive, I'd imagine. If they kept proper lists of their articles on wiki I would be able to find some, I imagine. Johnbod (talk) 03:12, 24 June 2024 (UTC)

Johnbod List here; may not be everything. Mathglot (talk) 03:34, 24 June 2024 (UTC)

Thanks, but I don't think that is at all complete. The template was only set up in October 22 (by 7804j), well into OKA's project. Stuff may have been added later. You used to able to access an off-wiki spreadsheet 7804j maintained, but I can't see that you can now. User:7804j? For example, the earlier efforts of User:Racnela21, one of the most prolific OKA editors, are not templated - see the 48k bytes of Brazilian Romantic painting (typically, initially called Brazilian Romanticism Painting). Johnbod (talk) 13:08, 24 June 2024 (UTC)

This list contains all articles created by OKA after the template was created. Oka was created relatively shortly before the template was created, therefore there are not many articles without it (probably 90+% have the template). The off wiki tracker is still at oka.wiki/tracker 7804j (talk) 13:24, 24 June 2024 (UTC)

Also, I'd like to highlight that quality is not really the topic of this discussion, since this is about whether COI should require all paid editors to go through AfC and, as you pointed out yourself, AfC's goals are not primarily to check quality. I'd suggest moving the OKA discussions somewhere else such as our talkpage in the intertranswiki project 7804j (talk) 13:27, 24 June 2024 (UTC)

Piotr brings up "would survive AfD" because that's the standard AfC uses. If OKA articles typically have quality issues that wouldn't be enough for deletion, then there's no point insisting they go through AfC – assuming reviewers are doing their job properly, they'll just send them right through. – Joe (talk) 11:00, 24 June 2024 (UTC)

Things that would make them fail Afd include repeating articles we already have under a different title, a perennial problem with OKA, which reviewers don't always pick up, but sometimes do - as currently at Draft:Crow-stepped gable. Besides, some reviewers (perhaps not "doing their job properly" - how shocking) insist on minimal standards of coherent English, etc. Johnbod (talk) 14:31, 24 June 2024 (UTC)

Health translation efforts from English to other languages are still running. Wiki Project Med Translation Dashboard Our translators are mostly volunteers with a mix of Wikipedians and professional translators. Doc James (talk · contribs · email) 12:40, 23 June 2024 (UTC)

Hi Piotrus,

Thanks for initiating that discussion! I am fully supportive of such an exemption, as I see this AfC requirement as additional red tape that consumes a lot of time for OKA translators and AfC reviewers.

Our core principle is that our translators are free to work on anything that interests them. We provide them with a monthly stipend, some training on how Wikipedia works, but we then see them as volunteer contributors on whom we impose some process to ensure they do not abuse the grant and provide overall value (eg, quality checks, quantity checks). To help them find articles to translate, we curate an optional backlog (at oka.wiki/tracker). Articles of this tracker primarily consist of "Featured" and "Good" quality articles from other Wikis, as well as red links from these articles. We also complement this with articles that we find important, eg, about geographical features such as lakes, mountains, etc. The broader principles for articles prioritization are described at oka.wiki/overview

Note that there was a similar discussion in the Interwiki talkpage, which can provide useful additional context.

Regarding Johnbod's response, I would like to bring 3 points of context:

1) While overall quality is good, it may vary. Because we have many different translators, with difference levels of experience, the quality will not be uniform. We are providing them with training, and we have observed their quality improved over time. We stop providing grants to translators wjth recurring quality issues. Overall, I do not agree with Johnbod's characterizarion of a high degree of quality issues. Often, the issues raised with OKA's work were not due to the quality of the translation, but because of the source article itself. We have published several thousand of articles, most of which are still live with very minimal change vs their original published version.

2) This discussion is not about assessing the quality of the work, but whether the COI requirement to go through AfC should apply to OKA. The only reason why our translators go through AfC today is because of the COI policy, which was not created primarily to check quality of paid translations but to eliminate bias. Therefore, I don't think such arguments are appropriate in the current discussion.

3) Our funding comes from many different private individuals, but it is true that currently I am the main donor. That being said, this should not make any difference as to whether we can be called an "NGO". Would the Gates Foundation not be called an NGO just because most of its funding comes from Bill Gates? We have over 15 full time translators who agree to do this work with a very small stipend, much smaller than what they could earn in a regular job, so the work of OKA is much more than that of a single person 7804j (talk) 08:46, 22 June 2024 (UTC)

Personally, I don't care how high quality the articles end up being, if you have a financial tie to a subject you should go through AfC. Lee Vilenski ^{(talk • contribs)} 08:59, 22 June 2024 (UTC)

Getting paid to translate an article about Brazilian Romantic painting (popular in the late 1800s) is not exactly the same as having a financial tie to the subject. WhatamIdoing (talk) 04:32, 28 June 2024 (UTC)

I would prefer not to couch any action in terms of "an exception" for a named user or group. Rather, I would prefer to see an adjustment to WP:PAID to make a modification to allow "philanthropic paid editing" where the articles in question and the content added are chosen by the paid editors and there is no oversight by the payer. At that point, individual articles and editors would be subject to the same kind of oversight as any other. It seems to me that philanthropic paid editing to expand the encyclopedia is within the scope of WP:HERE, and this should not be formulated as an "exception" as if something were wrong with it in the general case. Mathglot (talk) 09:14, 22 June 2024 (UTC)

I agree with [[U|Lee Vilenski}} if you have a financial tie to a subject you should go through AfC, The given example Draft:Renaissance in Ferrara is very poorly translated. Theroadislong (talk) 09:19, 22 June 2024 (UTC)

Courtesy ping: Lee Vilenski. Mathglot (talk) 09:22, 22 June 2024 (UTC)

But that's the thing, OKA editors don't have a financial tie to the subject. They're paid by an organisation to edit Wikipedia, but the selection of topics is independent. It's basically paid editing without a COI, which is a bit of blind spot in our current policies. – Joe (talk) 09:30, 22 June 2024 (UTC)

Indeed. What "tie to the subject" is there in "Renaissance in Ferrara"? We might as well call COI and PAID for Wikipedia:School and university projects or most of WP:GLAM stuff, and various edit-a-thons, since there is $ involved in it as well. Do we require AfC from Wikipedians in Residences? _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 10:48, 22 June 2024 (UTC)

Actually I would be interested to understand what are the requirements for projects such as the ones you mentioned to *not* qualify as paid editing. As you pointed out, Wikipedians in Residence do not need to go through AfC -- what are the formal criteria/policy allowing them to be compensated without being considered paid editors? 7804j (talk) 20:17, 23 June 2024 (UTC)

As per foundation:Policy:Terms of Use/Frequently asked questions on paid contributions without disclosure#How does this provision affect teachers, professors, and employees of galleries, libraries, archives, and museums ("GLAM")?, Wikipedians-in-residence are still considered paid editors for contributions for which they are being paid. isaacl (talk) 22:30, 23 June 2024 (UTC)

@Isaacl:, yes, but as I read it, they are free to make edits of their choice without even disclosing their paid status, as long as they are not making specific edits about the payer institution. The way I read it, is that GLAM employees do not need to disclose because: "Disclosure is only necessary where compensation has been promised or received in exchange for a particular contribution". That section recommends a simple disclosure for W-in-residence, but only in the case where they are "specifically compensated to edit the article about the archive at which they are employed". Paid status need not be disclosed for general edits unrelated to that. Do you see it differently? Mathglot (talk) 02:20, 24 June 2024 (UTC)

Yes, I do, and so has previous discussion at Wikipedia talk:Paid-contribution disclosure. If they are being compensated for a particular contribution, as per the section you quoted, then they fit the definition of a paid editor. :foundation:Policy:Terms of Use#Paid Contributions Without Disclosure does not distinguish reasons for the paid contributions. isaacl (talk) 06:14, 24 June 2024 (UTC)

Yes they do fit it if compensated for a *particular contribution*, and the Paid FAQ linked by the foundation Policy you cited above specifically calls out the circumstances when paid editors do *not* need to disclose their contributions. Those circumstances match those of paid OKA volunteers, who, had they been a Wikipedia-in-residence or a GLAM-paid instead of OKA-paid, would not have had to disclose their status, according to the wmf policy FAQ itself. Mathglot (talk) 06:39, 24 June 2024 (UTC)

On the English wikipedia we do require that disclosure "If you receive, or expect to receive, compensation for your contributions to Wikipedia, you must disclose who is paying you to edit (your "employer"), who the client is, and any other relevant role or relationship." Even if the foundation FAQ says that per the foundation they don't per English wikipedia they do. Horse Eye's Back (talk) 06:44, 24 June 2024 (UTC)

The FAQ is giving specific examples, and is non-exhaustive. As explained in the first paragraph of the section, you are only required to comply with the disclosure provision when you are compensated by your employer or by a client specifically for edits and uploads to a Wikimedia project. This is in accordance with the actual Terms of Use: if you are being specifically compensated for contributions, you are a paid editor, but this does not extend to your contributions that are not within the scope of your compensation. If you are being paid to edit about your employer, that's within the scope of your compensation, and so the relationship has to be disclosed (and the example is about this specific situation). isaacl (talk) 13:24, 24 June 2024 (UTC)

So in the same line of thought, this means that all articles created by Wikipedians in Residence in the context of the organization that pays them need to go through AfC (as @Horse Eye's Back suggests in the comment below), is that also your understanding? 7804j (talk) 16:21, 24 June 2024 (UTC)

Note that "Wikipedian-in-residence" is just a self-described title, without any oversight from anyone involved with the WMF or Wikipedia, so the scope of their role is entirely decided by their employer and them. Some of those who have participated at Wikipedia talk:Paid-contribution disclosure have said that they do not edit Wikipedia as part of their role; they provide education and support to the institution's staff. isaacl (talk) 16:56, 24 June 2024 (UTC)

"Do we require AfC from Wikipedians in Residences?" The outcome of the recent case involving the BYU library's Wikipedians in Residence clarified that the community does in fact expect Wikipedians in Residence to use AfC. Horse Eye's Back (talk) 03:54, 24 June 2024 (UTC)

@Mathglot "philanthropic paid editing". I like the term - hope it makes it into our updated policies. _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 10:51, 22 June 2024 (UTC)

This is one reason I prefer the term financial conflict of interest. "Paid editing" focuses on a transaction—being paid to edit—but the real issue is the tendency to bias created by some financial relationships. Wikipedians in Residence are the paradigmatic example of people who are literally paid to edit but don't have a conflict of interest; it seems like OKA translators are another. If we shifted the guideline to talk about FCOIs instead of paid editing, the need for an exception for philanthropy would disappear. – Joe (talk) 11:24, 22 June 2024 (UTC)

Hear, hear. There is nothing inherently wrong with folks making $$ out of volunteering. _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 14:17, 22 June 2024 (UTC)

By definition you can't make money out of volunteering, if they're making money they're working not volunteering. Horse Eye's Back (talk) 05:39, 24 June 2024 (UTC)

If you can make xxx$ out of a full tims job and only half of that when editing Wikipedia, it becomes more a hybrid role than pure full time job. Our translators usually give up much better paid opportunities for being able to work on Wikipedia. 7804j (talk) 06:10, 2 July 2024 (UTC)

7804j, I would not pursue this line; it's a distraction, and a loser. Volunteering/working is binary, there is no hybrid, in-between, or threshold of payment so low that it is not "working". Mathglot (talk) 06:18, 2 July 2024 (UTC)

In the context of Wikipedia I agree with you that there should be no distinction in the policy. I just wanted to call out that many of these paid editors do so not because they are interested financially but because they care about Wikipedia and just need some money to pay rent and food (thus why we call it a grant/stipend). Sometimes people are being overly harsh on them, so I think it's important to highlight they also do some personal sacrifices to do that job. 7804j (talk) 06:22, 2 July 2024 (UTC)

Indeed. And WiRs get paid stipends and such, and we still consider them volunteers, no? _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 08:09, 2 July 2024 (UTC)

We consider WiR and such to be paid editors if they are paid (there are volunteer WiR who don't get any compensation). Horse Eye's Back (talk) 15:32, 4 July 2024 (UTC)

You seem to be making the distinction between working full time and working part time, not between working and volunteering. Horse Eye's Back (talk) 15:32, 4 July 2024 (UTC)

No, I am making the distinction between working full time in a for-profit translation company that pays well, and working full-time through stipends from a non-profit organization like OKA that pays a lot less. OKA editors accept a much lower grant than what they could earn elsewhere because they know it's an important cause. 7804j (talk) 15:41, 4 July 2024 (UTC)

And what is the distinction? Neither of those is a hybrid situation or volunteering... Taking a lower salary to work in a job you want to work in vs one which pays more but you don't want to do is not volunteering, almost all of us do that. Horse Eye's Back (talk) 15:54, 4 July 2024 (UTC)

Wikipedians in Residence all have signficant conflicts of interest, primarily in relation to their employer. Horse Eye's Back (talk) 05:43, 24 June 2024 (UTC)

Everyone has significant conflicts of interest, primarily in relation to their employers. The issue is whether they make edits in those areas or not. If a WiR at the Museum of Nowheresville was editing Museum of Nowheresville, there'd be a problem. If an OKA translator was editing Open Knowledge Association, there'd be a problem. But that's not what we're talking about here. – Joe (talk) 10:49, 24 June 2024 (UTC)

Not able to square "Wikipedians in Residence are the paradigmatic example of people who are literally paid to edit but don't have a conflict of interest" with "Everyone has significant conflicts of interest, primarily in relation to their employers" Horse Eye's Back (talk) 07:05, 27 June 2024 (UTC)

So OKA has been on my radar for some years now due to off-wiki reports sent to the paid editing queue. I was extremely suspicious of it at first and (along with others active in UPE patrolling) worried it would be a sort of front for the usual abusive paid editing. However, I have to hold my hands up and say that it's been c. five years and nothing like that has come up. From what I've seen, the selection of topics is genuinely made based on what's missing on enwiki, and the quality of the translation are at least no worse than average. @7804j: You perhaps made an initial strategic error in structuring/talking about this as "freelancers" doing "paid editing", because this puts you in a category of people that the volunteer community, for good reason, have come to be very sceptical of. Essentially identical activities that are framed as grant-making or residency do not raise the same eyebrows, especially if you can get some sort of buy-in from the WMF (which is not hard).

Quality is a separate issue and something that pretty much always causes friction when people who aren't very familiar with Wikipedia are incentivised to contribute to it en masse. There is no easy to solution to this. Specifically, making them go through AfC isn't going to help – AfC reviewers don't have the time to do a close reading of drafts to look for translation issues. They'll take a look through for major problems (which OKA drafts don't seem to have) and for notability (virtually guaranteed because these are substantial articles on other Wikipedias) and then pass it through. So we'll end up with the same outcome as if they were created in mainspace directly, just with some extra volunteer time wasted within an already backlogged process.

As to whether OKA creations need to go through AfC, I am usually the last person to point this out, but technically this is a request not a requirement. AfC is broken by design because generally we don't want to encourage paid editors by giving them an efficient route to publication, or encourage volunteers to do work that someone else will get paid for. As Mathglot says, Neither our COI policy or the AfC process was designed with 'philanthropic paid editing' in mind. I think it's fine for OKA editors to bypass this and create directly in mainspace. This isn't an exception our a change to the rules, it's just applying WP:IAR and recognising that forcing good faith creations into a broken process because their creator got a stipend while writing them, or because they might have some translation issues, is not in the spirit of WP:FCOI. – Joe (talk) 09:25, 22 June 2024 (UTC)

@Joe Roe "extra volunteer time wasted" - exactly, this is the problem I am trying to address. _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 11:12, 22 June 2024 (UTC)

Thanks @Joe Roe!

Initially, I also thought that the AfC requirement for paid editors was a request and not a requirement. However, @Seraphimblade raised in my talk page that any OKA editor creating an article in the mainspace without going through AfC would be blocked. Hence why we started requiring all our translators to go through AfC since early May.

I agree with you that it was a mistake from my end to have initially used the term "freelancer". Our translators are volunteers receiving a grant to cover basic costs of living (~400 usd per month for the ones working full time). Going forward, I will make sure to always use the more accurate terms of "Grant/stipend recipients". I did not want to use the term of "Wikipedians in Residence" as it seemed to me that this requires that the work be related to the institution itself. I wasn't aware that there are options to get buy-in from the Wikimedia foundation, but I will explore this avenue as it will indeed help with acceptance of OKA among the community.

In general, I strongly with the idea of introducing a broader exemption to the AfC requirement of the COI policy to either philanthropic institutions that do not target specific topics and give high degree of freedom to grant recipients, or to payments that are too low to represent full wages (e.g., <xxx$ per month/ per hour).

7804j (talk) 11:54, 22 June 2024 (UTC)

Specifically you might want to look into meta:Wikimedia thematic organizations or one of the other categories of meta:Wikimedia movement affiliates. – Joe (talk) 12:06, 22 June 2024 (UTC)

Whatever avenues you explore, I would not get into proposals related to trying to find a threshold where a payment is "too low" to make a difference, and thus presumably not trigger a PAID concern. Experience with paid crowd-sourcing platforms such as MTurk shows that micropayments may attract volunteers for certain tasks, even sometimes for a larger than average task such as a translation. Mathglot (talk) 18:04, 22 June 2024 (UTC)

This might be a dumb question, but I'm tired and can't find it: where in the policies do we require paid editors to use AFC? (please do not ping on reply) Primefac (talk) 22:05, 22 June 2024 (UTC)

WP:COIEDIT states that paid editors "should put new articles through the Articles for Creation (AfC) process instead of creating them directly". _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 02:52, 23 June 2024 (UTC)

I see. Primefac (talk) 12:38, 23 June 2024 (UTC)

Ah, so here's this month's OKA thread, I thought I'd miss it!

If an organization of this sentiment really wanted to help the English Wikipedia, they would be working exclusively on poorly developed vital articles. Then there would be no AFC necessary. The English WP is far past the point where creating new articles is an effective way to make meaningful improvements. Unless, of course, this creation targets areas of systemic bias where there is a genuine dearth in coverage.

To me this appears much like the organizers have gone so far in one direction that whether or not their effort is actually worthwhile is no longer a consideration. Even with their current infrastructure, it would be considerably more effective to take EN FAs and translate them into other languages. Aza24 (talk) 07:29, 23 June 2024 (UTC)

You've created 68 articles, the last one two weeks ago. Are we to understand that that was the last one we needed? – Joe (talk) 11:22, 23 June 2024 (UTC)

Halleluyah, we are done! _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 13:27, 23 June 2024 (UTC)

The English Wikipedia does not need new articles nearly as much as it needs improvements on existing ones. As I said, the only exception is to fill systemic bias gaps, which yes, includes a woman poet! Comparing a single editor with an entire organization does not track.

Unfortunately, the OKA is fundamentally flawed in this regard, but it doesn’t seem like an object of concern for them. Aza24 (talk) 17:09, 23 June 2024 (UTC)

I should add that if I'm being overly critical, it's because this organization should be held to a high standard. Sine it is under the guise of effective altruism, the former "effective" qualifier needs to take more prominence. I can't see anywhere that it's even been considered how to most effectively help Wikipedia. Otherwise, the OKA would have approached the community before founding, to identify what is actually needed. Since they didn't, now we find ourselves in these same threads, time and time again. Aza24 (talk) 17:35, 23 June 2024 (UTC)

Your argument appears to be about your opinion on how work on Wikipedia ought to be prioritized, and is a red herring. One of the central features of a volunteer organization, is that volunteers work on articles of their choice, not articles of your choice, or some committee's choice. Thank goodness I didn't have to listen to you, or I never would have had the opportunity to translate that article about a medieval Catalan peasant uprising, when there were no doubt many hundreds of thousands of tasks more urgent than that one at the time. The OKA volunteers who translate articles of their choice in their own manner should be held to the same standard I was, namely, Wikipedia policies and guidelines, and nothing else. Mathglot (talk) 19:14, 23 June 2024 (UTC)

Thank goodness I don't have to listen to you either! Aza24 (talk) 19:45, 23 June 2024 (UTC)

@Aza24 I do not think this is the right place to discuss this. This thread is about whether to make changes to the AfC requirement of COI, not about how OKA prioritizes articles. So I would suggest moving that discussion for example to the OKA taskforce talkpage.

That being said, we (OKA) already operate along the lines of what you seem to recommend. Many if the articles our translators work are are about neglected topics in EN wiki, for example, articles about geographical features of non-English speaking countries (eg, Spain, Latin America) or non-English speaking historical figures. I would actually argue that improving coverage on these topics is much more important than extending already extensive articles on important topics. But most importantly, it takes different skill sets to translate vs expand articles. The editors who receive our grants would not necessarily be sufficiently familiar with these topics to be able to expand them starting from scratch.

Regarding your recommendation to translate from English to other languages: we do that already. We published thousands of articles in the Spanish and Portuguese Wikipedia, with a strong focus on under represented topics in these Wikipedia such as mathematics, computer science, etc. There's been a lot of off Wiki analysis of opportunities to maximize impact on donation that went on before we decided to set up OKA the way it is, and I'm happy to share more detail about the rationale if there is interest 7804j (talk) 19:41, 23 June 2024 (UTC)

I'm going to retract my comments. Given your response, I don't think I'm nearly as informed as I should be on the organization to be casting such aspirations/critiscms. Also, my comments seemed needly inflammatory; my apologies. – Aza24 (talk) 20:54, 23 June 2024 (UTC)

@Aza24 I just wanted to say that it is quite rare to see folks backtrack and even apologize in Internet discussions (and that includes on Wikipedia). Regardless of the issue at hand, I would like to say I very much respect and appreciate you for what you have just said above. Cheers, _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 02:47, 24 June 2024 (UTC)

How did feline hyperthyroidism come up then? Traumnovelle (talk) 09:23, 5 July 2024 (UTC)

I see a nescessary delay, there is no rush and that absolutely needs to be treated the same way as other paid edits. Horse Eye's Back (talk) 16:49, 23 June 2024 (UTC)

I agree that paid editing is fishy due to the presence of inherently non-encyclopedic motivation, which may ultimately lead to poor quality translations of selection of poorly referenced source articles. As I see, OKA is fairly new and it is probably not flooded with quick buck seekers, but things may quickly change when rumors spread on how to earn some extra easy cash off google translator. I took a quick look at OKA articles submitted in AfC and all my random picks seem to have good quality. So here is my suggestion: How about vetting decent contributors to bypass AfC? - Altenmann >talk 19:19, 23 June 2024 (UTC)

I could see creating some sort of “fast-track” for reviewing these articles, but some sort of review is still necessary. If for no other reason than preventing duplication of topic with existing articles. Blueboar (talk) 19:51, 23 June 2024 (UTC)

I could get behind a separate lane so to speak, I just really dislike the idea of creating a loophole. Horse Eye's Back (talk) 19:58, 23 June 2024 (UTC)

HEB, Can you expand on what you mean by the idea of "a separate lane"? I wouldn't favor a change that referred to OKA by name (except at best in an explanatory note as an illustration of a general point in line that requires an example). Plenty of generalized guidelines have logical carve-outs that need to be explicit, for example, the guidance that strongly discourages external links in the body of an article specifically states that it doesn't apply to inline citations. We could follow that approach.

But there may be even a better way to deal with this. Currently, the first line of WP:FCOI says this:

Being paid to contribute to Wikipedia is one form of financial COI; it places the paid editor in a conflict between their employer's goals and Wikipedia's goals.

In my view, this is the crux of the problem, because it *assumes* that an employer's goals are in conflict with Wikipedia's goals. But what if that is a false assumption? I believe the general problem we are addressing could be handled without any specific carve-out, by altering it as follows:

Being paid to contribute to Wikipedia is one form of financial COI; it places the paid editor in a conflict when their employer's goals and Wikipedia's goals differ.

If the goals of an organization do not differ from Wikipedia's goals, then no separate lane or carve-out is required elsewhwere. This somewhat leaves open the question of what we would define as Wikipedia's goals, but Wikipedia:Purpose (info page) says this:

Wikipedia's purpose is to benefit readers by acting as a widely accessible and free encyclopedia; a comprehensive written compendium that contains information on all branches of knowledge. ...

The goal of a Wikipedia article is to present a neutrally written summary of existing mainstream knowledge in a fair and accurate manner with a straightforward, "just-the-facts style".

If a philanthropic organization's goals are the same as Wikipedia's, and there is no organizational oversight of payees' output, then it seems to me no special lane is required. (edit conflict) Mathglot (talk) 20:35, 23 June 2024 (UTC)

The practical question is who's going to decide which edits do or do not need independent review? If in practice this can only be done on an article-by-article basis, then I don't think much is gained by setting up a new decision branch that comes before using the articles for creation process. isaacl (talk) 22:39, 23 June 2024 (UTC)

The lane or whatever isn't me idea so I don't want to speculate on it, in general I think what we have now works. In terms of the hypothetical unless they themselves are wikipedia how can their goals be the same as Wikipedia's? Generally organizations have self promotion as a goal and that is forbidden per WP:PROMOTION. Horse Eye's Back (talk) 05:52, 24 June 2024 (UTC)

The organisation's goals may be the same but the individual's goal may be to try and make as much as money as quickly as they can which can lead to machine translations + quality issues, which I've notice in the one OKA article I came across. Traumnovelle (talk) 09:25, 5 July 2024 (UTC)

That could be a problem if the payment model is Piece work, but it's unlikely to be a problem with a set monthly stipend. WhatamIdoing (talk) 19:20, 5 July 2024 (UTC)

The New Page Patrol process should already cover most of the review requirements, no? 7804j (talk) 20:11, 23 June 2024 (UTC)

Question: do we actually have some specific consensus that these uniformly awful translations should in fact be submitted through AfC? That would be such a good thing! Every one of them I've seen so far (mostly relating to horses) has been created directly in mainspace, and requires an amount of clean-up that seems to be far beyond the editor resources we have – with the result that overall this project is making the encyclopaedia worse, not better. I've asked myself several times why these pages were not being submitted as drafts, but not until now seen any discussion of them; if there's an standing consensus that they should go through AfC, I'll be draftifying several of them in the near future. Sorry, but oppose any kind of AfC exemption for the moment. Justlettersandnumbers (talk) 20:42, 23 June 2024 (UTC)

Justlettersandnumbers, First: imho, you should draftify them regardless, if they are not ready for mainspace, not because there is or isn't some guideline stating that they should all go through Afc. Secondly, do you draw a distinction between awful translations produced by paid translators and awful translations produced by unpaid translators that go straignt into mainspace, and if so, what criteria should be used for each? Granted, the former are easier to find due to categorization. Mathglot (talk) 20:52, 23 June 2024 (UTC)

• I think enough concerns have been raised about poor translations here that the argument to skip the AFC process is quite weak. I will also add that unedited machine translations are an extreme drain on experienced editor time, resulting in diffs like this one from 2021. If unedited machine translations are occurring here, this could turn into a big problem and big cleanup effort, and once sufficient evidence is gathered, we should attempt to communicate these concerns to the event organizers. –Novem Linguae (talk) 02:19, 24 June 2024 (UTC)

  I've seen no evidence that OKA translators are creating unedited machine translations. – Joe (talk) 10:55, 24 June 2024 (UTC)

  Sounds like @Johnbod (mostly these are machine translations by people whose English is rather poor) and @Theroadislong (Has this been machine translated? There seems to be a lot of mangled content here? in Draft:Renaissance in Ferrara) might disagree. –Novem Linguae (talk) 16:13, 24 June 2024 (UTC)

  Indeed - 7804j has never denied that these are machine translations, and they normally appear on en:wp in a single edit, & are not edited further except for a couple of tidies. There is no evidence that they are edited machine translations when OKA bow out, and they should be treated as "unedited machine translations" - what other evidence of absence would there actually be? Other volunteers are left to do things like categories and links, which they normally lack. Very rarely does anyone do the complete rewrite that ones like Draft:Renaissance in Ferrara need just to be comprehensible to an average English reader. To anyone who think OKA texts are "generally good" or "decent translations" I would say: just try actually reading that one - which btw will probably get far more views than most OKA efforts, as there is a real topic there. It covers our existing School of Ferrara but that is so crap I don't object on WP:FORK grounds, though it is typical that OKA haven't addressed this. Johnbod (talk) 15:11, 25 June 2024 (UTC)

  I think you're applying a really high standard here. For example, the original title of Brazilian Romanticism Painting, and yes of course that's not perfect English, but does it impair the reader's ability to understand that the article is about Romanticism in Brazilian art? No. I see the same kind of thing reading through the rest of the article and other OKA articles: uneven English, yes, but perfectly comprehensible and, more importantly, sourced encyclopaedic content. The rest will be ironed out with time, like how you corrected the title of Brazilian Romantic painting a couple of weeks after it was created.

  It's actually quite easy to verify whether a machine translation has been edited or not: just run the original through the same translator. For example, here's how DeepL handles the first paragraph of the first section:

  The Este court in Ferrara was one of the most vital in northern Italy from the end of the 14th century, when Niccolò d'Este started the university and initiated the construction of the castle[1]. The courtly connotations were pronounced, as evidenced by the interest in the world of fairy tales of medieval heritage, as evidenced by the numerous novels of chivalry that enriched the famous library, in astrology and esotericism[2]. On an artistic level, Pisanello, who produced various medals for Lionello d'Este, was highly appreciated, as was the illuminated production, both of an international nature, in which Belbello da Pavia (author of the Bible of Niccolò d'Este) stood out, and updated to humanism, such as that of Taddeo Crivelli (Bible of Borso d'Este)[2].

  Compare that to the draft:

  The court of the Este in Ferrara was one of the most vital in northern Italy since the late 14th century, when Niccolò d'Este funded the University of Ferrara and started the construction of the Castello Estense. His courtly features were prominent, as evidenced by his interests in the fable world of medieval heritage, astrology and esotericism. On the artistic level, Pisanello, who produced several medals for Lionello d'Este, was highly regarded, as was the illuminated production of both international in which Belbello da Pavia (author of the Bible of Niccolò d'Este) stood out, as well as update to humanism, such as that of Taddeo Crivelli (author of the Bible of Borso d'Este).

  Again, it's not perfect, but it's not somebody just acting as a conduit for automated translations, which is what the practice of draftifying these is supposed to filter out. OKA editors are using a machine translation as a base and then proofreading it, which in my experience is what practically everyone that works in more than one language does these days. – Joe (talk) 15:41, 25 June 2024 (UTC)

  Not sure what you think this demonstrates. It could be that they used a different translator. If you are suggesting they used the same one, then manually touched it up, the effect of their changes has on the whole made things worse, no? To someone who doesn't know the area, both versions of the passage are basicly gibberish in the details. To bring either up to even mediocre WP standards, a total rewording is needed. This is typical (ok, this example, which Piotrus selected, is worse than most of theirs these days). Johnbod (talk) 15:02, 28 June 2024 (UTC)

  Including estabilished and experienced editors like myself. (I machine translate and proofread my own articles between en and pl, for example). Nothing wrong with using MT as long as one knows how to proofread stuff (and if the original article of course is of decent starting quality to begin with). _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 02:53, 26 June 2024 (UTC)

  See Feline hyperthyroidism

  Deepl translate of the German lead gives me: Feline hyperthyroidism is a disorder of the endocrine system in domestic cats (feline, adjective from the Latin felis "cat"), which is characterised by hyperthyroidism. It is the most common hormonal disorder (endocrinopathy) in cats over ten years of age, whereas hyperthyroidism is much less common in other pets. The disease is often characterised by weight loss despite increased food intake, is usually detected by blood tests and is easily treatable.

  I believe the whole article is probably just a straight up machine translation. Traumnovelle (talk) 09:34, 5 July 2024 (UTC)

  Novem Linguae, one of the points of this discussion, I believe, is that there is a difference between poor translations in general on the one hand, and translations by paid OKA editors on the other. Can you confirm that the translations in your 2021 link above as added to Cemetery of San Fernando were from OKA editors? Because if they weren't, everyone, I think, is in agreement that there are very many poor translations by new editors. The question at issue here is whether that applies to OKA editors as well, to such a degree that Afc is necessary for their contributions. Mathglot (talk) 11:21, 24 June 2024 (UTC)

  Can you confirm that the translations in your 2021 link above as added to Cemetery of San Fernando were from OKA editors? They were not OKA editors. That link is just a generic example of how much work machine translations are to clean up. –Novem Linguae (talk) 16:13, 24 June 2024 (UTC)

@Justlettersandnumbers: I'm not sure if you're asking about this specific case or translations in general. If it's the specific case of OKA, it sounds like you've found a bad run of horse-related translations, but myself and others have seen a lot of decent translations from them too. The reason some are asking OKA translations to go through AfC is because they're paid for them, not because they're translations.

If you're asking whether there is community consensus for draftifying poor translations in general, I'd say the answer is no. Unedited machine translations are fair game (a legacy of the WMF's failed experiment with auto-translation, I believe), but if it just needs copyediting then draftspace will not help. AfC reviewers don't routinely do anything about translation issues, as long as it's a viable article. Instead there's the {{Cleanup translation}} family of templates and an active patrol that deals with them in mainspace. – Joe (talk) 11:22, 24 June 2024 (UTC)

The WMF has never attempted to do anything with auto-translation. They accidentally (and briefly) enabled exactly the sort of "machine translation as a base, but then proofread it and clean it up" system that many good editors use themselves, from Spanish to English (only that language pair) here, and then turned it back off when the error was pointed out to them.

In the meantime, one (1) editor dumped a bunch of unedited Spanish mis-translations in the mainspace, and we panicked and created Security through obscurity restrictions on all editors ever since. Which is to say: I can, and have, used machine translation to English in the Wikipedia:Content translation tool, but most editors, including those with far better translation skills than me, won't be able to figure out how to do that on their own. In the meantime, most editors are pasting the contents into machine translation in another tab, and thereby screwing up links, templates, categories, and formatting. Anyone who's been paying attention will know that this is typical of our community. WhatamIdoing (talk) 05:05, 28 June 2024 (UTC)

@WhatamIdoing Indeed. My students do translations for class assignments, and I often tell them not to bother with the official Wiki translation tool because it doesn't work due to the reasons you discuss (i.e. their work can't be easily published). Then, of course, they struggle with code etc. eating our class time, so instead of having let's say a discussion about free culture or such I have to spend time doing activities about how to add hyperlinks or templates or such. On the bright side, they eventually learn the code, at least some of it. But it is still embarassing that I have to tell them "don't use the official tool, it is not friendly enough". _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 09:50, 29 June 2024 (UTC)

Yes, that's what I was referring to. A promising tool that was killed by a botched deployment – typical of the WMF in that era! – Joe (talk) 06:30, 1 July 2024 (UTC)

If you are referring to Wikipedia:Administrators' noticeboard/CXT, then your summary is extremely misleading, as it was about the extremely poor translations from many editors, with that Spanish editor as the most visible example. But upon rereading that discussion, I see that you were trying to muddle the waters and defend the indefensible by providing wrong numbers there already, so I guess hoping that you will change now is rather useless. Fram (talk) 08:58, 1 July 2024 (UTC)

I moved Draft:History of Caraquet back to draft space yesterday. It would be nice if such articles didn't start with presenting speculation by one local amateur historian and genealogist as if it was accepted truth, even though it disagrees with nearly all actual historians and the available evidence. The remainder of the article isn't much better. Fram (talk) 08:58, 1 July 2024 (UTC)

@Fram What policy allows you to draftify such an article without consulting the community? I believe AfD is the only acceptable option (or perhaps PROD/CSD if not contested). _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 09:40, 1 July 2024 (UTC)

WP:ATD, why? The topic is probably salvageable, the article is largely rubbish, so the paid editor can make sure they write a decent article which at least follows accepted science, instead of blindly copying what another Wiki has produced. Fram (talk) 10:07, 1 July 2024 (UTC)

I do not see draftification listsed as an acceptable ATD. Sure, the article needs various fixes, but I don't see why they cannot be done in the mainspace. If you think it should not be in the mainspace, we need a community consensus (i.e. through AfD) on whether it should be de-mainspaced. Single editors do not have the power to delete (hide) articles - this is a task we relegate to the community (outside CSD-level garbage) and this is hardly at that level. See also WP:DRAFTNO. _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 08:13, 2 July 2024 (UTC)

I see it listed under incubation: "Recently created articles that have potential, but do not yet meet Wikipedia's quality standards, may be moved to the draft namespace ("draftified") for improvement, with the aim of eventually moving them back to the main namespace, optionally via the articles for creation (AfC) process..." (the whole incubation subsection is actually about draftification, incubation and draftification appear to by synonyms... Maybe we should just use one term as it seems to be causing confusion?) Horse Eye's Back (talk) 17:45, 5 July 2024 (UTC)

Before the Draft: space was created (late 2013), that section of the deletion policy was talking about the Wikipedia:Article Incubator. Before the Wikipedia:Article Incubator was created (in 2009), we moved such articles to the creator's userspace. WhatamIdoing (talk) 19:27, 5 July 2024 (UTC)

The problem is the ambiguous "Wikipedia's quality standards". Some AfC reviewers seem to decline anything that's not GA-level ready. _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 10:30, 6 July 2024 (UTC)

"Wikipedia's quality standards" does not mean GA and I don't think you will find a single editor who will publicly say that. If an AfC reviewer is doing that on the DL then bring a case against them and get their privilages stripped, someone being an abusive jerk isn't the wording's fault its the absusive jerk's fault. Horse Eye's Back (talk) 16:45, 6 July 2024 (UTC)

We do have a mismatch between the mainspace's actual standards and what it takes to get an article out of AFC. For example, we had a chat last week about why "too short" was listed in Wikipedia:WikiProject Articles for creation/Reviewing instructions as a reason to decline an article. We agreed to change it.

Looking at 10 recently accepted articles, the Page Size gadget shows a median new article accepted by AFC is around 400 words. A quick visit to Special:Random indicates that the median Wikipedia article (most of which are not new, and some of which are very well developed) is less than 200 words. I don't think that AFC should be expecting the typical new article to be twice the length of established articles. WhatamIdoing (talk) 18:18, 6 July 2024 (UTC)

@Horse Eye's Back I've seen some articles declined, by various reviewers, where I am sure those articles would not be draftified or deleted at AfD. Declining articles because not all content is referenced, for example, is I think pretty common (but I don't have a solid sample to say if this is a systemic problem, or I just stumbled upon some expections). Now, it's great to prod new editors and tell them to make sure everything is referenced - but if they don't do this, should their content be declined and even deleted, even through the same article, if published in the mainspace, would at best get some {{fact}}s? For example, recently Draft:Battle of Pinsk was declined due to no inline citations (it only had general links). The creator, fortunately, addressed this and now the article languishes in draft queue, even through it's obviously good enough for mainspace. But even without inline citations, it would've been fine as a stub/start-class; having inline citations is not necessary (not that I am not saying we should not push for their addition, I am just saying - the rules don't say lack of inline citations is sufficient reasons for not publishing content). _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 14:04, 9 July 2024 (UTC)

PS. Even AfC reviewing rules linked just above state that declining article due to lack of inline cites is an error: "Avoid declining an article because it correctly uses general references to support some or all of the material. The content and sourcing policies require inline citations for only four specific types of material, most commonly direct quotations and contentious material about living persons." _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 14:05, 9 July 2024 (UTC)

I have accepted this draft, though the lead section needs re-writing per WP:LEAD. Theroadislong (talk) 17:27, 9 July 2024 (UTC)

Thank you, @Theroadislong. I know some reviewers worry about what will happen if they accept WP:IMPERFECT articles. If the reviewer doesn't accept such an article, they break the nominal rules and often lose content (because the original editor will give up), but if they do, then someone who doesn't know the actual rules or who disagrees with them might come yell at them. If they do it more than rarely, the reviewer can end up at risk of a serious attack. One 'mistake' in 100 adds up to a lot of mistakes if you review thousands of articles, but nobody at ANI says "1% possible error rate"; they say "Obvious WP:COMPETENCE problem; here are a dozen he screwed up on!" WhatamIdoing (talk) 04:14, 15 July 2024 (UTC)

Here's what I think about the issue:

• AFC is essentially broken by design (See Wikipedia:Broken by design)
  • It takes an enormous amount of time
  • Reviewers do thankless work and don't want to exhaustively review a translation
  • Reviewers are technically speaking supposed to allow things that are notable & not promotive through regardless of translation qualify.
• The articles are accurate & unbiased but badly translated
  • Looked at a couple, consider Brazilian Romantic painting. The subject is notable and the article is probably going to be helpful to somebody, but the sentence "This pictorial production was part of the local evolution of the Romantic movement" seems typical. "Pictorial" is a word I assume is more common in portguese, but when used for no reason makes things jarring and hard to understand in English.
  • That one can probably be improved (though it would be a lot of work, given the length). But if you consider Draft:Renaissance in Ferrara, even the lead is genuinely difficult to understanding the meaning behind. Content can't be fixed if it can't be understood in the first place.
• Normal Wikipedia articles are also terrible
  • The current policy on badly translated articles is to leave them up, even if they're just -- in French.
  • There is Wikipedia:Pages_needing_translation_into_English

So, probably let them be created without AFC, but maybe the NGO should have someone who has native-level proficiency in English review them if they're not by professional translators? Because some of the text in Renaissance in Ferrara is bad, and Brazilian Romantic painting is obviously very oddly worded as of the first sentence. Maybe it's ok if some of the articles on Wikipedia are badly worded. Especially because AFC is not designed for this. Mrfoogles (talk) 23:00, 14 July 2024 (UTC)

The one thing that AFC *is* designed for is finding articles that duplicate material already present on Wikipedia, as in Draft:Wooden_house (see reviewer comment). That is important. Mrfoogles (talk) 23:03, 14 July 2024 (UTC)

I don't see how this is a COI. The editors are writing on random topics they choose. Presumably they have no financial or other interest in the topics they are writing on. If individual editors have a COI, they should of course declare it and go through AfC. If an article is really terribly awful and not notable at all, it will be deleted, merged, BLARed, etc.; if an article is really terribly awful and of marginal notability, someone at NPP will probably draftify it. voorts (talk/contributions) 21:20, 18 July 2024 (UTC)

arbitrary break (translated for $$)

There have been a lot of assertions unsubstantiated opinions about the quality of OKA-generated content that range roughly from it sucks to very good, with little to back it up. As of yesterday, articles which have been assessed for quality and which carry the {{OKA}} template on the Talk page now appear in the standard, quality-assessment categories; the parent category is OKA articles by quality. (A flat, quality-agnostic view is available here.) I am not knowledgeable about how these ratings are assigned, but afaik it has something to do with the Afc process. It might be interesting to compare the quality distribution here with that of all translated articles. In any case, at least we have some data to look at, instead of just raw opinion. Mathglot (talk) 20:03, 2 July 2024 (UTC)

Anything B and below is pretty much meaningless in terms of measuring quality as anyone can assign these ratings and they are not given much oversight/critical evaluation. I don't doubt some quality translated articles can exist but offering money for a task that can be very easily automated is a terrible idea as proven by the multiple examples of terrible articles.

@7804j I don't know how your payment model works but if you're paying per article that's a bad idea. Why not pay for good/featured articles instead? It would be much harder to game such a system and would result in better quality if editors were required to work on an article beyond creation. Traumnovelle (talk) 09:47, 5 July 2024 (UTC)

We're not paying per quantity, but per hour of work and instructing that people should focus on quality. Our translators are also paid when they work on improvements of existing articles. 7804j (talk) 09:49, 5 July 2024 (UTC)

How do you measure hours worked given people are working remotely, is it just a trust based model? I can still see someone abusing that through using a machine translation then claiming they did it manually to inflate hours worked. Time clock fraud. Also what put feline hyperthyroidism on the radar, if I may ask? Traumnovelle (talk) 10:08, 5 July 2024 (UTC)

I would say that while hours worked could be an interesting question and relevant for OKA's bookkeeping and financial health, the question of whether OKA is being defrauded by its users is irrelevant as far as Wikipedia article quality is concerned, so can we drop this line of inquiry, or move it to the OKA external website, and stick to the question of how this relates to Wikipedia?

As far as feline hyperthyroidism, I don't understand what you are asking; afaict, you were the first to mention this article. If you meant, "How did this topic get picked up by an OKA editor?" then I would say that my understanding is that OKA editors get to work on any topic of their choice. Is that what you were asking? Mathglot (talk) 10:35, 5 July 2024 (UTC)

Thanks for starting the category Category:OKA articles by quality, Mathglot, as a useful list of OKA articles. Unfortunately our assessments are normally almost entirely based on length, regardless of quality - and many OKA articles are all too long. I see there are ZERO A/FA/FL/GA class articles, & the great majority are B or C. Taking Brazilian Abolitionist Confederation, a 37 kbyte B-class slab from the dreaded User:Racnela21, this is in principle the kind of article I'd support, as being something we are unlikely to cover otherwise, even if it has only had about 40 views a month, a quick skim finds "The document also reports on other aspects of the history of the advances and setbacks made in the Empire's path towards abolition, which is described as a fatality that "caused slavery to become a fact and, what is more, to obtain universal tolerance". Huh? Johnbod (talk) 16:34, 9 July 2024 (UTC)

Zero sounds like the right number. The total number of A/FA/FL/GA class articles in the encyclopedia is 59,491^[source] and I would expect a sample of 60,000 articles drawn randomly from 8M articles in Wikipedia to have about 0.007 articles rated A/FA/FL/GA class. By that reckoning, we should see the first high quality OKA articles appear when the total number of OKA translations reaches somewhere between 200 and 1,000 times the current number. Mathglot (talk) 19:12, 9 July 2024 (UTC)

You're putting this paid editing on par with mass stub creation by now-banned users and all the terrible articles that wouldn't (or shouldn't) survive AfD. A lot of these articles are machine translated without any work in fixing them put into them by the 'creator'. Traumnovelle (talk) 19:19, 9 July 2024 (UTC)

My calculation is bonkers and I was going to redo it, but frankly trying to play a numbers game and somehow measure that against an unknown number of articles that shouldn't survive Afd is a distraction. In any case this is only a sliver of a much bigger issue, already being discussed in other forums, namely that of machine translation and AI output being added to the encyclopedia. This sliver is getting more attention because of the paid aspect, but it goes far beyond that. How are we to deal with that? Somebody said, "If you can't measure it, you can't improve it," and quality ratings seem like the first step. If they are strictly connected with length, do they have any value at all then? Mathglot (talk) 19:54, 9 July 2024 (UTC)

Let's be clear to those looking on; the calculation is not just wrong, it's wrong by many orders of magnitude and should be ignored. if about 60,000 out of 8M articles are A/FA/FL/GA, then that is a rate of 0.007 per article. If you then sample 60,000 articles, you would expect (60,000*.007) articles to me that class... not zero, but 420. If the OKA articles were as good as typical for reaching those classifications, we would expect to see them. (A reference above suggests there are 7000-and-some Oka articles, so we'd expect around 50 meeting that class.) This is not to say that there aren't other considerations, such as the age of the article; how many articles as new to engWiki as the Oka ones are of that class? -- Nat Gertler (talk) 21:59, 9 July 2024 (UTC)

It also takes time and motivation to achieve GA or FA. So don't expect new articles to easily reach that standard. For B class someone should have checked that it was well written. So hopefully B class OKA assessment is not just based on size and pictures. Graeme Bartlett (talk) 00:10, 10 July 2024 (UTC)

Well, all too clearly they haven't - see various complaints above and elsewhere. Many of these are translations of FA/GA articles on other wikis. Even allowing for different standards, if they were in comprehensible English, many ought to at least pass GA. But neither OKA or anyone else is interested in nominating them, if only because they would often need a total rewrite. Johnbod (talk) 01:26, 10 July 2024 (UTC)

The featured article on de.wiki I saw translated by OKA had multiple prose lines that were unreferenced. Whether that is due to article deterioration or if it passed like that I am unsure of. But machine translation introduces many issues that would result in an article failing GA class. Traumnovelle (talk) 01:30, 10 July 2024 (UTC)

No, that's just how dewiki does things. They use very few inline citations, even in Featured Articles. Today's Featured Article there is w:de:Paul Maas (Altphilologe), which has ~1,300 words and 10 refs. About half the paragraphs have no citations at all. Their wiki, their rules. WhatamIdoing (talk) 04:22, 15 July 2024 (UTC)

Policy against demands of proof of non-existence

Answered to my satisfaction - Altenmann >talk 18:17, 23 June 2024 (UTC)

Now and then someone tells me something like "What proof do you have that J. Random was not a Christian?" I know this is a logical blunder, but I cannot remember any rule against this in our WP:V rules. Neither I remember the name of the fallacy. Can someone remind me? - Altenmann >talk 17:20, 23 June 2024 (UTC) Proving a negative? Similar to but not the same as Argument from ignorance? Idk if it is in WP policies, but I would want proof (sourcing) that he was. Selfstudier (talk) 17:30, 23 June 2024 (UTC) but I would want proof (sourcing) that he was -- My question is about demanding a proof that 'he was not. - Altenmann >talk Proving a negative is philosophically too broad. But Evidence of absence seems to suit Wikipedia's approach to WP:TRUTH: our WP:V requires evidence. - Altenmann >talk 17:54, 23 June 2024 (UTC) I assume you're talking about this for statements within an article context, in which case I would need to see an example statement in which it's a problem. If the article on Judy Random states that she was a Christian, I would expect that to be sourced, as well as any statement that she was not a Christian (which is a sourcable thing.) If you're talking about in discussion, that seems quite allowable thing to ask, depending on what was being discussed. -- Nat Gertler (talk) 17:55, 23 June 2024 (UTC) It does not matter. Talk pages are not an idle chat: they are about article content. Of course you can say in talk page anything you want, but if the implications are to change article content, then the arguments must be based on reliable sources. Of course, there are discussions where opinions of editors do matter, such as article titles (heck, take AfDs), but still, they must involve arguments, not opinions, and arguments boil down to shat is said in "real world"- Altenmann >talk 18:01, 23 June 2024 (UTC) OK, the point is, if an article wants to claim that Random was not a Christian, you do actually need a source that says Random was not a Christian. I don't see what's hard about this. WP:V requires verifiability for all claims, including negative ones. --Trovatore (talk) 18:04, 23 June 2024 (UTC) Absolutely it does matter. Your initial post seemed to be seeking a rule against it, and you're on a page for discussing policy. The verifiability policies already cover this for article content, and there's no particular need for a rule against it elsewhere. The example is weak, as it seems quite possible to source a statement that Judy Random was not a Christian or to specify that she held some other religious belief. But if someone is asking that on the talk page, it seems quite a reasonable response to a talk page statement that she was not a Christian. It should not be disallowed to ask that as a response for a claim. -- Nat Gertler (talk) 18:08, 23 June 2024 (UTC) Sorry, I stated my question incorrectly. Let me set it closer to the issue: Someone added Category:Buddhists to a bio. I removed it and I was reverted because I didnt provide an evidence that a person was not a Buddhist. What would be my proper counter-argument. WP:CATV didnt enlighten me. Sorry for my fussy brains. - Altenmann >talk 18:13, 23 June 2024 (UTC) The WP:ONUS is on the person doing the adding to justify the addition. Usually, one could expect WP:BRD but that's not compulsory. So discussion on talk to resolve. Selfstudier (talk) 18:17, 23 June 2024 (UTC) Got it. WP:ONUS is what I needed. - Altenmann >talk 18:20, 23 June 2024 (UTC)

The above collapsed discussion does raise a point that sometimes troubles me. Category links don't have footnotes. In theory they're supposed to be justified by sourced material in the article, but you can't necessarily tell which cite justifies the category.
Of course in most cases this is not that much of a problem, but it can become one when someone adds a category that makes a potentially contentious claim. I remember this specifically over someone wanting to add category:Whitewashing in film to The Last Temptation of Christ (film), which struck me as an uncited criticism of the casting. --Trovatore (talk) 21:46, 23 June 2024 (UTC)

Perhaps one way to resolve this for categories without an clear justification in the prose (or which might do if prose is removed from the article for any reason or perhaps even just reworded) would be to put a hidden comment next to the category link with a source or explicit link to the relevant section of the article (e.g. "see criticism from XYZ Group", "source: P.D. Michaels, 2024", "Ref name=BBCNewsApril29"). Thryduulf (talk) 23:02, 23 June 2024 (UTC)

Hmm, it's better than nothing, but it seems more aimed at editors than at readers. --Trovatore (talk) 23:20, 23 June 2024 (UTC)

(A distinct but related concern is that categories can appear to make assertions in Wikivoice, which we have to be careful about.) --Trovatore (talk) 23:23, 23 June 2024 (UTC)

Categories are supposed to be for defining characteristics. If it's a defining characteristic, it really should be in the prose (although with the way we create categories like "Left-handed Inuit arcwelders from Texas", it may be a combination of different sections of prose.) Per WP:CATV, "It should be clear from verifiable information in the article why it was placed in each of its categories."-- Nat Gertler (talk) 02:01, 24 June 2024 (UTC)

Something else related to the collapsed part of this discussion, but not mentioned there, is that sometimes justification for a category can be implicit. For example if a person is verifiably Swedish and verifiably a member of an organisation that requires members to be Buddhists, you don't need an explicit citation to add Category:Swedish Buddhists to the article unless there is evidence they are/were not Buddhist (perhaps they renounced that religion later in life). Thryduulf (talk) 23:10, 23 June 2024 (UTC)

I think someone adding a category which casts the subject in a negative light, most especially if a BLP, ought to be prepared to defend the addition if challenged. Wehwalt (talk) 01:26, 24 June 2024 (UTC)

Everybody who adds anything needs to be prepared to defend it if challenged. In the example above the defence would be exactly as I've laid out - they are/were Swedish, are/were a member of an organisation that requires members to be Buddhists and there is no evidence the person adding it has seen to the contrary. Thryduulf (talk) 08:37, 24 June 2024 (UTC)

Hmm, so out of curiosity I took a look at that category, which has only two individual bios at the top level, one of which is Malin Ackerman. Ackerman's bio categorizes her as both a "Swedish Buddhist" as an "American Buddhist". However, the body asserts that she was raised Buddhist, and mentions her "Buddhist upbringing", but does not assert that she is currently Buddhist.

Not sure there's a broad policy conclusion here, but I think it's worth noticing that articles are not always entirely careful about these things. Thryduulf, this is arguably similar to the case you mention. She was raised Buddhist, with sources (I haven't checked them, but that seems not on-point in this discussion), and we have no active assertion that she decided she wasn't a Buddhist anymore. Is that enough to put her in the cats? My intuition is no, not when the article uses language that seems noncommittal on her current status. --Trovatore (talk) 17:38, 24 June 2024 (UTC)

I had a similar issue with people adding categories like Jewish Conservatives to Benjamin Disraeli, who was certainly not both Jewish and Conservative at the same time ... Wehwalt (talk) 17:50, 24 June 2024 (UTC)

Disraeli is not even an edgecase - the lead of the article makes it very clear that that category is incorrect and so should not be on the article. Thryduulf (talk) 17:56, 24 June 2024 (UTC)

@Trovatore: I picked the category out of thin air, so it's interesting you found an edgecase! Reading Ackerman's bio (but not the sources), I'd say that if the standard is "on the balance of probabilities" then the category is correct but if the standard is "beyond reasonable doubt" then it isn't (not because it's necessarily incorrect, but because there is reasonable doubt).
When it comes to BLP anything contentious or potentially defamatory absolutely needs to have the higher standard of proof, something innocuous is usually fine at the lesser standard (although obviously better is always preferred if possible). A person's religious beliefs are something that can be contentious and some people would regard some mischaracterisations as defamatory, but not everybody and not always. Given the content in the article I am completely confident that describing Ackerman as Buddhist would not be defamatory even if correct, and I'm not seeing anything to suggest it is contentious. My gut feeling is that they are probably nominally or casually Buddhist - someone who doesn't actively practice the faith but would tick that box on a form. Thryduulf (talk) 17:54, 24 June 2024 (UTC)

So the analogy with legal burdens of proof could get a bit strained, but I'd kind of suggest that the (underused) clear and convincing evidence might be a better way of thinking of it. "Eh, it's probably true" doesn't strike me as good enough to add a cat, particularly to a BLP, even if we think the subject probably doesn't mind being called a Buddhist. --Trovatore (talk) 22:33, 24 June 2024 (UTC)

I don't think categories are (or should be) limited to current status. Babe Ruth is not currently a baseball player, but he's probably properly in those categories. -- Nat Gertler (talk) 17:56, 24 June 2024 (UTC)

Wow, new one on me. I did not know that Babe Ruth was a Swedish Buddhist.

Anyway I think that's a bit of a different issue. Ruth's profession was ballplayer, until he retired. That's what he was known for. Ackerman is not particularly known for being a Buddhist, as far as I'm aware.

It does raise some interesting questions. Eldridge Cleaver became a conservative Republican, but is most known for what you could call "far left" activism, to the limited IMHO extent that that terminology makes sense. Does he belong in e.g. "socialist" categories? I really don't know. --Trovatore (talk) 22:51, 24 June 2024 (UTC)

Maybe we need "Lapsed ..." categories. Donald Albury 23:03, 24 June 2024 (UTC)

I think the idea that categories should be a single-moment snapshot rather than reflecting the wide range that has been noted is wrong. We have a list of American politicians who switched parties in office -- which party's categories should they be under? Both! There may be some categorization that only applies to non-notable periods of their life -- Jane was baptized but declared herself an atheist when she was 12, long before she became a professional cat juggler, so she certainly doesn't belong in Christian cat jugglers and perhaps not even in Christians at all, but if she switched from atheism to agnosticism mid-career, then she does belong in both atheist cat jugglers and agnostic cat jugglers. -- Nat Gertler (talk) 23:14, 24 June 2024 (UTC)

Categories are fundamentally for navigational purposes. If someone is looking for articles about ____, then they should find the articles related to _____, even if occasionally that article says "Well, you might have thought he was a ____, but the truth is rather more complex and interesting than that". WhatamIdoing (talk) 05:21, 28 June 2024 (UTC)

I'm aware of that viewpoint but I don't really agree. The problem is that an article's presence in a category often appears to be an assertion (in Wikivoice no less) that the subject of the article satisfies the category's defining criterion. If there were a way to make it clear to readers, including casual ones, that that is not the case ... but there isn't. --Trovatore (talk) 17:21, 28 June 2024 (UTC)

That's the biggest problem imo, with cats. I stopped paying attention to them for that reason, as long as people are not using cats to enforce or contradict content in actual articles, fine with me. Selfstudier (talk) 17:30, 28 June 2024 (UTC)

In some cases it can be mitigated by renaming the cat to make the criterion more objective. For example I happened to see that the category I called out, category:Whitewashing in film, is actually at CfD. I think a lot of the problem would go away if we renamed it to something along the lines of category:Controversies over whitewashing in film. It's reasonably objective whether there was a controversy; you can support that with one reliable cite. Whether the film is actually an example of whitewashing is much more fraught. --Trovatore (talk) 01:20, 29 June 2024 (UTC)

Trovatore, the second sentence of the Wikipedia:Categorization guideline literally says "The central goal of the category system is to provide navigational links to pages in Wikipedia within a hierarchy of categories".

I conclude from this that categories are therefore fundamentally for navigational purposes, equivalent to something in a navbox. WhatamIdoing (talk) 23:21, 30 June 2024 (UTC)

That might be the goal, but it doesn't trump V or NPOV. I sharply disagree with the idea of providing categories that might appear to make contentious claims just because they might help someone find something. --Trovatore (talk) 19:34, 1 July 2024 (UTC)

We follow the same basic rules for all forms of navigational content. That means that if it doesn't have to be cited in a navbox, it doesn't have to be cited in a category, or a ==See also== list, or a disambiguation page. None of them should be unfair ("non-neutral"), but the primary point of all navigation is to help people find things, not to hide appropriate content away because someone might jump to conclusions. WhatamIdoing (talk) 21:02, 2 July 2024 (UTC)

Putting an article in category:Foos, on its face, makes the claim that the subject of the article is a foo. That ineluctably implicates V, and the claim that it is a foo must be cited (if contentious). --Trovatore (talk) 20:45, 3 July 2024 (UTC)

See also why {{unreferenced category}} exists.

But I wonder whether we have the same idea about what's being "contended" in that small minority of cats that are actually contentious. I think that what matters is whether the article would be of interest to someone looking for articles about _____. This would include articles that are not, sensu strictu, actually about _____. For example, if you look in Category:Planets, you will find 13 pages and one redirect that are not planets. If you take the POV that putting an article in Category:Planets means you are defining that article's subject as "being a planet", then you will be unhappy to discover pages like Definition of planet and Equatorial bulge in that cat, because those subjects are related to planets but not actually planets themselves. OTOH if you take my POV, which is that putting an article in that cat means that someone looking to learn more about planets might be interested in those articles, then you won't have any concerns about the contents of that cat at all. WhatamIdoing (talk) 00:25, 4 July 2024 (UTC)

As I said, if we could make your POV clear to all readers, including casual ones ... but we can't. --Trovatore (talk) 02:00, 4 July 2024 (UTC)

We could. If we wanted to, every content cat page could have an explanation at the top that explains what a category is, what it means for a page to be listed there, and how to use the page. We haven't chosen to do this yet, but there's nothing stopping us from doing so, if we thought it was really important to explain to readers why Category:Planets does not exclusively contain articles about planets.

Actually, we already do, to a very limited extent; it looks like there's a link to Help:Category at the top of every cat page. That's more of a how-to/editor-help page, but we could change that to a reader-help page, if we wanted to. WhatamIdoing (talk) 03:21, 8 July 2024 (UTC)

WhatamIdoing: No. We can't. I mean, sure, we can, but people won't see it.

And that's COMPLETELY UNACCEPTABLE. I think it's utterly inconsistent with NPOV to apply categories that are going to look like assertions in Wikivoice and that are not supported by a consensus of sources. The navigational value is insignificant next to that. --Trovatore (talk) 06:22, 24 July 2024 (UTC)

But that's only if they go to the category page. The casual reader is only seeing the bottom of the page where it lists that this person is in Category:deadbeat dads and Category:pervs and skeezes with nothing covering the fact that he's in those categories as a critic of those people. (Obviously, I'm feeling far too lazy to look up a real example this morning.) -- Nat Gertler (talk) 13:30, 8 July 2024 (UTC)

If you're in the article, and it's important enough for the person to be in the cat, then there should normally be some content in the article itself that makes the relevance reasonably clear. That doesn't require the article to say "Ro Righteous is a deadbeat dad", but it should say something related to the subject (perhaps "Ro Righteous has repeatedly introduced legislation about child support payments"). WhatamIdoing (talk) 04:29, 15 July 2024 (UTC)

Because if there isn't any relevant content in the article, then there's no navigational point in putting the article in [Cat:Deadbeat dads]. WhatamIdoing (talk) 04:33, 15 July 2024 (UTC)

Categories are definitely a navigational tool...... when Wikipedia began we thought it'd be a good way of collecting data and analyzing relationships between articles. However categories are so unstable that data can never be reproduced for any real academic analysis. This is also a problem with our vital articles Moxy🍁 00:54, 4 July 2024 (UTC)

I think they're still a pretty good way of collecting data and analyzing relationships/various other things. They're certainly useful for building graphs and graphs can be very useful. There can be a lot of instability and confusing weirdness, but for the one fairly large topic area I've looked at, there are plenty of relatively stable structures in the networks too (that can be easier to see when edges are bundled e.g. here). Sean.hoyland (talk) 02:11, 4 July 2024 (UTC)

Idea is cat= List= navbox sort of thing, I get that but they are susceptible to manipulation and lots of editors can't be bothered to check, including me, although I used to. I might correct if I happen to notice something weird or outlandish, but all this diffuse, parent/child blah, nah. Selfstudier (talk) 11:12, 4 July 2024 (UTC)

@Trovatore, your comment that people won't see it has made me wonder if you and I are talking about completely different things. So I'm talking about something that looks like this:

The Category: page, with (1) a Help button to click on and get more information, (2) room for a description of what belongs on that page, and (3) a list of articles in the category.

and I think you're talking about something that looks like this:

The categories listed at the bottom of the article

Are you only talking about the list at the bottom of the article? WhatamIdoing (talk) 21:05, 24 July 2024 (UTC)

The categories as shown at the bottom of the article are my main concern, yes. --Trovatore (talk) 22:59, 24 July 2024 (UTC)

As a general rule, if the cat is at the bottom of the page, there should be something on the page above that explains why the cat is there. That might not be "He's definitely a <cat name> himself", but it should explain why this biography is related to that cat's subject. WhatamIdoing (talk) 00:32, 25 July 2024 (UTC)

In my view that's not good enough. I don't think there's any way to avoid giving the impression that the category at the bottom of the page is an assertion in Wikivoice, which means it needs the support of a consensus of sources. --Trovatore (talk) 00:42, 25 July 2024 (UTC)

Totally agree. If you RFC'd this, I'd support. And start sourcing See Also sections while we're at it. Primergrey (talk) 00:56, 25 July 2024 (UTC)

That's what the articles are for. Just repeating the sources used in category pages that the article already has would just make category pages really cluttered. Also, and this is just me, but you are insulting the intelligence of our readers if you think that they can't come to the conclusion that the categories in the article are representative of the sources used in said article. ♠JCW555 (talk)♠ 01:02, 25 July 2024 (UTC)

Huh? I didn't say anything about category pages. As I said, my main concern is that the categories as they display in the article may appear to be assertions in Wikivoice. Therefore articles should not be added to those categories unless the implied assertion would be the view of the consensus of the sources, not just a single source.

I don't think there's any available reform of the category system that addresses this concern. It could be I just haven't thought of it, in which case please do elaborate.

I think the only solution consistent with V and NPOV is to categorize less, specifically not to apply categories that would appear to be assertions and that are not supported by a consensus of sources. I think this concern is massively more important than ease of navigation. --Trovatore (talk) 01:37, 25 July 2024 (UTC)

Can you give me a couple of examples of BLPs in which a given cat is included, but the consensus of the sources is that the cat is irrelevant or wrong? I'm not looking for something like "This scholar is the foremost authority on deadbeat dads, so if you want to know about deadbeat dads, you need to read his work" or "This person is primarily notable because of a landmark court case about deadbeat dads", but "His ex once called him a deadbeat dad, and the consensus of sources is that she's wrong, but I put him in the cat anyway". WhatamIdoing (talk) 01:57, 25 July 2024 (UTC)

Way up higher in this same discussion there's the case of Malin Ackerman, who is categorized as a "Swedish Buddhist", an "American Buddhist", and some others. However the article does not say she is a Buddhist at all; it says she was raised Buddhist.

In the discussion it was speculated that she might be a casual or nominal Buddhist, or anyway someone who doesn't mind being called Buddhist, and that may well be true.

My view is that's not good enough. If we are going to put her in those cats, then the article should be able to say in Wikivoice "Malin Ackerman is a Buddhist", with all the sourcing requirements that entails. I don't mean that the article necessarily has to say that, but it has to be able to say it. --Trovatore (talk) 02:03, 25 July 2024 (UTC)

Are people raised in a religion not appropriately described as being related to that religion? I think you are interpreting this as "If it says Category:Buddhist, then the person must be actively Buddhist right now". I interpret it as indicating that the person is or was Buddhist. WhatamIdoing (talk) 03:22, 25 July 2024 (UTC)

Of course, if we had sources saying that she was definitely no longer Buddhist, then we'd use Category:Former Buddhists instead. But since we know that she definitely was in the past, and we don't have any concrete reason to believe that has changed, then I think the category is fine. We don't have a People who were verifiably Buddhists at one point but whose current adherence to that is unknown category. WhatamIdoing (talk) 03:28, 25 July 2024 (UTC)

No, I disagree. A living person in a "Buddhist" category should be verifiably a Buddhist right now. With strong enough sourcing to put that claim in Wikivoice. That's the natural inference a reader is going to make seeing the category at the bottom of the page. --Trovatore (talk) 06:34, 25 July 2024 (UTC)

I don't think that someone who reads "She was raised Buddhist" will either be surprised to see Buddhism-related cats, or jump to conclusions beyond the statement that they just read. WhatamIdoing (talk) 06:37, 25 July 2024 (UTC)

But they may not have read that part of the article. It appears to be an assertion in Wikivoice that she is a Buddhist. It should require the same sourcing as an assertion in Wikivoice that she is a Buddhist. --Trovatore (talk) 06:58, 25 July 2024 (UTC)

And by the way, that's not "jumping to a conclusion". That's what the plain language means on its face. You can't change that fact by putting assertions to the contrary on help pages. --Trovatore (talk) 07:01, 25 July 2024 (UTC)

The difference is that you (Trovatore) believe that presence in a category means the article subject is (subject of category) whereas WhatamIdoing is arguing that the presence in a category means the article subject is, was or is relevant to (subject of category). Based on how categories are used, the latter is correct. For example John Major is in all the following categories:

• Category:British Secretaries of State for Foreign and Commonwealth Affairs
• Category:Chancellors of the Exchequer of the United Kingdom
• Category:Conservative Party (UK) MPs for English constituencies
• Category:Conservative Party prime ministers of the United Kingdom
• Category:Councillors in the London Borough of Lambeth
• Category:Leaders of the Conservative Party (UK)
• Category:Leaders of the Opposition (United Kingdom)

All of them are or were true at some point but are not now, yet nobody is being mislead. Thryduulf (talk) 09:00, 25 July 2024 (UTC)

Well, I think those are a different case. Those are offices, and it's natural that they include anyone who has held the office. But note that it would be objectively incorrect to put someone in one of those categories who had not held the office, even if they were "relevant to" the office. So no, "the latter" is not correct. --Trovatore (talk) 16:25, 25 July 2024 (UTC)

What makes an office different to non-offices?

Why is it "natural" to include former office-holders in an office-holder category and completely inappropriate to put someone who was a Buddhist but who might or might not currently be in a category for Buddhists?

Which type are categories for place of origin? people associated with a place? occupational categories (e.g. John Major is in Category:English bankers)?

Is it appropriate for Boris Johnson to be in both Category:Politicians from Manhattan and Category:People who renounced United States citizenship? What about both Category:Writers from the London Borough of Southwark and Category:Writers from Manhattan? Does his presence in Category:Partygate scandal imply that he is a scandal? If not, why is that different to him being in Category:British Anglicans? Thryduulf (talk) 16:45, 25 July 2024 (UTC)

I agree with this, and on a side note as someone who does go to category pages to find new topics it is not at all helpful for them to be cluttered with entries that are only tenuously related. If I'm browsing contemporary Algerian authors it's because I want to learn about authors for whom "being Algerian" is a defining characteristic, not, e.g., French people who wrote about spending a few summers in Algeria. I also wish Wikipedia categories would distinguish between cats that are actually defining features of a topic, cats to which a topic belongs but that it's not "known for", and cats "associated with" a topic. I use color-coding when categorizing some of my own spreadsheets, so I can picture a system where on the topic's page cats of the first type are highlighted in cyan, cats of the second in yellow, and cats of the third in grey, and the topic is highlighted with its corresponding color on the category page. JoelleJay (talk) 00:07, 26 July 2024 (UTC)

This prioritization idea appeals to me, because sometimes you want to be able to find the famous cancer survivor who happens to be an athlete, vs the famous athlete who happens to be a cancer survivor.

But I also think it would lead to POV disputes, as people will inevitably, on some articles, have different ideas about what's most important. Lou Gherig probably thought that being a baseball player was more important than developing a neurological problem, but folks who are currently living with Lou Gherig's disease might think it was the other way around. WhatamIdoing (talk) 01:37, 26 July 2024 (UTC)

Lou Gehrig would certainly have "baseball player" and "people with ALS" as primary categories in my system. JoelleJay (talk) 03:28, 26 July 2024 (UTC)

WP:V relating to photographs

How to photographs align with WP:V? Consider an example "Jane Jones drove to work in a blue Chevrolet" where sources describe Jane Jones driving to work, have a picture of her blue Chevrolet, but do not explicitly describe the vehicle as blue. Would we be able to describe the vehicle in our articles based on the photograph publish in a WP:RS or only based on prose descriptions published in WP:RS? I took a glance at WP:V and couldn't find anything. --24.125.98.89 (talk) 13:18, 14 July 2024 (UTC)

If a photograph is published in a RS, we generally trust that the photograph is what the RS says it is. Synthesis can still creep in though. In your example, if the RS just says “this is a picture of Jane Jones’s car”, then it’s possible that she drove to work in a different car which might not have been blue. If the RS says clearly “this is the car in which Jane Jones drove to work”, then I think it would be verifiable to say she drove to work in a blue car. If this turns out to be an important or controversial fact (e.g. for Blue–green distinction in language reasons), we might want to ask for the assessment of “blue” to be made by the RS rather than by the editor.

If the source isn’t explicit in text, then it may also be a question of whether that information is due. Barnards.tar.gz (talk) 13:41, 14 July 2024 (UTC)

24.125, is this related to the tag you added to List of killings by law enforcement officers in the United States, July 2024 about whether the would-be assassin was actually a white person? I don't think anyone has any genuine doubts about that, and a couple of minutes turned up sources like these:

• "a tall, slender, white man who wore glasses and had long sandy-brown hair" [1]
• "According to the FBI, the shooter was identified as Thomas Matthew Crooks, a white male" [2]

I don't think you should assume that the information was added on the basis of a photo. WhatamIdoing (talk) 03:33, 15 July 2024 (UTC)

That series of lists does seem to have both V and DUE issues in the race column. I spot checked a few. There are cases where the person’s race is not mentioned and there is no photo, making it look like race has been inferred from name by the editor. There are cases where the person’s race is not mentioned and an image is given, and the editor may have made their own judgement about what their race looked like. Barnards.tar.gz (talk) 08:39, 15 July 2024 (UTC)

@Barnards.tar.gz, were you looking at only the cited sources? Do you have any reason to believe that any of these are actually wrong?

In terms of Gun violence in the United States, race is one of the biggest predictors of both the person holding the gun (e.g., police officers are disproportionately white) and the person getting shot. There are books, such as The Second: Race and Guns in a Fatally Unequal America and Policing the Second Amendment: Guns, Law Enforcement, and the Politics of Race, on the subject of how gun violence and race interact in the US. Gun violence and race is a notable subject; perhaps we will someday write an article on it. WhatamIdoing (talk) 23:11, 24 July 2024 (UTC)

An example from List of killings by law enforcement officers in the United States, February 2024 is Kassandra Lozano, whose entry uses this source: [3] which is about a car crash and doesn’t mention being killed by a law enforcement officer, or the race of the victim. Digging deeper, it seems the entry is actually based on this source: [4], which does state that a law enforcement officer was the cause of the crash, but doesn’t mention the victim’s race, or include a picture.

I’m guessing someone decided that a person called “Lozano” is likely to be Hispanic. Is that good enough for WP:V? Also, why “Hispanic”? The list also uses Latino/Latina occasionally. What taxonomy of race are we working to here? Barnards.tar.gz (talk) 07:25, 25 July 2024 (UTC)

Are new rules needed for high-profile or previously contested proposals?

We have recently had a slate of discussions at Wikipedia:Move review wherein discussions had run for the requisite seven days (or had been relisted and run for fourteen days or more), and had the typical handful of participants, and were thereafter closed as moved, and where post-closure challenges were made asserting that because of the scope of the subject, more time or participation was required. An example is the still-pending discussion of the disambiguation of ABC News, and the move of the subject previously at that title to ABC News (United States). Another discussion with a comparable move review was the move of Chairperson to Chair (officer), for which it was noted that despite near-universal support for moving the article away from chairperson, a pervious discussion had rejected Chair (officer) as a title.

We currently have one set of rules for carrying out a contested or potentially contested requested move. We have no mechanism for identifying proposed moves, merges, or other changes that could arguably require some lengthier discussion time or higher standard of community participation. We do routinely notify relevant Wikiprojects, and allow anyone to relist a discussion if there is an absence of clarity on consensus. I am bringing this here to figure out if we do need some extra set of rules for discussions that deal with higher-profile topics, or will involve fixing a lot of links and templates, or deal with a subject that was previously discussed and reached a different consensus. I am not comfortable with the idea that some unwritten rule exists requiring different treatment of such cases. The rules should be written. Cheers! BD2412 T 00:45, 16 July 2024 (UTC)

WP:RMRELIST is a fine rule, and already contains guidance telling editors to publicize an RM as widely as needed. We shouldn't start carving out exceptions, especially when we can't predict them from the outset (for example, I would not have expected ABC News to be all that contentious). Additionally, "I didn't get a chance to participate" is not a good reason to overturn an otherwise correct close. If somebody thinks the consensus developed in the first discussion was horrendously wrong, they can open a new one. voorts (talk/contributions) 01:05, 16 July 2024 (UTC)

I had thought about this, having made closures on highly linked articles before when I initially started nosing around at WP:RM. Checking link count wasn't really in my workflow, and still isn't because there are not many of such discussions that I had closed.

While WP:RMRELIST is sufficient for most pages, but there are some which may bode well have better outcomes if the discussion was directed to more people. The banner on the article is placed by a bot, which means that many active registered editors may miss it if the option to exclude bot edits in the watchlist is enabled. Not many would go on WP:RMC to look for articles to be moved as well, despite the high pageview counts (I suspect that many of the regulars load the page multiple times in the day).

It would be good to have at a minimum that the link count of the pages requested for be displayed in the notice generated by the {{requested move/dated}} template. At the very least, closers may take a pause before closing the RM discussion early.

It would be nice to have a centralised notification somewhere on a highly trafficked discussion page (Open tasks at WP:AN?) to list some RM discussions based on number of links to the articles involved. Exact criteria can be fleshed out separately. – robertsky (talk) 02:00, 16 July 2024 (UTC)

I think creating bright-line prescriptive rules on this subject is likely to lead to undesirable bureaucracy rather than any actual improvements in the space. Rather than the arguments about "Topic X is prominent enough to have merited a longer RM" being resolved, I think they'd just change shape and instead manifest as "Topic X is prominent enough to have fallen under the Popular RM Ruleset". (I also share voorts' stance that these assertions are generally fairly weak. It's not practical to keep discussions open indefinitely for fear of someone missing out.) I'm also concerned that, if we create additional procedural hoops for RM closers to jump through, it would exacerbate the existing issues where controversial or complex discussions linger unclosed for weeks beyond their intended end dates.

By and large I think the status quo already works, but if there is consensus to implement a change, I think robertsky's suggested minimum options – displaying link counts on the banner, or having centralized notifications somewhere – would strike a decent balance between increasing visibility and protecting the closure process from overcomplication. ModernDayTrilobite (talk • contribs) 05:23, 16 July 2024 (UTC)

One factor that inflates link counts is that if a template containing links to articles is included on a page, then every article linked in that template shows up in "What links from here", even though the link is only in the template, not elsewhere in the article. Some templates have hundreds of links in them. In other words, link counts are not a particularly accurate way of judging how many links will need to corrected after a move. Donald Albury 12:51, 16 July 2024 (UTC)

Yes, the widespread (over)use of navbox templates has made "what links here" virtually useless for many types of articles, sadly. Johnbod (talk) 15:30, 16 July 2024 (UTC)

Then we should have tools to determine how many actual non-template generated incoming links an article has. BD2412 T 15:35, 16 July 2024 (UTC)

Actually, it would be more useful to have "What links here" ignore links in templates. Donald Albury 16:30, 16 July 2024 (UTC)

Ideally I think it should be an option for "What links here" to show or hide links present only in transclusions, and also an option to show only pages that link via transcluded templates (grouped by template) given that its possible that some links wont show as being from the template namespace if they only appear based on parameters. Thryduulf (talk) 16:39, 16 July 2024 (UTC)

@Thryduulf: Agreed. It is always best to have options. BD2412 T 16:43, 16 July 2024 (UTC)

There's a nice plugin here to find source links that are not part of the template. Check it out at User:PrimeHunter/Source links.js and add it to your Special:MyPage/common.js file. ~ 🦝 Shushugah (he/him • talk) 16:43, 16 July 2024 (UTC)

I think this falls under WP:IAR and WP:NOTBURO. If you're closing a move request where there have been half a dozen previous requests that closed the other direction, or you're closing a move request that requires editing tens of thousands of pages, it's common sense to wait for more input. Similarly, if you close a move request, and lots of editors come out of the woodwork and say they would've participated had they seen it, then it should be clear that the discussion didn't necessarily capture the wider community consensus and should be re-opened. WP:RMRELIST is a process page, not a policy or a guideline, and it shouldn't be treated as prescriptive. --Ahecht (TALK
PAGE) 17:50, 16 July 2024 (UTC)

Maybe it is "common sense" but it's not the rule, and closes that are valid under the rule should not be overturned based on some amorphous notion of common sense. Also, for a discussion that has already been relisted once, or has been moribund for days, how long should we "wait for more input"? What is the signal that it is enough? BD2412 T 17:56, 16 July 2024 (UTC)

When no more comments are being made, and or the arguments are exclusively repeating themselves, then the closer can determine the strengths of differentΩ arguments rather than popularity of said arguments. ~ 🦝 Shushugah (he/him • talk) 18:51, 16 July 2024 (UTC)

We have seen discussions where that is exactly the case, but where the discussion once closed is still collaterally attacked for having been closed with too little participation, because the change was to a high-profile topic. BD2412 T 19:01, 16 July 2024 (UTC)

@BD2412 What rule are you referring to? And even if there were a rule, a rule being overturned based on some amorphous notion of common sense is exactly why we have WP:5P5 as a pillar and WP:IAR as a policy. --Ahecht (TALK
PAGE) 21:12, 16 July 2024 (UTC)

I am referring to the operations of Wikipedia:Requested moves that are laid out on that page. There is a process for proposing a move, a set time period for discussion, and a process for resolution of what has been proposed. There is no allowance there for declaring an article to be special for purposes of carrying out this process. BD2412 T 21:25, 16 July 2024 (UTC)

There doesn't need to be an allowance because that page is descriptive, not prescriptive. It is neither a policy nor a guideline. --Ahecht (TALK
PAGE) 02:28, 19 July 2024 (UTC)

In my extremely limited experience, the problem lies less with how long RMs are open and more with whatever smorgasbord of reasons causing move review to be unpleasant to closers (and potential closers). Even in less controversial RMs, there's an unfortunately non-negligible probability of some individual going to closer's talk, failing to articulate which significant evidence or fact was overlooked or WP:RMCI clause violated (per MR's instructions), ignoring any response by the closer that isn't acquiescence, and dragging the closer to MR, where the discussion remains open despite the giant "this is not the place to relitigate RMs" sign on MR's front door. Even if I snapped my fingers and RMs, effective immediately, have to be open for at least three months (like the I/P-related RM open since April), someone's going to come after closure at 3.5 months and argue I don't agree with it and didn't get a chance to voice my opinion so clearly it wasn't open long enough and not enough of the right people were notified, etc. What we need is a culture of compliance with and better enforcement of existing rules, so that RM closers have the support of the community and its norms when closing controversial RMs. If we do so in a way that helps people who are actually following the MR instructions by allowing the community to focus their resources on closures that actually need fixing, even better. Rotideypoc41352 (talk · contribs) 05:29, 18 July 2024 (UTC)

I agree with all of this. If in fact MR closers are reopening RM discussions based on these kinds of weak/irrelevant arguments, than there's an issue with how consensus is being evaluated at MR that needs to be addressed with the regular closers there. voorts (talk/contributions) 20:49, 18 July 2024 (UTC)

We also need people to relax a bit about these things. Some high-strung vitriol comes out over what amounts to a trivial matter, and one that can always be subject to a new consensus-testing process in the future. BD2412 T 21:04, 18 July 2024 (UTC)

This is an evergreen comment. voorts (talk/contributions) 21:08, 18 July 2024 (UTC)

• The people posing the question do have the option of using RFC rather than RM, giving a (minimum) 30 day discussion period.—S Marshall T/C 07:52, 18 July 2024 (UTC)
  • @S Marshall: They have the option of using RFC, yes, but there is no requirement for this. It remains permissible to use Wikipedia:Requested moves to propose even a move that is bound to be highly controversial, for a high-visibility subject, with substantial implications for incoming links. The friction is arising where that process has been used in its normal way, and people disagree with the outcome because the article to be moved was of that higher level of controversy. BD2412 T 21:07, 18 July 2024 (UTC)

    I thought RM was the exclusive forum for requesting moves. I think there'd be several valid procedural objections for using an RfC instead of RM. voorts (talk/contributions) 21:11, 18 July 2024 (UTC)

    • I believe we have used RFCs before where it proved impossible to reach a consensus as to a move target, and a broader rule needed to be established for the handling of the entire class of cases. BD2412 T 21:16, 18 July 2024 (UTC)

      The ongoing Wikipedia:Requests for comment/Titles of European monarchs, which while not a move request in and of itself, will be used as the justification for multiples moves pretty much regardless of what the outcome is. Thryduulf (talk) 21:45, 18 July 2024 (UTC)

• I voted to relist at that MR, but for the broader procedural question, I think the status quo is fine. The healthiest use case of MR is actually precisely this - when there's a close that is totally valid by the rules, but Other Stuff (TM) came up, and whoops it's time to IAR it. There's no need to change policy - 98% of closes can continue at a fast pace, and MR can quibble on the 1% of bad closes, and the 1% of times where a close was good but New Developments means that the close should be overturned anyway. That seems like a healthy ratio. SnowFire (talk) 21:58, 18 July 2024 (UTC)
  • The express purpose of MR is to determine whether the closer acted incorrectly, and expressly not to introduce new variables that should have been introduced in the initial move request. I see too many complaints of move requests not being extended from editors who could have extended it themselves while it was ongoing, too many complaints of lack of notification from editors who could have done some notifying, and too many efforts to relitigate the underlying issue rather than evaluating whether the close was within policy. BD2412 T 22:14, 18 July 2024 (UTC)

    To analogize to the legal space, an appellate court generally won't address (or will give more deference to the trial court) issues that weren't raised in the court below. MR is designed to review whether a close is reasonable—a pretty low standard—not to force the reopening of long and contentious RMs. voorts (talk/contributions) 22:30, 18 July 2024 (UTC)

    • Er, editors can't extend it? A relist is the equivalent of a close, so someone who's !voted shouldn't relist, since if they could there could be a naysayer's veto of the losing side just spamming relists. (They can obviously make "please extend this comments!" but there's no guarantee that they'll be heeded.)
    • And yes, MR is not RM round 2, but I don't think that's the case here nor is it accurate to portray it as such. Especially in cases where the issue is simply turnout, there isn't really a great need for "finality" or some such (that's what RFCs for if an issue is truly radioactive). Take the broader question. A nominator proposes a move, and it's largely ignored. 2 editors show up out of nowhere on Day 7 and !vote support. A closer sees this and reasonably closes as non-controversial and moves it. 99.5% of the time, the story stops there, it was indeed non-controversial. 0.5% of the time, people involved in the topic come out of the woodwork and say "whoa, that's not right." There is very little harm in letting a courtesy relist happen, so that's what the nominator should do to such a good-faith request, and they should be taken to MR otherwise. Maybe nothing changes, but maybe 20 other editors in the field pop up to say that the move was a terrible mistake. Who knows. But there is 0 harm in at least exploring the possibility of the latter case. (The other option is giving leave to file a new RM, of course, but then that might annoy !voters in the previous RMs who feel like they have to copy-paste their arguments to ensure their !vote "counts.") SnowFire (talk) 22:57, 18 July 2024 (UTC)
      • @SnowFire: There is no limitation provided as to who can relist a discussion, nor is there any policy that says that "a relist is the equivalent of a close", so, yes, any editor can relist the discussion, including one who has !voted. I think it's fairly obvious that an editor who spammed relists would get called out on that, and it is not a behavior that has occurred in practice. BD2412 T 23:04, 18 July 2024 (UTC)
        • That's not the case. See WP:RELIST: "Editor qualifications to relist a discussion are the same as required to close a discussion." Someone who has !voted can't close, so therefore they can't relist either. I agree that the behavior does not happen in practice, but that's because it's prohibited, and we should not encourage involved editors to perform a relist - they are not a neutral source for if a discussion has sufficient consensus for a close. (Oddly enough, a position I feel is closer to yours, in the name of making speedier closes!) SnowFire (talk) 23:09, 18 July 2024 (UTC)
          • Well, I've learned something new, then. As far as I recall, I have relisted discussions in which I was a participant on several occasions, usually because someone made a new proposal that was worth additional time to consider. I have never been criticized for so doing. BD2412 T 03:08, 19 July 2024 (UTC)
            • I'm sure your relists were fine, but point is we also shouldn't hold it against one side that they didn't force a relist themselves, because technically they shouldn't do that. SnowFire (talk) 10:26, 19 July 2024 (UTC)

No. Phil Bridger (talk) 22:59, 18 July 2024 (UTC)

Yes. High-profile, or previously contested, or technically complicated cases, all need a Rule that the next random nominator must point to and summarise the previous RMs, and mention technical issues.

The bad things to be prevented are a surreptitious move in a holiday period, or exhaustion of opponents allowing win by tendentious teamwork, or a consensus based on inadequate information.

Rules should be documented, YES!

Inadequate nominations should be speedy closeable for being inadequate. SmokeyJoe (talk) 04:11, 19 July 2024 (UTC)

I wonder if the rule that would be most useful might sound more like: If a consensus forms to move the page, and the result will require updating links in other articles, then no more than ____ articles may be updated per day (perhaps 50 or 100 per day, for the first week).

If you move the page, and the redirect stays in place, and someone complains (bad close, new information – the reason doesn't matter) and those complaints result in reversing the decision, then it's no big deal. You move the page back, and you're done.

If you move the page, and the redirect doesn't stay in place (e.g., gets converted to a DAB page), and the decision gets reversed, then you may need to update all of the linked pages, which can be a huge, watchlist-flooding task. Also, it's more likely to happen, because the watchlist flooding will attract attention and irritation to the recent move request. WhatamIdoing (talk) 21:33, 19 July 2024 (UTC)

Extent of WP:CHANGELOG

@HyperAccelerated entirely removed the "Version history" section of KDE Plasma. Upon being informed that DragonFly BSD had a similar section, they also removed it from that article, citing WP:CHANGELOG in both cases.

The policy specifically states against an "exhaustive" log and additionally encourages third-party sources. In both cases, third-party sources were used in addition to first-party sources. I believe that in general, the two version history sections were useful, although perhaps they did not need to be as detailed as they were.

How should this policy be applied? Blanket removal of the two sections seems a bit of an overreaction to me. iczero (talk) 16:33, 18 July 2024 (UTC)

The section that was on KDE Plasma strikes me as a good example of the kind of thing that WP:CHANGELOG is about - I would support that removal. It was an list of every version, many with little or no information on the contents. And the article also has prose sections on the major releases separate from the table, which serves as the 'summary of development' which WP:CHANGELOG suggests should be considered instead. MrOllie (talk) 16:39, 18 July 2024 (UTC)

@Iczero, I think the main problem is that different editors have different ideas of what "exhaustive" means, and that you would probably get a more practical answer from Wikipedia talk:WikiProject Computing.

One idea that I've had (wrt to previous disputes, because this happens several times a year) is that it would be helpful to have one or two Wikipedia:Essays that illustrate it. I imagine, for example, someone finding a freely licensed changelog for a notable open-source product, pasting the whole thing into the essay, and then saying "This is what exhaustive looks like" (a section that repeats the original almost in its entirety) and "This is what an encyclopedic summary looks like" (a good summary, with third-party sources) and perhaps one or two other examples (one that's borderline and one that's far too short to useful?).

In the meantime, it's possible that the short list at Wikipedia:Featured articles#Computing would contain a good example. WhatamIdoing (talk) 21:38, 19 July 2024 (UTC)

People like to cite WP:ALLCAPS links as justification for all sorts of things, including giant slash-and-burn edits that take out half an article.

WP:CHANGELOG was deliberately written to preserve articles like Android version history. The people who wrote it explicitly said they intended the policy to not be applied to those articles, or to prohibit articles from mentioning version histories.

The text was added sua sponte by this edit in February 2011, discussed at this talk page section, and its current wording arrived at by Wikipedia_talk:What_Wikipedia_is_not/Archive_45#WP:NOTCHANGELOG (consensus to retain here). At no point was the intention ever to remove them entirely -- again, the sole focus of the discussion that wrote the policy was how to preserve Android version history and articles like it. Given this, it seems like a rather tortured by-the-letter reading to invoke it while slashing out tens of kilobytes of text. jp×g🗯️ 12:19, 23 July 2024 (UTC)

Those past discussions and the current wording also requires the use of third-party (not self-published or official) sources which all these list fail as the use only the official sources, so they at least need improvement. -- LCU ActivelyDisinterested «@» °∆t° 12:31, 23 July 2024 (UTC)

Sure -- they aren't great -- but I don't think it's a reasonable basis for wholesale removal. How many versions are there listed in the table? Here are my two-minutes-and-no-flashlight pulled out of my keister search results:

References

jp×g🗯️ 13:23, 23 July 2024 (UTC)

Agree with MrOllie that KDE Plasma is definitely a good example of "bad" changelogs. The vast majority of it isn't cited to secondary sources and it reads as an exhaustive list of minor changes rather than high-level things, violating summary style guidelines to boot. As for "NOTCHANGELOG isn't supposed to apply to these articles" suggested above, NOTCHANGELOG applies to all changelogs. There's no carveout exemptions. You can argue it was crafted to make articles like Android version history compliant, but no articles get a pass from our content rules. Der Wohltemperierte Fuchs ^talk 12:33, 23 July 2024 (UTC)

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)

Notified: Wikipedia talk:Non-admin closure. voorts (talk/contributions) 02:59, 20 July 2024 (UTC)

A few thoughts.

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)

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)

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)

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)

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)

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

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)

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)

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)

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)

• 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)

  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)

  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)

  Sure. I meant contentious in the non-trademarked sense. Firefangledfeathers (talk / contribs) 22:19, 19 July 2024 (UTC)

• 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)

  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)

  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)

  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 Marshall T/C 18:11, 19 July 2024 (UTC)

  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)

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

  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)

  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)

  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)

• 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 Marshall T/C 07:58, 19 July 2024 (UTC)
• 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)
• 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)
• 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.

--SmokeyJoe (talk) 08:40, 21 July 2024 (UTC)

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)

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)

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)

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)

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)

Learning by doing is how Wikipedia works. WhatamIdoing (talk) 17:02, 20 July 2024 (UTC)

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)

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)

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.

- SmokeyJoe (talk) 08:54, 21 July 2024 (UTC)

Nobody can ever know in advance if their close will be controversial. Sometimes people get upset over the silliest issues. voorts (talk/contributions) 17:39, 21 July 2024 (UTC)

A few days ago, I said this, and I think it's apt here too.—S Marshall T/C 20:57, 21 July 2024 (UTC)

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)

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. Someone^TM getting upset over something silly is life, not controversy. SmokeyJoe (talk) 00:45, 22 July 2024 (UTC)

A topic of discussion can be controversial, but the outcome can sometimes be so obvious that the closure isn't challenged. For example, the recent RM for Gaza genocide. voorts (talk/contributions) 01:49, 22 July 2024 (UTC)

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)

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)

Stricter policy for unregistered ipv6 users vs ipv4 users

It is well established that unregistered (ip address) users are an important part of the Wikipedia community. However, a clear distinction can be made between ipv4 and ipv6, as the latter can be easily manipulated to create sock puppets and obscure other bad faith actions. The nature of ipv6 makes tracking, blocking, banning nearly impossible.

But the same is not true of ipv4 users, where the limited address space is a reasonable restraint, vs the virtually unrestrained nature of ipv6 unregistered users. Ipv6 creates a dense forest of ip addresses that bad actors can easily use to hide within.

I have personally experienced certain users (who are otherwise registered) logging out, and using a number of ipv6 addresses to harass and/or make bad faith edits. If unregistered users were restricted to ipv4 addresses, it would maintain access for unregistered users, while usefully hampering bad actors rolling through the nearly unlimited ipv6 addresses.

Of course, there should be no restriction connecting by ipv6 for registered user accounts.

Summary

Restricting only ipv6 unregistered users improves admin control, while not unduly hampering good-faith unregistered users' access to edit.  Myndex talk   09:27, 20 July 2024 (UTC)

Most people have no control over whether they use ipv4 or ipv6 addresses, and many who might have control won't know this. For most, the restriction would be completely arbitrary. There is also not a lack of harassment from ipv4s. CMD (talk) 10:01, 20 July 2024 (UTC)

Seems to unfair and unnecessarily discriminate against ipv6 users, who likely don't know they're ipv6 users, and can't control it. I don't know whether my IP is "ipv4" or "ipv6". I have noticed that some IP users are just numbers, like this: 40.7.211.792 or something, while some are more like 2f:00e::56a8:9000s. I assume that's the difference. Cremastra (talk) 10:22, 20 July 2024 (UTC)

You seem to have got the right idea. IPv4 addresses (like your first example) are usually expressed as 4 decimal numbers in the range 0-255 and are limited to about 4 billion in number, and IPv6 addresses are expressed in hexadecimal (base 16 with A-F representing the digits 10-15) with, in theory, over 10³⁸ addresses available, which means that they will "never" run out, in the same sense that IBM mainframes didn't run out of accessible memory with the increase in addressibility from 24 bits to 31 in the 1980s. Of course there's no need for the average encyclopedia writer to know or care about any of this. Phil Bridger (talk) 15:00, 20 July 2024 (UTC)

@CMD The user doesn't need control—any user's agent will use either ipv4 or ipv6, depending on the server connecting to. Wikipedia's servers could ask for ipv4 if an anonymous editor wanted to make an edit. And I am not suggesting banning nor blocking ipv6 addresses—only suggesting that ipv6 addresses be required to either log in or create an account. Perhaps temporary accounts might help.

An objective here is to prevent anonymous sock puppets. Perhaps there is a better method to require logging into some registered account from certain ip addresses. Myndex talk   10:04, 22 July 2024 (UTC)

• That's not how IPv6 users are treated, though. In effect, most IPv6 are allocated a /64 range of addresses (for example ABCD:EF12:3456:7890::/64) which is functionally equivalent to a single IPv4 address. When admins block or restrict IP users, they generally do this to the whole /64 range, not the individual IP (here's my blocking log, note the difference). Also note that we can extend that /64 to a wider range if necessary (there's a /32 in that list near the top). Therefore the differences between IPv4 and IPv6 are not a major issue. Black Kite (talk) 16:19, 20 July 2024 (UTC)

WP:LOUTSOCKing is a major pain for good faith IP editors, as it instills distrust towards them. But I don't see how tarring all IP editors using IPv6 addresses helps. Someone switching between different IPv6 /64 ranges is no different from someone switching between IPV4 addresses, and as Black Kite says there are methods for blocking ranges. -- LCU ActivelyDisinterested «@» °∆t° 16:26, 20 July 2024 (UTC)

Okay, but in practice ABCD:EF12:3456:7890::/64 does not seem narrow enough due I assume to DHCP/dynamic allocation at the ISP. YEs, this is still an issue with ipv4, but at the moment it doesn't appear that Wikipedia is grouping edits by only the first 64. And to be clear, I am not proposing that any ip address be blocked per se, only that certain IP addresses/ranges can be restricted to require login.  Myndex talk   09:46, 22 July 2024 (UTC)

In general on all but the busiest ranges you can go as wide as /48 and it will still be the same editor, so more than one editor in a /64 is unlikely. Anything wider than /48 and it's probably more than one editor. You can group edits simply by adding /64 or such to the end of the IP address in the contribution screen, it's not automatic but it only takes a second.

If IPv6 editors are required to create an account then they are blocked from editing as an IP. -- LCU ActivelyDisinterested «@» °∆t° 01:21, 23 July 2024 (UTC)

Isn't this all going to become redundant anyway when WP:Temporary accounts become a thing? Thryduulf (talk) 16:37, 20 July 2024 (UTC)

This (IPv4 v IPv6) isn't an issue IMO, but no it won't really, since any reasonably experienced editor (6 months tenure and 300 edits) will be able see the IPs behind the temporary accounts anyway. Black Kite (talk) 23:49, 20 July 2024 (UTC)

Inappropriate use of templates?

Is there anywhere on Wikipedia that details inappropriate use of templates? I have the feeling that {{rut}} and {{rus}} only exist to replace simple links, but I can't find a policy that outright forbids this. If I were to send those templates to WP:TfD, would they likely survive deletion? – PeeJay 14:08, 22 July 2024 (UTC)

{{rut}} and {{rus}} are redirects to other templates. Are you talking about these redirects (saving some typing vs their full {{Rugby union team}} and {{Rugby union stadium}} names) or those underlying actual templates? DMacks (talk) 12:58, 23 July 2024 (UTC)

I don't know where else to ask this & this might be a hornets' nest but here goes...

Recently there has been a spate of changes & reverts to the articles Martha Jefferson, John Wayles, Ulysses S. Grant National Historic Site, Sally Hemings and other articles concerning the usage of the terms "enslaved"/"enslaved persons" instead of "slaves". It is my understanding that "enslaved" & its associated terms are considered correct in modern usage as they describe a condition that could be considered reversible while the terms "slave"/"slaves" describe a person who is owned by another as that state of being and only as that state of being, plus the term being considered pejorative, etc. Do I have to open a Rfc for general usage of the terms "enslaved" to see if this is really the editorial consensus/Wikipedai accepted usage or whatever? It seems obvious to me that enslaved is preferred/accepted but there is disagreement over the usage. Not sure what to do and gawd help me RfCs can be such sinkholes of time & energy but then again I personally dislike long-simmering back&forth word-wrestling... Thanks, Shearonink (talk) 13:40, 23 July 2024 (UTC)

You mean we've actually not had one or several Rfc:s on this already? Gråbergs Gråa Sång (talk) 14:48, 23 July 2024 (UTC)

Fwiw, here's one previous discussion: Wikipedia_talk:Manual_of_Style/Words_to_watch/Archive_10#"Slaves"_versus_"enslaved_persons". I see there's no MOS:SLAVE atm. There is a WP:SLAVE, but it doesn't really help this discussion. Gråbergs Gråa Sång (talk) 14:51, 23 July 2024 (UTC)

One comment from that Words to watch discussion from HighinBC really stuck out to me:

"I say use the wording that is most common in the reliable sources the article is based on." I'm not sure I quite agree with it completely but it sure would stop any long-simmering edit wars over wording choices. - Shearonink (talk) 15:09, 23 July 2024 (UTC)

This is best starting point imo. Whether "slave" or "enslaved person" is preferable (and in most cases it will be a preference, not correct vs incorrect) will depend on the usage in reliable sources relevant to the topic area and is likely be context dependent. Thryduulf (talk) 15:17, 23 July 2024 (UTC)

Here's another discussion: Talk:Confederate_States_of_America/Archive_21#h-Request_for_comment:_"slaves"_vs._"enslaved_people"-2022-02-14T01:30:00.000Z. Gråbergs Gråa Sång (talk) 15:03, 23 July 2024 (UTC)

And some more.

• Talk:John_Adams/Archive_5#Request_for_Comment:_Should_the_article_on_John_Adams_refer_to_people_held_in_slavery_as_"enslaved_people"_or_"slaves"?
• Talk:History_of_slavery#"Enslaved_people"
• Talk:Zong_massacre#Slaves_vs_enslaved_people
• Talk:George_Washington_and_slavery/Archive_3#Using_“slave”_&_“slavery”_instead_of_“enslaved_person”_&_“enslavement”

Gråbergs Gråa Sång (talk) 15:07, 23 July 2024 (UTC)

We've not had a consensus for a strong preference either way regarding people-first language. Some consider the noun terms pejorative and prefer the adjective terms for that reason, other do not. On the related topic of disability, MOS:EUPHEMISM notes the priority is clarity of understanding. It links to the Wikipedia:WikiProject Disability/Style advice essay, which prefers people-first language where possible and clear but notes a mixture is fine. CMD (talk) 15:31, 23 July 2024 (UTC)

WP:SUFFER addresses person-first language in medical contexts. However, changing "slaves" to "enslaved persons" is not, strictly speaking, a case of person-first language.

I'm not sure that we need to have a single rule for all articles. I think that edit warring to enforce the retention of the older style of wording (i.e., to put slaves back in the article because that's the language used in history textbooks when some of us were kids) is inappropriate, but I think editors should be using their judgment instead of of imposing a one-size-fits-all rule on all articles. One should hesitate to label the American abolitionists Harriet Tubman or Frederick Douglass as 'slaves'; however, one might not have the same feeling about using that term for, say, Sicinnus from the 5th century BC or Spartacus of the 1st century CE. WhatamIdoing (talk) 18:19, 23 July 2024 (UTC)

Meh… Spartacus was born a free person and was subsequently “enslaved”. At which point he became a “slave”.

Tubman and Douglas were born in a condition of slavery, and thus were “slaves” until they gained their freedom. They used that term about themselves. Blueboar (talk) 00:56, 24 July 2024 (UTC)

Neither of your statements are arguments unto themselves. Need I explain how the latter argument falls apart especially quickly? Remsense诉 00:59, 24 July 2024 (UTC)

I wasn’t trying to make an argument either way, but noting that the words “enslaved” and “slave” are contextual. That said, a personal observation: When I see the term “enslaved”, I tend to assume it is referring to first generation slaves (ie those who were free, but then captured and… enslaved) and not to those born into slavery. That may be because I see “enslave” used more as a verb, rather than a noun. Blueboar (talk) 14:12, 25 July 2024 (UTC)

Agreed. See the Cambridge dictionary: en- "used to form verbs that mean to put into or onto something" or "used to form verbs that mean to cause to be something". Examples: encircle = "to put into a circle" or enlarge = "to make large". To enslave is to make someone into a slave and the past participle enslaved revers to someone who has been made into a slave. Martin of Sheffield (talk) 14:49, 25 July 2024 (UTC)

Someone born into slavery is enslaved by those who take advantage of the law. Alanscottwalker (talk) 14:56, 25 July 2024 (UTC)

No. The essence of "en-" is the "putting into" or "causing to be". A child born into slavery is not put into slavery, from the moment of birth (possibly conception?) they are already a slave. Just as a mare's foal belongs to the breeder from birth, the breeder does not acquire the foal. It's ugly, vicious and cruel, but then does any modern person not think that slavery is not ugly, vicious and cruel? Martin of Sheffield (talk) 15:56, 25 July 2024 (UTC)

No. Chattle slavery cannot exist without the owner, it is their assertion of the property interest that places the child into slavery. Alanscottwalker (talk) 16:05, 25 July 2024 (UTC)

This is unnecessary for the same reason we have WP:EUPHEMISM. Ngrams isn't the be-all end-all, but it's telling. This effort to erase the word "slave" gives the whiff of WP:ACTIVIST/WP:ADVOCACY/WP:RIGHTINGGREATWRONGS/whathaveyou. The discussions provided by Gråbergs Gråa Sång seem to indicate that the community broadly agrees. Thebiguglyalien (talk) 19:01, 24 July 2024 (UTC)

Agree with Thebiguglyalien. As I have said before, these WP:EUPHEMISMS are verbose and unecessary, and definitely have a tinge of WP:ADVOCACY-style editing. I'm not categorically opposed to them, but I'd like to see a lot more evidence that this term is becoming standard, and I'm not seeing that in common speech or most sources. Let's not put the cart before the horse – wait and see if this is a new and widely-used term, or another short-lived part of a new mild euphemism treadmill. Cremastra (talk) 00:16, 25 July 2024 (UTC)

Enslaved person or person who was enslaved is not a euphemism. Nothing's being covered up here. Something like involuntary migrant or involuntary worker could be a euphemism. Servant was a euphemism popular with white Americans in the 17th and 18th centuries, because it hid the ugly facts behind a veneer of normalcy (JSTOR 26361869). WhatamIdoing (talk) 00:57, 25 July 2024 (UTC)

Also, https://www.theatlantic.com/magazine/archive/2023/04/equity-language-guides-sierra-club-banned-words/673085/ says that "enslaved person has generally replaced slave", so apparently it's already a widely used term. It is not, however, new in any sense. It's been in use for more than two centuries, as you can see from a quick search in Google Books. WhatamIdoing (talk) 01:05, 25 July 2024 (UTC)

That's an opinion piece that sources its claim to another opinion piece. Thebiguglyalien (talk) 01:13, 25 July 2024 (UTC)

I hope you are not expecting a randomized controlled trial over word choice. WhatamIdoing (talk) 03:33, 25 July 2024 (UTC)

We should avoid taking American sources as indicators of global usage. CMD (talk) 01:14, 25 July 2024 (UTC)

True, but part of the complaint is that this change is only being seen in articles about American people. See, e.g., the recent complaint from @Clintville at Talk:Martha Washington that an article about an American subject, using WP:AMENG, shouldn't use the language popular in American sources because "It also makes no sense that the new term is only used in regards to American slavery. No one is changing the articles on Spartacus or the Ottoman Empire."

Since the word choice is only affecting American subjects, and the articles are written in American English, I think it's perfectly reasonable and normal for us to be consulting American sources about what's common or appropriate for them. WhatamIdoing (talk) 03:37, 25 July 2024 (UTC)

Sure, just a note worth keeping in mind as the opening post is a discussion on "general usage", and this factor is often overlooked. It may even be the case that American English common usage differs between Marth Washington and Spartacus. CMD (talk) 03:42, 25 July 2024 (UTC)

To me it gives off more of a feeling of trying to hide great wrongs. Advocates of "enslaved person" keep saying that calling someone a "slave" is dehumanizing. Well, duh. THAT WAS THE FREAKING POINT OF SLAVERY!!! Calling someone a slave hits the reader in the face with the fact that these people were seen as and treated as no better than garden tools. Calling someone an enslaved person covers all that up in a feel good bandage of "ain't we so much better now?". The past was UGLY. Which is why we need to look at it directly. --User:Khajidha (talk) (contributions) 11:43, 25 July 2024 (UTC)

Well, if anything was UGLY, surely it was enslaving others. It also makes little sense that you suggest the purpose is to make the present feel better, but what really you want to say is the past is UGLY. -- Alanscottwalker (talk) 12:49, 25 July 2024 (UTC)

The way slaves were treated depends greatly on time and place. Contrast the laws regarding slaves in the Tanakh (Hebrew Bible) with the way slaves were treated in the American South. None of those societies treated slaves well, but some were worse than others. And, no, the word does not imply a permanent condition. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:58, 25 July 2024 (UTC)

Um, yes that was the point of slavery; it is not the point of the language we use today. During slavery, they were property. Retrospectively, they can be actual people. The language shift is to highlight it was something done to them and didn't define them as a person. We're not writing fiction or Django Unchained such that we must retain the language used at the time for emotional resonance. We're trying to be as specific as possible in describing subjects. — Rhododendrites ^talk \\ 15:49, 25 July 2024 (UTC)

It's perfectly fine to call them enslaved, it's neither wrong nor anything else (in particular it is not euphemism) but a choice, whether we have a rule about it seems unlikely, except perhaps a modified type of ENGVAR procedure. Alanscottwalker (talk) 12:34, 25 July 2024 (UTC)

Just to add something related to the NGRAMS link: "slave" is a flexible term in English that is far more often used colloquially or metaphorically (slave to fashion, slave away at work, master/slave computers, treats X like a slave, etc.), so NGRAMS aren't going to be useful to identify trends in [the word referring specifically to the type of slave we're talking about]. That might in itself be a [weak] reason to go with some version of "enslaved person" -- because it's unambiguous. — Rhododendrites ^talk \\ 15:49, 25 July 2024 (UTC)

Discussion at Wikipedia talk:Criteria for speedy deletion § RfC: enacting C4 (unused maintenance categories)

 You are invited to join the discussion at Wikipedia talk:Criteria for speedy deletion § RfC: enacting C4 (unused maintenance categories). HouseBlaster (talk · he/they) 03:11, 25 July 2024 (UTC)

The header for this page

The top of this page (i.e., [Wikipedia:Village pump (policy)] ) says:

The policy section of the village pump is used to discuss already proposed policies and guidelines and to discuss changes to existing policies and guidelines.

This has probably been here for years, and it's basically true. However, in the last couple of years, I've seen a few editors claim that because of this sentence, you're not allowed to discussion changes to existing policies and guidelines on the talk pages of those policies or guidelines. That is, if you want to change, e.g., a sentence in WP:V, those editors, citing this sentence, genuinely believe that you really shouldn't discuss those changes at Wikipedia talk:Verifiability, and instead you either should or must discuss them here.

The relevant policy (the WP:PGCHANGE section of the Wikipedia:Policies and guidelines policy) prefers the talk page of the relevant policy, though the venue for a discussion is not absolutely mandatory. Huge discussions like Wikipedia:Verifiability/First sentence need their own pages, and the point behind the RFC system is to bring editors from all over to the location of the discussion, even if it's otherwise "hidden" on some low-traffic page. See Wikipedia talk:Policies and guidelines#Venue if you're interested in more details.

I'd like to adjust this sentence to still be truthful, while removing any suggestion that this is the primary venue for discussion about changes to a policy or guideline. I'm not sure how to do it, however. Perhaps something like "The policy section of the village pump is one of several venues used to discuss..."? Or "The policy section of the village pump is used to discuss some..."?

What do you think? WhatamIdoing (talk) 03:56, 25 July 2024 (UTC)

Is this really a widespread problem, or is it just a handful of people? If it's the latter I think we'd do better to educate or WP:TROUT those few people who insist on misinterpreting the existing sentence, which already doesn't make any claim to this being the only (or even a preferred) place for such discussions. Anomie⚔ 11:37, 25 July 2024 (UTC)

I’d support instructions to make trouting of such people mandatory 🐠 ~ 🦝 Shushugah (he/him • talk) 12:55, 25 July 2024 (UTC)

It's not necessarily fair to trout people for believing a literal reading of the written directions, especially since we have a large number of autistic editors (and young autistic editors – I saw one the other day who still believes that Santa Claus is real). WhatamIdoing (talk) 15:35, 25 July 2024 (UTC)

User pages and Displaytitle

I came across User:Allninemice/sandbox which not only hides the user namesapce from the title, but completely changes the title to "Anime". While this is a sandbox page, this also happens in the main userspacee (see User:Bernardwebb357). Is this a valid use? Gonnym (talk) 08:27, 25 July 2024 (UTC)

imo, no. The only reason the title should be altered is for minor formatting (e.g. italics, lowercase first letter) or to workaround technical limitations (but even in the latter case we tend not to, e.g. at MeToo movement). Thryduulf (talk) 08:51, 25 July 2024 (UTC)

• Wikipedia:User pages#Simulation and disruption of the MediaWiki interface could be used here, though I wouldn't worry about sandboxes much. — xaosflux ^Talk 09:06, 25 July 2024 (UTC)

Copyvio revdel question

Recently 37 revisions of the article Puberty blocker were revdeled in order to roll back the article to its state prior to a minor copyright violation. The non-copyvio content that was added in those 37 revisions, which included entirely new sections of the article, was then restored in a single new revision. While this isn't as problematic as a copy-paste move, it entails some of the same problems. Namely, it is no longer possible to see which editors contributed which content without asking an admin. I have two questions:

1. Does this cause any legal issues with our license compliance?
2. Is this practice a good idea? It seems like overkill that causes more problems than it solves. Why not just delete the copyvio material and move on?

Nosferattus (talk) 02:31, 26 July 2024 (UTC)

Re question 2. Revision deletion (and suppression) work on whole revisions only, so if problematic content is added in say revision 10 and not removed until revision 20, we have to delete (or suppress) all of revisions 10 to 19, even if the intermediate revisions added no problematic content (or indeed were entirely unrelated). This means the only options for dealing with such content are

1. Remove the problematic content then delete (or suppress) all the revisions between insertion and removal
2. Roll-back the article to the last revision before problematic content was added, delete (or suppress) all the revisions between insertion and removal and then re-add the good content.

Given that the effect of both options is identical for practical purposes which is best depends on the circumstances. If you have a particular desire to know who added what then diffs (minus any interaction with the problematic content) can be copied somewhere for reference by an admin (or oversighter if material has been suppressed rather than just revision deleted) but this is quite a bit of work so not something we do routinely (I've been an oversighter for nearly 10 years and can recall being asked this sort of question perhaps 2-3 times at most during that time).

I'll leave a definitive answer to question 1 to those more qualified than me, but my gut feeling is that if it did cause legal issues something would have been done about it before now as this hasn't changed since I became an admin in 2005 (although revision deletion was introduced during this time, the old method of deleting the whole page and restoring only the good revisions produced an identical output). Thryduulf (talk) 02:57, 26 July 2024 (UTC)

I once proposed using XML imports to rebase edits to avoid this problem in situations like this. The idea was shot down by pretty much everyone. * Pppery * _{it has begun...} 03:16, 26 July 2024 (UTC)

@Thryduulf: So if the 1st revision of the article philosophy was a copyvio that had persisted until the present day, would we revdel the entire history? What's wrong with just removing the copyvio? Surely retaining the article's version history would pass as fair use. Nosferattus (talk) 03:34, 26 July 2024 (UTC)

Regarding the licensing question: Creative Commons Attribution-ShareAlike license requires attribution, but not traceability of each word to a specific author. This would be difficult in any case for copy-edited passages, or rewrites that were based on previous versions. isaacl (talk) 02:57, 26 July 2024 (UTC)

Wikipedia:Attribution does not require blame will probably be of interest. —Cryptic 03:13, 26 July 2024 (UTC)

Technical

Bot activity problem

DannyS712 bot, a bot which is supposed to look after various daily or weekly maintenance tasks, hasn't made any edits since July 1, including failing to update Wikipedia:Database reports/Polluted categories (2) in eleven days despite that being a thing that's supposed to happen weekly, but the bot's maintainer says on their own userpage that they're not around much lately, and they haven't made any Wikipedia edits at all since July 3, so there's no way to know when they'll be back in order to look into it if I approach them personally (especially in July, when any editor could very well be on vacation for a couple of weeks). So could somebody take a quick gander into whether there's a problem with the bot, and maybe jumpstart it again if there is? Thanks. Bearcat (talk) 15:53, 12 July 2024 (UTC)

@DannyS712 is pretty active in other areas of the wikiverse and I suspect they will see this ping. It certainly doesn't hurt to try. https://toolsadmin.wikimedia.org/tools/id/dannys712-bot states they are the only maintainer, so there's nothing anyone can do to help (unless they are a Toolforge admin). — MusikAnimal ^talk 19:48, 12 July 2024 (UTC)

It's a straightforward query without any postprocessing, so if DannyS712 doesn't respond or can't easily fix whatever's gone wrong, the report can be run at will on Quarry and it'd be trivial to migrate the WP:DBR subpage to {{Database report}}. —Cryptic 20:08, 12 July 2024 (UTC)

I saw the ping, and have been meaning to get to this, but am aware of the issue - hopefully I'll have time this weekend, and sorry for the delays --DannyS712 (talk) 21:07, 12 July 2024 (UTC)

I'm not sure if DannyS712 got to it this weekend and the bot just hasn't run yet, but if he didn't get to it, feel free to copy over my sandbox which has {{Database report}} set up correctly. (cc @Bearcat) --rchard2scout (talk) 07:18, 15 July 2024 (UTC)

DannyS712 has written a ton of great code done so much to help enwiki. -- GreenC 15:48, 15 July 2024 (UTC)

Nobody said otherwise. The problem is with a bot not functioning properly for purely technical reasons, and absolutely nobody accused Danny of anything improper. Bearcat (talk) 14:39, 20 July 2024 (UTC)

I guess I just got the weekend wrong, I was out of town for a while - I definitely should have time this week, maybe even tomorrow DannyS712 (talk) 02:40, 21 July 2024 (UTC)

No worries. I was able to use the substitute on-the-fly report provided above to work around the bot issue, so the delay hasn't been a major crisis. Bearcat (talk) 14:04, 21 July 2024 (UTC)

Bot has been restarted --DannyS712 (talk) 00:05, 26 July 2024 (UTC)

WMF sabotage?

I assume that since loads of stuff has stopped working with every skin except Vector (2022), this is a deliberate way of forcing editors to switch to it even though no one wanted it in the first place. Nice call! ——Serial Number 54129 09:58, 15 July 2024 (UTC)

I see no sign of that. If you tell us your skin and what isn't working then maybe we can help. PrimeHunter (talk) 10:05, 15 July 2024 (UTC)

Of course PrimeHunter, and apologies to WMF for the hyperbole. but it's blooming odd. I haven't touched my scripts for over a month—I know there's probably too many!—but over the last week (not sure absolutely since when), One-Click Archiver and Discussion Closer have disappeared from where they used to be. I noticed the latter's absence earlier when I tried to close a discussion. Tried all the available skins in preferences, the two scripts were missing in all of them except Vector 2022. Coincidence? Hence my outraged squawks of sabotage  :) I'm using Vector 2010 btw. ——Serial Number 54129 11:01, 15 July 2024 (UTC)

@Serial Number 54129: That is, indeed, catastrophically egregious. Have you considered using User:Elli/OneClickArchiver.js and/or molotov cocktails? Polygnotus (talk) 11:39, 15 July 2024 (UTC)

Both scripts should have been updated for changes that have been communicated multiple times in the Tech News newsletter, scripts without active maintainers aren't the responsibility of the Foundation. Sjoerd de Bruin (talk) 12:09, 15 July 2024 (UTC)

Serial Number 54129, these are symptoms of a recent change in the HTML markup of headings, which you can see more about at mw:Heading HTML changes, and these scripts having inactive maintainers. There are new versions of the scripts you mention at User:DaxServer/DiscussionCloser and User:Elli/OneClickArchiver. Curbon7 (talk) 12:33, 15 July 2024 (UTC)

It's so complicated![/MOANS] I deal with it now. Thanks for all your help, @PrimeHunter, Sjoerddebruin, and Curbon7: and I guess you too Polygnotus :p ——Serial Number 54129 12:43, 15 July 2024 (UTC)

@Serial Number 54129 The good news is that all this stuff will break for Vector 2022 in the near future as well. The markup changes that broke those scripts was implemented on older skins first, but will be implemented on Vector 2022 in MediaWiki 1.44. --Ahecht (TALK
PAGE) 14:39, 15 July 2024 (UTC)

Serial Number 54129, I've already had to updaye one of my scripts to work in Vector 2022 because of some html change, not sure if that's related. — Qwerfjkltalk 16:05, 15 July 2024 (UTC)

Absolutely unacceptable opening comment. I just have to say it. F'ing 100k edits lets people get away with this shit I guess. —TheDJ (talk • contribs) 18:11, 15 July 2024 (UTC)

Yeah, this is ridiculous. How is "WMF sabotage" appropriate in any circumstance? @Serial Number 54129, if you were serious when you said "apologies to WMF for the hyperbole", you should've changed the section heading and struck your initial comments. Legoktm (talk) 04:49, 21 July 2024 (UTC)

Hey TheDJ, hey Legoktm here I am, for your delectation :) *waves* ——Serial Number 54129 21:23, 21 July 2024 (UTC)

@Serial Number 54129 I do not appreciate my good-faith efforts to improve the software you use being described as "sabotage". Matma Rex talk 16:59, 22 July 2024 (UTC)

The title of this thread is rather hyperbolic, but there is something to be said about how this breakage came to be. Wikipedia depends on hundreds (if not thousands) of add-on front-end scripts (and other back-end tools) to do essential work. I don't think it's hyperbolic at all to say that if all these tools were to suddenly stop working, it would be very difficult to keep things going. These tools depend on navigating (and in many cases, modifying) the structure of a rendered page. As such, the structure of the HTML is an essential API, just as much as any of the other documented APIs. The problem is, it's not documented. And as we've seen here, it's subject to change with little or no notice, breaking stuff willy-nilly. That needs to change. RoySmith (talk) 14:29, 15 July 2024 (UTC)

All changes like this are clearly communicated wide ahead. That users keep using outdated scripts (or fork a existing script and never process the upstream changes) and we as the community have no way to force them to switch to a maintained version (or gadget) is a huge problem in the longer term. Sjoerd de Bruin (talk) 14:53, 15 July 2024 (UTC)

(edit conflict) The issue here isn't little to no notice. The notice was given in Tech news updates and I had seen in the passing some repeated pings and conversations (or attempts to do so) on the various talk pages with the maintainers. Some of these userscripts as noted by some above were abandoned or maintainers not being active.

If anything, we should look at how the userscript system is being set up (by limitations of the software) to be dependent on bus factor of 1 editor, the maintainer to have the userscript updated. Are INTADMINS empowered to update these userscripts? If so, is having 9 INTADMINs (at the current count) sufficient to update and maintain the userscripts or even redirect these outdated userscripts to the updated ones when asked? – robertsky (talk) 14:56, 15 July 2024 (UTC)

Is there a centralised place that lists all the common userscripts and who runs them? I think such a list might be helpful to track this sort of thing. Especially if you add maybe a "Last updated" + "How many editors use it" column. If a script is not updated and it falls behind, it's much easier to follow along or maybe notify editors. Soni (talk) 15:06, 15 July 2024 (UTC)

For most used, see Wikipedia:User scripts/Most imported scripts. Sjoerd de Bruin (talk) 15:08, 15 July 2024 (UTC)

For a general list see Wikipedia:User scripts/List – robertsky (talk) 15:09, 15 July 2024 (UTC)

It's a pretty common problem with volunteer-written software. People often aren't great at succession planning, particularly when there is no financial incentive. Having the software be open source and thus available is probably good enough for small scripts. Once the tools become more elaborate, possibly with off-wiki build systems using languages other than Javascript, something more definite would be better. But it's a tradeoff: in the spirit of empowering anyone to build their own personal tools that can also be used by others, the community doesn't require any approvals that might be contingent on a long-term sustainable setup for maintenance (after all, the vast majority of scripts like the ones I wrote aren't ever going to need that). Human nature being what it is, it's hard to get backup developers ready unless they actually start taking over some of the development. But working in a team means some slowdown in development to co-ordinate and collaborate, though with the eventual benefit that there will be more redundancy in developers able to make fixes and enhancements. isaacl (talk) 16:25, 15 July 2024 (UTC)

There is seldom a backlog (see User:AnomieBOT/IPERTable) of ready-to-go bug fixes on abandoned user script pages. It is not up to intadmins to maintain the programming of everyone's personal scripts, but we will process bugfixes if the script owner has abandoned the project. In general, editors should never assume that another editor will make a future edit and could abandon or change their own personal scripts at anytime. — xaosflux ^Talk 18:27, 15 July 2024 (UTC)

Anyone reading this may be interested in this phab ticket for a "Gadget API for adding buttons to section titles". — Qwerfjkltalk 16:07, 15 July 2024 (UTC)

Yeap. I was just going to drop a link to the phab ticket you linked, thanks for linking it. The ideal workflow would have been to create this API first, THEN start deploying mw:Heading HTML changes. And anything that broke could be converted to the new API. But unfortunately that didn't happen. So now I have just been waiting for them to finish the staggered rollout, which will finally complete this Thursday July 18. At that point we can fix any remaining broken scripts. These scripts could have been fixed during the staggered rollout, but patching it to support 2 types of selectors is more complicated than just waiting for the rollout to finish, so the ideal time to fix all these is when the rollout is finished on Thursday. –Novem Linguae (talk) 21:47, 15 July 2024 (UTC)

Oof. An implemented phab:T337286 would have saved a lot of time spent on (mostly duplicate) work for userscript maintenance in Wikipedia:Village pump (technical)/Archive 213#Heading markup changes. —⁠andrybak (talk) 07:52, 16 July 2024 (UTC)

Probably worth posting this on the wishlist. If more gadget developers are asking for an API, it makes an easier case for prioritizing it. 🐸 Jdlrobson (talk) 23:08, 18 July 2024 (UTC)

Mediawiki errors

Tracked in Phabricator
Task T370304

Has anyone else been experiencing MediaWiki errors? I tried a few projects and got them across the board. I hope it's over now. ꧁Zanahary꧂ 00:18, 19 July 2024 (UTC)

I was also getting an error. I don't remember the exact error but it did start with MediaWiki: Wikimedia\Rdbms\[error name] I think it was DBUnexpectedError J2UDY7r00CRjH (talk) 00:23, 19 July 2024 (UTC)

I get this:

MediaWiki internal error.

Original exception: [34ac1401-8578-4b58-a1be-36b1278fa8bf] 2024-07-19 00:14:57: Fatal exception of type "Wikimedia\Rdbms\DBUnexpectedError"

Exception caught inside exception handler.

Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.

It has been happening on and off for about 10 minutes. PrimeHunter (talk) 00:28, 19 July 2024 (UTC)

I got that when I was previewing an edit, and another time when (IIRC) I just visited a user page. ClaudineChionh (she/her · talk · contribs · email) 00:32, 19 July 2024 (UTC)

Help, I'm drowning. It keeps happening every edit I make! The edits do seem to go through though, so there's that. Silverseren^C 00:44, 19 July 2024 (UTC)

I cannot make this edit logged in. I got the error several times, changed my theme to Minerva, changed my theme to Vector 2022, and now cannot open any page while logged in. It's fine (I think?) logged out, and the Android app works but can't post to this page, 2600:1702:1C50:1360:18FA:42C0:F510:BE6A (talk) 00:48, 19 July 2024 (UTC)

I have the exact same problem. 2001:BB6:3084:2658:F14B:6D9A:F011:5C09 (talk) 00:53, 19 July 2024 (UTC)

I am getting this too. I was not happening earlier today (Two hours ago). Looks like WP:THURSDAY. Hawkeye7 (discuss) 00:52, 19 July 2024 (UTC)

• It's not letting me delete any pages or posts responses to talk page comments. Frustrating. Liz ^{Read! Talk!} 00:56, 19 July 2024 (UTC)

  except for this one. Liz ^{Read! Talk!} 00:57, 19 July 2024 (UTC)

  The discussions I initiate are particularly robust and bugs know to leave them alone, out of reverence and disinterest. ꧁Zanahary꧂ 01:01, 19 July 2024 (UTC)

  The last page deleted happened at 00:22 UTC which was 50 minutes ago. Liz ^{Read! Talk!} 01:02, 19 July 2024 (UTC)

  Okay, some functionality for admins has returned. Liz ^{Read! Talk!} 01:05, 19 July 2024 (UTC)

I had three almost identical messages like these, with different exception codes:

• [f1541cf5-6bd5-4dac-bb64-7cff625c7692] 2024-07-19 00:40:42
• [ec5f67e0-1672-48da-8f70-a53aecdb9ad3] 2024-07-19 00:42:17
• [18674d8b-749c-40be-9138-0eba30011100] 2024-07-19 00:46:26

In between edits #1 and 2, I managed to save one edit. In trying to publish this edit, I got 1 2 3 more of these. Mathglot (talk) 00:56, 19 July 2024 (UTC)

Fyi, exception codes are always different. One per page load. Even if the error msg is the same. I think they correspond to error log entries. –Novem Linguae (talk) 19:58, 19 July 2024 (UTC)

Same, so dead. Can't navigate, edit, or view hardly any page when logged in without getting that error/warning page. Hope this gets fixed soon. 2606:A800:CD82:9700:1DE4:7632:6615:835C (talk) 00:57, 19 July 2024 (UTC)

Yeah, I'm the same. I can't do anything when logged in. The iOS app appears to be working fine though. 2001:BB6:3084:2658:F14B:6D9A:F011:5C09 (talk) 00:59, 19 July 2024 (UTC)

https://phabricator.wikimedia.org/T370304. Nurg (talk) 01:03, 19 July 2024 (UTC)

I'm the user who mentioned the iOS app above. Everything appears to be working okay now. Bertaut (talk) 01:06, 19 July 2024 (UTC)

I was about to ask whether anyone else had seen these errors. I don't think that I need to ask the question. It appears to have been resolved.

The question now is what happened and whether a recurrence can be prevented. Robert McClenon (talk) 02:36, 19 July 2024 (UTC)

According to some logs on IRC the database serving S4 (Commons) went down. For reasons I don't quite understand that caused pages with no relation to Commons to fail. Probably the devs will write up some docs on what happened soon. * Pppery * _{it has begun...} 19:24, 19 July 2024 (UTC)

• The IP information tool appears to be down, showing only "The IP information could not be retrieved." I wonder if that's related. CMD (talk) 08:00, 19 July 2024 (UTC)

  Not related. * Pppery * _{it has begun...} 19:24, 19 July 2024 (UTC)

  phab:T363118 –Novem Linguae (talk) 19:57, 19 July 2024 (UTC)

  Aww, I really hoped it was not the previous April/May issues. CMD (talk) 03:32, 20 July 2024 (UTC)

• Idea: 2024 CrowdStrike incident. I hope not, because that would mean that we depend upon Microsoft. --Redrose64 🌹 (talk) 19:14, 19 July 2024 (UTC)

  No, not related. * Pppery * _{it has begun...} 19:24, 19 July 2024 (UTC)

I thought I'd lost two or three hours of work on Timeline of the attempted assassination of Donald Trump, i.e. the entire new article. When I set about to begin it anew this morning, lo! It was all there! Passingly strange and a P.I.T.A. kencf0618 (talk) 16:59, 20 July 2024 (UTC)

• I'm seeing this problem again. It's not letting me post some talk page messages. Let's see if this gets posted. Liz ^{Read! Talk!} 01:23, 21 July 2024 (UTC)

  Weird, my message gets posted but I still am receiving error messages at the same time as if it didn't post. Liz ^{Read! Talk!} 01:24, 21 July 2024 (UTC)

  I'm experiencing this occasionally still. It could be a caching issue on my end from earlier errors I experienced this morning, though. Frustrating. Thankfully my talk page messages still seem to go through (eventually). GhostOfNoMeme 13:01, 21 July 2024 (UTC)

• I currently can't open any pages while logged in. My account is basically disabled because of this. Are there any updates? 95.164.181.95 (talk) 01:28, 21 July 2024 (UTC)

Folks are on it

I'll just note that the phab ticket is currently marked "Open, In Progress, Unbreak Now!". Translating from techno-speak, that basically means, "We know about it, we're working on it, and it's our highest priority issue at the moment". So we should just get out of their hair and let them work on it. RoySmith (talk) 16:47, 21 July 2024 (UTC)

And it's the weekend so while some of WMF's site reliability engineering team remains on-call to deal with outages probably fixing things is a higher priority than reporting the incident. * Pppery * _{it has begun...} 17:40, 21 July 2024 (UTC)

Error message

MediaWiki internal error

What does this mean? — Maile (talk) 01:30, 21 July 2024 (UTC)

See #Mediawiki errors. It means that things beyond your control are down, and there's nothing you can do about. The WMF people responsible for fixing the issue have already been notified. * Pppery * _{it has begun...} 01:36, 21 July 2024 (UTC)

Thanks for the quick reply. At least I know I didn't trigger it. — Maile (talk) 01:39, 21 July 2024 (UTC)

What's going on? I'm new here and could use some help.United StatesẂÈĎ

§ᛵᛠᙱᙳ@Maile66@Pppery Will;Draku (talk) 08:21, 21 July 2024 (UTC)

MediaWiki internal error.

I have been getting repeated "MediaWiki internal error.

Original exception: [d0d3b60c-5f72-4e07-ae15-3451f56eefcf] 2024-07-21 21:00:09: Fatal exception of type "Wikimedia\Rdbms\DBUnexpectedError"

Exception caught inside exception handler.

Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information."

messages tonight, had them last night too. the bit inside the square brackets changes each time. Happens when I click on a page link on my watchlist. Edge on Win11, also happens on Chrome on Android. DuncanHill (talk) 21:07, 21 July 2024 (UTC)

I just had this, I would assume this is the same as #Mediawiki errors, although https://www.wikimediastatus.net/ is showing something happened.Terasail^[✉️] 21:11, 21 July 2024 (UTC)

Only affects me while logged in. It's surreal looking at Special:Recentchanges and seeing a page full of only ip edits. —Cryptic 21:14, 21 July 2024 (UTC)

See the #Mediawiki errors thread above. Things were good for the past day or so, then another big spike of errors around 2100 UTC (i.e. about 20 minutes ago). RoySmith (talk) 21:20, 21 July 2024 (UTC)

Database error

Attempting to post a reply on a talk page, and it fails to post, with the error:

[81c7ca0f-eea1-42f7-8924-5a63e7dbb4cf] Caught exception of type Wikimedia\Rdbms\DBUnexpectedError

I'm betting I'll probably get the same error while trying to report this error... cheers. anastrophe, an editor he is. 01:29, 21 July 2024 (UTC)

And it posted, and the post on the talk page went through on a retry just now. Whee! cheers. anastrophe, an editor he is. 01:29, 21 July 2024 (UTC)

There was an outage affecting mostly logged-in page views (but mostly not logged-out page views, or logged-in edits – so you might have been able to save your comment, but not see it afterwards). I'll merge this with the section above that discusses it. Matma Rex talk 16:49, 22 July 2024 (UTC)

List of pages containing sic with hide

How can I generate a list of pages containing {{sic}} with the optional |hide= argument? -- GreenC 05:19, 19 July 2024 (UTC)

The "monthly report" in the TemplateData section is sometimes helpful. This list might be what you want. It's based on the monthly database dump, so it won't be current. The most recent report shows 4,277 articles. – Jonesey95 (talk) 05:47, 19 July 2024 (UTC)

You can also try a live search like hastemplate:sic insource:hide insource:/\| *hide *=/ PrimeHunter (talk) 09:05, 19 July 2024 (UTC)

Thanks (and for {{search link}} I'd not seen before). My goal is to find uses of {{sic}} embedded in URLs ie. hastemplate:sic insource:hide insource:/\| *hide *=/ insource:/[-]\{\{sic/, has about 80. To get them all I'd probably need to change the last regex to insource:/[^ ]{{sic/ then use a bot to see if it's in a URL, in which case might as well use the larger number from Jonesey95. Only trying to understand how widespread this intractable problem is. Employing {{sic}} or not in these situations is a bad choice either way, and I don't see a good solution. If you don't add {{sic}} then users and user scripts/AWB etc search and replace misspellings, breaking the URL. If you do add {{sic}}, it breaks bots and tools which can't parse multiple encoding schemes, it violates the IETF RFC on URL encoding standards. In theory bots and tools should account for it, but it's an edge case and difficult to program for, I'd be surprised if any tools or bots are aware of it. -- GreenC 15:11, 19 July 2024 (UTC)

@GreenC: {{nobots}} may be of use. Polygnotus (talk) 23:52, 19 July 2024 (UTC)

I don't think {{nobots}} would make sense here. Even {{bots|deny=AWB}} would probably be excessive. WP:SPELLBOT basically prohibits spell-checking bots, and if a human editor is using AWB or some other tool or script (or even manual "fixing") to break URLs while spell-checking then WP:MEATBOT would apply if they refuse to be more careful with their edits. Anomie⚔ 13:01, 20 July 2024 (UTC)

OTOH, I suspect the editors adding {{sic}} inside URLs aren't trying to stop bots or scripts from fixing them so much as trying to clear a search for misspellings as they fix the ones that can correctly be fixed. Checking the first few from GreenC's search above finds all were added by User:Federhalter, so pinging him in the hope he will elucidate his process and he and GreenC can come to a better solution. Anomie⚔ 13:14, 20 July 2024 (UTC)

OK thanks for pinging Federhalter, hope they respond.

Using this template or not has deleterious effects over the long term. How many URLs have been silently broken by spell checkers, we never know. How many URLs have been mangled by bots, or link rot incorrectly detected, because of the template. My intuition is the spell checker problem is more common because there are more editors running spell checks; and we hope bot writers are more expert to deal with the template. The template thus might have the advantage, though neither is a good solution. -- GreenC 16:32, 20 July 2024 (UTC)

Indeed, these edits were a (misguided) attempt to exclude misspellings from search results, e.g. Carribean insource:/carribean/i. At the time I was unaware this can cause problems. I learned since then. The reason for including the parameter 'insource' in the first place, instead of simply using Carribean, is that the latter returns (a lot of) results which are only a "redirect from" a misspelled title and do not contain an actual misspelling. I could not yet find an alternative search method for fixing this. Federhalter (talk) 07:05, 21 July 2024 (UTC)

Background color in edit textarea for dark mode

When I edit admin-protected pages like Template:Disambig editnotice, I get nearly-white text on a very light pink background, and it's nearly invisible. Does anyone know where this color is set? Is that part of the skin CSS?

BTW, I added class=skin-invert to that template, but the results are pretty ugly in dark mode. It (and many other templates) could probably use upgrading to CSS variables with the palette from [5], though it's very difficult for me to edit it safely at the moment. -- Beland (talk) 03:46, 20 July 2024 (UTC)

I've thrown Something at the problem now that I've been reminded about at least 5% of why I asked for int admin back. We're going to need to refine colors, these don't necessarily mesh well with syntaxhighlighting, which is still a known problem child. Izno (talk) 04:07, 20 July 2024 (UTC)

(Alternatively, we can ditch the pink for editing protected things and just use the base colors, but IDK how that will go down with Everyone.) Izno (talk) 04:10, 20 July 2024 (UTC)

The pink reminds me that I'm editing a protected page, and that I need to exercise extra caution. --Redrose64 🌹 (talk) 08:13, 20 July 2024 (UTC)

This discussion prompted me to post a bug report: MediaWiki talk:Common.css § Pink background-color for protected pages doesn't work without CodeMirror. —⁠andrybak (talk) 12:20, 20 July 2024 (UTC)

FTR, andrybak's problem turned out to be a conflict with a gadget; see mw:User talk:Remember the dot/Syntax highlighter.js#Inline styles interfere with enwiki's CSS. -- Beland (talk) 18:58, 21 July 2024 (UTC)

I know what the purposes of the background is, I am just about convinced however that it isn't valuable to load for every user in the groups of interest. Izno (talk) 16:34, 20 July 2024 (UTC)

I'm now getting white text on a dark red background in dark mode, which makes things a lot easier to edit in dark mode. Many thanks! I'm still curious where this fix was implemented, in case I run into similar problems elsewhere? -- Beland (talk) 19:03, 21 July 2024 (UTC)

MediaWiki:Group-sysop.css and MediaWiki:Group-templateeditor.css. Izno (talk) 19:19, 21 July 2024 (UTC)

Aha, thanks for the pointers! -- Beland (talk) 19:50, 21 July 2024 (UTC)

As for the BTW, this template strongly needs to reconsider whether it should have the (coffee) color it does. It is intended as a system message (edit intro) and should be colored as expected for that series of templates. It looks like it was added based on "it would be more noticeable", which I think is a miss since most other edit notices are no more noticeable. But particularly to using a Codex color, there are no coffee colors in that palette. Izno (talk) 04:15, 20 July 2024 (UTC)

I've changed it to "background-color-warning-subtle" from the official palette, which is more or less the same hue. It still ends up as an ugly brown in dark mode, even without "class=skin-invert". Presumably there needs to be an official thinking up of a good subtle warning color for dark mode?

Whether this should be notionally colorized as a warning or as info I'm agnostic about. Looking through the templates in Category:Editnotice templates, the aesthetics are really all over the place. Some templates get attention by having a yellow icon, red icon, yellow border (which is nice even in dark mode), red words as internal headers, yellow background, or pink background. Some have no attention-getting colors at all. Should we start a discussion somewhere about making the visual conventions more uniform? If these are all going to need to be converted to use the new official palette, they'd need to be adjusted anyway. -- Beland (talk) 19:22, 21 July 2024 (UTC)

I wouldn't be surprised by an ugly brown being the flip for yellow. Using the skin-invert class should be used only for non-flipping colors, and this isn't one of those.

We don't need to convert to Codex per se, we just need to be sensitive to what colors we have and are providing in multiple color themes now. Having a standardized color scheme (which we in fact already have for the message box series, though as you point out it is often customized) is one way to be successful at that objective by default. Adding the customizations that we do is the issue, and could be solved either by removal of those colors, making some other standard templates/templatestyles, or using upstream variables from Codex or even Common.css. A discussion about the customizations is probably warranted somewhere, but I don't know how many people are interested in that kind of topic - often there is resistance along the lines of "it looks like how I wanted" (which would echo refrains from when the message boxes were standardized nearly 20 years ago). Izno (talk) 19:35, 21 July 2024 (UTC)

Unstrip post-expand size limit

Hello, I'm working on a fairly large page that may be coming up against some technical limits. One may be the Unstrip post-expand size. But I can't say I understand much about this datum and the help files don't say much. Do these stats look problematic? Except for the Unstrip post-expand size value none are more than about 50% of the limit.

Post-expand include size 1,155,959/2,097,152 bytes Template argument size 9,599/2,097,152 bytes Highest expansion depth 16/100 Expensive parser function count 37/500 Unstrip recursion depth 1/20 Unstrip post-expand size 4,254,075/5,000,000 bytes

My understanding is that the Post-expand include size is a hard limit, but don't know about Unstrip post-expand size. Mr. Swordfish (talk) 21:55, 20 July 2024 (UTC)

See Help:Template limits#Unstrip post-expand size and mw:Manual:Template limits#Unstrip post-expand size. You may lose styling from TemplateStyles at the end of the page if the limit is broken. The latter link also says "some other extensions implemented in a similar manner". I don't know which extentions can be affected. I have never encountered this limit in practice. Category:Pages where the unstrip size limit is exceeded only lists two articles and 13 other pages. The bottom of List of Android smartphones currently shows what can happen when navbox styling is lost from Template:Android (operating system). Which page are you referring to? PrimeHunter (talk) 22:38, 20 July 2024 (UTC)

Thanks for your prompt reply. The two links you provided say the same thing, and don't tell me much. I'd already read the first one.

The page in question is List of common misconceptions. See the next thread. Mr. Swordfish (talk) 01:48, 21 July 2024 (UTC)

The large Unstrip post-expand size mainly comes from numerous citations loading Module:Citation/CS1/styles.css. If it was blank then List of common misconceptions would use 1,640,908 instead of 4,298,458 of the allowed 5,000,000 bytes. Maybe we should try to reduce the impact of loading it. PrimeHunter (talk) 20:58, 21 July 2024 (UTC)

Does that count include the comments in that css file? Maybe it would help just minimizing it to a styles.min.css, and loading that instead? --rchard2scout (talk) 21:27, 21 July 2024 (UTC)

No, it's the minimized CSS that's counted. Anomie⚔ 23:23, 21 July 2024 (UTC)

Surely enough page views have at least one citation on them that it would make sense to merge that into the main MediaWiki:Common.css. —Cryptic 21:45, 21 July 2024 (UTC)

MediaWiki talk:Common.css/to do#description has a discussion about why we should prefer TemplateStyles categorically. But specific to numbers, no, we have something like 60 million pages and only 6 million of them carry a CS1 template.

I would object to changing anything here, for both the reasons espoused in the to do page and because we should not change general templates to suit the whims of arbitrary edge case pages. There are approximately 3 main space pages which are hitting an issue with this limit. Reduce their size per WP:SIZE/WP:SPLIT as expected of such pages. This is the standard response to such hard limits as are imposed by the software. To be honest, I'm shocked that any pages hit the unstrip limit, it's very hard to do that (almost always, a page will hit WP:PEIS first). Izno (talk) 01:38, 22 July 2024 (UTC)

Maybe adding the styles to {{Reflist}} can be a possible solution? Gonnym (talk) 03:48, 22 July 2024 (UTC)

Citations are used outside of reflist and on pages without the reflist template all the time. Izno (talk) 04:14, 22 July 2024 (UTC)

Is the relevant metric "pages", or "page views"? WhatamIdoing (talk) 16:47, 22 July 2024 (UTC)

I can't find it now, but some years ago I expressed a concern that if a template was used multiple times then multiple copies of its template styles would be loaded. I was assured that this could not happen, only the first instance would be processed. It now seems that I was misinformed. --Redrose64 🌹 (talk) 22:30, 21 July 2024 (UTC)

Only the first instance in the page is served to the browser. The situation here, on the other hand, is counting on the server before the deduplication happens. See my comment in the section below for details. Anomie⚔ 23:23, 21 July 2024 (UTC)

PEIS question

We have a question at Talk:List of common misconceptions#Split proposal about Help:Template limits. This is one of our largest pages, with 569,144 bytes of wikitext, 869 refs, and 1,220 templates. I think it would be best to answer it over there. WhatamIdoing (talk) 22:20, 20 July 2024 (UTC)

The post-expansion inclusion size of that page is currently a bit above 50% of the limit. so that should not be much of an issue. OTOH, the Unstrip post-expand size is over 80% of the limit, which may or may not be an issue. See the previous thread. Yeah, we could use some informed technical advice, either here or at the talk page there. Mr. Swordfish (talk) 01:45, 21 July 2024 (UTC)

Looks like much of the "Unstrip post-expand size" is it counting every repetition of the TemplateStyles stylesheets, even though these are deduplicated before the article is sent to the browser (somewhat unfortunately that's the direction T160563 wound up going in). Which means, for example, the minified version of Module:Citation/CS1/styles.css is counted 1113 times even though it's only included in the page output once. If the limit winds up being exceeded, then TemplateStyles <style> tags at the end of the article (like for the portal bar) might wind up broken. "Manual" deduplication for the cite template styles (i.e. sticking one before the <references /> and passing an arg to all the cite templates to have them not include that) might work, but in more general cases you'd want to be careful that the on-demand section loading for the mobile apps (if they still do that) doesn't break. Anomie⚔ 13:13, 21 July 2024 (UTC)

Issue with archive bot (Lowercase sigmabot III)

I think something may be wrong with Lowercase sigmabot III. Looking at its contributions, it only archived 4 talk pages on the 19th, about 80 on the 20th, and only 4 so far today. For comparison, it usually seems to archive many hundreds or thousands (for example on the 18th it archived well over 700). Any insight? GhostOfNoMeme 09:28, 21 July 2024 (UTC)

Please contact the bot owner, they are the only one who can change/check the bot. —TheDJ (talk • contribs) 10:28, 21 July 2024 (UTC)

Unfortunately, they seem MIA. No edits for 2 years, and no response to past messages on their talk page. I suppose there's nothing that can be done. GhostOfNoMeme 10:36, 21 July 2024 (UTC)

That's pessimistic, GhostOfNoMeme. Well, the bot didn't start on the 19th, and I can't tell why, but it hasn't reoccurred, so let's not worry about it for now. On the 20th it ran into an issue partway through its run. I've put in a workaround so that is less likely going forward. And today it's been running fine. (It doesn't start until 12:00 UTC, so that's why you didn't see any activity when you started this thread.) — The Earwig (talk) 23:27, 21 July 2024 (UTC)

Ah, good to know. Thanks! I'd seen a very recent mention on the creator's talk page of the impending deflagging of another of his bots due to activity. I'm not particularly familiar with how bots are created, maintained, or reviewed, so I assumed the worst. Appreciate the info The Earwig! GhostOfNoMeme 13:35, 22 July 2024 (UTC)

Toolsadmin suggests that 0xDeadbeef and The Earwig might be undocumented co-operators. * Pppery * _{it has begun...} 15:31, 21 July 2024 (UTC)

Thanks, Pppery. I added myself as a co-maintainer on the bot's userpage. — The Earwig (talk) 23:22, 21 July 2024 (UTC)

This may be phab:T370603. --Redrose64 🌹 (talk) 21:18, 21 July 2024 (UTC)

Seems unrelated, unless IABot is also having issues due to high maxlag. — The Earwig (talk) 23:28, 21 July 2024 (UTC)

Fix Infobox: Dylan Dog

I'm not sure if this is the correct place to post a request. Could someone please check the page Dylan Dog and fix the infobox? I'm a bit out of practice with formatting standards. Also, what would have been the correct place to make this request? Thanks! 100.19.66.49 (talk) 15:30, 21 July 2024 (UTC)

Seems it was fixed here [6] and WP:HELPDESK would have been a righter place. I remember reading that comic. Gråbergs Gråa Sång (talk) 16:38, 21 July 2024 (UTC)

Dark Mode Text

In dark mode, at {{Soulfly}}, the actual link for Soulfly is an extremely dark grey that is difficult to see on a black background. Also, when editing, anything that is NOT a link is grey text on a white background. It was not this way before. Does anyone know how to fix this? --Jax 0677 (talk) 21:35, 21 July 2024 (UTC)

I get the same result. Any unvisited link is a helpful blue on a black background. Any visited link is dark gray (#202122, if I am reading my inspector correctly) on a black background (#101418, I think, which is "--background-color-base"). My inspector says that the contrast ratio is 1.14. – Jonesey95 (talk) 23:29, 21 July 2024 (UTC)

• Reply - Thank you very much for your feedback. I think that the first issue may be exclusive to {{Navbox musical artist}}. And now we wait, I suppose... --Jax 0677 (talk) 23:32, 21 July 2024 (UTC)

Jdlrobson made some edits to {{Navbox musical artist}} about a week ago that added color: #202122 to several parameter styles. I'm still using the Dark Mode gadget rather than the Foundation version, and I'm not experiencing the issue in Vector 2022. Folly Mox (talk) 10:17, 22 July 2024 (UTC)

--> Template_talk:Navbox#Make_navbox-title_links_show_in_dark_mode 🐸 Jdlrobson (talk) 18:57, 22 July 2024 (UTC)

Screen blacking-out on mobile app

So I rrecently used my iPhone to access the Teahouse and the scrreen flickered between normal and black for about 10 seconds before going all black. Restarting the app doesn't fix this either. Unfortunately I have no image of this, but to describe it:

• The screen would flicker between being able to read, then white, then flickering black.
• Then the screen would stop flickering and go all-black. This isn't an issue with my device, as only a few pages within the Wikipedia app in specific do it.
• Every part of the screen was black except the upper search bar and the Wikipedia logo.
• Then I atttempted to restart the app and see if the glitch would go away, but it kept doing it.

I noticed that extremely long pages or threads will completely black-out iPhone screens (including the Teahouse, which is notoriously long). This can be a serious issue when trying to access something in-the-moment, and the Teahouse still is completely broken on my phone. I have no idea if this is even a Wikipedia-side issue, but yea. Just anted to make ya'll aware of this. I'll try to get an image tomorrow, it's prretty hard to explain. Sir MemeGod ._. (talk - contribs - created articles) 04:16, 22 July 2024 (UTC)

Also I do apologize if this was the wrong place to report this. (I'd report it to Phabricator but I've never been able to access it due to a separate and unrelated glitch) Sir MemeGod ._. (talk - contribs - created articles) 04:18, 22 July 2024 (UTC)

MemeGod27, issues specific to the iOS app might get a more informed response at mw:Talk:Wikimedia Apps or at the technical support email address listed at :mw:Wikimedia Apps/iOS FAQ § If I have a question or a suggestion, how do I get in touch? Folly Mox (talk) 10:27, 22 July 2024 (UTC)

Hello @Sir MemeGod,

I'm Amal Ramadan, Senior Movement Communications Specialist supporting the mobile apps team at the foundation, can you send the model and iOS version of your device, please? I will forward it to our iOS engineers to work on solving it.

Also, you can follow with us through the iOS support email: ios-support@wikimedia.org

Thanks. ARamadan-WMF (talk) 08:54, 24 July 2024 (UTC)

Cellullar data drain

Apologies if this is not the right place for my query. While using the Wikipedia app on iOS with a 4G connection, I received a notification from my provider stating I had only 5GB left in my data package. Eight minutes later, I received another message saying my data package was completely used up. Upon checking my cellular usage settings, I found that the Wikipedia app had consumed 6.8GB of data in just about 10 minutes. What could be the cause of this? 141.196.107.237 (talk) 05:08, 22 July 2024 (UTC)

Could be that you looked at pages with many large images? Jo-Jo Eumerus (talk) 06:11, 22 July 2024 (UTC)

I visited articles including the 2024 US presidential elections, January 6 Capitol attack, Trump assassination attempt, Joe Biden presidential campaign 2024, and the 2024 presidential debate. I’m not sure that these articles would use 6.8GB of data in such a short time. 141.196.138.120 (talk) 07:04, 23 July 2024 (UTC)

141, do you happen to have a large Reading List of articles saved for offline viewing? Is it possible that it was syncing across devices or refreshing its contents for another reason?

I'm afraid most of us editors at English Wikipedia have very little experience with the apps, since they don't support full editing functionality. Someone here may have answers for you, but in case none are forthcoming, you could always ask the iOS app team directly at mw:Talk:Wikimedia Apps or at the technical support email address listed at :mw:Wikimedia Apps/iOS FAQ § If I have a question or a suggestion, how do I get in touch? Folly Mox (talk) 09:58, 22 July 2024 (UTC)

No, I don’t have any reading lists saved for offline viewing. Thank you for providing the email address for further assistance. 141.196.138.120 (talk) 07:06, 23 July 2024 (UTC)

Hello,

I'm Amal Ramadan, Senior Movement Communications Specialist supporting the mobile apps team at the foundation. After discussing this issue with our iOS engineer lead, we have created a ticket T370790 for further investigation. Please subscribe to it for updates. It would also be helpful if you could let us know if you were reading only or using multimedia options in the article as well. ARamadan-WMF (talk) 08:13, 24 July 2024 (UTC)

TemplateStyles CSS help: tbody tr:first-child {<css attributes>}

 Courtesy link: Wikipedia:Copying text from other sources § Can I copy from open license or public domain sources?
 Courtesy link: Draft:License compatibility

If that subject line does not look cryptic to you, I would love to have your advice. I am trying to spin off the table about License compatibility that you can view here, into a template so I can use it in multiple articles, and add user-configurable style, and I am running into problems using CSS to reproduce the blue background in the first row. Currently, the template is at Draft:License compatibility. I am busy on two tracks: adding parameters for user stylability, and moving the original style to Draft:License compatibility/styles.css as default style. In trying to reproduce the original table style with the blue background and bolded white font in the top row as seen here, I tried the following at Draft:License compatibility/styles.css:

.lic-comp tbody tr:first-child {
	background-color:blue;
	color:white;
}

but it doesn't seem to be working properly; instead of rendering the top row with blue background, it is rendering the *second row* with blue background, and I don't understand why. Thanks for any tips you can offer. Mathglot (talk) 09:33, 22 July 2024 (UTC)

All rows in a wikitext-generated table are in <tbody>, not <thead>, even if the first one(s) include only <th>s. If the table is sortable, jquery.tablesorter puts the first row in <thead> for JavaScript-enabled users. You should probably add a class to the row itself rather than rely on a pseudo-class. Nardog (talk) 09:45, 22 July 2024 (UTC)

Thank you very much from this response. The table is non-sortable. When I look at the generated Html, I see this:

Html for table

<table class="wikitable lic-comp"> <tbody><tr> <th colspan="2">License Compatibility with Wikipedia<sup id="cite_ref-1" class="reference"><a href="#cite_note-1">&#91;1&#93;</a></sup> </th></tr> <tr> <td><span class="heading">Licenses compatible with Wikipedia</span> </td> <td><span class="heading">Licenses <i>not</i> compatible with Wikipedia</span> </td></tr> <tr> <th scope="row" colspan="2"><span class="lic-comp-label">Creative Commons licenses</span> </th></tr> <tr style="vertical-align: top;"> <td> <ul><li>CC BY, all versions and ports, up to and including 4.0</li> <li>CC BY-SA 1.0, 2.0, 2.5, 3.0, 4.0</li> <li><a rel="nofollow" class="external text" href="https://creativecommons.org/share-your-work/public-domain/cc0/">CC0</a></li></ul> </td> <td> <ul><li>CC BY-NC</li> <li>CC BY-NC-ND</li> <li>CC BY-ND</li> <li>CC BY-NC-SA</li></ul> </td></tr> <tr> <th colspan="2"><span class="lic-comp-label">Other licenses</span> </th></tr> <tr> <td> <ul><li>GFDL <b>and</b> CC BY or CC BY-SA</li></ul> </td> <td> <ul><li>any GNU-only license (including GFDL)</li></ul> </td></tr></tbody></table>

so it seems like the first tr child should be the top row, not the second one. Are you saying that jquery alters the Html after the capture posted here from right-click, view page source? Mathglot (talk) 09:55, 22 July 2024 (UTC)

If it's sortable, yes. I know it doesn't pertain to this table since it's not a data table and so is unlikely to be made sortable, but it's good practice to not rely on :first-child or :nth-child to select header rows because jquery.tablesorter modifies them for a subset of users. Nardog (talk) 10:00, 22 July 2024 (UTC)

Thanks. I'll try a different approach, although I'm not sure how to address a row in a wikitable, unless I convert it to an Html table first, and then I have the row and cell tags available which I can address. Maybe that's where this should go, at this point, unless there is an alternative. Mathglot (talk) 10:08, 22 July 2024 (UTC)

You can just write |- class="...". Nardog (talk) 10:11, 22 July 2024 (UTC)

Oh, really? Cool! I don't know how I missed that. I checked Help:Table and Help:Table/advanced and didn't see that. That should provide a solution to this; thanks a lot! (edit conflict) Mathglot (talk) 10:15, 22 July 2024 (UTC)

@Mathglot: Many (specifically, class= dir= id= lang= style= title=) attributes that are valid on a <tr> element are also permitted on |-, which is the direct equivalent in Wikitext. --Redrose64 🌹 (talk) 19:09, 22 July 2024 (UTC)

Just to say: I find the color unnecessary, distracting and hurting accessibility. Sjoerd de Bruin (talk) 10:12, 22 July 2024 (UTC)

Sjoerddebruin, you may be right, but as I am spinning off content written by another editor into a Template, I feel like the first effort should exactly reproduce their original design, so I can introduce the template into the article where they originally added the wikitext, without any changes to the rendered page. The parameters being added to the template will provide configurability to other users, to alter it as they see fit. Thanks for your comment. Mathglot (talk) 10:19, 22 July 2024 (UTC)

I doubt a template like this needs much customization options, what would the use cases be? Sjoerd de Bruin (talk) 10:25, 22 July 2024 (UTC)

I don't see any blue background or white text. Have you enabled "Make headers of tables display as long as the table is in view" at Special:Preferences#mw-prefsection-gadgets? That also messes with unsortable tables. I get blue background and white text in the top row with this which adds thto your code:

.lic-comp tbody tr:first-child th {
	background-color:blue;
	color:white;
}

PrimeHunter (talk) 10:32, 22 July 2024 (UTC)

Oh, I must have misunderstood something then. I thought Mathglot was trying to turn "Licenses compatible with Wikipedia" and "Licenses not compatible with Wikipedia" blue. Nardog (talk) 10:40, 22 July 2024 (UTC)

They are blue now, that is the problem. For starters, I am trying to echo the original, which is here, using templatestyles instead of inline style. So far, I haven't managed to do it. That would be the baseline, from which user configurability could begin. Mathglot (talk) 10:46, 22 July 2024 (UTC)

At this point, I'm going to take a break, but I should add if anyone wants to play with the template, this is a wiki, so by all means, please try stuff out in the template, or the styles.css, if you have an idea how to progress with this. Thanks, Mathglot (talk) 10:50, 22 July 2024 (UTC)

I just made the draft table much simpler (and I believe more accessible), feel free to revert if it's too drastic a change. Nardog (talk) 11:09, 22 July 2024 (UTC)

Oh, in that case it's because the default background applies to <th>, not <tr>, so it takes precedence over your custom style in TemplateStyles. .lic-comp tr:first-child > th is one way to do it. Nardog (talk) 10:50, 22 July 2024 (UTC)

@Mathglot: You didn't answer whether you have enabled "Make headers of tables display as long as the table is in view". If I enable it then I get the result you describe with blue in the second row. Without it, my code works for me, but it would be better to not rely on which table-altering features are used. PrimeHunter (talk) 11:00, 22 July 2024 (UTC)

@PrimeHunter:, Oh, thanks for thinking of that—yes, I do have header view enabled, so is that interfering somehow? I did check the page Html and didn't see anything suspicious, does the header gadget maybe change the th to something else after the page Html snapshot is taken for developer tools? In any case, what if I assign the row an id attribute, maybe I could use that to address the row uniquely regardless whether it was th or something else. Is that even possible in a wikitable, I'm not sure I've ever tried to assign a row an id attribute, and I don't see anything at Help:Table about it. Mathglot (talk) 07:45, 25 July 2024 (UTC)

@Mathglot: Page Source in Firefox shows the original html but when I right-click the heading and use Inspect Element, the gadget has changed <tbody> in the first row to <thead class="mw-sticky-header-element">. tbody is still in the second row so your CSS matches there instead. id's can be applied to rows like |- id="header" which can be targeted with #header th {...}. I often use row id's to link to a row. See Help:Tables and locations#Section link or map link to a row anchor. PrimeHunter (talk) 10:38, 25 July 2024 (UTC)

User_talk:Rosiestep#Helen_Hunt_Jackson

Help! I've somehow broken a friend's talkpage so that the indentations have turned into parentheses. I don't know how you even do that.... Adam Cuerden ^(talk)_{Has about 8.9% of all FPs.} 11:35, 22 July 2024 (UTC)

It was a stray </div> from a section higher. Adam Cuerden ^(talk)_{Has about 8.9% of all FPs.} 13:13, 22 July 2024 (UTC)

How to transclude a specific section to a parent article

I would like to transclude this section and only that section of that page to here. I tried using templates like Template:Excerpt, but I can't seem to figure it out. I am hoping that someone can provide me with some guidance on how I can do this? Interstellarity (talk) 21:23, 22 July 2024 (UTC)

The following syntax can be used: {{#section-h:Wikipedia:Vital_articles/Level/4/People|People}}. See Help:Labeled section transclusion and Help:Section#Section transclusion for details. —⁠andrybak (talk) 00:01, 23 July 2024 (UTC)

Thanks, I will try that. Interstellarity (talk) 09:34, 23 July 2024 (UTC)

@Andrybak: one more question: on Wikipedia:Vital articles/Level/4 in the sections starting with Biology and health sciences, I have it as code. How do I fix that or can you fix it for me? Interstellarity (talk) 15:45, 23 July 2024 (UTC)

The page is too big, it hit the limit of so called post-expand include size. —⁠andrybak (talk) 15:47, 23 July 2024 (UTC)

@Andrybak Is there a different way to fix this? Interstellarity (talk) 16:03, 23 July 2024 (UTC)

@Interstellarity I submitted a pull request to the bot that updates those pages which should greatly reduce the post-expand include size. --Ahecht (TALK
PAGE) 17:58, 23 July 2024 (UTC)

Tech News: 2024-30

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Feature News

• Stewards can now globally block accounts. Before the change only IP addresses and IP ranges could be blocked globally. Global account blocks are useful when the blocked user should not be logged out. Global locks (a similar tool logging the user out of their account) are unaffected by this change. The new global account block feature is related to the Temporary Accounts project, which is a new type of user account that replaces IP addresses of unregistered editors that are no longer made public.
• Later this week, Wikimedia site users will notice that the Interface of FlaggedRevs (also known as "Pending Changes") is improved and consistent with the rest of the MediaWiki interface and Wikimedia's design system. The FlaggedRevs interface experience on mobile and Minerva skin was inconsistent before it was fixed and ported to Codex by the WMF Growth team and some volunteers. [7]
• Wikimedia site users can now submit account vanishing requests via GlobalVanishRequest. This feature is used when a contributor wishes to stop editing forever. It helps you hide your past association and edit to protect your privacy. Once processed, the account will be locked and renamed. [8]
• Have you tried monitoring and addressing vandalism in Wikipedia using your phone? A Diff blog post on Patrolling features in the Mobile App highlights some of the new capabilities of the feature, including swiping through a feed of recent changes and a personal library of user talk messages for use when patrolling from your phone.
• Wikimedia contributors and GLAM (galleries, libraries, archives, and museums) organisations can now learn and measure the impact Wikimedia Commons is having towards creating quality encyclopedic content using the Commons Impact Metrics analytics dashboard. The dashboard offers organizations analytics on things like monthly edits in a category, the most viewed files, and which Wikimedia articles are using Commons images. As a result of these new data dumps, GLAM organisation can more reliably measure their return on investment for programs bringing content into the digital Commons. [9]

Project Updates

• Come share your ideas for improving the wikis on the newly reopened Community Wishlist. The Community Wishlist is Wikimedia’s forum for volunteers to share ideas (called wishes) to improve how the wikis work. The new version of the wishlist is always open, works with both wikitext and Visual Editor, and allows wishes in any language.

Learn more

• Have you ever wondered how Wikimedia software works across over 300 languages? This is 253 languages more than the Google Chrome interface, and it's no accident. The Language and Product Localization Team at the Wikimedia Foundation supports your work by adapting all the tools and interfaces in the MediaWiki software so that contributors in our movement who translate pages and strings can translate them and have the sites in all languages. Read more about the team and their upcoming work on Diff.
• How can Wikimedia build innovative and experimental products while maintaining such heavily used websites? A recent blog post by WMF staff Johan Jönsson highlights the work of the WMF Future Audience initiative, where the goal is not to build polished products but test out new ideas, such as a ChatGPT plugin and Add a Fact, to help take Wikimedia into the future.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe. You can also get other news from the Wikimedia Foundation Bulletin.

MediaWiki message delivery 00:01, 23 July 2024 (UTC)

Adding parameter to an infobox

I would like to add a parameter called `committee_url` to Template:Infobox technology standard (see my comment there). I tried unsuccessfully to add it, but the template update didn't seem to propagate, such that I couldn't properly update the documentation. The edit was undone, I am boosting this request here given it is a quiet template. Tule-hog (talk) 03:22, 23 July 2024 (UTC)

Resolved

 – Template_talk:Infobox_technology_standard#Committee_URL

Tule-hog (talk) 04:53, 23 July 2024 (UTC)

Date editing tools?

I am often editing dates in citations manually, there might be tools to help? Specifically things like converting all |date= to mdy/dmy, and converting certain parameters to iso. Do tools like this exist? -- GreenC 17:06, 23 July 2024 (UTC)

@GreenC the presence of the {{Use mdy dates}} or {{Use dmy dates}} template on a page will cause all citation templates on that page to automatically display dates in the specified format. There's no reason to edit them in the source. --Ahecht (TALK
PAGE) 17:22, 23 July 2024 (UTC)

You know, there are reasons to edit the source, for instance there are editors with disabilities for whom the source code is already pretty unreadable. I recommend that editors continue to fix all instances of YYYY-MM-DD formatting until a system-wide solution can be found. Abductive (reasoning) 04:48, 25 July 2024 (UTC)

I use User:Ohconfucius/script/MOSNUM dates.js which works like a charm and updates the date in any such template above. It fixes dates both in text and citations. Jonatan Svensson Glad (talk) 22:05, 23 July 2024 (UTC)

Excellent, thanks! Special:Diff/1234312528/1236323855 -- GreenC 02:42, 24 July 2024 (UTC)

Sill needs to be manually checked some times ;) Special:Diff/1236327753 Jonatan Svensson Glad (talk) 03:10, 24 July 2024 (UTC)

Some module timing out

I stumbled upon this diff, where for some reason all lua calls fail. Does someone know why? — Alien333 (what I did & why I did it wrong) 18:04, 23 July 2024 (UTC)

@Alien333:  Works for me, and please see Wikipedia:Village pump (technical)/Archive 213#The time allocated for running scripts has expired. --Redrose64 🌹 (talk) 18:15, 23 July 2024 (UTC)

¯\_(ツ)_/¯ Still not working for me (including after purge), but eh, it's a past diff anyways, so not important. — Alien333 (what I did & why I did it wrong) 18:36, 23 July 2024 (UTC)

Automated tool that I can use to change headings to be one level down

I would like to edit the headings so that they are one level down like in here. I know I could probably do it the old-fashioned way, but it would probably take up a lot of time to do so. I'm looking for an easy solution that I can use so that it will bring the headings one level down. For example: if it is a level 2 heading, I would like it into a level 3 heading. What would you recommend I do? Please ping me in your response. Interstellarity (talk) 23:23, 23 July 2024 (UTC)

@Interstellarity, this will probably work with the regex find replace in the wikitext 2010 or 2017 editors: find ==([^=]*?)==, replace ===$1===, mark the find as a regex find, and then hit the appropriate go button. Izno (talk) 23:46, 23 July 2024 (UTC)

@Izno: How can I do this for turning level 1 headings into level 2 headings, level 2 headings into level 3 headings, and level 3 headings into level 4 headings, and so on? Interstellarity (talk) 00:26, 24 July 2024 (UTC)

Search for: ^((={1,5})[^=\n][^\n]*\2)

Replace with: =$1=

Nardog (talk) 00:36, 24 July 2024 (UTC)

Removing subpage w/o name change?

Tracked in Phabricator
Task T231692

Perhaps this is impossible, but I noticed that Talk:AC/DC is technically a subpage of the unrelated Talk:AC disambiguation, merely due to the backslash's double function as a title & subpage sorter (classic Wikipedia shenanigans). Is this removable somehow? Not a huge issue, but certainly not ideal either. Aza24 (talk) 06:18, 24 July 2024 (UTC)

Not possible right now. There's probably a task on Phabricator for it somewhere. * Pppery * _{it has begun...} 06:19, 24 July 2024 (UTC)

We could hide the parent page link to Talk:AC with .page-Talk_AC_DC .subpages {display:none;} in MediaWiki:Common.css but I don't support it. Each unwanted link would need its own code and the increased CSS size doesn't seem worth it. It would still be a subpage with other associated features. PrimeHunter (talk) 10:41, 24 July 2024 (UTC)

Could this be done with templatestyles, by creating something like {{nobreadcrumbs}}? --rchard2scout (talk) 11:54, 24 July 2024 (UTC)

No, because TemplateStyles can only style things inside .mw-parser-output and this isn't there. * Pppery * _{it has begun...} 15:30, 24 July 2024 (UTC)

Even if that weren't the case, doing it right in pure css would be difficult at best. Consider what would need to be done to get Talk:AC/DC/Archive 1's breadcrumbs to look right. —Cryptic 18:21, 24 July 2024 (UTC)

@Aza24: It's been a known issue (see WP:TITLESLASH) for at least as long as I've been on Wikipedia (15+ years). Also, it's not a backslash but a slash. --Redrose64 🌹 (talk) 18:16, 24 July 2024 (UTC)

Gotcha. Well, worth a shot :) Aza24 (talk) 18:20, 24 July 2024 (UTC)

Level 4 vital articles

On this page, Wikipedia:Vital articles/Level/4, when I click the edit link on a particular section, any section, it brings me to the section before the one I clicked. I recently transcluded the sections so I'm not sure if this is part of the problem and it is buggy right now since this is new, but I am working on it to try to bring it so it can be stable and free from bugs. Interstellarity (talk) 22:00, 24 July 2024 (UTC)

I was able to replicate the problem. I did a null edit and the problem went away. – Jonesey95 (talk) 22:13, 24 July 2024 (UTC)

@Jonesey95 The problem isn't with the subpages, it's with the main page of level 4 that I'm trying to figure out. I saw that you replicated the problem, but I am unaware of a null edit that caused the problem to go away. Interstellarity (talk) 22:17, 24 July 2024 (UTC)

I didn't say anything about subpages, and you could not have seen either my replication of the problem or a null edit. In any event, the page is currently in Category:Pages where post-expand include size is exceeded, which will cause all sorts of problems. The page size needs to be reduced before it will behave predictably. – Jonesey95 (talk) 22:31, 24 July 2024 (UTC)

@Interstellarity I would recommend undoing your transclusion of those sections, as it causes the page to be huge, take forever to load, and, most importantly, exceed the WP:PEIS limit so that the entire thing doesn't display properly. It also may have broken Cewbot, as seen at this edit right after your transclusion. --Ahecht (TALK
PAGE) 13:58, 25 July 2024 (UTC)

UX nit: on-hover of link to same page

When a wikilink on a page points to that same page, it displays as bold rather than regular blue. These are not clickable links, as one is already on that page. As of...recently...however, the mouse cursor over these items still turns from the normal pointer into the hand as if it were a regular link. Vector2022, Firefox-115.13.0esr. Examples tested are [[User:DMacks]] on User:DMacks and spot-checking several navboxes (mainspace pages that transclude templates with a link to the mainspace page). DMacks (talk) 22:38, 24 July 2024 (UTC)

Not using screen width

I use Wikipedia on my laptop and PC, which both have roughly the same size screens. Now, I haven't made any setting changes, and everything is fine on my laptop, but on my PC, out of the blue, Wikipedia is no longer using the full page width. For some things! Talk pages are fine, infoboxes are where they should be, same with end of article templates and category lists. It's just the article text itself (and any images in the article) that isn't using the full screen - its right-hand border is roughly in line with the standard infobox position. I've taken a few screenshots to illustrate the problem.

[10] (regular article with infobox)

[11] (categories at end of article)

[12] (talk page)

[13] (editing)

Any help would be very much appreciated. Bertaut (talk) 00:15, 25 July 2024 (UTC)

@Bertaut, this is something that I might expect to happen if you turn on the "Improved appearance for mobile, narrow and wide screens (documentation)" in your gadgets in Special:Preferences. Can you see that is unchecked?

Second step, if that is unchecked, please go to a page of interest and add ?safemode=1 in the URL bar and then hit your version of "go" and see if the issue persists. Izno (talk) 00:29, 25 July 2024 (UTC)

That appears to have fixed it; that option was checked. Can't believe it was that simple!! The fact that I didn't have the problem on the laptop made me think it wasn't a Wiki setting. Really appreciate that. Thanks. Bertaut (talk) 00:34, 25 July 2024 (UTC)

For dark mode: How should a template change the "background-color" property?

We have a dark mode now, but I'm confused about how templates should handle background colors. An editor raised a specific issue at Template_talk:Bar_chart#Dark_mode_error, and I asked that individual, but maybe other people will have this same confusion.

The issue is that many templates use a pale (but not white) background to set boxes aside from the main content. These templates typically leave the "color" property of text alone. The default color is black but becomes white in dark mode. The resulting pale text on a pale background is unreadable. For example, activate dark mode and check out Prince Albert, Saskatchewan#Demographics. The glowing template there is {{Canada census}}. It uses the background colors #f8f9fa and lavender and does not change the "color" property of the text.[14] This seems to be a bug in dark mode, but I see many similar templates listed at this bug-tracking page as if they are template bugs: [15]

The recommendations from the WMF seem to suggest defining a light and dark background color on each template?[16] If that's the answer, then that's the answer, but seems like a massive amount of work when templates exist for years without being fixed for mobile, screen readers, narrow screens, the new desktop theme, and so on.

Also, what does this mean for templates that allow a user to set the background? On {{bar chart}} this would make the text unreadable on at least one of the two modes, and so user-determined colors would need to be disabled.[17] I looked up a version of Elie Wiesel that I know has the background-color set at the page level for its {{quote box}}es.[18] I see "html.skin-theme-clientpref-night .quotebox:not(.notheme)" disabling both "background" and "color" properties at the site's theme level. This appears to have been done for many widely used templates (infoboxes and nav boxes), but what is expected for other templates?

I imagine the background colors cannot just be turned off because templates like {{legend}} use them for meaning. But is there no way for the site to automatically figure that black text with a custom background color should not become white? Rjjⁱⁱⁱ (talk) 05:57, 25 July 2024 (UTC)

The fact that stuff wasn't fixed for years isn't a reason to continue doing so. A lot of user selected colors don't pass WP:COLOR's AA minimal requirement. Gonnym (talk) 07:13, 25 July 2024 (UTC)

The advice is here: Recommendations for night mode compatibility on Wikimedia wikis.

• Whenever you set background-color, set a color.
• You can use CSS variables and design tokens, which will flip their color depending on the mode used.
• If you need other colours that have to flip/adapt, use the scoped classes for dark mode and automatic dark mode in a TemplateStyles stylesheets.

Yes this is a massive amount of work. This was always going to be the consequence of people wanting dark mode. —TheDJ (talk • contribs) 08:19, 25 July 2024 (UTC)

Personal opinion is that setting color is generally unnecessary in 'structural' templates like infoboxes. Simply getting a template to output a background compatible with the theme is usually enough. Izno (talk) 17:34, 25 July 2024 (UTC)

WMF has a tool that lists contrast issues of the top 100 visited pages at https://night-mode-checker.wmcloud.org/en-mobile/night.html, that should probably be a priority.

Finding the rest of the issues is a matter of finding contrast issues. Do not try to assign a text color to every background-color, it is a waste of time with no real benefit. Only assign a text color if the contrast is insufficient according to WCAG AA.

You want to take the hex color values of #101418 which is dark mode background and #6D8AF2 which is the link color. Hex values close to those have insufficient contrast. I recommend finding the first available contrast friendly color and search for everything that has less contrast (you can use https://webaim.org/resources/contrastchecker/ to find this color). The search can be done with an regex. Additionally "background:transparent" is also an issue, and should probably be removed on sight.

WCAG AA has an different contrast requirement for graphs than for text, so that applies to template:bar chart. Snævar (talk) 13:28, 25 July 2024 (UTC)

Also note that Module:Color contrast, as well as various templates built off of it, exist for enforcing WCAG compliance even with user-specified colors. --Ahecht (TALK
PAGE) 13:56, 25 July 2024 (UTC)

I think most of your questions are answered above. TheDJ links to the page most of interest to the question. Some specifics:

There is a design token background-color-neutral-subtle which in light mode is a near-white grey. I have been normalizing templates to that color as the base when I encounter a near-white. In the case of the census template, it is the exact same color in light mode as you have pointed out. (It's probable that I'm the one to blame: I would have added that color to the template when I was removing the use of infobox class from non-infoboxes.)

For the specific case of templates that allow the user to change the color:

1. Remove allowing the user to change the color. This may or may not be feasible either technically (because it does not fit the semantics of the template) or because you're afraid of screeching from users who have always done it that way and have not had a care in the world about how unable it makes us to provide a dark mode. Either way, if you think you can get away on the second axis, strongly go for the first.
2. Do a hard override in TemplateStyles (e.g. Template:Color/styles.css, because that template matches the first case above) or at a global level (we have some generic CSS in MediaWiki:Vector-2022.css that hits a bunch of cases).

seems like a massive amount of work when templates exist for years without being fixed for mobile, screen readers, narrow screens, the new desktop theme, and so on. Welcome to Wikipedia. Identify priorities and backlogs (for example, MediaWiki talk:Common.css/to do), advertise that you're working on it ( ;) ), fix things that affect you personally when you find them, and ultimately, do what you can. Izno (talk) 17:56, 25 July 2024 (UTC)

Thanks all! Izno and TheDJ's post covered everything. Appreciate the explanations. I was hoping there would be a simple solution, but can accept there is not, Rjjⁱⁱⁱ (talk) 22:16, 25 July 2024 (UTC)

Request for Lua code review: New language module

Hello fellow Wikipedians,

I'm a first-time technical contributor, so I'm not entirely sure if this is the best place for this request, but I believe kickstarting a conversation here is a good start. I've just created my first module in Lua and would welcome feedback and a review from the more experienced technical members of our community.

The module, Module:Korean transliteration notice, is designed to support articles about Korea. Unfortunately, there is no universal method for romanizing the Korean language, with the two Korean governments having different standards and Western academia preferring another.

According to the MOS:KO, there are established conventions for which articles should use which method, but there is currently no categorization, automation, enforcement, or awareness among many editors and a template like this would help greatly and be a good first step.

Don't know Korean? Don't worry. This module is designed to work very similarly to Module:English variant notice, which I used as a foundation for the transliteration module. Here are some key links to the documentation and example template outputs:

• Module:Korean transliteration notice
• Template:Korean transliteration notice/documentation
• Template:Revised Romanization of Korean
• Template:McCune-Reischauer romanization of Korean
• Template:Yale romanization of Korean

Since this is my first attempt at this stuff on Wikipedia, I'm bound to have missed something. I would greatly appreciate any feedback on:

• Code structure and organization
• Performance considerations
• Any other best practices I might have missed

Once the module has been reviewed here or on the module talk page, I'll seek further community feedback from the MOS:KO community.

Thank you in advance for your time and expertise!

Best regards,

-- Nonabelian (talk) 15:19, 25 July 2024 (UTC)

No globals. Add require ('strict') at the top. Do you really mean to export all of the functions in the module? If not, then function p.whatever() should be changed to local function whatever() (may require repositioning in the module).

—Trappist the monk (talk) 17:47, 25 July 2024 (UTC)

Performance considerations There are some cases where you should worry about performance (templates widely used like millions of pages, or several hundred uses per page, or the modules are huge), but otherwise, don't worry about it. Izno (talk) 18:01, 25 July 2024 (UTC)

@Trappist the monk: Great advice. Done. (I think!) @Izno: Phew! Thank you! --Nonabelian (talk) 19:55, 25 July 2024 (UTC)

Adding documentation subpage to module doc pages

Currently, {{Documentation subpage}} is added to module doc pages with MediaWiki:Scribunto-doc-page-header. The problem with this approach is that the system message does not add Category:Module documentation pages. If we want to add it, we have to either transclude {{Documentation subpage}} ourselves, which makes it appear twice, or add the category directly, which makes it much harder to update in case the category is moved in the future.

I have gone with the second approach for now by editing Template:Documentation/preload-module-doc to add the category, but I don't think that it's a good idea. What we should do instead is blank MediaWiki:Scribunto-doc-page-header and transclude {{Documentation subpage}} manually to all the module doc pages, as was suggested in MediaWiki talk:Scribunto-doc-page-header § Category:Module documentation pages. Nickps (talk) 16:01, 25 July 2024 (UTC)

Note: I originally intended to ask the devs to make the system message add the category but this has been proposed in the past in phab:T289404 and was declined. This is why I think adding the template manually is the best approach. Nickps (talk) 16:03, 25 July 2024 (UTC)

(edit conflict) This is yet another proposal to make a huge number of edits to accomplish something of very questionable value. Not worth it IMO. * Pppery * _{it has begun...} 16:04, 25 July 2024 (UTC)

The code for {{Documentation subpage}} has a test that looks like it tries to assign a category: ... [[Category:{{#switch:{{SUBJECTSPACE}} |Template=Template |Module=Module |User=User |#default=Wikipedia}} documentation pages]] .... My naive question is: why isn't that code working? Does an if statement need to be redesigned? Can something else be tweaked inside that template? I'm not clear on how the page-header page "adds" the doc subpage to the template without actually transcluding it; maybe the category could be "added" in the same way that the doc subpage template is "added". – Jonesey95 (talk) 16:19, 25 July 2024 (UTC)

@Jonesey95: The template works fine. The problem is that system messages do not add categories (see phab:T289404). If the template is included directly to a page, like in Module:Citation/CS1/doc, the categorisation works as intended. That's what I want to do, but if MediaWiki:Scribunto-doc-page-header isn't blanked first, people will see the message appear twice, assume it's a mistake and remove the template. Nickps (talk) 16:23, 25 July 2024 (UTC)

I'm more inclined to just delete Category:Module documentation pages. Unlike its twin Category:Template documentation pages which isn't very useful as a category but requires no effort to populate, this requires a lot of effort and the value over CirrusSearch isn't large enough to justify it. * Pppery * _{it has begun...} 16:35, 25 July 2024 (UTC)

And I fixed a lot of them with a single edit. It really won't take as much effort as you think. Nickps (talk) 16:44, 25 July 2024 (UTC)

@Nickps: Could you please stop making these edits until there's consensus that they should be done? You're creating a dangerous fait accompli. * Pppery * _{it has begun...} 17:06, 25 July 2024 (UTC)

I will stop. But you're not explaining what's so dangerous about them. They can be reverted as easily as I am doing them. Nickps (talk) 17:07, 25 July 2024 (UTC)

10 minutes of edits done manually can be reverted in less than half that by someone with AWB. I'm not creating a fait accompli and I'd like you to take that back. Nickps (talk) 17:11, 25 July 2024 (UTC)

You've been doing this for over an hour, not 10 minutes. * Pppery * _{it has begun...} 17:13, 25 July 2024 (UTC)

Fair, I lost track of time, I guess. Still, really easy to revert. Nickps (talk) 17:17, 25 July 2024 (UTC)

(edit conflict) What's dangerous is explained in the essay I linked - it inappropriately biases the situation toward the automatic documentation being removed later because the edits required to do it are already in place. The cost of this is that every time a module is created {{documentation subpage}} has to be manually added to the subpage forevermore, and I'm not seeing what the point of Category:Module documentation pages even is when the search I linked above can produce the same output in the unlikely event anyone cares. * Pppery * _{it has begun...} 17:12, 25 July 2024 (UTC)

I've just nominated Category:Module documentation pages for deletion. * Pppery * _{it has begun...} 17:17, 25 July 2024 (UTC)

Display of Text Image is Distorted

Hello, I found a problem on Commons. The problem is with images in SVG format, where there is distortion in the display of the text of the image, a change in the location of the text display, and a difference in the size of the text display.

This is a sample image, please click and view. So if you click on it, it will appear to you like this.

I thought the problem was due to the program I use to edit photos. For about a full day, I was experimenting with solving the problem, trying different size dimensions and so on, but it was not solved. Then in the end I discovered that the cause of the problem was the Commons website and not me.

I was also able to find out the reason for the problem on the Commons website. It occurs because the text is in a large size, and if you reduce it, the text size will be displayed at approximately the correct size.

Therefore, I ask that the technicians responsible please fix this defect, because it is a major problem. I have stopped editing images until the problem is fixed. Unfortunately, many people must have stopped designing images in this format and uploading them to Wikipedia articles because of this problem.

Note: I do not want to raise the discussion within the Commons project, because it is a very important problem related to the display of images in Wikipedia articles, and Because there is no interest from technicians within the Commons project. Mohmad Abdul sahib talk☎ talk 21:55, 25 July 2024 (UTC)

How do you know technicians from the Commons project wouldn't be interested in this issue if you haven't raised it there? Tule-hog (talk) 22:06, 25 July 2024 (UTC)

Automated redundancy check on redirects

Hello - I was using {avoided double redirect} incorrectly and creating redirect categorization redundancy on edits on my account from before July 19, 2024. I would like to request anyone with experience with automation to run a (hopefully already existing) script to prune redirects created by my account - that is, removing redundant categorization from redirects using {avoided double redirect}. Alternatively, any helpful pointers to completing this task on my own would be appreciated (should I try AWB?). Tule-hog (talk) 22:04, 25 July 2024 (UTC)

More MediaWiki problems?

I'm having problems deleting pages, I get the following message when I try to delete the old-fashioned way:

Error

Our servers are currently under maintenance or experiencing a technical problem.

And when using Twinkle:

Deleting page: Failed to delete the page: error "error" occurred while contacting the API.

Is this more Thursday problems? Liz ^{Read! Talk!} 23:22, 25 July 2024 (UTC)

Problem has improved a bit but I'll leave this post up. Liz ^{Read! Talk!} 23:27, 25 July 2024 (UTC)

Things are back to normal. I guess it was a glitch with the servers again. Liz ^{Read! Talk!} 01:26, 26 July 2024 (UTC)

Proposals

"WP:PROPOSE" redirects here. For proposing article deletion, see Wikipedia:Proposed deletion and Wikipedia:Deletion requests.

Discussion at Wikipedia:Village pump (WMF) § Unnecessary line on fundraiser banner

 You are invited to join the discussion at Wikipedia:Village pump (WMF) § Unnecessary line on fundraiser banner. It is about a controversial line in current fundraiser (putting invitation here as it is kind of a proposal to remove it). –ExclusiveEditor _{Notify Me!} 14:56, 11 July 2024 (UTC)

A profound emotion of acceptance It’s privilege to be invited on this matter but my familiarity with the topic is pretty much kindergarten level, but I would try my best if I can to be of service for the cause of of this organization spreading facts and knowledge of false/correct informations and understanding of both information’s existence. Thank you for the inviteThe Summum Bonum (talk) 12:22, 12 July 2024 (UTC)

Are you using an LLM to generate your answers, or are you writing in a language other than English and using a translator program? Donald Albury 17:44, 12 July 2024 (UTC)

Doesn't look like an LLM. They are either translating, or are a new user trying to be very well language(d), reminding me of myself when I was new. ExclusiveEditor _{Notify Me!} 13:45, 13 July 2024 (UTC)

I tried removing unnecessary lines on my comment then learned that it is considered an act of destroying the context of a non private conversation, within minutes I changed it. I would have just said a simple "thank you for the invitation but Im not qualified on the topic I was invited to."(The Summum Bonum (talk) 13:25, 18 July 2024 (UTC)

productive criticism? or Assuming Im not human?am I invited or nil?The Summum Bonum (talk) 12:19, 18 July 2024 (UTC)

Is my name Intimidating? that your curiously asking me if I'm using an LLM. "I find your lack of faith disturbing"- Darth Vader. lol. now I sound more like an A.I.. The Summum Bonum (talk) 12:28, 18 July 2024 (UTC)

@The Summum Bonum: Its not about your name but the way you wrote your reply in a stretchy fashionable and to be honest, in an unusual way made it feel like written by an LLM, especially because this descriptions also match others comments which were confirmed to be written by LLM. However I think it is clear now, that is really written by you, a human! ExclusiveEditor _{Notify Me!} 13:29, 21 July 2024 (UTC)

Request

Hi Wikipedia users and admins!

I am a new user on Wikipedia. I have made more than 10 edits and I need to edit some pages that are semi-protected or first level protection and also create some new pages on Wikipedia, without having to create them as a draft first. Please can you unlock the feature of semi-protected pages or first level protection pages on my account and also make possible for me to create some pages directly, without having to create them as a draft first.

Thanks AdamSala1991 (talk) 08:04, 18 July 2024 (UTC)

@AdamSala1991: You just have to wait one more day and your account will be autoconfirmed, then you can do all of those things. – Joe (talk) 11:39, 18 July 2024 (UTC)

Watchlisted. ——Serial Number 54129 13:17, 18 July 2024 (UTC)

The Khmer Wikipedia appears with the letters in Bold

Hi Wikipedia editors and admins!

I am a new user in Khmer Wikipedia and I have a concern. I have seen that this Wiki appears with its writing system in Bold (dark letters), which previously didn't appeared. This is seen on the language list where the Khmer language appears, when viewing articles on the Khmer Wikipedia and on the search results on Khmer Wikipedia. Can you fix the issue and make the Khmer Wikipedia to appear in normal letters, in all its forms (where the Khmer language appears, when viewing articles on the Khmer Wikipedia and on the search results on Khmer Wikipedia), like the other Wikipedia editions are?

Thanks Cheni001 (talk) 13:57, 18 July 2024 (UTC)

The editors here at the English Wikipedia cannot do anything regarding issues on any other wikis, you will need to ask for help on that Wiki (I don't speak or read Khmer so I can't advise what the best location is, but based on Google Translate km:ជំនួយ:មាតិកា is probably a good place to start looking). However, my guess is that it might be a font issue, you should be able to check that by looking at the entry for Khmer at Help:Multilingual support (Indic). If that is the issue some of the other information on that page may resolve your issue. Thryduulf (talk) 14:11, 18 July 2024 (UTC)

@Cheni001, what kind of phone are you using?

@SGrabarczuk (WMF), is there any chance that the Web team changed any fonts? WhatamIdoing (talk) 05:24, 20 July 2024 (UTC)

Thanks @WhatamIdoing for pinging me! We haven't changed any fonts recently. I will ask the teammates if they know what this may be about, though. SGrabarczuk (WMF) (talk) 20:29, 22 July 2024 (UTC)

Allow everyone to move pages in draftspace

I'm proposing that moving a page that's in draftspace to a target also in draftspace be an action that doesn't require being autoconfirmed. This is so if a draft is created in the wrong place by an IP, they can fix it themselves without going to RM, which they probably don't know exists. An example where this would have been useful is Moshe Mizrahi (basketball) which, according to its history, was created at Draft:Moshe Mizrahi ( basketball), moved to mainspace by an AfC reviewer at Moshe Mizrahi ( basketball) and only then moved to the correct title. This left behind a useless mainspace redirect that I had to RfD. If the IP could have moved the draft to the correct title, there is a good change they would have done so and the useless mainspace redirect would not have been created in the first place. Nickps (talk) 14:46, 18 July 2024 (UTC)

AfC reviewers should and usually do correct the titles of drafts when they move them to mainspace. If and until that happens, what they're called in draftspace doesn't really matter. – Joe (talk) 15:37, 18 July 2024 (UTC)

In theory, I agree that allowing anybody to move a draft to a different draft title would be fine. The problem is that (as far as I know), the MediaWiki permissions system isn't flexible enough to allow non-autoconfirmed moves only in specific namespaces, and the effort required to add that capability wouldn't be justified by the benefit. RoySmith (talk) 15:50, 18 July 2024 (UTC)

Well, similarly to how editors don't have to worry about performance, editors shouldn't worry about how easy or difficult something is to implement either. I'll take it to Phabricator and let the devs worry about it. What we need to figure out is just whether there is any reason not to do it. Nickps (talk) 16:46, 18 July 2024 (UTC)

Please post the phab number here when you get one. RoySmith (talk) 16:47, 18 July 2024 (UTC)

Wait, before I do, are you sure that's right? We can limit who moves a page like we do with Files and Categories. Is there a reason we can't go the other way around with drafts and lift a restriction? Nickps (talk) 16:55, 18 July 2024 (UTC)

For now I just asked VPT to come here. Nickps (talk) 17:00, 18 July 2024 (UTC)

My understanding is that moving a page requires the "move" user permission. The Files and Categories namespaces are special-cased by the movefile and move-categorypages permissions, but I don't believe there is any general-case ability to apply the move permission to arbitrary namespaces. RoySmith (talk) 17:12, 18 July 2024 (UTC)

This seems like a solution in search of a problem. A non-autoconfirmed editor who notices that a page is misnamed and successfully moves it will be a rare creature indeed. Meanwhile, any regular editor can move a draft page to the correct name in Draft space, and AFC editors should be checking the name. It's right there in step 1 of accepting an AFC: "Select an appropriate name". – Jonesey95 (talk) 19:13, 18 July 2024 (UTC)

You are mostly correct. However, a) AfC reviewers don't always do that as my example demonstrates and b) even if we ignore that, I believe that we should be providing as much freedom to users as possible. Locking actions behind user rights should be done only when necessary, not merely because it's convenient. Restricting moves in mainspace makes sense because move vandalism is disruptive. In draftspace that is way less of a problem and if necessary, move semi-protection exists. Nickps (talk) 19:35, 18 July 2024 (UTC)

To be fair, your example is eight years old, was corrected in less than four hours, and the AfC reviewer that accepted it has been banned for years. Do you have any idea how frequent this problem is? I take your point that technical implementation isn't our job, but some sort of cost–benefit analysis still wouldn't go amiss, and I'm sure the devs will ask for one anyway. – Joe (talk) 21:38, 18 July 2024 (UTC)

I'm not sure how I could gather frequency data for this situation but, here's a recent example of a non-autoconfirmed (at the time) editor asking to move a draft to a new title in WP:RM/TR. So it's not like the feature would go unused. Nickps (talk) 01:24, 19 July 2024 (UTC)

Also, going back to the original RfD that inspired this, we find Draft:Marabella North Secondary School ( Marabella Senior Comprehensive), Draft:Philip Dukes ( Viola Soloist) and Draft:Argo ( Sword Art Online ) which were all moved to mainspace to the uncorrected names. That last one might have been a cut and paste since the move log is empty but Argo ( Sword Art Online ) was created all the same. Nickps (talk) 01:51, 19 July 2024 (UTC)

Draft authors usually want to move to mainspace, not another draft name. Giving them a move link and move form which doesn't work for mainspace may confuse and annoy them more than help them. PrimeHunter (talk) 15:31, 19 July 2024 (UTC)

That's one way of looking at it. But, on the other hand, that move form would be the perfect place to put instructions for how to move to mainspace since people would look there. Something like: "This form can be used to change the name of the draft. Only autoconfirmed users can move drafts to the main namespace. If that is what you want to do, see WP:Articles for creation". Nickps (talk) 19:25, 19 July 2024 (UTC)

@RoySmith phab:T370471 has now been opened. Nickps (talk) 19:30, 18 July 2024 (UTC)

I would worry about draft hijacking. BD2412 T 02:18, 19 July 2024 (UTC)

All I hear is "Encourage move vandals to focus on the Draft: space", and I don't think I like what I hear. WhatamIdoing (talk) 05:27, 20 July 2024 (UTC)

This seems less like a solution in search of a problem than a problem in search of a problem. Non-autoconfirmed editors don't need the ability to move pages, and the most common use case (moving their user sandbox to Draft:Title) wouldn't even be covered, since it would cross namespaces. On the other hand, this would open up a broad attack surface for very little benefit. Folly Mox (talk) 09:38, 21 July 2024 (UTC)

I see some comments saying that this will increase vandalism in draftspace but very little evidence to support this view. In my opinion, until someone provides such evidence, restrcting IPs' ability to move in draftspace goes against WP:SOP#2 as it fails to meet the standard of strict scrutiny. Nickps (talk) 12:06, 21 July 2024 (UTC)

WP:SOP#2 doesn't have anything to do with this proposal. Not giving IP addresses/un-confirmed editors the ability to move pages is a technical anti-spam/anti-vandal measure, since moves are demonstrably much harder to undo than plain edits. Sohom (talk) 19:57, 21 July 2024 (UTC)

Such a measure makes sense on mainspace sure, but not on draftspace which is not as popular of a target for vandals and where the damage isn't as front facing. SOP#2 has everything to do with it since it's an arbitrary restriction that targets new/unregistered users. Nickps (talk) 20:06, 21 July 2024 (UTC)

How would you revert a vandal who went on a vandalism spree and moved a few thousand drafts to Draft:<insert_random_expeletive_here> ? (Short answer, you couldn't, you would need to get hold of a page-mover (or if the vandal is more sophisticated, a admin) to undo the damage). Sohom (talk) 20:13, 21 July 2024 (UTC)

The thing you're describing isn't even possible. Moving a page to overwrite a page that already exists is not allowed (except WP:MOR but that is irrelevant). Can you provide an example of my proposal being harmful that can actually happen? Nickps (talk) 21:46, 21 July 2024 (UTC)

They don't have to all be the same random_expletive. (I am somewhat dismayed to discover that Willy on Wheels is a bluelink.) —Cryptic 21:59, 21 July 2024 (UTC)

Ok, in that case I'll just revert the moves like normal. Due to WP:MOR that should be easy. No need for a page mover. Nickps (talk) 23:27, 21 July 2024 (UTC)

Nickps, thank you for volunteering to clean up all the complicated chained page move vandalism your proposal would open the door to, but kindly read the room. Folly Mox (talk) 11:07, 22 July 2024 (UTC)

When I think the room is wrong, I'm going to say so, thank you very much. Also, I'm not just saying it, my actions support it as well. Nickps (talk) 11:12, 22 July 2024 (UTC)

And just to be clear, yes, I'm saying that I'm going to be watching Recent Changes if we do this. Nickps (talk) 11:27, 22 July 2024 (UTC)

I'll try to spell it out a bit more, it takes the vandal exactly one more edit to each page for it be effectively irreversible without admin/page-mover help. Also, I assume you will not be reading RecentChanges, all the time 24 * 7 * 365 hours.

Your previous actions proves the opposite, that we already have to deal with a fair bit of page move vandalism, and we don't want to enable features that opens us up to more of the same kind of vandalism. Sohom (talk) 12:12, 22 July 2024 (UTC)

Again, no one has shown that this draftspace move vandalism will actually happen let alone that our processes will be overwhelmed by it. Up until that is shown, I can only consider such statements fear mongering. But, as I'm willing to compromise, I suggest we at least do a trial of this and see whether I'm right and constructive moves are the rule or you're right and move vandalism overwhelms our processes.

I have to also point out that we do have the tools to deal with move vandalism. Semi-move protection is already a thing and page movers/admins can revert more advanced vandalism. If you're worried about me pushing work to other people, rest assured that if the kind of vandalism you describe actually happens, I'll go directly to WP:PERM/PM. Nickps (talk) 12:24, 22 July 2024 (UTC)

"0 days ago" in time duration calculation

Reading the July 2024 global cyber outages article one notices in the infobox that the incident happened "0 days ago". Shouldn't that be "today" or "Today" instead? Nxavar (talk) 10:32, 19 July 2024 (UTC)

• This was raised a year ago at Template talk:Time ago#Unnatural "0 days ago" and "0 days' time" by Brightgalrs, but it didn't receive a reply. Based on the history of Module:Time ago, Mr. Stradivarius, Johnuniq and GreenC appear to be the people to ask. Thryduulf (talk) 11:09, 19 July 2024 (UTC)

Thanks for pointing this out. Nxavar (talk) 14:38, 19 July 2024 (UTC)

Looks like it was discussed about a year ago at Template_talk:Time_ago. I don't think anyone has volunteered to add this feature, nor is it the result of anyone's previous work causing it, more like a design question than a bug, best way to say "now". Could also try WP:TEMPREQ for help. -- GreenC 15:49, 19 July 2024 (UTC)

It really feels like the most expedient solution would be to use Template:Start date and switch to Template:Start date and age after a day has passed. Firefangledfeathers (talk / contribs) 16:01, 19 July 2024 (UTC)

"Today" isn't the same day everywhere in the world. "0 days ago" indicates less than 24 hours ago, which could include "yesterday" in some time zones. WhatamIdoing (talk) 05:30, 20 July 2024 (UTC)

So have it say "Less than 24 hours ago" or "Less than 1 day ago" instead of "0 days ago" Soni (talk) 03:42, 24 July 2024 (UTC)

Legalize "subsection" parameter of template "imdb title"

There are 20 thousands of pages which refer to a movie's IMDB title page subsection. They can't use Template:IMDb title because the template doesn't document how to link to a subsection.

Even current template allows doing that via undocumented trick (although that produces a warning) - just add /section to the movie id. Example: test at IMDb.

So I propose - either document this trick and make it official, or add another parameter to the template. fuxx (talk) 18:52, 20 July 2024 (UTC)

{{IMDb title}} is meant for an external links section, not a reference. There is rarely reason to link a subsection there. IMDb is a deprecated source for references: WP:IMDb. PrimeHunter (talk) 00:22, 21 July 2024 (UTC)

Does the community still want moved pages to be unreviewed

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.

Does the community still want this feature implemented? (cc @Pppery, @Hey man im josh and @Novem Linguae who participated in an initial discussion on the NPP Discord server, also see T370593) Sohom (talk) 07:44, 21 July 2024 (UTC)

Taking my developer hat away, I personally don't think this should be implemented anymore. Sohom (talk) 07:54, 21 July 2024 (UTC)

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)

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)

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

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)

• 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)
• Strong oppose per nom and Josh. Reviewers already are swamped as it is. (t · c) buidhe 14:53, 21 July 2024 (UTC)
• Oppose on the merits. I agree this is unnecessary and wasteful. But this discussion needed to be had and formally codified anyway to avoid unintentional cabalish behavior /WP:CONLEVEL problems. * Pppery * _{it has begun...} 15:19, 21 July 2024 (UTC)
• 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)

  Hmmm, maybe I should have restricted this to mainspace? But I'll let somebody with better SQL-fu than I have play with it. RoySmith (talk) 15:34, 21 July 2024 (UTC)

  It's even worse than that - there were more moves in mainspace yesterday than there were total curations. —Cryptic 16:27, 21 July 2024 (UTC)

  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. —Cryptic 16:55, 21 July 2024 (UTC)

• 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)
• 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)
• 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)
  • That makes more sense. Numbers for July 20 and all of July. —Cryptic 20:02, 22 July 2024 (UTC)
• ??? 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)

Adding a slight speed bump to slow down revert wars.

There's a editor's notice right now on a really contentious page: "You must follow the bold-revert-discuss cycle if your change is reverted." My reaction was, "Good idea. Reverting a revert never seems to end well. Maybe that rule should apply to all pages."

Yes, I know, that's not going to happen. But we can nudge people in that direction. How about a feature detects this and makes the user confirm that's what they want to. "We see you want to revert a revert. This is often viewed with antagonism. Please consider using the BOLD, revert, discuss cycle instead."

And if the user still wants to revert, they can, but at least we've slowed down the madness a tad. Isaac Rabinovitch (talk) 15:34, 23 July 2024 (UTC)

There is an opt-in script (preference?) (although I can't remember where to find it) that asks you for confirmation before actioning a rollback. The intent of this is to avoid accidental rollbacks, IIRC there was a discussion that rejected making it opt-out because it hinders vandal fighting and similar activities, although this was quite a long time ago and consensus may have changed with the rise of tools like huggle, etc Thryduulf (talk) 15:48, 23 July 2024 (UTC)

That is legitimately a good idea in my opinion, although it should be noted that WP:BRD is only an essay and technically optional. Wikipedia:Edit warring, which is policy, could be a better basis for a reminder if a revert-of-revert is detected, and I don't object to the text itself mentioning BRD if it is clear that it's optional (but encouraged).

The functionality itself might need some MediaWiki software tweaking to be implemented, but I'm not a specialist. Chaotic Enby (talk · contribs) 15:51, 23 July 2024 (UTC)

It is difficult to slow down revert wars without slowing down vandal fighting. —Kusma (talk) 16:38, 23 July 2024 (UTC)

You must follow the bold-revert-discuss cycle if your change is reverted. Is that a thing? Or it's just an ordinary editor writing that? Selfstudier (talk) 16:52, 23 July 2024 (UTC)

Awilley added this to Template:American politics AE a few years ago. I assume this was related to his Enforced BRD idea. I don't think it makes sense to tell editors that they must follow an optional process, but WP:EPTALK (which is mandatory for all editors) is less well-known, and perhaps they couldn't get consensus for imposing WP:1RR. WhatamIdoing (talk) 17:00, 23 July 2024 (UTC)

Bit like WP:CRP. Selfstudier (talk) 17:06, 23 July 2024 (UTC)

I'm concerned about how this would impact anti-vandalism, especially when you can't seem to get ahold of an admin to block or protect. It won't matter to a vandal if it takes an extra click and five or ten seconds to re-deface a page; it will matter if takes longer to revert them. Slowing down fights over content disputes is all well and good, but not when the WP:WRONGVERSION is one full of profanity. —Cryptic 17:49, 23 July 2024 (UTC)

Although I am an admin, I do not particularly focus on antivandalism, and in my experience, before I turned on requiring a confirmation prompt for a rollback, I was accidentally rolling back edits far more often than I used rollback for vandalism. In fact, when I do have to revert a lot of edits I still prefer to verify that each edit is indeed vandalism. I think that the 'requiring an affirmative prompt before rollback' setting should be optout rather than optin. Donald Albury 18:08, 23 July 2024 (UTC)

This is a potential application of edit check that is being explored, I believe. Sdkb ^talk 04:08, 24 July 2024 (UTC)

This seems like a good idea, and I'm not concerned about its impact on anti-vandalism. It isn't the end of the world if vandalism is reverted a few seconds later; and it will help cut down on accidental or over-zealous reverts. Cremastra (talk) 00:20, 25 July 2024 (UTC)

What does vandalism have to do with this idea? I'm not talking about making it harder to revert other people's edits. I'm talking about making it harder to do a double revert. Isaac Rabinovitch (talk) 11:32, 25 July 2024 (UTC)

1. Vandal replaces the lead image of a highly-viewed but not-currently-protected article with a freshly-uploaded dickpic at some time after most US admins have gone to bed and before most European admins have woken up. 2. Cluebot immediately reverts. 3. Appalled bystander immediately tags the image on Commons for speedy deletion and asks for the vandal to be blocked at WP:AIV. 4. Vandal makes the same edit, which is a revert of Cluebot; it's slow because of the new revert-of-a-revert feature, but he doesn't mind. 5. Entire group of appalled bystanders try to revert the vandal; it's slow because because of the new revert-of-a-revert feature, and Cluebot doesn't intervene because it doesn't re-revert the same page. 6. Entire group expands their futile pleading for help to WP:RFPP and WP:ANI. 7-20ish: repeat steps 4 and 5 and occasionally 6 until an admin intervenes.

The problem here is that it's making step 5 slower, no matter how large the entire group of appalled bystanders is or how quickly they react. —Cryptic 14:12, 25 July 2024 (UTC)

How often have you seen this happen? Vs how often have you seen revert wars? Isaac Rabinovitch (talk) 14:19, 25 July 2024 (UTC)

This exact scenario? Never, because we don't have this exploitable misfeature you're proposing that makes reverting vandalism arbitrarily slower. Non-exactly-repeated vandalism that persists for dozens of reverts before an admin puts a stop to it? All the time. Try searching the ANI archives for, say, AIV backlogged. —Cryptic 14:33, 25 July 2024 (UTC)

@Cryptic I'm a bit confused, because I don't see a proposal to implement a cooldown timer. Steps 5 and 6 would be "5. Entire group of appalled bystanders try to revert the vandal, get a message asking them to confirm, and hit 'OK'. 6. Entire group moves on with their lives." --Ahecht (TALK
PAGE) 15:32, 25 July 2024 (UTC)

This can't be done in a client-side javascript "Are you sure?" popup like the existing, optional ones for rollback links. There needs to be a roundtrip to the server to find that the attempted edit is a revert, and that at least one of the edits it's reverting was itself a revert, and then kick it back to the user. Besides, the last sentence of the proposal - but at least we've slowed down the madness a tad - makes the goal explicit; if it's not appreciably slowing down a vandalism rerevert, it's not accomplishing its stated purpose anyway. —Cryptic 15:41, 25 July 2024 (UTC)

Although I agree with the spirit behind the idea, I can't help but think that the existing policies rules and guides are sufficient. If an editor is intent on BRRD, for example, there is not much to be done about it except to take it up in talk, if an editor were continuously making use of BRRD to try and force through their view, then that's a behavioral problem and should be dealt with as such. One could ask an admin to impose WP:CRP if the issues were causing disruption. And so on.Selfstudier (talk) 16:12, 25 July 2024 (UTC)

Bot to restore long-term protections after shorter-term higher protections expire

A recurring issue with page protection is that long-term protections are sometimes overwritten by shorter-term protections at a higher protection level. When the shorter-term protection expires, administrators need to manually restore the previous lower protection level. For example, Beyoncé is indefinitely semi-protected due to vandalism and was recently fully protected due to edit warring. When the full protection expired, semi-protection needed to be restored manually by an administrator (more examples: 162794559, 162856607, 162974964, 163272356, 163337925). In addition to this happening after full protection due to edit warring, it also happens with ECP being applied to previously semi-protected articles.

Right now, administrators need to remember on their own, set a reminder, or rely on someone submitting a reprotection request on WP:RFPP. Unfortunately, disruption can be the result when the restoration of protection is delayed too long. Also, concerns about timely restoration can influence administrators to choose an approach other than protection when protection would have been their first choice in some situations.

The bot will not take any action if the duration of the higher protection level extends beyond the prior protection's expiration date, or if the protection level is the same or lower.

Following the requirements in WP:ADMINBOT, I'm requesting community approval before requesting approval at WP:BRFA. Thanks. Daniel Quinlan (talk) 02:47, 24 July 2024 (UTC)

This is a great idea. It would be helpful for the protection log entry to note the original protecting admin, the one responsible for the long-term protection. Firefangledfeathers (talk / contribs) 03:04, 24 July 2024 (UTC)

Definitely! I also plan to include the originally logged reason. Daniel Quinlan (talk) 03:09, 24 July 2024 (UTC)

Thanks, this would be very helpful. Johnuniq (talk) 03:31, 24 July 2024 (UTC)

Great idea. I've had to badger too many admins to reapply protections in similar scenarios. – Aza24 (talk) 06:10, 24 July 2024 (UTC)

I'm definitely not the first person to have the idea. After I starting looking into this, I found more than a few previous discussions (which also helped me iron out some details), such as this proposal for a bot in 2017. Starting with this task, I'm hoping to alleviate some of the drudgery I've experienced as an administrator helping out on WP:RFPP. Daniel Quinlan (talk) 08:56, 24 July 2024 (UTC)

I should also mention https://phabricator.wikimedia.org/T41038 which is from 2012. In the absence of a solution built into MediaWiki, a bot seems like the best approach and I'm volunteering to maintain and run it. Daniel Quinlan (talk) 09:21, 24 July 2024 (UTC)

As I mentioned on discord, and at m:Community Wishlist/Wishes/Restore long term protection when short term protection expires. This would be super handy. ScottishFinnishRadish (talk) 10:48, 24 July 2024 (UTC)

I agree this would be useful functionality. I'n not sure implementing it as a bot is the right approach (but I won't oppose the idea either). T194697 covers the same idea for blocks; all the reasons given there apply equally well to page protections. RoySmith (talk) 12:05, 24 July 2024 (UTC)

I feel like this has been raised before and went nowhere, though I might be misremembering. In any case, yes, this is functionality that should exist, whether as a bot or part of the protection interface. Vanamonde93 (talk) 17:59, 24 July 2024 (UTC)

Ah, now I remember why this sounded familiar: Wikipedia:Bots/Requests for approval/DYKToolsAdminBot. RoySmith (talk) 20:14, 24 July 2024 (UTC)

This would be useful functionality. May I suggest that the bot also drop a templated message about its actions at the user talkpage of the (non-bot) admin who most recently protected the page, so that they can undo/adjust the bot's page-protection if needed? Abecedare (talk) 02:29, 25 July 2024 (UTC)

Full support here. One would think this would just be in the MediaWiki code by now... EggRoll97 ^(talk) 21:41, 25 July 2024 (UTC)

Organized toolbar

I've tried making the toolbar a bit more orderly: https://snipboard.io/12CV83.jpg. Infogiraffic (talk) 09:19, 24 July 2024 (UTC)

"Has wiki in the name vs. not" isn't that useful of an organizational principle to me. Sdkb ^talk 12:15, 24 July 2024 (UTC)

In this example, how do Blame and Wikiblame differ? Folly Mox (talk) 17:55, 25 July 2024 (UTC)

Idea lab

Resources on severe mental illness pages

For example, on the pages for “Eating Disorders” and “Anorexia Nervosa” include a section about what hotlines and organizations are available for eating disorder treatment in predominantly English-speaking countries. It’s very likely that struggling individuals may come to wikipedia to learn more about what they’re dealing with, and how someone can access information about treatment is objectively relevant to the topic. Ju1c3machine (talk) 09:34, 24 June 2024 (UTC)

I'm often one to call out "that's not what Wikipedia is for", but I actually agree. Considering it purely from the perspective of building an encyclopedia, treatment and how people seek it is a legitimate aspect of its coverage, and an article is incomplete without it. I'd also say that these sort of resources are relevant external links that would be appropriate to include at the bottom of their article—maybe even in their own subsection under external links if applicable. Thebiguglyalien (talk) 22:52, 24 June 2024 (UTC)

Might be worth perusing a recent (2022) discussion on adding suicide hotline numbers to related articles, as it seems pertinent. Link to discussion Schazjmd (talk) 22:59, 24 June 2024 (UTC)

One question is, who would be responsible/liable if a reader suffers harm from following a no-longer valid or malicious link from such a page? That is why we have disclaimers on pages about medical topics. Donald Albury 23:09, 24 June 2024 (UTC)

If a link becomes invalid, how is that any different from other links being caught and updated by editors? Wiki isn't providing services so there's no liability issues- same as if the Yellow Pages contained a hotline that went out of order. Ju1c3machine (talk) 13:49, 25 June 2024 (UTC)

How does one decide which organisations are worthy of having their hotlines mentioned? There are far too many organisations for these issues to include all of them and having to subjectively decide on them is bound to cause more problems than it is worth. Where would you even include it either, anywhere near the top would cause issues with those who simply want to read an article and if they're at the bottom they'd be quite useless. Traumnovelle (talk) 08:11, 20 July 2024 (UTC)

For Wikipedia:Stand-alone lists, it would be possible to be comprehensive. A list of several hundred short items is not unreasonable.

Within an article, editors should use the ordinary methods of determining article content. For example, what was the first or most historically important service? "____ became the first charity to offer helpline services via SMS texting" is appropriate encyclopedic content.

Second, once you look outside the suicide/crisis category, there are often very few of these services. For example, the US appears to have three hotlines for eating disorders: two general ones, and one specifically for insulin-dependent diabetics. That's it. The UK appears to have one. It would not be difficult to construct a sentence that says something like "In the UK, free support services, such as a helpline, are offered by the charity Beat". WhatamIdoing (talk) 20:50, 21 July 2024 (UTC)

There are more than 50 English speaking countries. Also having to choose which services are mentioned by name is obviously problematic, especially if it isn't already summarised in a secondary source. Traumnovelle (talk) 03:42, 22 July 2024 (UTC)

section break 1, mental health topic

Personally, when seeing this, I was curious what other encyclopedias that exist in part/whole online do regarding this, so I went to a few to check. Let me preface this by saying I don't think it's a valid comparison to compare Wikipedia to a print encyclopedia for something like this, because we aren't ever complete and that's okay in part because we are online and perpetually being improved and updated. My opinion and analysis of policies/guidelines is after the list:

• Encyclopedia Brittanica - suicide suicide resource box on the side of the page, depression (psychology) crisis information within the first paragraph, no information on article "bipolar disorder", no information on article "schizophrenia".
• Encyclopedia.com - suicide basics discusses suicide hotlines existing but no specific links/numbers, depression again discusses their existence, and recommends checking "telephone books' [...] Community Service sections [... or] calling emergency services (911 in most places) but this is at the bottom of this long page. Has an article on "crisis intervention" that doesn't list specifics or how to find. Nothing on article "substance abuse". Of note, however, is that some of these articles have "resources" sections that do list specific phone numbers and/or websites for organizations providing hotlines.
• The Canadian Encyclopedia - suicide info at top of article, mental health nothing in article, but links to a couple hotlines in the external links section at bottom of page, Suicide among Indigenous Peoples in Canada info at top of article.

The biggest issue people have with us including them is "scope" or similar. These arguments necessarily reference what Wikipedia is not - either directly or through essays/etc. Relevant policies, guidelines, and essays that have been referenced before or likely to be referenced now are below - along with my analysis of why they don't preclude mental health information from being provided on pages:

• From WP:NOT: Advertising, marketing, publicity, or public relations... or issuing public service announcements - nobody's asking for "public service announcements" style of information. What people are asking for seems to be similar to what The Canadian Encyclopedia publishes on their articles directly about suicide. Also from WP:NOT: Simple listings without contextual information showing encyclopedic merit. Listings such as the white or yellow pages should not be replicated. - this is referencing actual lists that are not encyclopedically relevant, not what's being requested here.
• From WP:ADVOCACY: Wikipedia is first and foremost an encyclopedia which aims to create a breadth of high-quality, neutral, verifiable articles and to become a serious, respected reference work. - as shown above, many encyclopedias do publish resources as part of their encyclopedic mission. Also from Wikipedia:Advocacy § Identifying advocacy: Some editors come to Wikipedia with the goal of raising the visibility or credibility of a specific viewpoint. It may be a hypothesis which they feel has been unduly dismissed or rejected by the scientific community; it may be alternate or revisionist interpretation of a historical event or personage; it may be additions to an article about an organization to portray it in a positive or negative light. The essential problem is that these goals conflict with Wikipedia's mission. Wikipedia is not a venue to right great wrongs, to promote ideas or beliefs which have been ignored or marginalized in the Real World, or to be an adjunct web presence for an organization. Wikipedia cannot give greater prominence to an agenda than experts or reliable sources in the Real World have given it; the failure to understand this fundamental precept is at the root of most problems with advocacy on Wikipedia. - resource information is not advocacy by any definition. The only applicable part of this could be "an adjunct web presence for an organization", but even that doesn't really apply, since nobody is advocating for any specific organization to be represented, but general information. The potential for the resources to be used to advocate for specific organizations can be handled through guidelines on how the specific information displayed is to be selected, where it is to be displayed on the page, and carefully selecting which pages they do display on.
• No Righting Great Wrongs is also commonly referenced - but it doesn't apply here. You might think that Wikipedia is a great place to set the record straight and right great wrongs, but that is absolutely not the case. While we can record the righting of great wrongs, we can't actually "ride the crest of the wave" ourselves. - there is no "record" attempting to be "set... straight", and in fact, we wouldn't be "rid[ing] the crest of the wave ourselves". Many encyclopedias that are online include these resources already, and in fact many non-encyclopedia websites do too. We would be following, not leading, in that sense.
• The 5 pillars - Wikipedia is an encyclopedia - Wikipedia combines many features of general and specialized encyclopedias, almanacs, and gazetteers. - again, as showed above, encyclopedias do contain this sort of information sometimes.
• Wikipedia:No disclaimers - A disclaimer in a Wikipedia article is a statement or warning that the article is not appropriate, suitable, or guaranteed for some specified purpose. - again, not what's being requested here. While some may desire for these notices to include a statement about what is included in the article, that is not what the basis of this is about. Again, see The Canadian Encyclopedia - a simple statement To reach the Canada Suicide Prevention Service, contact 1-833-456-4566. would suffice, even without the first sentence they include about the content of the article.
• Wikipedia:External links - External links normally should not be placed in the body of an article. Nobody is proposing they be placed in the body of the article, but instead in a header or infobox style. And to note, infoboxes already allow external links in them, so there's a huge precedent for external links not being relegated to the bottom of the page when placing them at the top is more useful to our readers. Some acceptable external links include those that contain further research that is accurate and on-topic, information that could not be added to the article for reasons such as copyright or amount of detail, or other meaningful, relevant content that is not suitable for inclusion in an article for reasons unrelated to its accuracy. Pretty clear that this is "further research..." and is "other meaningful, relevant content that is not suitable for inclusion in the article".
• Arguments are also made that the information may become outdated, become malicious, not work when a reader clicks them... but these sorts of arguments don't affect our ability to put other external links in articles, even in the infobox. As always, Wikipedia is never finished, and these notices could be crafted in a way that allows (trusted) editors to update them when necessary. And that's actually the benefit of an online, everyone-can-edit encyclopedia over a print one - a print encyclopedia would not be able to be updated on the spot if/when resources change. Hence why I do not think comparing us to print encyclopedias here is reasonable - because they do have this as a valid reason to not put information into their print versions.
• Last thing I'll address in these bullet points is the question of liability that Donald Albury brings up above. To make a slight correction, we do not have disclaimers on medical articles - but the reason we don't is the general disclaimer at the bottom of every page on the wiki. We also have the medical specific disclaimer, but that isn't actually linked directly from the bottom bar, and per our guidelines on disclaimers, shouldn't be linked in specific articles either. If those disclaimers suffice to protect us from liability from pages that explicitly detail current medical practice, and even more so, pages like crisis hotline, rape, suicide, and more to have external links to, phone numbers for, information about, and images that reference them now... then those same disclaimers will protect us if the same information is presented in a different manner/place on the page. If this sort of proposal is further developed, it would be prudent to confirm with legal the wording/etc to ensure they're aware - but they've really never prior regulated the wording of content in that sort of way.

To be quite honest, this is a stylistic decision, and only a stylistic decision. Not an issue of whether it's encyclopedic or not, because other online encyclopedias do include this information at least sometimes (and again, we follow, not lead). Not an issue of whether a link would violate our policy on external links, because such links would meet the three criteria listed there: Is the site content accessible to the reader? Is the site content proper in the context of the article (useful, tasteful, informative, factual, etc.)? Is the link functioning and likely to remain functional? (emphasis mine). It's not trying to right a great wrong, because there is no "great wrong" being righted, this would be purely informational in nature. It's not a disclaimer, because nobody's suggesting this be simply be a warning about what follows in the article (which would be a disclaimer), but to more prominently place relevant and helpful information towards the top of the article in some way. Not advocacy, because nobody is suggesting we advocate for anything - providing this information at the top of the article(s) in question would serve an informational purpose for our readers. While it's certainly within us editors' discretion as a community here to decide "we don't want to provide this information", there's really no policy reason that we can't. And even if there was, If a rule prevents you from improving or maintaining Wikipedia, ignore it. Wikipedia exists to be an encyclopedia - "A comprehensive reference work (often spanning several printed volumes) with articles" - and to provide useful articles for readers... in a way that the reader will understand and find interesting. Whether we want to admit it or not, some readers will be directed to Wikipedia when they are searching for information about suicide, mental health, rape, etc. and currently, the primary place they will see it is the very end of articles in External Links - which does not serve our readers who will in a time of distress see a long article and likely never make it to the EL section. For all of the above reasons, I support further discussion, and workshopping of an infobox or top-banner style notice to be placed on pages that would provide this information. I would be happy to workshop some examples of formatting if it would be beneficial to this discussion or an eventual RfC, but I would need others to input on the best way to provide geographically relevant information - is it that the banner links to a separate page (whether in article space, project space, or elsewhere) that contains resources by country/location? Or is it the use of geo-notices as proposed here? Or is there another way that wouldn't require the user to click through to a separate page? -bɜ:ʳkənhɪmez (User/say hi!) 01:00, 25 June 2024 (UTC)

"Whether we want to admit it or not, some readers will be directed to Wikipedia when they are searching for information about suicide, mental health, rape, etc. and currently, the primary place they will see it is the very end of articles in External Links" That's funny. I would have thought that the primary place they would find such information is the articles themeselves. If I were looking for help, therapy, treatment, etc for such things, I wouldn't go to the article about them. I would do a search for "suicide helpline" or "rape crisis center", etc. Sorry, but you still fail to show that WP:NOT doesn't apply. User:Khajidha (talk) (contributions) 13:26, 25 June 2024 (UTC)

It's completely reasonable that someone that suspects they may have a mental health problem may do research about it to see if it really does line up with what they're experiencing. Providing this information in no way detracts from the usefulness of Wikipedia- the only possible effect is positive. Ju1c3machine (talk) 13:47, 25 June 2024 (UTC)

That's not what the original poster is asking to add. That's what should already be in the article. --User:Khajidha (talk) (contributions) 14:07, 25 June 2024 (UTC)

I am the original poster- I'm saying that if someone is researching a condition, it might be because they're thinking they have it, so including resources would be helpful. Ju1c3machine (talk) 14:31, 25 June 2024 (UTC)

Which are you looking to add 1) details about the disorder to "see if it really does line up with what they're experiencing" or 2) places to go for an actual diagnosis, because these are different things. The first is encyclopedically relevant, the second isn't. --User:Khajidha (talk) (contributions) 14:46, 25 June 2024 (UTC)

I'm asking to add resources such as official government sponsored hotlines, because if someone is on the page for a mental illness they think they might have, where to find treatment is relevant and helpful information. Ju1c3machine (talk) 17:57, 25 June 2024 (UTC)

No, the most likely effect will be that more people will rely on Wikipedia to give them information about helplines, etc., rather than on more relevant and more complete websites. Chaotic Enby (talk · contribs) 17:32, 25 June 2024 (UTC)

As mentioned before, news sites commonly include hotlines at the end of articles about suicide- I don't think anyone has drawn the conclusion that they should head to the NYT for mental health information. Ju1c3machine (talk) 17:58, 25 June 2024 (UTC)

We're not a news site. What they do is completely irrelevant. --User:Khajidha (talk) (contributions) 11:41, 26 June 2024 (UTC)

What IS relevant is that other online encyclopedias do, as mentioned above. Ju1c3machine (talk) 16:04, 26 June 2024 (UTC)

section break 2, mental health topic

I don't see an issue with making a cat hall page to list "recognized" resources for mental health type issues, with "recognized" being either official govt resources (like 988 for the Suicide hotline) or from expert, well known medical organizations in that area. Since these can vary by country, a separate page makes sense, and which could be highlighted by a color keyed navbox. Masem (t) 14:21, 25 June 2024 (UTC)

I definitely agree that we might want to limit resources to those that are official/government funded instead of random organizations. Ju1c3machine (talk) 14:32, 25 June 2024 (UTC)

How many official/government contact points are we talking about? There are 193 members of the UN plus a few other generally recognized sovereignties, some breakaway states, a number of dependent territories, and many sub-territories (states, provinces, etc.), each of which may have their own resource contact points. So, do we concentrate on providing contact information only for political units with large populations? Sending people to on-line contacts which do not have a local presence will often not be enough. In some places, directing people with problems to official contacts may not be the best way to help them. Maintaining all of that information (protecting it from link-rot, vandals and well-meaning but ill-informed editors) is going to require work from volunteers (edit-protection or pending changes may help, but is not perfect). I am afraid that, based on the typical level of maintenance in Wikipeida projects, a page such as proposed here will end up giving unusable or even harmful information to people seeking help. Donald Albury 16:28, 25 June 2024 (UTC)

For article content, when the full list isn't feasible, we usually focus on large English-speaking countries plus anything with significance (the oldest, the biggest, etc.).

For external links, we would normally link to a web directory instead of maintaining anything ourselves (e.g., https://www.psychologytoday.com/us/basics/suicide/suicide-prevention-hotlines-resources-worldwide for suicide hotlines). WhatamIdoing (talk) 16:43, 25 June 2024 (UTC)

If this is on a separate list page, there is no reason not to include them all. One or multiple tables (organized by continent) can make for easy navigation. Subpages could be made for North America (US states and Canadian provinces) and any other country where there is such significant lower level govt involvement. — Masem (t) 16:44, 25 June 2024 (UTC)

I was thinking that keeping it to English-speaking countries would be enough, considering this is English Wikipedia. Ju1c3machine (talk) 18:02, 25 June 2024 (UTC)

That would cover more than 50 different countries. Traumnovelle (talk) 04:30, 21 July 2024 (UTC)

Is there a limit to how many countries we can provide information on? Ju1c3machine (talk) 12:07, 21 July 2024 (UTC)

I like the idea of a separate page or a template similar to a navbox, but I think that should only be a partial solution. Again, many articles already include resources (of varying quality and number) at the bottom of the page in the external links section. So adding more resources even further down on the page doesn’t really improve anything here. Maybe I misunderstood you? But I’d prefer it to be an info box style template (whether above, below, or incorporated into the info box if the article had one) with a sentence inviting people to click a link if all they want to see is the resources without having to scroll the article. -bɜ:ʳkənhɪmez (User/say hi!) 18:56, 25 June 2024 (UTC)

On the original idea, of having a section (or paragraph) in articles about various organizations/crisis lines, I think it's a good idea. If the article is organized along the suggested WP:MEDSECTIONS plan, then it would usually go under ==Society and culture==. For example, an article about suicide could mention 1-800-273-8255 (song).

In terms of ==External links==, Wikipedia:Manual of Style/Medicine-related articles#External links has recommended for years that local/city organizations be excluded (because even if we think it's great that one city has a support group meeting on Thursday mornings for that kind of cancer, that's really not useful information for the rest of the world), and that either a small number of national/international groups be considered for inclusion, or a link to a good Web directory (which does not have to be Curlie, and often shouldn't be). WhatamIdoing (talk) 16:37, 25 June 2024 (UTC)

• This is becoming a WP:Perennial proposals issue, but I have several reservations about this practice, however well-intentioned. The evidence of the effectiveness of suicide hotlines is inconclusive. Any endorsement of this health intervention is non-compliant with WP:MEDRS. The inclusion of such resources could a) be taken as condescending by people who have these conditions or b) could encourage faulty self-diagnosis, which would be very problematic. Encouraging the reader to think of their subjectivity as a potential victim of an illness can have deleterious psychological effects. Further, as Donald Albury notes, the work of actually verifying that any given hotline, even if government-sponsored, is actually sincere in its mission and serves to help those who call it represents a massive amount of volunteer effort on a global scale, with a very real risk of sending people to crisis lines that will cause them harm (due to insufficient patient privacy protections, due to inadequately trained personnel or ideologically rather than scientifically-driven therapy practices, etc.). The framing of this entire question feels like a response to a school-assembly PSA: why depression and anorexia? Why not schizophrenia, or BPD? What about illnesses that are not primarily mental, but which almost certainly see a significant amount of traffic from people who suspect that they've contracted them, such as gonorrhea or COVID? Crisis hotline disclaimers are a feel-good solution in search of a problem, and we will certainly find a can of worms' worth of problems if we implement it. _signed, Rosguill ^talk 17:09, 25 June 2024 (UTC)

  OP here- you might note that the original post uses anorexia as an example- if there are help lines for BPD and schizophrenia then I think those should be added as well. I"m not weighing in on physical illnesses because that's very clearly a matter for doctors, and it's a bad-faith argument to compare the two. "Here's where people that have this can get help'" is in no way condescending or encouraging self-diagnosis, and I'm pretty confused on how you drew that conclusion from what I said at all. Ju1c3machine (talk) 18:06, 25 June 2024 (UTC)

  I agree that it needs more discussion on what article(s) or topics this would display on. But the mere fact that discussion and hashing out are needed shouldn’t preclude a proposal from moving forward. -bɜ:ʳkənhɪmez (User/say hi!) 18:57, 25 June 2024 (UTC)

  I thought so too, so I added WP:PEREN#Add prominent links to crisis hotlines on relevant articles a few days ago. We'll still have to let this one play out though. Anomie⚔ 01:52, 27 June 2024 (UTC)

  I think that was premature. WhatamIdoing (talk) 20:40, 27 June 2024 (UTC)

  I think it was warranted after the previous discussion in April, following the two in September 2022, following the one in 2019. I just didn't get around to it then. But once this one goes the same way with respect to banners or notices in the lead, we can re-add it. 🤷 Anomie⚔ 23:03, 27 June 2024 (UTC)

  But will it? So far, I see nobody objecting to adding some information about the existence and work of support organizations in the body of the article. I think that means there is support for including that information. WhatamIdoing (talk) 01:51, 28 June 2024 (UTC)

  I recommend reading section 3 of this discussion, there are definitely notable arguments against from @Chaotic Enby and @AddWittyNameHere. Ju1c3machine (talk) 04:16, 28 June 2024 (UTC)

  I didn't reply under section break 3, but I am very much not opposed to adding information about support organizations in a verifiable and WP:DUE encyclopedic way. What I take issue with is a list of miscellaneous external links, but that's something else. Chaotic Enby (talk · contribs) 04:23, 28 June 2024 (UTC)

  Whoops, sorry, just woke up and operating pre-coffee over here. I do think that having a separate page of resources sorted by country is the best solution at this point, but I do feel like it's going to spiral into me creating wiki articles for each organization and their work/history eventually... Ju1c3machine (talk) 04:37, 28 June 2024 (UTC)

  That would be amazing, that's how the encyclopedia grows! Chaotic Enby (talk · contribs) 04:48, 28 June 2024 (UTC)

  Perhaps you should re-read what I actually wrote, below and there and at Wikipedia talk:Perennial proposals, instead of setting up a strawman? Anomie⚔ 10:46, 28 June 2024 (UTC)

The idea needs some workshopping and refinement, but I support in principle. The page/template would need to be 30/500 protected at minimum, but full or templateeditor protection would be preferable because it would be a definite target for trolls. It might also be worth opening a dialogue with the Foundation to see if they or Trust & Safety might want to give some input. They might even have some resources or a grant for maintaining it. The Wordsmith^{Talk to me} 17:19, 25 June 2024 (UTC)

Pages aren't protected preemptively, and trolls are virtually never extended-confirmed so I don't see what full protection would bring in this case, except making it much harder to add new entries assuming the proposal goes through. Chaotic Enby (talk · contribs) 17:25, 25 June 2024 (UTC)

Articles are usually not pre-emptively protected, though there are some exceptions like Today's Featured Article when it's on the Main Page. Other high-risk pages like the Main Page itself are protected, and we have an entire guideline allowing high risk templates to be pre-emptively protected on a case-by-case basis. Regarding the WP:NOT argument, I think there's a valid WP:IAR exemption that can be justified on humanitarian grounds. The Wordsmith^{Talk to me} 17:42, 25 June 2024 (UTC)

Today's Featured Article is only preemptively protected because previous TFA were repeatedly targeted, and is still only semi-protected. The only preemptively full or template-protected pages, high-risk templates are protected because they are transcluded on tens of thousands of pages and can cause immediate widespread damage to the encyclopedia, while not needing regular updates. A list of information on many organizations will definitely need regular updates, while not being transcluded to the same scale as citation or infobox templates, so full protection is very much not needed. Chaotic Enby (talk · contribs) 18:20, 25 June 2024 (UTC)

Sorry, but this still falls under WP:NOT. You have still not demonstrated why Listings such as the white or yellow pages should not be replicated. does not apply here, especially with the proposal of making separate pages for this information. Chaotic Enby (talk · contribs) 17:29, 25 June 2024 (UTC)

Information on organizations that treat or provide assistance with a disease is objectively relevant to the Wiki pages aimed to provide information about that disease. Even if that were not the case, I also agree with The Wordsmith on there being a valid exemption to the rule for humanitarian reasons. Ju1c3machine (talk) 18:10, 25 June 2024 (UTC)

See WP:NOTIAR. As pointed by multiple people above, it is not even clear that this would be an improvement to begin with, let alone an improvement to our purpose of being an encyclopedia, and making an exception for "humanitarian reasons" would open the door to a lot more non-encyclopedic stuff that could be justified on the same grounds (humanitarian fundraisers, advocacy groups, etc.) Chaotic Enby (talk · contribs) 21:02, 25 June 2024 (UTC)

I'd like to point out the post from bɜ:ʳkənhɪmez above- I agree that is is an improvement to our purpose of being an encyclopedia, given that other encyclopedias include this information. Ju1c3machine (talk) 10:05, 26 June 2024 (UTC)

We don't follow what other online encyclopedias do. Both of the ones mentioned also include quizzes but we aren't adding those. Traumnovelle (talk) 08:37, 20 July 2024 (UTC)

I addressed this in my comments above. Encyclopedias exist to serve their readers. And sometimes this means we bend the “not a white pages directory”, whether in lists with links to our own articles or lists with external links. -bɜ:ʳkənhɪmez (User/say hi!) 18:59, 25 June 2024 (UTC)

While, yes, encyclopedias exist to serve their readers, that doesn't mean that anything that is potentially useful has to go in an encyclopedia. Lists with links to our own articles aren't anything like a white page directory, and I don't think anyone here would object that a list of notable helplines wouldn't be encyclopedic. But a standalone repository of phone numbers/external links, while useful for some readers, wouldn't be more encyclopedic than a software changelog. WP:USEFUL is not an argument for IAR. Chaotic Enby (talk · contribs) 19:59, 25 June 2024 (UTC)

Anything can be an argument for IAR - if it's an improvement. You say it's not encyclopedic, then why do other online encyclopedias generally include them on at least some pages - see above? Further, nobody is suggesting that the list be put in mainspace. -bɜ:ʳkənhɪmez (User/say hi!) 20:33, 25 June 2024 (UTC)

I strongly oppose including any kind of out-of-band helpline links, both for the practical reasons already identified (vetting that they are legit; keeping them up to date; normalising the expectation that Wikipedia is a place to get medical advice) and because there is very limited evidence these things are helpful, and the possibility that they are actively harmful, causing ideation that may not otherwise have crystallised. Barnards.tar.gz (talk) 19:41, 25 June 2024 (UTC)

I can see your point behind causing ideation for something like suicide, but don't see how that relates to other topics, like eating disorders or bipolar disorder. Seeing a phone number for either of those isn't going to make someone 'start' being bulimic or bipolar. Ju1c3machine (talk) 09:46, 26 June 2024 (UTC)

I'm not saying that a phone number is going to cause a mental illness, just that mental illness, generally speaking, is a complex phenomenon and its contributing factors are not well understood. I think it is at least plausible that reading an article which is written in a dispassionate, detached, neutral tone, will have a different psychological impact to reading a warning notice that personalises the interaction by suggesting that you might want to call this number if you are affected. This isn't a peer-reviewed comment. It may be an unfounded concern. But this proposal is a public health intervention, so I'd want to have a steer from a medical authority of some sort that it isn't going to cause more harm than good. Barnards.tar.gz (talk) 16:20, 26 June 2024 (UTC)

Note - I sandboxed the easiest method of doing this at the top of the page - adding to the infobox either above the image or at the bottom of the infobox - I don't really like either of these ideas since I think that it makes the statement less prominient than it should be, but you can see them here. Of note, I didn't expect WP:Mental health resources to be a blue link. It's a soft redirect to meta:Mental health resources. So it appears that Trust and Safety has already gotten rid of any liability concerns through the normal disclaimers/etc. And obviously it can be maintained, as they are doing it. I think the mere fact this page exists and has been approved by Trust and Safety means that any argument based on "we can't keep it updated" can be put to rest permanently. It would be ideal to have a version of that page adopted to the English Wikipedia however. -bɜ:ʳkənhɪmez (User/say hi!) 20:31, 25 June 2024 (UTC)

I like the sandboxed version (and think at the bottom of the box looks better than at the top from an aesthetic point of view), but that then raises the issue of having to create another page to link to for each illnesses' resources- instead of this just being acceptable to add to a page, it would require creating an entirely new page and linking it, which seems like a bit bigger of a project than I originally intended for. That being said, I really do like the way that Wikimedia's page is formatted, and wonder if it would be possible to create one page for helplines and link to individual sections that are relevant for each topic. Ju1c3machine (talk) 20:44, 25 June 2024 (UTC)

In this case, it could be good to have it outside of mainspace (possibly in projectspace instead), and a hatnote at the top of the page would be a more elegant solution than an infobox, as the latter is intended to summarize information. Chaotic Enby (talk · contribs) 20:47, 25 June 2024 (UTC)

A hatnote would be an option, but then you run into issues of "what if a page already has a hatnote"? I know some pages have long hatnotes, but this should really be separate from a hatnote for disambiguation, redirect, etc. reasons, as it's completely separate. I was going to try to sandbox a new "infobox" similar to the topic navigation boxes that show on suicide and other topics, but after everything moved to modules (which is great, don't get me wrong) I really can't be arsed. -bɜ:ʳkənhɪmez (User/say hi!) 21:29, 25 June 2024 (UTC)

@Berchanhimez, your sandbox's infobox says:

"Help If you or someone you know is considering suicide, you can find resources to help here".

Why not a simple, ordinary link to "List of suicide crisis lines", without the WP:YOU-style writing? WhatamIdoing (talk) 22:02, 27 June 2024 (UTC)

I'm happy for anyone to edit it to be better, but I don't think a simple link to a list without a sentence isn't going to be what is ideal here. If that's all people are okay with it's better than nothing I guess. -bɜ:ʳkənhɪmez (User/say hi!) 00:52, 28 June 2024 (UTC)

References

• Oppose I support anyone applying for money at meta:Grants:Start to develop this idea. Here and every other time this has been proposed, I feel that the early ideas are more harmful than good. Problems include
  • English Wikipedia is a global service, but there are no crisis support services that are global. There are not even enough regional support services to be satisfactory.
  • Services are not neutral. Many of them take positions on ethics and values. For example, some crisis hotlines may advise people that their lives will be better if they quit being LGBT+. We should not recommend an external service without having a process to report and evaluate them.
  • Wikipedia is not prepared to recommend products and services. If we start doing this, then certain organizations get government, foundation, and other funding and while others do not. Organizations will pay staff to persuade Wikipedians, sponsor Wikipedians to travel, send their staff people to conferences, talk about the partnership in the media, and advise the wiki community with expertise that is difficult to evaluate. Managing endorsements requires staff, and the first step is not to make endorsements to see what happens.

Again, I support the development of the idea, and someone should apply for a grant to develop all the reasons for and against. Bluerasberry (talk) 14:56, 26 June 2024 (UTC)

Very good point, especially regarding the non-neutral position that Wikipedia would have to take when recommending services. These are not comparable to external links, which are just showing links where relevant information can be found, without recommending the services provided in these links.
It's not even a question of "managing endorsements would be complicated". Managing endorsements would make us fundamentally non-neutral. We shouldn't be recommending products and services to begin with. Chaotic Enby (talk · contribs) 16:02, 26 June 2024 (UTC)

A free-to-use government-sponsored emergency hotline is neither a service nor a product. All of the arguments above can easily be handled by just providing official resources. Additionally, the anti-LGBT hotline falls under WP:FRINGE and isn#t relevenat to the current discussion. Ju1c3machine (talk) 16:07, 26 June 2024 (UTC)

A free-to-use government-sponsored emergency hotline is neither a service nor a product. It is, by definition, a service. And anti-LGBT hotlines are relevant to the discussion because, sadly, some countries' official resources are anti-LGBT. Chaotic Enby (talk · contribs) 17:16, 26 June 2024 (UTC)

This is a proposition about hotlines on mental illness articles- what mental illness would need an anti-LGBT hotline? Ju1c3machine (talk) 11:43, 27 June 2024 (UTC)

Some countries consider LGBT people to suffer from mental illnesses. You very likely don't want to call a government hotline in Qatar to effectively turn yourself in for being gay. Headbomb {t · c · p · b} 12:41, 27 June 2024 (UTC)

I believe that falls under WP:FRINGE. Additionally, there isn't a specific psychology page for homosexuality as a mental illness. Ju1c3machine (talk) 12:51, 27 June 2024 (UTC)

WP:FRINGE or not, if you're recommending government hotlines, that's the kind of stuff you risk having in more than a few countries. And given that the readers we link the hotline to will likely trust it enough to share personal details (even if just for the needed context), some of them will actually risk ending up in that situation, with the hotline possibly blaming their LGBT identity as the cause for their condition, even if they didn't reach the hotline through a specific "homosexuality as a mental illness" page. Chaotic Enby (talk · contribs) 14:33, 27 June 2024 (UTC)

That's definitely something to keep in mind, but I think the discussion should surround what criteria we are used to provide resources that are safe for users instead of "here's why we should scrap the whole idea". Ju1c3machine (talk) 21:43, 27 June 2024 (UTC)

section break 3, mental health topic

I agree that if there's interest in the idea, the Foundation should be consulted. Normally I'm very opposed to integrating them further into enwiki processes, but this area seems like it would be a logical place for that. Trust & Safety may have even considered doing this already, and might be willing to share and research or insight they have. Maybe they'd even be willing to take care of maintaining the list. It seems like this discussion is to figure out whether there's some interest in the overall idea that's worth developing further, and I think there is. The Wordsmith^{Talk to me} 16:41, 26 June 2024 (UTC)

Any advice on how to move forward from here? This is my first time suggesting something like this on wiki, I'm not super up to speed on what the correct process is. Ju1c3machine (talk) 17:10, 26 June 2024 (UTC)

You wait for there to be a consensus here. IMO it's likely this will turn out much the same as previous times this sort of thing has been brought up: between the questionable impact of helplines and the need to be global, something at the top of the article or in the lead beyond a hatnote like we have on Suicide (pointing to Suicide prevention) is unlikely to be accepted. Similarly, a listing within an article is unlikely to overcome WP:NOT#Wikipedia is not a directory. OTOH, a well-written section in the articles (or standalone article, if independently notable) about types of prevention or support would probably be accepted. Anomie⚔ 01:52, 27 June 2024 (UTC)

I think we need to operate on the principle, "first, do no harm". I have not seen any WP:MEDRS-compliant source that says whether such helplines are helpful or harmful or neither. I myself suffer from a mental illess (two in fact) and, though I don't claim to speak for anyone but myself, can see that it is by no means self-evident that helplines, or the promotion of them, actually help. Yes, they provide a nice warm glow to the people that operate them or volunteer for them, but I would probably be adversely affected by the suggestion that I should call one. Phil Bridger (talk) 17:26, 26 June 2024 (UTC)

I too have mental health issues (+autism, which in my case brings with it a good few issues that do at times interact with my mental health issues), and while I am also not claiming or attempting to speak for anyone but myself, I can confirm your statement beyond a "would be": suggestions of calling a helpline/crisis line have in the past adversely affected me (by setting off an anxiety attack or flashback, mainly), and my experience with actually using such services a handful of times has varied from "slightly helpful" to "harmful". AddWittyNameHere 06:33, 27 June 2024 (UTC)

I'd like to reiterate (again) that I'm not advocating for the "random volunteer tells you to not commit suicide" type hotlines, I'm advocating for the "hello I think I need to get help for my eating disorder, can you please help me make an appointment with a provider in my area" type hotline. Ju1c3machine (talk) 06:54, 27 June 2024 (UTC)

@Ju1c3machine: I know you are. (Though not everyone in this discussion is, on both sides). That said, those sorts of hotlines would still adversely affect me, simply because they break down the barrier between "abstract concept" and "this (could) apply to me", which is what such hotlines/their mentions within the relevant contexts are based on: someone realizing "this applies to me" and which leads to either realizing they need help (the type of hotline you advocate for) or spiraling and needing more acute intervention (which the other type of hotline is supposed to provide, at least).

I can absolutely see how that would be helpful in a lot of cases, but at least for me personally, that "barrier-breaking" is more likely to do harm than good. By turning an abstract, distant concept (which, sure, I know happens to apply to me too) into something about me, first and foremost (that happens to apply to other people too) may bring on the "this is talking about me, remember that time when you [...] oh and that perfectly describes that other time when [...]" spiral of flashbacks depending on my state of mind at the time.

Of course, my experiences are my own, and like I said, I can see how it would be helpful in plenty of cases. But that it can do harm alongside good is something I feel should be weighed into decisions. AddWittyNameHere 07:37, 27 June 2024 (UTC)

I can see your point, but also think that it has potential to do a lot of good- for example, I have ARFID, and a suggestion on the page to get help might have saved me a lot of struggle instead of thinking that my eating disorder was just "how I am" or "picky eating", and something worth getting help for. Not to get too personal, but my delay in getting help has lead to being diagnosed with heart disease, likely as a consequence of malnutrition- something that could have been avoided if I had known where to go to get help for it sooner. Ju1c3machine (talk) 12:03, 27 June 2024 (UTC)

Likewise, I can also see your point. It has potential to do both good and harm, alongside what's likely the greater bulk of cases—folks to which the issue described does not apply, particularly—in which it has negligible to no impact at all. I do wish there was a better way to figure out how much harm it would prevent vs cause, but if wishes were fishes...

So, barring that, my main reason for mentioning the point (both here and elsewhere in the section) is to ensure that its potential for causing harm alongside preventing it is taken into consideration, in part in whether this is a good idea, but especially in, if it is decided it is a good idea, what way to implement this and what group of articles to apply it to.

(As for too personal, I think sometimes getting personal in discussions about matters like this and accessibility concerns can be pretty useful by illustrating how a change could be/have been helpful (or harmful) in a non-hypothetical manner.) AddWittyNameHere 04:44, 28 June 2024 (UTC)

Does it change anything that there's a Trust and Safety approved list on meta already that we link to from WP:Mental health resources already? Pinging both User:Bluerasberry and User:The Wordsmith to ensure they both see that they've already started a list, and merely linking to that list (if nothing else) would almost certainly not be something they'd want to give "more" approval to. -bɜ:ʳkənhɪmez (User/say hi!) 17:41, 26 June 2024 (UTC)

I've also added a note to the talk page of the meta page for anyone with experience in how this page is used, or from the WMF, to comment here if they so desire. -bɜ:ʳkənhɪmez (User/say hi!) 17:43, 26 June 2024 (UTC)

@Berchanhimez: WMF Trust and Safety is great for what they do. They should not change anything.

However, when resources are scarce and the Wikimedia user community wants something versus the Wikimedia Foundation wanting something different, then T&S is going to side with the WMF. In general, T&S prioritizes protection where the WMF as a corporation could be legally liable. T&S do not prioritize lower level safety issues, and if for example, we had democratic governance, then most Wikipedians would vote to eliminate the common familiar problems and not the rare emergency problems. I am not saying that democracy is good or bad in this case, just that the majority of requests/votes would be for things that T&S does not do.

It is not appropriate for the Wikimedia community to freely edit that page on meta. Some pages on meta are sort of owned by WMF staff, and that is one of them. I support that page being there, but it being there does not indicate universal consensus to endorse driving traffic to it or its contents. When a lot of WMF staff edit a page then editors get scared away from raising criticism or concerns or problems.

Again, I support anyone applying for a grant to document all the social and ethical issues that come from making crisis referrals to organizations outside of our platform, and to just take this seriously. Bluerasberry (talk) 18:01, 26 June 2024 (UTC)

I don’t think we’d necessarily need to edit that page or maintain a local copy - even just linking to that page directly in the hatnote (or whatever is decided) would suffice. I can’t really tell what your opinion is - at first, it was reading as that it’s “not possible” to make such a page, but Trust and Safety already has done so and apparently they’re not concerned with the liability from it at all, nor linking/directing to those specific organizations. I’m not suggesting that page is evidence of a consensus - that’s what this discussion is for - but that page is evidence that Trust and Safety has already thought about the issue of “which organizations” and our liability and decided that they are either non-issues or can be properly managed by them vetting the links. -bɜ:ʳkənhɪmez (User/say hi!) 18:28, 26 June 2024 (UTC)

section break 4, mental health topic

Is there a way to get WMF's opinion on the idea? Ju1c3machine (talk) 18:50, 26 June 2024 (UTC)

The WMF can do whatever they want on MetaWiki, but having a corporation-vetted list of services masquerading as an encyclopedia article is not what Wikipedia is for. There isn't even evidence that it would be helpful, let alone that it would be a justified WP:IAR improvement to the encyclopedia. Chaotic Enby (talk · contribs) 19:05, 26 June 2024 (UTC)

Nobody is suggesting this would “masquerade as an encyclopedia article”, so statements like that are less than unhelpful. -bɜ:ʳkənhɪmez (User/say hi!) 20:22, 26 June 2024 (UTC)

How is including a relevant link to an existing Wikimedia page "masquerading as an encyclopedia article"? Ju1c3machine (talk) 05:40, 27 June 2024 (UTC)

I wonder whether the people supporting this proposal would advise people with cancer or heart disease (or arthritis - I have never considered suicide as a way out of my mental problems, but I would do just about anything to get rid of the pain when my arthritis flares up) to phone a well-meaning amateur rather than seek professional help? Phil Bridger (talk) 19:11, 26 June 2024 (UTC)

I can see this point being made for suicide crisis lines, but the types of resources I had in mind are the kind where you can call and someone helps walk you through finding professional help in your area. Ju1c3machine (talk) 19:14, 26 June 2024 (UTC)

@Ju1c3machine: In List of countries by English-speaking population, India, Pakistan, and Nigeria are top 5. It would be disappointing if we did not recommend good services to them but designed our support to refer people in other countries. It is a challenge to find regional services in those places. Bluerasberry (talk) 19:22, 26 June 2024 (UTC)

Taking Nigera as an example, it took approximately 30 seconds to find a list of government-sponsored hotlines. Ju1c3machine (talk) 05:38, 27 June 2024 (UTC)

Wow! It's almost like there are ways to find this information that are already available and are much better at it. -- User:Khajidha (talk) (contributions) 15:19, 27 June 2024 (UTC)

Wow! It's almost like that's not the point of the proposal, and that consolidated information should be available from the page itself for easier access to those needing help. You can't argue both "we can't do this because the resources are hard to find" and "we don't need to do this because the resources are already super easy to find somewhere else", that's absurd. Ju1c3machine (talk) 04:18, 28 June 2024 (UTC)

Show me where I argued that these things were hard to find? --User:Khajidha (talk) (contributions) 11:43, 1 July 2024 (UTC)

The person that replied before you argued that it was hard to find resources, which I disproved, and then you said we don’t need to because it’s easy to find resources. Since when does “you can find this information somewhere else” mean that it doesn’t belong on Wiki? Ju1c3machine (talk) 08:14, 2 July 2024 (UTC)

People with cancer aren’t at risk of dying imminently by suicide if they don’t find another path forward. Your suggestion comes closer to a general “medical disclaimer” that’s explicitly not appropriate on Wikipedia. Offering people an option other than “keep looking at articles about depression/suicide until you do it or get tired of it” isn’t the same thing as “contact your doctor to discuss medical concerns”. Attempting to make that analogy minimizes the urgency of suicide prevention. -bɜ:ʳkənhɪmez (User/say hi!) 20:24, 26 June 2024 (UTC)

People with cancer aren’t at risk of dying imminently by suicide if they don’t find another path forward. - they well might. Cancer comes with elevated suicide rates, particularly when the prognosis is poor and/or quality of life is significantly, long-term impaired—concerns about the former and ways of hopefully tackling the latter are both better discussed with a doctor than an amateur volunteer without access to your medical information.

Offering people an option other than “keep looking at articles about depression/suicide until you do it or get tired of it” isn’t the same thing as “contact your doctor to discuss medical concerns”. Going to be a little more explicit here about my mental health/experiences with mental health crises than I would otherwise be: in my case, that "offered option" would increase rather than decrease the risk I am at.

From experience, if not actively struggling, looking at [clinical representations of/distant mentions of] suicide and depression with or without mention of hotlines is unlikely to set off my suicidal ideation and related matters.

If I am struggling, however, without such hotlines it makes it a distant and clinical concept, which has helped me distance myself from such thoughts a time or two. On the other hand, with hotlines (and especially when those are directed at the reader) provided, it breaks the barrier that makes it an abstract concept and turns it into "something I might feel tempted to do/could do". Which tends to make my ideation a lot less abstract and my intrusive thoughts more intrusive. (That my experiences with crisis lines are a mixed-leaning-negative bag including two cases that set off my anxiety if reminded of them at the wrong time does very much not help there)

Of course, I am just one person, and my personal experiences don't apply to everyone. I'm not saying "it is harmful to me, therefore it must be harmful in general". But there does seem to be a tendency (in general discourse, not you specifically, nor even this discussion specifically) to gloss over the fact that the presence of such reader-directed hotlines might cause some people harm, too. It might well be that on the whole, that harm of their presence is outweighed by the harm of their absence—but that's impossible to determine without first taking into account that there is harm on both sides of the coin. AddWittyNameHere 07:18, 27 June 2024 (UTC)

I'd like to ask that that discussion stays on topic to my original proposal, which was to add resources for where someone can find treatment options for mental health problems, not suicide hotlines themselves. My suggestion was prompted by friends of mine with mental health problems wishing there were easier ways to get help- in some countries, there are easier ways to get help, and I believe adding them might help make those options more widely known, especially when (as mentioned before) someone is reading Wikipedia to learn more about a condition that they didn't know was the reason behind their maladaptive behavior. Ju1c3machine (talk) 11:39, 27 June 2024 (UTC)

This is the sort of thing Google (or any other search engine) would be much better for than Wikipedia. -- User:Khajidha (talk) (contributions) 15:17, 27 June 2024 (UTC)

Suicide hotlines are easy: We can link to List of suicide crisis lines, which already exists (for more than a decade), already is sourced, etc., and we're done.

I think the more interesting area is non-suicide social support. So to answer the question from @Phil Bridger, I would recommend a peer-led support group to people with cancer. People with cancer who join peer support groups tend to live longer and have better quality of life than people who don't. Support groups are mentioned, e.g., in Breast cancer#Society and culture. Note that it doesn't say "If you live in Ruritania, contact the Ruritanian Cancer Support Group"; instead, it has encyclopedic information about the earliest support group for breast cancer. Someone could expand that article content if they wanted to; the result would probably say something like some are organized through hospitals and there are a bunch on social media. It might even touch on the practice of having separate support groups for women who are highly likely to survive vs those at risk of treatment failure and death.

I don't know if there are similar groups for heart disease. Part of what seems to make a peer-led support group work is having everyone more or less in the same situation, so it might not be "heart disease", but instead for people with a specific type of heart disease.

But overall, I would recommend the "well-meaning amateur" in some instances. WhatamIdoing (talk) 21:56, 27 June 2024 (UTC)

add resources for where someone can find treatment options for mental health problems Using your Anorexia nervosa example, what specific resources or links would you add? Some1 (talk) 01:57, 28 June 2024 (UTC)

Resources that I had in mind when I posted the proposal (not meeting the criteria of 'maybe we should stick to government-sponsored organizations' because I don't have time at the moment to do research and I happen to know of these off the top of my head) would be NEDA and ANAD, whose hotlines connects individuals with treatment options (ANAD was the first ED hotline to exist which I think is also a neat fact to stick in an article somewhere), EatRight, which has a directory of nutritionists and dieticians (who are an essential part of recovery, as people with EDs need a very specific diet to avoid refeeding syndrome), NAMI, which provides general mental health group support, and Eating Disorders Anonymous, which might be a helpful tool for someone who doesn't need traditional inpatient treatment. Ju1c3machine (talk) 04:32, 28 June 2024 (UTC)

Slightly more awake addition to this: Eating Disorders Anonymous is also a good resource for those who can’t access inpatient treatment, but it’s an option many in ED communities are completely unaware exists, so I believe linking that one specifically would have a rapid positive impact on those affected, especially for users in the US (where it can be prohibitively expensive and/or not covered by insurance) and the UK (where I’m less familiar with the topic, but believe there are also some issues there with waiting times and quality of treatment facilities). Ju1c3machine (talk) 06:03, 28 June 2024 (UTC)

• I have to confess that I have never really understood the overall meme of mental health hotlines. You see them in a bunch of cases (notoriously, near the ends of subway platforms). My main experience with them is that they are obnoxiously and insistently slathered over my screen if I try to look something up which happens to be tangentially related to a contentious mental health topic. The impulse is very easy to understand, as it's a syllogism you see all over the place: "suicide is a tragedy, something should be done about tragedies, and this is something". Here is something to consider: many of our readers get to Wikipedia by way of a search engine. If you search for "suicide" you're already forced to scroll past a full screen's worth of paternalistic lecturing from Google LLC, so are we actually providing any benefit by making our readers sit through a second one after they click the Wikipedia link? jp×g🗯️ 00:43, 7 July 2024 (UTC)

If you don't believe me, here is what you see when you Google "suicide" (I am in California so your results may vary):

Help is available
Speak with someone today
88 Suicide and Crisis Lifeline
Languages: English, Spanish
Hours: Available 24 hours
Call 988	Text 988
Chat	Official website
	Learn more • Feedback
Connect with people you trust
From International Association for Suicide Prevention · Learn more
If you’re struggling, it’s okay to share your feelings. To start, you could copy one of these pre-written messages and send it to a trusted contact.
Reach out	Contact a loved one	Express your feelings
When you get a chance can you contact me? I feel really alone and suicidal, and could use some support.	I don’t want to die, but I don't know how to live. Talking with you may help me feel safe. Are you free to talk?	This is really hard for me to say but I’m having painful thoughts and it might help to talk. Are you free?
For informational purposes only. Consult your local medical authority for advice.

After this, there are three videos hoisted to the top of the results: "Suicide: Facts & Misconceptions You Should Know", "How Do I Ask For Help If I’m Thinking About Suicide?" and "Teen Suicide Prevention". All of this takes up about a full screen on a normal computer. Then you scroll down past another screen or so of offically-approved links to suicide hotlines (one from the California State Portal, one from the CDC, one from the NIH, and then one from the WHO). Only then, after Google has diligently eliminated all possible sources of legal liability (e.g. repeated CYA disclaimers about "consult your local medical authority") do they permit the Wikipedia link to appear. I copied the full text content of the search results page into a reading-time estimator, and it gave me 1:54. This means that someone who clicks on the link to Suicide from a Google search does so after having spent nearly the entire runtime of Led Zeppelin - IMMIGRANT SONG.mp3 having helpline numbers shoved in their face. Are we really, genuinely, helping this person, or are we just making ourselves feel better, at the cost of diminishing their ability to read the article? jp×g🗯️ 01:04, 7 July 2024 (UTC)

I don't think anyone is suggesting something intrusive that would diminish someone's ability to read the article. The suggestions I've seen so far are a hatnote style one line at the top which would likely be in italics, or an addition to the infobox, or a small box above/below the infobox with a page of resources linked to from it. -bɜ:ʳkənhɪmez (User/say hi!) 01:07, 7 July 2024 (UTC)

If you read the conversation, we are talking about a small link to mental health resources for issues that are not suicide. I would appreciate it if this conversation would stop getting derailed by what I was unaware is a controversial topic. I recognize that there are mixed opinions on suicide resources and warnings, which are numerous- this is not the case for other mental health issues, such as eating disorders, or this conversation wouldn’t be taking place. Ju1c3machine (talk) 04:06, 7 July 2024 (UTC)

I wouldn't say it's getting derailed. Suicide is the option that has the most pre-existing consideration within Wikimedia Foundation projects (see WP:Mental health resources) and is also the one with the most correlation in other encyclopedias/etc. Yes, it's divisive, but those opposing them for their "efficacy" are opposing all mental health resource links for their efficacy from what I can see. -bɜ:ʳkənhɪmez (User/say hi!) 05:36, 7 July 2024 (UTC)

I don't see a lot of evidence that people are thinking about anything except suicide. In fact, I added a link to Diagnosis of autism#External links a couple of weeks ago. It's about mental health. It's a resource. It's a link. There's been no opposition, and I expect no opposition (assuming nobody decides to be WP:POINTY after I mention it here). I'm hoping that some readers, particularly high school students writing the predictable paper for health class, will click the link and learn something (e.g., that the diagnostic process for autism involves fairly ordinary personality-type quizzes). WhatamIdoing (talk) 05:45, 7 July 2024 (UTC)

That's a good data point, but I think the original proposal was for them to be more prominent (i.e. infobox, a box above/below the infobox on the side, a hatnote, etc) rather than relegated to the bottom of the page in EL. I agree that putting them as EL isn't generally considered controversial. -bɜ:ʳkənhɪmez (User/say hi!) 05:54, 7 July 2024 (UTC)

Ju1c3machine's original proposal here was to have a directory of information in a section within the article. You jumped in early on and started advocating for a prominent "call to action" at the top of the article. Then WhatamIdoing jumped in with some more status-quo options (e.g. external links that could comply with WP:EL and in-article coverage in line with WP:DUE rather than against WP:NOTDIR) but also refuses to accept that people can make a distinction between those and yours.

To my eyes, the rest of the discussion seems to have been supportive of WP:DUE and WP:EL, and opposed to top of the article calls to action and to article-space directories other than the already-existing List of suicide crisis lines. Whether the line on more subtle hatnotes has moved from the very subtle one approved in Wikipedia:Village pump (proposals)/Archive 161#Proposal to add suicidal disclaimer at Suicide is unclear. Anomie⚔ 11:23, 7 July 2024 (UTC)

I believe that people can make a distinction between different forms. However, I don't believe that putting an oversimplified line in WP:PEREN that says the community has a consensus not to "Add prominent links to crisis hotlines on relevant articles" will result in people making that distinction. WhatamIdoing (talk) 23:30, 7 July 2024 (UTC)

You believe people won't read more than the heading of anything, so if it's not possible to state as a soundbite then it's not possible to state at all. Anomie⚔ 10:36, 8 July 2024 (UTC)

I do not believe that.

I do believe that most people do not read things closely.

I do believe that most editors will not read past the headline when they believe that the headline has told them the whole story, and especially if they want the contents of an oversimplified headline to be the whole story.

See also all the people who see an WP:UPPERCASE shortcut and assume that they know what the policy says – even if the linked page isn't a policy and says the opposite of the shortcut (e.g., WP:VOTE and WP:NOTAVOTE, which point to the same essay; WP:DEADLINE and WP:NOTDEADLINE; WP:NOTWINNING and WP:WINNING; and so forth). This is not a unique problem. The whole internet has problems with people only reading part of the story, and then going out to assert that they really know what's going on because they read – well, not the whole article, but the headline, one caption, and half of the first paragraph. We have a rule against relying on news headlines if you haven't read the whole article, and against relying on abstracts if you haven't read the whole journal article; we would not need those rules if busy people could be relied upon to read the whole thing every time. WhatamIdoing (talk) 01:31, 13 July 2024 (UTC)

So which is it? We can't add it to WP:PEREN if we can't reduce it to a soundbite because people won't read more than that, or we can add it to WP:PEREN because we have rules against not reading the whole thing and hundreds or thousands of existing rules that already require reading the whole thing to get right? Anomie⚔ 13:08, 14 July 2024 (UTC)

You can't add your summary to PEREN because you don't have consensus. WhatamIdoing (talk) 23:46, 14 July 2024 (UTC)

Because exactly one person (you) objects, for no reason you can support? 🙄 I don't think that's how consensus is supposed to work. But if you're going to be like that, I suppose we can waste time with an RFC about it after this discussion too closes with consensus against a prominent top-of-article call to action. Anomie⚔ 11:22, 15 July 2024 (UTC)

We could equally say that "exactly one person (you) supports". WhatamIdoing (talk) 22:00, 17 July 2024 (UTC)

You could say that, but you'd be wrong. At least one other person here has supported adding it to WP:PEREN. Anomie⚔ 02:38, 18 July 2024 (UTC)

I went with suicide, because it's the one thing where the argument is strongest for including some kind of hatnote or warning label. For e.g. anorexia or bulimia, the case is quite a bit weaker, since there is not a possibility that the person is imminently about to die -- they have just as much time as anyone else, they just have a mental disorder. They are just as intelligent as anyone else, too, and I don't see why we need to give them additional hatnotes on top of an article that's already about the disorder (we don't have hatnotes at the top of bandsaw that tell you to wear safety glasses, or gas metal arc welding that tell you to make sure your ground clamp is connected, et cetera). People with anorexia can read, yes? If you Google "anorexia", you already get reams of stuff about how to get help and where to get help and here's a helpline and et cetera. The intended demographic of this intervention seems extremely small: people who have a mental illness and desperately need help for it, who are wise enough to be reading a Wikipedia article, but not wise enough to be able to type "[name of disorder] help" into a search engine? jp×g🗯️ 07:24, 7 July 2024 (UTC)

I think the important thing to remember is that, while yes, many people treat Google as a first source of information, our articles are linked to throughout the web. For all we know, someone's reading an article on some blog somewhere that has a link to our article on suicide, and it may not even be a clear link (perhaps it was an easter egg link on that site). Many people also do use our interwiki links and/or search bar to get to articles directly, rather than dealing with the ads/promoted links on Google/other search engines. Sure, I don't think anyone going to the Canadian Encyclopedia is so internet unsavvy that they can't go to Google and type in "X help". But that's not why their hatnotes exist. It's because people arrive at articles they don't intend to, or that they may have intended to but only after going down a rabbit hole of seeing things that have triggered them to be thinking about committing suicide. Let's use an example - someone hears a nice Avicii song that they enjoyed, and they come to look up the album/song on Wikipedia. They then click the article about Avicii, because they want to read more about him - without even thinking about suicide. In reading our article, they read about his suicide, and that gets them to thinking about it. There isn't currently a wikilink to suicide in his article that I can see (though there maybe should be?) - but they now, thinking about the topic of suicide and seeing that a musical artist that they enjoyed committed suicide, happen to go to our article on suicide, in a time of distress. Not because they came to Wikipedia thinking about suicide - they came here for information on a song/musician. But they ended up on our article about suicide nonetheless. That is the "intended demographic", and for those with mental illness, going down those rabbit holes that lead to researching suicide or self-harm is all too common. It costs nothing for us to add a prominent but not intrusive list of resources for them to use if they want to stop going down that rabbit hole but can't do so on their own. -bɜ:ʳkənhɪmez (User/say hi!) 08:05, 7 July 2024 (UTC)

This is really well worded and a great descriptor of why I made this proposal, thank you! Ju1c3machine (talk) 16:50, 7 July 2024 (UTC)

"they have just as much time as anyone else, they just have a mental disorder"

Eating disorders have the highest mortality of any mental illness. This is being proposed because an issue I struggle with isn't very well known and I didn't realize help existed for it, let alone that it was a problem that I needed serious help with instead of just being a 'personality quirk'. I'm not sure why you think reading an article on one of the most popularly used websites on the internet makes you 'wise', but no, for a lot of these resources googling doesn't really provide resources or help- it's just WebMD summaries of how to spot early signs of those issues in kids, because god forbid those kids not figure out there's a name for what's wrong with them until later and want to fix it. Ju1c3machine (talk) 16:48, 7 July 2024 (UTC)

I note that there have been over a hundred responses to this, but only one (this one from Rosguill) has come with a WP:MEDRS-compliant source, and that was inconclusive and about suicide prevention lines, which we are told is not the subject of this discussion. Phil Bridger (talk) 12:01, 7 July 2024 (UTC)

Redefining ECP

Once again concerns about ECP being too easy to work towards have been raised at AN. My concern with this is that we are WP:BITING good faith editors who see the requirements and, not knowing that we don't want editors working towards them, decide to do so through productive and good faith edits.

Rather than repeatedly taking such editors to AN or ANI, or otherwise sanctioning them, the best solution is to change our requirements so that even if an editor chooses to work towards them we can have faith than they have obtained a minimum level of understanding and competency. As a simple and conservative change towards this, I suggest that to obtain ECP an editor must have:

• 500 edits outside of draft and user space (noting that articles written in draft or user space but moved to article space will be considered article space edits)
• 200 of which are more than 250 bytes

Implementing this can done with a simple adminbot, which would check whether users have met the requirement and grant them ECP if they have. Users who have already been granted ECP will be grandfathered in.

@Iskandar323, Amayorov, EggRoll97, Swatjester, Starship.paint, Sean.hoyland, Selfstudier, and XDanielx: Notify editors who participated in the recent AN discussion. BilledMammal (talk) 20:56, 9 July 2024 (UTC)

I know there have been concerns about me gaining ECP in less than a week, but I must say that it certainly wasn't easy. It took me around five days of non-stop editing and learning, practically without taking a break except for sleep.

But anyway, I think yours is a great suggestion! Is there some concept like a cumulative edit to a page? Because otherwise a user could simply insert-delete a wall of text multiple times to meet the requirements. Amayorov (talk) 21:02, 9 July 2024 (UTC)

I'd say a user inserting and deleting a wall of text would be blocked as WP:NOTHERE before they get to ECP. Also, I genuinely don't think non-stop editing for days without taking breaks except for sleep is healthy. Not in terms of your edits, but in terms of actual health. Chaotic Enby (talk · contribs) 21:05, 9 July 2024 (UTC)

I agree with this. I'm not concerned about editors who obtain ECP through bad faith edits, as they are easy to identify and there is no WP:BITE issue in sanctioning them for it. BilledMammal (talk) 21:10, 9 July 2024 (UTC)

I agree that a qualitative strengthening of the requirements would be beneficial. I mentioned the spirit of the 500/30 rule before, and in my mind, the spirit is indeed to build up both editing experience and community and guideline familiarity. This actually helps editors who are interested in getting into contentious topic areas in the long run, as it ensures that they begin editing in such areas on a more solid footing and are less likely to inadvertently run afoul of the brighter red lines. The measure ignoring user spaces would improve the qualitative bar a little, though I wonder if it is enough. I might also exclude talk, since chatting in talk, especially with the more recent reply function, often really isn't anything akin to editing. Also, I have certainly seen disruptive users rapidly racking up edits through very vapid or actively disruptive talk page contributions. I totally agree with the 200x250 part –assuming it is feasible to implement. However, I might also add a further dimension, and that is time. The 30 days rule only requires that an account exist for 30 days, but I think the original spirit of this was that an editor edits for 30 days. Again, if practically implementable, it would be good to tighten this to 30 days in which actual edits were made – a metric that, again, would provide some assurances that a user has spent a decent amount of time actually becoming familiar with everything. Iskandar323 (talk) 21:13, 9 July 2024 (UTC)

If we're using an adminbot to apply the rights, almost anything is feasible.

Personally, I would prefer to see some talk space participation, as collaboration is an important part of editing. Adjusting how the 30 day rule works could be useful, although I'm not sure how you propose this is done - perhaps the clock starts after the 100th edit, rather than when the account is registered?

One thing to keep in mind is that previous discussions suggest that the more complicated the requirements are the less likely they are to be supported by the community, which is why I've kept them simple this time. However, we could always run an RfC with multiple options? The status quo, a conservative option, and an ambitious option? BilledMammal (talk) 21:22, 9 July 2024 (UTC)

Even the clock starting from the first mainspace edit would be an improvement – so 30 days since an account nominally goes active in mainspace. This would weed out accounts that just boot up to sniff around, play around in the sandbox, comment in talk and gentrify their own user pages, among others. Iskandar323 (talk) 21:54, 9 July 2024 (UTC)

Is there perhaps another way to frame this? I'm not opposed to the general idea of using a minimum edit size as a proxy for edit quality, and why that works neatly from an automation standpoint, but it's not without it's problems either. But it seems to me that the real problem we're trying to solve for is edit count abuse that leads to post-confirmation problems on ECR articles, specifically. Communicating expectations of editors is good, but we can take a step back and look at the reason why that expectation arose -- it's not really about the 500 edit requirement and what they did to meet it, it's about demonstrating that one knows how to play by the rules and can edit constructively with others (particularly AFTER their 500th edit). Now, let's say we had a hypothetical user who achieves ExC status through 500 meaningless, insubstantial edits -- but then goes on to have a productive career subsequently and either never edits on ECR articles or does so only in a constructive and harmless manner. Is that user a problem? No. More importantly, is the fact that the user gamed the system to get their ExC status a problem, if they're not actually displaying any problematic behavior? IMO, no. So, separate from the above discussion about edit size and counting active editing days instead of account age, what I'd like to see, is a way that specific problem users (and ONLY them, not every single extended confirmed editor) can be reported and have their pre-confirmation edits put up for review if they're behaving badly post-confirmation; with the result of having their extended confirmed status be revoked if necessary. I'm assuming that would take the form of a new noticeboard, but possibly could already be covered by an existing one? I hope I'm explaining it clearly enough. ⇒SWATJester ^{Shoot Blues, Tell VileRat!} 23:28, 9 July 2024 (UTC)

If the goal is to expect constructive contribution from people before they can get ECP, then no automated way of assigning it will be sufficient, as it will still not show constructive ability to collaborate. Any set of "metrics" one can define, including edit count, days active, edits in certain namespaces (such as Article or Talk), size of edits, etc. will either be gameable just as easily as it is now, or will result in it being unnecessarily difficult to obtain to prevent that gaming. Only if there is truly an issue with the current way (assign it automatically after 30d/500 edits), then the only real other option is for it to be assigned manually, such as by request on a permissions noticeboard (or a new board set up for "experienced confirmed editor" confirmation or similar). I do not believe that is in the spirit of the ECP, however, which was intentionally not supposed to be a "trusted editor" but just a "second level autoconfirmed". -bɜ:ʳkənhɪmez (User/say hi!) 03:15, 10 July 2024 (UTC)

I tend to agree with Berchanhimez's rather pessimistic view. ECP apparently can't do what it was hoped it could do, with the exception, in my view, of reducing the temperature on talk pages by excluding fire-starters. More comments later... Sean.hoyland (talk) 05:30, 10 July 2024 (UTC)

Other comments.

• I'm unconvinced that we are WP:BITING good faith editors. I think they trickle into contentious topic areas organically and don't even notice ECP because they will already have crossed the barrier editing the millions of other articles in good faith. In other words, they don't have an objective that is inconsistent with the Universal Code of Conduct. It would be great if there were a whole bunch of good faith editors out there who wanted to join the PIA topic area for example, but I'm not seeing it, before or after ECP was implemented. In reality, I think it is more like a cloud of people with no intention of complying with the prohibition against 'Systematically manipulating content to favour specific interpretations of facts or points of view'. ECP doesn't appear to help them gain the ability to leave their biases at the door before they enter contentious topic areas.
• re: "is the fact that the user gamed the system to get their ExC status a problem, if they're not actually displaying any problematic behavior? IMO, no." I think the answer to this question depends in part on whether Wikipedia requires editors to be honest, to comply with all policies or only some policies. Editors with a "criminal record" that removed their right to be here are more likely to game the system, more likely to make an effort to appear to be a constructive editor, at least for awhile, until their problematic behavior manifests again and the block->sock cycle restarts. Many of the numerous blocked editors are very experienced editors, they are pretty good editors if you ignore their dishonesty, advocacy, racism, ultranationalism or whatever peculiarities they have that get them into trouble. One of the objectives of ECP was to increase the cost of entry for editors who employ deception via sockpuppetry. There is no evidence that it does that, not as far as I can tell anyway. This is a very significant issue because it means there are two classes of editors, and only one of the classes is affected by sanctions, the class that does not employ deception via sockpuppetry. So, for me, "if they're not actually displaying any problematic behavior" is not a very useful test in itself if honesty matters, and it doesn't really tell me anything useful about the value of ECP. Certainly, in PIA, we are dealing with many experienced ban evading editors with a good understanding of the content rules who unfortunately choose to behave like sociopaths. But maybe honesty doesn't matter because it is not enforceable in practice. Wikipedia could make that decision, that we no longer care whether you are using sockpuppetry to evade a sanction because you are generating decent content some of the time. Sean.hoyland (talk) 06:41, 10 July 2024 (UTC)

  I think the answer to this question depends in part on whether Wikipedia requires editors to be honest, to comply with all policies or only some policies.

  My problem with this is I don't think they are breaking any policies by "gaming" ECP. We tell them that they need 500 edits and 30 days tenure to edit; we don't tell them that working towards that through productive edits will be seen "gaming" the system.

  There is no evidence that it does that

  This is part of what adding the minimum byte size will do. It's harder to make large productive edits than it is to make small ones; it will make it harder for editors game ECP, or it will make them more likely to do it through unproductive edits, which will make them easier to catch. BilledMammal (talk) 04:50, 11 July 2024 (UTC)

  Byte size is not the best thing either though. Many things, such as templates (with parameters that are not used but valid parameters for the template), references (which can be 250 bytes on their own in some cases), and a plethora of other "trivial" contributions can be over 250 bytes. And things under 250 bytes can be productive edits too. I would be against a byte size rule for automatic granting - at that point, it needs to just be moved to be granted by administrators after evaluating the edits. Because any size of edit you come up with will be just as easy to "game" as it is now, and would prevent legitimate editors who don't meet it from getting it. That's why I think the only options are leave it as is, or to move it to no longer being granted automatically at all - if "gaming" truly is a concern.

  Personally, I don't see gaming as a concern - because ECP is not to say whether an editor is productive or not - just that they've at least spent more time here than the 4 days/10 edits for autoconfirmed. Even if they gamed it, so what? If they are disruptive, we have processes to deal with that already (such as Arb Enforcement for Contentious Topics, AN(/I) for other behavioral issues, etc.) and I have seen no evidence that those areas are failing to deal with problematic editors. Ultimately, I feel the people arguing to make it harder to get misunderstand its purpose - which is not to segregate editors into productive/non-productive, but is to merely make sure someone who is still brand new can't just hop in to certain pages/topic areas. It's in the name - extended confirmed. A confirmed/autoconfirmed editor is not someone who is guaranteed to be productive - they're just someone who has not made an account an hour ago and has at least some experience with the edit window so they're less likely to "accidentally" delete text or mess something up because they don't understand the edit window. Likewise, EC is just that, but with a bit longer and a bit more edits under their belt. -bɜ:ʳkənhɪmez (User/say hi!) 05:32, 11 July 2024 (UTC)

  Hear hear. Curbon7 (talk) 06:15, 11 July 2024 (UTC)

@BilledMammal:, I agree that people are not breaking any policies by "gaming" ECP. For interest, for your minimum byte size considerations, some plots of the first 600 (or less) edits for a few editors who were blocked as socks. The signals are quite diverse. Sean.hoyland (talk) 13:47, 12 July 2024 (UTC)

I think they [good faith editors] trickle into contentious topic areas organically and don't even notice ECP because they will already have crossed the barrier editing the millions of other articles in good faith. Many (maybe even a majority, though I can't say for sure) high edit-count editors who work in ECP areas tend to limit their edits almost exclusively to these areas, sometimes on a daily basis for years on end. We certainly don't question the extent of these editors' good faith on the basis of where they choose to spend their editing efforts. I don't see why we can't extend the same courtesy to new editors. For example, in your first 500 edits, you made changes to articles which are today ECP. As far as I know, nobody questioned your good faith on the basis of the areas where you chose to start editing. We should continue that with new editors. spintheer (talk) 06:00, 12 July 2024 (UTC)

@Spintheer:, I understand this way of thinking, but "I don't see" is not a good state to be in when you are under attack and thinking about countermeasures. Here is an example where you would have been wrong over a thousand times just for one person employing deception via sockpuppetry to edit in the PIA topic area. Here's another, and another, and another, and it just goes on and on, dishonest people exploiting weaknesses in the ways we guard content. To slightly correct the record for your entertainment, in my case, although it long predated the Arbcom ECP remedy, lots of people questioned my good faithiness, made all sorts of dumb and confusing accusations together with a sprinkling of the occasional threats of violence. But it makes no difference to me whether people question my good faith. Good for them, everyone should question everything all the time, including everything they believe to be true about the world and themself. Assuming anything, including good faith, tells me nothing useful about an editor. The relevant question for me is whether a person is complying with the rules, all of the rules, including rules against advocacy and the use of deception. There need to be countermeasures. There is agreement on that at least. There need to be countermeasures because the strength of the attractive force that content exerts on editors is apparently, in a large number of cases, inversely proportional to their capacity to comply with section 3.3 of the Universal Code of Conduct. I don't know what those countermeasures should be. ECP is not an effective countermeasure. AGF is not an effective countermeasure. Quite the opposite. It is something that is exploited. Rules need to deal with the unpleasant reality rather than a faith based optimistic model of Wikipedia. Sean.hoyland (talk) 08:38, 12 July 2024 (UTC)

I would like to see new measures tested, alternatives or additions to ECP, things that try to address root causes. Unfortunately, I lack the imagination to think of them.

e.g.

* A test that ensures that an editor understands that they must comply with section 3.3 of the Universal Code of Conduct all the time i.e. they understand and accept that they can't convolve their biases with content, regardless of whether it is in good faith or bad faith.

* A place to report non-compliance with section 3.3 that handles reports as routinely as reports of non-compliance with things like revert rules, civility rules etc.

* Routine frictionless use of checkuser in contentious topic areas i.e. effectively make fishing a countermeasure (I'm sure there are arguments against this that I would probably find unconvincing).

But tweaking ECP wouldn't hurt. Sean.hoyland (talk) 07:24, 10 July 2024 (UTC)

@Sean.hoyland, UCOC 3.3 is the section about "Deliberately introducing biased, false, inaccurate or inappropriate content" and "Systematically manipulating content to favour specific interpretations of facts or points of view" (among other things). Are you mostly concerned about POV pushing?

On the assumption that you're thinking about that (and not, e.g., about 3.3's prohibition of hate speech), then I think that it's important to remember that one person's POV pushing is another's genuine attempt to help Wikipedia.

If the article seems too "red" to you, then you try to make it more balanced. And the next person thinks your version is too "blue" and tries to make it more balanced ...which now looks too "red" to you again. This is 100% good-faith editing. It's not all editing in compliance with the community's own POV about what "color" the subject Really™ Is, but it is good-faith editing, and nobody's exploiting anything here. We're all just trying to do our best.

If we keep at it, with just a little intellectual humility (like many Wikipedians, I am confident that I am always right; also, I have been wrong in the past, and it might happen again) and a little willingness to learn (huh, I never thought about it from that angle before), then we usually end up with a better article than if we kick out all the editors who disagree with us or challenge the article's neutrality. Sometimes that's hard. Sometimes we're in the wrong space emotionally to see beyond our own POV. Our needs can overwhelm our ability to understand someone else's view.

But those needs can be managed. We can have a group writing an emotional subject like Mother that includes editors with every type of parents as well as every type of family member themselves. We end up with a better article than if we leave the article entirely to the starry-eyed would-be mother, or to the child abuse survivor, or to the father. What we can't do, though, is do that work without going through the effort of working with other humans. https://www.newyorker.com/news/letter-from-silicon-valley/the-lonely-work-of-moderating-hacker-news talks about an approach to moderating group chats that I think is very similar to our aspirations. The net result is that it's a long game that requires a lot of investment in individual education. Every single editor has to be brought through the process: "Oh, I see. You think this, because you are looking it at from the POV of poverty. Okay, I'm looking at this subject from the POV of personal fulfillment. Can we find a way to fit both of these views into the article?"

I think we keep hoping for a model of "everyone can edit, but it won't be a big, time-sucking, energy-draining endeavor". This is not realistic. Democracy does not have a monopoly on being "noisy and messy and complicated". Wikipedia is all of those things, too. WhatamIdoing (talk) 02:12, 13 July 2024 (UTC)

@WhatamIdoing:, well, don't get me started on modelling the dynamics of the system over time or I'll be here all day.

• I'm mostly concerned about the consequences of there being 2 classes of editors - a class that must follow the rules because sanctions have consequences for them and a class that is unaffected by rules because they reincarnate in sock form. The existence of 2 classes has a significant impact on the dynamics of the system at all times scales, at a particular article at a particular time for example and over long time scales.
• I'm also concerned about POV pushing, not because I have opinions that differ from other people or because of something like a community POV. A reason POV pushing is significant for me is captured by the notion of genetic drift, because just like allele frequency, the incremental corrective processes that move the content dot towards policy compliance, are critically dependent on population size. I don't believe that the population size is large enough to do that in the PIA topic area for example in many cases. And this is another area where the existence of a class of disposable accounts can have a influence on the dynamics. 
• There is the idealized spherical cow type model of the dynamics of Wikipedia. I understand this is the way many people think about things like neutrality and completeness in Wikipedia, as an emergent property of the system. It's an optimistic model and perhaps it is a good first approximation in the majority of cases over long time scales. But what I would say is, if someone thinks they have a decent model of the dynamics in Wikipedia, it probably doesn't work in the PIA topic area. The dynamics are more complicated and diverse, noisy and messy as you say.
• Simple optimistic models have all sorts of assumptions that are not always valid e.g. 

• The notion of a shared objective function, that the system has a single attractor, that individuals acting in good faith are all trying to nudge things towards it. This is observably not the case, and we know that because we can observe efforts to push content up the hill, away from what sources say.
• That we are dealing with individuals where there is a one-to-one mapping between an account and a person. Neither of these things are true in all cases. There is account sharing and coordination between account holders to push the dot up the hill to a preferred location inconsistent with policy. We know this is the case. 
• That the dynamics moves the content dot towards policy compliance over time because of the interactions of many competing agents. Maybe, but what we also observe is instabilities rather than gradual movement towards an equilibrium, again, often because of the existence of 2 classes of agent. These instabilities manifest as things like rapid transitions of content between 2 states via edit warring, over the presence or absence of a word for example.

• As a general point, it's probably true to say that nobody can control the dynamics. They're too complicated and we're not that smart. Attempts to steer things in a direction will probably fail. What can be done though is to try to control what we have the power to control, the behavior of individual agents, the editors, to make sure that they follow the rules, all of the rules, in the hope that what emerges is okay. I look to other complex systems made up of many interacting agents that are meant to have a shared objective function but in fact have complicated competing interests, social insects in colonies where the queen mated with many different males for example. There is misalignment between the interests of subsets of workers. How do they deal with this conundrum? They invest a great deal of energy in worker policing to make sure everyone is following the same set of rules. Sean.hoyland (talk) 07:06, 13 July 2024 (UTC)

Sean, I agree with basically everything you say, except that I prefer to use a Spherical frictionless chicken in my models. ;-)

1. We already have two classes of editors: Those of us with social capital, and everyone else. Disposable accounts are a thing, but they are primarily a thing for spam, rather than geopolitical POV pushing, especially when non-ECP editors get kicked out of discussions
2. One of my concerns about the ECP approach is that it reduces the size of the pool that could edit PIA articles. IMO we need some limits, but we might actually benefit from more editors there, rather than fewer. See Template:Registered editors by edit count – click to Table 2 if you want to see the numbers calculated against those who have made 1+ edits, rather than those who managed to figure out Special:CreateAccount. BTW, while 14 million accounts have made 1+ edit ever, only about 800K made 1+ edit last year, and about half of those never came back after the first day. User:WhatamIdoing/I am going to die compares this against what it would take to replace an editor like me.
3. I think you are right about not everyone prioritizing the same goals in exactly the same ways. In other areas, I have seen editors make decisions based on a desire to influence sources. For example, years ago, some editors were upset with a source about Chemotherapy. The source wasn't wrong (i.e., chemo is vital for some forms of cancer and has limited value for others), but they were upset about the overall value (specifically, chemo is vital for uncommon forms of cancer and has limited value for common forms, which means that the "median" patient probably gets a smaller benefit than they believe they're getting). They were doubly upset that since the Wikipedia article started citing this paper, the paper had been cited several more times in the formal literature, and they suspected that these authors were finding the source in the Wikipedia article. So we removed it, because editors wanted to influence future sources. OTOH, I don't think this was a case of trying to push content up the hill, away from what sources say. I think it was an attempt to push the content towards "alignment with the sources I happen to be familiar with" (e.g., an oncology textbook that emphasizes the importance of chemotherapy as one part of a comprehensive treatment plan, but never tried to calculate the isolated benefit of just the one part).
   I assume that the same thing happens in many areas: The politician wants the article to say "known for freedom" instead of "known for conspiracy theories"; the company wants the article to say "fourth largest producer of widgets" instead of "responsible for the massive pollution scandal"; and presumably everyone on all sides of PIA want their side to be held up as the One True™ Righteous Cause. But I still think that the article will be better if people from all those sides talk it through, than if I get to decide on my own what the article(s) will say. (There's an open question about whether we will be better off, as these conversations are doubtless wearing and sometimes painful for the community members involved, but I am convinced that WP:YESPOV is correct about what's best for the article.)
4. Strict rule enforcement is also wearing and sometimes painful, and I'm not sure that it's always humane. When someone is terribly upset, it might be better to gently and privately encourage them to take a break than to sanction them for experiencing reasonable emotions. Right now, we likely have people editing PIA articles who are mourning family members, and many more who are a little more distantly but still significantly affected. When people are being told that their lives don't matter because they have the 'wrong' ethnicity, religion, or nationality, we can't expect them to be totally impersonal about it. The 2024 United States presidential election is being written by editors who are afraid about what will happen if the wrong guy gets re-elected, based on sources written by authors who are afraid about the same thing, and we expect this to just get worse. We have some young trans editors who are very upset about the Cass Review, which looks like a harbinger of a worldwide shift in the way gender care has been handled, and they're watching this unfold and doubtless thinking that the very thing they valued most when they were trans teens is being denied to the next generation, just because it has only been proven to be very, very, very wanted by the trans teens, which the establishment doesn't care about, and not proven to have certain practical long-term outcomes that the establishment does care about. We could kick all of these affected people out of these articles, but (a) that leaves us with a smaller population working on them, (b) it leaves us with fewer voices for certain POVs, (c) we'll probably end up with worse articles as a result, and (d) it doesn't seem very kind – or effective, when you think about the socking problem – to tell people to go away from the thing they most care about.

WhatamIdoing (talk) 08:02, 13 July 2024 (UTC)

Is this intended only for AI area? ECP is broader than that, although AI is Arbcom specified.Selfstudier (talk) 13:39, 10 July 2024 (UTC)

It would have to be all areas - I don't think there is a reasonable way to separate it. BilledMammal (talk) 20:02, 10 July 2024 (UTC)

I'm not sure this would make much of a difference. The "half in the mainspace" rule will likely make no significant difference, as editing the mainspace is what newer editors do. The "big edits" rule can be gamed; just hang out at RecentChanges for a few days to find blanking vandals, or run a script to add citation templates to articles. Two or three copies of {{cite web}} will usually produce the desired number of bytes.

ECP originally wasn't based on any sort of evidence that 500 was better than any other number, and this is also not based on any sort of evidence. I suggest that you collect some numbers. For example, we know that during 2023, about 800,000 accounts made 1+ edits (new and old accounts together). We also know that very few of those 800,000 editors have achieved ECP status. Can we figure out how many editors achieved ECP in 2023, and then how many would have done so, under the proposed rules? The first should be pretty straightforward; just figure out how many people in this list created their accounts during 2023. It's probably a bit more than half a percent of those who edited at all, so I'd expect an answer around 4K or so. I'm not sure what it would take to check the new requirements, but you only have to check them for the people who achieved ECP last year, because the ~795,000 editors who either already had it, or who didn't manage to make 500 edits yet, wouldn't be affected by these changes anyway.

If very few would be affected, then what's the point? It'd just be rearranging the deck chairs. But if a lot of editors would be affected, we will have to ask ourselves whether we truly want our small percentage of eligible editors to be even smaller. Our dispute resolution processes are built on the principle that when we have problems like POV pushing, we generally need more eyes on the situation, rather than fewer. WhatamIdoing (talk) 06:19, 14 July 2024 (UTC)

I ran some queries. There were 1968288 accounts created in 2023 (UTC), excluding any blocked with the "hideuser" option. 487317 have made at least one edit since creation (note that edit may have been in 2024). 1776 have edited at least 500 times since creation, 1773 more than 500 times. 1691 are currently extendedconfirmed; this link currently shows those 1691, plus the first from 2024 and the last from 2022 (note it displays the creation dates in your configured timezone rather than UTC). There are 106 accounts with at least 500 edits that aren't in the group, presumably most because they haven't made a 501st edit since reaching the 30 days. The 21 accounts in the group without 500 edits were manually granted extendedconfirmed. Anomie⚔ 13:40, 14 July 2024 (UTC)

Thanks. Is there any way to test those 'new' (2023) extended-confirmed accounts against the proposed rules, without having to do it manually? It's possible to do 2K if we have to, but that could easily take a week of full-time work. WhatamIdoing (talk) 23:49, 14 July 2024 (UTC)

Sure, someone could write code implementing whichever checks are proposed, and then run that list of users through the check. The above discussion is a bit too TL;DR for me personally to want to try to extract what the proposal(s) is/are though. But as a quick check, it seems 401 of the now-1693 extendedconfirmed accounts registered in 2023 have made fewer than 500 mainspace edits, and 235 have made fewer than 500 edits when excluding only the User and Draft namespaces (294 when also excluding User talk and Draft talk). Here's a query listing them: quarry:query/84853. Anomie⚔ 12:07, 15 July 2024 (UTC)

Thanks v much for putting some numbers to this. Selfstudier (talk) 12:16, 15 July 2024 (UTC)

New shortcut

Tracked in Phabricator
Task T369993

A recent "feature" on article pages (PC, Chrome) is an indelible box near the top left of article space, giving access to the list of headings. This is an unhelpful irritant to someone who simply wants to read an article, as it obscures the first words of several lines. Assuming it's a useful feature, can it be made minimizable or semi-transparent and becomes opaque when moused-over ? Doug butler (talk) 15:02, 13 July 2024 (UTC)

I'm not seeing this in Firefox or Chromium on Linux, logged in or logged out, using monboook, vector or vector2022 skins. If it is something that's from Wikipedia rather than your browser this is a question that's better suited to the technical village pump or phabricator than this board. Thryduulf (talk) 15:20, 13 July 2024 (UTC)

Screenshot with table of contents expanded

@Doug butler, are you seeing something like this, at the top of World? This screenshot shows the table of contents covering up part of the first paragraph. If you click the button right next to the =World= title, it will collapse. WhatamIdoing (talk) 19:59, 13 July 2024 (UTC)

Thanks, exactly that box, functions the same, but on article space, covering the first three or four letters on the first two or three lines of text (Vector (2022) everything vanilla standard). When an article is opened, the three dotted lines symbol is there alongside the title of the article, then appears (as my problematic box) as soon as I scroll down sufficiently that the title line is goes off-screen. Doug butler (talk) 23:40, 13 July 2024 (UTC)

@Doug butler, please try this link:

https://en.wikipedia.org/wiki/Katharine_Viner?safemode=1

The safemode=1 bit will screw up the infobox formatting, but don't worry about that. Just see if that fixes the problem or if the problem is unchanged. (I expect it to be unchanged, but the answer will tell us who to contact about getting it fixed.) WhatamIdoing (talk) 00:15, 14 July 2024 (UTC)

Thanks for the prompt reply. Behavior of that box exactly as before. Doug butler (talk) 00:24, 14 July 2024 (UTC)

Then I think we want @SGrabarczuk (WMF) and @Jdlrobson from the Web team. You said you're using Chrome on a PC. What version for Chrome and for Windows?

Does this behavior change if you change the size or zoom of the window/screen? WhatamIdoing (talk) 00:54, 14 July 2024 (UTC)

Windows 10 Pro 22H2 installed 25 July 2020 on Lenovo 4205 laptop i5

Chrome is up to date:

Version 126.0.6478.127 (Official Build) (64-bit) Doug butler (talk) 01:12, 14 July 2024 (UTC)

To clarify, my problem box remains in the same position on the screen as I scroll down through the article, so it masks just the leftmost three or four letters on the top two or three lines, assuming "Small" text selected. The box remains the same screen size with "Standard" or "Large" text selected. Size of the box increases and decreases proportionately with text size as Ctrl+ or Ctrl- invoked. Doug butler (talk) 01:01, 14 July 2024 (UTC)

This is included within Vector 2022 when the screen size is too small for a sticky header. To make the button semi-transparent unless hovered, add the following CSS to your personal CSS for Vector 2022:

#vector-page-titlebar-toc {
  opacity: 50%;
}
#vector-page-titlebar-toc:hover {
  opacity: inherit;
}

I'll see if I can create a patchset for this. Aaron Liu (talk) 02:49, 14 July 2024 (UTC)

Actually, add the following as well if you want it to be opaque when extended:

#vector-page-titlebar-toc:active {
  opacity: inherit;
}

Aaron Liu (talk) 03:15, 14 July 2024 (UTC)

I've opened the task, submitted the patch, and attached a {{tracked}} before the opening... ask. Aaron Liu (talk) 03:27, 14 July 2024 (UTC)

I might leave CSS alone and report back ? Should I subscribe to the task ? As you can tell, I'm not at all HTML-savvy. Doug butler (talk) 04:25, 14 July 2024 (UTC)

You don't have to subscribe to the task, but you're welcome to.

If you don't feel any need to have this solved urgently, then you could do nothing, and perhaps it will get fixed for everyone on an upcoming WP:THURSDAY. If you want it fixed sooner than that, then updating your account files will fix it just for your account. WhatamIdoing (talk) 05:47, 14 July 2024 (UTC)

It was an inconvenience, is all, and another week is not a problem. Thanks all for taking it seriously — most impressive service. Doug butler (talk) 10:30, 14 July 2024 (UTC)

Bot to automatically fix one class of dead http links

I recently corrected a dead link where the only change needed was to change the scheme from HTTP to HTTPS. It should be possible to write a bot that will automatically check each dead link with an http scheme and test whether changing the scheme to https resolves the issue. I'm not sure whther the process should be fully automatic or require using the Mark IV eyeball before confirming the changes. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 08:49, 18 July 2024 (UTC)

This seems like a good idea. I wonder if it would be possible to incorporate into an existing bot that scans for and fixes dead link like InternetArchiveBot operated by Cyberpower678 and Harej? Thryduulf (talk) 09:16, 18 July 2024 (UTC)

User:GreenC may also be a botop interested in this problem, but I do see a potential major issue, in that bots are generally incapable of determining whether a link is truly live: custom 404s and redirects to domain roots return "live" HTTP codes similar to a fully functional link that supports a cited claim. This would definitely be a task that requires supervision, to avoid changing link status from dead just because HTTPS returns a custom 404 instead of a pure HTTP code to the same effect. Folly Mox (talk) 14:14, 18 July 2024 (UTC)

I already do this with WaybackMedic at WP:URLREQ on a per domain and per request basis.

It's actually very rare for a http to be dead and a https live. It can also happen in reverse for example http://static.espn.go.com/nfl/news/2003/0722/1584068.html works but https://static.espn.go.com/nfl/news/2003/0722/1584068.html gives a security error due to a misconfigured site, although if you "accept the risk" it will work, but then brings up a slightly different page. The variety of problems with URLs is infinite, and most of them have problems, mostly related to this kind of stuff: WP:LINKROT#Glossary

Anyway, if there is a problem with a domain, report it to URLREQ. -- GreenC 14:26, 18 July 2024 (UTC)

Shorter link syntax in citations

The CS1 and CS2 templates have parameters to associate a URL with a text parameter, e.g., |section-url=. Typically these are derived from |url= by adding a fragment, e.g., #page=foo for a page within a PDF. It would make editing easier if there were a more compact way to express such URLs. Two options would be

1. Allow, e.g., |section-url=#fragment, as a request to use the fragment with the |url= value prepended.
2. Add new parameters, e.g., |section-frag=fragment, |section-PDF-page=pageno.

What's the best path forward? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 09:07, 18 July 2024 (UTC)

This can create problems elsewhere with tools when the URL is abstracted. The problem of abstracting URLs occurs in 100s if not 1000s of specialized templates that most tools do not support (there are too many) and thus bots and tools don't maintain the URLs, creating link rot, failure to account, etc.. It's almost always best to state URLs in literal form so standard tools can access them. -- GreenC 16:05, 18 July 2024 (UTC)

That sounds more like an argument for than an argument against. Having the URL path on only one parameter solves the problem of, e.g., updating |url= but forgetting to update |section-url=.

A similar problem occurs when a page number is specified as an external link; updating |url=https://path does not automatically update [http://path#page=PDF-page printed-page], although in this case a solution seems less obvious. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:54, 19 July 2024 (UTC)

Note that |section-url= is an alias of |chapter-url=, and chapter urls are not always on the same web page as the main body of the document being sourced. If one were to implement a shorter syntax of this type, you would not need new parameters as you propose, the hash character should be signal enough, as it is an invalid character in the content of a url that lacks a fragment. Mathglot (talk) 19:52, 19 July 2024 (UTC)

I meant for the two options to be mutually exclusive in regards to each specific parameter.

Yes, a leading hash is not valid in a URL, making it trivial to distinguish between a URL and a bare fragment. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 09:45, 21 July 2024 (UTC)

Have you already looked at Wikipedia:Citing sources#Links and ID numbers, which includes information about multiple ways to link to specific pages, giving examples for PDFs and Google Books? WhatamIdoing (talk) 21:18, 19 July 2024 (UTC)

I use CS1 and CS2 templates, and using |url=url with |title=title seems cleaner than using |title=[url title]. I do use explicit external lenks for, e.g., |page=. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 09:45, 21 July 2024 (UTC)

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)

If you're hoping for a constructive response, you might want to consider WP:TEXTWALL. And in the future, consider using paragraphs. Gråbergs Gråa Sång (talk) 06:44, 21 July 2024 (UTC)

I ask not to judge my writing.

Thank! Appspame (talk) 20:40, 21 July 2024 (UTC)

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)

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)

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.

I ask not to ignore the first message I posted.

Thank Jack. Appspame (talk) 20:36, 21 July 2024 (UTC)

First, I agree with Gråbergs Gråa Sång that the WP:TEXTWALL makes it hard to read.

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.

Do you have a RS for the original name being ישוע? Or for the Christian fathers adopting יִמַּח שְׁמוֹ וְזִכְרוֹ (abbreviated יש"ו) as his name? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 09:18, 21 July 2024 (UTC)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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

מתי 1:16... ("יַעֲקֺב הוֹלִיד אֶת יוֹסֵף בַּעַל מִרְיָם, אֲשֶׁר מִמֶּנָּה נוֹלַד יֵשׁוּעַ הַנִּקְרָא מָשִׁיחַ." ) Appspame (User talk:Appspame|talk]]) 22:03, 21 July 2024 (UTC)

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)

The New Testament was written in Koine Greek, not in Hebrew. Cullen328 (talk) 22:15, 21 July 2024 (UTC)

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)

If I didn't want to search in Greek I would contact you with a Greek caption, but I'm searching in Hebrew Appspame (talk) 22:30, 21 July 2024 (UTC)

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)

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)

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)

I brought all the proofs, I brought all the explanations!... Appspame (talk) 08:02, 22 July 2024 (UTC)

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)

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)

Do you think WP:RIGHTGREATWRONGS applies to what you want to be done on the English Wikipedia, whatever that is? Gråbergs Gråa Sång (talk) 11:26, 22 July 2024 (UTC)

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)

Aren't you the Wikimedia Foundation?! So what good are you to me?! Appspame (talk) 14:16, 22 July 2024 (UTC)

Like someone once wrote, that is the question. Gråbergs Gråa Sång (talk) 14:18, 22 July 2024 (UTC)

What?.... Appspame (talk) 14:20, 22 July 2024 (UTC)

Wikipedia is written by thousands of volunteers. The Wikimedia Foundation maintains its infrastructure, not its content. —Tamfang (talk) 06:01, 23 July 2024 (UTC)

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)

No, this is the English wikipedia; Wikimedia Foundation is something entirely different. And we (TINW) are here for the benefit of the readers, not for the benefit of editors with an ax to grind, and are subject to various policies, one of which is the requirement for reliable sources as defined in WP:RS. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:15, 25 July 2024 (UTC)

For the interested, related discussions on he-WP:[19][20]. Gråbergs Gråa Sång (talk) 11:23, 22 July 2024 (UTC)

• Comment: There appear to be 14 en-wiki articles where "ישו" appears. In all but possibly one a change from "ישו" would definitely not be reasonable as they either use it in contexts where that specific form is necessary and/or where the Yeshu/Yeshua::Jesus/Joshua distinction is discussed (Jews and Christmas, Public holidays in Israel, Toledot Yeshu, The Lost Tomb of Jesus, Jesus Trail, The Book of Nestor the Priest, Aleinu, Yimakh shemo, Yeshua, Yeshu, Isa (name), Arabic Name, Biblical names in their native languages). For Religious perspectives on Jesus the cited work would need to be consulted, but the way it's written suggests that it should be left as is. ^~Hydronium^~Hydroxide^~(Talk)~ 12:32, 22 July 2024 (UTC)

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)

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)

Assuming you mean the Academy of the Hebrew_Language (הָאָקָדֶמְיָה לַלָּשׁוֹן הָעִבְרִית), then your assertion does not appear to be reflected in the practice of that organisation. ^~Hydronium^~Hydroxide^~(Talk)~ 14:32, 22 July 2024 (UTC)

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)

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)

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)

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)

@Cullen328, it appears that you've accidently edited Appspame's comment to improperly add an expletive? Aaron Liu (talk) 15:59, 22 July 2024 (UTC)

Aaron Liu, that was an inadvertent burp from my phone. I apologize and have removed the error. Cullen328 (talk) 16:33, 22 July 2024 (UTC)

Automate suggesting wiki links?

One of the ways articles are discoverable is through wiki-links. Sometimes I come across articles that reference specific people or events, and there exists Wikipedia articles with exact matches to the inline text. This could also be a gamified task for new editors to look at proposed wiki links to be matched with inline text. It should reuse the existing visual editor interface as much as possible. Given the possibility of false/sloppy matches, these types of edits could be marked for multiple reviews, while still enable new editors to make constructive edits and have fun at it.

The main challenges I foresee are: implementing such a suggester and possibly encouraging excessive linking or worse, incorrect wiki links. ~ 🦝 Shushugah (he/him • talk) 14:09, 25 July 2024 (UTC)

What you describe is almost exactly Add a link, a feature developed by the Growth team. There is a discussion about turning it on at English Wikipedia as a test, feel free to join it. Trizek_(WMF) (talk) 14:24, 25 July 2024 (UTC)

WMF

Wikimedia Foundation Bulletin: an experiment

Hi all. We invite your feedback on a proposed way to improve communication from and about the Wikimedia Foundation. The Wikimedia Foundation Bulletin is an experiment to establish a more standardised format and cadence. It would include headlines and links from the Wikimedia Foundation's technical work; Foundation activities with communities and affiliates; as well as with other stakeholders like readers, donors, regulators, the media, and the general public.

A short overview of the concept itself is on Meta at m:Wikimedia Foundation Bulletin, with the first “trial” issue at m:Wikimedia_Foundation_Bulletin/2024/06-01 - also copied below. You can subscribe to the bulletin via talk page delivery on any Wikimedia wiki. Depending on the feedback received, we might start this as a regular Bulletin for the coming fiscal year (which starts July 1).

This is an experiment: we want to know what you think, what is missing, what is too much, and whether this is something that we should consider investing more time and effort into. Please post your feedback on the Bulletin talk page - on the concept itself, and suggestions on anything from the design to specific words used would also be helpful. You can also provide feedback in this thread; by email to askcacwikimedia.org; or at the next Conversation with the Wikimedia Foundation’s Board of Trustees on 27 June at 18:00 UTC.

On behalf of the Wikimedia Foundation Community Affairs Committee, MPeel-WMF (talk) 18:38, 18 June 2024 (UTC)

I've put the second issue below as well, and have signed this page up to receive them automatically in the future. Thanks. Mike Peel (talk) 12:38, 3 July 2024 (UTC)

Bulletin June 2024

Here is a quick overview of highlights from the Wikimedia Foundation over the first half of June 2024. Please help Translate.

---

Upcoming and current community conversations

Talking: 2024 continues

• Open AffCom Office Hours on Affiliates Strategy Implementation (June 19 at 14:00 UTC)
• Procedure for Sibling Project Lifecycle: Call for feedback (through June 23)

Annual Goals Progress on Infrastructure

See also newsletters: Wikimedia Apps · Growth · Research · Wikifunctions & Abstract Wikipedia · Tech News · Langauge and Internationalization · other newsletters on Mediawiki.org

• Improvements for editors with extended rights - Edit Check, PageTriage, Edit Patrol on Android, Release Rights improvements in Upload Wizard, and the Watchlist on iOS.
• Responding to other community needs with Edit Recovery, QR share, Multiblocks schema changes, AutoSuggestSiteLink and bringing back The Who Wrote That Extension.
• Voting on Community Wishlist Survey renaming (through June 20)
• Scholarship Applications for the Wikimedia Technology Summit (WTS-2024) are open (through July 10)
• Wikimedia Enterprise updates: Realtime Streaming Updates: Parallel Connections and Restart Support (June 14)
• AI for the people: How machines can help humans improve Wikipedia
• Designing the typography of Wikipedia
• Latest Tech News

Annual Goals Progress on Equity

See also a list of all movement events: on Meta

• Upcoming Wikimania (7–10 August, Katowice, Poland): the Program will be soon announced!
• Africa Growth Pilot: feedback is invited for Module 2: 101 Ways to Contribute to Wikimedia
• Let's Connect: about the new Event Registration Tool and a Women's Health in Wikimedia Projects
• WikiLearn: Check out some of our newest courses such as Open Refine for Wikimedia Commons
• WikiCelebrate: Celebrated the work of B20180, a prolific administrator of Thai Wikimedia projects and a content contributor in Thai and beyond!
• Community conferences: submission deadline for Round 1 applications: September 2.

Annual Goals Progress on Safety & Inclusion

See also blogs: Global Advocacy Blogs · blogs

• Final draft of the Movement Charter published on June 10. Movement Charter Launch Party on June 20. Ratification: June 25–July 9
• Evaluation of the U4C election results (ongoing)
• “Don’t Blink”: Protecting the Wikimedia model, its people, and its values in April 2024 (June 4)

Annual Goals Progress on Effectiveness

See also: quarterly Metrics Reports

• Feedback welcome on community collaboration page for annual banner fundraising campaign on English Wikipedia in India for non-logged in readers (planned for Aug 13 to Sep 10)
• Banner fundraising campaigns started in Japan, Spain (also on Catalan Wikipedia), Greece, Malaysia, Portugal, South Africa, and Sweden (through June 25)
• Progress on the plan: How the Wikimedia Foundation has advanced on its 2023-2024 Annual Plan goals – Part 3 (June 12)

Wikimedia Endowment updates

• The Wikimedia Endowment 2022–2023 annual report published
• First grantees – Abstract Wikipedia and Wikifunctions, Kiwix, the Wikimedia machine learning project and Wikidata

Board and Board committee updates

See Wikimedia Foundation Board noticeboard · Affiliations Committee Newsletter

Trustees talk about how the Wikimedia Foundation Board of Trustees works

• 2024 Board Selection: Call for Questions for candidates ended on June 12
• Affiliates strategy: Affiliate Health Criteria and changes to the User Group recognition process (June 12)
• Upcoming Board meeting: June 20 (agenda)
• Upcoming Conversation with Trustees: June 27

In the media

• Elections 2024: How Wikimedia is combating misinformation using AI, human intervention (June 2)
• AI ‘gold rush’ for chatbot training data could run out of human-written text (June 6)
• ‘We’re writing history’: Spanish women tackle Wikipedia’s gender gap (June 12)

Other Movement curated newsletters & news

See also: Wikimedia blog · Goings-on · Wikimedia World · Signpost (en) · Kurier (de) · other newsletters:

• Topics: Education · GLAM · The Wikipedia Library
• Wikimedia Projects: Communities newsletter · Milestones · Wikidata
• Regions: Central and Eastern Europe

Subscribe or unsubscribe · Help translate

Previous editions of this bulletin are on Meta. Let askcacwikimedia.org know if you have any feedback or suggestions for improvement!

MPeel-WMF (talk) 18:38, 18 June 2024 (UTC)

Wikimedia Foundation Bulletin June Issue 2

Here is a quick overview of highlights from the Wikimedia Foundation over the second half of June 2024. Please help translate.

---

Upcoming and current events and conversations

Wikimania Katowice

Talking: 2024 continues

• Register now for Wikimania Katowice (7–10 August 2024).
• Editing team community conversation - CopyVio Check and Real-time Checks (03 July 2024, in English)
• Growth team community conversation - New tasks for newcomers and patrollers' burden (16 July 2024, in Spanish)

Annual Goals Progress on Infrastructure See also newsletters: Wikimedia Apps · Growth · Research · Web · Wikifunctions & Abstract Wikipedia · Tech News · Language and Internationalization · other newsletters on Mediawiki.org

• Wikimedia Hackathon 2024: Good projects and good people!
• MediaWiki 1.42 general release.
• The Community Configuration extension is released to more Wikipedias.
• The Trust & Safety Product team published the Incident Reporting System MVP User Testing Summary and a project update on temporary accounts.
• Recent changes from the latest Tech News.
• Reference Check to be rolled out on all Wikipedias. Read the initial results from the Edit Check project.
• Concluded voting on Community Wishlist Survey renaming; new name now Community Wishlist.
• “Add an image” suggested edit was released to Wikipedia iOS app & Donation through native GPay is now available on the Wikipedia Android app.
• Talk pages permalinks are now available at all wikis.
• A new task force was formed to replace the disabled Graphs with more secure, easy to use, and extensible Charts.
• Wikimedia Enterprise Quarterly technical update focusing on machine readability, content integrity, and API usability.
• Proposal for a Product & Tech Advisory Council.

Annual Goals Progress on Equity See also a list of all movement events: on Meta

• Highlights and achievements & future plans from Wikisource Loves Manuscripts Project.
• Learn how to edit and upload to Wikimedia Commons with OpenRefine.
• Watch the recording of the 11th edition of Wiki Workshop where research sessions on topics like Disinformation, Reliability, Representation and Gender, Governance and Policy, were held.
• First edition of WikiLearn News released, highlighting opportunities and progress in the area of skills development.
• The WikiData tools everyone is talking about during the 2023 LD4 Conference on Linked Data.
• The Wikimedia Foundation has become a member of the Unicode Consortium.

Annual Goals Progress on Safety & Inclusion See also blogs: Global Advocacy blog · Global Advocacy Newsletter · Policy blog

• Evaluation of the U4C election results (ongoing)
• Building a public policy network from both sides of the Pacific: Lessons from the 1st Global Wiki Advocacy Meet-up.

Annual Goals Progress on Effectiveness See also: quarterly Metrics Reports

• Thoughts on the Wikimedia Foundation's annual plan from the Japanese Wikipedia community.
• Where is Wikimedia in the Climate Crisis? – a recap of sustainability work across the movement and at the Foundation for 2023. Foundation Sustainability metrics for 2023 also available on Meta.
• The Wikimedia Foundation's revamped social media strategy is available on Meta.

Board and Board committee updates See Wikimedia Foundation Board noticeboard · Affiliations Committee Newsletter

• Wikimedia Foundation Board liaisons published reflections on final Movement Charter draft.
• June 27 Conversation with Trustees Wikimedia Foundation Community Affairs Committee/2024-06-27 Conversation with Trustees: notes & recording including outcomes of the 20 June Board meeting and a discussion of the movement charter.
• Ratification vote on Movement Charter until July 9, 2024 at 23:59 UTC
• 2024 Board Selection: Candidates have answered community questions selected by the Elections Committee.
• Affiliates strategy: Affiliate Health Criteria and changes to the User Group recognition process (feedback page)
• Feedback on Procedure for Sibling Project Lifecycle finished on June 23. The revised version was published. Updates in July

Foundation statements

• Wikimedia Foundation statement on volunteer processes on reliable sources

Other Movement curated newsletters & news See also: Diff blog · Goings-on · Wikimedia World · Signpost (en) · Kurier (de) · other newsletters:

• Topics: Education · GLAM · The Wikipedia Library
• Wikimedia Projects: Milestones · Wikidata
• Regions: Central and Eastern Europe

Subscribe or unsubscribe · Help translate

Previous editions of this bulletin are on Meta. Let askcacwikimedia.org know if you have any feedback or suggestions for improvement!

Mike Peel (talk) 12:38, 3 July 2024 (UTC)

These are excellent. Please keep them up, we could find a better way to integrate links to such newsletters from a global news page on Meta as well. [perhaps alongside one-line links out to the latest newsletters on individual projects] – SJ + 17:59, 13 July 2024 (UTC)

thanks, Sj! just to clarify, are you talking about this page: Internal news media? --アンタナナ 10:06, 15 July 2024 (UTC)

I happened to view this with a different browser zoom level today, and FYI in case it helps, I find the one column version more readable than the two column version. –Novem Linguae (talk) 06:03, 14 July 2024 (UTC)

Thanks @Novem Linguae, very helpful - we've had the same feedback about the two column version on French Wikipedia too so for the next issue (or maybe the one after that) we'll make the switch to single column. MPaul (WMF) (talk) 09:30, 15 July 2024 (UTC)

Discussion at Wikipedia:Village pump (miscellaneous) § Voting to ratify the Wikimedia Movement Charter is now open – cast your vote

 You are invited to join the discussion at Wikipedia:Village pump (miscellaneous) § Voting to ratify the Wikimedia Movement Charter is now open – cast your vote. –Novem Linguae (talk) 14:03, 25 June 2024 (UTC)

@Novem Linguae as you know, I opened a discussion there on how people should vote, in my opinion. is this location okay for some discussion on this topic, as well? Sm8900 (talk) 15:05, 28 June 2024 (UTC)

I think we should discuss it at the other location to keep things centralized. –Novem Linguae (talk) 15:55, 28 June 2024 (UTC)

ok, noted. that sounds fine. Sm8900 (talk) 17:23, 28 June 2024 (UTC)

Discussion at Wikipedia:Village pump (miscellaneous) § The Community Wishlist is reopening July 15, 2024

 You are invited to join the discussion at Wikipedia:Village pump (miscellaneous) § The Community Wishlist is reopening July 15, 2024. –Novem Linguae (talk) 20:47, 4 July 2024 (UTC)

POTY (Picture of the Year) competition needs help!

POTY desperately needs new volunteers who can do the things required to run the competition. With the current state of the committee, it is likely that there will be no POTY this year, as the main member who ran scripts for the competition has burned-out from doing wikipedia tasks and isn't up for it. Others on the committee are also missing in action.

Check out the Discussion here [21]. •Shawnqual• 📚 • 💭 03:47, 6 July 2024 (UTC)

Consider posting to WP:VPT where our programmers hang out, and consider including in your post links to https://github.com/legoktm/poty-scripts and to https://poty-stuff.toolforge.org/ so that technical folks can easily examine the scripts. –Novem Linguae (talk) 17:57, 6 July 2024 (UTC)

I posted on VPT and did not get any replies! :-/ The section was just archived •Shawnqual• 📚 • 💭 07:29, 15 July 2024 (UTC)

@Shawnqual: Anyone figure out a solulu for this one yet? If not I may be able to pitch in. jp×g🗯️ 12:28, 22 July 2024 (UTC)

This might be the latest repo: https://gitlab.wikimedia.org/toolforge-repos/poty-stuff –Novem Linguae (talk) 20:01, 22 July 2024 (UTC)

Discussion at Wikipedia:Village pump (miscellaneous) § U4C Special Election - Call for Candidates

 You are invited to join the discussion at Wikipedia:Village pump (miscellaneous) § U4C Special Election - Call for Candidates. –Novem Linguae (talk) 03:33, 10 July 2024 (UTC)

Unnecessary line on fundraiser banner

Today I saw an exceptionally large banner on a wiki page (while not logged in), requesting donations. While this topic has been discussed previously, however this message states "it will soon be too late to help us in our fundraiser." This statement gives a clear message that Wikimedia is in dire financial condition and will soon go bankrupt, disregarding its ever growing 'substantial financial resources'. I have observed discontent among editors as well as readers about aggressive donation campaign sometimes, this one is clearly misleading (or maybe even a fraud for its language). Even after acknowledging the fact that there are multiple projects under Wikimedia (also those beyond the sisters of Wikipedia), it is nowhere accurate to say "it will soon be too late to help us in our fundraiser." Given that we editors strive hard to make articles as accurate and void of fringe theories as possible, this statement should be removed, and rather there should be some rules on how this banners are made. ExclusiveEditor _{Notify Me!} 13:39, 10 July 2024 (UTC)

I'd interpret this differently -- to me it says the fundraiser will soon be over and if you want to donate during the fundraiser, soon it will be too late. Mike Christie (talk - contribs - library) 13:51, 10 July 2024 (UTC)

Oh come on, Mike. If I said "it's nearly too late to pull me out of the water!", would you think I was drowning, or nearly finished with my swim? The fundraising team are clearly pushing the community-established limits on banner language with this one.

@ExclusiveEditor: It might be more effective to raise this at Wikipedia:Fundraising/2024 banners. – Joe (talk) 14:00, 10 July 2024 (UTC)

Joe, thanks for the link; I think I'd seen that before but forgotten it. I don't see the banners myself as I'm always logged in so perhaps I'm not as sensitized to the language as others (or as others who've been discussing this for a while). I agree it's striking a note of urgency that takes a second to interpret; I wouldn't blame a reader of that text who -- for a moment -- thought it meant what ExclusiveEditor said. But it seems harmless to me to have text in a fundraising banner that says "this fundraising period is coming to an end; please donate now before you it ends". Do you read the linked RfC as saying that no text connoting urgency should be included in a fundraising banner? Or is it just that the urgency mustn't be in service of one of the points bulleted in that RfC close? Mike Christie (talk - contribs - library) 14:29, 10 July 2024 (UTC)

I see it now @Mike Christie:, however would the people be not able to donate once the fundraiser is over? It is just creating an uneasy and unneeded sense of urgency. It is like say a youtuber who knows people will subscribe to his channel once they see at least of his video, but for that he puts a clickbait thumbnail over his video. It is not up to the standards of Wikipedia. Rather like me, many would take the wrong meaning out of it, especially from non English speaking countries. By the way I've started a discussion at meta:Talk:Fundraising#About Wikipedia:Fundraising/2024 banners for this, however I am not closing this because I've also suggested about a set of rules that mediates the banners, discussion about which could still be made here. ExclusiveEditor _{Notify Me!} 16:36, 10 July 2024 (UTC)

Clearly it is controversial and subject to negative interpretations, so pull it out pending some further development. BD2412 T 23:11, 10 July 2024 (UTC)

• FWIW WMF members from the Fundraising team were aware of issues with this line since 3 weeks. Some of us shared feedback on nearly identical text at meta:Talk:Fundraising/WMF India fundraising campaign. The reply we got from User:JBrungs (WMF) and User:SPatton (WMF) was that this text will go through "testing".

It was not made clear what said "testing" would be on. I thought it implied "We will test multiple options and choose the one that gives most fundraising" which is fairly counterproductive. But 20+ days after the feedback, the fundraisers launched anyway with the odd phrasings, without clarity on how much of the 30 day period is "testing" and "production" phase. Soni (talk) 15:08, 11 July 2024 (UTC)

Clearly the testing was not of something that it should've been, or else this would not have started. ExclusiveEditor _{Notify Me!} 15:16, 11 July 2024 (UTC)

It does look like it was intended to imply things about the WMF's financial position that aren't true. Perhaps there was some thought that people might give because of that false urgency without checking to see if the WMF was really going bust. It's rather unseemly for the WMF, an organization that seeks to educate, to indulge in deception.Wehwalt (talk) 16:40, 11 July 2024 (UTC)

Thanks for the discussion here.

The intention behind the line "it will soon be too late to help us in our fundraiser" was to convey that “this fundraiser will soon be over,” not to suggest any financial threat to Wikipedia. We intentionally avoid peppering Wikipedia with multiple donation buttons, so very few people donate outside of a campaign. The fundraiser is the key moment for giving, and we aim to emphasize the importance of our work with a sense of urgency. The general use of urgency in messaging is an important and appropriate persuasion tool in nonprofit fundraising. It helps potential donors understand that their donation is necessary to advance a cause they care about.

However, ExclusiveEditor, your interpretation of the line as indicating a threat to Wikipedia’s financial stability is enough for us to reconsider its phrasing. We will workshop this line to avoid any misunderstandings.

Currently, we have no active banner campaigns live, aside from a brief systems test this week in India. Soni, to respond to your query, in India, we plan to run 2-3 short tests before the campaign goes live on August 13th. These tests will ensure our payment systems work at scale and help us refresh the content in response to the feedback we have been receiving. Sheetal Puri (WMF) (talk) 22:34, 11 July 2024 (UTC)

and help us refresh the content in response to the feedback we have been receiving Can you elaborate? What feedback do you expect to receive during the 2-3 short test period?

Is that feedback from editors? Readers? Is there a space where said feedback is collected so it's clearer to follow along what the changes are motivated by Soni (talk) 23:27, 11 July 2024 (UTC)

Why not use the exact words "this fundraiser will soon be over" if that is what you are trying to say? If you have to decode it for the editing community then presumably readers are having the exact same misinterpretation as us. * Pppery * _{it has begun...} 23:34, 11 July 2024 (UTC)

(e/c) I can't think of a way of saying "this fundraiser will soon be over" that actually conveys the meaning "this fundraiser will soon be over" in a clear and straightforward way. DuncanHill (talk) 23:35, 11 July 2024 (UTC)

Emails to past donors account for a very substantial part of revenue.

For reference, there is similar language in the current English fundraising emails (Email 1, Email 2, Email 3, Email 4) as well. For example:

• "I’m sorry to interrupt, but it's Friday, June 14, 2024, and time will soon run out to help us because the clock is ticking on this fundraiser." (Email 2)
• "But time will soon run out for you to help us in this fundraiser, so if you've been holding off until “later”, this is your moment. We need you. Please, remain one of Wikipedia's rare supporters." (Email 3)
• "I know I said I was done in my last email, but it's Friday, June 14, 2024, and we haven't reached our goal. There are only a few days left in this fundraiser to make a difference. You have shown with your last donation how committed you are to helping us sustain Wikipedia. Please, remain one of the 2% of supporters who propel this important mission forward. It matters. We need you. Please remain an active Wikipedia supporter." (Email 4)

Also worth looking at:

• "We don’t charge a subscription fee or run ads because we don’t want to put barriers between you and the knowledge you seek. In return, can we count on your support today?" (Email 1)
• "Major websites have come and gone; new generations are growing up with no memory of a world without the connectivity and instant gratification of the internet. We owe it to them, in a world that is always changing, to keep Wikipedia free for everyone. Like it always was and always should be." (Email 2)
• "This might be my last chance to request, so I want to make sure this third email reaches everyone who might donate. Right now, we're at a critical stage of our fundraiser." (Email 3)
• "You have shown with your last donation how committed you are to helping us sustain Wikipedia. Please, remain one of the 2% of supporters who propel this important mission forward. It matters. [...] But I hope you'll agree that in a world where disinformation is everywhere, it is crucial that everyone has access to trustworthy information. We need our community of donors to help us reach our goal, and time will soon run out in this fundraiser." (Email 4)

Emails to past donors account for a very substantial part of revenue. --Andreas JN466 07:23, 13 July 2024 (UTC)

Revamped community wishlist is now open

 You are invited to join the discussion at meta:Community Wishlist. –Novem Linguae (talk) 05:37, 17 July 2024 (UTC)

Living without the WMF?

The political evolution of the US is worrying, given that the WMF is based there. What if in a few years the US government takes control of the WMF, seizes its assets, or becomes otherwise hostile? Can Wikipedia as we know it survive without being based in the US? Are there plans for decentralization or redundancy? Sylvain Ribault (talk) 19:08, 18 July 2024 (UTC)

Without speaking to the political situation, I will note that Wikipedia is backed up on server farms in other countries, and anyone can operate a clone of Wikipedia from anywhere, even if they could not use the name "Wikipedia". Donald Albury 20:27, 18 July 2024 (UTC)

This sort of doom-mongering is never helpful. * Pppery * _{it has begun...} 20:32, 18 July 2024 (UTC)

Interesting question. The WMF itself is pretty much entirely centralised, but it's always been pretty good at making it easy to mirror or fork Wikipedia. Our license is of course also a big help. So in this kind of scenario, I imagine preserving the content would be no problem at all, but reassembling the community would be difficult, and rebuilding the kind of financial resources the WMF has (to host, maintain, and develop Mediawiki) would be very challenging indeed. – Joe (talk) 20:42, 18 July 2024 (UTC)

And to what extent could the existing Wikimedia chapters help? How dependent are they from the WMF? Sylvain Ribault (talk) 09:01, 19 July 2024 (UTC)

Whatever dystopian future awaits the US, that the WMF would be taken over by political hacks is 3 or 4 apocalypses removed from reality. Headbomb {t · c · p · b} 11:59, 19 July 2024 (UTC)

What specifically in regard to wikipedia do you find worrying about American politics? Horse Eye's Back (talk) 17:24, 19 July 2024 (UTC)

I think the main actual obstacle is that Wikipedia's existence depends on a fairly high degree of active maintenence of the MediaWiki software, and also -- most crucially -- that search engines give us a gigantic volume of incoming traffic. Incidentally, the forks that have existed have routinely had trouble with being absolutely slaughtered in Google rankings because their content is all considered by the algorithm to be "plagiarized" from Wikipedia. jp×g🗯️ 12:26, 22 July 2024 (UTC)

Wikimedia Foundation Bulletin July Issue 1

Here is a quick overview of highlights from the Wikimedia Foundation over the first half of July 2024. Please help Translate.

---

Upcoming and current events and conversations

Wikimania Katowice

Talking: 2024 continues

• Registration for Wikimania Katowice (7–10 August 2024) is still open. Register to attend in-person or virtually until 26 July.
• The call for presentation submissions for the WikiArabia 2024 is open (until July 28).

Annual Goals Progress on Infrastructure See also newsletters: Wikimedia Apps · Growth · Research · Web · Wikifunctions & Abstract Wikipedia · Tech News · Language and Internationalization · other newsletters on Mediawiki.org

• The Community Tech team launched a new, continuous Community Wishlist. Wish submission is now open and can be filled at any time.
• Join the Product and Technology Advisory Council (PTAC) as technical volunteers. Applications are open until August 10.
• A new task force was formed to replace the disabled Graph with more secure, easy to use, and extendible Chart. You can subscribe to the newsletter to get notified about new project updates and other news about Chart.
• CampaignEvents extension, add an Image feature on iOS Wikipedia app and more recent changes from the Tech News. Read also other news in the previous edition.
• Dark mode - one of the most requested features will transform Wikipedia’s accessibility and is now available on select wikis, on mobile and desktop, in both reading and editing mode!
• MediaWiki insights into work done to improve security, ease of use, maintainability and overall code health. Also, a 25% increase in the number of authors who have committed more than 5 patches!
• Have you ever wished monitoring and fighting vandalism was easier from your mobile device? Edit Patrol is here to help.
• On the value of experimentation – a Future Audiences perspective.

Annual Goals Progress on Equity See also a list of all movement events: on Meta

• Wikicelebrate Ellie from El Salvador, a passionate Wikipedia trainer, event organizer and someone who finds joy in seeing others grow.
• Growing visual knowledge on the Wikimedia projects – the experiences of the Image Description Month.
• Enhancing Learning with Ancient Manuscripts – Wikisource Loves Manuscripts pilot project in Indonesia.

Annual Goals Progress on Safety & Integrity See also blogs: Global Advocacy blog · Global Advocacy Newsletter · Policy blog

• The call for candidates for the special election of the Universal Code of Conduct Coordinating Committee (U4C) is open now until July 19.
• Protecting the Wikimedia model, its people, and its values – highlights from the Global Advocacy Team.
• Reflections from the Digital Rights and Inclusion Forum 2024 (DRIF24).

Annual Goals Progress on Effectiveness See also: quarterly Metrics Reports

• Key Takeaways, Trends, and Lessons from FY23/24 Community Fund Grants

Board and Board committee updates See Wikimedia Foundation Board noticeboard · Affiliations Committee Newsletter

• Wikimedia Foundation Board of Trustees published its decision not to ratify the draft Movement Charter along with proposed next steps (minutes, resolution, appendix).
• Movement Charter voting is closed. At the time of drafting, the scrutineers are working to ensure that all votes on the ballot are valid.

Foundation statements

• Wikimedia Foundation’s Accreditation to the World Intellectual Property Organization was blocked for a fourth time by China.

Other Movement curated newsletters & news See also: Diff blog · Goings-on · Wikimedia World · Signpost (en) · Kurier (de) · other newsletters:

• Topics: Education · GLAM · The Wikipedia Library
• Wikimedia Projects: Milestones · Wikidata
• Regions: Central and Eastern Europe

Subscribe or unsubscribe · Help translate

Previous editions of this bulletin are on Meta-Wiki. Let askcacwikimedia.org know if you have any feedback or suggestions for improvement!

MediaWiki message delivery 21:19, 18 July 2024 (UTC)

Sunday July 28 Strategic Wikimedia Affiliates Network meeting (Results of Movement Charter ratification)

SWANs gathering for a conversation

Hello everyone!

The Strategic Wikimedia Affiliates Network (SWAN) is a developing forum for all Wikimedia movement affiliates and communities to share ideas about current developments in the Wikimedia Movement. It expands on the model of the All-Affiliates Brand Meeting (following the re-branding proposal by the WMF) to help lay some of the groundwork for further Wikimedia 2030 strategy process work.

At this meeting we will focus on the results of the Movement Charter ratification. We will also discuss the aftermath of the Board of Trustees' decision to veto the Movement Charter, including their recent proposals. We will also cover updates about upcoming Wikimania 2024.

This month, we are meeting on Sunday, July 28, and you are all invited to RSVP here.

UTC meeting times are 03:00 UTC and 16:00 UTC

Nadzik (talk) 17:35, 20 July 2024 (UTC)

Miscellaneous

Reliable sources controversy

Wikipedians might be interested in knowing about a popular article released yesterday about admin @David Gerard, the alleged systematic misuse of Reliable sources and numerous instances of editing under clear COIs across several years. The article has received substantial attention on Twitter (600k views in less than a day). I'm skeptical of some specific claims made in the article, but overall, I think that it makes important well-sourced accusations of misbehavior, and that the community (and admins) might want to have a broader discussion about it.

I'm not sure what would be appropriate venues for discussion on this. agucova (talk) 14:57, 11 July 2024 (UTC)

Appropriate venues would not include someone's blog or Twitter. I don't know whether David Gerard is right or wrong on the subject of reliable sources, but I do know that tracingwoodgrains.com and Twitter are not. Phil Bridger (talk) 15:22, 11 July 2024 (UTC)

They're words, written in the English language, which you can read and decide whether they're true or not.

I mean, if there's a "wet paint" sign on the bench, would you just ignore it and plop straight down because it doesn't have a green entry at RSP? jp×g🗯️ 19:13, 12 July 2024 (UTC)

Yes, they're English words, but they will only all be read be Wikipedia-obsessives (or, even worse, people who are obsessed with one Wikipedia editor) with too much time on their hands. "Wet paint" can be read in a split second. Phil Bridger (talk) 19:36, 12 July 2024 (UTC)

On a first read through, this is clearly a thoroughly researched piece by a writer who is familiar with how Wikipedia operates and diligently provides his diffs. It's not a random Twitter complaint to dismiss out of hand. It deserves careful consideration. – Teratix ₵ 15:59, 11 July 2024 (UTC)

no one is a villain in their own mind is very much my feeling from reading it. -- LCU ActivelyDisinterested «@» °∆t° 17:09, 11 July 2024 (UTC)

Sophocles worded it so much more eloquently. Traumnovelle (talk) 07:10, 13 July 2024 (UTC)

I did a spot check of several of the sources and conversations and did not particularly think it was fair in its analysis. It felt very deliberately set up to make the standard "Wikipedia hates conservatives" critique, especially in how it framed the result of the PinkNews discussion. ThadeusOfNazereth(he/him)^{Talk to Me!} 18:01, 11 July 2024 (UTC)

Yep. It's angry logorrhea from a Quillette fan. Nothing of consequence. XOR'easter (talk) 19:16, 11 July 2024 (UTC)

I hate when people think they can decide "what is of consequence" for other people. 2603:7000:92F0:1100:51CB:6D03:8226:ABA1 (talk) 06:45, 12 July 2024 (UTC)

Well, it could have been worse -- it could have been an angry driveby troll comment at the Village Pump. jp×g🗯️ 19:29, 12 July 2024 (UTC)

"Nothing of consequence" including BLP CoI violations? I don't intend to relitigate anything but that did seem pretty consequential to me. iczero (talk) 05:35, 14 July 2024 (UTC)

Most of the article did not focus on this at all, but rather on Gerard's behavior. This does not seem like a crucial consideration to the discussion. agucova (talk) 20:13, 11 July 2024 (UTC)

We're so blessed to have DG. I stopped reading when they damningly referenced his views on the Huffington Post, which apparently changed between 2010 and 2020. Shocking stuff. Firefangledfeathers (talk / contribs) 18:15, 11 July 2024 (UTC)

To add a summary for onlookers not looking to spend 2 hours diving into the article.

The article is a pretty in-depth investigation from someone familiar with Wikipedia policies, where they allege that David Gerard has, over the span of almost a decade, engaged in systematic and strategic editing in a personal crusade against several people, violating not only a number of enwiki policies, but also largely going unnoticed, despite a number of disparate ArbCom cases and reported incidents, all which failed to see a bigger pattern in his edits.

The author explains that a key way he managed to do this was by feeding negative information about some of these people to journalists, which would then publish articles with the information, which he would then use as references in their articles to portray them in a negative light. He would also use the Reliable sources system differentially, in numerous instances using it to justify his edits under COI.

The article contains many serious allegations, and my impression after digging into them is that at least some of them have substantial and straightforward merit, directly verifiable from the provided evidence.

I urge editors to not get bogged down on specific claims made in the introduction about the Reliable sources system, since this is not actually the main focus of the article. The accusations made are far more serious and far-reaching. agucova (talk) 18:17, 11 July 2024 (UTC)

Again, this is how I feel about it. The big claims are BlPs Ask me about air Cryogenic air (talk) 18:37, 11 July 2024 (UTC)

Yeah other editors are capable of reading, and having read it all I can't say I'm very jnoressed. "largely going unnoticed, despite a number of disparate ArbCom cases" I've yet to hear of an ArbCom case that goes 'largely unnoticed'. feeding negative information about some of these people to journalists I'm absolutely sure, beyond any reasonable doubt, that the journalist and editors of the Guardian didn't take one single persons word for granted without making certain of what they published. -- LCU ActivelyDisinterested «@» °∆t° 19:33, 11 July 2024 (UTC)

Note that the policy violation is not the feeding information to the journalists, but then using that reference to edit under a clear COI (not only being in a crusade against the person, but also having been a source). Also, with "largely going unnoticed" I meant that the crusades/COIs were what went mostly unnoticed. agucova (talk) 20:12, 11 July 2024 (UTC)

If they've been taken to ANI or ArbCom they haven't gone unnoticed, the results just weren't to some editors liking. And if a reliable source substantiates the claims then it's a very weak COI. -- LCU ActivelyDisinterested «@» °∆t° 20:31, 11 July 2024 (UTC)

Sorry, maybe I didn't express myself clearly. I meant that the ANI and ArbCom cases just didn't cover the accusations in the article, but instead focus on specific things that on their own don't look like flagrant violations. The Scott Alexander ANI did establish the COI, but didn't notice the other articles where Gerard had also done the same thing. The article threads them together to make a broader case. agucova (talk) 20:41, 11 July 2024 (UTC)

Well if there is really anything there, and I still don't believe there is, then someone will need to make a case at ANI or ArbCom with diffs to show the behaviour. But I would note that anything on rationalwiki has nothing to do with Wikipedia, same with Reddit, Twitter, Facebook, etc. I agreed elsewhere recently that editors making nasty remarks on external sites should be covered by Wikipedia policies (it isn't currently), but that would also apply to linking to tweats that do the same. Also anyone wanting to discuss the reliability of Pinknews should take it to WP:RSN, same with Quillette or Unz, Gerard did not decide anything about this sources, and any personal biases they may have (which I'm sure they do, as all people have biases) were only one voice in a community decision. -- LCU ActivelyDisinterested «@» °∆t° 21:13, 11 July 2024 (UTC)

I agreed elsewhere recently that editors making nasty remarks on external sites should be covered by Wikipedia policies - though it's worth pointing out that what people post here is still covered; linking to an offsite screed doesn't protect people from WP:ASPERSIONs. Agucova has posted repeated aspersions about DG in this thread, outright alleging a cloud of vague sinister activities with no specific policy-based accusations or evidence attached to them at all. If that keeps happening I would suggest a WP:BOOMERANG; it is not acceptable for editors to try and drag off-wiki harassment like this here. --Aquillion (talk) 21:48, 11 July 2024 (UTC)

I was noting the linking to a tweet, now linked by multiple editors, that describes DG as 'the Forest Gump of the internet' and that doing so is probably against policy. I was just trying to not point it out directly. -- LCU ActivelyDisinterested «@» °∆t° 22:26, 11 July 2024 (UTC

That's something I actually called myself, 'cos I keep being on the sidelines of interesting things. (Though I never played college football and don't run, like, at all.) The blog post now attributes it - David Gerard (talk) 22:30, 11 July 2024 (UTC)

Fair enough, I've struck my comment. -- LCU ActivelyDisinterested «@» °∆t° 22:34, 11 July 2024 (UTC)

Note my careful use of the word 'alleged'. I haven't made any accusations. I'm in the course of preparing a proper ANI case, but it's not simple or fast when there's two decades of context to go through. agucova (talk) 21:52, 11 July 2024 (UTC)

"Alleged" does not free someone from the constraints of WP:ASPERSIONs; the entire point of the policy is to prevent people from making vague handwavy aspersions of the sort that you are introducing here. --Aquillion (talk) 22:20, 11 July 2024 (UTC)

'Diffs or no allegations' is the normal standard, and those allegations should be at the appropriate venue. -- LCU ActivelyDisinterested «@» °∆t° 22:23, 11 July 2024 (UTC)

> journalist and editors of the Guardian didn't take one single persons word for granted without making certain of what they published

A Guardian article about LessWrong contained a number of inaccuracies (some were corrected after the LessWrong team pointed them out): https://x.com/ohabryka/status/1802563541633024280?s=46. I wouldn’t think they make certain of what they publish. Saminmihail (talk) 16:37, 16 July 2024 (UTC)

Relaible sources sometimes make mistakes. What is important is whether they aknowledge and correct those mistakes. Donald Albury 16:43, 16 July 2024 (UTC)

This article was also linked here. It seems to be today's Twitterstorm. If the people posting this want to get something done, rather than just whinge about how awful Wikipedia is, they need to make their point succinctly on Wikipedia, rather than expect people to read a very long blog post whose provenance we do not know. Phil Bridger (talk) 18:40, 11 July 2024 (UTC)

I've provided a summary above, but the article covers so many accusations that it's not easy to compress it all. It's just an inherently very complex case. agucova (talk) 20:13, 11 July 2024 (UTC)

After reading it myself, it mostly looks like nonsense written by an angry culture-warrior type who detests David and who is upset that WP:RSes don't cover their pet topics the way they like, but who doesn't have any actual arguments or diffs to back up policy-based complaints. It also looks like most of the other people who have read it seem to agree, so I'd suggest you either WP:DROPTHESTICK or make any actual arguments for specific policies you feel were violated and things you believe should happen on WP:ANI or WP:AE, with actual diffs that relate to policy-based arguments and not just links to random blogs. If you insist on doing so, I'd strongly suggest doing it without linking the screed in question - it's clearly not helpful and fails to make a coherent policy-based argument itself. Either way I'd expect a WP:BOOMERANG if you keep pushing it too hard; we have no control over what people post off-wiki, but on-wiki, editors are protected from WP:HOUNDing and WP:ASPERSIONS, which you're already pretty deep into. Pointing at a largely nonsensical blogpost from an axe-grindy culture-warrior and asking people to not get bogged down on specific claims while making vague handwavy aspersions against a well-established editor in good standing with stuff like the accusations made are far more serious and far-reaching is not acceptable. If you want to continue without becoming the focus yourself, then every single thing you say about DG needs to be extremely specific about what policies you feel have been violated, with specific diffs for each accusation; if you're unwilling to do that, you need to WP:DROPTHESTICK, accept that you got hoodwinked by a blog post, and move on, preferably with an apology to DG for bringing this nonsense here in the first place. --Aquillion (talk) 21:40, 11 July 2024 (UTC)

From a quick read, this seems to just be someone who has multi-decade beef with David writing a rambling and often nonsensical screed. Best course of action is to just ignore it, it'll blow over. Curbon7 (talk) 20:27, 11 July 2024 (UTC)

I read the article, and it doesn't make a bit of sense. What does the price of Bitcoin have to do with Gerard's influence over the definition of reliable sources? It piles up detail on detail with no clear explanation of what the actual bannable behavior is. Agucova's insistence that we "not get bogged down on specific claims" basically means "Gerard is bad, don't worry about understanding why". Toughpigs (talk) 21:15, 11 July 2024 (UTC)

I said to, "not get bogged down on specific claims made in the introduction about the Reliable sources system". I'm saying that the relevant claims are the ones after the introduction. agucova (talk) 21:56, 11 July 2024 (UTC)

• STOP - or at least pause. If we are going to talk about a specific editor, at least have the courtesy to notify them of the discussion. Blueboar (talk) 22:08, 11 July 2024 (UTC)

I apologize for not giving a notice to DG; I seem to have forgotten some of my Wikipedia etiquette with time.

Because I worry about further hurting the case for what, I believe, are serious accusations, I'll follow Aquillion's suggestion and WP:DROPTHESTICK. I'm ceasing discussion on this thread until I can write down a proper ANI case with a good restatement of the evidence in the article. Admins should feel free to lock down this discussion.

I don't feel like I'm the best person to write down an ANI case, so if anyone wants to take this over from me, feel free to let me know through my talk page. agucova (talk) 22:12, 11 July 2024 (UTC)

Thanks for covering this important controversy. There is a balance to be found between protecting whistleblowers and safeguarding the accused from potential defamation. But the mentality in this thread is too much about discarding the accusation without having taken the time to read them.

I don't know how representative the article is of David Gerard's edits in general, since it focuses on the problems. But the article is an in-depth investigation, well-written and well-sourced. The fact that it's self-published should not be a reason to simply ignore any piece of information from it, especially in the context of a discussion, and considering that it links to many Wikipedia diffs. As suggested here, there should be some nuance: "Self-published works are sometimes acceptable as sources, so self-publication is not, and should not be, a bit of jargon used by Wikipedians to automatically dismiss a source as 'bad' or 'unreliable' or 'unusable'.".

I do not know David Gerard personally, but regrettably, the article resonates with my experiences over the past few months. You can occasionally see high-profile editors that show a recurring pattern of strawman arguments, edit wars, sarcasms, and pedantry about Wikipedia's rules that justifies opinionated edits. I have much respect for the people who spend significant time trying to improve the encyclopedia. But it's tragic how aggressive activism and bad epistemics sometimes bring out the worst in very smart and morally dedicated people. Alenoach (talk) 21:17, 12 July 2024 (UTC)

TracingWoodgrains (talk · contribs · deleted contribs · logs · filter log · block user · block log) is an editor here. -- Valjean (talk) (PING me) 23:26, 11 July 2024 (UTC)

Thanks for the tag. I have edited only very rarely, and I do not believe it would be appropriate for me to step in for the first time as a participant in an ongoing controversy spurred by one of my articles. This is obviously a subject I have strong feelings about, but I do not believe I should bring those feelings onto Wikipedia given the conflict of interest created by my article. I believe my writing speaks for itself on this matter. TracingWoodgrains (talk) 23:46, 11 July 2024 (UTC)

Then you are admittedly not here to build the encyclopedia. Since you haven't broken any rules, I don't see any reason to block you for you to be blocked on that basis. Maybe you'll decide to become active. -- Valjean (talk) (PING me) 01:07, 12 July 2024 (UTC)

Hm, I guess you could put it that way? I don't believe that policy fits; it's not that I'm not here to build an encyclopedia, it's that I'm not here at all. I've never been an active Wikipedia user and am only responding to people now because they're tagging me in. I researched details about your site as a journalistic exercise from the standpoint of a curious outsider. Were I to edit in the future, I suspect having my first serious activity in the site be engaging in a detailed dispute over an article I wrote would be a poor way to begin. TracingWoodgrains (talk) 01:47, 12 July 2024 (UTC)

@Valjean: It's good that you "don't see any reason to block you [TracingWoodgrains] on that basis", because you can't block anyone on this website for any reason. -- Guerillero ^{Parlez Moi} 18:24, 12 July 2024 (UTC)

LOL! As well I know. I'm not an admin, but my comment was intended to prevent such a thing from happening. I had just witnessed an account related to this debacle blocked for that reason (NOTHERE), and it was justified. In this case, I don't see any justifiable reason for a block. My comment was purely preventive. After I wrote it, I realized that my comment might trigger such a reaction, so I finished off with that comment in order to prevent it. -- Valjean (talk) (PING me) 18:31, 12 July 2024 (UTC)

I have now stricken that wording, since it led to this misunderstanding. I hope the works. -- Valjean (talk) (PING me) 18:33, 12 July 2024 (UTC)

When somebody writes an article on an external website critical of Wikipedia, I am not aware of any standard practice to ping their account with vaguely-worded threats(?) of administrative action, and I would be opposed to starting such a practice, as it does not seem smart or useful. jp×g🗯️ 19:33, 12 July 2024 (UTC)

It would be nice if you read what I have written before commenting. There was no threat to this editor. I hoped they would begin editing more. I just wanted to prevent what happened to another editor from happening here. It was just written clumsily, so AGF. BTW, that other editor has been unblocked. -- Valjean (talk) (PING me) 01:36, 13 July 2024 (UTC)

What the post actually says

It is very strange to me how many people are in this section giving confident opinions about the merits of the claims in the post, while admitting to not having read it, or saying something about how its "provenance" is unknown -- it's not a cuneiform tablet, it's a blog post on the Internet, you can just go read it, and then use your brain to tell whether or not the things it says are true. If you aren't going to read it, then your opinion on whether it's true is almost by definition incapable of being useful. At any rate, it is fairly long, so I will reproduce here the summary I posted elsewhere.

If you read the article, it's not really a screed, nor is it "nonsensical", nor is it any of the other weird stuff people are saying who have not read it. For those without a lot of time on their hands, it's about an even split between:

1. Statements of fact that every drama-sniffer around here is already quite familiar with (people fling shit about politics all the time at RSN, Gerard was topic-banned a few years ago for aggressively pursuing COI edits in re Dr. Scotty Codex, etc)
2. Opinions that well-respected Wikipedians express all the time (it is a gigantic pain in the arse when people queue up AWB jobs to indiscriminately mass-remove deprecated sources; RSN is often a sewer).
3. Catalog of various based deeds David has done over time (represent WMUK for years, be the first CheckUser of all time, lead the charge against the crystal-woo morons, be the sysadmin of a really funny shock site, be right about the Chelsea Manning fiasco), various cringe deeds (get topic-banned after an aggressive COI campaign to defame aforementioned Dr. Scotty Codex, ongoing sloppy mass-removals of deprecated sources), and various neutral deeds (he hates cryptocurrency, and I guess he was a big LessWrong guy back in the day, which in retrospect makes the thing with Dr. Codex even more silly).

The main bombshell accusation being made in this piece against Gerard is something that basically everyone here knows: there is a big gaggle of libs who are always trying to use WP:RSP as a septic tank into which to flush newspapers they don't like. Now, before some bumberchute at Wikipediocracy gets their hemorrhoids up reading me type this dangerous harmful right-wing propaganda: it is not just libs who do this. Wikipedia, in its majestic equality, also lets Republicans act like chimpanzees about whether the Wetumpka Argus-Picayune or whatever is destroying our country and must be removed from all citations. But broadly, I think we are all pretty well aware of this. By volume, about 10% of RSN is discussion attempting to find consensus on what sources are reliable for use on Wikipedia, and 90% is rancid political mudflinging. Does anybody seriously disagree with this? It's a zoo! Clearly, we are ashamed enough about it being a zoo to insta-gib n00bs who show up and tell us so. But are we proud enough of our encyclopedia to actually fix it? jp×g🗯️ 19:09, 12 July 2024 (UTC)

I think you have you numbers back to front, the vast majority of RSN is banal questions about uncontroversial sources. The contentious discussions get lots of attention, but editors then miss all the minor discussions that go past unnoticed.

If anyone has any disagreement with consensus on Pinknews, Unz, or Quillette can open a discussion. If editors don't agree with them they might look to the quality of their arguments rather than posts that claim one individual is some master influencer. Yes the culture war generates lots of crap, but RSN isn't the cause of that.

Also again yes I read the whole post before even my first reply. -- LCU ActivelyDisinterested «@» °∆t° 19:38, 12 July 2024 (UTC)

Well, that's what I mean: there really are discussions assessing the reliability of random unfamiliar sources in the boring straightforward way the noticeboard is well-suited for. The problem is that there's been a separate system grafted onto that, in which people write thousands of words of barely-readable walltext trying to give incredibly detailed assessments of decades' worth of output by major national newspapers... and then the only possible outcomes are "green", "yellow", "red" and "gray". The noticeboard/source list format does not work very well for doing this. This separate system is operated almost entirely by political animus, and unlike most onwiki politics arguments, it has wide-ranging destructive effects on the entire project.

For example, if there is some big nasty 600-comment-long RfC about gun control at Talk:Gun control, the worst-case scenario is that the article gun control says something dumb, temporarily (there can be another RfC later, and it's pretty simple to go back to an old revision). But if there is some big nasty RfC about gun control at Wikipedia:Reliable sources/Noticeboard, the worst-case scenario -- it doesn't actually matter which side wins, because both sides call it "victory" when one of the the other guys' sources is shitlisted -- is that some hapless website/newspaper gets painted red or gray, and somebody will go on a cackling AWB spree and completely hose up ten thousand articles by ripping out half the references, including articles about other political stuff that had nothing to do with the original argument.

This will also tear up articles about random stuff that isn't even remotely political. Many of them will then run the risk of being deleted because there "have no sources" (read: they have perfectly usable sources that happened to employ a guy who wrote something really stupid about politics ten years later). The loss of this content and these articles is, in practice, typically permanent. Source deprecation/GUNREL is basically a cluster munition that causes collateral damage all over the project every time it's fired, and I think we would probably be better off if we tried to be cognizant about this and resist the urge to give everything a reductive color-coded label. jp×g🗯️ 20:11, 12 July 2024 (UTC)

But the flip side is that political bias can also lead people to place excessive weight on trivial things or the opinions of non-experts who don't really belong in the article; or, worst of all, to take things that have actually dubious sourcing and state it as fact. If we don't draw a line as to the quality of required sources, what happens in political articles is that angry partisans on all sides of a dispute cram in everything they can dredge up, either to push the article in one direction or in a genuine good-faith effort to "balance out" what they see as bias by others. This results in articles that are bloated, unreadable, full of dubiously-sourced points or counterpoints, and which generally fail to reflect the tone, focus, and accuracy we would find from higher-quality sources. I think that if you look over how high-traffic articles have progressed over the last decade (as RSN and RSP achieved their current state), they have mostly improved in every respect - more accurate, better sourcing, more neutral, and so on. See eg. this paper discussing it. Saying "we're losing content" isn't meaningful because high-traffic, well-established articles aren't supposed to grow endlessly; they constantly both gain and lose content. The question is whether we're maintaining a balance that reflects the best sources - ie. removing poorly-supported, marginal or undue things and adding high-quality well-sourced things in a more balanced manner - and overall I think we've been getting better at that over time. For the most part, the only egregiously unbalanced articles are ones that have few editors, and that's not something that can be solved with policy or practice, since those things still require editors to implement them. --Aquillion (talk) 02:52, 13 July 2024 (UTC)

I think perhaps the biggest issue is the "cackling AWB spree". Sure, we shouldn't rely on unreliable news articles, but winning an "argument" on RSP shouldn't be a good reason to rip sources out of a huge pile of wiki articles. It's a gross overreaction if anything and a huge pain to fix if/when yet another argument breaks out on RSP and reverses that "decision". iczero (talk) 05:27, 14 July 2024 (UTC)

I mean, that's an extremely hostile way to characterize it. The fact is that when there's a clear-cut RSP decision, it needs to be implemented eventually; when a source comes up at RSP, that usually means there are constant disputes over it, which in turn means that people are using (or trying to use it) all over Wikipedia. And usually, people only implement it on scale for extremely clear-cut results (generally just deprecation; mere unreliable and other-concerns-exists results get implemented much more slowly and with more focus on controversial, exceptional, or BLP-sensitive things.) Before people stepped up to start implementing them, sources like the Daily Mail remained used all over the wiki, despite a clear consensus that they were unreliable and should generally be avoided; cleaning that up is a necessary service. And, as I've said, I feel that on the whole this work has improved our articles - most of the complaints seem to essentially amount to people disagreeing with the RFC's outcomes, which is certainly not a reason to obstruct implementation. We don't have to WP:SATISFY everyone before implementing an RFC. --Aquillion (talk) 22:02, 19 July 2024 (UTC)

I believe there's a pretty big difference between "we ought to recheck articles using this source" and "indiscriminately remove absolutely every reference citing the source". The former is (generally) done by humans; the latter is done by pure automation with little to no regard to actual article content, whether it be good or bad.

I would argue the best way to implement RSP verdicts involves generating a list of all affected articles and attempting to replace the source (or, if not possible, removing the content). Otherwise, even simply tagging the source as unreliable (i.e. by ) is a better idea than an AWB spree.

Yes, perhaps some cases (like The Daily Mail) are clear-cut. Others may not be. In either case, automated removal is usually not a good idea. iczero (talk) 22:48, 19 July 2024 (UTC)

In a perfect world where all Wikipedia editors were paid full-time employees (or well-off retirees, or universal basic income recipients, or whatever) things would be different. But the world we live in is one where everybody is a volunteer, and there are far more tasks to be done than editor-hours to do them in. It's true that articles should not have stuff in them cited to bad sources, and that they should not have uncited material -- but I hope everyone can agree that simply going through Category:Articles with unsourced statements (currently 521,561) with a blindfold and a chainsaw removing thousands of kilobytes of text from each page would be so unhelpful as to arguably constitute vandalism.

Regardless of what we may claim for rhetorical or political reasons, it seems like elementary logic and common sense that something cited to a shite rag like the Daily Mail would still have a higher probability of being accurate than something cited to nothing at all -- so I don't think the situation is all that different, and I'm similarly opposed to chainsawing them. jp×g🗯️ 02:46, 20 July 2024 (UTC)

Statements tagged {{cn}} fall into a few broad categories:

• previously adequate source deleted (usurped by globally blacklisted host, unarchived deadlink, removed erroneously during rewrite, etc.)
• unreliable, deprecated, or verification failing source deleted
• source already present in article but not cited for tagged statement
• source exists in parent, related, or sister language article but never imported during split or translation
• source never provided.

Where no source was ever provided for a tagged statement, in the target article or any related article, some of these will have been confected, misremembered, or learnt in error from an unreliable source. I'm not sure what percentage of the time that's the case rather than someone just not bothering to write down where they read something where if they had recorded their source we'd accept it no problem.

I also have no strong insight into what percentage of claims tagged {{cn}} have never had a source versus have had a source that the tagging editor did not look for hard enough. But I would say that the probability of something cited to nothing at all being accurate is actually pretty good. Folly Mox (talk) 10:32, 20 July 2024 (UTC)

Yeah, in my experience the likelihood of an unsourced claim being true is somewhere above 90%, and the likelihood of something (e.g. celeb gossip) being sourced to the Daily Mail is like 99% -- it just really doesn't seem like a thing which needs to be aggressively fixed by removing the reference. jp×g🗯️ 12:29, 20 July 2024 (UTC)

Honestly my main take-away from the article is that anyone who edits a lot and has opinions is going to inevitably end up pushing those opinions one way or another. This is probably a bad thing but cannot really be fixed: the most we can do is take care of the more egregious episodes. —Ashley Y 19:55, 12 July 2024 (UTC)

Usual disclaimer that David Gerard is a huge asset to the site and is usually right... but... without relitigating old disputes, let's not say that "[DG] was right about the Chelsea Manning fiasco". That was undoubtedly his lowest moment. What could have been a boring, standard WP:Requested Move turned into months of drama because DG insisted on doing the move out of process. If he had just dropped off a !vote like any other editor, or hell, done nothing, the article was going to move anyway, as indeed it eventually did after the dust settled. Just rather than having it be a community decision, just like 99.9% of other potentially controversial moves, he just tried to cowboy the move through on grounds of personal authority? It was a mistake. It made the result weaker, not stronger, as it opens up tales like this about admin abuse as the reason why, rather than "no this is what the community decided." The lesson is to just wait for the discussion to close. SnowFire (talk) 03:48, 14 July 2024 (UTC)

Recommitting to Wikipedian greatness

I was inspired by the article to form and write up some convictions about what makes Wikipedia great, and how we can recommit to its sustained improvement. Thanks for taking a look if you do. Pizpa (talk) 14:02, 18 July 2024 (UTC)

Advice on a merger misstep

Re the merger I asked about here yesterday, when I created the {{merge to}} and {{merge from}}, I had not seen Wikipedia:Merging. Because of that and a lack of forethought on my part, I created the discussion in the talk page of the source article rather than that of the destination.

I now see that the destination article is a more sensible location, if only because, should the merger take place, then the now-stump (okay, redirect) source article would be a too-out-of-the-way (if not impossible) place for the historical record of the merger discussion. Darn!

A complicating factor is that the discussion has since been joined by another editor.

How—if at all—should I proceed to remedy my misstep? PaulTanenbaum (talk) 15:47, 16 July 2024 (UTC)

@PaulTanenbaum, the first thing to do is not worry, because Wikipedia:Wikipedia is not a game of Mother, May I? If you make a misstep, it's okay.

The two usual things to do (yes, this happens often enough that there are usual things to do!) are:

1. Put a note on the 'other' talk page that links to the existing discussion, and proceed as if everything is 100% normal, or
2. Cut/paste the entire existing discussion to the 'correct' talk page, and set things up as if you had done everything perfectly from the first moment.

If you choose the first approach, please make sure that the "(discuss)" links in the mergeto/from templates are working (on both 'to' and 'from' pages).

If you choose the second approach, I suggest that you tell the first commenter (e.g., on their User_talk: page) why you moved the discussion and give them a link to its new location. Also leave a note on the 'incorrect' talk page that points to the discussion's new location.

Finally, if you'd like to avoid this problem in the future, go to Special:Preferences#mw-prefsection-gadgets-gadget-section-browsing and enable Twinkle. Then, in the future, you can use the TW menu > Tag > merge dialog box to make sure that everything automatically goes in the ordinary place. WhatamIdoing (talk) 22:46, 17 July 2024 (UTC)

Yizhi Jane Tao

• Yizhi Jane Tao (edit | talk | history | protect | delete | links | watch | logs | views)

There's someone who have been vandalising this entry for more than a year, ranging from unjustifiably deleting important information to sharing irrelevant rumours about the biographee. Rewed (talk) 21:55, 17 July 2024 (UTC)

@Rewed, please see Wikipedia:Requests for page protection.

The easiest way to submit a report is to go to Special:Preferences#mw-prefsection-gadgets-gadget-section-browsing and enable Twinkle. Then, go back to the page and find the new 'TW' menu (near the watchlist ☆ button). Choose "RPP" from the Twinkle menu. Fill the in the form with a brief explanation of the problem and your request (e.g., for WP:SEMI to stop editing by the unregistered editor) . WhatamIdoing (talk) 22:49, 17 July 2024 (UTC)

I have protected the page. Please keep an eye on the talk page, to see if someone requests changes. Graeme Bartlett (talk) 22:52, 17 July 2024 (UTC)

Wikimedia Movement Charter ratification voting results

You can find this message translated into additional languages on Meta-wiki. Please help translate to other languages.

Hello everyone,

After carefully tallying both individual and affiliate votes, the Charter Electoral Commission is pleased to announce the final results of the Wikimedia Movement Charter voting.  

As communicated by the Charter Electoral Commission, we reached the quorum for both Affiliate and individual votes by the time the vote closed on July 9, 23:59 UTC. We thank all 2,451 individuals and 129 Affiliate representatives who voted in the ratification process. Your votes and comments are invaluable for the future steps in Movement Strategy.

The final results of the Wikimedia Movement Charter ratification voting held between 25 June and 9 July 2024 are as follows:

Individual vote:

Out of 2,451 individuals who voted as of July 9 23:59 (UTC), 2,446 have been accepted as valid votes. Among these, 1,710 voted “yes”; 623 voted “no”; and 113 selected “–” (neutral). Because the neutral votes don’t count towards the total number of votes cast, 73.30% voted to approve the Charter (1710/2333), while 26.70% voted to reject the Charter (623/2333).

Affiliates vote:

Out of 129 Affiliates designated voters who voted as of July 9 23:59 (UTC), 129 votes are confirmed as valid votes. Among these, 93 voted “yes”; 18 voted “no”; and 18 selected “–” (neutral). Because the neutral votes don’t count towards the total number of votes cast, 83.78% voted to approve the Charter (93/111), while 16.22% voted to reject the Charter (18/111).

Board of Trustees of the Wikimedia Foundation:

The Wikimedia Foundation Board of Trustees voted not to ratify the proposed Charter during their special Board meeting on July 8, 2024. The Chair of the Wikimedia Foundation Board of Trustees, Nataliia Tymkiv, shared the result of the vote, the resolution, meeting minutes and proposed next steps.  

With this, the Wikimedia Movement Charter in its current revision is not ratified.

We thank you for your participation in this important moment in our movement’s governance.

The Charter Electoral Commission,

Abhinav619, Borschts, Iwuala Lucy, Tochiprecious, Der-Wir-Ing

MediaWiki message delivery (talk) 17:52, 18 July 2024 (UTC)

If the Board of Trustees had veto power, maybe they should've voted first before wasting the time of the 2,500 other people who voted. --Ahecht (TALK
PAGE) 20:39, 18 July 2024 (UTC)

I understand that "the 2,500 other people who voted" had an opportunity to provide anonymous comments along with their votes, so I can't see that as a complete waste of time. WhatamIdoing (talk) 18:13, 19 July 2024 (UTC)

About article Harbin

@Discospinster: Hi! If you translate this website this website with Google Translation, You will find a sentence that says: "Harbin" comes from the Jurchen language "Harwen", which means "swan". Because that website is the city government website, it should be a reliable source. This is different from the "Place of Drying Fishing Nets" statement introduced by English Wikipedia. I wonder if I can add it to the article? Suspected source, but not sure if it counts as original research. See also: Google Books (in Chinese). In addition, [22] [23] I found that some websites said that the literal meaning of "Harbin" comes from "Alejin", which means "honor". BUT THEY AREN'T ENGLISH SOURCES, ALSO I WAS NOT FIND ENGLISH SOURCES. And the harbin article Japanese Wikipedia have aparted these theories.-邻家的王子 (talk) 19:17, 18 July 2024 (UTC)

If the source is reliable it doesn't matter that it's not in English. You can add that information if it would be considered reliable. ... discospinster _talk 19:19, 18 July 2024 (UTC)

@邻家的王子, it is our policy that you can use Wikipedia:NONENGLISH sources. Editors should only use good sources, but there are many good sources that are written in other languages.

Finding a source that says "swan" does not prove that "place of drying fishing nets" is wrong. Sometimes it is best to say something like "Different meanings have been ascribed to the name. For example, the city government says the name means swan in the Jurchen language, and the Hong Kong Trade Development Council says that it means 'place of the drying fishing nets'."

When something needs a longer explanation, it should not usually be included in the Wikipedia:Infobox. WhatamIdoing (talk) 20:28, 18 July 2024 (UTC)

Talk:Evangelos Marinakis has an RfC

Talk:Evangelos Marinakis has an RfC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. D.S. Lioness (talk) 18:01, 22 July 2024 (UTC)

This appears to be a question about whether to include the word oligarch. WhatamIdoing (talk) 18:24, 23 July 2024 (UTC)

That's right! D.S. Lioness (talk) 18:25, 23 July 2024 (UTC)

Performing a random pages test on business articles

I've been focusing a bit on Wikipedia's articles on businesses recently. I think anyone who spends even a little time in the topic area knows we have problems with promotion, COI/paid editing, and dependence on non-independent sourcing. However, it's difficult to find hard numbers on just how big the problems are. To remedy this, I'm trying to obtain a random sample of a few hundred Wikipedia articles on companies to assess the extent to which they comply with our content policies. However, I'm having a bit of trouble working out how to get a good sample:

• Idea 1: Hit Special:Random. If article is about a company, add to list. Otherwise discard. Repeat until satisfied with number of articles on the list. Problem: Time-consuming and impractical for single editor.
• Idea 2: Use query service (Petscan or Quarry) to generate a list of company articles based on Wikipedia category system. Problem: Wikipedia category system not suited to this task. Structure of Category:Companies tree includes too many non-company articles (e.g. biographies in Category:People by company). Difficult to reliably filter.
• Idea 3: Query Wikidata for items about companies with an enwiki article. Problem: Potential for systematic bias in results if Wikidata editors focus on creating items for highly notable companies.
• Idea 4: Query DBpedia for company entities with enwiki articles. Problem: Classification as "company" apparently somewhat unreliable. Too many non-company articles in query results. Results seem to only appear if enwiki page was created before or up to ~2022.

I'm a bit stumped on what to do. Is there a way to adapt one of my ideas to produce good results? Or is there another idea I'm missing? – Teratix ₵ 16:05, 23 July 2024 (UTC)

For sure, trying to navigate the category tree from Category:Companies will just end up in a world of pain. You'll do much better using wikidata, say starting from company (Q783794). There's a dedicated query language for this sort of thing, see wikidata:Wikidata:SPARQL tutorial. RoySmith (talk) 16:15, 23 July 2024 (UTC)

Yep, I've written a SPARQL query that pulls a random sample of Wikidata items on companies with enwiki articles. My concern is that this sample may not necessarily be representative of a random sample of companies with enwiki articles, depending on how Wikidata editors select which enwiki businesses to create items for.

If, for example, Wikidata is more likely to have an item on a prominent rather than an obscure business (given both have enwiki articles), then a random sample of Wikidata items will feature more prominent businesses than a random sample of Wikipedia articles, which could lead to biased results.

But I don't really know much about how Wikidata editing works, so this could be wrong. – Teratix ₵ 16:33, 23 July 2024 (UTC)

(edit conflict)

Modify {{infobox company}} (used in ~85,000 articles) so that it emits a tracking category listing all articles that use that template? Allow the category to populate (could take a month or more). Add {{random in category}} to the category (or use Special:RandomInCategory) to fetch your random samples?

If there are other infoboxen that are commonly used in business articles, do the same with those templates; populate only the one common category.

When done, revert your template edits and delete the category.

—Trappist the monk (talk) 16:23, 23 July 2024 (UTC)

RandomInCatagory isn't very random (see T230700 and T200703). The strategy it uses is fine for an end user who wants to idly article hop, but I wouldn't use it for anything that requires statistical rigor. Keying off {{infobox company}} seems like a reasonable approach, but it suffers from a lot of the same problems the category tree DAG graph blob does. There's many similar templates, all related in a quasi-tree structure, but not easy to navigate. You might start from {{Organization infoboxes}}. It also suffers from the wikidata problem of people who write company articles being hit-or-miss about whether they add infoboxes of any kind.

You might want to go with multiple approaches to discover company articles and combine/deduplicate the results. Asking ChatGPT was amusingly useless. RoySmith (talk) 16:54, 23 July 2024 (UTC)

No need to mangle mainspace even temporarily with a tracking category; you can do something like this if you accept that transcluding {{Infobox company}} is good enough. —Cryptic 17:06, 23 July 2024 (UTC)

More than that, please don't "mangle mainspace". I know this idea was well-intended, but historically such things have been frowned upon. RoySmith (talk) 17:12, 23 July 2024 (UTC)

Please explain how tracking categories mangle mainspace. Link to the consensus discussion that states that such things have been frowned upon.

—Trappist the monk (talk) 18:04, 23 July 2024 (UTC)

I can't find it now, but there was a thread (perhaps on WP:VPT? a few months ago about one of the mobile apps adding tags for its own tracking purposes. The general consensus was that it was a bad idea. There's a related phab ticket at T360164. RoySmith (talk) 18:19, 23 July 2024 (UTC)

That was about edit summaries, not actual article content. WhatamIdoing (talk) 18:26, 23 July 2024 (UTC)

My wording was perhaps facetious, but - at least on my part - the intent wasn't so much as "this would be harmful" as "this would be impractical". It's going to take a while - perhaps a long while - for the category to get fully populated after you add it to the template (unless you null edit all its transcluders, which has its own problems). And you might have to go through several iterations of adding and removing templates to/from your dataset. —Cryptic 18:28, 23 July 2024 (UTC)

You can use toolforge:randomincategory for a more truly random selection from a category. It will be a bit slow the first time you run it on an 85,000 member category, but it should work (and it caches data for 10 minutes so subsequent runs should be fine). --Ahecht (TALK
PAGE) 18:02, 23 July 2024 (UTC)

Great idea. How about going the Petscan route but using one of the more systematised subcategories of Category:Companies, like Category:Companies by country? I imagine that almost all company articles are in that tree. – Joe (talk) 16:55, 23 July 2024 (UTC)

We've actually already tried that, specifically with cat:Companies by country. It gets way too many non-company articles way too quickly, even after pruning categories starting with "People by company". —Cryptic 17:13, 23 July 2024 (UTC)

Yeah, that's typical for category traversals. Honestly, having accumulated a few scars from trying things like this in the past, I think the wikidata route is your best bet. Or at least your least bad bet. RoySmith (talk) 17:19, 23 July 2024 (UTC)

You might be able to leverage Category:WikiProject Companies articles and the advice given to me at Wikipedia talk:PetScan#Help creating query. WhatamIdoing (talk) 18:28, 23 July 2024 (UTC)

Thanks for the input, everyone. I've reflected a bit and come up with a hybrid/kludge solution that might work: deliberately getting a larger than optimal sample from Category:Companies by country with Petscan/Quarry, filtering out non-company articles from the sample by checking with Petscan whether they match a Wikidata query for whatever unwanted types (e.g. biographies) tend to show up, then just manually discarding anything unwanted that sneaks through the filter. – Teratix ₵ 15:18, 25 July 2024 (UTC)

Porandla

-- GreenC 01:03, 25 July 2024 (UTC)

An impressive journey, originally located quite far inland, the village moved to the coast, then moved again back inland but more to the northeast. (The first and last both seem to be clear villages on google maps, and there is at the very least a street with that name in the location of the second one.) CMD (talk) 02:06, 25 July 2024 (UTC)

It also had a different name from 2011 before losing all its text in 2022, but seems never to have had any source. PamD 05:40, 25 July 2024 (UTC) expanded 08:49, 25 July 2024 (UTC)

This source supports the statement in the original version of the article, so perhaps we should revert to that and add the source - and choose whichever of the later-added coordinates seems appropriate. PamD 09:01, 25 July 2024 (UTC)

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)