Wikipedia:Village pump

Welcome to the village pump! Choose one of the sections below to start or join a discussion.

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

[[da:Wikipedia:Landsbybr%F8nden]]

Archiving

Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive). These dicussions will be kept archived for 7 more days. During this period the discussion can be moved to a relevant talk page if appropriate. After 7 days the discussion will be permanently removed.

News

"WP:VPN" redirects here. For the Wikipedia policy on the use of open proxies such as virtual private networks, see Wikipedia:Open proxies.

See also: Wikipedia:News

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)

Translator here. I stumbled across this group a couple of months ago. I was well into remediation of an article when I began to wonder who had created the thing -- something I normally care about not at all -- and discovered it was an OKA editor. I talked to the coordinator and was told that the editor in question was one of their best, that the editor was a really nice person, and the quality of the English was not really an issue, since nice people like me would fix things up. Oh, and I was just jealous because I was not myself getting paid.

I am far from a snob when it comes to English, and in fact spend most of my time on Wikipedia instilling readability into the work of subject matter experts whose English is not as good as they think it is, or who have not realized the problems with machine translation. For the most part consider it a good use of my time. I dropped the article after that remark though; I don't appreciate my pro bono efforts being taken for granted in anyone's business model. The article was inane as I recall, and seemed hastily written. Copy-editing is analogous to image editing. In the same way that you can't bring out pixels that aren't there, you can't add meaning to vague generalities; it requires research and at that point you are re-writing. More bytes does not equal more information necessarily, or even very often. The WP:PNT translation project essentially drowned in MT bullshit and this project is only a more subtle incarnation of the same problem.

I vehemently oppose removing the little quality control there is now for these articles, and we really do not need more of them.Elinruby (talk) 21:49, 27 July 2024 (UTC)

Hi Elinruby,

I assume the conversation you are referring to is this one? I don't think you are making a fair characterization of that discussion. As I responded in that thread, I completely agree that the improvements you made to the article were great, but I think one needs to make the distinction between "Improving the English" vs "Improving the overall writing". Sometimes, the English is correct but the writing can be improved (e.g., shortening of sentences that are too long). People with native English may still sometimes make poor sentence constructions. Of course, both the quality of the English and of the writing are important, but I was just saying that the two concepts are orthogonal. And if the sentence construction of the original article was poor, it makes it also harder for translators to resolve these in the translation, hence why sometimes it gets missed; but when someone flags our article on these grounds, we go back to it and improve them. In any case, these type of issues will not be caught through the AfC process.

I have never implied that you were "jealous" of the fact they are paid. In that thread, I had just asked whether your judgement of the work would have been as harsh if the editor was a volunteer rather than paid. 7804j (talk) 07:36, 28 July 2024 (UTC)

Of course you don't, and the answer is still no. I would not. I constantly clean up good articles in bad English because it is helping someone to share their knowledge, and I applaud the sharing of knowledge. I stick up for editors that other editors are trying to get blocked on CIR grounds because of their English, and to the best of my ability encourage such editors to contribute where they have a competitive advantage, ie where their knowledge of another language matters. I would, for the record, applaud your concept, in theory. But having been up close and personal with its products, I have to say that the quality is so poor that it literally would be easier to simply pay these people for the article topics they identify, then have someone else do the writing. That an article can be so bad it is better re-started from scratch is a concept I loudly poo-pooed back in the day of CTX. I hereby recant my then-assertion that nothing could be that bad. I will however stick to my guns on the weird concept that turning CTX off fixed anything at all. It is a useful tool when properly used, like all machine translation. I say this as someone who went though *all* of the flagged material with DGG and S Marshall. What was lacking in the CTX debacle and is still lacking today, as we see, is a sane workflow for translations, one that involves some quality control and does not massively penalize anyone who attempts to clean up a translation. As for whether you said the word "jealous" in that particular venue -- whatever. I seem to recall more than one conversation, as I was quite perturbed to discover than in your mind I was working for you.

I am not claiming that you engaged in personal attacks, just explaining one of several sorry episodes that made me stop trying to fix machine translation. I merely report that you did not seem able to understand that I think that if anyone is going to pay anyone for anything at Wikipedia it should not be for creating ever-increasing piles of dreck. Those piles are what we have now, not solely because of you of course, but you are adding to them using the same badly broken system, where incomprehensibly translated articles may or may not get flagged and may or may not go to WP:PNT, where as far as I know nobody works on them at this point. Sending them back to the original writer is a laughable solution btw, and this is true of AfC in general. Anyway. AfC is not very good-quality control, it's true, but it is *some* quality control. We could perhaps have a conversation on what could be done better, but as I told you then, it is important to realize that I am not available to clean up after you. I have much more interesting things I am trying to clean up, and this is true of most other wikipedia editors. Elinruby (talk) 21:50, 28 July 2024 (UTC)

For the record, I am jealous of folks being paid to do wiki work (more than I am, as my work, to some degree, already involves some peripheral interaction with Wikimedia...), and I do wish I could write for wiki as a full time, salaried job. And I do not mind saying so - and still supporting this project :P _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 09:59, 28 July 2024 (UTC)

In many ways I wish you could too, Piotrus. I would btw support your students not having to go through AfC if you were willing to vouch for the results. We have had this conversation before about content creation. But this is another instance of you supporting the wrong people, perhaps for the right reasons, imho. Elinruby (talk) 21:50, 28 July 2024 (UTC)

FYI almost no education projects use AfC; it is not required and it is cumbersome and too backlogged to be reliable in a setting with deadlines. I actually have data on that (as in, data supporting the claim most educational project use sandboxes, not draft space), from my research into the educational and Wiki stuff. _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 10:01, 31 July 2024 (UTC)

I believe Piotrus is correct, but to put some numbers on it, I have raised this at ENB. Mathglot (talk) 00:43, 1 August 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)

  The draft as it was first submitted was:
  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^[1]. His courtly features were prominent, as evidenced by his interests in the fable world of medieval heritage, evidenced by the numerous chivalric novels that enriched his famous library, in astrology and esotericism^[2]. 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 (Bible of Borso d'Este)^[2].

  That is substantially identical to the unedited machine translation. JoelleJay (talk) 04:02, 28 July 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)

Since this is still running, people might like to comment at Talk:Spanish Decadence. Johnbod (talk) 17:41, 1 August 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)

We do allow genuinely bad closures to be reversed through close reviews. If the close is so egregious, the close review will likely be a snow overturn. voorts (talk/contributions) 23:31, 26 July 2024 (UTC)

And, while this is not a great outcome, it's also not something we should fear. People learn by making mistakes, at least to the extent that they're willing to learn. Some people are resistant to learning from their mistakes; they are the ones to fear. RoySmith (talk) 23:58, 26 July 2024 (UTC)

I've suggested a flag like this in the past, and I still think it's a good idea. We don't even need to say it gives "the same weight that an admin has"; we could just say that closing especially contentious or WP:CTOP discussions requires (or recommends) the discussioncloser right and bundle it into the sysop flag in addition to making it available at WP:RFPERM. The Wordsmith^{Talk to me} 18:46, 1 August 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)

I think the type of discussion being closed plays a substantial role. For RMs and some RfCs in CTs I don't think NACs are per se a problem, but at AfD, where non-admins literally cannot close in favor of the most common outcome, we really do need to retain the current guidance. AfD NACs can become experienced at closing debates that have a relatively clear keep or ATD outcome, but they are perpetually lacking in the skill of finding consensus for deletion. A non-delete outcome is also necessarily predetermined when a NAC decides to close an AfD, which means in close cases where either a keep or a delete outcome would be within discretion they will always go for keep. And that's on top of the already strong selection bias towards inclusionism among current NACs, which would skew things even further. JoelleJay (talk) 05:11, 26 July 2024 (UTC)

they are perpetually lacking in the skill of finding consensus for deletion I think that's a bit unfair to NACs. After all, we can't close as delete, so how would you know if we can't find consensus for it. In my experience, when I see a discussion where the discussion could reasonably be closed as delete, I add it to my watchlist, skip it, and when it's closed I can see if I agree with the admin closure. voorts (talk/contributions) 13:32, 26 July 2024 (UTC)

NACs can be plenty competent at assessing discussions, but as they are not supposed to close anything where deletion would be remotely reasonable they can't develop the practical skills needed for both reading nuanced consensus and communicating that consensus. JoelleJay (talk) 22:06, 26 July 2024 (UTC)

I don't see why assessing/communicating that consensus is any different than assessing/communicating any other form of consensus. Plus, most AfDs appear to be closed without a written rationale anyways. voorts (talk/contributions) 22:09, 26 July 2024 (UTC)

But the point is that the AfDs closed by NACs should, by definition, not need a close summary because the outcome is uncontroversial. So if NACs have been following the current guidance, they could not have developed experience in closing AfDs where deletion is on the table, and especially not the ones where they would need to provide a close summary explaining why they didn't see consensus to delete. They just literally cannot cultivate that skillset. JoelleJay (talk) 22:44, 26 July 2024 (UTC)

I disagree. In an AFD with one or two good rationals for delete (e.g. "the sources do not meet GNG") but there are (many) more editors who say that that there are sufficient sources or who come after the first delete comments, I think a close summary is helpful. - Enos733 (talk) 22:50, 26 July 2024 (UTC)

I agree and I wish close summaries (and relisting comments) were a lot more common, but I think it's still true that they're not expected for uncontroversial outcomes. JoelleJay (talk) 23:00, 26 July 2024 (UTC)

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)

• If a non admin's close of a discussion produces another, longer, more contentious discussion, then their close was not a net positive contribution, and they should not do such closes. Sometimes admin closes are bad and result in additional contentious discussions. Admins aren't magically better at analytical thinking.
• We should advise non admins to not close contentious discussions unless they are very confident that they will explain their close to the satisfaction of all the participants. I agree. The guidance should be "to each according to his ability". But, per my first bullet above, the same should be said for admins. If an admin doesn't feel confident that they have the chops to close a particular discussion, they shouldn't feel like their status gives them license to bite off more than they can chew.
• Don't make a habit of it. If a challenge to their close surprises them in any way, then strongly consider reverting the close and listing it at Wikipedia:Closure requests. Unless a close is clearly vandalism or extremely incoherent, we shouldn't be reverting closes absent a close review. Otherwise, we invite random editors to revert closes because they think it's inadequate, leading to even more bickering and bad feelings.

voorts (talk/contributions) 23:30, 26 July 2024 (UTC)

I agree that Admins aren't magically better at analytical thinking, but it is a trait that we select for at RFA, so a random admin will usually do better in this area than a random non-admin. WhatamIdoing (talk) 02:58, 28 July 2024 (UTC)

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 think this is the better path. I'd oppose striking #2 entirely, but I think we can make some more room in it for places where NACs are fine by modifying that first clause which seems to be the more objectionable one. I think a small improvement would be The discussion is contentious, (especially if it falls within a Contentious Topic), and your close is likely to be controversial. While it is true that nobody can know for sure if the close will be controversial (occasionally there's an editor who just can't let go), we're only assessing the likelihood which is usually common sense. A high-profile RFC over a controversial WP:ARBPIA issue or certain parts of the MOS, for example, have a high likelihood of being controversial while a merge discussion about insects where basically everyone is on the same page is not. If a closer is unable to see the difference, they probably don't have the judgement to assess consensus anyway. The Wordsmith^{Talk to me} 18:37, 1 August 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)

Just throwing this out there: there should be some sort of statement that BADNAC is not itself a grounds to challenge a close, and that challengers should focus on the assessment of consensus, not who assessed it. voorts (talk/contributions) 23:34, 26 July 2024 (UTC)

I agree with this suggestion.

That section currently ends with ...or could result in a request to redo the process at Wikipedia:Deletion review, and a footnote saying Discuss with the closing editor first before starting a deletion review. We could change it to say:

...or could result in a request to redo the process at Wikipedia:Deletion review. Discuss with the closing editor first before starting a deletion review. If you need to pursue deletion review, your explanation should focus on content. Reviews that only complain that the discussion was summarized by a non-admin, without identifying at least one substantive error in the result, can be removed without warning by any editor. WhatamIdoing (talk) 03:07, 28 July 2024 (UTC)

I'd oppose at least the last sentence of this. DRV already comes down like a ton of bricks on arguments based solely on the lack of admin privileges, and nominations based solely on that are rare enough that I can't remember the last time it happened. Advising early closes there is already dangerous, since DRVs are themselves overturned so rarely that it's only barely inaccurate to say "it never happens", and so it's important that it's gotten right the first time; simply reverting nominations is even worse, and seems very likely to me to raise the heat in what we try very hard to keep a drama-free zone. —Cryptic 03:32, 28 July 2024 (UTC)

"DRV already comes down like a ton of bricks on arguments based solely on the lack of admin privileges"... so you don't think we should warn folks not to make "arguments based solely on the lack of admin privileges"? WhatamIdoing (talk) 04:08, 31 July 2024 (UTC)

I mostly object to the rest of the sentence, about removing requests. DRV doesn't even speedy close nominations consisting mostly or entirely of accusations of bias or other personal attacks anymore (despite its own instructions), let alone just blank them. I've got no problem with your suggested text up to and including the WP:FOC link; maybe add something to the effect of ", not just complain that the discussion was summarized by a non-admin." to the end. —Cryptic 04:21, 31 July 2024 (UTC)

I wasn't just speaking to deletion discussions, but also using BADNAC solely as a means to challenge an RfC closure, for example, so I think we need some broader proposed language. Also, the last sentence of BADNAC is odd because it purports to apply only to "inappropriate early closures of deletion debates" (emphasis added), which doesn't really have much to do with the rest of BADNAC. voorts (talk/contributions) 06:16, 28 July 2024 (UTC)

I agree that the scope of any warning needs to be broader than just early closures of XFDs. WhatamIdoing (talk) 04:09, 31 July 2024 (UTC)

I agree. Although I'd nominally like #2 to be struck, I think that would have to be done with a strengthening of #3 or something like Scribolt describes. ~~ AirshipJungleman29 (talk) 23:37, 31 July 2024 (UTC)

I think the issue, if there is one, is with bad closes, not specifically with bad non-admin closes. Yes, there is a pretty strong correlation between being an admin and being a good closer, because for both it is usually best to be an "experienced editor" (I'm deliberately avoiding defining that), but correlation is not causation. Phil Bridger (talk) 09:02, 11 August 2024 (UTC)

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)

No, the phrases mean the same thing with no differentiation in terms of permanence. The only difference is the emphasis on the humanity of the person. Given that, "slave" becomes socially unacceptable because who (the thinking goes) after becoming aware of that distinction would use the word "slave" except someone who is intentionally being accommodating of dehumanization.

"Use the same words as sources" doesn't seem tenable, given that we don't want to refer to people as Negroes or Coloreds or the n-word or other terms that were used at various times. Nor do even modern-era printed sources change as the social acceptability of sensitive words changes over the course of a couple decades. It would be weird if we now referred to openly gay people as "admitted homosexuals", even though that wasn't unusual to hear on the TV news in 1980s America. -- Beland (talk) 06:29, 31 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)

Etymological fallacy probably needs some improvements, if anyone's interested in the subject. WhatamIdoing (talk) 04:11, 31 July 2024 (UTC)

(Oh, that's a good one. Might just take you up on that.) Remsense诉 05:05, 31 July 2024 (UTC)

"Enslaved" does not refer to first-generation slaves only. Everyone who is in a state of slavery is also in a state of enslavement or enslaved, even if they have always been that way. Arguably, everyone is born free, and enslavement is a continuing, ongoing process, preventing people from actualizing the universal desire for freedom, though the threat of violence.

But regardless of our feelings about how "active" ongoing enslavement is, the en- prefix is also used to describe states that are "passive", never-changing, and never-not-been. Something is encapsulated or entangled even if it has always been that way. We can also say something was encapsulated or entangled at a particular point in time, or that someone was enslaved at a particular point in time, in which case we'd need to use context to clarify if we mean an initial change of state or the continuation of an ongoing state. But "was an enslaved person" unambiguously means "was in a state of slavery at that time", in contrast to the ambiguous "person X was enslaved". -- Beland (talk) 06:47, 31 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)

People advocate for "enslaved person" because it is both humanizing and highlights the ugliness of the past more by emphasizing that a very horrible thing is being done to a real person, who is more than a dehumanized social role like "slave". -- Beland (talk) 06:14, 31 July 2024 (UTC)

If I may: to me, both perspectives expressed here clearly have significant merit to them, which is why we're here having this discussion. No one needs me to tell them that a harrowing thing about slavery is we have to engage in the lifelong process of understanding these people both as human and more, as their stories are remarkable and frankly the closest I can get to "sacred"—while simultaneously having to actually make an active effort to truly understand them as property, if we are to understand how these conditions could exist and perpetuate, and thus do their experiences justice.

This is all to say that—it seems appropriate for both terms to be used depending on context, possibly with specific attention to the tone and purpose of the immediately surrounding prose. As noted above, I do not think "enslaved person" is a euphemism in the slightest; it is perfectly informative and neutral, and I do not even see it as a "gentler" word tonally. It is obviously reasonable to use the vast majority of the time, as it seems implausible that reader would not understand the term upon reading: it is fairly familiar if not predominant. However, I would not advocate its recommendation over "slave" as a content guideline. At the same time, I don't see any reason why an article should solely use one or the other, so there are not strong WP:RETAIN reasons not to use it unless one goes out of their way to replace existing prose. I think that would require discussion on a case by case basis. Remsense诉 06:35, 31 July 2024 (UTC)

Assuming one accepts the argument that "enslaved person" is supposed to be more humanizing, in what context would "slave" ever be better, and due to what factors? (We can use "enslaved by X" instead of "slave of X", and so on, so I don't see grammatical context mattering, and I'm assuming direct quotes would retain original language, even if offensive - if not because it's offensive.) Likewise, if one accepts the argument that "enslaved person" is either too euphemistic or sounds too PC, what context factors would change the calculus to favor "enslaved person" over "slave"? -- Beland (talk) 07:51, 31 July 2024 (UTC)

This is sort of what I'm getting at: I really think it may be best if these terms are treated as equivalent or eligible to be used in free variation most of the time: it's hard to put forward a compelling hypothetical when one isn't right in front of me. It's important to think hard about these things, but sometimes if I try to think too hard for a reason, I'll end up making up a mediocre one instead of acknowledging the fact that words are forever slippery and depending on the situation certain vocabulary choices simply can't be demonstrated to make a real difference to the quality of the text. Remsense诉 07:53, 31 July 2024 (UTC)

Ah, OK, "free variation" (implying the truce of "retain existing") does make more sense to me than "depends on context" if one declares neutrality in the argument over whether one of the terms always has a bad ring to it. (Though I am not actually neutral on that question.) -- Beland (talk) 08:08, 31 July 2024 (UTC)

To me it really does matter on the conversation being had, though it makes all the sense in the world people have notably divergent perspectives on what's most appropriate when Remsense诉 08:24, 31 July 2024 (UTC)

I hope this doesn't sound cynical or straight up blockheaded, but returning to a point I made earlier: since the two terms can be agreed to be lexically equivalent for our purposes (i.e. no one will be confused if one term is used in place of another, even if they may have distinct connotations the core meaning is clear)—perhaps it's more workable for some if we embrace doing the exact opposite of our usual "figure out one term and stick with it" that would normally be the only sane means—here, I think it's possible we just use both terms a lot in most articles. Maybe I'm sounding blockheaded because the presence of the unwanted term would displease more than also being "assured" (you know what I mean) of a "counterweight". The audience while reading is both made to reckon with the humanity of enslaved people, and feel the appropriate sting from reckoning with terms useful in a system that didn't treat them that way. Dunno. Remsense诉 08:31, 31 July 2024 (UTC)

We don't throw in an occasional "Negro" in Wikipedia's voice to generate mild offense in our readers by using an outdated term which can now sound insensitive outside of proper nouns or direct quotes, nor do we refer to it as "the peculiar institution" in free variation. The only reason to keep "slavery" around in free variation is if it's widely perceived as neutral and not offensive. -- Beland (talk) 19:19, 31 July 2024 (UTC)

The idea was predicated on an assumption that this lexical situation is in practice categorically less offensive from others such as the examples you gave. In this case, I think a firm dichotomy of neutral versus non-neutral may harm our analysis: one would have to admit these are certainly both "terms to watch", in the Wikipedia idiom. We deal with different magnitudes of connotation in our language every time we have to choose what words to utter. I would insist that as far as pure text thought experiment goes, the idea is simply not as crass as the examples you give. (Could certainly make an argument that it's absurd socially and would make things worse if tried though.) Remsense诉 19:52, 31 July 2024 (UTC)

Language changes. "Negro" has fallen completely out of use in contemporary English, "Slave" has not. There are people arguing and campaigning that it should, but per WP:NPOV that is not for Wikipedia to have an opinion about. Wikipedia should always be just behind the peak usage shift when it comes to changing language - i.e. we follow just behind the majority, but that point has not happened yet with regards to "slave"/"enslaved person". We do not and should not prohibit either term, but neither do we or should be actively encourage the use of one term over the other and we absolutely should not be making any changes without article-level consensus and consideration of individual context. Thryduulf (talk) 20:51, 31 July 2024 (UTC)

Sure, my point is that we shouldn't use a term because it has fallen out of acceptable contemporary use for the purpose of being intentionally jarring, aside from the question of whether or not that has actually happened. -- Beland (talk) 21:20, 31 July 2024 (UTC)

I'm not sure I quite understand your last comment. If you are saying that a term having fallen out contemporary use is not a reason in itself to use that term then we agree. If you are saying that "slave" shouldn't be used because it has, or should have, fallen out of use then we disagree. Thryduulf (talk) 21:35, 31 July 2024 (UTC)

In that particular comment, I was making the first point you mentioned. -- Beland (talk) 23:51, 31 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)

Templates and WP:MOS

I thought that templates (and modules) used in articles must produce output consistent with WP:MOS. In particular, automatic calculations and unit conversions should use established output formats instead of inventing their own (especially if they are explicitly marked as "unacceptable" in MOS:NUM). Is this always true, or there might be some exceptions? And if such exceptions exist, how they should be established?

My question is general, but the confusion arose from Module talk:Age § abbr=on violates MOS in particular. I was told there (by the WP administrator maintaining the module) that "more than a mention of a guideline is needed to effect a change" and that "it would be good to get opinions from editors currently interested in affected articles rather than rely on a guideline", although without any explanations where these opinions are supposed to be collected and why they should override WP:CONLEVEL. — Mikhail Ryazanov (talk) 00:37, 1 August 2024 (UTC)

How about an example of what it does, versus what the MOS says it should do? Dicklyon (talk) 03:30, 1 August 2024 (UTC)

Some easy-to-see cases are at Brazilian currency#Historical currencies. This is not the right place to discuss the details but examples can be helpful to save time:

• {{time interval|1942-11-01|1967-02-13|abbr=on}} → 24y 3m 12d

The issue is that MOS:UNITSYMBOLS says there should be a non-breaking space before the units. Another issue is that m is used as the abbreviation for month (as above) but also for minute, as in the next example from Expedition 59#Uncrewed spaceflights to the ISS.

• {{time interval|2019-4-4, 14:22|2019-07-29, 10:44|show=dhm|abbr=on}} → 115d 20h 22m

Please discuss at the above link. Johnuniq (talk) 04:05, 1 August 2024 (UTC)

Oh, you're wanting discussion at Module talk:Age § abbr=on violates MOS. Thanks. Dicklyon (talk) 04:34, 1 August 2024 (UTC)

Please don't get distracted. The question is whether templates must obey WP:MOS (and if not, why). — Mikhail Ryazanov (talk) 05:03, 3 August 2024 (UTC)

The manual of style is a guideline, and like all guidelines should be followed unless there is a good reason not to. That is not something that can be discussed at a level higher than either the individual template or a group of closely related templates, because that is the highest level at which it can be determined whether or not there is a good reason for doing something contrary to the guidelines (and that is because the answer is always context dependent).

In the linked discussion there is the additional question of whether the specific guidance in the manual of style is correct on the specific point. Thryduulf (talk) 10:03, 3 August 2024 (UTC)

It seems to me that your opinion on the level of discussion explicitly contradicts the policy WP:CONLEVEL. — Mikhail Ryazanov (talk) 01:12, 5 August 2024 (UTC)

It only seems that way if you don't understand what a guideline is. Guidelines are standards that should usually be followed but must be interpreted with common sense and exceptions will apply. This means that the answer to the question "should templates obey the MOS?" is "Usually." However that isn't the question you actually want to know the answer to, which is "should this specific template follow the manual of style?" and that is something that can only be answered in the context of the individual template and so is best discussed at that template's talk page. 01:32, 5 August 2024 (UTC) Thryduulf (talk) 01:32, 5 August 2024 (UTC)

I am interested in the community consensus, not in your personal interpretation, unsupported by any references (and contradicting the fact that WP:MOS does include many exceptions for specific cases, which would be unnecessary if your ideas about ignoring general guidelines in local contexts were correct). — Mikhail Ryazanov (talk) 03:01, 8 August 2024 (UTC)

It's not "my personal interpretation" it's the definition of a guideline. Thryduulf (talk) 03:04, 8 August 2024 (UTC)

Then please quote that "definition". — Mikhail Ryazanov (talk) 03:30, 8 August 2024 (UTC)

See WP:GUIDES: "Guidelines are sets of best practices supported by consensus. Editors should attempt to follow guidelines, though they are best treated with common sense, and occasional exceptions may apply.

See also the header of each guideline, which says something like "This page documents an English Wikipedia content guideline. Editors should generally follow it, though exceptions may apply." The header varies depending on the type of guideline, but they're all pretty close to that. Firefangledfeathers (talk / contribs) 03:34, 8 August 2024 (UTC)

From the top of Wikipedia:Manual of Style: This guideline is a part of the English Wikipedia's Manual of Style. It is a generally accepted standard that editors should attempt to follow, though occasional exceptions may apply.. Thryduulf (talk) 09:32, 8 August 2024 (UTC)

Now we need an expert on "common sense"... WP:COMMONSENSE says: "When advancing a position or justifying an action, base your argument on existing agreements, community foundation issues, and the interests of the encyclopedia, not your own common sense. Exhorting another editor to 'just use common sense' is likely to be taken as insulting, for good reasons." And Wikipedia:Ignore all rules linked from "normally"/"occasional exceptions" explains what it actually means: "If a rule prevents you from improving or maintaining Wikipedia, ignore it." I don't think that designing a general-purpose module/template such that it systematically violates the rules without any explanations (or even mentioning the discrepancy) can be called "common sense". I also don't think that broadly using nonstandard formatting, especially if the MOS explicitly calls it "unacceptable", can be considered an "improvement" (otherwise, if this "exception" is really an improvement and is so common, it must be included in the MOS). — Mikhail Ryazanov (talk) 03:18, 9 August 2024 (UTC)

The point is that if someone claims an exception applies because it improves the encyclopaedia and another person disagrees because they think it doesn't, then what happens next is discussion. That discussion needs to take place in the place relevant to that exception so it has the benefit of full context and is visible to editors who are involved with the relevant article/template/whatever. The consensus of that discussion will determine whether the exception is justified or not.

In this case you need to participate in the linked discussion and make your case there about why you think the the exception is not justified in this particular case. Refusing to engage and just repeating that you don't think there should be exceptions is just wasting your and others' time. Thryduulf (talk) 08:40, 9 August 2024 (UTC)

Fixing over-capitalization by bot

In general, if an RM discussion has come to a robust consensus for a particular capitalization pattern in a title, is it recommended to fix article text where the un-preferred version appears, to make it more MOS:CAPS compliant? In particular, do you support changing things like 2020 United States Census to 2020 United States census in article text, in light of the consensus at Talk:2020 United States census/Archive 1#Requested move 16 November 2020 (and all the other US census years, too), given that there are on the order of 50,000 of them, such that the work would need to be done by a bot?

Also, what about mass-fixing things tagged as miscapitalizations, often without RM discussions, such as Mechanical Engineering, American Football, Chief of Staff, Artificial Intelligence, Private Company, with about 500 to 1000 articles each? Assuming a bot could be made good enough at avoiding false-positive triggering based on good context parsing, are these likely to be approvable easily for a bot, or would each one need a discussion such as an RFC, like we did on the NFL Draft? Or just a discussion at WP:BRFA? Or in the other direction, to capitalize under-capitalized items, such as Hyderabad queer pride and Youtube? In general, when is it appropriate to ask for a bot, and for that request to be approved? I don't necessarily need a guideline or policy on this question if there's a clear enough opinion, hopefully in favor of moving toward compliance with style guidelines more rapidly than can be done by hand, or even by AWB.

But in particular, for now, it's about the census. (ps. I don't do bots, but I've had some luck enlisting help from several who do.) Dicklyon (talk) 03:58, 1 August 2024 (UTC)

Assuming a bot could be made good enough at avoiding false-positive triggering based on good context parsing this feels like the key element. WP:CONTEXTBOT gives "Correcting spelling, grammar, or punctuation mistakes." as the first example of the sort of bot that is extremely difficult. In the examples you give, all of them are likely to occur at some point as proper nouns and/or quotes where the author has used more capitals than we would (especially "artificial intelligence"). Certainly not bot should be changing the capitalisation of anything where there has been no explicit community consensus that a particular capitalisation is always an error (not just most commonly). Thryduulf (talk) 10:01, 1 August 2024 (UTC)

@Thryduulf: Hey! Jumping in as one of the apparent several who do bots. I operate an approved bot that fixes miscapitalizations of "NFL draft," but only within wikilinks and some hatnotes. Since the RfC about that capitalization resulted in a consensus to change article titles and text, a bot request discussion and a subsequent BRFA were held. (For the exact behind-the-scenes logic, feel free to review the BRFA and my source code.) Out of the 3,000 pages affected by this task since I finally got this task up and running a few days ago, my spot checks haven't found any issues, and not a single change has been reverted (yet), so I'm fairly confident in the technical logic. Now, I'm not sure whether the same community consensus holds up for the "census" case, so that's how we find ourselves here. I'm personally less sure about the more common terms like "Artificial Intelligence" which are more likely to be used in quotes/etc, but I think links to "XXXX United States Census" redirects could be fixed with little to no error in line with the "NFL Draft" links. Perhaps this remains a case-by-case issue rather than a broad policy/guideline, but I'd love to learn a community answer to Dicklyon's question, In general, when is it appropriate to ask for a bot, and for that request to be approved? Bsoyka (t • c • g) 14:07, 1 August 2024 (UTC)

Links specifically do seem like a case when there is a very low possibility of false positives (although again some quotes might be exceptions) for terms that are clearly almost always a proper noun or common noun and where there is a low chance of links to the wrong article (e.g. links to 2020 United States Census are unlikely to be wrongly targetted, links to Artificial intelligence could be intended for e.g. Artificial Intelligence (book), Artificial Intelligence (EP) or Artificial Intelligence (journal).)

As for the general question, I think a request should only be approved if, at minimum, both the following are true:

• There is an explicit community consensus that all* instances of one or more specific terms are incorrect and should always be changed.
• There is an explicit community consensus for a bot to make the changes*. The consensuses need not be in separate discussions, but there must be explicit consensus for both points.

*or a clearly defined subset, e.g. only in links, only in articles in specific category, etc.

Thryduulf (talk) 14:31, 1 August 2024 (UTC)

It might be simpler to test the thing by addressing the many examples of under-capitalization. Johnbod (talk) 17:38, 1 August 2024 (UTC)

For this sort of thing, it would need human supervision, and be restricted to smaller groups of miscapitalizations. So use semi-automation. AWB could handle this and speed changes. Also there is a regex editor that can help where something is wrong many times in one article. Graeme Bartlett (talk) 22:29, 1 August 2024 (UTC)

I agree that for most of the other (non-census) cases, AWB is the way to go. Thanks for the input/feedback about that. So back to the census cases.

I searched up uses of /2020 United States Census/ and related to see what they look like. First observation: the majority of case fixes would be "cosmetic", to links piped through the over-capitalized redirect, in these specific cases:

 population_as_of = [[2020 United States Census|2020]]
 in the [[2020 United States Census|2020 United States census]]
 |[[2020 United States Census|2020 census]]
 with a [[2020 United States Census|2020 census]] population
 the [[2020 United States Census|2020 census]]
 ([[2020 United States Census|2020 census]])
 ([[2020 United States Census|2020]])

Then there are the ones that are not just cosmetic:

 The [[2020 United States Census]]
 stat_ref =  [[2020 United States Census|2020 U.S. Census]]
 the [[2020 United States Census|2020 Census]]
 The [[2020 United States Census|2020 Census]]
 the 2020 United States Census
 the [[2020 United States Census]]

Including these with the correct lowercase link, piped to capitalize:

 [[2020 United States census|As of 2020 United States Census]]
 The [[2020 United States census|2020 U.S. Census]]
 the [[2020 United States census|2020 U.S. Census]]
 the [[2020 United States census|2020 United States Census]],
 the [[2020 United States census|2020 Census]]
 ([[2020 United States census|2020 Census]])
 ([[2020 United States census|2020 Census]] <ref> ...

I know fixing "cosmetic" errors is frowned upon, but fixing those is the only way to reduce the list of "what links here", to the point where the remaining odd cases can be found and fixed "by hand". If we decide that kind of fixing is not OK, then we should still do the non-cosmetic ones; that's how Bsoyka handled the NFL Draft downcasing bot, to avoid raising that objection; no file is edited if the edit would be only cosmetic.

I found only one "no go" hit on /2020 United States Census/, but I'm sure there will be some more like this, in ref titles, file names, or whatever: "title=2020 United States Census Profile ...". I think Bsoyka's parser identifies and avoids such contexts. Dicklyon (talk) 04:04, 2 August 2024 (UTC)

To clarify how my current bot task handles the logic on NFL draft edits:

• Yes, as Dicklyon described, the bot only edits if at least one non-cosmetic change is made (affecting something visible to the reader). If so, other cosmetic changes are bundled into the same edit. If there are only cosmetic changes to be made in the article, the bot doesn't edit. If the same task is run for the census articles, this is how I recommend handling it.
• As it runs now, the bot shouldn't touch |title=2020 United States Census Profile, since it doesn't include a wikilink. Now, if it was |title=[[2020 United States Census]] Profile, the bot would currently try to edit that. However, that's a weird edge case that I find incredibly unlikely to actually happen. Also, as long as the citation also has a URL, we'd get a URL–wikilink conflict error, which pops up in a well-maintained category.
• Reiterating for clarity, my bot's NFL draft task currently only edits in two places: wikilinks and hatnotes (specifically only {{Main}}, {{See also}}, and {{Further}}). I believe this significantly limits false positives and the CONTEXTBOT issue, because it's not blindly replacing plain text throughout the article. This has already been tested pretty extensively now—so far no false positives have been reported to me, and none of that task's edits have been reverted.

Happy to answer any other questions about how this could function for U.S. censuses and other similar cases. However, I'm not sure a policy discussion is the right venue for the specific census replacement proposal. Let's first figure out a general rule for when a bot should be used to correct miscapitalizations, and then we can discuss the census case at the appropriate venue as needed depending on this discussion's outcome.

As for my opinions, I support Thryduulf's proposal above; I believe there should be an explicit consensus for bots making mass replacements in article text, and I don't believe this is included by default in a requested move discussion. Additionally, I disagree that human supervision should be required for these mass replacements—as I've indicated above, my bot has shown in practice that these edits work fine without supervision when the logic is done right. Bsoyka (t • c • g) 04:39, 2 August 2024 (UTC)

I just searched up the not-linked /the 2020 United States Census/. There are 67, all which (as verified by eye on the search hits) should be downcased. But one has "the 2020 United States Census Data", so Data would also need to be downcased. These can be done easily enough by AWB. So yes, I agree sticking to links is good. I have seen any Main or Also templates or such, but I haven't looked.

As for skipping the cosmetic-only ones, that's going to leave quite a mess; that is, the "what links here" will not be a useful guide to finishing thke fixing. That's why I brought up the possibility of "bending" that guideline. The edits are called "cosmetic", but they do have a visible effect on maintenance reports, which is the point. I think that's maybe a smaller issue on the NFL Draft ones; do you have an estimate of how many are skipped as being only cosmetic? Dicklyon (talk) 05:47, 2 August 2024 (UTC)

I do not support "bending" the usual requirements about cosmetic edits. Maintenance reports, especially relatively trivial ones like capitalisation, are not a good reason to disrupt other editors. Thryduulf (talk) 07:30, 2 August 2024 (UTC)

I believe these non-visual edits to piped links wouldn't be considered "cosmetic" according to our policies because WP:COSMETICBOT specifically allows changes that affect the "administration of the encyclopedia", such as the maintenance of hidden categories used to track maintenance backlogs. I have no opinion on whether these trivial edits should actually be made for miscapitalizations, as I understand the reasoning for both sides of that argument. Bsoyka (t • c • g) 13:22, 2 August 2024 (UTC)

I'd want to see some consensus that the piped replacements should be done rather than relying solely on that bullet to avoid complaints about WP:COSMETICBOT. Anomie⚔ 13:53, 2 August 2024 (UTC)

I'd want to see that, too. That's why I'm asking. Dicklyon (talk) 17:04, 2 August 2024 (UTC)

WP:VPR would probably be better for the question, since it's not really a policy question anymore. Anomie⚔ 19:34, 2 August 2024 (UTC)

Maybe it's too hard to converge on a general policy here, and we should instead take the census case specifically to WP:RFBA? Dicklyon (talk) 18:42, 2 August 2024 (UTC)

I can work on some preliminary code and get a request going soon. Bsoyka (t • c • g) 19:02, 2 August 2024 (UTC)

See also this very similar bot request that just popped up, also changing one incorrect character across a large number of pages per a page move consensus: Wikipedia:Bot requests#Consensus: Aldo, Giovanni e Giacomo Bsoyka (t • c • g) 20:03, 2 August 2024 (UTC)

Files in content categories

When evaluating the botworthiness of the task of adding the NOGALLERY tag to categories that contain non-free files, I realized that we don't have clear guidelines on when locally hosted files (non-free or otherwise) should be placed in content categories.

Wikipedia:Manual_of_Style/Images#Uploading_images and WP:FILECAT vaguely imply that files should be placed in categories, but the rules are so unclear that in practice there is a lot of inconsistency when it comes to content categories primarily intended for articles (e.g. Category:PAW Patrol), as opposed to ones that are dedicated to files (e.g. Category:Halo (franchise) media files). –LaundryPizza03 (dc̄) 06:31, 3 August 2024 (UTC)

Is there a problem with media and articles being in the same category?

If we have a lot of local media about a given topic then it makes sense to have a dedicated category for that, but if we only have a one or two (as I guess will be the case for most topics illustrated by non-free files) then it doesn't seem useful to have a separate category, but also potentially useful for e.g. File:2 Tone Records.png to be in Category:2 Tone Records. Thryduulf (talk) 09:56, 3 August 2024 (UTC)

The question, then, is when exactly we want to do that. –LaundryPizza03 (dc̄) 23:37, 3 August 2024 (UTC)

Why do we need exact rules? If a media file is relevant to a content category then it can go in that category, unless there is a more specific sub-category in which it fits. Create subcategories if and when there are enough pages to justify one. If there is a disagreement, discuss it. This seems to work for all other pages in categories so I don't understand why it won't work here? Thryduulf (talk) 00:04, 4 August 2024 (UTC)

It is necessary to answer the question to figure out the botworthiness of the task of adding NOGALLERY tags. –LaundryPizza03 (dc̄) 00:38, 4 August 2024 (UTC)

This feels backwards, but I can't quite put my finger on why. Thryduulf (talk) 00:42, 4 August 2024 (UTC)

The TL;DR of the bot request seems to be this: WP:NFCC doesn't allow non-free images to show in Category-namespace galleries. If a non-free image is added to a category that doesn't already have __NOGALLERY__, and editor might either revert the addition of the image to the category or add __NOGALLERY__ to the category description to suppress the gallery (I see you, Thryduulf, suggested a third alternative there that would require a new magic word be added to MediaWiki). As things currently stand, that decision would fall under WP:CONTEXTBOT as which to choose depends on human judgement as to whether the category should contain non-free images or not. LaundryPizza03 is hoping for exact-enough rules that would make it not be WP:CONTEXTBOT, since he want a bot to handle this rather than having humans work off of a database report. Anomie⚔ 13:46, 4 August 2024 (UTC)

British vs UK

Why is often "UK" used instead of just "British" word? For example, there is "UK singles chart" instead of "British singles chart" so it's like there would be "RO record charts" instead of "Romanian record charts". Eurohunter (talk) 20:44, 4 August 2024 (UTC)

"British" may refer to the island of Great Britain, or to the British Isles (which, I might add, is a controversial name in some circles), but "U.K." is short for the United Kingdom of Great Britain and Northern Ireland, which doesn't really match either meaning of "British". Donald Albury 21:38, 4 August 2024 (UTC)

Agreed. Its similar to "US" vs "American" in terms of when one or the other is appropriate. Theknightwho (talk) 22:37, 4 August 2024 (UTC)

I would suggest the difference is the same as that between Romania record charts and Romanian record charts, British being a demonym for the UK (or what Donald said, to give it its proper name). Sometimes one is more appropriate. -- zzuuzz ^(talk) 21:43, 4 August 2024 (UTC)

Many/most Irish people with enetitlements to British citizenship who live in areas governed by the UK would generally not call themselves British. Most people living in the six counties, would not consider that they live in Britain, but rather live in the UK (the legal entity) or Ireland (the geogrpahic entity). See Terminology of the British Isles for more detail. Regards, Goldsztajn (talk) 22:39, 4 August 2024 (UTC)

Of course, it's also true to say that many Northern Irish people would say that they are British. DuncanHill (talk) 22:54, 4 August 2024 (UTC)

We have a handy encyclopedia somewhere around here with an article that covers this question: Terminology of the British Isles. Not quite the specificity of American (word), but it's close. —Cryptic 23:07, 4 August 2024 (UTC)

Views on de-orphaning?

What does the community think about systematic efforts to add links to orphaned articles?

Until recently, my impression was de-orphaning can sometimes be beneficial (I did a bit when I was starting to edit) but, in most cases, isn't hugely significant because decent search engines are widespread. Additionally, many orphans cover naturally obscure topics which just aren't going to get many readers or improvements even if they were linked elsewhere.

However, I've been coming across cases where de-orphaning has actually made things worse, generally by giving too much weight to a subject we might not even want to have an article on in the first place. For example, I recently cleaned out a large number of dubiously-notable companies whose establishments were listed as nationally prominent events on pages like 2000 in the United States because of systematic de-orphaning.

It's become increasingly unclear to me whether de-orphaning efforts, as currently practised, are doing more good than harm. But this is based on my impressions, not detailed analysis. So I'm interested to hear others' thoughts.

(A couple of previous discussions: 2017, 2019, there's probably been others). – Teratix ₵ 06:15, 5 August 2024 (UTC)

It probably depends on exactly what is meant by deorphaning. Adding links to relevant articles is good, in that it provides readers a path to find new information. Search cannot help someone find something they don't know they are looking for. The 2017 and 2019 discussions however make a good point that deorphaning as an end in itself is obsolete.

Stepping back slightly, is there more information on what the de-orphaning efforts as currently practised are? The adding of links where they are not beneficial is not great, but how much of it is a problem, and is it a systemic issue or a relatively occasional occurrence? CMD (talk) 06:54, 5 August 2024 (UTC)

The issue with de-orphaning is that it tends to be rather black-and-white. WikiProject Orphanage has the singular objective of reducing the backlog of orphaned articles, which can result in articles that may not meet GNG being given undue weight. Something like the introduction of an 'Orphan-Notability' template, alongside the 'Orphan' template, might help. When de-orphaning a particular article, the option of replacing the 'Orphan' template with 'Orphan-Notability' would create two lists: one for orphaned articles and another for orphaned articles requiring a notability check before they are de-orphaned. Svampesky (talk) 09:15, 5 August 2024 (UTC)

I've seen good things happen from good links. If an article has no inbound article links it gets very few page views, and thus very few edits. With meaningful links from other articles it is now being seen by readers interested in related topics, and someone reading an article on one topic is probably just the person to make good edits to a related article they click through to. It's true that low-quality links, like linking to a dubiously notable company in a large city article because the company is based there, tend to lower the quality of the established article. Cluttering it up without adding useful information for readers.

I think if meaningful, good article links can't be created to an article, that's a strong sign that the article subject is not notable. It's not a criteria for deletion of course, just an indication that a topic might not be encyclopedic, if no other encyclopedia articles should even mention it. Here2rewrite (talk) 11:29, 5 August 2024 (UTC)

+1 for I think if meaningful, good article links can't be created to an article, that's a strong sign that the article subject is not notable.. CapitalSasha ~ talk 11:33, 5 August 2024 (UTC)

As an "Orphanologist" working on oldest orphan articles (beginning with 2014 backlog articles), I have seen much progress. At one point the backlog was over 120,000 articles and now about 55,000. And millions more of non-orphan articles. Prior to my involvement, the consensus is to make orphan tag "invisible" after two months. My suggestion would be to show all orphan tags. Regards, JoeNMLC (talk) 13:11, 5 August 2024 (UTC)

It always seems odd to me if an article can't reasonably be linked to other articles. This could of course mean that those other articles are missing rather than that our orphan is not notable. As for whether we use visible or invisible tags, it rather depends on whether we think the task is something we want to invite our readers to do. In its early days, yes I assume most new orphans can easily be linked into the project. After some time it ceases to be a newbie task and it requires a bit more experience of the project - does this link improve the pedia or is it visual clutter? I'm not sure whether two months is the right time and if not whether it should be increased to three or more or reduced to one. But if we were going to change the interval I'd like it done with some data as to the relative ease of deorphaning articles after one, two or three months. Ideally the link should become invisible at the point where deorphaning becomes a task we don't want to promote to newbies. ϢereSpielChequers 13:33, 5 August 2024 (UTC)

I don't find this odd at all, and being an orphan isn't the end of the world. Of course some articles are crying out to be linked to (creators of new articles are often very poor at looking for links to add). I'm strongly against WP:UNDUE adding the name and a link just for the sake of de-orphaning. Johnbod (talk) 15:08, 5 August 2024 (UTC)

• When this was discussed in 2017, I left rather lengthy comment. Although I no longer de-orphan to the same extent that I once did, I still think the tag is valuable as a diagnostic that signals that an article should be looked at. As I said back then, I have found plenty of instances where investigating why something is tagged as orphaned has helped me improve Wikipedia - merging duplicate articles, upmerging stubs to parent articles, creating new articles in a taxonomic chain, fixing broken links, and initiating the deletion of junk that no one has laid eyes on in years.
  Issues can arise when people focus more on the idea of removing the tag at all costs rather than figuring out what to do with the article, but that can happen with any maintenance backlog. Think of someone who mass-redirects unsourced articles rather than improving sourcing. Is the problem the tag, or the behavior? Let's not throw the baby out with the bathwater if we can solve the crap-links problem by dealing with whoever is doing it. ♠PMC♠ (talk) 08:00, 6 August 2024 (UTC)

  I agree. Even if someone deorphans by mechanically adding a See also link to a more prominent article, the watchers of that more prominent article will then be alerted to the lesser article and it then has an opportunity to be improved. ~Kvng (talk) 14:20, 8 August 2024 (UTC)

  As is often the case when editing WP, de-orphaning requires a degree of editorial judgement. The problems almost always occur when people edit without discernment - adding links just for the sake of linking. The reality is that some de-orphaning links are very beneficial, while others are not. Blueboar (talk) 14:44, 8 August 2024 (UTC)

The relevant policy/guideline is actually already there:

It may be the case that some articles currently just cannot be de-orphaned. If this is the case then please do not try to 'force-fit' by adding unrelated links to articles where they don't belong just for the sake of de-orphaning. Always keep in mind that our primary goal is to improve the reader's experience, not satisfy the editor's indulgence in statistical achievements. Your priority when adding links should be to maintain article quality by adding relevant and useful links wherever possible
— WP:CANTDEORPHAN

So, unnecessary links can always be removed. But it's not always bad, and the inclusion or non-inclusion criteria of certain articles in general articles such as "X year" may not be straightforward; what "degree" of notability (if a person has an article on Wikipedia that person is already notable) a person has to have to be included in "Births"?

Companies can be included in some lists by location or something else. What to put in "See also" is also covered by a guideline.

But do some articles even need to exist? I somewhat agree with other users regarding the (probable) lack of notability (though it may require changes in some notability policies). The other important thing here is the size of the article. Members of the state legislatures are presumed notable, but what if the fact that a person was a member is almost the only thing we know about them? Example. Named natural features are often notable, provided information beyond statistics and coordinates is known to exist. But for some very small streams, this "information beyond" is the etymology and what bodies of water they flow into (sometimes another small stream). Example, Example. The same doubts arise regarding small unidentified villages (that may not even exist), very small neighbourhoods or just "areas".

There are also a lot of articles about New Zealand court decisions, but that's a separate story.

Finally, there are some interesting guidelines about orphans: Editors may also remove the tag from any article if they believe that de-orphaning is unlikely to be successful, or if they have attempted to provide incoming links -//- However, if you are certain the article is unlikely to ever be de-orphaned then simply remove the tag. Can this also be the answer sometimes? It can also be elaborated. For example, after some time and/or a number of attempts an article may be declared "hopeless" and the tag may be removed.

The reality is that some de-orphaning links are very beneficial, while others are not. A lot of those that "are not" are not harmful either. Oloddin (talk) 05:53, 10 August 2024 (UTC)

I've opened a new section on your first question below, as it extends beyond the question of deorphaning. Nikkimaria (talk) 02:58, 11 August 2024 (UTC)

Ukrainians in the United Kingdom vs Ukrainian diaspora in the United Kingdom

What is the difference between "Ukrainians in the United Kingdom" and "Ukrainian diaspora in the United Kingdom"? Eurohunter (talk) 17:40, 5 August 2024 (UTC)

Nothing now, as the latter redirects to the former. Bduke (talk) 00:03, 6 August 2024 (UTC)

Palaeogenetics and ethnicity in articles

I had this big plan where I'd intentfully draft my case before even making a post here and it would have robust sourcing and all that, but I realized I should just go for it and if there's any agreement other editors will chime in.

The key summary is: the scholarly field of palaeogenetics (or archaeogenetics) has exploded in the past decade-plus. The data we can collect from the DNA of millennia-old human remains is a shocking new advancement. However, scholarly sources often use ethnic labels for the historical genetic populations they are studying. This creates friction with the universal understanding among serious people since the end of World War II that ethnicity is a social and cultural category, not a genetic one; one's ethnicity is the result of human choices and not amino acid pairs. As such, the distinct field of ethnography generally shies from ascribing ethnic identity to almost any individual that isn't the author or focus of direct literary analysis. To wit, speaking of "Lombard DNA" (etc.) is completely inane if we're to take it as face value; it is best defended as a shorthand for lack of better language to use in these papers.

That said: if one has pages for historical people groups or demographics on their watchlist, they will notice a lot of tertiary analysis of these studies being added to articles, which often transparently conflate the actual subject of the article with genetic populations analysed in a distinct manner, sometimes because that's what those sources themselves do. I think we should consider some guideline regarding the correct representation of what this information is actually saying and how it relates to the universal notion of ethnicity otherwise described in articles about them. Remsense诉 07:10, 7 August 2024 (UTC)

There should be agreement in principle, the discussions on the topics I've seen (and been involved in) tend to land on ensuring that such genetic studies are not over-emphasised in relevant articles. The biggest risk is that detailed coverage of X or Y genetic study, which will use shorthands out of necessity (often explaining so in the paper), gets added to an otherwise underdeveloped article and thus turns the paper output from perhaps an academically interesting note about a certain group of people that comes with a lot of interpretative caveats, to coming off in the article as a defining trait of said group of people. I haven't seen an academic paper suggest that the genetic studies overturn ideas of ethnicity, however unfortunately the papers do get entangled with the many complex issues surrounding defining ethnicity on individual and group levels. I would support a broad guideline noting the principles of understanding the limitations and limited meaning of such studies. CMD (talk) 08:25, 7 August 2024 (UTC)

Rewriting WP:BITE

A RfC is open on rewriting the guideline WP:Please do not bite the newcomers. Ca ^{talk to me!} 13:47, 8 August 2024 (UTC)

Wikipedia:Notability (species)

An RfC to adopt a guideline regarding the notability of species has been opened at Wikipedia talk:Notability (species)#Proposal to adopt this guideline. C F A 💬 23:59, 9 August 2024 (UTC)

Inclusion in year articles

In a section above, Oloddin asked "the inclusion or non-inclusion criteria of certain articles in general articles such as "X year" may not be straightforward; what "degree" of notability (if a person has an article on Wikipedia that person is already notable) a person has to have to be included in "Births"?" I think this is a very good question, and on a quick look I couldn't find any guidelines that answered it (please let me know if I've missed it). Should the article 2000 in the United States include everyone in Category:2000 births born in the US? If no, who should it include/exclude? Nikkimaria (talk) 02:58, 11 August 2024 (UTC)

So long as a person is notable in Wikipedia terms, I would say they should be included. General year lists include everyone born in those years. I don't see why year in X nation lists should be any different. voorts (talk/contributions) 03:15, 11 August 2024 (UTC)

voorts, I don't think general year lists do - for example Category:1994 births has 16k entries but 1994 has nowhere near that. (And if it did the page probably wouldn't load). Nikkimaria (talk) 03:40, 11 August 2024 (UTC)

This appears to be the most recent consensus on the topics of births & deaths at year articles. voorts (talk/contributions) 03:57, 11 August 2024 (UTC)

There also seems to be some consensus at WP:YEARS for the proposition that someone should be internationally notable to be included in the international (i.e., plain old year) article, as opposed to year by nation articles. voorts (talk/contributions) 04:01, 11 August 2024 (UTC)

Shortly after that discussion, I took this "consensus" to the Village Pump and then ANI, where it was found to be a false consensus and one of the editors enforcing it was topic banned. Thebiguglyalien (talk) 06:57, 11 August 2024 (UTC)

Thank you for that context. voorts (talk/contributions) 07:31, 11 August 2024 (UTC)

I agree that we ought to have some inclusion criteria. International and national notability for year and year by nation articles respectively seems to be one workable guideline, although I'm not wedded to it. voorts (talk/contributions) 04:04, 11 August 2024 (UTC)

This is something of a hornets nest. WikiProject Years has been taken to task a few times for ownership issues, and groups of users have on occasion come up with their own systems that contradict P&G. User:InvadingInvader/Against international notability describes some of the events that led to removal of births and deaths lists in year articles per Wikipedia:Village pump (proposals)/Archive 199#RFC: split births & deaths from year articles. I've also reminded editors that per WP:PROPORTION, things shouldn't be included in the article if they're not given significant coverage in sources about that year—which births virtually never are. Thebiguglyalien (talk) 06:54, 11 August 2024 (UTC)

Per the RfC linked above long lists of births should be removed. Most birth inclusions also seem questionable weight-wise in general; most notable individuals were not notable at their births, and their births would not have had a significant impact on X year. CMD (talk) 07:28, 11 August 2024 (UTC)

Technical

Unicode direction weirdness

With Baghdad Conservatory in my Firefox edit the start of the line is left of the edit box. Previously this resulted in someone adding an extra "T" to yield "TThe". But now the "The" looks like "he" in the edit box. Somewhere in the Arabic text there is a left to right unicode direction indicator as I can tell by trying to add spaces to it. How can we find and remove such characters? And is that character messing up the edit box? Graeme Bartlett (talk) 22:33, 3 August 2024 (UTC)

It looks fine in my Firefox (128.0.3), with Monobook, Vector, or Vector2022, in the "2010 editor", with and without &safemode=true added to the URL. I don't see any LRM or similar characters in that article. Anomie⚔ 13:02, 4 August 2024 (UTC)

After seeing the discussion linked below, which mentions that it happens when the line starting with LTR text wraps within some RTL text, I was able to reproduce. I can reproduce in a plain textarea locally, so it doesn't seem to have anything to do with Wikipedia specifically. Anomie⚔ 17:11, 4 August 2024 (UTC)

This is one of the reasons that the cs1|2 templates support |script-title=. Try this:

{{cite news |script-title=ar:الراحل حنّا بطرس جزء من تاريخ الموسيقى في العهد الملكي |url=http://www.daraddustour.com/%D8%A7%D9%84%D8%AA%D9%81%D8%A7%D8%B5%D9%8A%D9%84/tabid/94/smid/604/ArticleID/31615/reftab/123/Default.aspx |accessdate=31 July 2011 |newspaper=Addustour |date=28 September 2010 |url-status=dead |archiveurl=https://web.archive.org/web/20120328094702/http://www.daraddustour.com/%D8%A7%D9%84%D8%AA%D9%81%D8%A7%D8%B5%D9%8A%D9%84/tabid/94/smid/604/ArticleID/31615/reftab/123/Default.aspx |archivedate=28 March 2012}}

الراحل حنّا بطرس جزء من تاريخ الموسيقى في العهد الملكي. Addustour. 28 September 2010. Archived from the original on 28 March 2012. Retrieved 31 July 2011.

|script-title= causes cs1|2 to wrap the title in <bdi>...</bdi> (bidirectional isolate) tags:

'"`UNIQ--templatestyles-00000047-QINU`"'<cite class="citation news cs1 cs1-prop-script">[https://web.archive.org/web/20120328094702/http://www.daraddustour.com/%D8%A7%D9%84%D8%AA%D9%81%D8%A7%D8%B5%D9%8A%D9%84/tabid/94/smid/604/ArticleID/31615/reftab/123/Default.aspx <bdi lang="ar" >الراحل حنّا بطرس جزء من تاريخ الموسيقى في العهد الملكي</bdi>]. ''Addustour''. 28 September 2010. Archived from [http://www.daraddustour.com/%D8%A7%D9%84%D8%AA%D9%81%D8%A7%D8%B5%D9%8A%D9%84/tabid/94/smid/604/ArticleID/31615/reftab/123/Default.aspx the original] on 28 March 2012<span class="reference-accessdate">. Retrieved <span class="nowrap">31 July</span> 2011</span>.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Addustour&rft.atitle=%D8%A7%D9%84%D8%B1%D8%A7%D8%AD%D9%84+%D8%AD%D9%86%D9%91%D8%A7+%D8%A8%D8%B7%D8%B1%D8%B3+%D8%AC%D8%B2%D8%A1+%D9%85%D9%86+%D8%AA%D8%A7%D8%B1%D9%8A%D8%AE+%D8%A7%D9%84%D9%85%D9%88%D8%B3%D9%8A%D9%82%D9%89+%D9%81%D9%8A+%D8%A7%D9%84%D8%B9%D9%87%D8%AF+%D8%A7%D9%84%D9%85%D9%84%D9%83%D9%8A&rft.date=2010-09-28&rft_id=http%3A%2F%2Fwww.daraddustour.com%2F%25D8%25A7%25D9%2584%25D8%25AA%25D9%2581%25D8%25A7%25D8%25B5%25D9%258A%25D9%2584%2Ftabid%2F94%2Fsmid%2F604%2FArticleID%2F31615%2Freftab%2F123%2FDefault.aspx&rfr_id=info%3Asid%2Fen.wikipedia.org%3AWikipedia%3AVillage+pump" class="Z3988"></span>[[Category:CS1 uses Arabic-language script (ar)]]

—Trappist the monk (talk) 13:16, 4 August 2024 (UTC)

Previous discussion (July 2023) at Wikipedia:Village pump (technical)/Archive 206 § RTL scripts sometimes left-shifting lines displayed in editing environment (browser dependent). Folly Mox (talk) 16:31, 4 August 2024 (UTC)

Browsers automatically display text in some scripts as right to left. This can cause different issues and confusion when editing. If you cannot read those scripts anyway then you may prefer to display them left-to-right with code like this in your CSS:

textarea {
  direction: ltr;
  unicode-bidi: bidi-override;
}

It doesn't affect what you save so you're not going to damage the pages but may be less likely to do something wrong. PrimeHunter (talk) 15:39, 5 August 2024 (UTC)

XTools Edit Count down?

Since yesterday, when I bring up my Edit Count from XTools, nothing has updated in two days. Specifically, the Actrion, Patrol figure. On the Basic information, it says "Latest edit 2024-08-03 03:11" which is in error. It also lists "Latest logged action" as 2024-08-03 03:06. Something on the stats end not working? — Maile (talk) 18:48, 4 August 2024 (UTC)

High replag means that all sorts of stuff that should update will not update until the replication lag goes back to zero. – Jonesey95 (talk) 20:42, 4 August 2024 (UTC)

Yes, there has been a high replag on both English Wikipedia and the Commons for two days now. It seems to have something to do with this. It's lasting longer than it was expected to take. Liz ^{Read! Talk!} 00:21, 5 August 2024 (UTC)

Yup. I noticed this one too, today. Ktin (talk) 00:38, 5 August 2024 (UTC)

Thanks for the input. It's been so many years since I've seen this happen, that I forgot the possibility of it. — Maile (talk) 01:39, 5 August 2024 (UTC)

Actually, it seems to happen fairly frequently, I'd guess monthly or every other month. It usually happens on Thursdays or Fridays. It becomes very evident if your editing relies on bot reports. They seem the most directly affected by these system lags. Liz ^{Read! Talk!} 01:50, 5 August 2024 (UTC)

So the replication lag has reached three and a half days. Is this situation normal or has something gone wrong and needs to be attended to? Can an end date be predicted or is it indeterminate? Nurg (talk) 22:25, 6 August 2024 (UTC)

I poked around and was unable to find a phabricator bug report, but my searching on phabricator does not work well. It looks T367856 accounts for this outage, but there has been no communication from WMF explaining why it is taking longer than the expected 26 hours and when it might be over. Maybe there is chatter on an e-mail list. Does anyone know if the WMF has uptime targets for their servers, including replag? With this one outage, currently at 92 hours, they will be below 99% uptime for the year. We had a 3+ hour outage in May 2024, a 4+ hour outage in June 2024, a 4+ hour outage in September 2023, and probably more. That's a good four and a half days of known downtime in the last twelve months for this valuable service. Not ideal. – Jonesey95 (talk) 06:34, 7 August 2024 (UTC)

There is no guarantees for replag. It is a best effort. We are seeing a lot of this over the last 2 years because Wikimedia are doing major rearchitecting of various database tables to enable them to keep scaling, and unlike the production environment the tools environment does not have the same level of support that would allow to execute these changes without impact. —TheDJ (talk • contribs) 09:32, 7 August 2024 (UTC)

According to a post at https://phabricator.wikimedia.org/T367856 nothing is broken. A process is running that may take 6 days – or maybe longer, or maybe not so long. Nurg (talk) 00:42, 8 August 2024 (UTC)

They're obviously working on Valve Time - X201 (talk) 07:11, 9 August 2024 (UTC)

Hooray, we are over 168 hours (one full week)! (175 hours at this writing.) That's more than a full week of database reports being out of date. It's going to be fun to mop up over a week's worth of mess when this outage finally gets sorted. – Jonesey95 (talk) 17:15, 10 August 2024 (UTC)

It's not a record. I seem to recall that about four or five years back replag hit two or perhaps three weeks. --Redrose64 🌹 (talk) 18:18, 10 August 2024 (UTC)

AfD Statistics not updating either

AfD Statistics https://afdstats.toolforge.org/afdstats has not updated since at least yesterday. I am assuming this is th same issue as replag — Maile (talk) 13:02, 5 August 2024 (UTC)

Working again, as of this AM. — Maile (talk) 11:33, 8 August 2024 (UTC)

Wikiproject Assessment tables not updating either

Reported at Wikipedia talk:Version 1.0 Editorial Team/Index. Same root cause? Nurg (talk) 23:48, 5 August 2024 (UTC)

PetScan

I'm assuming that WP:PETSCAN is affected by the same problem as well, because articles that I fixed a few days ago are still showing in the search results. - X201 (talk) 08:05, 8 August 2024 (UTC)

User Scripts and Template Substitution

I have a minor issue that I need some assistance with. I used to have two scripts that would help with some non-admin closures and archives. I believe the scripts were Discussion closer and manual-archiver. I have been inactive for some time, but, when I checked today -- neither of them seem to be working. In the past I would find two links on the right hand side of a discussion "Archive" and "Close". I would use them to do some amount of non-admin closures to clear the backlog at WT:ITN. Did something change with these scripts? Am I doing something wrong?

Also, unrelated, at User:Ktin I see that the template substitution seems to be failing on most of the templates. Is that because there is a limit on the number of templates on an user page? This is obviously a minor issue. But was generally curious. Thanks. Ktin (talk) 00:36, 5 August 2024 (UTC)

User:Ktin is in Category:Pages where post-expand include size is exceeded. This causes attempted transclusions to just become template links when the limit is broken. It varies greatly how costly templates are. The main cause in your case is the 31 {{Get short description}}. For example, {{Get short description |2023 Indian Premier League final}} uses 9% of the 2 MB limit. PrimeHunter (talk) 13:05, 5 August 2024 (UTC)

Without those 31 {{Get short description}}, the whole page would only use 3% of the limit instead of breaking it. You import User talk:DannyS712/DiscussionCloser in User:Ktin/common.js. See User talk:DannyS712/DiscussionCloser#Patched version (I haven't tried it). You also load User:Evad37/OneClickArchiver. Wikipedia:One click archiving says it's no longer recommended and suggests other scripts. PrimeHunter (talk) 13:17, 5 August 2024 (UTC)

Thanks a lot, PrimeHunter. The template evaluation workload makes sense. Appreciate you helping me get to the bottom of that. Will try updating that and the scripts over the weekend. Have a nice one! Ktin (talk) 15:23, 5 August 2024 (UTC)

Yes, it transcludes and recursively transcludes the target page. You might want to use something like {{Annotated link}} for better performance, though I'm not sure if that will help with the PEI limit. — Qwerfjkltalk 12:10, 7 August 2024 (UTC)

Template:Efn

Tracked in Phabricator
Task T371839

Template:Efn used with basic parameters would usually be displayed as ^[a][b] etc. But, in the recent days it's being displayed as ^{[lower-alpha 1][lower-alpha 2]} etc. Why is it? Vestrian24Bio (TALK) 01:20, 5 August 2024 (UTC)

Where? -- Michael Bednarek (talk) 05:06, 5 August 2024 (UTC)

Any page I see using it. Vestrian24Bio (TALK) 05:40, 5 August 2024 (UTC)

 Works for me Specific examples please. --Redrose64 🌹 (talk) 06:47, 5 August 2024 (UTC)

Windows 10 version history, Windows 11 version history

Screenshots: [1], [2] Vestrian24Bio (TALK) 06:56, 5 August 2024 (UTC)

"Rendered with Parsoid", as above (#Start a discussion notice on Talk pages) to your earlier question. -- Michael Bednarek (talk) 07:39, 5 August 2024 (UTC)

Why is the Parsoid causing these problems and it isn't discussed anywhere on en-WP?? Vestrian24Bio (TALK) 07:42, 5 August 2024 (UTC)

Vestrian24Bio, because most people don't use Parsoid, so some templates break with it. — Qwerfjkltalk 08:33, 5 August 2024 (UTC)

Neither Windows 10 version history nor Windows 11 version history uses {{efn}}, please supply examples where {{efn}} is actually used and is a definite factor in the perceived problem. Also, your screenshots are unusable, as I can't find whatever it is I'm supposed to be looking for. Please follow the directions at WP:WPSHOT. --Redrose64 🌹 (talk) 14:41, 5 August 2024 (UTC)

The section Windows 10 version history#Channels transcludes {{Windows 10 versions}} which uses efn. I can see the ^{[lower-alpha 1][lower-alpha 2]} as described in the screenshot and the list then is a,b, etc. Could the transclusion interfere with the correct behaviour of efn?  —  Jts1882 | talk  14:50, 5 August 2024 (UTC)

I can see the problem on any page listed here. So, I took screenshots of 3 random pages:

• Aristotle – Lead paragraph with ^{[upper-alpha 1]}; Screenshot
• ASCII – Screenshot
• Apple Inc. – Screenshot

Vestrian24Bio (TALK) 15:44, 5 August 2024 (UTC)

I see no problem with any of these articles, logged-in or logged-out. If no problem is apparent when logged-out, but you have a problem when logged-in, that tells me that there's something unusual about your custom settings. --Redrose64 🌹 (talk) 17:39, 5 August 2024 (UTC)

"Rendered with Parsoid" as said above. Vestrian24Bio (TALK) 17:41, 5 August 2024 (UTC)

I don't see how that happens. According to mw:Parsoid, it's something to do with converting Wikitext to HTML. So, as all of our pages are written using Wikitext, and all of our readers are served HTML, the conversion process should be the same for everybody, and Parsoid must be that process. So why do I get something different from Vestrian24Bio? Has one of us turned off Parsoid, and if so, how and why? --Redrose64 🌹 (talk) 20:21, 5 August 2024 (UTC)

It's not the default wikitext parser. If you opt into it at the bottom of Special:Preferences#mw-prefsection-editing, you should see the [lower-alpha 1] misparse, too; I do, at least. —Cryptic 20:37, 5 August 2024 (UTC)

There is ongoing work in this area. I will file a bug. Izno (talk) 17:09, 5 August 2024 (UTC)

Looks like the CSS for phab:T156351 (that Parsoid requires rather than using MediaWiki:Cite link label group-lower-alpha) needs updating after Ieff73769, probably from .mw-ref > a[data-mw-group=lower-alpha]::after to .mw-ref > a[style~="mw-Ref"][data-mw-group=lower-alpha]::after (and the same for the other groups). Anomie⚔ 00:50, 6 August 2024 (UTC)

Yes, that would fix it, just a specificity issue it looks like. And the change looks deliberate, but 1) I'm not sure the impact was considered, and 2) I'm not sure that [style~="mw-Ref"] particularly is a nice selector for sundry reasons. Izno (talk) 01:11, 6 August 2024 (UTC)

I've made Anomie's change as a for-now solution while we wait for whatever is being hacked on by WMDE. Izno (talk) 02:54, 10 August 2024 (UTC)

Dark mode for pure-HTML table templates

Template:Hsl-swatches and Template:Hsv-swatches use the pure HTML table format and needs to be adapted so that they display correctly in dark mode. –LaundryPizza03 (dc̄) 04:03, 5 August 2024 (UTC)

Fixed by Jonesey. Izno (talk) 17:22, 5 August 2024 (UTC)

Tech News: 2024-32

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

• Two new parser functions will be available this week: {{#dir}} and {{#bcp47}}. These will reduce the need for Template:Dir and Template:BCP47 on Commons and allow us to drop 100 million rows from the "what links here" database. Editors at any wiki that use these templates, can help by replacing the templates with these new functions. The templates at Commons will be updated during the Hackathon at Wikimania. [3][4]
• Communities can request the activation of the visual editor on entire namespaces where discussions sometimes happen (for instance Wikipedia: or Wikisource: namespaces) if they understand the known limitations. For discussions, users can already use DiscussionTools in these namespaces.
• The tracking category "Pages using Timeline" has been renamed to "Pages using the EasyTimeline extension" in TranslateWiki. Wikis that have created the category locally should rename their local creation to match.

Project updates

• Editors who help to organize WikiProjects and similar on-wiki collaborations, are invited to share ideas and examples of successful collaborations with the Campaigns and Programs teams. You can fill out a brief survey or share your thoughts on the talkpage. The teams are particularly looking for details about successful collaborations on non-English wikis.
• The new parser is being rolled out on Wikivoyage wikis over the next few months. The English Wikivoyage and Hebrew Wikivoyage were switched to Parsoid last week. For more information, see Parsoid/Parser Unification.

Learn more

• There will be more than 200 sessions at Wikimania this week. Here is a summary of some of the key sessions related to the product and technology area.
• The latest Wikimedia Foundation Bulletin is available.
• The latest quarterly Language and Internationalization newsletter is available. It includes: New design previews for Translatable pages; Updates about MinT for Wiki Readers; the release of Translation dumps; and more.
• The latest quarterly Growth newsletter is available.
• The latest monthly MediaWiki Product Insights newsletter is available.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 20:40, 5 August 2024 (UTC)

c:Template:Dir and c:Template:BCP47. I don't think I've ever used them. --Redrose64 🌹 (talk) 22:16, 5 August 2024 (UTC)

They're templates used by templates. Almost every file description page uses them indirectly when marking up the languages of file descriptions, for example. Probably many other translateable templates do as well. Matma Rex talk 09:01, 6 August 2024 (UTC)

Only templates that deal with multiple languages are likely to use these. Often as part of other templates. These are typical cases of templates that are used the most without people ever realizing they exist ;) —TheDJ (talk • contribs) 09:28, 7 August 2024 (UTC)

Cite button in Visual Editor is broken

I'm getting 404 errors from the API in the console, don't have time to investigate further. RAN1 (talk) 03:22, 6 August 2024 (UTC)

It works for me (trying to cite "https://www.example.com"). What inputs cause the problem for you? Matma Rex talk 08:59, 6 August 2024 (UTC)

Works for me now too. The API endpoint was responding with 404s when I was trying to cite apnews.com, it looked like it went down. RAN1 (talk) 14:43, 6 August 2024 (UTC)

WikiProject templates category redirect mess

Something is suddenly causing various templates associated with WikiProjects to populate category redirects. Part of the problem is rooted in the template and category names not matching.

Populated redirects include: Category:WikiProject Belgrade, Category:WikiProject Doctor Who templates, Category:WikiProject Magazines templates and Category:WikiProject Portals templates.

Is anyone able to identify what change has caused these to suddenly populate and fix it? Thanks in advance. Timrollpickering (talk) 10:40, 6 August 2024 (UTC)

Based on timestamps things were added to the category, the first three look like they're due to Special:Diff/1238812083. The last seems to have been done manually: Special:Diff/1238918898, Special:Diff/1163203429/1238919315, Special:Diff/1238919052, and Special:Diff/1238918849. Anomie⚔ 12:30, 6 August 2024 (UTC)

Gadget to view section sizes

Is there a way to view a page's section sizes without having to add {{Section sizes}}? A diehard editor (talk | edits) 13:10, 6 August 2024 (UTC)

Not aware of a way to see it all at once, but you can use Wikipedia:Prosesize on the edit preview screen when looking at a particular section. CMD (talk) 14:34, 6 August 2024 (UTC)

Delay in global lock on account

𝕲𝕵𝕺𝕭𝕬𝕵 𝕺𝕽𝕯𝕰𝕶 𝕺𝕱 𝕾𝕬𝕿𝕬𝕹's account is global locked, even though their name is in title blacklist for only on English Wikipedia. Also, why was their account even given the permission to be created, so that they can make three edits and then get globally locked? Thanks, ExclusiveEditor _{Notify Me!} 16:11, 6 August 2024 (UTC)

This global account was created on another project, TBL doesn't stop autocreation. — xaosflux ^Talk 18:58, 6 August 2024 (UTC)

Adding transparency to make templates more dark-mode friendly

As someone who has witnessed the transition to Fandom Desktop which had a dark mode included, I want to suggest something that might actually be good for templates, and that is adding transparency to backgrounds (not to the font, just to backgrounds using rgba or hex codes) This could be done automatically but it might be better to do so in wikitext and may be a good addition to the manual of style. This would allow the text to be colored white (or whatever) and we would not have to auto-color stuff with backgrounds black. I wonder what level of transparency would be good for this. I was thinking 0.1 but there isn't a good way to check. Maybe this could be done as a bot task for inline styles and by interface admins for CSS sheets. Awesome Aasim 19:34, 6 August 2024 (UTC)

Maybe that is useful for the night mode gadget (I would not know), but for the vector-2022/minerva night mode using 'background:transparent' where the light mode color is white is frowned upon per Mw:Recommendations for night mode compatibility on Wikimedia wikis#Avoid using background: none or background: transparent. Snævar (talk) 21:58, 8 August 2024 (UTC)

Excessive "link added" notices

When a link to an article someone has created is added to a navbox, and someone subsequently edits any page in such navbox, regardless of the content of that edit, the user who created said article which was added to the navbox gets a notice that a "link was added" to that article, when that is not the case. I'm guessing the reason as to why mediawiki doesn't "register" that a link was added to a navbox in each transclusion of it has to do with the page not being purged until the next edit is made to it, but is there a way this can be fixed for link added notices? I'm aware one could just turn these off, but it does nevertheless seem like a bug. Flemmish Nietzsche (talk) 08:44, 7 August 2024 (UTC)

Not currently. From the perspective of Mediawiki, there is no difference between a link included in a page vs included via a templat, or rather what u describe a specific subset of templates. —TheDJ (talk • contribs) 09:15, 7 August 2024 (UTC)

I'm having a similar problem; I got two notifications earlier today,

1. A link was made from ‪2027 Cricket World Cup qualification‬ to ‪2027 Cricket World Cup Qualifier Play-off‬. [5]
2. A link was made from ‪2027 Cricket World Cup Qualifier‬ to ‪2027 Cricket World Cup Qualifier Play-off‬. [6]

I got these notifications because I created 2027 Cricket World Cup Qualifier Play-off‬, but I don't have any of these pages on my watchlist or subscriptions.

I'm also confused because whenever a new notification arrives its also sent as a mail notification (only to those who preferred it). But, no mail notification is received when "A link was made" notification arrives... Vestrian24Bio (TALK) 10:06, 9 August 2024 (UTC)

These are settings per notification type, in your preferences, in the notifications section. —TheDJ (talk • contribs) 09:50, 10 August 2024 (UTC)

Editing problem

Hi. For about four days I have been unable to edit articles. When I click on either the edit tab at the top of a page or the section edit tags to the right of section headings, an edit box appears to open, but a blue progress bar appears at the top which stops about three-quarters of the way across the page. As a result, I have an edit box where I can work, but no way to save my changes. Exceptions that do work are: 1. on pages like this one, the tab at the top that opens a new section; 2. clicking on "reply" on a talk page; and 3. clicking on "undo" in an article history. Those open functional edit boxes (hence I can write this). But regular editing is effectively blocked. Does anyone have an idea what the problem might be? (Incidentally, for the last year I have successfully been using the 2017 wikitext editor. I don't know if that is the problem, but I can't find any way to access it to switch it off.) Doric Loon (talk) 00:25, 8 August 2024 (UTC)

The blue progress bar you describe is probably the loading animation for the Visual Editor. In your Preferences you can uncheck the checkbox named "Enable the visual editor". Then Save the changes with the Save button near the bottom of the page.

Exception 2 is probably the Discussion Tools feature.

I am not sure what could cause this problem, and I never use the Visual Editor. Programmers often, but not always, put error messages in the Javascript console when something goes wrong. Depending on which browser you have you could try pressing F12 to open the Developer tools, and then clicking on "Console" and then loading a webpage with the Visual Editor enabled (which will fail) to see if it generates any error messages. If there are any error messages this may be useful to whoever tries to diagnose the problem. Polygnotus (talk) 12:34, 8 August 2024 (UTC)

What browser/operating system are you using? What versions? What happens when you click this edit link? Izno (talk) 15:36, 8 August 2024 (UTC)

OK, I seem to have solved it by unclicking "Use the wikitext mode inside the visual editor, instead of a different wikitext editor This is sometimes called the '2017 wikitext editor'" in Preferences. Perhaps this plug-in is no longer working. Shame, I did find it helpful, how it marked coding in different colours. Anyway, problem solved, thanks. Doric Loon (talk) 15:56, 8 August 2024 (UTC)

The 2010 wikitext editor also can use highlighting, see the marker icon in the middle of the editing bar. Izno (talk) 15:59, 8 August 2024 (UTC)

"Remember me" not working as intended for me

Exactly as title. The checkbox states that it would last a year, yet sometimes I would find myself not logged in even though I am using the same device, same browser, etc. It is just a mild annoyance, but can someone give me pointers on how to fix this? Thanks in advance. —Mint Keyphase (Did I mess up? What have I done?) 01:26, 8 August 2024 (UTC)

Could happen if you log out on another device in the meantime. hgzh 10:51, 8 August 2024 (UTC)

But I am only using this one device logged in, and I'm quite sure my account wasn't hacked (hopefully(?)). —Mint Keyphase (Did I mess up? What have I done?) 11:23, 8 August 2024 (UTC)

Anything that clears or blocks your local storage (cookies) can invalidate your saved logon. Some browser or browser extension updates can cause this. — xaosflux ^Talk 15:10, 8 August 2024 (UTC)

FWIW I was logged out unexpectedly under similar circumstances on the day this was posted as well. I use Windows primarily with Chrome; if you also have a similar configuration, that *could* be an explanation. Graham87 (talk) 04:26, 9 August 2024 (UTC)

In Javascript, insert template in correct place (after hatnotes)

According to MOS:ORDER, DuplicateReferences has to insert maintenance templates at the correct place in the article (6. Maintenance, cleanup, and dispute tags). Is there a trick to ensure that the template {{Duplicated citations}} is inserted at the correct location? Polygnotus (talk) 12:14, 8 August 2024 (UTC)

The obvious method is to make a long list of all the templates, and all redirect to those templates (and filter out those that are not used in mainspace), that should appear above the maintenance templates. But that quickly turns into a giant list and a lot of work. Isn't there a smarter way to do this? Is there some kind of Javascript library I can import? Polygnotus (talk) 16:09, 8 August 2024 (UTC)

Figured it out (somewhat) by stealing getting inspiration from Twinkle's code. [7] which uses morebits [8]

regexes

const shortDescriptionRegex = /\{\{\s*short description\s*\|[^}]+\}\}/i; const displayTitleRegex = /\{\{\s*(DISPLAYTITLE|Lowercase title|Italic title)\s*(\|[^}]+)?\}\}/i; const hatnoteRegex = /\{\{\s*(hatnote|main|correct title|dablink|distinguish|for|further|selfref|year dab|similar names|highway detail hatnote|broader|about|other uses?|redirect|see)\s*(\|[^}]+)?\}\}/i; const articleStatusRegex = /\{\{\s*(Featured list|Featured article|Good article)\s*\}\}/i; const deletionProtectionRegex = /\{\{\s*(db|delete|prod|proposed deletion|ArticleForDeletion|AfDM|pp|protected)\s*(\|[^}]+)?\}\}/i;

Polygnotus (talk) 05:59, 10 August 2024 (UTC)

CT scan viewer gadget, part 2

Doc James talked to me at a conference and asked me to look into installing MediaWiki:Gadget-ImageStackPopup.js as a default gadget. It looks like this one is pretty much ready. The last discussion on it was at Wikipedia:Village pump (technical)/Archive 213#New Gadget for viewing CT images, and it looks like all recent suggestions by folks such as TheDJ and DMacks were implemented and this can move forward. At some point Xaosflux also set this up as a gadget in the "test" category.

It sounds like the next step is to set this up to be a default gadget, and we should work out the details for that. In one discussion, MusikAnimal also suggested that this gadget only be loaded for pages that need it, and that this could be done using categories.

With these parameters in mind, is this how we should set up the MediaWiki:Gadgets-definition? Is everyone OK with moving forward?

== template-gadgets ==
* ImageStackPopup [ ResourceLoader | default | categories = Pages using gadget ImageStackPopup ] | ImageStackPopup.js | ImageStackPopup.css

Thanks. –Novem Linguae (talk) 13:44, 8 August 2024 (UTC)

I'm ok with it. —TheDJ (talk • contribs) 13:58, 8 August 2024 (UTC)

Seems like it has been fairly stable? I've created the trigger category using the same naming convention as the others (Category:Pages using gadget ImageStackPopup) - which will need to get populated to pages where this will need to run. That is likely best done via some template. — xaosflux ^Talk 14:59, 8 August 2024 (UTC)

Prior discussion was that perhaps these should be un-opt-out-able (i.e. hidden gadgets), primarily to not pollute the gadget list. I'm not sure that is needed though, and could always be revisited after this goes live. — xaosflux ^Talk 15:01, 8 August 2024 (UTC)

So barring any objections, the next steps are: update the pages to somehow include the category; move the gadget from test to template-gadgets with updated parameters. — xaosflux ^Talk 15:07, 8 August 2024 (UTC)

Using a consistent template-gadget category naming convention isn't strictly necessary but I think it has benefits (in this case, just change the included trigger category, or add an additional cat, in Template:ImageStackPopup). — xaosflux ^Talk 15:13, 8 August 2024 (UTC)

Sure. I've changed the tracking category to Category:Pages using gadget ImageStackPopup in {{ImageStackPopup}}, and I've updated the proposed gadget-definition code above. –Novem Linguae (talk) 20:57, 8 August 2024 (UTC)

•  Done @Novem Linguae: I've promoted this from test to template-gadget; please validate and ping me if any issues. — xaosflux ^Talk 15:29, 9 August 2024 (UTC)

RFPPI's automatic section title

I am unsure which talk page is the intended place to ask for this since most redirect to WT:RFPP (which, if it was the intended place, is protected), but is there any way to change the form (the Request protection button), so that it does this automatically? – 2804:F1...20:147 (talk) 20:26, 8 August 2024 (UTC)

The above is saying that the "Request protection" button at Wikipedia:Requests for page protection should insert a colon in front of the title if that title is for a Category (so the result is a link to the category rather than something which puts the page in the category). That is above my pay grade but might involve ?withJS=MediaWiki:Request-page-protection-form.js at MediaWiki:Request-page-protection-form.js. Johnuniq (talk) 00:19, 9 August 2024 (UTC)

Ah, reading the code it seems that the formatted text comes from the template values in Wikipedia:Requests for page protection/Forms-configuration.json.

Is there any side effect to just adding the colon in the section titles there? It seems like that's what the pagelinks template already does (and many others).

I won't request an edit there because I already started this, and because I'm not sure if it's that easy. Thanks for this info. – 2804:F1...20:147 (talk) 03:11, 9 August 2024 (UTC)

Just to be clear, that is my question (and if yes, my suggestion) now. Does simply doing this change at the aforementioned JSON work for fixing this?:

−

=== [[$title]] ===

+

=== [[:$title]] ===

– 2804:F1...92:7B79 (talk) 16:36, 9 August 2024 (UTC)

Add A Fact experimental tool from Future Audiences

The Future Audiences team at the foundation is launching Add A Fact, an experimental tool for adding information to English Wikipedia from outside the website. You can download the extension from the Chrome store here: Add A Fact. For now, an (auto)confirmed English Wikipedia account is required to submit facts with this extension.

The idea was developed and workshopped with Wikipedians at WCNA 2023, demoed and tested with Wikipedia community members as part of our team’s regular monthly community calls.

Here is a short demo video on the extension:

A quick how-to —

1. While reading any secondary source on the web (a news item, a scholarly article, etc.), you can open Add A Fact and highlight a short claim that you may want to add to Wikipedia.
2. An LLM will check if the selected claim is related to any existing Wikipedia articles, and will present information about whether the fact is fully, partially, or not present in these articles. You may also search for an article of your choosing.
3. Once you select a Wikipedia article to add your fact to, Add A Fact will give you the option of sending a pre-filled template message to the talk page of the article, which includes the selected text, any additional comments you’d like to add, and a structured citation. This message will be signed under your Wikipedia username.
4. If the URL of the source you are on appears on WP:Reliable_sources/Perennial_sources, you will receive a warning message about your source’s reliability (but will still be able to add a suggested fact from this source). If the URL of the source you are on appears on the spam blocklist, you will not be able to add a suggested fact from this source.
5. To limit any potential misuse/spam, Add A Fact users will be limited to sending a maximum of 10 facts per day during this early experimental period.

We've answered some common questions on our FAQ.

Add A Fact seeks to prove or disprove a hypothesis about how we might continue to sustain and grow Wikimedia projects in a changing online knowledge landscape. In this case, we’re seeking to understand how people can make editorial contributions off-platform (that is, without going directly to Wikipedia.org), and if generative AI can support or hinder this process.

If you use the tool, please give us your thoughts anonymously via the feedback form on the extension, in this VP thread or on my subpage. DErenrich-WMF (talk) 16:09, 9 August 2024 (UTC)

No Firefox support? Why not? Which APIs are you missing? Polygnotus (talk) 20:49, 9 August 2024 (UTC)

@Polygnotus: FF doesn't support service workers in manifest v3 but I actually think there's a way I can work around this (looking into this today). FF support is on our radar. DErenrich-WMF (talk) 21:06, 9 August 2024 (UTC)

Thank you. The tool looks interesting but I strongly dislike Chrome. Polygnotus (talk) 21:20, 9 August 2024 (UTC)

If its a chrome extension then, It would work in Microsoft Edge as well. Vestrian24Bio (TALK) 00:19, 10 August 2024 (UTC)

I dislike Edge even more strongly, for very similar reasons. Polygnotus (talk) 00:30, 10 August 2024 (UTC)

It is unfortunate that the video demo shows someone suggesting a press release for a source on a medical topic, which would surely not pass WP:MEDRS. MrOllie (talk) 21:33, 9 August 2024 (UTC)

That's a good point. We tried to have the tool warn you about unacceptable sources but encoding all the nuances of the rules is hard. But doing this better is something we should look more into. DErenrich-WMF (talk) 23:05, 9 August 2024 (UTC)

The message left on the talk page, will that include some template or tracking category, so that editors can easily find a list of facts to be added, and act upon them? Otherwise, especially if the facts are posted on lesser-watched talkpages, it'll be like shouting into the void. --rchard2scout (talk) 06:30, 10 August 2024 (UTC)

It doesn't currently use a tracking template but that's planned for the next minor release. For now you can find the relevant edits by using hashtags DErenrich-WMF (talk) 17:21, 10 August 2024 (UTC)

Will we be able to find out how many facts posted to talk pages have been reviewed and used in articles, as opposed to rejected, and how many have not been considered at all (eg because of being on a less-watched page)? In what other ways will this tool be evaluated? For example, how might we detect an increase in, as the close of Wikipedia:Administrators' noticeboard/IncidentArchive1160#User:Drbogdan, persistent low-quality editing, and WP:NOTSOCIALNETWORK issues put it, mass-adding content based on low-quality popular science churnalism to our science articles, expecting that other editors will review it and determine whether to improve or remove it, leading to an indefinite community block? NebY (talk) 01:56, 11 August 2024 (UTC)

Once the experiment is complete (probably in a few months) we will put together a report with our findings. See for example the report for the last project we did. The metrics we're looking at are the kind of things you'd expect: number of users, number of edits, number of reverts, etc. But probably more importantly we're also collecting qualitative evidence (e.g. discussions like this one, feedback forms or by manually looking at the edits being made). DErenrich-WMF (talk) 04:09, 11 August 2024 (UTC)

Getting Cite errors and CS1/CS2 errors for an article via the API

I want to get information about Cite errors and CS1/2 errors via the API. The input should be the title of a Wikipedia article and the output should be either a list of cite errors or a list of CS1/2 errors (or a combination).

The articles are in Category:Pages with citation errors and Category:CS1 errors. There doesn't appear to be a separate category for CS2 errors.

CS1/CS2

If I add {{citation |first=bar |title=foo}} to my userpage I see:

foo {{citation}}: |first= missing |last= (help)

On this article I can see that the API reports that there is a CS1 error, but not what the actual problem is. I have added the CSS found here so I can see the specific CS1 error when viewing the article in my browser. But how can I get this information via the API? It looks to me like Module:Citation/CS1/Configuration generates the error messages; does the fact that the error is generated by this Lua script mean I can't get this information via the API? Or do I have to get the rendered page to get the actual HTML and search that for error messages?

Is it possible to detect (via the API) if an edit causes a CS1/CS2 error before actually making the edit?

There are roundabout ways, but otherwise, the answer to does the fact that the error is generated by this Lua script mean I can't get this information via the API is yes. Each error emits a category but you will only know which categories go with which citations by using something like the mw:API:Expandtemplates on the source wikitext. If you don't care about knowing which templates have which issues, you can use the categories API. Another solution is to get the HTML and then search for the relevant classes with e.g. mw:API:REST API though I think there are other APIs one could use (even ignoring screen scraping).

Is it possible to detect (via the API) if an edit causes a CS1/CS2 error before actually making the edit? Only with something like the above. Izno (talk) 02:27, 10 August 2024 (UTC)

Cite error

On Brainwashing I see a cite error on ref 87: Cite error: The named reference they-never-said-it was invoked but never defined (see the help page). Which API call should I make to get this information? I assumed it was this (Sandbox).

Is this also handled by a Lua script somewhere? What is the URL? It looks like its using MediaWiki:Cite error references no text but I can't seem to find a Lua module referencing that. Is it in a MediaWiki extension written in PHP?

Do I have to get the rendered page to get the actual HTML and search that for error messages?

How would I detect (via the API) if an edit causes a cite error before actually making the edit?

It looks like I am at least able to find errors before they happen with action=parse, but those are warnings from the parser, not the Lua script(s). Is that correct?

These errors originate from mw:Extension:Cite. You can explore the documentation there, but I do not think there is anything to indicate errors in an API. Besides whatever categories are emitted, as discussed above, but that would not tell you which references caused an error I believe. Izno (talk) 02:30, 10 August 2024 (UTC)

Bot

Which bot, if any, is running on Category:Pages with broken reference names to find the most recent revision that contains that refname so it can be restored? Shouldn't be too hard to write, right? Can the InternetArchiveBot do that?

Polygnotus (talk) 23:43, 9 August 2024 (UTC)

AnomieBOT. Izno (talk) 02:19, 10 August 2024 (UTC)

@Izno: Thanks a lot! This is a con of the Lua stuff, but there are a lot of pros. Lots of food for thought. Polygnotus (talk) 05:55, 10 August 2024 (UTC)

Using Twinkle to tag articles

I apologise if this has been asked already.

I have noticed a problem with accessing all of the tag options when using Twinkle. I switch between mobile to desktop when I need to use Twinkle, in most instances the full drop down menu is fine, I can scroll up or down to find the correct message I need. When trying to add a welcome message for new users the scroll doesn't work though. I can only access the initial few welcome messages but that's it. I also have the same problem with tagging articles in the mainspace. I've found an article published to the mainspace and it doesn't have any references. I wanted to tag it as such but I am unable to scroll down the menu to the correct option.

Most of the Twinkle options are fine, such as CSD, I can scroll down to view all the options. It seems to be a problem with Welcome messages and article tagging. Am I doing something wrong? Thanks in advance, Knitsey (talk) 15:42, 10 August 2024 (UTC)

What OS/browser are you using? Nardog (talk) 20:15, 10 August 2024 (UTC)

Hi Nardog, Google chrome. Is that what you mean? Knitsey (talk) 20:30, 10 August 2024 (UTC)

Google Chrome is your browser. "OS" is short for Operating System which is most likely Microsoft Windows (other options are Linux and Mac OS). Polygnotus (talk) 01:53, 11 August 2024 (UTC)

Polygnotus, I completely missed the OS bit! Android, version 14 if that makes a difference. The scroll down options always used to work. I've been on a Wikipedia break for about 8 months, come back and those two sections no longer scroll. Knitsey (talk) 02:13, 11 August 2024 (UTC)

So you're on a mobile device or tablet? And nothing happens even if you swipe down? Is the desktop mode on? Nardog (talk) 02:49, 11 August 2024 (UTC)

I use my mobile. Switch to desktop to use Twinkle. It is just those two menus that I can't scroll down... Welcome messages for new users and the tag menu on articles.

The Twinkle menu for vandalism warnings is fine, I can scroll down on that. The same for CSD, I can scroll down on that too.

With Welcome messages, I can always go back to using templates for now. I'm just curious as to why those two drop downs and whether it cwn be fixed. Knitsey (talk) 03:01, 11 August 2024 (UTC)

By the desktop mode I mean the "Desktop site" in the Chrome menu. Is it checked? Nardog (talk) 03:32, 11 August 2024 (UTC)

I'm not sure what you mean? I go to the bottom of the Wikipedia page and click desktop view. Knitsey (talk) 03:43, 11 August 2024 (UTC)

Warburg Institute italic title

Can someone take a look at the Warburg Institute article? The title is being italicized (when it should not be); it uses {{infobox journal}} later in the article, which auto-italicizes, but it's set to "no" as the template says so presumably this should not be happening. Aza24 (talk) 01:35, 11 August 2024 (UTC)

@Aza24: I removed the underscore in the "italic title" infobox parameter and it looks like that was the issue. DanCherek (talk) 01:44, 11 August 2024 (UTC)

Oh, strange—Thanks! Aza24 (talk) 01:45, 11 August 2024 (UTC)

Wikipedia:Long-term abuse/List

Some of the entries are referring to historic/stale accounts. It's hard to gauge. I was thinking add a column, "Page last edited". Is this information available somehow, given the name of a page, return the date of last edit? It's not a perfect solution but some information is better than none, recent activity will be more visible. -- GreenC 04:19, 11 August 2024 (UTC)

I believe it is mw:API:Revisions: example. In my limited experience, it can foul up if strange things occur. I forget exactly what but it was something like the user had been renamed, or maybe a revision deletion? Johnuniq (talk) 05:59, 11 August 2024 (UTC)

@GreenC: given the name of a page, return the date of last edit - yes, see Help:Magic words#Page revision data. Let's assume that the LTA habitually targets pages in Category:Civil parishes in Oxfordshire. We might have this partial list:

• List of civil parishes in Oxfordshire Crouch, Swale 20240805195559
• Abingdon-on-Thames Murgatroyd49 20240717065044
• Adderbury Martinevans123 20240608221415
• Adwell Redrose64 20240527201450
• Alvescot GoingBatty 20220123234127
• Ambrosden 86.182.168.130 20240601130830
• Appleford-on-Thames Legolag 20240705160708
• Appleton-with-Eaton Redrose64 20240528122608

--Redrose64 🌹 (talk) 09:51, 11 August 2024 (UTC)

Tool limits on mobile version

Moved from Wikipedia talk:Village pump

What's the technical or by design reason for the limitations of the editing tools on the mobile version? Many of the tools that you can add through code particularly don't seem to show up in any form in the mobile format. Is there any features pipeline to introducing this functionality? Iskandar323 (talk) 10:47, 11 August 2024 (UTC)

Proposals

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

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)

Thanks for clarifying that Sohom. Aszx5000 (talk) 09:01, 9 August 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)

  not for all article moves but for those by non-EC users which I think was 40 a day at the time. This somehow ended up not reflected in the 2017 RFC close and not reflected in the 2017 Phabricator ticket. We could go off on a tangent about whether that RFC was closed correctly or not, but I think it's a non-issue because we'll get a fresh consensus in this RFC that will override any lack of clarity about the previous close. –Novem Linguae (talk) 23:58, 28 July 2024 (UTC)

• ??? 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)
• Oppose: Unnecessary. They will almost always be marked as reviewed immediately, so this just adds a pointless burden to the NPP queue. C F A 💬 22:15, 28 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)

@Folly Mox. For some reason they exist as two different pages: https://xtools.wmcloud.org/blame/en.wikipedia.org?page and https://blame.toolforge.org/wikiblame.php. Infogiraffic (talk) 17:48, 26 July 2024 (UTC)

Blame and Wikiblame have the same goal, but they're separate tools/separate software code. Someone might want to have access to both tools, but they should be side by side in the list.

On the other hand, Wikiblame should not be in the list with Wikidata, Wikinews, Wikibooks, and other sister projects. But Commons and Wiktionary should be in the list of sister projects, and I don't see them. WhatamIdoing (talk) 05:24, 27 July 2024 (UTC)

@WhatamIdoing. Hopefully I haven't given off the impression that I am offering an exhaustive overview. Commons and Wiktionary are just as welcome. My main focus was on getting some relatively hidden tools to be accessible via 'Analysis'. Infogiraffic (talk) 08:32, 29 July 2024 (UTC)

As a proof of concept, I think it's fine. I wouldn't personally find it very useful, because I'd rather type than look for anything in a menu. But others, especially those less familiar with MediaWiki software, likely have the opposite preference. WhatamIdoing (talk) 16:29, 29 July 2024 (UTC)

Both tools serve the same purpose (revision history tracking) but have separate codebases. Ideally, they should be grouped together under a single, clear label like "Revision History." While some users prefer keyboard shortcuts, menus can be helpful for those less familiar with MediaWiki. Perhaps a balance can be struck? We could consider a hybrid approach with both keyboard shortcuts and a more intuitive menu structure. What about submenus for categories like "Analysis Tools" (where "Revision History" would reside) and "Sister Projects"? BlackOrchidd (talk) 08:46, 7 August 2024 (UTC)

Afd to Prn/Pcn

Can we rename Articles for deletion to Articles for checking/Reviewing notability which will give a positive impression than the present one. 103.66.169.3 (talk) 19:36, 26 July 2024 (UTC)

• I think this is one of the perennial proposals, and the answer is "not necessary" (at any rate, it would require rewriting thousands of lines of active software, and moving half a million pages). jp×g🗯️ 22:15, 26 July 2024 (UTC)
  • The French Wikipedia did this, perhaps two years ago. AIUI they thought the communicative value (e.g., that we are here to check notability, not necessarily to delete the page) outweighed the one-time hassle. (Also, you don't have to move the prior pages; you can just move a few key pages, like Wikipedia:Articles for deletion itself, and leave the old ones alone.) WhatamIdoing (talk) 05:39, 27 July 2024 (UTC)
    • I've been around long enough to remember the move from Wikipedia:Votes for deletion. It was a one-time hassle, yes, but it was a major hassle. (Uncle G may want to comment; xe did most of the legwork IIRC, and is still active.) —Cryptic 05:51, 27 July 2024 (UTC)
      • It was indeed a huge undertaking; no, we do have to move a huge amount of pages (as my major work 'bot did); and as JPxG points out there is more in place nowadays that is hardwired to the page prefix (from the templates that we invented at the same time, to people's private add-in scripts) than there was back then. Moreover we are not checking notability. We are deciding whether an administrator hits a delete button on an article, for those cases where it isn't obvious on sight that the article should be deleted and 1 person alone can safely make the decision to press that button. It's a very clear name for the very single purpose that it is there for. Stuff outwith the decision about whether an administrator hits a delete button or not is intentionally left to the editorship at large. Uncle G (talk) 02:08, 28 July 2024 (UTC)

        I'm also old enough to remember the VfD days. Anyway, AfD has its problems. What it's called is not one of them. Let's worry about stuff that matters. RoySmith (talk) 02:25, 28 July 2024 (UTC)

        @Uncle G I appreciate the clarfication that this tool is focused on assisting administrators with clear cut deletion decisions, leaving broader editorial judgments to the communiity. Maybe having a name that reflects this purpose, like "Rapid Deletion Assist" or something similar, could be helpful. BlackOrchidd (talk) 09:15, 7 August 2024 (UTC)

        "Rapid Deletion Assist"? Did you mean Category:Expired proposed deletions? Or perhaps WP:CSD? Or perhaps Special:Nuke? Also AfD is a venue and a process, but not a tool (those are pieces of code).

        Maybe we should leave the name as is, so we don't have to rewrite thousands of scripts and move a half million pages. If there's one deeply embedded major nomenclature failure on the project, it's Notability. The amount of confusion about / discomfort with AfD would need to increase by two orders of magnitude before it would be worth renaming at this point.

        Apologies for the grumpiness. My keyboard keeps crashing, which I hate is a thing that is possible. Folly Mox (talk) 10:12, 7 August 2024 (UTC)

• I agree with Uncle G, the current name has a clarity that said replacements would not have. Even if the new name is somewhat less intimidating to newcomers, it's better to be upfront about what's happening. ― novov (t c) 06:14, 28 July 2024 (UTC)
• Rename to Articles for Discussion?, in line with the other XFDs. I had a similar query and sometimes feel uncertain about nominating articles when I'm on the fence if they should be deleted/merged/redirected. The 'AfD' acronym is also maintained. Svampesky (talk) 23:11, 30 July 2024 (UTC)
  • Sigh. In particular. —Cryptic 23:24, 30 July 2024 (UTC)

    LOL, I had no idea :) Svampesky (talk) 23:42, 30 July 2024 (UTC)

Rephrase the talk page box "Description" prompt

I propose to change the message string at MediaWiki:Discussiontools-replywidget-placeholder-newtopic from Description to Your talk page comment.

The current "Add a topic" interface

Currently if a user clicks "Add a topic" on an article talk page, a box appears which prompts them for a "Subject" and a "Description".

"Description" is somewhat cryptic in that context, and seems like a placeholder string that was never reassessed. A talk page message or question isn't really a description of anything. In some contexts (like Talk:ChatGPT and Talk:Google, talk pages which ended up locked in response to so many people mistaking "Add a topic" for a direct query to those services) asking for a "Description" may, to some users, look more like a prompt to communicate privately with a generative AI or web service, rather than the start of a human conversation with Wikipedia editors.

I raised the suggestion more broadly at the idea lab earlier in the year and was told that, regarding a change to this specific interface message, altering these strings will affect all pages. This change has to be very carefully considered. So here's a concrete proposal to change it. Will "Your talk page comment" make sense in all contexts where this string is displayed, and would we agree that it was an improvement on "Description"? Belbury (talk) 14:06, 8 August 2024 (UTC)

We can certainly improve on "description", and "Your talk page comment" would be such an improvement although I am not immediately certain it is the best we can do - especially if this appears anywhere other than talk pages? Perhaps something as simple as "Your message" would work? Thryduulf (talk) 14:13, 8 August 2024 (UTC)

"Your message" is a definite improvement to "Description". Schazjmd (talk) 14:18, 8 August 2024 (UTC)

Notified: WT:UX, WT:TPP. I would also be interested to hear what PPelberg (WMF) or others on the Talk Pages Project think of this. Sdkb ^talk 15:12, 8 August 2024 (UTC)

• This is a smart suggestion; thanks for raising, Belbury! I'm inclined to support "Your message" for conciseness and to be on the safe side given Thryduulf's concern that it might be used outside of talk pages. Sdkb ^talk 15:15, 8 August 2024 (UTC)

  I agree it should be changed Alexio2727 (talk) 10:45, 9 August 2024 (UTC)

  I agree with the idea, but would be inclined to suggest "Your comment", given that "Your message" might still be mistaken for a ChatGPT/Google/etc. prompt query. Chaotic Enby (talk · contribs) 18:06, 9 August 2024 (UTC)

  I've got no objections to "Your comment". Thryduulf (talk) 18:15, 9 August 2024 (UTC)

• "Your comment". Just based on widespread, almost universal Wikipedia terminology. Messages are for emails and texts—things that are sent, not posted. ―Mandruss ☎ 18:22, 9 August 2024 (UTC)

Deploying Edit Check on this wiki

While attending Wikimania this year, Selena Deckelmann (User:SDeckelmann-WMF) demonstrated a new feature for Visual Editor, Edit Check in a session. Edit check introduces additional prompts in Visual Editor when an editor tries to insert a blacklisted URL as reference and also when they try to publish a revision without inserting a reference. This greatly helps with encouraging editors inserting references in their edits. If I recall correctly, the percentage of editors inserting references increased from 11% to 40% in their tests (do correct me if I am wrong as I am going off on my recollection).

There is certainly some benefits in enabling this, primarily on improving the verifiability and reliability of content that's on English Wikipedia. Most of the sister projects have already been deployed with this feature. English Wikipedia does not have this feature enabled yet. The only thing that is holding back this feature is that Visual Editor is not set as the default editor for anonymous and new editors.

Therefore, I would like to propose that:

1. Visual Editor be the default editor for anonymous and new editors.
2. Deploy Edit Check.

– robertsky (talk) 17:26, 9 August 2024 (UTC)

I thought Visual Editor is already the default for new accounts and unregistered editors? Folly Mox (talk) 17:59, 9 August 2024 (UTC)

The last time I checked, new editors are presented with a pop-up box that asks them to choose which editor they'd like to use, with the solid blue button pushing them a bit toward the VisualEditor.

This thread is rather underdeveloped. For a proposal of this magnitude, I think we should figure out relevant factual questions (like what the current default is) and then draw up a more formal survey that could be CENT-listed, etc. Sdkb ^talk 19:05, 9 August 2024 (UTC)

Another question is how does it work with edits that don't need references adding (e.g. creating redirects, adding links on disambiguation pages, fixing spellings, etc)? Thryduulf (talk) 19:08, 9 August 2024 (UTC)

In theory, this sounds like a great idea. I'm eager to try it out, but I think a first step would be to make it available as an opt-in on enwiki. Then after people have got some experience with it, let's come back and talk about making it the default. RoySmith (talk) 20:09, 9 August 2024 (UTC)

Here's an userscript that I cooked up: User:Robertsky/edit-check-optin.js. It adds &ecenable=1 to edit links that goes to Visual Editor (mw:Help:Edit_check#Testing_Reference_check). – robertsky (talk) 20:37, 9 August 2024 (UTC)

There's a simpler option for userscripts that should work: window.MWVE_FORCE_EDIT_CHECK_ENABLED=true;

So long as that's there before VE loads, it should force you to have edit check. Either method also bypasses the account restrictions on edit check, so you're not quite getting the pure experience that people would if we just turned it on for enwiki. By default it only shows up for new users (defined as under 100 edits), and someone might want to edit the configuration on-wiki for that. DLynch (WMF) (talk) 21:26, 9 August 2024 (UTC)

The add-reference check is very conservative currently. You need to be a user with less than 100 edits who has added a whole new paragraph of at least 50 characters (configurable per-wiki) that contains no references before it'll pop up. This can all be loosened up in the future, whether by default or through community configuration, but we figured that those criteria had pretty low odds of being a false positive to start with.

It's quite interesting that this boosts the percentages so much, because I honestly thought that complete new-editors would be doing far more minor edits. But no, major new blocks of text are pretty popular.

It's actually turned on with the reference check everywhere but 8 of the wikipedias (bn, de, en, hi, id, nl, pl, ru), so it's pretty easy to try it out on another wiki if you don't want to jump through userscript hoops here. DLynch (WMF) (talk) 21:34, 9 August 2024 (UTC)

Not sure where ReplyTool will put this, but nothing I'm seeing in the documentation requires VE to be the default editing interface in order to deploy the new tool. So deployment doesn't seem contingent upon answering the larger question of whether VE should be default. Folly Mox (talk) 22:17, 9 August 2024 (UTC)

Unless things have changed in the last year, it doesn't need it to be the default, but editor does need to be in the visual editor, and that's somewhat more likely to happen (especially for the editor's first edit) when the visual editor is the default. WhatamIdoing (talk) 01:29, 10 August 2024 (UTC)

The functionality is targeted towards new editors and anonymous editors, therefore the need for Visual Editor to be the default before the deployment of the functionality is considered complete. Also there are on wiki configuration options that we may want to adjust. As stated by Dlynch (WMF) above, the tool is configured by default for an user with less than 100 edits and making revisions of more than 50 characters. – robertsky (talk) 04:15, 10 August 2024 (UTC)

Minor quibble: enwiki has already got the prompts about blacklisted URLs for references/links. We rolled those out everywhere on the logic that any edits involving them were going to get blocked-on-save anyway so it wasn't going to disrupt any workflows. :D

It's a bit fuzzy because we called the project "Edit check", and we're developing a specific system called edit check (of which the "add reference" check is the first example), but we're also doing smaller edit-enhancement features along the way that colloquially get called checks just because of the project.

To use the famous quote: "There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors." DLynch (WMF) (talk) 21:43, 9 August 2024 (UTC)

Given the information you've provided.

Conduct a thorough analysis of the potential consequences of setting Visual Editor as the default for anonymous and new users. Consider factors such as user experience, editor retention, and overall editing patterns. If making Visual Editor the default is not feasible, investigate other strategies to increase Edit Check adoption. This could include targeted outreach to experienced editors, promoting the feature through in-editor messages, or developing incentives for reference usage. Regardless of the chosen approach, it's essential to closely monitor the impact of Edit Check on reference usage and article quality. This data will be crucial for refining the feature and measuring its overall effectiveness.

BlackOrchidd (talk) 09:31, 10 August 2024 (UTC)

BlackOrchidd, please sanity check your chatbot's AI response before posting embarrassing things like this. Folly Mox (talk) 13:04, 10 August 2024 (UTC)

• I'd support making Visual Editor the default, as long as they also leave wikitext editing as an option (which I'm sure they will). VE is much better nowadays than when it was first released. As a WYSIWYG editor, I suspect it is much more new editor friendly. It is unarguably better at things such as automatic citation generation and table editing (adding and removing columns and rows, moving columns and rows around). And for the few things it is bad at (such as complicated template syntax), power users can just switch to wikitext editing. Any logged in user can select their default at Special:Preferences (under "Editing mode"). –Novem Linguae (talk) 10:47, 10 August 2024 (UTC)

  Agree 100% MichaelMaggs (talk) 12:00, 10 August 2024 (UTC)

  I totally agree that VE should be the default for new users. I use VE every day, and it's just fine for most stuff, and getting better incrementally. Folks who think VE should not be the default should go to edit-a-thons and try teaching new users. 20 years ago, wiki-markup was the new hotness and was miles ahead of editing raw HTML. Today it's just a barrier to entry for potential new editors. RoySmith (talk) 12:24, 10 August 2024 (UTC)

• When I first edited English Wikipedia as an IP editor, I found WikiText editing very difficult to understand. I’m sure that most new IP editors face this issue. I strongly support making the Visual Editor the default. New IP editors are often unfamiliar with Wikipedia and may not know how to cite a reference using the WikiText editor. They may also not know how to switch to Visual Editing. Frankly, I still have to check the preview before publishing edits using the WikiText editor because I sometimes make mistakes. GrabUp - Talk 11:08, 10 August 2024 (UTC)
• Potentially minor bugbear alert: The visual editor reference creator still hasn't figured out the basic functionality of allowing for an easily accessed and obvious use of an |author= field, instead forcing all authors into |last and |first. It's not a groundbreaking issue, but it's really disappointing that it's still around after so long, especially given the many words given over the years about attracting more diverse perspectives etc. The default reference tool that we are going to create a pop up asking all new editors to use should allow for sources from authors whose names don't fit into the common European name format. It may be hidden behind an additional field button, but at least the wikitext reference creator has the option. CMD (talk) 12:10, 10 August 2024 (UTC)

  My biggest bugbear is the lack of ability to set a reference name. For example in this edit I switched from visual to source editing so I could reuse citations between prose and infobox. Although admittedly this is not something a brand new editor wants to do, being able to set a name other than ":0", ":1", etc would be rather handy. Thryduulf (talk) 12:28, 10 August 2024 (UTC)

  Agreed, that's a huge bugbear. It was the sixth most agreed upon community wish for 2023, and something that is also already part of the wikitext reference creator. CMD (talk) 12:39, 10 August 2024 (UTC)

  All programmers should read Falsehoods Programmers Believe About Names, and then re-read it every few years to refresh their memory. People who design database schemas should re-read it every time they start a new project. I agree that it's not a showstopper for our purposes, but it is a surprising lack of cultural sensitivity from an organization which is so into i18n.

  For me, the biggest bugbear is that there's no good way to convert a {{cite web}} into another template without basically starting from scratch. It really should be smart enough to figure out that if {{cite web}} has a "first=" field, it can safely map that into {{cite news}}'s "first=" and so on. It won't be perfect, but it'll get you most of the way there. RoySmith (talk) 12:57, 10 August 2024 (UTC)

  @Chipmunkdavis @RoySmith Visual editor follows the definition of the template parameters at Template:Cite web#TemplateData (and so on for other cite templates). I think the developers would also wish that you didn't require the name to be split into two fields; it's a chore to fill it out this way. If you think this can be changed, please edit it there. Matma Rex talk 13:58, 10 August 2024 (UTC)

  @Matma Rex you are entirely correct that VE gets its field definitions from the templates. The first part of my comment about first_name/last_name ethnocentricity applies equally well to template writers.

  But, the part about being able to convert one type of citation to another really is a VE issue. The "automatic" feature of the VE template editor is very handy, but it often can't intuit the proper type of template (that's not VE's fault) and falls back to using {{cite web}}. It would be really handy if you could say, "Please make that into {{cite news}}, and do the best job you can converting the fields". RoySmith (talk) 14:38, 10 August 2024 (UTC)

  |author= is already present in the existing template parameters, even if just as an alias of |last. Not presenting the alias in VE is a choice of VE, the buck should not just be passed to blindly following a particular table. CMD (talk) 14:56, 10 August 2024 (UTC)

  It might be controlled by the WP:TEMPLATEDATA in something like Template:Cite/doc. I think VE reads the template data to determine the parameters it displays. If a parameter is omitted or set as hidden, perhaps it is not displayed. Not 100% sure but that is probably worth checking. –Novem Linguae (talk) 15:08, 10 August 2024 (UTC)

  It is indeed in the TemplateData for each of the Cite_whatever templates -- if you go look at the source to Template:Cite_web/doc around line 1601 you'll see the field-mapping for that one. There's a description of how it all works over on mediawiki.org. DLynch (WMF) (talk) 23:08, 10 August 2024 (UTC)

  @DLynch (WMF) I've got a question for you. As noted above, VE does a good job of guessing the right template type for some sources (say, the NYTimes), and for many other sources, can't figure it out so resorts to {{cite web}}. If I understand the flow properly, the bottom layer in the stack is zotero, and if I wanted to teach VE to understand that https://www.bxtimes.com/orchard-beach-nature-center-reopens-after-2-35m-renovation-officials-hold-ribbon-cutting-event/ should be cited using {{cite news}}, zotero is where that teaching has to happen. Is that correct?

  Assuming it is, then it would be really useful to have some statistics of how often VE (I know, I should really be saying Citoid or Zotero, or something else, but I'll just keep saying VE because that's what the end user sees) gets it wrong. I'm not entirely sure how we would define "gets it wrong", but a first pass might be "VE initially calls it {{cite web}} which is later corrected to a different {{cite xxx}} variant". Some of that might require instrumentation inside VE to detect when the user abandons a constructed citation before saving it. Some of it might require analyzing revisions to the page to see when template types are corrected after the fact. But let's assume one way or another, we could build a log of incorrect categorizations.

  Then what we would do is take the full log of these reports, group them by top-level domain, and sort by frequency. If it came out that "bxtimes.com" was the most frequently domain which got mis-categorized, then it would be the highest priority for a human to go figure out how to fix and add that knowledge to the VE (Citoid? zotero?) database. After enough iterations of fixing the highest priority ones, we'd end up with a better system. If (total SWAG here) we could find the 100 top problems that accounted for 50% of the total errors, with a very small amount of human work to fix them, we could have a major win.

  Does this seem like a reasonable understanding of the problem? RoySmith (talk) 00:17, 11 August 2024 (UTC)

  It sounds like a reasonable stab at the misassignment-of-citation-templates issue.

  Caveat up front: I'm a developer, but I've never actually touched the internals of Citoid+Zotero, so I might be wrong about details here. That said, I believe you're right that the classification part happens entirely in Zotero, and further that if you want to teach Zotero about how to classify a new site there's some guidelines we have for that over on mediawiki.org. This coming from Zotero is also why we have vastly more classifications than we actually use on-wiki -- check out the mapping for that.

  It's possible that some of the incorrect template-usage you see could be at the level of those mappings, as well -- I note that the `statute` type is just hooked up to the generic `Citation` rather than to {{Cite_act}}, for instance, though that's probably far from the most common one to need.

  As for the specifics of working that list-of-sources out...

  We do have some instrumentation inside VE already that could probably be looked at to work out how often someone gets all the way to the "presented with a citation-template" step and then abandons it, which would give us an okay up-front guess at the rate where something is wrong with the generated citation. Ignoring the question of other types of failure for now, the next problem is that our VE usage-instrumentation is carefully ignorant of content for privacy reasons, so it doesn't know anything about what URL was looked up when that happened. Looking for revisions which consist of just a citation template being replaced with a different citation template sounds doable, albeit slow.

  I wonder if we could approach it another way. Assuming that Zotero has some internal logging of the translator it used when we make a request to it, or that it can be persuaded to tell Citoid this, we could perhaps add some logging for requests that fall back to the default-translator for unknown pages. That's not a perfect match for the misclassifications, but it's much easier to find. It does leave out cases where the translator exists but is getting it wrong, of course. DLynch (WMF) (talk) 01:46, 11 August 2024 (UTC)

  it doesn't know anything about what URL was looked up when that happened does it know/track what type of template it chose? If so we can possibly work out what proportion of e.g. cite-news vs cite-web generations were abandoned? I don't think, ottomh, there would be any privacy issues with that? Thryduulf (talk) 01:53, 11 August 2024 (UTC)

  Unfortunately not. All it tracks is that a citoid request happened, and then either that the "insert" button was chosen or that something was done to move away from the citoid results list. It doesn't even track what type was chosen if you go to the "manual" tab and explicitly pick one of the templates listed there.

  I do agree it seems very unlikely to be a privacy issue. I mostly mentioned that was the guiding principle to explain why the case for so many questions like this turns out to be "we never needed this actually-very-innocuous content-related data before, so we weren't collecting it". DLynch (WMF) (talk) 02:09, 11 August 2024 (UTC)

  Please post corresponding Phabricator tickets for all mentioned "bugbears". 1) Having tickets for these things and 2) making noise in them is the best way to move these fixes forward. –Novem Linguae (talk) 14:31, 10 August 2024 (UTC)

  T372202 RoySmith (talk) 15:05, 10 August 2024 (UTC)

  Reference naming: T52568 • T92432 • T245199 • T52474 • T334073 • T245199 • T215867 • T52568. Thryduulf (talk) 15:33, 10 August 2024 (UTC)

  The first two in Thryduulf's list (T52568 and T92432) look pretty useful. I've subscribed to those. –Novem Linguae (talk) 16:04, 10 August 2024 (UTC)

Wikipedia:Notability (species)

An RfC to adopt a guideline regarding the notability of species has been opened at Wikipedia talk:Notability (species)#Proposal to adopt this guideline. C F A 💬 00:06, 10 August 2024 (UTC)

Proposal: Create quizzes on Wikipedia

I’ve always been disappointed that Wikipedia doesn’t offer this feature and would love for it to be put in to Wikipedia. Since we have AI around, we can easily create quiz questions on a larger scale for the most popular articles. We could start by implementing quizzes on the main page and going from there. I understand that Wikipedia is an encyclopedia, but the question I came here to answer is that is it just an encyclopedia or is it more than an encyclopedia that includes features that are not just for encyclopedias as a general learning site. Britannica has something similar and I think it would be great not to copy everything it does, but have it as inspiration for creating quizzes. I would like to discuss if Wikipedia should have extra features that make the website more enjoyable rather than just reading and editing. I hope you will consider this suggestion. Interstellarity (talk) 21:33, 10 August 2024 (UTC)

The NY Times runs a weekly quiz, with questions about the previous week's news stories. It's kind of fun (even if I rarely score above 50%). My guess is if you pitched this to WP:SIGNPOST they'd be happy to run it. On the other hand, there's absolutely nothing stopping you from doing it in your own userspace and announcing it on WP:VP. If people like it, they'll vote with their mouse clicks.

My gut feeling is people won't be enthused about an AI-generated quiz. RoySmith (talk) 21:44, 10 August 2024 (UTC)

I'm not too on board with including quizzes and other gadgets like this, that are a pretty heavy weight to maintain (especially with having to review all the AI-generated quiz questions), while not really being encyclopedic and probably being an uncomfortable distraction for a lot of readers (including me). However, having them on the Signpost would be cool, although I don't think them being AI-generated is a good thing.
On a larger scale, I'm afraid of "feature bloat" where the core thing (here, the encyclopedia) gets buried under layers of gimmicks, ultimately making it much less convenient and not necessarily more enjoyable. Adding more for the sake of adding more isn't necessarily a good thing. Chaotic Enby (talk · contribs) 22:43, 10 August 2024 (UTC)

The idea of quizzes was discussed in June 2022 and by you in March 2022. As I said in those discussions, anyone should feel free to start quizzes on a project page to establish a track record of being able to produce them regularly, and to figure out what audience exists for this feature. isaacl (talk) 04:03, 11 August 2024 (UTC)

I don't get why we need things like extensions and AI to run quizzes. Quizzes existed long before Mediawiki and AI. Just take a couple of minutes to ask a few questions each day/week/month in your user space and advertise it on one of the village pumps and/or Signpost. If the feature is popular then it can be formalised to the main page etc. Nothing will happen unless someone (most likely you) volunteers to do it. Phil Bridger (talk) 08:40, 11 August 2024 (UTC)

Miscellaneous

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)

I've done this now, splitting off Porandla, Jagtial district. If anyone can figure out what the page was about in its second iteration, that may need another split. CMD (talk) 00:44, 2 August 2024 (UTC)

CMD: thank you for sorting out these villages! -- GreenC 05:48, 9 August 2024 (UTC)

How do you determine the "size" of a list (or merging / splitting purposes)?

Ok, this may be a silly and redundant question. So, WP:SIZERULE gives good guidelines for when articles should be trimmed or merged. However, WP:SIZE states that readable prose size only includes "the amount of viewable text in the main sections of the article, not including tables, lists, or footer sections." For the purpose of merging lists, and with the removal of the kb limits (which I had previously used to judge list size) on WP:SIZE how do you determine the size of a list (as related to existing guidelines stated on WP:SIZERULE) if you wish to merge or split a page? Historyday01 (talk) 13:17, 5 August 2024 (UTC)

The kb limits on WP:SIZE also applied only to readable prose, nothing has changed in that respect. List splits likely come down to editorial judgement, what best helps a reader. Some lists do still end up breaking other limits like WP:PEIS, but that's not common. CMD (talk) 01:25, 6 August 2024 (UTC)

Hmm, ok. I suppose that somewhat answers my question. What about list mergers? That also comes down to editorial judgment as well? Historyday01 (talk) 12:35, 7 August 2024 (UTC)

It does, keeping in mind WP:NLIST. CMD (talk) 12:51, 7 August 2024 (UTC)

Ok, thanks. I'll definitely keep WP:NLIST in mind. I will say that I referred this discussion to another user on here as well in reference to a possible split of the List of black animated characters page. Historyday01 (talk) 15:16, 9 August 2024 (UTC)

Low standards for references on the English Wikipedia

Why does the English Wikipedia allow the creation of articles without reliable sources? For example, if you look at the references for "El amor de mi bohío," you will find databases, blogs and other wikis. The same with Mira que eres linda, the sources are blogspot and Brito EcuRed. That's why many editors whose articles are deleted on the Spanish Wikipedia come to create them here, because the requirements for reliable sources are minimal. I don't think this does any good for Wikipedia's reputation. KokuyoKoychi (talk) 22:25, 5 August 2024 (UTC)

@KokuyoKoychi, the requirements aren't minimal but enforcement is difficult. Hundreds (or more) articles are created every day. There aren't enough editors to screen each one (although the New Page Patrol makes a valiant effort at doing so). Schazjmd (talk) 23:41, 5 August 2024 (UTC)

Proposals to increase the requirements for sourcing in new articles have so far failed to receive a consensus. Donald Albury 00:09, 6 August 2024 (UTC)

Reminder! Vote closing soon to fill vacancies of the first U4C

You can find this message translated into additional languages on Meta-wiki. Please help translate to other languages.

Dear all,

The voting period for the Universal Code of Conduct Coordinating Committee (U4C) is closing soon. It is open through 10 August 2024. Read the information on the voting page on Meta-wiki to learn more about voting and voter eligibility. If you are eligible to vote and have not voted in this special election, it is important that you vote now.

Why should you vote? The U4C is a global group dedicated to providing an equitable and consistent implementation of the UCoC. Community input into the committee membership is critical to the success of the UCoC.

Please share this message with members of your community so they can participate as well.

In cooperation with the U4C,

-- Keegan (WMF) (talk) 15:29, 6 August 2024 (UTC)

Wayback Machine collection search

Normally it is not possible to full-text search through the Wayback Machine. However, they do make available certain collections for full-text search, such as the US Government docs collection has 403 million pages. The list of collections currently available for searching:

https://web-beta.archive.org/collection-search

This is a beta service. There is currently a bug in the interface sometimes it redirects to the home page. If this happens, go to a collection search that is working (such as the US govt docs link above) and use the pull-down menu to navigate the collections. You can also search via URL such as:

https://web-beta.archive.org/pdf/search/wikipedia

..will search the "pdf" collection (1,317,870,629 PDF files) on the word "wikipedia"

-- GreenC 05:04, 9 August 2024 (UTC)

Is there a place to discuss all design choices for Wikipedia?

Is there a place to discuss all things related to visual aspects of Wikipedia? Icons, logo, screen layout, typography?Blue Pumpkin Pie (talk) 17:28, 9 August 2024 (UTC)

WP:VPT is a good place for general technical questions and bug reports. Got anything specific in mind? –Novem Linguae (talk) 21:07, 9 August 2024 (UTC)

The technical village pump is a good place to discuss the implementation details of a design. However to discuss the design itself, this village pump page would be more suitable. isaacl (talk) 21:48, 9 August 2024 (UTC)

Ban in Azerbaijani Wikipedia

Hello, I would like to complain about the administrators of the Azerbaijani Wikipedia. The fact is that when I added az:Yenisey (Yenisei) in parentheses to the article its name in the Yenisei language in addition to the Russian term (and of course wrote the source from the 1899 book), I was banned by the Nemoralis administrator. To the question “what Wikipedia rule did I break,” he answered in an arrogant manner, “your account will not be unblocked.” I wrote this message here because I don’t know where to write. I also wrote the message to the Azerbaijani section, but Azerbaijani administrators support each other since for several years in a row these are basically the same people. Please help me in this situation. At least express your opinion, please.

To make it clearer, I write the difference between the articles:

Before: Yenisey (rus. Енисе́й), (evenk Ионесси "böyük su", xak. Ким, tıva Улуг-Хем "böyük çay", və Ene-Say (Ana-çay), nen. Енся’ ям’

After: Yenisey (rus. Енисе́й), (evenk Ионесси "böyük su", xak. Ким, tıva Улуг-Хем "böyük çay", və Ene-Say (Ana-çay), nen. Енся’ ям’, q.türk 𐰚𐰢 Kəm)

Thank you; Sebirkhan (talk) 19:21, 9 August 2024 (UTC)

Normally the standard reply is enwiki has no powers over azwiki (and azwiki over enwiki). But you could try to find an azwiki admin who is active on enwiki. You could ask them about it here, in a neutral ground, maybe also try to find a neutral person on enwiki not from azwiki, to help moderate the dispute. It seems extreme to ban someone over what you describe so either they are bad amins or there is more to the story. -- GreenC 19:35, 9 August 2024 (UTC)

"bad admins" is surprisingly plausible. There are four azwiki admins indefinitely blocked here (Solavirum, Nemoralis, Wertuose, Atakhanli), including the admin who blocked Sebirkhan on azwiki. But Google Translate of the azwiki discussion linked to paints a different picture than an admin cabal supporting each other. * Pppery * _{it has begun...} 19:59, 9 August 2024 (UTC)

Indeed, this editor appears to have continuously ignored advice regarding using old sources for names in article leads and received a one-month block in response. I don't see any indication of foul play, and I say that as the admin who blocked 2/4 of the az.wiki admins listed above from en.wiki. _signed, Rosguill ^talk 20:22, 9 August 2024 (UTC)

However, I do not understand why I cannot add the name of the Yenisei River in the Yenisei language in brackets, while the name of this river in other languages ​​is added at the beginning (Maybe then we should delete all the names and leave only the official one - Russian). Where should I add this name if not in this Wikipedia article? I consider it important for preserving history. After all, I did not come up with this name. But the administrator deleted it and blocked my account and my IP Sebirkhan (talk) 20:35, 9 August 2024 (UTC)

As the admin of AzViki, I can say that the user presents the situation differently. The user constantly adds words in the old Azerbaijani language or the old Turkish language to the beginning of the articles, changes the names of the articles. We have repeatedly warned him to use only modern Azerbaijani words, not archaic words. As a result, he was blocked at the very end. And now he allegedly says that he added the word in Yenisei language to the beginning of the article, while he added the version in ancient Turkic language, which is unrelated to the topic. However, the Yenisei language has nothing to do with the ancient Turkic language. And the user does such things many times. The user even once wrote that the word "shogun" is a Turkish word in the Shogun article on AzWiki. Cosmic Bard ^utora! 20:32, 9 August 2024 (UTC)

It is not true because, A regular azwiki user does not have the technical ability to change article titles. Also I do not use Turkish language in Azerbaijani section.

Everything you write is far-fetched, because I have never written in my life that shogun is a Turkish word or comes from a Turkish word. However, thanks to me, the administrators eventually changed the name of the page Syoqun to Şoqun (which is correct from the point of view of the Azerbaijani language and Japanese language, and also others) and this is a fact if you look at the history of the article. Sebirkhan (talk) 20:41, 9 August 2024 (UTC)

In the edit Cosmic Bard identifies, you added [[Qədim_türk_dili|Əski türkcə]]: 𐱁𐰭𐰆𐰣, /şöŋün/, which would indeed suggest that the origin of shogun is Old Turkic. _signed, Rosguill ^talk 20:52, 9 August 2024 (UTC)

You are right, however (even though this is a word written in dictionaries), I thereby pointed out the inconsistency of using the Russian form Syoqun in the Azerbaijani language, in the end we came to a compromise Şoqun. I was not banned for this reason. The azwiki administrator is simply trying to direct the conversation in a different direction. While not banned for this, specifically I received a message about blocking after changing the Yenisei page and the administrator canceled my edits. Sebirkhan (talk) 20:58, 9 August 2024 (UTC)

also it was in 2019 Sebirkhan (talk) 21:04, 9 August 2024 (UTC)

You are not blocked just because of the Yenisei River article. Everyone can do something wrong. A user cannot be blocked for one edit. You are blocked because you keep doing things like this. Before that, you wrote the Dnepr River as "Ozü River" in a article, and I warned you about this, that this river is not called Özü River in any source in the modern Azerbaijani language. I will not comment further on this issue here, because it is not EnViki's issue, but AzViki's issue. Cosmic Bard ^utora! 21:08, 9 August 2024 (UTC)

Why do use word Dnepr while the official name of this river is Dnipro? Sebirkhan (talk) 21:11, 9 August 2024 (UTC)

References