This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.
Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).
Policy
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 here02:27, 22 June 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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 here02:50, 23 June 2024 (UTC)[reply]
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)[reply]
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)[reply]
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/tracker7804j (talk) 13:24, 24 June 2024 (UTC)[reply]
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 project7804j (talk) 13:27, 24 June 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
"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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Initially, I also thought that the AfC requirement for paid editors was a request and not a requirement. However, @Seraphimbladeraised 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).
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)[reply]
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 notping on reply) Primefac (talk) 22:05, 22 June 2024 (UTC)[reply]
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)[reply]
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.
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
@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 here02:47, 24 June 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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 here09:59, 28 July 2024 (UTC)[reply]
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)[reply]
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 here10:01, 31 July 2024 (UTC)[reply]
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>talk19:19, 23 June 2024 (UTC)[reply]
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)[reply]
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:
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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].
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)[reply]
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)[reply]
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 here02:53, 26 June 2024 (UTC)[reply]
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.
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
@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 here09:50, 29 June 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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 here08:13, 2 July 2024 (UTC)[reply]
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)[reply]
"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)[reply]
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)[reply]
@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 here14:04, 9 July 2024 (UTC)[reply]
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 here14:05, 9 July 2024 (UTC)[reply]
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)[reply]
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.
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
This is not a formal proposal, but may be a precursor to one. WP:NAC is generally cited as the roadmap for non-admin closures. It cautions non-admins against closing potentially contentious discussions, but does not prohibit them. It is also only an essay; but the relevant policy pages that I skimmed do not appear to make distinctions between admin and non-admin closures.
We have a good few experienced non-admin closers. Their decisions are, best as I can tell, not inferior to admin ones. However, based on the caution against contentious closures by non-admins in WP:NAC, I believe they are challenged far more frequently, and consequently their closures often end up costing, rather than saving, the community time (if this comes to a formal proposal, I will do the archival research needed to show this).
I'd like thoughts on a) whether we should prohibit non-admin closures in contentious topics, as a means of saving community time on close reviews; and b) what the best way to do this would be, given that WP:NAC does not currently carry formal weight. Regards, Vanamonde93 (talk) 21:57, 18 July 2024 (UTC)[reply]
First, there are levels of contentiousness, with ARBPIA at one end and ARBBLP at the other. While non-admin closures may be more likely to be challenged for the former to the point of costing community time, I am certain that is not true of the latter.
Second, I am certain this does not apply to request moves. As a NAC, I close a lot of RM's, and as expected given the volume a number are challenged. I haven't found it any more likely that those I close within contentious topics are challenged than those outside, and given the number closed to the number contested I am certain that these closures have saved community time. BilledMammal (talk) 22:11, 18 July 2024 (UTC)[reply]
I generally think we should be offloading bureaucratic workload from admins, not piling more on. If there are specific subject areas that become magnets for poor NACs, existing processes are sufficient to curtail those without instruction creep. VQuakr (talk) 22:17, 18 July 2024 (UTC)[reply]
As a regular NAC, I'm not sure NACs are challenged more often than admin closures; even if they were, close reviews are relatively rare (for example, as of December 2023, there was an average of 2 close reviews per month as discussed here). More importantly, we shouldn't be taking editor's powers away just because some editors spuriously choose to challenge closures solely on the grounds that they were done by non-admins. As for NAC, I read that just as you do—as a word of caution, not as a command. voorts (talk/contributions) 22:35, 18 July 2024 (UTC)[reply]
Thinking out loud, but if NACs are costing the community time in contentious areas, I think it would be better to have a new "userright" (for want of a better term) called "discussion closer" that gives users who have it no extra tools but the same weight in closing discussions as an admin has. Such a right would need to be conferred in a process only slightly heavier weight than file mover - I'm thinking something like request open 2-5 days, consensus in a discussion that has at least 5 supports from admins and/or discussion closers (no consensus after 5 days = not granted). We would then recommend that discussions that are or which are likely to be contentious be closed by admins or discussion closers.
NAC would be explicitly not a permissible ground on which to challenge a closure by a discussion closer - if that's the only reason given the challenge would be speedily declined, if it was accompanied by other reasons then the portion of the statement relating to being an NAC would be struck.
Actually, even without the discussion closer status, speedily declining any review request where NAC is the only ground would be a good thing. Thryduulf (talk) 22:44, 18 July 2024 (UTC)[reply]
speedily declining any review request where NAC is the only ground would be a good thing – This, 100%. As Vanamonde noted, there's no actual policy or guideline that says we give admin closures more weight. Indeed, per WP:NOBIGDEAL and WP:ANOT, being an admin doesn't give anyone special authority over content decisions or determing consensus. To the extent that people read WP:NAC as implying that admin closes are better than NACs just because the closers have a mop, it ought to be clarified. I'm against the new "userright" because I don't like the idea that some editors determinations of consensus are weightier than others. voorts (talk/contributions) 22:55, 18 July 2024 (UTC)[reply]
@Voorts: I agree with you about the admin-non-admin distinction, but in general, there most certainly are editors who shouldn't be doing NACs. We need to allow genuinely bad closures to be reversed: we also don't want the closer's status as a non-admin to become a distraction. I'm open to other ideas on how to achieve that. Vanamonde93 (talk) 01:04, 19 July 2024 (UTC)[reply]
In such cases, the review request needs to say "this summary does not accurately/fully represent the outcome of the discussion" rather than saying "the wrong kind of person wrote this". WhatamIdoing (talk) 21:41, 19 July 2024 (UTC)[reply]
We do allow genuinely bad closures to be reversed through close reviews. If the close is so egregious, the close review will likely be a snow overturn. voorts (talk/contributions) 23:31, 26 July 2024 (UTC)[reply]
And, while this is not a great outcome, it's also not something we should fear. People learn by making mistakes, at least to the extent that they're willing to learn. Some people are resistant to learning from their mistakes; they are the ones to fear. RoySmith(talk)23:58, 26 July 2024 (UTC)[reply]
I've suggested a flag like this in the past, and I still think it's a good idea. We don't even need to say it gives "the same weight that an admin has"; we could just say that closing especially contentious or WP:CTOP discussions requires (or recommends) the discussioncloser right and bundle it into the sysop flag in addition to making it available at WP:RFPERM. The WordsmithTalk to me18:46, 1 August 2024 (UTC)[reply]
I think making it clear that only very experienced closers should close complicated or contentious discussions is sufficient. Relatedly, one of the things I look for at RFA is difficult closes the candidate has made. ScottishFinnishRadish (talk) 23:35, 18 July 2024 (UTC)[reply]
I think the type of discussion being closed plays a substantial role. For RMs and some RfCs in CTs I don't think NACs are per se a problem, but at AfD, where non-admins literally cannot close in favor of the most common outcome, we really do need to retain the current guidance. AfD NACs can become experienced at closing debates that have a relatively clear keep or ATD outcome, but they are perpetually lacking in the skill of finding consensus for deletion. A non-delete outcome is also necessarily predetermined when a NAC decides to close an AfD, which means in close cases where either a keep or a delete outcome would be within discretion they will always go for keep. And that's on top of the already strong selection bias towards inclusionism among current NACs, which would skew things even further. JoelleJay (talk) 05:11, 26 July 2024 (UTC)[reply]
they are perpetually lacking in the skill of finding consensus for deletion I think that's a bit unfair to NACs. After all, we can't close as delete, so how would you know if we can't find consensus for it. In my experience, when I see a discussion where the discussion could reasonably be closed as delete, I add it to my watchlist, skip it, and when it's closed I can see if I agree with the admin closure. voorts (talk/contributions) 13:32, 26 July 2024 (UTC)[reply]
NACs can be plenty competent at assessing discussions, but as they are not supposed to close anything where deletion would be remotely reasonable they can't develop the practical skills needed for both reading nuanced consensus and communicating that consensus. JoelleJay (talk) 22:06, 26 July 2024 (UTC)[reply]
I don't see why assessing/communicating that consensus is any different than assessing/communicating any other form of consensus. Plus, most AfDs appear to be closed without a written rationale anyways. voorts (talk/contributions) 22:09, 26 July 2024 (UTC)[reply]
But the point is that the AfDs closed by NACs should, by definition, not need a close summary because the outcome is uncontroversial. So if NACs have been following the current guidance, they could not have developed experience in closing AfDs where deletion is on the table, and especially not the ones where they would need to provide a close summary explaining why they didn't see consensus to delete. They just literally cannot cultivate that skillset. JoelleJay (talk) 22:44, 26 July 2024 (UTC)[reply]
I disagree. In an AFD with one or two good rationals for delete (e.g. "the sources do not meet GNG") but there are (many) more editors who say that that there are sufficient sources or who come after the first delete comments, I think a close summary is helpful. - Enos733 (talk) 22:50, 26 July 2024 (UTC)[reply]
I agree and I wish close summaries (and relisting comments) were a lot more common, but I think it's still true that they're not expected for uncontroversial outcomes. JoelleJay (talk) 23:00, 26 July 2024 (UTC)[reply]
As a somewhat irregular NAC-er focussed on AfDs, I can appreciate where this is coming from - although my (purely anecdotal) observations of DRV would say this is not, relatively speaking, a problem in that sphere. I think the question is less about status (admin or not) and rather experience; I wouldn't necessarily be opposed to setting some thresholds (edit count, participation etc) for NAC on CTOPs, but I don't see a strong enough case yet for exclusion. Regards,--Goldsztajn (talk) 23:29, 18 July 2024 (UTC)[reply]
Like anything else on the wiki, the qualification to do most things is that you know how to do it, and having a mop is no promise that you do. I'm sure most of the regulars at WP:AfD, admin or not, know the details of our notability guidelines better than I do; it's absurd to suggest that I'm better qualified to close a complicated AfD just because 19 years ago, 27 people thought I'd be an OK admin. Our current NAC mindset is an anachronism and should be done away with. RoySmith(talk)23:54, 18 July 2024 (UTC)[reply]
We should root out and destroy every suggestion that discussion closure is an admin task. It makes sense for the admin noticeboards, and is vestigial in most other places. I like Thryduulf's user right suggestion (I know others have suggested something similar in the past) and speedy close suggestion, though I've rarely seen a situation where NAC is the only objection. We should guide newer closers to less controversial discussions, and we should explicitly indicate that experience multiple discussions is necessary for closing contentious, major discussions. We should still allow for challenges based (in part) on lack of experience, it's just that many non-admin closers are much more experienced than almost all admins. Firefangledfeathers (talk / contribs) 01:14, 19 July 2024 (UTC)[reply]
This isn't any different from any other process. I spend a lot of time at DYK. For all the chaos that goes on there, there's an effective culture of new people being groomed to take on greater responsibility. You start out by doing your obligatory initial reviews and move on to more complicated things like building prep sets. People inevitably make mistakes, the mistakes get fixed, experience is gained, and the cycle continues. WP:GA works the same way. And WP:FA. And dozens of other nooks and crannies of the wiki where just plain editors sans mop keep everything going. As it should be. When somebody's been working in an area for a long time, they become an expert at it. The idea that some random admin who's never worked in that area could possibly do a better job is absurd. RoySmith(talk)01:37, 19 July 2024 (UTC)[reply]
I agree with Roy.
@Firefangledfeathers, even a "major" discussion on an officially Contentious Topic™ can sometimes be easy and uncontentious to summarize. The ideal result of an RFC is that everyone already knows what the outcome is. A given participant might be inclined to privately summarize that outcome as "The community is a bunch of jerks who'll be the first up against the wall when the revolution comes", but even the most passionate editor on the "losing" side can often recognize when a consensus has been reached for the "wrong" result. In such cases, we don't necessarily need a highly experienced editor to state the obvious. WhatamIdoing (talk) 21:53, 19 July 2024 (UTC)[reply]
Outside of deletion discussions and other outcomes that need an admin to carry out (where it absolutely does make sense), I view invoking BADNAC as essentially scope creep. You don't need to be an admin to close RfCs, at all. But I don't think it's fair to dismiss people who bring it up as baseless wikilawyers either. Usually what they're trying to allude to is that contentious discussions are hard to close and therefore that the community expects someone with experience in making successful closes to do it. This is a good and widely agreed upon principle, but it's not written down with a handy shortcut, so BADNAC gets invoked instead. If we articulate that broader principle somewhere, I think we'll see BADNAC cited less often. – Joe (talk) 07:32, 19 July 2024 (UTC)[reply]
Outside of deletion discussions and other outcomes that need an admin to carry out (where it absolutely does make sense). There's no fundamental reason why a non-admin can't close an AfD as "delete" and then find an admin to actually push the button. In fact, it looks like {{Db-xfd}} covers exactly this use case. This is similar to how non-admin SPI clerks can determine that an account is a sock and should be blocked and then have to go find an admin to do it for them. RoySmith(talk)14:57, 19 July 2024 (UTC)[reply]
No fundamental reason, no, but why create the extra work and complexity when we have no shortage of admins willing to close AfDs? Any process that requires admin intervention should be left to admins unless and until it becomes obvious they need the extra help (as with SPI), as matter of efficiency if nothing else. – Joe (talk) 15:04, 19 July 2024 (UTC)[reply]
I think that's over-broad. I think you shouldn't have to be a sysop to close an RfC that's about making a change to a fully-protected page, for example.—S MarshallT/C18:11, 19 July 2024 (UTC)[reply]
Pressing delete from a closed AfD feels like a situation where an admin would need to verify consensus in the first place and so now you've spent the time of two editors where one could have done. Beyond that, I am pretty staunchly opposed to admin close creep in places like RfCs. When I was a regular at AfD, I found non-admin work to be far less "right" than with RfCs; I think it attracts a different kind of non-admin. Best, Barkeep49 (talk) 04:02, 20 July 2024 (UTC)[reply]
@Barkeep49 your point about the button-pusher needing to verify the result is valid, and indeed I've made similar arguments myself. But a good close can make that job a lot easier. A good close won't just say "Consensus to delete". It'll summarize the main points made on both sides, list the minority opinions, and talk about which arguments were rejected by other discussants (or by the closer) and for what reasons. With a good analysis like that, you can get your head around the discussion without having to read every word. And, yes, the button-pusher is ultimately responsible for their actions, and I assume all responsible button-pushers will dig as far as they feel is necessary to validate the summary. RoySmith(talk)15:55, 21 July 2024 (UTC)[reply]
Most AfDs don't require a long closing statement or often don't require any closing statement. This lack of need for closing statements is a way that AfD is different from RfCs. This also doesn't change my point - it's not a good use of editor time to close something which will require substantial re-verification to implement (outside of processes like DYK which are designed to have these multiple levels of checking). Best, Barkeep49 (talk) 17:15, 21 July 2024 (UTC)[reply]
It's true that "Consensus to delete" is an adequate close for many AfDs. I would expect somebody to write the kind of detailed analysis I outlined above only for discussions that warranted it due to their complexity. RoySmith(talk)13:35, 22 July 2024 (UTC)[reply]
now you've spent the time of two editors where one could have done is true, but we don't stop people from wasting their own time. The admin would have to spend time to process the deletion regardless of whether it was NAC'd first or not. So in the NAC scenario, the only person who's time is arguably wasted is the NAC who volunteered their time to do this, and if that's how people want to spend their time, I don't see why policy should prohibit them from doing so. Arguably, two sets of eyes is a benefit anyway, so it's not necessarily wasted time at all. Levivich (talk) 23:51, 21 July 2024 (UTC)[reply]
I would distinguish between a discussion close that's a content decision, and one that's a conduct or technical decision. There are philosophical and principled reasons why we absolutely must not give sysops special authority to make content decisions. Conduct decisions in CT areas, on the other hand, are best reserved for sysops even where an unelected person could make them.—S MarshallT/C07:58, 19 July 2024 (UTC)[reply]
There are non-admins (like S Marshall) who would be in the top 10% of admins regarding closures (even if I disagree with one) if they were one. And vice versa. It's just that the odds and optics are better when it's an admin. I think that the current guidance on this is about right. North8000 (talk) 15:46, 19 July 2024 (UTC)[reply]
There a many inherent reasons for people not to close long, complicated, or contentious discussions, so I see the lessening of the pool of willing closers as throwing the baby out with the bathwater, so to speak. Alanscottwalker (talk) 16:06, 19 July 2024 (UTC)[reply]
It cautions non-admins against closing potentially contentious discussions, but does not prohibit them. WP:NAC should do more than caution, but still should not prohibit. It should advise against NAC closes of contentious discussions where consensus is not abundantly clear.
We have a good few experienced non-admin closers. Absolutely. Adminship is not a requirement for being a good closer, but being a good closer is something tested at RfA, or at least, not being a bad closer and knowing your own strengths is tested at RfA.
Some challenges to NAC closes may be unfair, but this depends on perspective. It is a fact that many ordinary Wikipedians do not consider a non admin close of a contentious discussion to be a satisfactory close. This is not a reason to slap down ordinary wikipedians, but for non admins engaging in advances functions to do it more conservatively. A good skillful close should make a contentious-looking discussion look no longer contentious.
If a non admin's close of a discussion produces another, longer, more contentious discussion, then their close was not a net positive contribution, and they should not do such closes.
We should advise non admins to not close contentious discussions unless they are very confident that they will explain their close to the satisfaction of all the participants. Alternatively put: If an admin is confident that they can close a discussion to the satisfaction of all participants, then they should be encouraged to do so. Despite being very confident, non admins are allowed to be wrong, sometimes. Don't make a habit of it. If a challenge to their close surprises them in any way, then strongly consider reverting the close and listing it at Wikipedia:Closure requests. Then, sit back and see if someone else closes it the same way.
In any discussion, the closer should be the least important person, not the most important person.
All of the above should apply equally to XfDs, RM, and RfCs. It should apply moreso to closes at AN, DRV, MRV and XRV.
Spurious challenges should not be feared. Spurious challenges are characterised by a SNOW endorse at review.
I don't think a special user-right for closing is warranted. If credentials are wanted, I suggest a category of barnstars for good closes.
If a non admin's close of a discussion produces another, longer, more contentious discussion, then their close was not a net positive contribution, and they should not do such closes. Sometimes admin closes are bad and result in additional contentious discussions. Admins aren't magically better at analytical thinking.
We should advise non admins to not close contentious discussions unless they are very confident that they will explain their close to the satisfaction of all the participants. I agree. The guidance should be "to each according to his ability". But, per my first bullet above, the same should be said for admins. If an admin doesn't feel confident that they have the chops to close a particular discussion, they shouldn't feel like their status gives them license to bite off more than they can chew.
Don't make a habit of it. If a challenge to their close surprises them in any way, then strongly consider reverting the close and listing it at Wikipedia:Closure requests. Unless a close is clearly vandalism or extremely incoherent, we shouldn't be reverting closes absent a close review. Otherwise, we invite random editors to revert closes because they think it's inadequate, leading to even more bickering and bad feelings.
I agree that Admins aren't magically better at analytical thinking, but it is a trait that we select for at RFA, so a random admin will usually do better in this area than a random non-admin. WhatamIdoing (talk) 02:58, 28 July 2024 (UTC)[reply]
Amending BADNAC?
I want to be very clear that when I opened this it wasn't because I felt some NACs were inappropriate, but because I wanted to avoid spurious challenges, or challenges where non-admin status was muddying the waters. It's fairly clear that there is strong support for not limiting NACs; so what do folks think of an alternative approach to address the problem I mention, and making BADNAC contingent strictly on experience rather than admin status: that is, essentially striking BADNAC#2, and perhaps strengthening the reference to experience in BADNAC#3? Vanamonde93 (talk) 02:45, 20 July 2024 (UTC)[reply]
I am in favor of striking #2. I think #3 could be struck too; if somebody inexperienced is really good at evaluating consensus and has read Wikipedia's PAGs, I don't see why the close ought to be overturned on those grounds alone. But, I can live with #3 as it's currently if there's consensus that that kind of limitation should be in BADNAC. Also, I've notified WT:NAC of this discussion. voorts (talk/contributions) 03:04, 20 July 2024 (UTC)[reply]
The likelihood that someone using an account with few edits will do a passable job on anything except the most obvious cases is low. Also, it gives anyone on the "losing" side an opportunity to suggest that the newbie is a bad-hand sock, which is more drama that we would like to avoid.
BTW, "experienced editor" appears to be a label that there are different views about. @Levivich and I were chatting about this at Wikipedia talk:Wikipedians#Higher volume: Can someone who has "only" been editing for a year (the median account activity is one day), with "only" 500 edits total (more than 99.25% of accounts that have ever made a first edit), averaging "only" one edit per day during the last month (less than 10% of currently active accounts), be truly considered "an experienced editor"? If you'd like to provide a third opinion (or fourth, or fifth), please share your idea of what the minimum standard for "an experienced editor" could be over there. WhatamIdoing (talk) 05:14, 20 July 2024 (UTC)[reply]
It sounds like we need to temper our expectations regarding how we treat newcomers on Wikipedia, instead of limiting them because others might have bad faith objections.
As for a rare but pertinent counterexample, I noticed Chrhns's close of an RFC within their first 50 edits. It was well reasoned, not "exceptionally obvious" and pretty much the exact close I would make too. I did end up suggesting they edit other parts of the Wiki first, simply because I know how contentious challenges can get. But should they (or editors like them but with 500 more edits) be restricted from one part of the encyclopedia just because they read the rules before they start editing?
I think it's far more important that close challenges cite an actual policy being broken instead of just BADNAC. If a close is flawed, it will be flawed on multiple grounds. Soni (talk) 11:23, 20 July 2024 (UTC)[reply]
Agree in general, CTs excepted, non EC editors cannot close or even participate in internal project discussions. Otherwise I don't object to NACs in principle, if they are messed up, as some will be, we have the procedures to deal with that. Learning by doing is not a bad thing. Selfstudier (talk) 11:30, 20 July 2024 (UTC)[reply]
Your observation that they get challenged more often could be right and a reason to advise non-admin to be careful (thus keeping it included as advice at NAC) without doing the wrong thing of making that advise a prohibition, which is what people are objecting to here. I think some data more than than the philosophical discussion above could be useful in making this kind of decision. Best, Barkeep49 (talk) 04:04, 20 July 2024 (UTC)[reply]
I will attempt to compile data in a few days. I think the problem exists regardless of frequency, however. A close challenge in which the closer's admin/non-admin status has become a factor is, I think, a priori a bad use of the community's time. Evaluations of closures need to focus on other things. Vanamonde93 (talk) 01:33, 21 July 2024 (UTC)[reply]
I oppose simply striking #2 ("The outcome is a close call (especially where there are several valid outcomes) or likely to be controversial") but suggest instead rewording it. As it reads, I don't think it is very good. I suggest, it get ideas started,
"The discussion is contentious and your close is likely to be controversial."
I think it is a good idea to put the judgement of the appropriateness of the NAC in the control of the NAC-er, and point to "the close" as the thing that will be judged. (The number of valid outcomes parenthetical is wordy verbosity)
"#3 The non-admin has little or no experience editing Wikipedia generally or has little or no previous participation in discussions." is good and important. It doesn't require touching. It is important for newbies. To make it easier for newbies to understand, I would suggest closers should have one year experience editing Wikipedia, and 500 edits in projectspace, and 100 AfDs participated before closing AfDs.
Critique or criticise the close, not the closer, absolutely yes, start there. Where the same closer repeated has their closes criticised, maybe there is a pattern of evidence to suggest a change in behaviour.
NAC-ers should be advised to be cautious in closing, not prohibited in closing. NAC-ers should be advised on how the can best help. On a quick review of old-admin closes, I think you'll find they tend to be terse. A newcomer may think that a good close is a terse close. SmokeyJoe (talk) 00:50, 22 July 2024 (UTC)[reply]
nobody can ever know in advance if their close will be controversial? Nonsense. Wrong. If you can't tell that the discussion is contested, with heated participants, and that your close does not address their positions, then you should not be closing. SomeoneTM getting upset over something silly is life, not controversy. SmokeyJoe (talk) 00:45, 22 July 2024 (UTC)[reply]
I think this is the better path. I'd oppose striking #2 entirely, but I think we can make some more room in it for places where NACs are fine by modifying that first clause which seems to be the more objectionable one. I think a small improvement would be The discussion is contentious, (especially if it falls within a Contentious Topic), and your close is likely to be controversial. While it is true that nobody can know for sure if the close will be controversial (occasionally there's an editor who just can't let go), we're only assessing the likelihood which is usually common sense. A high-profile RFC over a controversial WP:ARBPIA issue or certain parts of the MOS, for example, have a high likelihood of being controversial while a merge discussion about insects where basically everyone is on the same page is not. If a closer is unable to see the difference, they probably don't have the judgement to assess consensus anyway. The WordsmithTalk to me18:37, 1 August 2024 (UTC)[reply]
I am in favor of striking #2 and strengthening the reference to experience in #3. I think experience, not the admin bit, is the strongest predictor of good closes. Levivich (talk) 23:56, 21 July 2024 (UTC)[reply]
As I see it, BADNAC serves a couple of purposes. Preventing bad quality closes by telling editors when they might not be appropriate before they attempt to close. Providing the outcome of a close a degree of "authority" against challenges from without or within by setting some minimum standards and allowing closes procedurally to be set aside regardless content. I see the second as being less important than the quality of the close but in terms of optics, if the DAILYMAIL close was made by a 2 day account it would not have had the same weight. Therefore I do see some value in retaining a version of the current #2 somehere in BADNAC which sets a higher bar in terms of required experience for something controversial or complex than a simple snowclose. In terms of how that experience is defined, it should be related to actually closing discussions, not just general editing, and admin status should not be relevant. Scribolt (talk) 08:26, 22 July 2024 (UTC)[reply]
Just throwing this out there: there should be some sort of statement that BADNAC is not itself a grounds to challenge a close, and that challengers should focus on the assessment of consensus, not who assessed it. voorts (talk/contributions) 23:34, 26 July 2024 (UTC)[reply]
I agree with this suggestion.
That section currently ends with ...or could result in a request to redo the process at Wikipedia:Deletion review, and a footnote saying Discuss with the closing editor first before starting a deletion review. We could change it to say:
...or could result in a request to redo the process at Wikipedia:Deletion review. Discuss with the closing editor first before starting a deletion review. If you need to pursue deletion review, your explanation should focus on content. Reviews that only complain that the discussion was summarized by a non-admin, without identifying at least one substantive error in the result, can be removed without warning by any editor.WhatamIdoing (talk) 03:07, 28 July 2024 (UTC)[reply]
I'd oppose at least the last sentence of this. DRV already comes down like a ton of bricks on arguments based solely on the lack of admin privileges, and nominations based solely on that are rare enough that I can't remember the last time it happened. Advising early closes there is already dangerous, since DRVs are themselves overturned so rarely that it's only barely inaccurate to say "it never happens", and so it's important that it's gotten right the first time; simply reverting nominations is even worse, and seems very likely to me to raise the heat in what we try very hard to keep a drama-free zone. —Cryptic03:32, 28 July 2024 (UTC)[reply]
"DRV already comes down like a ton of bricks on arguments based solely on the lack of admin privileges"... so you don't think we should warn folks not to make "arguments based solely on the lack of admin privileges"? WhatamIdoing (talk) 04:08, 31 July 2024 (UTC)[reply]
I mostly object to the rest of the sentence, about removing requests. DRV doesn't even speedy close nominations consisting mostly or entirely of accusations of bias or other personal attacks anymore (despite its own instructions), let alone just blank them. I've got no problem with your suggested text up to and including the WP:FOC link; maybe add something to the effect of ", not just complain that the discussion was summarized by a non-admin." to the end. —Cryptic04:21, 31 July 2024 (UTC)[reply]
I wasn't just speaking to deletion discussions, but also using BADNAC solely as a means to challenge an RfC closure, for example, so I think we need some broader proposed language. Also, the last sentence of BADNAC is odd because it purports to apply only to "inappropriate early closures of deletion debates" (emphasis added), which doesn't really have much to do with the rest of BADNAC. voorts (talk/contributions) 06:16, 28 July 2024 (UTC)[reply]
I think the issue, if there is one, is with bad closes, not specifically with bad non-admin closes. Yes, there is a pretty strong correlation between being an admin and being a good closer, because for both it is usually best to be an "experienced editor" (I'm deliberately avoiding defining that), but correlation is not causation. Phil Bridger (talk) 09:02, 11 August 2024 (UTC)[reply]
I 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
"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)[reply]
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)[reply]
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 (JSTOR26361869). WhatamIdoing (talk) 00:57, 25 July 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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. — Rhododendritestalk \\ 15:49, 25 July 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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. — Rhododendritestalk \\ 15:49, 25 July 2024 (UTC)[reply]
Templates and WP:MOS
I thought that templates (and modules) used in articles must produce output consistent with WP:MOS. In particular, automatic calculations and unit conversions should use established output formats instead of inventing their own (especially if they are explicitly marked as "unacceptable" in MOS:NUM). Is this always true, or there might be some exceptions? And if such exceptions exist, how they should be established?
My question is general, but the confusion arose from Module talk:Age § abbr=on violates MOS in particular. I was told there (by the WP administrator maintaining the module) that "more than a mention of a guideline is needed to effect a change" and that "it would be good to get opinions from editors currently interested in affected articles rather than rely on a guideline", although without any explanations where these opinions are supposed to be collected and why they should override WP:CONLEVEL. — Mikhail Ryazanov (talk) 00:37, 1 August 2024 (UTC)[reply]
Some easy-to-see cases are at Brazilian currency#Historical currencies. This is not the right place to discuss the details but examples can be helpful to save time:
The issue is that MOS:UNITSYMBOLS says there should be a non-breaking space before the units. Another issue is that m is used as the abbreviation for month (as above) but also for minute, as in the next example from Expedition 59#Uncrewed spaceflights to the ISS.
The manual of style is a guideline, and like all guidelines should be followed unless there is a good reason not to. That is not something that can be discussed at a level higher than either the individual template or a group of closely related templates, because that is the highest level at which it can be determined whether or not there is a good reason for doing something contrary to the guidelines (and that is because the answer is always context dependent).
In the linked discussion there is the additional question of whether the specific guidance in the manual of style is correct on the specific point. Thryduulf (talk) 10:03, 3 August 2024 (UTC)[reply]
It only seems that way if you don't understand what a guideline is. Guidelines are standards that should usually be followed but must be interpreted with common sense and exceptions will apply. This means that the answer to the question "should templates obey the MOS?" is "Usually." However that isn't the question you actually want to know the answer to, which is "should this specific template follow the manual of style?" and that is something that can only be answered in the context of the individual template and so is best discussed at that template's talk page. 01:32, 5 August 2024 (UTC) Thryduulf (talk) 01:32, 5 August 2024 (UTC)[reply]
I am interested in the community consensus, not in your personal interpretation, unsupported by any references (and contradicting the fact that WP:MOS does include many exceptions for specific cases, which would be unnecessary if your ideas about ignoring general guidelines in local contexts were correct). — Mikhail Ryazanov (talk) 03:01, 8 August 2024 (UTC)[reply]
See WP:GUIDES: "Guidelines are sets of best practices supported by consensus. Editors should attempt to follow guidelines, though they are best treated with common sense, and occasional exceptions may apply.
See also the header of each guideline, which says something like "This page documents an English Wikipedia content guideline. Editors should generally follow it, though exceptions may apply." The header varies depending on the type of guideline, but they're all pretty close to that. Firefangledfeathers (talk / contribs) 03:34, 8 August 2024 (UTC)[reply]
Now we need an expert on "common sense"... WP:COMMONSENSE says: "When advancing a position or justifying an action, base your argument on existing agreements, community foundation issues, and the interests of the encyclopedia, not your own common sense. Exhorting another editor to 'just use common sense' is likely to be taken as insulting, for good reasons." And Wikipedia:Ignore all rules linked from "normally"/"occasional exceptions" explains what it actually means: "If a rule prevents you from improving or maintaining Wikipedia, ignore it." I don't think that designing a general-purpose module/template such that it systematically violates the rules without any explanations (or even mentioning the discrepancy) can be called "common sense". I also don't think that broadly using nonstandard formatting, especially if the MOS explicitly calls it "unacceptable", can be considered an "improvement" (otherwise, if this "exception" is really an improvement and is so common, it must be included in the MOS). — Mikhail Ryazanov (talk) 03:18, 9 August 2024 (UTC)[reply]
The point is that if someone claims an exception applies because it improves the encyclopaedia and another person disagrees because they think it doesn't, then what happens next is discussion. That discussion needs to take place in the place relevant to that exception so it has the benefit of full context and is visible to editors who are involved with the relevant article/template/whatever. The consensus of that discussion will determine whether the exception is justified or not.
In this case you need to participate in the linked discussion and make your case there about why you think the the exception is not justified in this particular case. Refusing to engage and just repeating that you don't think there should be exceptions is just wasting your and others' time. Thryduulf (talk) 08:40, 9 August 2024 (UTC)[reply]
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)[reply]
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)[reply]
@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)[reply]
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.
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
When evaluating the botworthiness of the task of adding the NOGALLERY tag to categories that contain non-free files, I realized that we don't have clear guidelines on when locally hosted files (non-free or otherwise) should be placed in content categories.
Is there a problem with media and articles being in the same category?
If we have a lot of local media about a given topic then it makes sense to have a dedicated category for that, but if we only have a one or two (as I guess will be the case for most topics illustrated by non-free files) then it doesn't seem useful to have a separate category, but also potentially useful for e.g. File:2 Tone Records.png to be in Category:2 Tone Records. Thryduulf (talk) 09:56, 3 August 2024 (UTC)[reply]
Why do we need exact rules? If a media file is relevant to a content category then it can go in that category, unless there is a more specific sub-category in which it fits. Create subcategories if and when there are enough pages to justify one. If there is a disagreement, discuss it. This seems to work for all other pages in categories so I don't understand why it won't work here? Thryduulf (talk) 00:04, 4 August 2024 (UTC)[reply]
The TL;DR of the bot request seems to be this: WP:NFCC doesn't allow non-free images to show in Category-namespace galleries. If a non-free image is added to a category that doesn't already have __NOGALLERY__, and editor might either revert the addition of the image to the category or add __NOGALLERY__ to the category description to suppress the gallery (I see you, Thryduulf, suggested a third alternative there that would require a new magic word be added to MediaWiki). As things currently stand, that decision would fall under WP:CONTEXTBOT as which to choose depends on human judgement as to whether the category should contain non-free images or not. LaundryPizza03 is hoping for exact-enough rules that would make it not be WP:CONTEXTBOT, since he want a bot to handle this rather than having humans work off of a database report. Anomie⚔13:46, 4 August 2024 (UTC)[reply]
"British" may refer to the island of Great Britain, or to the British Isles (which, I might add, is a controversial name in some circles), but "U.K." is short for the United Kingdom of Great Britain and Northern Ireland, which doesn't really match either meaning of "British". Donald Albury21:38, 4 August 2024 (UTC)[reply]
Many/most Irish people with enetitlements to British citizenship who live in areas governed by the UK would generally not call themselves British. Most people living in the six counties, would not consider that they live in Britain, but rather live in the UK (the legal entity) or Ireland (the geogrpahic entity). See Terminology of the British Isles for more detail. Regards, Goldsztajn (talk) 22:39, 4 August 2024 (UTC)[reply]
Until recently, my impression was de-orphaning can sometimes be beneficial (I did a bit when I was starting to edit) but, in most cases, isn't hugely significant because decent search engines are widespread. Additionally, many orphans cover naturally obscure topics which just aren't going to get many readers or improvements even if they were linked elsewhere.
However, I've been coming across cases where de-orphaning has actually made things worse, generally by giving too much weight to a subject we might not even want to have an article on in the first place. For example, I recently cleaned out a large number of dubiously-notable companies whose establishments were listed as nationally prominent events on pages like 2000 in the United States because of systematic de-orphaning.
It's become increasingly unclear to me whether de-orphaning efforts, as currently practised, are doing more good than harm. But this is based on my impressions, not detailed analysis. So I'm interested to hear others' thoughts.
It probably depends on exactly what is meant by deorphaning. Adding links to relevant articles is good, in that it provides readers a path to find new information. Search cannot help someone find something they don't know they are looking for. The 2017 and 2019 discussions however make a good point that deorphaning as an end in itself is obsolete.Stepping back slightly, is there more information on what the de-orphaning efforts as currently practised are? The adding of links where they are not beneficial is not great, but how much of it is a problem, and is it a systemic issue or a relatively occasional occurrence? CMD (talk) 06:54, 5 August 2024 (UTC)[reply]
The issue with de-orphaning is that it tends to be rather black-and-white. WikiProject Orphanage has the singular objective of reducing the backlog of orphaned articles, which can result in articles that may not meet GNG being given undue weight. Something like the introduction of an 'Orphan-Notability' template, alongside the 'Orphan' template, might help. When de-orphaning a particular article, the option of replacing the 'Orphan' template with 'Orphan-Notability' would create two lists: one for orphaned articles and another for orphaned articles requiring a notability check before they are de-orphaned. Svampesky (talk) 09:15, 5 August 2024 (UTC)[reply]
I've seen good things happen from good links. If an article has no inbound article links it gets very few page views, and thus very few edits. With meaningful links from other articles it is now being seen by readers interested in related topics, and someone reading an article on one topic is probably just the person to make good edits to a related article they click through to. It's true that low-quality links, like linking to a dubiously notable company in a large city article because the company is based there, tend to lower the quality of the established article. Cluttering it up without adding useful information for readers.
I think if meaningful, good article links can't be created to an article, that's a strong sign that the article subject is not notable. It's not a criteria for deletion of course, just an indication that a topic might not be encyclopedic, if no other encyclopedia articles should even mention it. Here2rewrite (talk) 11:29, 5 August 2024 (UTC)[reply]
+1 for I think if meaningful, good article links can't be created to an article, that's a strong sign that the article subject is not notable.. CapitalSasha ~ talk11:33, 5 August 2024 (UTC)[reply]
As an "Orphanologist" working on oldest orphan articles (beginning with 2014 backlog articles), I have seen much progress. At one point the backlog was over 120,000 articles and now about 55,000. And millions more of non-orphan articles. Prior to my involvement, the consensus is to make orphan tag "invisible" after two months. My suggestion would be to show all orphan tags. Regards, JoeNMLC (talk) 13:11, 5 August 2024 (UTC)[reply]
It always seems odd to me if an article can't reasonably be linked to other articles. This could of course mean that those other articles are missing rather than that our orphan is not notable. As for whether we use visible or invisible tags, it rather depends on whether we think the task is something we want to invite our readers to do. In its early days, yes I assume most new orphans can easily be linked into the project. After some time it ceases to be a newbie task and it requires a bit more experience of the project - does this link improve the pedia or is it visual clutter? I'm not sure whether two months is the right time and if not whether it should be increased to three or more or reduced to one. But if we were going to change the interval I'd like it done with some data as to the relative ease of deorphaning articles after one, two or three months. Ideally the link should become invisible at the point where deorphaning becomes a task we don't want to promote to newbies. ϢereSpielChequers13:33, 5 August 2024 (UTC)[reply]
I don't find this odd at all, and being an orphan isn't the end of the world. Of course some articles are crying out to be linked to (creators of new articles are often very poor at looking for links to add). I'm strongly against WP:UNDUE adding the name and a link just for the sake of de-orphaning. Johnbod (talk) 15:08, 5 August 2024 (UTC)[reply]
When this was discussed in 2017, I left rather lengthy comment. Although I no longer de-orphan to the same extent that I once did, I still think the tag is valuable as a diagnostic that signals that an article should be looked at. As I said back then, I have found plenty of instances where investigating why something is tagged as orphaned has helped me improve Wikipedia - merging duplicate articles, upmerging stubs to parent articles, creating new articles in a taxonomic chain, fixing broken links, and initiating the deletion of junk that no one has laid eyes on in years. Issues can arise when people focus more on the idea of removing the tag at all costs rather than figuring out what to do with the article, but that can happen with any maintenance backlog. Think of someone who mass-redirects unsourced articles rather than improving sourcing. Is the problem the tag, or the behavior? Let's not throw the baby out with the bathwater if we can solve the crap-links problem by dealing with whoever is doing it. ♠PMC♠ (talk)08:00, 6 August 2024 (UTC)[reply]
I agree. Even if someone deorphans by mechanically adding a See also link to a more prominent article, the watchers of that more prominent article will then be alerted to the lesser article and it then has an opportunity to be improved. ~Kvng (talk) 14:20, 8 August 2024 (UTC)[reply]
As is often the case when editing WP, de-orphaning requires a degree of editorial judgement. The problems almost always occur when people edit without discernment - adding links just for the sake of linking. The reality is that some de-orphaning links are very beneficial, while others are not. Blueboar (talk) 14:44, 8 August 2024 (UTC)[reply]
The relevant policy/guideline is actually already there:
It may be the case that some articles currently just cannot be de-orphaned. If this is the case then please do not try to 'force-fit' by adding unrelated links to articles where they don't belong just for the sake of de-orphaning. Always keep in mind that our primary goal is to improve the reader's experience, not satisfy the editor's indulgence in statistical achievements. Your priority when adding links should be to maintain article quality by adding relevant and useful links wherever possible — WP:CANTDEORPHAN
So, unnecessary links can always be removed. But it's not always bad, and the inclusion or non-inclusion criteria of certain articles in general articles such as "X year" may not be straightforward; what "degree" of notability (if a person has an article on Wikipedia that person is already notable) a person has to have to be included in "Births"?
Companies can be included in some lists by location or something else. What to put in "See also" is also covered by a guideline.
But do some articles even need to exist? I somewhat agree with other users regarding the (probable) lack of notability (though it may require changes in some notability policies). The other important thing here is the size of the article. Members of the state legislatures are presumed notable, but what if the fact that a person was a member is almost the only thing we know about them? Example. Named natural features are often notable, provided information beyond statistics and coordinates is known to exist. But for some very small streams, this "information beyond" is the etymology and what bodies of water they flow into (sometimes another small stream). Example, Example. The same doubts arise regarding small unidentified villages (that may not even exist), very small neighbourhoods or just "areas".
Finally, there are some interesting guidelines about orphans: Editors may also remove the tag from any article if they believe that de-orphaning is unlikely to be successful, or if they have attempted to provide incoming links-//-However, if you are certain the article is unlikely to ever be de-orphaned then simply remove the tag. Can this also be the answer sometimes? It can also be elaborated. For example, after some time and/or a number of attempts an article may be declared "hopeless" and the tag may be removed.
The reality is that some de-orphaning links are very beneficial, while others are not. A lot of those that "are not" are not harmful either. Oloddin (talk) 05:53, 10 August 2024 (UTC)[reply]
I had this big plan where I'd intentfully draft my case before even making a post here and it would have robust sourcing and all that, but I realized I should just go for it and if there's any agreement other editors will chime in.
The key summary is: the scholarly field of palaeogenetics (or archaeogenetics) has exploded in the past decade-plus. The data we can collect from the DNA of millennia-old human remains is a shocking new advancement. However, scholarly sources often use ethnic labels for the historical genetic populations they are studying. This creates friction with the universal understanding among serious people since the end of World War II that ethnicity is a social and cultural category, not a genetic one; one's ethnicity is the result of human choices and not amino acid pairs. As such, the distinct field of ethnography generally shies from ascribing ethnic identity to almost any individual that isn't the author or focus of direct literary analysis. To wit, speaking of "Lombard DNA" (etc.) is completely inane if we're to take it as face value; it is best defended as a shorthand for lack of better language to use in these papers.
That said: if one has pages for historical people groups or demographics on their watchlist, they will notice a lot of tertiary analysis of these studies being added to articles, which often transparently conflate the actual subject of the article with genetic populations analysed in a distinct manner, sometimes because that's what those sources themselves do. I think we should consider some guideline regarding the correct representation of what this information is actually saying and how it relates to the universal notion of ethnicity otherwise described in articles about them. Remsense诉07:10, 7 August 2024 (UTC)[reply]
There should be agreement in principle, the discussions on the topics I've seen (and been involved in) tend to land on ensuring that such genetic studies are not over-emphasised in relevant articles. The biggest risk is that detailed coverage of X or Y genetic study, which will use shorthands out of necessity (often explaining so in the paper), gets added to an otherwise underdeveloped article and thus turns the paper output from perhaps an academically interesting note about a certain group of people that comes with a lot of interpretative caveats, to coming off in the article as a defining trait of said group of people. I haven't seen an academic paper suggest that the genetic studies overturn ideas of ethnicity, however unfortunately the papers do get entangled with the many complex issues surrounding defining ethnicity on individual and group levels. I would support a broad guideline noting the principles of understanding the limitations and limited meaning of such studies. CMD (talk) 08:25, 7 August 2024 (UTC)[reply]
In a section above, Oloddin asked "the inclusion or non-inclusion criteria of certain articles in general articles such as "X year" may not be straightforward; what "degree" of notability (if a person has an article on Wikipedia that person is already notable) a person has to have to be included in "Births"?" I think this is a very good question, and on a quick look I couldn't find any guidelines that answered it (please let me know if I've missed it). Should the article 2000 in the United States include everyone in Category:2000 births born in the US? If no, who should it include/exclude? Nikkimaria (talk) 02:58, 11 August 2024 (UTC)[reply]
So long as a person is notable in Wikipedia terms, I would say they should be included. General year lists include everyone born in those years. I don't see why year in X nation lists should be any different.voorts (talk/contributions) 03:15, 11 August 2024 (UTC)[reply]
Shortly after that discussion, I took this "consensus" to the Village Pump and then ANI, where it was found to be a false consensus and one of the editors enforcing it was topic banned. Thebiguglyalien (talk) 06:57, 11 August 2024 (UTC)[reply]
I agree that we ought to have some inclusion criteria. International and national notability for year and year by nation articles respectively seems to be one workable guideline, although I'm not wedded to it.voorts (talk/contributions) 04:04, 11 August 2024 (UTC)[reply]
Per the RfC linked above long lists of births should be removed. Most birth inclusions also seem questionable weight-wise in general; most notable individuals were not notable at their births, and their births would not have had a significant impact on X year. CMD (talk) 07:28, 11 August 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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}}
|script-title= causes cs1|2 to wrap the title in <bdi>...</bdi> (bidirectional isolate) tags:
'"`UNIQ--templatestyles-0000003C-QINU`"'<citeclass="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 <bdilang="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<spanclass="reference-accessdate">. Retrieved <spanclass="nowrap">31 July</span> 2011</span>.</cite><spantitle="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+%28all%29"class="Z3988"></span>[[Category:CS1 uses Arabic-language script (ar)]]
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:
Since yesterday, when I bring up my Edit Count from XTools, nothing has updated in two days. Specifically, the Actrion, Patrol figure. On the Basic information, it says "Latest edit 2024-08-03 03:11" which is in error. It also lists "Latest logged action" as 2024-08-03 03:06. Something on the stats end not working? — Maile (talk) 18:48, 4 August 2024 (UTC)[reply]
Yes, there has been a high replag on both English Wikipedia and the Commons for two days now. It seems to have something to do with this. It's lasting longer than it was expected to take. LizRead!Talk!00:21, 5 August 2024 (UTC)[reply]
Actually, it seems to happen fairly frequently, I'd guess monthly or every other month. It usually happens on Thursdays or Fridays. It becomes very evident if your editing relies on bot reports. They seem the most directly affected by these system lags. LizRead!Talk!01:50, 5 August 2024 (UTC)[reply]
So the replication lag has reached three and a half days. Is this situation normal or has something gone wrong and needs to be attended to? Can an end date be predicted or is it indeterminate? Nurg (talk) 22:25, 6 August 2024 (UTC)[reply]
I poked around and was unable to find a phabricator bug report, but my searching on phabricator does not work well. It looks T367856 accounts for this outage, but there has been no communication from WMF explaining why it is taking longer than the expected 26 hours and when it might be over. Maybe there is chatter on an e-mail list. Does anyone know if the WMF has uptime targets for their servers, including replag? With this one outage, currently at 92 hours, they will be below 99% uptime for the year. We had a 3+ hour outage in May 2024, a 4+ hour outage in June 2024, a 4+ hour outage in September 2023, and probably more. That's a good four and a half days of known downtime in the last twelve months for this valuable service. Not ideal. – Jonesey95 (talk) 06:34, 7 August 2024 (UTC)[reply]
There is no guarantees for replag. It is a best effort. We are seeing a lot of this over the last 2 years because Wikimedia are doing major rearchitecting of various database tables to enable them to keep scaling, and unlike the production environment the tools environment does not have the same level of support that would allow to execute these changes without impact. —TheDJ (talk • contribs) 09:32, 7 August 2024 (UTC)[reply]
Hooray, we are over 168 hours (one full week)! (175 hours at this writing.) That's more than a full week of database reports being out of date. It's going to be fun to mop up over a week's worth of mess when this outage finally gets sorted. – Jonesey95 (talk) 17:15, 10 August 2024 (UTC)[reply]
I'm assuming that WP:PETSCAN is affected by the same problem as well, because articles that I fixed a few days ago are still showing in the search results. - X201 (talk) 08:05, 8 August 2024 (UTC)[reply]
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)[reply]
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)[reply]
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. — Qwerfjkltalk12:10, 7 August 2024 (UTC)[reply]
Template:Efn used with basic parameters would usually be displayed as [a][b] etc. But, in the recent days it's being displayed as [lower-alpha 1][lower-alpha 2] etc. Why is it? Vestrian24Bio (TALK) 01:20, 5 August 2024 (UTC)[reply]
I see no problem with any of these articles, logged-in or logged-out. If no problem is apparent when logged-out, but you have a problem when logged-in, that tells me that there's something unusual about your custom settings. --Redrose64 🌹 (talk) 17:39, 5 August 2024 (UTC)[reply]
I don't see how that happens. According to mw:Parsoid, it's something to do with converting Wikitext to HTML. So, as all of our pages are written using Wikitext, and all of our readers are served HTML, the conversion process should be the same for everybody, and Parsoid must be that process. So why do I get something different from Vestrian24Bio? Has one of us turned off Parsoid, and if so, how and why? --Redrose64 🌹 (talk) 20:21, 5 August 2024 (UTC)[reply]
Yes, that would fix it, just a specificity issue it looks like. And the change looks deliberate, but 1) I'm not sure the impact was considered, and 2) I'm not sure that [style~="mw-Ref"] particularly is a nice selector for sundry reasons. Izno (talk) 01:11, 6 August 2024 (UTC)[reply]
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.
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.
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 Rextalk09:01, 6 August 2024 (UTC)[reply]
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)[reply]
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)[reply]
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.
𝕲𝕵𝕺𝕭𝕬𝕵 𝕺𝕽𝕯𝕰𝕶 𝕺𝕱 𝕾𝕬𝕿𝕬𝕹's account is global locked, even though their name is in title blacklist for only on English Wikipedia.[1] Also, why was their account even given the permission to be created, so that they can make three edits and then get globally locked? Thanks, ExclusiveEditorNotify Me!16:11, 6 August 2024 (UTC)[reply]
^.*[^\0-\x{FFFF}].* <casesensitive> in # Very few characters outside the Basic Multilingual Plane are useful in titles on local
Adding transparency to make templates more dark-mode friendly
As someone who has witnessed the transition to Fandom Desktop which had a dark mode included, I want to suggest something that might actually be good for templates, and that is adding transparency to backgrounds (not to the font, just to backgrounds using rgba or hex codes) This could be done automatically but it might be better to do so in wikitext and may be a good addition to the manual of style. This would allow the text to be colored white (or whatever) and we would not have to auto-color stuff with backgrounds black. I wonder what level of transparency would be good for this. I was thinking 0.1 but there isn't a good way to check. Maybe this could be done as a bot task for inline styles and by interface admins for CSS sheets. AwesomeAasim19:34, 6 August 2024 (UTC)[reply]
When a link to an article someone has created is added to a navbox, and someone subsequently edits any page in such navbox, regardless of the content of that edit, the user who created said article which was added to the navbox gets a notice that a "link was added" to that article, when that is not the case. I'm guessing the reason as to why mediawiki doesn't "register" that a link was added to a navbox in each transclusion of it has to do with the page not being purged until the next edit is made to it, but is there a way this can be fixed for link added notices? I'm aware one could just turn these off, but it does nevertheless seem like a bug. Flemmish Nietzsche (talk) 08:44, 7 August 2024 (UTC)[reply]
Not currently. From the perspective of Mediawiki, there is no difference between a link included in a page vs included via a templat, or rather what u describe a specific subset of templates. —TheDJ (talk • contribs) 09:15, 7 August 2024 (UTC)[reply]
I'm having a similar problem; I got two notifications earlier today,
A link was made from 2027 Cricket World Cup qualification to 2027 Cricket World Cup Qualifier Play-off. [5]
A link was made from 2027 Cricket World Cup Qualifier to 2027 Cricket World Cup Qualifier Play-off. [6]
I'm also confused because whenever a new notification arrives its also sent as a mail notification (only to those who preferred it). But, no mail notification is received when "A link was made" notification arrives... Vestrian24Bio (TALK) 10:06, 9 August 2024 (UTC)[reply]
Hi. For about four days I have been unable to edit articles. When I click on either the edit tab at the top of a page or the section edit tags to the right of section headings, an edit box appears to open, but a blue progress bar appears at the top which stops about three-quarters of the way across the page. As a result, I have an edit box where I can work, but no way to save my changes. Exceptions that do work are: 1. on pages like this one, the tab at the top that opens a new section; 2. clicking on "reply" on a talk page; and 3. clicking on "undo" in an article history. Those open functional edit boxes (hence I can write this). But regular editing is effectively blocked. Does anyone have an idea what the problem might be? (Incidentally, for the last year I have successfully been using the 2017 wikitext editor. I don't know if that is the problem, but I can't find any way to access it to switch it off.) Doric Loon (talk) 00:25, 8 August 2024 (UTC)[reply]
The blue progress bar you describe is probably the loading animation for the Visual Editor. In your Preferences you can uncheck the checkbox named "Enable the visual editor". Then Save the changes with the Save button near the bottom of the page.
I am not sure what could cause this problem, and I never use the Visual Editor. Programmers often, but not always, put error messages in the Javascript console when something goes wrong. Depending on which browser you have you could try pressing F12 to open the Developer tools, and then clicking on "Console" and then loading a webpage with the Visual Editor enabled (which will fail) to see if it generates any error messages. If there are any error messages this may be useful to whoever tries to diagnose the problem. Polygnotus (talk) 12:34, 8 August 2024 (UTC)[reply]
OK, I seem to have solved it by unclicking "Use the wikitext mode inside the visual editor, instead of a different wikitext editor This is sometimes called the '2017 wikitext editor'" in Preferences. Perhaps this plug-in is no longer working. Shame, I did find it helpful, how it marked coding in different colours. Anyway, problem solved, thanks. Doric Loon (talk) 15:56, 8 August 2024 (UTC)[reply]
Exactly as title. The checkbox states that it would last a year, yet sometimes I would find myself not logged in even though I am using the same device, same browser, etc. It is just a mild annoyance, but can someone give me pointers on how to fix this? Thanks in advance. —Mint Keyphase (Did I mess up?What have I done?) 01:26, 8 August 2024 (UTC)[reply]
Anything that clears or blocks your local storage (cookies) can invalidate your saved logon. Some browser or browser extension updates can cause this. — xaosfluxTalk15:10, 8 August 2024 (UTC)[reply]
FWIW I was logged out unexpectedly under similar circumstances on the day this was posted as well. I use Windows primarily with Chrome; if you also have a similar configuration, that *could* be an explanation. Graham87 (talk) 04:26, 9 August 2024 (UTC)[reply]
In Javascript, insert template in correct place (after hatnotes)
The obvious method is to make a long list of all the templates, and all redirect to those templates (and filter out those that are not used in mainspace), that should appear above the maintenance templates. But that quickly turns into a giant list and a lot of work. Isn't there a smarter way to do this? Is there some kind of Javascript library I can import? Polygnotus (talk) 16:09, 8 August 2024 (UTC)[reply]
Figured it out (somewhat) by stealing getting inspiration from Twinkle's code. [7] which uses morebits [8]
It sounds like the next step is to set this up to be a default gadget, and we should work out the details for that. In one discussion, MusikAnimal also suggested that this gadget only be loaded for pages that need it, and that this could be done using categories.
With these parameters in mind, is this how we should set up the MediaWiki:Gadgets-definition? Is everyone OK with moving forward?
Prior discussion was that perhaps these should be un-opt-out-able (i.e. hidden gadgets), primarily to not pollute the gadget list. I'm not sure that is needed though, and could always be revisited after this goes live. — xaosfluxTalk15:01, 8 August 2024 (UTC)[reply]
So barring any objections, the next steps are: update the pages to somehow include the category; move the gadget from test to template-gadgets with updated parameters. — xaosfluxTalk15:07, 8 August 2024 (UTC)[reply]
Using a consistent template-gadget category naming convention isn't strictly necessary but I think it has benefits (in this case, just change the included trigger category, or add an additional cat, in Template:ImageStackPopup). — xaosfluxTalk15:13, 8 August 2024 (UTC)[reply]
I am unsure which talk page is the intended place to ask for this since most redirect to WT:RFPP (which, if it was the intended place, is protected), but is there any way to change the form (the Request protection button), so that it does this automatically? – 2804:F1...20:147 (talk) 20:26, 8 August 2024 (UTC)[reply]
Is there any side effect to just adding the colon in the section titles there? It seems like that's what the pagelinks template already does (and many others).
Add A Fact experimental tool from Future Audiences
The Future Audiences team at the foundation is launching Add A Fact, an experimental tool for adding information to English Wikipedia from outside the website. You can download the extension from the Chrome store here: Add A Fact. For now, an (auto)confirmed English Wikipedia account is required to submit facts with this extension.
The idea was developed and workshopped with Wikipedians at WCNA 2023, demoed and tested with Wikipedia community members as part of our team’s regular monthly community calls.
Here is a short demo video on the extension:
A quick how-to —
While reading any secondary source on the web (a news item, a scholarly article, etc.), you can open Add A Fact and highlight a short claim that you may want to add to Wikipedia.
An LLM will check if the selected claim is related to any existing Wikipedia articles, and will present information about whether the fact is fully, partially, or not present in these articles. You may also search for an article of your choosing.
Once you select a Wikipedia article to add your fact to, Add A Fact will give you the option of sending a pre-filled template message to the talk page of the article, which includes the selected text, any additional comments you’d like to add, and a structured citation. This message will be signed under your Wikipedia username.
If the URL of the source you are on appears on WP:Reliable_sources/Perennial_sources, you will receive a warning message about your source’s reliability (but will still be able to add a suggested fact from this source). If the URL of the source you are on appears on the spam blocklist, you will not be able to add a suggested fact from this source.
To limit any potential misuse/spam, Add A Fact users will be limited to sending a maximum of 10 facts per day during this early experimental period.
Add A Fact seeks to prove or disprove a hypothesis about how we might continue to sustain and grow Wikimedia projects in a changing online knowledge landscape. In this case, we’re seeking to understand how people can make editorial contributions off-platform (that is, without going directly to Wikipedia.org), and if generative AI can support or hinder this process.
That's a good point. We tried to have the tool warn you about unacceptable sources but encoding all the nuances of the rules is hard. But doing this better is something we should look more into. DErenrich-WMF (talk) 23:05, 9 August 2024 (UTC)[reply]
The message left on the talk page, will that include some template or tracking category, so that editors can easily find a list of facts to be added, and act upon them? Otherwise, especially if the facts are posted on lesser-watched talkpages, it'll be like shouting into the void. --rchard2scout (talk) 06:30, 10 August 2024 (UTC)[reply]
Will we be able to find out how many facts posted to talk pages have been reviewed and used in articles, as opposed to rejected, and how many have not been considered at all (eg because of being on a less-watched page)? In what other ways will this tool be evaluated? For example, how might we detect an increase in, as the close of Wikipedia:Administrators' noticeboard/IncidentArchive1160#User:Drbogdan, persistent low-quality editing, and WP:NOTSOCIALNETWORK issues put it, mass-adding content based on low-quality popular science churnalism to our science articles, expecting that other editors will review it and determine whether to improve or remove it, leading to an indefinite community block? NebY (talk) 01:56, 11 August 2024 (UTC)[reply]
Once the experiment is complete (probably in a few months) we will put together a report with our findings. See for example the report for the last project we did. The metrics we're looking at are the kind of things you'd expect: number of users, number of edits, number of reverts, etc. But probably more importantly we're also collecting qualitative evidence (e.g. discussions like this one, feedback forms or by manually looking at the edits being made). DErenrich-WMF (talk) 04:09, 11 August 2024 (UTC)[reply]
Getting Cite errors and CS1/CS2 errors for an article via the API
I want to get information about Cite errors and CS1/2 errors via the API. The input should be the title of a Wikipedia article and the output should be either a list of cite errors or a list of CS1/2 errors (or a combination).
On this article I can see that the API reports that there is a CS1 error, but not what the actual problem is. I have added the CSS found here so I can see the specific CS1 error when viewing the article in my browser. But how can I get this information via the API? It looks to me like Module:Citation/CS1/Configuration generates the error messages; does the fact that the error is generated by this Lua script mean I can't get this information via the API? Or do I have to get the rendered page to get the actual HTML and search that for error messages?
Is it possible to detect (via the API) if an edit causes a CS1/CS2 error before actually making the edit?
There are roundabout ways, but otherwise, the answer to does the fact that the error is generated by this Lua script mean I can't get this information via the API is yes. Each error emits a category but you will only know which categories go with which citations by using something like the mw:API:Expandtemplates on the source wikitext. If you don't care about knowing which templates have which issues, you can use the categories API. Another solution is to get the HTML and then search for the relevant classes with e.g. mw:API:REST API though I think there are other APIs one could use (even ignoring screen scraping).
Is it possible to detect (via the API) if an edit causes a CS1/CS2 error before actually making the edit? Only with something like the above. Izno (talk) 02:27, 10 August 2024 (UTC)[reply]
Cite error
On Brainwashing I see a cite error on ref 87: Cite error: The named reference they-never-said-it was invoked but never defined (see the help page). Which API call should I make to get this information? I assumed it was this (Sandbox).
Is this also handled by a Lua script somewhere? What is the URL? It looks like its using MediaWiki:Cite error references no text but I can't seem to find a Lua module referencing that. Is it in a MediaWiki extension written in PHP?
Do I have to get the rendered page to get the actual HTML and search that for error messages?
How would I detect (via the API) if an edit causes a cite error before actually making the edit?
It looks like I am at least able to find errors before they happen with action=parse, but those are warnings from the parser, not the Lua script(s). Is that correct?
These errors originate from mw:Extension:Cite. You can explore the documentation there, but I do not think there is anything to indicate errors in an API. Besides whatever categories are emitted, as discussed above, but that would not tell you which references caused an error I believe. Izno (talk) 02:30, 10 August 2024 (UTC)[reply]
I have noticed a problem with accessing all of the tag options when using Twinkle.
I switch between mobile to desktop when I need to use Twinkle, in most instances the full drop down menu is fine, I can scroll up or down to find the correct message I need. When trying to add a welcome message for new users the scroll doesn't work though. I can only access the initial few welcome messages but that's it.
I also have the same problem with tagging articles in the mainspace. I've found an article published to the mainspace and it doesn't have any references. I wanted to tag it as such but I am unable to scroll down the menu to the correct option.
Most of the Twinkle options are fine, such as CSD, I can scroll down to view all the options. It seems to be a problem with Welcome messages and article tagging. Am I doing something wrong? Thanks in advance, Knitsey (talk) 15:42, 10 August 2024 (UTC)[reply]
Polygnotus, I completely missed the OS bit! Android, version 14 if that makes a difference. The scroll down options always used to work. I've been on a Wikipedia break for about 8 months, come back and those two sections no longer scroll. Knitsey (talk) 02:13, 11 August 2024 (UTC)[reply]
I use my mobile. Switch to desktop to use Twinkle. It is just those two menus that I can't scroll down... Welcome messages for new users and the tag menu on articles.
The Twinkle menu for vandalism warnings is fine, I can scroll down on that. The same for CSD, I can scroll down on that too.
With Welcome messages, I can always go back to using templates for now. I'm just curious as to why those two drop downs and whether it cwn be fixed. Knitsey (talk) 03:01, 11 August 2024 (UTC)[reply]
Can someone take a look at the Warburg Institute article? The title is being italicized (when it should not be); it uses {{infobox journal}} later in the article, which auto-italicizes, but it's set to "no" as the template says so presumably this should not be happening. Aza24 (talk)01:35, 11 August 2024 (UTC)[reply]
Some of the entries are referring to historic/stale accounts. It's hard to gauge. I was thinking add a column, "Page last edited". Is this information available somehow, given the name of a page, return the date of last edit? It's not a perfect solution but some information is better than none, recent activity will be more visible. -- GreenC04:19, 11 August 2024 (UTC)[reply]
What's the technical or by design reason for the limitations of the editing tools on the mobile version? Many of the tools that you can add through code particularly don't seem to show up in any form in the mobile format. Is there any features pipeline to introducing this functionality? Iskandar323 (talk) 10:47, 11 August 2024 (UTC)[reply]
When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.
Back in 2017, the community decided in this RfC that moved pages should be unpatrolled. The feature was stuck in Phabricator purgatory and was never actually implemented.
I'm really surprised so many people supported that: it would create a substantial added burden for patrollers in exchange for maybe making a very rare problem slightly easier to detect. (Redirects from page moves already go into the queue, and even if they're retargeted elsewhere, a good reviewer should notice the suspicious history.) Unless this is a much larger-scale issue than I'm aware of, I don't think that proposal should be implemented. Extraordinary Writ (talk) 08:00, 21 July 2024 (UTC)[reply]
I have seen cases (e.g. recently at AT CBS This Morning) where a long-standing patrolled page becomes unpatrolled because a non-autopatrolled user moved the page - like from vandalism being reverted like CBS This Morning, or from requested moves like (709487) 2013 BL76. There can be quite a lot of these cases. Is this scenario also part of this discussion? thanks. Aszx5000 (talk) 09:36, 21 July 2024 (UTC)[reply]
@Aszx5000 That specific behavior is part of a bug that started happening recently and will be probably reverted. It's being tracked in T370593. The default behaviour is to not unpatrol page that are moved. Sohom (talk) 10:00, 21 July 2024 (UTC)[reply]
I think the RfC should be respected. Yes, WP:CCC but we really shouldn't overturn an RfC without an new RfC. Besides, this will help with detecting move vandalism in some cases so it is a useful change. Nickps (talk) 12:32, 21 July 2024 (UTC)[reply]
Oppose: If the RfC hasn't been implemented in 7 years, and it was only recently implemented by accident, it makes sense to revisit the discussion instead of implementing it by surprise so much later on in time. As one of the more active patrollers, I absolutely hate the idea of adding to the workload / massive backlog by adding pages to the queue just for being renamed. Really we'd want to just mark it as patrolled 99% of the time anyways. Hey man im josh (talk) 14:49, 21 July 2024 (UTC)[reply]
FWIW, I attempted to figure out how much moving and patrolling actually goes on so I could see if making it necessary to re-patrol moves would indeed add a significant workload. I came up with 916 moves and 1225 patrols yesterday. My SQL is weak (and my understanding of the MediaWiki schema even weaker) so I don't know if these numbers are accurate or not. If they are, then it looks like this would almost double the patrolling workload. RoySmith(talk)15:33, 21 July 2024 (UTC)[reply]
Though, as usual, raw statistics are misleading. Neither of our queries, for instance, try not to count page moves by autopatrolled users, or pages moved out of the main namespace without leaving a redirect or where the redirect was later deleted. I can at least compensate for the small sample size by showing stats for all of July up to now, which are better: 7068 page moves starting in mainspace, 13519 mainspace page curations. —Cryptic16:55, 21 July 2024 (UTC)[reply]
Oppose. I don't see much of a point in implementing this as it would unnecessarily double the workload of the NPP team. Redirects left behind from moves are already placed in the redirect queue (except for users in the page mover, autopatrolled, and redirect autopatrolled groups, including administrators). DannyS712 bot then automatically reviews a portion of them if the changes fit certain criteria, and the rest are reviewed manually. I feel like this system works just fine; it's not like we have a runaway page-move vandalism issue on our hands. —TechnoSquirrel69 (sigh) 17:50, 21 July 2024 (UTC)[reply]
Oppose. To quote myself from 2017: Oppose pending more information. I'm concerned about rushing into something that will potentially hugely increase the load at the already hugely-backlogged WP:NPP. How many pages are moved per day? How many more reviewers would we need to handle the extra load? What's the scale of this problem? Are there other solutions we could explore (e.g. marking pages that have {{disambig}} removed as unpatrolled)? We have the answers to some of those questions above, and it's not looking good. Doing this would double the NPP workload in order to close a loophole that is apparently so small that nobody noticed it had been accidentally left open for the last seven years. Really bad idea. – Joe (talk) 21:35, 21 July 2024 (UTC)[reply]
Comment: the proposal as it developed in the 2017 RfC was not for all article moves but for those by non-EC users which I think was 40 a day at the time. Cenarium's comment is not clear to me but search for "40" (not pinging them because they have not edited since April). Pinging @Ivanvector: who initiated the proposal for their comments. We don't know if this is still a concern or if other mechanisms were put in place. S0091 (talk) 19:39, 22 July 2024 (UTC)[reply]
not for all article moves but for those by non-EC users which I think was 40 a day at the time. This somehow ended up not reflected in the 2017 RFC close and not reflected in the 2017 Phabricator ticket. We could go off on a tangent about whether that RFC was closed correctly or not, but I think it's a non-issue because we'll get a fresh consensus in this RFC that will override any lack of clarity about the previous close. –Novem Linguae (talk) 23:58, 28 July 2024 (UTC)[reply]
??? I don't know that area that well because that not normally where I do my NPP work but I thought this was already happening. For example Extracorporeal procedure was in the cue. The community really needs for fix some things to help with the disaster at NPP but worrying about easy stuff like this really isn't it. North8000 (talk) 20:28, 22 July 2024 (UTC)[reply]
Oppose: Unnecessary. They will almost always be marked as reviewed immediately, so this just adds a pointless burden to the NPP queue. CFA💬22:15, 28 July 2024 (UTC)[reply]
Blame and Wikiblame have the same goal, but they're separate tools/separate software code. Someone might want to have access to both tools, but they should be side by side in the list.
On the other hand, Wikiblame should not be in the list with Wikidata, Wikinews, Wikibooks, and other sister projects. But Commons and Wiktionary should be in the list of sister projects, and I don't see them. WhatamIdoing (talk) 05:24, 27 July 2024 (UTC)[reply]
@WhatamIdoing. Hopefully I haven't given off the impression that I am offering an exhaustive overview. Commons and Wiktionary are just as welcome. My main focus was on getting some relatively hidden tools to be accessible via 'Analysis'. Infogiraffic (talk) 08:32, 29 July 2024 (UTC)[reply]
As a proof of concept, I think it's fine. I wouldn't personally find it very useful, because I'd rather type than look for anything in a menu. But others, especially those less familiar with MediaWiki software, likely have the opposite preference. WhatamIdoing (talk) 16:29, 29 July 2024 (UTC)[reply]
Both tools serve the same purpose (revision history tracking) but have separate codebases. Ideally, they should be grouped together under a single, clear label like "Revision History." While some users prefer keyboard shortcuts, menus can be helpful for those less familiar with MediaWiki. Perhaps a balance can be struck? We could consider a hybrid approach with both keyboard shortcuts and a more intuitive menu structure. What about submenus for categories like "Analysis Tools" (where "Revision History" would reside) and "Sister Projects"? BlackOrchidd (talk) 08:46, 7 August 2024 (UTC)[reply]
Afd to Prn/Pcn
Can we rename Articles for deletion to Articles for checking/Reviewing notability which will give a positive impression than the present one. 103.66.169.3 (talk) 19:36, 26 July 2024 (UTC)[reply]
I think this is one of the perennial proposals, and the answer is "not necessary" (at any rate, it would require rewriting thousands of lines of active software, and moving half a million pages). jp×g🗯️22:15, 26 July 2024 (UTC)[reply]
The French Wikipedia did this, perhaps two years ago. AIUI they thought the communicative value (e.g., that we are here to check notability, not necessarily to delete the page) outweighed the one-time hassle. (Also, you don't have to move the prior pages; you can just move a few key pages, like Wikipedia:Articles for deletion itself, and leave the old ones alone.) WhatamIdoing (talk) 05:39, 27 July 2024 (UTC)[reply]
It was indeed a huge undertaking; no, we do have to move a huge amount of pages (as my major work 'bot did); and as JPxG points out there is more in place nowadays that is hardwired to the page prefix (from the templates that we invented at the same time, to people's private add-in scripts) than there was back then. Moreover we are not checking notability. We are deciding whether an administrator hits a delete button on an article, for those cases where it isn't obvious on sight that the article should be deleted and 1 person alone can safely make the decision to press that button. It's a very clear name for the very single purpose that it is there for. Stuff outwith the decision about whether an administrator hits a delete button or not is intentionally left to the editorship at large. Uncle G (talk) 02:08, 28 July 2024 (UTC)[reply]
I'm also old enough to remember the VfD days. Anyway, AfD has its problems. What it's called is not one of them. Let's worry about stuff that matters. RoySmith(talk)02:25, 28 July 2024 (UTC)[reply]
@Uncle G I appreciate the clarfication that this tool is focused on assisting administrators with clear cut deletion decisions, leaving broader editorial judgments to the communiity. Maybe having a name that reflects this purpose, like "Rapid Deletion Assist" or something similar, could be helpful. BlackOrchidd (talk) 09:15, 7 August 2024 (UTC)[reply]
"Rapid Deletion Assist"? Did you mean Category:Expired proposed deletions? Or perhaps WP:CSD? Or perhaps Special:Nuke? Also AfD is a venue and a process, but not a tool (those are pieces of code).Maybe we should leave the name as is, so we don't have to rewrite thousands of scripts and move a half million pages. If there's one deeply embedded major nomenclature failure on the project, it's Notability. The amount of confusion about / discomfort with AfD would need to increase by two orders of magnitude before it would be worth renaming at this point.Apologies for the grumpiness. My keyboard keeps crashing, which I hate is a thing that is possible. Folly Mox (talk) 10:12, 7 August 2024 (UTC)[reply]
I agree with Uncle G, the current name has a clarity that said replacements would not have. Even if the new name is somewhat less intimidating to newcomers, it's better to be upfront about what's happening. ― novov(tc)06:14, 28 July 2024 (UTC)[reply]
Rename to Articles for Discussion?, in line with the other XFDs. I had a similar query and sometimes feel uncertain about nominating articles when I'm on the fence if they should be deleted/merged/redirected. The 'AfD' acronym is also maintained. Svampesky (talk) 23:11, 30 July 2024 (UTC)[reply]
Currently if a user clicks "Add a topic" on an article talk page, a box appears which prompts them for a "Subject" and a "Description".
"Description" is somewhat cryptic in that context, and seems like a placeholder string that was never reassessed. A talk page message or question isn't really a description of anything. In some contexts (like Talk:ChatGPT and Talk:Google, talk pages which ended up locked in response to so many people mistaking "Add a topic" for a direct query to those services) asking for a "Description" may, to some users, look more like a prompt to communicate privately with a generative AI or web service, rather than the start of a human conversation with Wikipedia editors.
I raised the suggestion more broadly at the idea lab earlier in the year and was told that, regarding a change to this specific interface message, altering these strings will affect all pages. This change has to be very carefully considered. So here's a concrete proposal to change it. Will "Your talk page comment" make sense in all contexts where this string is displayed, and would we agree that it was an improvement on "Description"? Belbury (talk) 14:06, 8 August 2024 (UTC)[reply]
We can certainly improve on "description", and "Your talk page comment" would be such an improvement although I am not immediately certain it is the best we can do - especially if this appears anywhere other than talk pages? Perhaps something as simple as "Your message" would work? Thryduulf (talk) 14:13, 8 August 2024 (UTC)[reply]
This is a smart suggestion; thanks for raising, Belbury! I'm inclined to support "Your message" for conciseness and to be on the safe side given Thryduulf's concern that it might be used outside of talk pages. Sdkbtalk15:15, 8 August 2024 (UTC)[reply]
I agree with the idea, but would be inclined to suggest "Your comment", given that "Your message" might still be mistaken for a ChatGPT/Google/etc. prompt query. Chaotic Enby (talk · contribs) 18:06, 9 August 2024 (UTC)[reply]
"Your comment". Just based on widespread, almost universal Wikipedia terminology. Messages are for emails and texts—things that are sent, not posted. ―Mandruss☎18:22, 9 August 2024 (UTC)[reply]
Deploying Edit Check on this wiki
While attending Wikimania this year, Selena Deckelmann (User:SDeckelmann-WMF) demonstrated a new feature for Visual Editor, Edit Check in a session. Edit check introduces additional prompts in Visual Editor when an editor tries to insert a blacklisted URL as reference and also when they try to publish a revision without inserting a reference. This greatly helps with encouraging editors inserting references in their edits. If I recall correctly, the percentage of editors inserting references increased from 11% to 40% in their tests (do correct me if I am wrong as I am going off on my recollection).
There is certainly some benefits in enabling this, primarily on improving the verifiability and reliability of content that's on English Wikipedia. Most of the sister projects have already been deployed with this feature. English Wikipedia does not have this feature enabled yet. The only thing that is holding back this feature is that Visual Editor is not set as the default editor for anonymous and new editors.
Therefore, I would like to propose that:
Visual Editor be the default editor for anonymous and new editors.
The last time I checked, new editors are presented with a pop-up box that asks them to choose which editor they'd like to use, with the solid blue button pushing them a bit toward the VisualEditor.
This thread is rather underdeveloped. For a proposal of this magnitude, I think we should figure out relevant factual questions (like what the current default is) and then draw up a more formal survey that could be CENT-listed, etc. Sdkbtalk19:05, 9 August 2024 (UTC)[reply]
Another question is how does it work with edits that don't need references adding (e.g. creating redirects, adding links on disambiguation pages, fixing spellings, etc)? Thryduulf (talk) 19:08, 9 August 2024 (UTC)[reply]
In theory, this sounds like a great idea. I'm eager to try it out, but I think a first step would be to make it available as an opt-in on enwiki. Then after people have got some experience with it, let's come back and talk about making it the default. RoySmith(talk)20:09, 9 August 2024 (UTC)[reply]
There's a simpler option for userscripts that should work: window.MWVE_FORCE_EDIT_CHECK_ENABLED=true;
So long as that's there before VE loads, it should force you to have edit check. Either method also bypasses the account restrictions on edit check, so you're not quite getting the pure experience that people would if we just turned it on for enwiki. By default it only shows up for new users (defined as under 100 edits), and someone might want to edit the configuration on-wiki for that. DLynch (WMF) (talk) 21:26, 9 August 2024 (UTC)[reply]
The add-reference check is very conservative currently. You need to be a user with less than 100 edits who has added a whole new paragraph of at least 50 characters (configurable per-wiki) that contains no references before it'll pop up. This can all be loosened up in the future, whether by default or through community configuration, but we figured that those criteria had pretty low odds of being a false positive to start with.
It's quite interesting that this boosts the percentages so much, because I honestly thought that complete new-editors would be doing far more minor edits. But no, major new blocks of text are pretty popular.
It's actually turned on with the reference check everywhere but 8 of the wikipedias (bn, de, en, hi, id, nl, pl, ru), so it's pretty easy to try it out on another wiki if you don't want to jump through userscript hoops here. DLynch (WMF) (talk) 21:34, 9 August 2024 (UTC)[reply]
Not sure where ReplyTool will put this, but nothing I'm seeing in the documentation requires VE to be the default editing interface in order to deploy the new tool. So deployment doesn't seem contingent upon answering the larger question of whether VE should be default. Folly Mox (talk) 22:17, 9 August 2024 (UTC)[reply]
Unless things have changed in the last year, it doesn't need it to be the default, but editor does need to be in the visual editor, and that's somewhat more likely to happen (especially for the editor's first edit) when the visual editor is the default. WhatamIdoing (talk) 01:29, 10 August 2024 (UTC)[reply]
The functionality is targeted towards new editors and anonymous editors, therefore the need for Visual Editor to be the default before the deployment of the functionality is considered complete. Also there are on wiki configuration options that we may want to adjust. As stated by Dlynch (WMF) above, the tool is configured by default for an user with less than 100 edits and making revisions of more than 50 characters. – robertsky (talk) 04:15, 10 August 2024 (UTC)[reply]
Minor quibble: enwiki has already got the prompts about blacklisted URLs for references/links. We rolled those out everywhere on the logic that any edits involving them were going to get blocked-on-save anyway so it wasn't going to disrupt any workflows. :D
It's a bit fuzzy because we called the project "Edit check", and we're developing a specific system called edit check (of which the "add reference" check is the first example), but we're also doing smaller edit-enhancement features along the way that colloquially get called checks just because of the project.
Conduct a thorough analysis of the potential consequences of setting Visual Editor as the default for anonymous and new users. Consider factors such as user experience, editor retention, and overall editing patterns. If making Visual Editor the default is not feasible, investigate other strategies to increase Edit Check adoption. This could include targeted outreach to experienced editors, promoting the feature through in-editor messages, or developing incentives for reference usage. Regardless of the chosen approach, it's essential to closely monitor the impact of Edit Check on reference usage and article quality. This data will be crucial for refining the feature and measuring its overall effectiveness.
I'd support making Visual Editor the default, as long as they also leave wikitext editing as an option (which I'm sure they will). VE is much better nowadays than when it was first released. As a WYSIWYG editor, I suspect it is much more new editor friendly. It is unarguably better at things such as automatic citation generation and table editing (adding and removing columns and rows, moving columns and rows around). And for the few things it is bad at (such as complicated template syntax), power users can just switch to wikitext editing. Any logged in user can select their default at Special:Preferences (under "Editing mode"). –Novem Linguae (talk) 10:47, 10 August 2024 (UTC)[reply]
I totally agree that VE should be the default for new users. I use VE every day, and it's just fine for most stuff, and getting better incrementally. Folks who think VE should not be the default should go to edit-a-thons and try teaching new users. 20 years ago, wiki-markup was the new hotness and was miles ahead of editing raw HTML. Today it's just a barrier to entry for potential new editors. RoySmith(talk)12:24, 10 August 2024 (UTC)[reply]
When I first edited English Wikipedia as an IP editor, I found WikiText editing very difficult to understand. I’m sure that most new IP editors face this issue. I strongly support making the Visual Editor the default. New IP editors are often unfamiliar with Wikipedia and may not know how to cite a reference using the WikiText editor. They may also not know how to switch to Visual Editing. Frankly, I still have to check the preview before publishing edits using the WikiText editor because I sometimes make mistakes. GrabUp - Talk11:08, 10 August 2024 (UTC)[reply]
Potentially minor bugbear alert: The visual editor reference creator still hasn't figured out the basic functionality of allowing for an easily accessed and obvious use of an |author= field, instead forcing all authors into |last and |first. It's not a groundbreaking issue, but it's really disappointing that it's still around after so long, especially given the many words given over the years about attracting more diverse perspectives etc. The default reference tool that we are going to create a pop up asking all new editors to use should allow for sources from authors whose names don't fit into the common European name format. It may be hidden behind an additional field button, but at least the wikitext reference creator has the option. CMD (talk) 12:10, 10 August 2024 (UTC)[reply]
My biggest bugbear is the lack of ability to set a reference name. For example in this edit I switched from visual to source editing so I could reuse citations between prose and infobox. Although admittedly this is not something a brand new editor wants to do, being able to set a name other than ":0", ":1", etc would be rather handy. Thryduulf (talk) 12:28, 10 August 2024 (UTC)[reply]
All programmers should read Falsehoods Programmers Believe About Names, and then re-read it every few years to refresh their memory. People who design database schemas should re-read it every time they start a new project. I agree that it's not a showstopper for our purposes, but it is a surprising lack of cultural sensitivity from an organization which is so into i18n.
For me, the biggest bugbear is that there's no good way to convert a {{cite web}} into another template without basically starting from scratch. It really should be smart enough to figure out that if {{cite web}} has a "first=" field, it can safely map that into {{cite news}}'s "first=" and so on. It won't be perfect, but it'll get you most of the way there. RoySmith(talk)12:57, 10 August 2024 (UTC)[reply]
@Chipmunkdavis @RoySmith Visual editor follows the definition of the template parameters at Template:Cite web#TemplateData (and so on for other cite templates). I think the developers would also wish that you didn't require the name to be split into two fields; it's a chore to fill it out this way. If you think this can be changed, please edit it there. Matma Rextalk13:58, 10 August 2024 (UTC)[reply]
@Matma Rex you are entirely correct that VE gets its field definitions from the templates. The first part of my comment about first_name/last_name ethnocentricity applies equally well to template writers.
But, the part about being able to convert one type of citation to another really is a VE issue. The "automatic" feature of the VE template editor is very handy, but it often can't intuit the proper type of template (that's not VE's fault) and falls back to using {{cite web}}. It would be really handy if you could say, "Please make that into {{cite news}}, and do the best job you can converting the fields". RoySmith(talk)14:38, 10 August 2024 (UTC)[reply]
|author= is already present in the existing template parameters, even if just as an alias of |last. Not presenting the alias in VE is a choice of VE, the buck should not just be passed to blindly following a particular table. CMD (talk) 14:56, 10 August 2024 (UTC)[reply]
It might be controlled by the WP:TEMPLATEDATA in something like Template:Cite/doc. I think VE reads the template data to determine the parameters it displays. If a parameter is omitted or set as hidden, perhaps it is not displayed. Not 100% sure but that is probably worth checking. –Novem Linguae (talk) 15:08, 10 August 2024 (UTC)[reply]
Assuming it is, then it would be really useful to have some statistics of how often VE (I know, I should really be saying Citoid or Zotero, or something else, but I'll just keep saying VE because that's what the end user sees) gets it wrong. I'm not entirely sure how we would define "gets it wrong", but a first pass might be "VE initially calls it {{cite web}} which is later corrected to a different {{cite xxx}} variant". Some of that might require instrumentation inside VE to detect when the user abandons a constructed citation before saving it. Some of it might require analyzing revisions to the page to see when template types are corrected after the fact. But let's assume one way or another, we could build a log of incorrect categorizations.
Then what we would do is take the full log of these reports, group them by top-level domain, and sort by frequency. If it came out that "bxtimes.com" was the most frequently domain which got mis-categorized, then it would be the highest priority for a human to go figure out how to fix and add that knowledge to the VE (Citoid? zotero?) database. After enough iterations of fixing the highest priority ones, we'd end up with a better system. If (total SWAG here) we could find the 100 top problems that accounted for 50% of the total errors, with a very small amount of human work to fix them, we could have a major win.
It sounds like a reasonable stab at the misassignment-of-citation-templates issue.
Caveat up front: I'm a developer, but I've never actually touched the internals of Citoid+Zotero, so I might be wrong about details here. That said, I believe you're right that the classification part happens entirely in Zotero, and further that if you want to teach Zotero about how to classify a new site there's some guidelines we have for that over on mediawiki.org. This coming from Zotero is also why we have vastly more classifications than we actually use on-wiki -- check out the mapping for that.
It's possible that some of the incorrect template-usage you see could be at the level of those mappings, as well -- I note that the `statute` type is just hooked up to the generic `Citation` rather than to {{Cite_act}}, for instance, though that's probably far from the most common one to need.
As for the specifics of working that list-of-sources out...
We do have some instrumentation inside VE already that could probably be looked at to work out how often someone gets all the way to the "presented with a citation-template" step and then abandons it, which would give us an okay up-front guess at the rate where something is wrong with the generated citation. Ignoring the question of other types of failure for now, the next problem is that our VE usage-instrumentation is carefully ignorant of content for privacy reasons, so it doesn't know anything about what URL was looked up when that happened. Looking for revisions which consist of just a citation template being replaced with a different citation template sounds doable, albeit slow.
I wonder if we could approach it another way. Assuming that Zotero has some internal logging of the translator it used when we make a request to it, or that it can be persuaded to tell Citoid this, we could perhaps add some logging for requests that fall back to the default-translator for unknown pages. That's not a perfect match for the misclassifications, but it's much easier to find. It does leave out cases where the translator exists but is getting it wrong, of course. DLynch (WMF) (talk) 01:46, 11 August 2024 (UTC)[reply]
it doesn't know anything about what URL was looked up when that happened does it know/track what type of template it chose? If so we can possibly work out what proportion of e.g. cite-news vs cite-web generations were abandoned? I don't think, ottomh, there would be any privacy issues with that? Thryduulf (talk) 01:53, 11 August 2024 (UTC)[reply]
Unfortunately not. All it tracks is that a citoid request happened, and then either that the "insert" button was chosen or that something was done to move away from the citoid results list. It doesn't even track what type was chosen if you go to the "manual" tab and explicitly pick one of the templates listed there.
I do agree it seems very unlikely to be a privacy issue. I mostly mentioned that was the guiding principle to explain why the case for so many questions like this turns out to be "we never needed this actually-very-innocuous content-related data before, so we weren't collecting it". DLynch (WMF) (talk) 02:09, 11 August 2024 (UTC)[reply]
Please post corresponding Phabricator tickets for all mentioned "bugbears". 1) Having tickets for these things and 2) making noise in them is the best way to move these fixes forward. –Novem Linguae (talk) 14:31, 10 August 2024 (UTC)[reply]
I’ve always been disappointed that Wikipedia doesn’t offer this feature and would love for it to be put in to Wikipedia. Since we have AI around, we can easily create quiz questions on a larger scale for the most popular articles. We could start by implementing quizzes on the main page and going from there. I understand that Wikipedia is an encyclopedia, but the question I came here to answer is that is it just an encyclopedia or is it more than an encyclopedia that includes features that are not just for encyclopedias as a general learning site. Britannica has something similar and I think it would be great not to copy everything it does, but have it as inspiration for creating quizzes. I would like to discuss if Wikipedia should have extra features that make the website more enjoyable rather than just reading and editing. I hope you will consider this suggestion. Interstellarity (talk) 21:33, 10 August 2024 (UTC)[reply]
The NY Times runs a weekly quiz, with questions about the previous week's news stories. It's kind of fun (even if I rarely score above 50%). My guess is if you pitched this to WP:SIGNPOST they'd be happy to run it. On the other hand, there's absolutely nothing stopping you from doing it in your own userspace and announcing it on WP:VP. If people like it, they'll vote with their mouse clicks.
I'm not too on board with including quizzes and other gadgets like this, that are a pretty heavy weight to maintain (especially with having to review all the AI-generated quiz questions), while not really being encyclopedic and probably being an uncomfortable distraction for a lot of readers (including me). However, having them on the Signpost would be cool, although I don't think them being AI-generated is a good thing. On a larger scale, I'm afraid of "feature bloat" where the core thing (here, the encyclopedia) gets buried under layers of gimmicks, ultimately making it much less convenient and not necessarily more enjoyable. Adding more for the sake of adding more isn't necessarily a good thing. Chaotic Enby (talk · contribs) 22:43, 10 August 2024 (UTC)[reply]
The idea of quizzes was discussed in June 2022 and by you in March 2022. As I said in those discussions, anyone should feel free to start quizzes on a project page to establish a track record of being able to produce them regularly, and to figure out what audience exists for this feature. isaacl (talk) 04:03, 11 August 2024 (UTC)[reply]
I don't get why we need things like extensions and AI to run quizzes. Quizzes existed long before Mediawiki and AI. Just take a couple of minutes to ask a few questions each day/week/month in your user space and advertise it on one of the village pumps and/or Signpost. If the feature is popular then it can be formalised to the main page etc. Nothing will happen unless someone (most likely you) volunteers to do it. Phil Bridger (talk) 08:40, 11 August 2024 (UTC)[reply]
Idea lab
Resources on severe mental illness pages
For example, on the pages for “Eating Disorders” and “Anorexia Nervosa” include a section about what hotlines and organizations are available for eating disorder treatment in predominantly English-speaking countries. It’s very likely that struggling individuals may come to wikipedia to learn more about what they’re dealing with, and how someone can access information about treatment is objectively relevant to the topic. Ju1c3machine (talk) 09:34, 24 June 2024 (UTC)[reply]
I'm often one to call out "that's not what Wikipedia is for", but I actually agree. Considering it purely from the perspective of building an encyclopedia, treatment and how people seek it is a legitimate aspect of its coverage, and an article is incomplete without it. I'd also say that these sort of resources are relevant external links that would be appropriate to include at the bottom of their article—maybe even in their own subsection under external links if applicable. Thebiguglyalien (talk) 22:52, 24 June 2024 (UTC)[reply]
One question is, who would be responsible/liable if a reader suffers harm from following a no-longer valid or malicious link from such a page? That is why we have disclaimers on pages about medical topics. Donald Albury23:09, 24 June 2024 (UTC)[reply]
If a link becomes invalid, how is that any different from other links being caught and updated by editors? Wiki isn't providing services so there's no liability issues- same as if the Yellow Pages contained a hotline that went out of order. Ju1c3machine (talk) 13:49, 25 June 2024 (UTC)[reply]
How does one decide which organisations are worthy of having their hotlines mentioned? There are far too many organisations for these issues to include all of them and having to subjectively decide on them is bound to cause more problems than it is worth. Where would you even include it either, anywhere near the top would cause issues with those who simply want to read an article and if they're at the bottom they'd be quite useless. Traumnovelle (talk) 08:11, 20 July 2024 (UTC)[reply]
For Wikipedia:Stand-alone lists, it would be possible to be comprehensive. A list of several hundred short items is not unreasonable.
Within an article, editors should use the ordinary methods of determining article content. For example, what was the first or most historically important service? "____ became the first charity to offer helpline services via SMS texting" is appropriate encyclopedic content.
Second, once you look outside the suicide/crisis category, there are often very few of these services. For example, the US appears to have three hotlines for eating disorders: two general ones, and one specifically for insulin-dependent diabetics. That's it. The UK appears to have one. It would not be difficult to construct a sentence that says something like "In the UK, free support services, such as a helpline, are offered by the charity Beat". WhatamIdoing (talk) 20:50, 21 July 2024 (UTC)[reply]
There are more than 50 English speaking countries. Also having to choose which services are mentioned by name is obviously problematic, especially if it isn't already summarised in a secondary source. Traumnovelle (talk) 03:42, 22 July 2024 (UTC)[reply]
There are only about 35 countries where English is the main language spoken, and most of them do not have any hotlines or other specialized resources for people with eating disorders. For example, Grenada in an English-speaking country, and the way you decide whether to mention Grenada's eating disorder group is: You can't, because they don't have one. They don't even appear to have a suicide crisis hotline. List of suicide crisis lines attempts to be comprehensive, and we only have about half the countries listed.
Personally, when seeing this, I was curious what other encyclopedias that exist in part/whole online do regarding this, so I went to a few to check. Let me preface this by saying I don't think it's a valid comparison to compare Wikipedia to a print encyclopedia for something like this, because we aren't ever complete and that's okay in part because we are online and perpetually being improved and updated. My opinion and analysis of policies/guidelines is after the list:
Encyclopedia Brittanica - suicide suicide resource box on the side of the page, depression (psychology) crisis information within the first paragraph, no information on article "bipolar disorder", no information on article "schizophrenia".
Encyclopedia.com - suicide basics discusses suicide hotlines existing but no specific links/numbers, depression again discusses their existence, and recommends checking "telephone books' [...] Community Service sections [... or] calling emergency services (911 in most places) but this is at the bottom of this long page. Has an article on "crisis intervention" that doesn't list specifics or how to find. Nothing on article "substance abuse". Of note, however, is that some of these articles have "resources" sections that do list specific phone numbers and/or websites for organizations providing hotlines.
The biggest issue people have with us including them is "scope" or similar. These arguments necessarily reference what Wikipedia is not - either directly or through essays/etc. Relevant policies, guidelines, and essays that have been referenced before or likely to be referenced now are below - along with my analysis of why they don't preclude mental health information from being provided on pages:
From WP:NOT: Advertising, marketing, publicity, or public relations... or issuing public service announcements - nobody's asking for "public service announcements" style of information. What people are asking for seems to be similar to what The Canadian Encyclopedia publishes on their articles directly about suicide. Also from WP:NOT: Simple listings without contextual information showing encyclopedic merit. Listings such as the white or yellow pages should not be replicated. - this is referencing actual lists that are not encyclopedically relevant, not what's being requested here.
From WP:ADVOCACY: Wikipedia is first and foremost an encyclopedia which aims to create a breadth of high-quality, neutral, verifiable articles and to become a serious, respected reference work. - as shown above, many encyclopedias do publish resources as part of their encyclopedic mission. Also from Wikipedia:Advocacy § Identifying advocacy: Some editors come to Wikipedia with the goal of raising the visibility or credibility of a specific viewpoint. It may be a hypothesis which they feel has been unduly dismissed or rejected by the scientific community; it may be alternate or revisionist interpretation of a historical event or personage; it may be additions to an article about an organization to portray it in a positive or negative light. The essential problem is that these goals conflict with Wikipedia's mission. Wikipedia is not a venue to right great wrongs, to promote ideas or beliefs which have been ignored or marginalized in the Real World, or to be an adjunct web presence for an organization. Wikipedia cannot give greater prominence to an agenda than experts or reliable sources in the Real World have given it; the failure to understand this fundamental precept is at the root of most problems with advocacy on Wikipedia. - resource information is not advocacy by any definition. The only applicable part of this could be "an adjunct web presence for an organization", but even that doesn't really apply, since nobody is advocating for any specific organization to be represented, but general information. The potential for the resources to be used to advocate for specific organizations can be handled through guidelines on how the specific information displayed is to be selected, where it is to be displayed on the page, and carefully selecting which pages they do display on.
No Righting Great Wrongs is also commonly referenced - but it doesn't apply here. You might think that Wikipedia is a great place to set the record straight and right great wrongs, but that is absolutely not the case. While we can record the righting of great wrongs, we can't actually "ride the crest of the wave" ourselves. - there is no "record" attempting to be "set... straight", and in fact, we wouldn't be "rid[ing] the crest of the wave ourselves". Many encyclopedias that are online include these resources already, and in fact many non-encyclopedia websites do too. We would be following, not leading, in that sense.
The 5 pillars - Wikipedia is an encyclopedia - Wikipedia combines many features of general and specialized encyclopedias, almanacs, and gazetteers. - again, as showed above, encyclopedias do contain this sort of information sometimes.
Wikipedia:No disclaimers - A disclaimer in a Wikipedia article is a statement or warning that the article is not appropriate, suitable, or guaranteed for some specified purpose. - again, not what's being requested here. While some may desire for these notices to include a statement about what is included in the article, that is not what the basis of this is about. Again, see The Canadian Encyclopedia - a simple statement To reach the Canada Suicide Prevention Service, contact 1-833-456-4566. would suffice, even without the first sentence they include about the content of the article.
Wikipedia:External links - External links normally should not be placed in the body of an article. Nobody is proposing they be placed in the body of the article, but instead in a header or infobox style. And to note, infoboxes already allow external links in them, so there's a huge precedent for external links not being relegated to the bottom of the page when placing them at the top is more useful to our readers. Some acceptable external links include those that contain further research that is accurate and on-topic, information that could not be added to the article for reasons such as copyright or amount of detail, or other meaningful, relevant content that is not suitable for inclusion in an article for reasons unrelated to its accuracy. Pretty clear that this is "further research..." and is "other meaningful, relevant content that is not suitable for inclusion in the article".
Arguments are also made that the information may become outdated, become malicious, not work when a reader clicks them... but these sorts of arguments don't affect our ability to put other external links in articles, even in the infobox. As always, Wikipedia is never finished, and these notices could be crafted in a way that allows (trusted) editors to update them when necessary. And that's actually the benefit of an online, everyone-can-edit encyclopedia over a print one - a print encyclopedia would not be able to be updated on the spot if/when resources change. Hence why I do not think comparing us to print encyclopedias here is reasonable - because they do have this as a valid reason to not put information into their print versions.
Last thing I'll address in these bullet points is the question of liability that Donald Albury brings up above. To make a slight correction, we do not have disclaimers on medical articles - but the reason we don't is the general disclaimer at the bottom of every page on the wiki. We also have the medical specific disclaimer, but that isn't actually linked directly from the bottom bar, and per our guidelines on disclaimers, shouldn't be linked in specific articles either. If those disclaimers suffice to protect us from liability from pages that explicitly detail current medical practice, and even more so, pages like crisis hotline, rape, suicide, and more to have external links to, phone numbers for, information about, and images that reference them now... then those same disclaimers will protect us if the same information is presented in a different manner/place on the page. If this sort of proposal is further developed, it would be prudent to confirm with legal the wording/etc to ensure they're aware - but they've really never prior regulated the wording of content in that sort of way.
To be quite honest, this is a stylistic decision, and only a stylistic decision. Not an issue of whether it's encyclopedic or not, because other online encyclopedias do include this information at least sometimes (and again, we follow, not lead). Not an issue of whether a link would violate our policy on external links, because such links would meet the three criteria listed there: Is the site content accessible to the reader? Is the site content proper in the context of the article (useful, tasteful, informative, factual, etc.)? Is the link functioning and likely to remain functional? (emphasis mine). It's not trying to right a great wrong, because there is no "great wrong" being righted, this would be purely informational in nature. It's not a disclaimer, because nobody's suggesting this be simply be a warning about what follows in the article (which would be a disclaimer), but to more prominently place relevant and helpful information towards the top of the article in some way. Not advocacy, because nobody is suggesting we advocate for anything - providing this information at the top of the article(s) in question would serve an informational purpose for our readers. While it's certainly within us editors' discretion as a community here to decide "we don't want to provide this information", there's really no policy reason that we can't. And even if there was, If a rule prevents you from improving or maintaining Wikipedia, ignore it. Wikipedia exists to be an encyclopedia - "A comprehensive reference work (often spanning several printed volumes) with articles" - and to provide useful articles for readers... in a way that the reader will understand and find interesting. Whether we want to admit it or not, some readers will be directed to Wikipedia when they are searching for information about suicide, mental health, rape, etc. and currently, the primary place they will see it is the very end of articles in External Links - which does not serve our readers who will in a time of distress see a long article and likely never make it to the EL section. For all of the above reasons, I support further discussion, and workshopping of an infobox or top-banner style notice to be placed on pages that would provide this information. I would be happy to workshop some examples of formatting if it would be beneficial to this discussion or an eventual RfC, but I would need others to input on the best way to provide geographically relevant information - is it that the banner links to a separate page (whether in article space, project space, or elsewhere) that contains resources by country/location? Or is it the use of geo-notices as proposed here? Or is there another way that wouldn't require the user to click through to a separate page? -bɜ:ʳkənhɪmez (User/say hi!) 01:00, 25 June 2024 (UTC)[reply]
"Whether we want to admit it or not, some readers will be directed to Wikipedia when they are searching for information about suicide, mental health, rape, etc. and currently, the primary place they will see it is the very end of articles in External Links" That's funny. I would have thought that the primary place they would find such information is the articles themeselves. If I were looking for help, therapy, treatment, etc for such things, I wouldn't go to the article about them. I would do a search for "suicide helpline" or "rape crisis center", etc. Sorry, but you still fail to show that WP:NOT doesn't apply. User:Khajidha (talk) (contributions) 13:26, 25 June 2024 (UTC)[reply]
It's completely reasonable that someone that suspects they may have a mental health problem may do research about it to see if it really does line up with what they're experiencing. Providing this information in no way detracts from the usefulness of Wikipedia- the only possible effect is positive. Ju1c3machine (talk) 13:47, 25 June 2024 (UTC)[reply]
I am the original poster- I'm saying that if someone is researching a condition, it might be because they're thinking they have it, so including resources would be helpful. Ju1c3machine (talk) 14:31, 25 June 2024 (UTC)[reply]
Which are you looking to add 1) details about the disorder to "see if it really does line up with what they're experiencing" or 2) places to go for an actual diagnosis, because these are different things. The first is encyclopedically relevant, the second isn't. --User:Khajidha (talk) (contributions) 14:46, 25 June 2024 (UTC)[reply]
I'm asking to add resources such as official government sponsored hotlines, because if someone is on the page for a mental illness they think they might have, where to find treatment is relevant and helpful information. Ju1c3machine (talk) 17:57, 25 June 2024 (UTC)[reply]
No, the most likely effect will be that more people will rely on Wikipedia to give them information about helplines, etc., rather than on more relevant and more complete websites. Chaotic Enby (talk · contribs) 17:32, 25 June 2024 (UTC)[reply]
As mentioned before, news sites commonly include hotlines at the end of articles about suicide- I don't think anyone has drawn the conclusion that they should head to the NYT for mental health information. Ju1c3machine (talk) 17:58, 25 June 2024 (UTC)[reply]
I don't see an issue with making a cat hall page to list "recognized" resources for mental health type issues, with "recognized" being either official govt resources (like 988 for the Suicide hotline) or from expert, well known medical organizations in that area. Since these can vary by country, a separate page makes sense, and which could be highlighted by a color keyed navbox. Masem (t) 14:21, 25 June 2024 (UTC)[reply]
I definitely agree that we might want to limit resources to those that are official/government funded instead of random organizations. Ju1c3machine (talk) 14:32, 25 June 2024 (UTC)[reply]
How many official/government contact points are we talking about? There are 193 members of the UN plus a few other generally recognized sovereignties, some breakaway states, a number of dependent territories, and many sub-territories (states, provinces, etc.), each of which may have their own resource contact points. So, do we concentrate on providing contact information only for political units with large populations? Sending people to on-line contacts which do not have a local presence will often not be enough. In some places, directing people with problems to official contacts may not be the best way to help them. Maintaining all of that information (protecting it from link-rot, vandals and well-meaning but ill-informed editors) is going to require work from volunteers (edit-protection or pending changes may help, but is not perfect). I am afraid that, based on the typical level of maintenance in Wikipeida projects, a page such as proposed here will end up giving unusable or even harmful information to people seeking help. Donald Albury16:28, 25 June 2024 (UTC)[reply]
For article content, when the full list isn't feasible, we usually focus on large English-speaking countries plus anything with significance (the oldest, the biggest, etc.).
If this is on a separate list page, there is no reason not to include them all. One or multiple tables (organized by continent) can make for easy navigation. Subpages could be made for North America (US states and Canadian provinces) and any other country where there is such significant lower level govt involvement. — Masem (t) 16:44, 25 June 2024 (UTC)[reply]
I like the idea of a separate page or a template similar to a navbox, but I think that should only be a partial solution. Again, many articles already include resources (of varying quality and number) at the bottom of the page in the external links section. So adding more resources even further down on the page doesn’t really improve anything here. Maybe I misunderstood you? But I’d prefer it to be an info box style template (whether above, below, or incorporated into the info box if the article had one) with a sentence inviting people to click a link if all they want to see is the resources without having to scroll the article. -bɜ:ʳkənhɪmez (User/say hi!) 18:56, 25 June 2024 (UTC)[reply]
On the original idea, of having a section (or paragraph) in articles about various organizations/crisis lines, I think it's a good idea. If the article is organized along the suggested WP:MEDSECTIONS plan, then it would usually go under ==Society and culture==. For example, an article about suicide could mention 1-800-273-8255 (song).
In terms of ==External links==, Wikipedia:Manual of Style/Medicine-related articles#External links has recommended for years that local/city organizations be excluded (because even if we think it's great that one city has a support group meeting on Thursday mornings for that kind of cancer, that's really not useful information for the rest of the world), and that either a small number of national/international groups be considered for inclusion, or a link to a good Web directory (which does not have to be Curlie, and often shouldn't be). WhatamIdoing (talk) 16:37, 25 June 2024 (UTC)[reply]
This is becoming a WP:Perennial proposals issue, but I have several reservations about this practice, however well-intentioned. The evidence of the effectiveness of suicide hotlines is inconclusive.[1] Any endorsement of this health intervention is non-compliant with WP:MEDRS. The inclusion of such resources could a) be taken as condescending by people who have these conditions or b) could encourage faulty self-diagnosis, which would be very problematic. Encouraging the reader to think of their subjectivity as a potential victim of an illness can have deleterious psychological effects. Further, as Donald Albury notes, the work of actually verifying that any given hotline, even if government-sponsored, is actually sincere in its mission and serves to help those who call it represents a massive amount of volunteer effort on a global scale, with a very real risk of sending people to crisis lines that will cause them harm (due to insufficient patient privacy protections, due to inadequately trained personnel or ideologically rather than scientifically-driven therapy practices, etc.). The framing of this entire question feels like a response to a school-assembly PSA: why depression and anorexia? Why not schizophrenia, or BPD? What about illnesses that are not primarily mental, but which almost certainly see a significant amount of traffic from people who suspect that they've contracted them, such as gonorrhea or COVID? Crisis hotline disclaimers are a feel-good solution in search of a problem, and we will certainly find a can of worms' worth of problems if we implement it. signed, Rosguilltalk17:09, 25 June 2024 (UTC)[reply]
OP here- you might note that the original post uses anorexia as an example- if there are help lines for BPD and schizophrenia then I think those should be added as well. I"m not weighing in on physical illnesses because that's very clearly a matter for doctors, and it's a bad-faith argument to compare the two. "Here's where people that have this can get help'" is in no way condescending or encouraging self-diagnosis, and I'm pretty confused on how you drew that conclusion from what I said at all. Ju1c3machine (talk) 18:06, 25 June 2024 (UTC)[reply]
I agree that it needs more discussion on what article(s) or topics this would display on. But the mere fact that discussion and hashing out are needed shouldn’t preclude a proposal from moving forward. -bɜ:ʳkənhɪmez (User/say hi!) 18:57, 25 June 2024 (UTC)[reply]
I think it was warranted after the previous discussion in April, following the two in September2022, following the one in 2019. I just didn't get around to it then. But once this one goes the same way with respect to banners or notices in the lead, we can re-add it. 🤷 Anomie⚔23:03, 27 June 2024 (UTC)[reply]
But will it? So far, I see nobody objecting to adding some information about the existence and work of support organizations in the body of the article. I think that means there is support for including that information. WhatamIdoing (talk) 01:51, 28 June 2024 (UTC)[reply]
I didn't reply under section break 3, but I am very much not opposed to adding information about support organizations in a verifiable and WP:DUE encyclopedic way. What I take issue with is a list of miscellaneous external links, but that's something else. Chaotic Enby (talk · contribs) 04:23, 28 June 2024 (UTC)[reply]
Whoops, sorry, just woke up and operating pre-coffee over here. I do think that having a separate page of resources sorted by country is the best solution at this point, but I do feel like it's going to spiral into me creating wiki articles for each organization and their work/history eventually... Ju1c3machine (talk) 04:37, 28 June 2024 (UTC)[reply]
The idea needs some workshopping and refinement, but I support in principle. The page/template would need to be 30/500 protected at minimum, but full or templateeditor protection would be preferable because it would be a definite target for trolls. It might also be worth opening a dialogue with the Foundation to see if they or Trust & Safety might want to give some input. They might even have some resources or a grant for maintaining it. The WordsmithTalk to me17:19, 25 June 2024 (UTC)[reply]
Pages aren't protected preemptively, and trolls are virtually never extended-confirmed so I don't see what full protection would bring in this case, except making it much harder to add new entries assuming the proposal goes through. Chaotic Enby (talk · contribs) 17:25, 25 June 2024 (UTC)[reply]
Articles are usually not pre-emptively protected, though there are some exceptions like Today's Featured Article when it's on the Main Page. Other high-risk pages like the Main Page itself are protected, and we have an entire guideline allowing high risk templates to be pre-emptively protected on a case-by-case basis. Regarding the WP:NOT argument, I think there's a valid WP:IAR exemption that can be justified on humanitarian grounds. The WordsmithTalk to me17:42, 25 June 2024 (UTC)[reply]
Today's Featured Article is only preemptively protected because previous TFA were repeatedly targeted, and is still only semi-protected. The only preemptively full or template-protected pages, high-risk templates are protected because they are transcluded on tens of thousands of pages and can cause immediate widespread damage to the encyclopedia, while not needing regular updates. A list of information on many organizations will definitely need regular updates, while not being transcluded to the same scale as citation or infobox templates, so full protection is very much not needed. Chaotic Enby (talk · contribs) 18:20, 25 June 2024 (UTC)[reply]
Sorry, but this still falls under WP:NOT. You have still not demonstrated why Listings such as the white or yellow pages should not be replicated. does not apply here, especially with the proposal of making separate pages for this information. Chaotic Enby (talk · contribs) 17:29, 25 June 2024 (UTC)[reply]
Information on organizations that treat or provide assistance with a disease is objectively relevant to the Wiki pages aimed to provide information about that disease. Even if that were not the case, I also agree with The Wordsmith on there being a valid exemption to the rule for humanitarian reasons. Ju1c3machine (talk) 18:10, 25 June 2024 (UTC)[reply]
See WP:NOTIAR. As pointed by multiple people above, it is not even clear that this would be an improvement to begin with, let alone an improvement to our purpose of being an encyclopedia, and making an exception for "humanitarian reasons" would open the door to a lot more non-encyclopedic stuff that could be justified on the same grounds (humanitarian fundraisers, advocacy groups, etc.) Chaotic Enby (talk · contribs) 21:02, 25 June 2024 (UTC)[reply]
I'd like to point out the post from bɜ:ʳkənhɪmez above- I agree that is is an improvement to our purpose of being an encyclopedia, given that other encyclopedias include this information. Ju1c3machine (talk) 10:05, 26 June 2024 (UTC)[reply]
I addressed this in my comments above. Encyclopedias exist to serve their readers. And sometimes this means we bend the “not a white pages directory”, whether in lists with links to our own articles or lists with external links. -bɜ:ʳkənhɪmez (User/say hi!) 18:59, 25 June 2024 (UTC)[reply]
While, yes, encyclopedias exist to serve their readers, that doesn't mean that anything that is potentially useful has to go in an encyclopedia. Lists with links to our own articles aren't anything like a white page directory, and I don't think anyone here would object that a list of notable helplines wouldn't be encyclopedic. But a standalone repository of phone numbers/external links, while useful for some readers, wouldn't be more encyclopedic than a software changelog. WP:USEFUL is not an argument for IAR. Chaotic Enby (talk · contribs) 19:59, 25 June 2024 (UTC)[reply]
Anything can be an argument for IAR - if it's an improvement. You say it's not encyclopedic, then why do other online encyclopedias generally include them on at least some pages - see above? Further, nobody is suggesting that the list be put in mainspace. -bɜ:ʳkənhɪmez (User/say hi!) 20:33, 25 June 2024 (UTC)[reply]
I strongly oppose including any kind of out-of-band helpline links, both for the practical reasons already identified (vetting that they are legit; keeping them up to date; normalising the expectation that Wikipedia is a place to get medical advice) and because there is very limited evidence these things are helpful, and the possibility that they are actively harmful, causing ideation that may not otherwise have crystallised. Barnards.tar.gz (talk) 19:41, 25 June 2024 (UTC)[reply]
I can see your point behind causing ideation for something like suicide, but don't see how that relates to other topics, like eating disorders or bipolar disorder. Seeing a phone number for either of those isn't going to make someone 'start' being bulimic or bipolar. Ju1c3machine (talk) 09:46, 26 June 2024 (UTC)[reply]
I'm not saying that a phone number is going to cause a mental illness, just that mental illness, generally speaking, is a complex phenomenon and its contributing factors are not well understood. I think it is at least plausible that reading an article which is written in a dispassionate, detached, neutral tone, will have a different psychological impact to reading a warning notice that personalises the interaction by suggesting that you might want to call this number if you are affected. This isn't a peer-reviewed comment. It may be an unfounded concern. But this proposal is a public health intervention, so I'd want to have a steer from a medical authority of some sort that it isn't going to cause more harm than good. Barnards.tar.gz (talk) 16:20, 26 June 2024 (UTC)[reply]
Note - I sandboxed the easiest method of doing this at the top of the page - adding to the infobox either above the image or at the bottom of the infobox - I don't really like either of these ideas since I think that it makes the statement less prominient than it should be, but you can see them here. Of note, I didn't expect WP:Mental health resources to be a blue link. It's a soft redirect to meta:Mental health resources. So it appears that Trust and Safety has already gotten rid of any liability concerns through the normal disclaimers/etc. And obviously it can be maintained, as they are doing it. I think the mere fact this page exists and has been approved by Trust and Safety means that any argument based on "we can't keep it updated" can be put to rest permanently. It would be ideal to have a version of that page adopted to the English Wikipedia however. -bɜ:ʳkənhɪmez (User/say hi!) 20:31, 25 June 2024 (UTC)[reply]
I like the sandboxed version (and think at the bottom of the box looks better than at the top from an aesthetic point of view), but that then raises the issue of having to create another page to link to for each illnesses' resources- instead of this just being acceptable to add to a page, it would require creating an entirely new page and linking it, which seems like a bit bigger of a project than I originally intended for. That being said, I really do like the way that Wikimedia's page is formatted, and wonder if it would be possible to create one page for helplines and link to individual sections that are relevant for each topic. Ju1c3machine (talk) 20:44, 25 June 2024 (UTC)[reply]
In this case, it could be good to have it outside of mainspace (possibly in projectspace instead), and a hatnote at the top of the page would be a more elegant solution than an infobox, as the latter is intended to summarize information. Chaotic Enby (talk · contribs) 20:47, 25 June 2024 (UTC)[reply]
A hatnote would be an option, but then you run into issues of "what if a page already has a hatnote"? I know some pages have long hatnotes, but this should really be separate from a hatnote for disambiguation, redirect, etc. reasons, as it's completely separate. I was going to try to sandbox a new "infobox" similar to the topic navigation boxes that show on suicide and other topics, but after everything moved to modules (which is great, don't get me wrong) I really can't be arsed. -bɜ:ʳkənhɪmez (User/say hi!) 21:29, 25 June 2024 (UTC)[reply]
I'm happy for anyone to edit it to be better, but I don't think a simple link to a list without a sentence isn't going to be what is ideal here. If that's all people are okay with it's better than nothing I guess. -bɜ:ʳkənhɪmez (User/say hi!) 00:52, 28 June 2024 (UTC)[reply]
Oppose I support anyone applying for money at meta:Grants:Start to develop this idea. Here and every other time this has been proposed, I feel that the early ideas are more harmful than good. Problems include
English Wikipedia is a global service, but there are no crisis support services that are global. There are not even enough regional support services to be satisfactory.
Services are not neutral. Many of them take positions on ethics and values. For example, some crisis hotlines may advise people that their lives will be better if they quit being LGBT+. We should not recommend an external service without having a process to report and evaluate them.
Wikipedia is not prepared to recommend products and services. If we start doing this, then certain organizations get government, foundation, and other funding and while others do not. Organizations will pay staff to persuade Wikipedians, sponsor Wikipedians to travel, send their staff people to conferences, talk about the partnership in the media, and advise the wiki community with expertise that is difficult to evaluate. Managing endorsements requires staff, and the first step is not to make endorsements to see what happens.
Very good point, especially regarding the non-neutral position that Wikipedia would have to take when recommending services. These are not comparable to external links, which are just showing links where relevant information can be found, without recommending the services provided in these links. It's not even a question of "managing endorsements would be complicated". Managing endorsements would make us fundamentally non-neutral. We shouldn't be recommending products and services to begin with. Chaotic Enby (talk · contribs) 16:02, 26 June 2024 (UTC)[reply]
A free-to-use government-sponsored emergency hotline is neither a service nor a product. All of the arguments above can easily be handled by just providing official resources. Additionally, the anti-LGBT hotline falls under WP:FRINGE and isn#t relevenat to the current discussion. Ju1c3machine (talk) 16:07, 26 June 2024 (UTC)[reply]
A free-to-use government-sponsored emergency hotline is neither a service nor a product. It is, by definition, a service. And anti-LGBT hotlines are relevant to the discussion because, sadly, some countries' official resources are anti-LGBT. Chaotic Enby (talk · contribs) 17:16, 26 June 2024 (UTC)[reply]
Some countries consider LGBT people to suffer from mental illnesses. You very likely don't want to call a government hotline in Qatar to effectively turn yourself in for being gay. Headbomb {t · c · p · b}12:41, 27 June 2024 (UTC)[reply]
WP:FRINGE or not, if you're recommending government hotlines, that's the kind of stuff you risk having in more than a few countries. And given that the readers we link the hotline to will likely trust it enough to share personal details (even if just for the needed context), some of them will actually risk ending up in that situation, with the hotline possibly blaming their LGBT identity as the cause for their condition, even if they didn't reach the hotline through a specific "homosexuality as a mental illness" page. Chaotic Enby (talk · contribs) 14:33, 27 June 2024 (UTC)[reply]
That's definitely something to keep in mind, but I think the discussion should surround what criteria we are used to provide resources that are safe for users instead of "here's why we should scrap the whole idea". Ju1c3machine (talk) 21:43, 27 June 2024 (UTC)[reply]
section break 3, mental health topic
I agree that if there's interest in the idea, the Foundation should be consulted. Normally I'm very opposed to integrating them further into enwiki processes, but this area seems like it would be a logical place for that. Trust & Safety may have even considered doing this already, and might be willing to share and research or insight they have. Maybe they'd even be willing to take care of maintaining the list. It seems like this discussion is to figure out whether there's some interest in the overall idea that's worth developing further, and I think there is. The WordsmithTalk to me16:41, 26 June 2024 (UTC)[reply]
Any advice on how to move forward from here? This is my first time suggesting something like this on wiki, I'm not super up to speed on what the correct process is. Ju1c3machine (talk) 17:10, 26 June 2024 (UTC)[reply]
You wait for there to be a consensus here. IMO it's likely this will turn out much the same as previous times this sort of thing has been brought up: between the questionable impact of helplines and the need to be global, something at the top of the article or in the lead beyond a hatnote like we have on Suicide (pointing to Suicide prevention) is unlikely to be accepted. Similarly, a listing within an article is unlikely to overcome WP:NOT#Wikipedia is not a directory. OTOH, a well-written section in the articles (or standalone article, if independently notable) about types of prevention or support would probably be accepted. Anomie⚔01:52, 27 June 2024 (UTC)[reply]
I think we need to operate on the principle, "first, do no harm". I have not seen any WP:MEDRS-compliant source that says whether such helplines are helpful or harmful or neither. I myself suffer from a mental illess (two in fact) and, though I don't claim to speak for anyone but myself, can see that it is by no means self-evident that helplines, or the promotion of them, actually help. Yes, they provide a nice warm glow to the people that operate them or volunteer for them, but I would probably be adversely affected by the suggestion that I should call one. Phil Bridger (talk) 17:26, 26 June 2024 (UTC)[reply]
I too have mental health issues (+autism, which in my case brings with it a good few issues that do at times interact with my mental health issues), and while I am also not claiming or attempting to speak for anyone but myself, I can confirm your statement beyond a "would be": suggestions of calling a helpline/crisis line have in the past adversely affected me (by setting off an anxiety attack or flashback, mainly), and my experience with actually using such services a handful of times has varied from "slightly helpful" to "harmful". AddWittyNameHere06:33, 27 June 2024 (UTC)[reply]
I'd like to reiterate (again) that I'm not advocating for the "random volunteer tells you to not commit suicide" type hotlines, I'm advocating for the "hello I think I need to get help for my eating disorder, can you please help me make an appointment with a provider in my area" type hotline. Ju1c3machine (talk) 06:54, 27 June 2024 (UTC)[reply]
@Ju1c3machine: I know you are. (Though not everyone in this discussion is, on both sides). That said, those sorts of hotlines would still adversely affect me, simply because they break down the barrier between "abstract concept" and "this (could) apply to me", which is what such hotlines/their mentions within the relevant contexts are based on: someone realizing "this applies to me" and which leads to either realizing they need help (the type of hotline you advocate for) or spiraling and needing more acute intervention (which the other type of hotline is supposed to provide, at least).
I can absolutely see how that would be helpful in a lot of cases, but at least for me personally, that "barrier-breaking" is more likely to do harm than good. By turning an abstract, distant concept (which, sure, I know happens to apply to me too) into something about me, first and foremost (that happens to apply to other people too) may bring on the "this is talking about me, remember that time when you [...] oh and that perfectly describes that other time when [...]" spiral of flashbacks depending on my state of mind at the time.
Of course, my experiences are my own, and like I said, I can see how it would be helpful in plenty of cases. But that it can do harm alongside good is something I feel should be weighed into decisions. AddWittyNameHere07:37, 27 June 2024 (UTC)[reply]
I can see your point, but also think that it has potential to do a lot of good- for example, I have ARFID, and a suggestion on the page to get help might have saved me a lot of struggle instead of thinking that my eating disorder was just "how I am" or "picky eating", and something worth getting help for. Not to get too personal, but my delay in getting help has lead to being diagnosed with heart disease, likely as a consequence of malnutrition- something that could have been avoided if I had known where to go to get help for it sooner. Ju1c3machine (talk) 12:03, 27 June 2024 (UTC)[reply]
Likewise, I can also see your point. It has potential to do both good and harm, alongside what's likely the greater bulk of cases—folks to which the issue described does not apply, particularly—in which it has negligible to no impact at all. I do wish there was a better way to figure out how much harm it would prevent vs cause, but if wishes were fishes...
So, barring that, my main reason for mentioning the point (both here and elsewhere in the section) is to ensure that its potential for causing harm alongside preventing it is taken into consideration, in part in whether this is a good idea, but especially in, if it is decided it is a good idea, what way to implement this and what group of articles to apply it to.
(As for too personal, I think sometimes getting personal in discussions about matters like this and accessibility concerns can be pretty useful by illustrating how a change could be/have been helpful (or harmful) in a non-hypothetical manner.) AddWittyNameHere04:44, 28 June 2024 (UTC)[reply]
I've also added a note to the talk page of the meta page for anyone with experience in how this page is used, or from the WMF, to comment here if they so desire. -bɜ:ʳkənhɪmez (User/say hi!) 17:43, 26 June 2024 (UTC)[reply]
@Berchanhimez: WMF Trust and Safety is great for what they do. They should not change anything.
However, when resources are scarce and the Wikimedia user community wants something versus the Wikimedia Foundation wanting something different, then T&S is going to side with the WMF. In general, T&S prioritizes protection where the WMF as a corporation could be legally liable. T&S do not prioritize lower level safety issues, and if for example, we had democratic governance, then most Wikipedians would vote to eliminate the common familiar problems and not the rare emergency problems. I am not saying that democracy is good or bad in this case, just that the majority of requests/votes would be for things that T&S does not do.
It is not appropriate for the Wikimedia community to freely edit that page on meta. Some pages on meta are sort of owned by WMF staff, and that is one of them. I support that page being there, but it being there does not indicate universal consensus to endorse driving traffic to it or its contents. When a lot of WMF staff edit a page then editors get scared away from raising criticism or concerns or problems.
Again, I support anyone applying for a grant to document all the social and ethical issues that come from making crisis referrals to organizations outside of our platform, and to just take this seriously. Bluerasberry (talk)18:01, 26 June 2024 (UTC)[reply]
I don’t think we’d necessarily need to edit that page or maintain a local copy - even just linking to that page directly in the hatnote (or whatever is decided) would suffice. I can’t really tell what your opinion is - at first, it was reading as that it’s “not possible” to make such a page, but Trust and Safety already has done so and apparently they’re not concerned with the liability from it at all, nor linking/directing to those specific organizations. I’m not suggesting that page is evidence of a consensus - that’s what this discussion is for - but that page is evidence that Trust and Safety has already thought about the issue of “which organizations” and our liability and decided that they are either non-issues or can be properly managed by them vetting the links. -bɜ:ʳkənhɪmez (User/say hi!) 18:28, 26 June 2024 (UTC)[reply]
The WMF can do whatever they want on MetaWiki, but having a corporation-vetted list of services masquerading as an encyclopedia article is not what Wikipedia is for. There isn't even evidence that it would be helpful, let alone that it would be a justified WP:IAR improvement to the encyclopedia. Chaotic Enby (talk · contribs) 19:05, 26 June 2024 (UTC)[reply]
Nobody is suggesting this would “masquerade as an encyclopedia article”, so statements like that are less than unhelpful. -bɜ:ʳkənhɪmez (User/say hi!) 20:22, 26 June 2024 (UTC)[reply]
I wonder whether the people supporting this proposal would advise people with cancer or heart disease (or arthritis - I have never considered suicide as a way out of my mental problems, but I would do just about anything to get rid of the pain when my arthritis flares up) to phone a well-meaning amateur rather than seek professional help? Phil Bridger (talk) 19:11, 26 June 2024 (UTC)[reply]
I can see this point being made for suicide crisis lines, but the types of resources I had in mind are the kind where you can call and someone helps walk you through finding professional help in your area. Ju1c3machine (talk) 19:14, 26 June 2024 (UTC)[reply]
Wow! It's almost like that's not the point of the proposal, and that consolidated information should be available from the page itself for easier access to those needing help. You can't argue both "we can't do this because the resources are hard to find" and "we don't need to do this because the resources are already super easy to find somewhere else", that's absurd. Ju1c3machine (talk) 04:18, 28 June 2024 (UTC)[reply]
The person that replied before you argued that it was hard to find resources, which I disproved, and then you said we don’t need to because it’s easy to find resources. Since when does “you can find this information somewhere else” mean that it doesn’t belong on Wiki? Ju1c3machine (talk) 08:14, 2 July 2024 (UTC)[reply]
People with cancer aren’t at risk of dying imminently by suicide if they don’t find another path forward. Your suggestion comes closer to a general “medical disclaimer” that’s explicitly not appropriate on Wikipedia. Offering people an option other than “keep looking at articles about depression/suicide until you do it or get tired of it” isn’t the same thing as “contact your doctor to discuss medical concerns”. Attempting to make that analogy minimizes the urgency of suicide prevention. -bɜ:ʳkənhɪmez (User/say hi!) 20:24, 26 June 2024 (UTC)[reply]
People with cancer aren’t at risk of dying imminently by suicide if they don’t find another path forward. - they well might. Cancer comes with elevated suicide rates, particularly when the prognosis is poor and/or quality of life is significantly, long-term impaired—concerns about the former and ways of hopefully tackling the latter are both better discussed with a doctor than an amateur volunteer without access to your medical information.
Offering people an option other than “keep looking at articles about depression/suicide until you do it or get tired of it” isn’t the same thing as “contact your doctor to discuss medical concerns”. Going to be a little more explicit here about my mental health/experiences with mental health crises than I would otherwise be: in my case, that "offered option" would increase rather than decrease the risk I am at.
From experience, if not actively struggling, looking at [clinical representations of/distant mentions of] suicide and depression with or without mention of hotlines is unlikely to set off my suicidal ideation and related matters.
If I am struggling, however, without such hotlines it makes it a distant and clinical concept, which has helped me distance myself from such thoughts a time or two. On the other hand, with hotlines (and especially when those are directed at the reader) provided, it breaks the barrier that makes it an abstract concept and turns it into "something I might feel tempted to do/could do". Which tends to make my ideation a lot less abstract and my intrusive thoughts more intrusive. (That my experiences with crisis lines are a mixed-leaning-negative bag including two cases that set off my anxiety if reminded of them at the wrong time does very much not help there)
Of course, I am just one person, and my personal experiences don't apply to everyone. I'm not saying "it is harmful to me, therefore it must be harmful in general". But there does seem to be a tendency (in general discourse, not you specifically, nor even this discussion specifically) to gloss over the fact that the presence of such reader-directed hotlines might cause some people harm, too. It might well be that on the whole, that harm of their presence is outweighed by the harm of their absence—but that's impossible to determine without first taking into account that there is harm on both sides of the coin. AddWittyNameHere07:18, 27 June 2024 (UTC)[reply]
I'd like to ask that that discussion stays on topic to my original proposal, which was to add resources for where someone can find treatment options for mental health problems, not suicide hotlines themselves. My suggestion was prompted by friends of mine with mental health problems wishing there were easier ways to get help- in some countries, there are easier ways to get help, and I believe adding them might help make those options more widely known, especially when (as mentioned before) someone is reading Wikipedia to learn more about a condition that they didn't know was the reason behind their maladaptive behavior. Ju1c3machine (talk) 11:39, 27 June 2024 (UTC)[reply]
Suicide hotlines are easy: We can link to List of suicide crisis lines, which already exists (for more than a decade), already is sourced, etc., and we're done.
I think the more interesting area is non-suicide social support. So to answer the question from @Phil Bridger, I would recommend a peer-led support group to people with cancer. People with cancer who join peer support groups tend to live longer and have better quality of life than people who don't. Support groups are mentioned, e.g., in Breast cancer#Society and culture. Note that it doesn't say "If you live in Ruritania, contact the Ruritanian Cancer Support Group"; instead, it has encyclopedic information about the earliest support group for breast cancer. Someone could expand that article content if they wanted to; the result would probably say something like some are organized through hospitals and there are a bunch on social media. It might even touch on the practice of having separate support groups for women who are highly likely to survive vs those at risk of treatment failure and death.
I don't know if there are similar groups for heart disease. Part of what seems to make a peer-led support group work is having everyone more or less in the same situation, so it might not be "heart disease", but instead for people with a specific type of heart disease.
Resources that I had in mind when I posted the proposal (not meeting the criteria of 'maybe we should stick to government-sponsored organizations' because I don't have time at the moment to do research and I happen to know of these off the top of my head) would be NEDA and ANAD, whose hotlines connects individuals with treatment options (ANAD was the first ED hotline to exist which I think is also a neat fact to stick in an article somewhere), EatRight, which has a directory of nutritionists and dieticians (who are an essential part of recovery, as people with EDs need a very specific diet to avoid refeeding syndrome), NAMI, which provides general mental health group support, and Eating Disorders Anonymous, which might be a helpful tool for someone who doesn't need traditional inpatient treatment. Ju1c3machine (talk) 04:32, 28 June 2024 (UTC)[reply]
Slightly more awake addition to this: Eating Disorders Anonymous is also a good resource for those who can’t access inpatient treatment, but it’s an option many in ED communities are completely unaware exists, so I believe linking that one specifically would have a rapid positive impact on those affected, especially for users in the US (where it can be prohibitively expensive and/or not covered by insurance) and the UK (where I’m less familiar with the topic, but believe there are also some issues there with waiting times and quality of treatment facilities). Ju1c3machine (talk) 06:03, 28 June 2024 (UTC)[reply]
I have to confess that I have never really understood the overall meme of mental health hotlines. You see them in a bunch of cases (notoriously, near the ends of subway platforms). My main experience with them is that they are obnoxiously and insistently slathered over my screen if I try to look something up which happens to be tangentially related to a contentious mental health topic. The impulse is very easy to understand, as it's a syllogism you see all over the place: "suicide is a tragedy, something should be done about tragedies, and this is something". Here is something to consider: many of our readers get to Wikipedia by way of a search engine. If you search for "suicide" you're already forced to scroll past a full screen's worth of paternalistic lecturing from Google LLC, so are we actually providing any benefit by making our readers sit through a second one after they click the Wikipedia link? jp×g🗯️00:43, 7 July 2024 (UTC)[reply]
If you don't believe me, here is what you see when you Google "suicide" (I am in California so your results may vary):
From International Association for Suicide Prevention · Learn more
If you’re struggling, it’s okay to share your feelings. To start, you could copy one of these pre-written messages and send it to a trusted contact.
Reach out
Contact a loved one
Express your feelings
When you get a chance can you contact me? I feel really alone and suicidal, and could use some support.
I don’t want to die, but I don't know how to live. Talking with you may help me feel safe. Are you free to talk?
This is really hard for me to say but I’m having painful thoughts and it might help to talk. Are you free?
For informational purposes only. Consult your local medical authority for advice.
After this, there are three videos hoisted to the top of the results: "Suicide: Facts & Misconceptions You Should Know", "How Do I Ask For Help If I’m Thinking About Suicide?" and "Teen Suicide Prevention". All of this takes up about a full screen on a normal computer. Then you scroll down past another screen or so of offically-approved links to suicide hotlines (one from the California State Portal, one from the CDC, one from the NIH, and then one from the WHO). Only then, after Google has diligently eliminated all possible sources of legal liability (e.g. repeated CYA disclaimers about "consult your local medical authority") do they permit the Wikipedia link to appear. I copied the full text content of the search results page into a reading-time estimator, and it gave me 1:54. This means that someone who clicks on the link to Suicide from a Google search does so after having spent nearly the entire runtime of Led Zeppelin - IMMIGRANT SONG.mp3 having helpline numbers shoved in their face. Are we really, genuinely, helping this person, or are we just making ourselves feel better, at the cost of diminishing their ability to read the article? jp×g🗯️01:04, 7 July 2024 (UTC)[reply]
I don't think anyone is suggesting something intrusive that would diminish someone's ability to read the article. The suggestions I've seen so far are a hatnote style one line at the top which would likely be in italics, or an addition to the infobox, or a small box above/below the infobox with a page of resources linked to from it. -bɜ:ʳkənhɪmez (User/say hi!) 01:07, 7 July 2024 (UTC)[reply]
If you read the conversation, we are talking about a small link to mental health resources for issues that are not suicide. I would appreciate it if this conversation would stop getting derailed by what I was unaware is a controversial topic. I recognize that there are mixed opinions on suicide resources and warnings, which are numerous- this is not the case for other mental health issues, such as eating disorders, or this conversation wouldn’t be taking place. Ju1c3machine (talk) 04:06, 7 July 2024 (UTC)[reply]
I wouldn't say it's getting derailed. Suicide is the option that has the most pre-existing consideration within Wikimedia Foundation projects (see WP:Mental health resources) and is also the one with the most correlation in other encyclopedias/etc. Yes, it's divisive, but those opposing them for their "efficacy" are opposing all mental health resource links for their efficacy from what I can see. -bɜ:ʳkənhɪmez (User/say hi!) 05:36, 7 July 2024 (UTC)[reply]
I don't see a lot of evidence that people are thinking about anything except suicide. In fact, I added a link to Diagnosis of autism#External links a couple of weeks ago. It's about mental health. It's a resource. It's a link. There's been no opposition, and I expect no opposition (assuming nobody decides to be WP:POINTY after I mention it here). I'm hoping that some readers, particularly high school students writing the predictable paper for health class, will click the link and learn something (e.g., that the diagnostic process for autism involves fairly ordinary personality-type quizzes). WhatamIdoing (talk) 05:45, 7 July 2024 (UTC)[reply]
That's a good data point, but I think the original proposal was for them to be more prominent (i.e. infobox, a box above/below the infobox on the side, a hatnote, etc) rather than relegated to the bottom of the page in EL. I agree that putting them as EL isn't generally considered controversial. -bɜ:ʳkənhɪmez (User/say hi!) 05:54, 7 July 2024 (UTC)[reply]
Ju1c3machine's original proposal here was to have a directory of information in a section within the article. You jumped in early on and started advocating for a prominent "call to action" at the top of the article. Then WhatamIdoing jumped in with some more status-quo options (e.g. external links that could comply with WP:EL and in-article coverage in line with WP:DUE rather than against WP:NOTDIR) but also refuses to accept that people can make a distinction between those and yours.To my eyes, the rest of the discussion seems to have been supportive of WP:DUE and WP:EL, and opposed to top of the article calls to action and to article-space directories other than the already-existing List of suicide crisis lines. Whether the line on more subtle hatnotes has moved from the very subtle one approved in Wikipedia:Village pump (proposals)/Archive 161#Proposal to add suicidal disclaimer at Suicide is unclear. Anomie⚔11:23, 7 July 2024 (UTC)[reply]
I believe that people can make a distinction between different forms. However, I don't believe that putting an oversimplified line in WP:PEREN that says the community has a consensus not to "Add prominent links to crisis hotlines on relevant articles" will result in people making that distinction. WhatamIdoing (talk) 23:30, 7 July 2024 (UTC)[reply]
You believe people won't read more than the heading of anything, so if it's not possible to state as a soundbite then it's not possible to state at all. Anomie⚔10:36, 8 July 2024 (UTC)[reply]
I do not believe that.
I do believe that most people do not read things closely.
I do believe that most editors will not read past the headline when they believe that the headline has told them the whole story, and especially if they want the contents of an oversimplified headline to be the whole story.
See also all the people who see an WP:UPPERCASE shortcut and assume that they know what the policy says – even if the linked page isn't a policy and says the opposite of the shortcut (e.g., WP:VOTE and WP:NOTAVOTE, which point to the same essay; WP:DEADLINE and WP:NOTDEADLINE; WP:NOTWINNING and WP:WINNING; and so forth). This is not a unique problem. The whole internet has problems with people only reading part of the story, and then going out to assert that they really know what's going on because they read – well, not the whole article, but the headline, one caption, and half of the first paragraph. We have a rule against relying on news headlines if you haven't read the whole article, and against relying on abstracts if you haven't read the whole journal article; we would not need those rules if busy people could be relied upon to read the whole thing every time. WhatamIdoing (talk) 01:31, 13 July 2024 (UTC)[reply]
So which is it? We can't add it to WP:PEREN if we can't reduce it to a soundbite because people won't read more than that, or we can add it to WP:PEREN because we have rules against not reading the whole thing and hundreds or thousands of existing rules that already require reading the whole thing to get right? Anomie⚔13:08, 14 July 2024 (UTC)[reply]
Because exactly one person (you) objects, for no reason you can support? 🙄 I don't think that's how consensus is supposed to work. But if you're going to be like that, I suppose we can waste time with an RFC about it after this discussion too closes with consensus against a prominent top-of-article call to action. Anomie⚔11:22, 15 July 2024 (UTC)[reply]
I went with suicide, because it's the one thing where the argument is strongest for including some kind of hatnote or warning label. For e.g. anorexia or bulimia, the case is quite a bit weaker, since there is not a possibility that the person is imminently about to die -- they have just as much time as anyone else, they just have a mental disorder. They are just as intelligent as anyone else, too, and I don't see why we need to give them additional hatnotes on top of an article that's already about the disorder (we don't have hatnotes at the top of bandsaw that tell you to wear safety glasses, or gas metal arc welding that tell you to make sure your ground clamp is connected, et cetera). People with anorexia can read, yes? If you Google "anorexia", you already get reams of stuff about how to get help and where to get help and here's a helpline and et cetera. The intended demographic of this intervention seems extremely small: people who have a mental illness and desperately need help for it, who are wise enough to be reading a Wikipedia article, but not wise enough to be able to type "[name of disorder] help" into a search engine? jp×g🗯️07:24, 7 July 2024 (UTC)[reply]
I think the important thing to remember is that, while yes, many people treat Google as a first source of information, our articles are linked to throughout the web. For all we know, someone's reading an article on some blog somewhere that has a link to our article on suicide, and it may not even be a clear link (perhaps it was an easter egg link on that site). Many people also do use our interwiki links and/or search bar to get to articles directly, rather than dealing with the ads/promoted links on Google/other search engines. Sure, I don't think anyone going to the Canadian Encyclopedia is so internet unsavvy that they can't go to Google and type in "X help". But that's not why their hatnotes exist. It's because people arrive at articles they don't intend to, or that they may have intended to but only after going down a rabbit hole of seeing things that have triggered them to be thinking about committing suicide. Let's use an example - someone hears a nice Avicii song that they enjoyed, and they come to look up the album/song on Wikipedia. They then click the article about Avicii, because they want to read more about him - without even thinking about suicide. In reading our article, they read about his suicide, and that gets them to thinking about it. There isn't currently a wikilink to suicide in his article that I can see (though there maybe should be?) - but they now, thinking about the topic of suicide and seeing that a musical artist that they enjoyed committed suicide, happen to go to our article on suicide, in a time of distress. Not because they came to Wikipedia thinking about suicide - they came here for information on a song/musician. But they ended up on our article about suicide nonetheless. That is the "intended demographic", and for those with mental illness, going down those rabbit holes that lead to researching suicide or self-harm is all too common. It costs nothing for us to add a prominent but not intrusive list of resources for them to use if they want to stop going down that rabbit hole but can't do so on their own. -bɜ:ʳkənhɪmez (User/say hi!) 08:05, 7 July 2024 (UTC)[reply]
"they have just as much time as anyone else, they just have a mental disorder"
Eating disorders have the highest mortality of any mental illness. This is being proposed because an issue I struggle with isn't very well known and I didn't realize help existed for it, let alone that it was a problem that I needed serious help with instead of just being a 'personality quirk'. I'm not sure why you think reading an article on one of the most popularly used websites on the internet makes you 'wise', but no, for a lot of these resources googling doesn't really provide resources or help- it's just WebMD summaries of how to spot early signs of those issues in kids, because god forbid those kids not figure out there's a name for what's wrong with them until later and want to fix it. Ju1c3machine (talk) 16:48, 7 July 2024 (UTC)[reply]
I note that there have been over a hundred responses to this, but only one (this one from Rosguill) has come with a WP:MEDRS-compliant source, and that was inconclusive and about suicide prevention lines, which we are told is not the subject of this discussion. Phil Bridger (talk) 12:01, 7 July 2024 (UTC)[reply]
Changing all values of the Hebrew language, from Yeshu(ישו), Yeshua(ישוע)
Hello Wikimedia Foundation, my name is Jack from Israel and I would like to talk to you about a very important topic that has never been mentioned almost at all.
In the United States they say the name Jesus, the "J" becomes a "Y" and thus the name Yesus or "Jesus" was created.
Anti-Christian elements criticize his imposition on his name and omitted the last letter in the name of Yeshua and turned it into the name "Yeshu" as a derogatory word, when the word Yeshu becomes an initials and its meaning becomes the phrase "yimakh shemo v'zikhro",
This was mentioned in all the Hebrew scriptures and also in the wikipedia.
In my opinion it is not even necessary to explain why this topic is so important and most importantly to change the value of his name from "Yeshu (ישו)" to "Yeshua (ישוע)".
But here are some explanations from my own why it is so important;
First, changing a person's name can damage history, also changing Napoleon's name can damage the future reporters and also lead to the end of the being Napoleon, we would not want to erase a person like this from our history and forget him on the other hand, today it can be seen that 80% of the people of the State of Israel do not know His real name and they even call him in the derogatory word "yimakh shemo v'zikhro" Wikipedia should tell us (the people), Correct information, up-to-date, and true information! And a person who doesn't understand what a certain entry means, like for example "Yeshua" is welcome to do Wikipedia, that's what you were created for, right?
When a person does not know what Yeshua word means, he can do Wikipedia and understand.
Secondly, the moral and social level involved, changing a person's name and turning it into a derogatory word looks like this ("yimakh shemo v'zikhro") an injury to Christianity as a whole, disrespects the person (Jesus) and humanity, which colludes with deranged Messianic rabbis who devote their entire lives to inventing lies about Christianity . Does Wikipedia, are you members of the Wikimedia Foundation, agree with these values?
In this way, it is like taking the name of something and changing or removing or adding a letter to its name, this can lead to complete oblivion of the person. As can lead to the future bringing of precious Hebrew reporters, and even the rewriting of the New Testament and changing its future name from Yeshua to Yeshu.
We don't see it now, but in the course of the years and the progress of evolution, where books will become digital material and thus bring Wikipedia as the most authoritative source on the Internet; What will be created by this is an injury to the name of Jesus and also an injury to the values of history.
In addition, here is an article that was written on Wikipedia in 2017 but did not receive much attention:
"As a free encyclopedia, we are supposed to meet certain standards. These standards should on the one hand be professional and on the other hand take into account the reading public. I will point out facts: regardless of the name, the entry is currently one of the poorest in Wikipedia on the subject when it includes a list of sources that is so sparse on one of the entities (Note that I did not use the word people so as not to offend, of course) the important ones in humanity history. In addition, in my humble opinion, the Hebrew Wikipedia is the only one that uses a historical derogatory word. I understand that for a large part of you it is not perceived as a derogatory word, but it is certainly possible that a large part of the population does. In fact, it is so unfortunate because it is also about "gypsies", one of the most common derogatory words in connection with peoples in the world that people use without noticing. On the one hand, Wikipedia should champion the professional name, which is Yeshua, and on the other hand, it should champion the non-blatant name, which surprisingly ( cynicism) is also Yeshu. In fact, every time a discussion about the name of the entry comes up, we must reject the request, which comes up again and again, and it changes the name of the entry. The fact that we as Wikipedians receive these complaints over and over again only exacerbates the situation and presents us in a negative light My hypothesis is that it will not offend a person if the name of the entry is Yeshua, but indeed it will be if it is the name Yeshu. We, as Wikipedians, allow the name of the entry to continue, so it is possible that we are actually hurting other people's feelings, even if unintentionally..."
In conclusion, changing the name of Yeshua(ישוע) to Yeshu(ישו) is not only an injury to Christianity as a whole, to human dignity, it is also an injury to history itself and can even cause major problems from this issue.
Therefore I ask the Christians who are reading this, will you allow the people to blaspheme the name of Jesus?
Will Wikipedia give priority to such a disgrace?
That's why I ask in every language of request,
to change the word "Yeshu" to the word "Yeshua" in the Hebrew values
I would love it if you read and contact me, many thanks Jack 87.71.160.172 (talk) 22:51, 20 July 2024 (UTC)[reply]
From what I have been able to gather, you have a problem with the way the Hebrew (or transliterated Hebrew) for Jesus of Nazareth is written in at least some (all?) articles? From what I can see (MOS:JESUS) we don't have a site-wide consensus on how the name should be presented in Hebrew. As such, how it is referred to in any particular article will depend on the sources being used for the information - if the sources use one transliteration then that's fine to use. That said, I appreciate that this IP believes one spelling of it (in Hebrew or transliterated Hebrew) to be offensive to some at least. I can't tell if the IP is complaining about something solely present on Hebrew Wikipedia (if so we can't really do much), but it may be a good idea to add something to MOS:JESUS as to how we refer to the person - do we always use the English name "Jesus (of Nazareth)", do we sometimes use the Hebrew name, and if the second, what spelling/transliteration do we use? I'll be leaving a note on the IP's talkpage to ask them to clarify their issue. -bɜ:ʳkənhɪmez (User/say hi!) 07:42, 21 July 2024 (UTC)[reply]
It looks like there is some related information in Yeshu. It appears that this set of letters was used in one (i.e., a single) medieval-era Masekhet as an acronym rather than/as a pun on the name, and a 17th-century German man, Johann Andreas Eisenmenger pushed the idea that this spelling is always insulting, along with quite a lot of errors, bigotry, and nonsense.
Some modern writers use the difference between Yeshua and Yeshu to distinguish between Jesus of Nazareth and all of the (many) other people with the same given name ("Joshua" being the most common English spelling). If that is the widely accepted convention in Hebrew, then I would expect that not following it would be confusing to readers. WhatamIdoing (talk) 09:05, 21 July 2024 (UTC)[reply]
According to your opinion, the two main reasons why you do not want to change the name from Yeshu to Yeshua are:
The first was that the use of the name Joshua can cause confusion with other names in history, many rabbis who use this claim as a cover for changing his name Yeshua to Jesus (yimakh shemo v'zikhro).
This claim is completely absurd and can be refuted in several ways.
The first, the most well-known example (which occurs mainly among the rabbis), is the change of the name Yeshu to Yeshua, so that they do not get confused between the name *Joshua* and Yeshua, which is completely absurd in the English language and also in the Hebrew language, it does not come out or sound the same, the addition of the letter " The "in the King of God" can change the spelling completely, (Yeshua - *Yehósua*), another example, changing a name, dropping a letter changes the name completely, for example Jack-Jacek, one can understand the essential difference between the two names, thus expanding the claim. Of course there are other examples in this regard, but I will not list them...
Second claim, "Israeli society is already used to the word "Yeshu", and this is also a rather absurd claim, as if a society decides to change the name of something (and something else very important throughout history) collectively, it does not really change its name, like this friend that everyone calls him by a nickname, but finally his original name will appear on his ID card. And so is Wikipedia, which is supposed to serve as an identity card of values; And the kind of value and also Yeshua.
In addition, if any company decides to boycott any country, and even create a political conflict against it-
A. This does not mean that it is impossible to change the situation and bring it to a better two-state situation.
B. The mere fact that one country decides to ignore another country does not make the other country non-existent.
And likewise his name, if a company of people decides to reverse the name of Yeshua and become the word "Yeshu" it did not reduce his name to Yeshu!
Also, Wikipedia must adhere to the correct values and provide correct and reliable information.
In addition, you wrote "there is not much to be done if this"
I am personally ready to sit down and change all the values in which the word Yeshu appears, and I also recommend to the members of the Wikimedia Foundation in Israel to make an effort to correct the values.
Second, This was mentioned in all the Hebrew scriptures is anachronistic; the Hebrew scripture were closed long before his time. As for the Talmud, the date that I have seen for the early part, the Mishna, is 200 CE, surely a bit late to have influenced the spelling in the Christian scriptures.
Third, if there are surviving Aramaic copies of the Christian scriptures then the name written there should be used. Otherwise, the Greek transliteration now accepted in Christianity should be used.
My intention is that it could lead to the rewriting of the New Testament, in the name of technological progress... What could be written by a Jew who does not know the true name of Yeshua and will therefore call his false name Yeshu Appspame (talk) 20:38, 21 July 2024 (UTC)[reply]
In Judaism there is such a thing called the Ark of the Covenant where every rabbi can add more and more and more books the Hebrew Scriptures do not close they continue. The very fact that you say such a thing means that you know nothing and a half about Judaism or about the State of Israel itself. You can ask any rabbi and he will answer it for you. (cf. Sifrei Kodesh entry) Appspame (talk) 08:11, 22 July 2024 (UTC)[reply]
Here is another example of a book written in the last 500 years Shulchan Aruch is a very important book for Judaism! So much so that it even entered part of it into the Pesach legend! Appspame (talk) 08:14, 22 July 2024 (UTC)[reply]
In general, the very thought that they took the name of a historical figure and simply changed his name definitively does not excite you, the use of the wrong name can lead to historical disruptions and surely the website Wikipedia, which should lead to one of the most authoritative sites for learning on the Internet, gives the wrong name of some person throughout history ? If the name Napoleon was written incorrectly you would correct it correctly and if any other name was written incorrectly you would correct it.! But when it comes to this name, suddenly there is a problem, right?! Appspame (talk) 20:44, 21 July 2024 (UTC)[reply]
I specifically turned to you because I know that you are people with logical considerations, people who know some logic in their lives. You can admit that you simply do not have the strength to change all the names on Wikipedia to their true value. I actually did not address the Israeli community because the Israeli community does not understand the value of the importance of such a thing, but you who live in the United States should know the value of the importance of such a thing! This is not only a disruption of history, it is also an injury to the person's name. Appspame (talk) 20:47, 21 July 2024 (UTC)[reply]
Respectfully, there is no "true value" to which we should change everything on Wikipedia. Names have been transliterated and written different ways in various languages throughout the centuries, and Wikipedia relies on verifiability, not truth. If you want this change to be made, claiming that it is the "true" spelling isn't enough, you need to provide us with sources actually using it as the Hebrew spelling. Chaotic Enby (talk · contribs) 21:35, 21 July 2024 (UTC)[reply]
Isn't the New Testament the most correct spelling for Jesus' name? The rest of the inscriptions are actually under the inscriptions of rabbis or rabbis that were written after the New Testament. The oldest inscription in which the name Jesus was mentioned was the New Testament. Appspame (talk) 21:41, 21 July 2024 (UTC)[reply]
In my opinion, it is absolutely absurd that you need to bring evidence for the name of Jesus, that you can simply go to the place where he mentioned his name for the first time in the New Testament! This is the oldest source that mentions his name, and also it should be brought to the most authoritative place regarding his name, and also an attribution of a name change written about 500 after his death, should not be attributed any meaning to it. If so, can you bring me a Hebrew source older than the New Testament that attributes his name, and also says that his name is Yeshu...? Appspame (talk) 21:47, 21 July 2024 (UTC)[reply]
There are many editions of the New Testament, some of which use one spelling. Even if you took the oldest edition, that one would have several words spelt according to the conventions of the time instead of modern Hebrew. Aaron Liu (talk) 21:54, 21 July 2024 (UTC)[reply]
In Hebrew we have two types of new house, the first is modern Hebrew and in biblical Hebrew the word Yeshu does not appear in both of them Appspame (talk) 22:06, 21 July 2024 (UTC)[reply]
You say that there are other versions of the New Testament in an older way in Hebrew, I want you to find me an older New Testament in which the word Yeshu is written, if you do not find it, this makes the most recent existing New Testament the oldest place where his name was mentioned. Any claim that is not a counterquote is considered to be evasion Appspame (talk) 22:11, 21 July 2024 (UTC)[reply]
I can also invent that there is an older inscription past the life of Alexander the Great and it says his name Mordechai Reuveni. That doesn't make it right! Appspame (talk) 22:14, 21 July 2024 (UTC)[reply]
Matthew 1:16... (and Jacob the father of Joseph, the husband of Mary, and Mary was the mother of Jesus who is called the Messiah.)
> If the name Napoleon was written incorrectly you would correct it
True, but we'd have to talk about what "correct" is. We write about Napoleon, even though his name was Napoléon in French and Napoleone at his birth. Which one is "correct"? WhatamIdoing (talk) 02:08, 31 July 2024 (UTC)[reply]
In the United States they say the name Jesus, the "J" becomes a "Y" and thus the name Yesus or "Jesus" was created. What?? —Tamfang (talk) 06:06, 23 July 2024 (UTC)[reply]
A lot of languages share the Latin root Iēsūs. Learned borrowing, the proper way of inheriting words, changes the spelling to be more in line with a language's phonetical spelling. Way back when, the J was the proper way to spell Y. I think that's what it means. Aaron Liu (talk) 02:37, 31 July 2024 (UTC)[reply]
But I'm not looking for the value in Greek, I'm looking for it in Hebrew, in Hebrew they write Yeshua, according to the oldest inscription the New Home in Hebrew! Appspame (talk) 22:28, 21 July 2024 (UTC)[reply]
Why do you insist so much on not changing the name of the entry, and admitting mistakes?, I suggest you also research the issue and go to the Igod.com website, which explains some important topics in the Bible and the New Testament! Appspame (talk) 22:35, 21 July 2024 (UTC)[reply]
Appspame, nobody can tell from your overly lengthy commentary which specific articles here on the English Wikipedia you propose to change and which reliable sources you propose to cite. We cannot help you with any other language version of Wikipedia. You need to be far more concise and clear. Cullen328 (talk) 01:33, 22 July 2024 (UTC)[reply]
Ok, I'll try it, the oldest Hebrew source in which the name Jesus appears is found in the New Testament. The New Testament is not found in the entire state of Israel where the word Yeshu appears, Wikipedia relies on older writings written about 500 years after Jesus and 1500 years written by Rabbis. I am personally ready to change the values in which this disgrace appears and change his real name from Yeshu to Yeshua all I need you to do is to approve me thank you! Appspame (talk) 08:01, 22 July 2024 (UTC)[reply]
Appspame, I guess that I need to repeat my questions since you failed to answer the first time. Which specific articles here on the English Wikipedia do you propose to change and which specific reliable sources do you propose to cite? Vague, sweeping claims are worthless here. Please produce the specifics, or move on to something else. Cullen328 (talk) 08:56, 22 July 2024 (UTC)[reply]
No, I'd love to talk about it a little more I want to really understand what is the point where you don't want to change his name to his real name? the New Testament because it is a faithful place, and if you don't want to take the New Testament it is a faithful place, the place after which it was written was the Koran, also in the Koran his name is mentioned and guess what his name is Yeshua, my first point is that it is forbidden to change a historical detail, to come and say that there is not enough evidence to prove that it is a historical detail whose name Was Yeshua it's like coming and saying that there is not enough historical evidence of Napoleon's name was Napoleon. The books of the New Testament are not only "books of stories" but also historical books that tell us about the First Temple period here in Jerusalem. My second point is that if a society is used to something it doesn't mean that you can't just change it, for example if South Africa is used to massacres and genocide, doesn't that mean you can't change it and just leave it as it is? So you can also change! I'm trying to understand why you are so opposed to this question mark I brought proofs I brought points for thought but you decide to ignore them why?! It's about my English, I'm very sorry, it's my English, after all, I live in Israel, be patient with me, thank you. And once again, it's important for me to point out that I don't come from a place of anger, I come from a place of disappointment, disappointment that I even have to come and say such a thing to come and wake up people's eyes and explain to them that my name is my name, and my name is not what changed it, that's why it gives me a feeling of disappointment Towards myself, towards humanity and towards Wikipedia which cooperates with unreal and incorrect values! More than that, you take values that were written exclusively in Hebrew by messianic rabbis and not by people who actually knew Christianity and who knew who Jesus is, so I think that your faithful source are not instructive, but because they were written by people who hate the New Testament and hate Jesus and that's how they are Let his name be known. In the same scripture where the name Yeshu was written, there were also lies written about him and lies also about the New Testament by those people who did not even dare to open the New Testament or read from it or understand it. And you call them a faithful source? Appspame (talk) 09:20, 22 July 2024 (UTC)[reply]
Btw, this is not the Wikimedia Foundation (you wrote "Hello Wikimedia Foundation" in your OP), this is more like the en-WP Wikipedia community, or at least the parts of it that noticed this thread and decided to write a reply.
My understanding so far is that you want every Wikipedia-article, in any language, that includes a Hebrew spelling of Jesus, to use the Hebrew spelling you prefer. That is not something en-WP can decide, and while you can try to contact the Wikimedia Foundation, it's not an issue I think they'll consider their business, they generally leave Wikipedia content to the various Wikipedia communities. Hope this helps some. Gråbergs Gråa Sång (talk) 11:43, 22 July 2024 (UTC)[reply]
Wikipedia is written by thousands of volunteers. The Wikimedia Foundation maintains its infrastructure, not its content. —Tamfang (talk) 06:01, 23 July 2024 (UTC)[reply]
We are not the Wikimedia Foundation. We are the volunteers who actually do the work. The Wikimedia Foundation just handles funding and legal issues; it doesn't actually control the content of Wikipedia at all. You're talking to the right people if you want to change something, but Wikipedia makes changes by WP:CONSENSUS, not by a few people who are in charge. This means we will argue about something for a long time before doing anything about it. Cremastra (talk) 07:18, 25 July 2024 (UTC)[reply]
Addendum: An Israeli citizen could hypothetically lobby the Israeli government to change the name of its public holiday "עליית ישו השמיימה". If -- and only if -- that effort were successful, then Public holidays in Israel could and should be modified. Getting the Israel Museum in Jerusalem to modify the Ossuary shown in The Lost Tomb of Jesus so that its caption could reflect the change is another task that a local could likewise hypothetically attempt. (TL;DR: Don't) ~Hydronium~Hydroxide~(Talk)~12:44, 22 July 2024 (UTC)[reply]
Nonsense! In Israel, according to the Hebrew Language Academy, Yeshu's real name is Yeshua and you can ask the Hebrew Language Academy, they are responsible for the Hebrew language, not Wikipedia! So that Wikipedia does not only dishonor the name of the person, it also dishonors the historical value, also dishonors the Hebrew language and the Hebrew Language Academy. Appspame (talk) 14:20, 22 July 2024 (UTC)[reply]
You take the names of the Catholic Christian holidays that were translated by non-Catholics and these names were never approved by the Hebrew Language Academy and you give them as an example?! What kind of example is this? You show some examples and you say, here is the name that appears here and here and only on this holiday does this name appear, perhaps only because only this holiday has been approved and translated by the academy and qualified Christian authorities! Appspame (talk) 14:24, 22 July 2024 (UTC)[reply]
By the way, I actually chose to talk to you because I thought you were more reasonable people who know facts and live in the sand and should understand the essence of the matter! Appspame (talk) 14:26, 22 July 2024 (UTC)[reply]
And once again you never answered me why you are so, so opposed to changing the name to his real name? Are there internal factors that tell you not to do such a thing, is it only because I am Israeli and you are anti-Semitic? Is it because you are against Christianity and in favor of desecrating the name of Jesus? Tell me what the real reason is that you are so opposed!? Appspame , (talk) 14:28, 22 July 2024 (UTC)[reply]
Stop with the absurd personal attacks, Appspame. Your proposal is failing to gain support because you do not understand English Wikipedia's policies and guidelines, have not brought forward any reliable sources, and show no sign of taking on board the feedback you are receiving. You are an anonymous person and your claimed personal expertise is of no value here. Cullen328 (talk) 15:52, 22 July 2024 (UTC)[reply]
One of the ways articles are discoverable is through wiki-links. Sometimes I come across articles that reference specific people or events, and there exists Wikipedia articles with exact matches to the inline text. This could also be a gamified task for new editors to look at proposed wiki links to be matched with inline text. It should reuse the existing visual editor interface as much as possible. Given the possibility of false/sloppy matches, these types of edits could be marked for multiple reviews, while still enable new editors to make constructive edits and have fun at it.
I rewrote the guideline Wikipedia:Please do not bite the newcomers to be more concise and readable in this rewrite. The current version contains many duplicated guidance, irrelevant information, and painfully common-sense recommendations (I don't think I need to provide any examples). It contains one outdated guidance (draftication is now more common than userification), and poor accessibility decisions like long bullet points as well as linking non-specific words like "here". Concise writing leads more people to actually read the guideline. How do you feel about this rewrite? Should I add/remove/change anything? Catalk to me!14:41, 27 July 2024 (UTC)[reply]
The rewrite is the diff posted above; your minor copyediting is this one. I did compare the current rewrite to the last revision of WP:BITE prior to your edits there, to show the totality of your changes, and then forgot to mention it after I figured out I had to reverse the parameter values in {{Diff4}} to get it to produce the effect I wanted. Apologies for the confusion. (Also I like the rewrite. Have you seen shameless plug?) Folly Mox (talk) 15:27, 27 July 2024 (UTC)[reply]
No worries! I didn't realize that diff viewing between two pages were possible. I do like HouseBlaster's YFA rewrite over the current version. Catalk to me!17:41, 27 July 2024 (UTC)[reply]
While I like most of this, I feel like some of the removed points should be kept. For example, the "what to do" section feels like it would make people pointed to the guideline less aggravated, and "Common newcomer errors" offers examples of situations to apply the guideline. A lot of rationale was removed: for example, the point that newcomers contribute most substantial content was pretty poignant and the part about "be bold" feels like it should be included in the "it's okay" section. I'll see if I can change some of this.Also, I personally have an intense dislike of punctuation right after an external link; the icon stands out a lot and looks unpleasant. Should the Stackoverflow link be converted to a footnote? Aaron Liu (talk) 22:38, 27 July 2024 (UTC)[reply]
Much thanks for ironing out awkward prose! I am not a native speaker of English so copyediting takes effort for me.
I relegated the result of 2006 informal study into an efn since it is outdated by nearly two decade. I am not sure if the finding still applies today. I'll try to find up-to-date sources.
I removed the section What to do if you feel you have "bitten" since it felt like the standard life advice when you have hurt somebody/made a mistake, and isn't specific to bite cases.
I like the bit you added about WP:AGF/Hanlon's razor. AGF should be mentioned as a strategy to not bite. However, I feel as if the paragraph could be reduced to a simple bullet point/sentence, since much of it is just restating the first and second paragraph. Catalk to me!16:39, 28 July 2024 (UTC)[reply]
Yeah, I'd go the efn route as well.For the razor, one of the other points I felt was missing was the part about teaching. The paragraph seemed like the best way to incorporate that. It also includes stuff about not assuming malice. Aaron Liu (talk) 16:45, 28 July 2024 (UTC)[reply]
We're more trying to see if the "anons and newbies contribute most substantial content" can be sourced with recent, "published" data. Aaron Liu (talk) 14:36, 29 July 2024 (UTC)[reply]
t felt like the standard life advice when you have hurt somebody/made a mistake A lot of life advice applies to Wikipedia. Common sense isn't as prevalent as it once was, and being a section near the bottom (we could even move it to the very bottom) it really shouldn't hurt to include it. Aaron Liu (talk) 14:44, 29 July 2024 (UTC)[reply]
I understand your point; but if someone doesn't know a interpersonal skill as basic as this, they shouldn't be editing Wikipedia in my opinion.
Maybe the section could be condensed to these three bullet points:
A lot of us here are on the autism spectrum (I am) and interpersonal skills aren't necessarily our forté. Also, people can react very differently towards conflict, irrespective of neurodivergence. A lot of other websites thrive on unkind interactions like sarcasm and cutting remarks. We can assume neither an editor's interpersonal skills nor their learnt behaviours from other online communities. Attempting to educate is worthwhile. Folly Mox (talk) 16:16, 29 July 2024 (UTC)[reply]
I should have realized that my comment can be inconsiderate, I am sorry for the insensitive remark. I agree with your reasoning behind keeping the section, though I do think the current version of the section has room for concision-ing. Catalk to me!16:29, 29 July 2024 (UTC)[reply]
I think this linking would be very helpful. Any editor interested in finishing one Requested Image from Paris will likely be able to help with other articles in Paris. But there should be a clear link given from talk pages. Starting discussion here because both templates affect 250K+ articles. I'll move to another venue (which?) if it looks like a good idea overall. Soni (talk) 04:14, 28 July 2024 (UTC)[reply]
Could MOS:TMRULES be amended to avoid conflict with WP:COMMONNAME, esp for contemporary artists and their works?
To tl;dr it – Many contemporary artists [esp. musicians, and esp Korean pop groups] consistently use exceptional stylization (non exhaustive example: ALL CAPS) for the name of their groups and/or works. It has become commonplace for sources to observe these exceptional stylizations. Conventional interpretation of MOS:TMRULES has created an untold number of articles of where Wikipedia often sticks out as the only online resource that doesn't observe these exceptional stylizations. I believe I can make a compelling case, one by one, to amend these article titles to observe the exceptional stylization. Does this have to carry on as a one-by-one where the compelling case must be made each time, or could a policy change streamline / reduce the workload?
Longform: I think Wikipedia struggles, and will continue to struggle, with the name of artists who prefer exceptional stylization ('exceptional' in the Wikipedia sense of the term). For a specific example, a lot of Korean music groups have come to prefer stylizations which break grammatical conventions. Typically, there are artists who will style their name in all caps even though it doesn't stand for anything, such as ARTMS. There, I created a move request with what I believe is a compelling argument to move from Artms to ARTMS, but I would not consider this a one-off.
As I discuss on the talk page of IVE (group), a myriad of other Korean groups come to mind, limited to, but hardly inclusive of Le Sserafim, Twice, Artms, Blackpink(re: LE SSERAFIM, TWICE, ARTMS, BLACKPINK – all consistently observed as such officially and in most sources). These artists don't incidentally use all caps stylization, they are all consistently using this stylization on social media, on streaming services, in album databases, etc. Looking back retroactively, even defunct Kpop groups like Loona were actually consistently using all caps stylizations not as a branding idiosyncrasy, but in effect, as their name.
The problem as I'm suggesting it, is that Wikipedia is currently the odd duck out for a number of articles – the argument as I've made for ARTMS can consistently be made for a number of these groups. When I search these groups up Wikipedia is often showing up on the first page of search results, and is typically the only result that does not honor the allcaps stylization. My impression is that MOS:TMRULES is in place to avoid Wikipedia being beholden, or being seen as beholden, to any branding concerns or marketing interests of any entity, but in this topic area Wikipedia just ends up looking bizarre. Still, I think there are some decent questions and points of possible disagreement with how to best interpret the policies that currently exist – i.e. posts by Wuju Daisuki in the IVE group talk page. It is a bit ambiguous how to reconcile MOS:TMRULES, MOS:BIOEXCEPT, MOS:IDENTITY in some of these cases.
Another matter to consider: on top of all this, many of these groups will also have works with exceptional stylization. Again, ALL CAPS stylizations are typically the case, but albums like DALL(officially <Dall>, regardless of the fact the album artwork stylizes the title as the full title), (+_+)(actually [+ +], this is an acceptable title given technical restrictions but gives you an example of how varied these titles can be), Ive Switch(actually consistently stylized as IVE SWITCH), the song Unforgiven (Le Sserafim song)(actually always stylized as UNFORGIVEN, and again, always stylized as LE SSERAFIM) – it isn't just that Wikipedia will be exception in how it chooses to name groups in this category area, but also how it names their works, output, etc. A number of the music labels also consistently prefer exceptional stylization and are consistent with this stylization even in minutiae like fine print of legal documents.
Though it is probably the easiest area by which myriad examples can be found, it shouldn't really be something that is only going to be relevant to Korean groups. Much of my music library is comprised of works published from the early 2010s and later, and I suppose you could attribute the internet(?) to an interest in breaking the conventions of how artists have usually titled works. The patten (musician) article correctly observes that the non-capitalization is the consistently observed stylization of the artist, and the body of the article documents correctly that most of their albums are stylized in all caps. However, the article for ESTOILE NAIANT is Estoile Naiant, though the overwhelming majority of sources observe the all caps stylization [Tiny Mix Tapes], [RA], [FACT], [Apple Music], etc. This is not a one-off. As many labels go digital and many artists primarily work and publish online, it seems like they have more interest in creating titling which happen to potentially conflict with MOS:TMRULES, but thanks to the free flow of information online, they can enforce this stylization, and satisfy WP:COMMONNAME.
(Aside: Those factors which have contributed to a rapid increase of exceptional stylizations are effectively entrenched at this point, and so I except this to become increasingly common as time goes on. Then as an alternate consideration: as it becomes easier for brands to enforce or otherwise affect consistent use of preferred stylization across sources reporting on them, is TMRULES altogether an archaic policy which attempts to enforce a traditional encyclopedic mode which is not relevant to the 21st century?)122141510 (talk) 17:26, 29 July 2024 (UTC)[reply]
I don't think it's in Wikipedia's best interest to try and follow by default what is essentially marketing stylization, because that's ultimately not a COMMONNAME issue but a styling one, and our Manual of Style takes precedence. Arguing it on a case-by-case basis is absolutely preferable to trying to turn Wikipedia's articles into BLɅϽKPIИK by default. We're an encyclopedia, not an extension of a marketing effort. (Beyond this, trying to do a carveout for this would have logical knock-on effects to a ton of Wikipedia's coverage, for example how some artists present their songs with all-lowercase titles.) Der Wohltemperierte Fuchstalk17:49, 29 July 2024 (UTC)[reply]
It is a COMMONNAME issue at this point – Wikipedia is typically the outlier. I would characterise MOS:TMSTYLE as presuming the artist or their works will not be successful in enforcing or affecting their preferred stylization when they are discussed in reliable sources. I don't know when exactly, but sometime in the last 10-20 years that presumption has become wrong more often than it has become right, and it's easy to see how the internet has led to interest in all this.
Regarding BLACKPINK vs BLAϽKPINK, I'd consider it more of an edge case than completely undermining the point I'm bringing up. That is, I think the default question editors should have to reach a consensus is not "should Wikipedia document them as Blackpink or BLACKPINK?" but "should Wikipedia document them as BLACKPINK or BLAϽKPINK?" I'm essentially objecting to where the WP:ONUS is in this matter. 122141510 (talk) 18:06, 29 July 2024 (UTC)[reply]
Oppose – we shouldn't make it easy for anyone to get away with ALLCAPS capitalization, since that's just a cheap marketing gimmick. Gawaon (talk) 18:01, 29 July 2024 (UTC)[reply]
Too common to be reasonably characterized as just cheap marketing gimmick, and since an overwhelming majority of sources accept these stylizations anyways – whether ALL CAPS, all lower case, or otherwise – Wikipedia is going to observe them because they end up becoming the common name anyways. I really think that this is a question of whether compelling argument or not could be made to move hundreds of articles, something can be done to manage the active workload, backlog, and change the parameters for future titles. I could knock off a series of move requests this week and see how it goes if it isn't going to be taken as too WP:POINTy. 122141510 (talk) 18:22, 29 July 2024 (UTC)[reply]
I'd add a "citation needed" to that. A news search for "Le Sserafim" includes quite early hits such as [11], [12], [13], [14], [15], all of which use the normal case form. Marketing material will of course, and by definition, use the marketing gimmick form – independent media and anybody else, not necessarily. Gawaon (talk) 19:04, 29 July 2024 (UTC)[reply]
Yeah I think @122141510 might be a little too focused on one specific corner of media, whereas "publications precisely replicate the formatting the band does" isn't really extended to a lot of other media (for example, films do a ton of specific weirdness with their titles, and outside of very exceptional cases, we don't tend to follow it.) Also, COMMONNAME very much doesn't speak to stuff like ALLCAPS formatting, it's talking about choosing article naming more generally. I don't think the comparison of "do we call this species by its common or scientific name" really relates to the question of "do we respect marketing ALLCAPS for k-pop groups". Der Wohltemperierte Fuchstalk19:19, 29 July 2024 (UTC)[reply]
It's incorrect to narrow this down only to kpop groups. I've focused on them by way of example that should be understood to be non-exhaustive, and a below comment points out there's another concurrent move request regarding a US group which is fundamentally the same problem and – I assert – coming to an (imo) incorrect consensus that contradicts with the consensus currently forming for a move request I submitted. It would only be a lack of familiarity by which we might assume this will only be Korean pop music. 122141510 (talk) 19:32, 29 July 2024 (UTC)[reply]
Under MOS:BIOEXCEPT and MOS:IDENTITY, living subjects of articles are entitled to exceptional stylization if groups clearly and consistently use an exceptional style, and an overwhelming majority of sources use the same exceptional style. It doesn't have to be all of them. An argument already exists for these moves – I'm asking to streamline that, and also expand the scope just a bit to observe that their works are in effectively the same boat – Wikipedia is avoiding stylization out of an excess of caution, and is out of step with sources and the common name as a result.
I'd assert that something to the the effect that if an artist consistently styles themselves and/or their works with an exceptional stylization and they've pushed that exceptional stylization to a plurality of streaming services or music stores, they're likely to be able to successfully enforce or otherwise assert their stylization across an overwhelming majority of sources and satisfy those criteria, and effectively become the COMMON NAME by which they and/or their works are referred to as.
I am assuming linking these won't run afoul of canvassing – especially since you don't appear to agree – but if you disagree with the premise, I'd actually encourage you to take a look at the one aforementioned move request I submitted and mentioned already Talk:Artms#Requested_move_25_July_2024, and another I just became aware of by way of this page Talk:DNCE#Requested_move_19_July_2024. If the former in particular is successful, it could effectively serve as a template for a series of move requests I could submit which would be limited only by time available to me, but I'd rather reach a point of 'per X' or some other kind of 'QED' by being able to point to a policy – the same way the latter move request, despite being fundamentally the same circumstance, is currently looking like it will reach a consensus to reject exceptional stylization by simply citing MOSTM without anything inherently mandating considering the COMMONNAME before they cite it; flawed consensus that prioritizes an incorrect reading of MOSTM over COMMONNAME has already occurred. 122141510 (talk) 19:21, 29 July 2024 (UTC)[reply]
Except that for most bio cases, like kd lang, the request isn't to shift to all caps but sonething that remains clearly readable in running prose. Shifting a name to ALLCAPS where that is not an established initialism makes articles harder to read, and that's part of why the MOS presscribes it this way. Masem (t) 19:30, 29 July 2024 (UTC)[reply]
Harder to read? This isn't a personal attack, but may I ask how old you are and/or roughly what generational cohort you are a member of? I can readily imagine it's harder to read for older individuals, but if it was that much harder to read for a younger audience, they wouldn't be consistently observing it on their fan sites, fan wikis, SNS, etc. and journalists would avoid it in the bodies of their articles and/or the titles of their articles. I've never known teenagers or young adults to be big sticklers for observing brand conventions if they don't have to – hence, maybe, why it's still Lego and not LEGO. Is there some policy where consideration for what some editors might find hard to read should be prioritized over the common name? AFAIK the only limitation along those lines would be technical restrictions, but I understand that as primarily being because Wikipedia couldn't render certain titles anyways, even if editors could reach a consensus to do so otherwise. 122141510 (talk) 19:38, 29 July 2024 (UTC)[reply]
It's not just a generation thing, we serve the global readership that understands English, which includes those where English may be a secord or third language. Throwing ALLCAPS names around that aren't there to simplify a larger proper name (like for NASA or EPA) is unnecessary when the same info can be present in normal case and is far easier to read by the worldwide readership.
Also the COMMONNAME point here is not yet shown. Marketing material is not the same as the reliable sources we try to judge COMMONNAME on. Masem (t) 19:46, 29 July 2024 (UTC)[reply]
I simply don't believe that all caps are harder to read to the extent we'd have to override common name, regardless of whether the user's first language is English or not. I have only perused the abstracts or skimmed a few research papers, but maybe the first time we read something in all caps – like COMMONNAME(!) – we might find it difficult to read, but we quickly get used to it and it is no longer as distracting or difficult to read. I don't trefer to COMMONNAME, MOSTM, etc. in all caps to make contributing to Wikipedia harder for any editors who might have reading difficulties, and I doubt you do either. I'm not sure I appreciate what point you're trying to make. I read your argument almost like making an argument for localization? I'd oppose changing Lavrentiy Beria's name just because a plurality of people for whom English is their first language cannot read or pronounce his first name correctly? 122141510 (talk) 19:53, 29 July 2024 (UTC)[reply]
Your argument: "These artists are doing something silly for no reason and their fans have glommed onto it. Wikipedia should too."
There are plenty of other things I think are ridiculous which Wikipedia has entire series of articles on, and I'm sure you might feel similarly about other article(s), but insofar as what we're discussing here, I object to reducing my argument such that artistic expression is something artists might do that is silly for no reason, or that fans have 'glommed onto' their expression. Please don't put words in my mouth. My argument is Wikipedia isn't observing the common name and incorrectly reading MOS:TM. 122141510 (talk) 13:52, 30 July 2024 (UTC)[reply]
”… Wikipedia relies on sources to determine when an unusual name format has become conventional for a particular trademark; only names that are consistently styled a particular way by a substantial majority of independent, reliable sources are styled that way in Wikipedia.”
In other words, the guideline already tells us that we should follow COMMONNAME, by looking at how independent reliable sources format a trademarked name in their running text.
That said… there are two key words in this instruction: the first is independent… we don’t look at promotional material, album covers, etc, as these are not independent. The second key word is consistently. We need to establish that there is indeed a non-standard presentation that is COMMON. A few sources presenting the name in a particular format is not enough. We would need to establish that most (if not all) of the independent sources do so. That is rare. Blueboar (talk) 14:33, 30 July 2024 (UTC)[reply]
I think I agree most of what you're saying. We only disagree on how rare it is – I don't think it's rare at all. Maybe trying to raise the issue proactively is causing people to underestimate and won't really go anywhere. Is there a particular number of successful RMs I might need to submit before I can make a case to editors? Or should I just keep submitting them and instead of assuming it will be a problem, someone managing the WP:RM workflow might flag it instead? I don't know the best approach here, but I guess I'll just start submitting more of them. 122141510 (talk) 19:22, 30 July 2024 (UTC)[reply]
That’s up to you… but my advice would be to go very slowly. If you truly CAN establish that a significant majority of independent reliable sources consistently use some particular styling, that should support moving the article. But… be cautious. You don’t want to earn yourself a reputation for filing unsubstantiated (and therefore disruptive) RMs. Blueboar (talk) 20:00, 30 July 2024 (UTC)[reply]
Let me be a little clearer about this. You absolutely do not want this to happen:
You: Everybody says BLACKPINK, so Wikipedia should change the title of Blackpink to use all caps.
Eve: But WP:DAILYMAIL sometimes uses the all-caps styling.
So if you are going to make a claim that we need to change the title because it is "commonplace" to use all caps, you need to first determine whether it's actually common, instead of being common inside your filter bubble, or common primarily on social media, or only within a particular category of source. WhatamIdoing (talk) 02:41, 31 July 2024 (UTC)[reply]
I'm conscious of that. The amount of effort involved there is quite gargantuan but it is probably better, as Blueboard suggested, to go slowly. I've identified four relevant articles at this time;
Artms, where there is virtually no source that does not render the group as ARTMS. I submitted the RM and expect it to achieve consensus.
DNCE, where there is virtually no source that does not render the group as DNCE. I did not submit the RM which is attempting to move away from the stylization (against sources), and it's not obvious if it will or will not achieve consensus. I'd like it to be a good example to demonstrate the problem is hardly limited to kpop, but even if there is consensus to retain the current stylization, it may form around something else – so I'd almost have to make a WP:POINT of finding a non-Korean group to use as example.
Ive (group) is taking my first bite at the apple of an RM which failed previously, but was not a well-argued RM imo. The RM I've submitted is an interesting edge case where I upfront identify 3 sources which do not observe the IVE stylization – I hope editors will be able to argue for or against along the lines as I've suggested (what is 'almost never' in TMRULES? are we obliged to consider IDENTITY the way I've asserted we are?) but of course aren't obliged to do so.
Estoile Naiant has virtually all sources but a single aggregate website observing the consistent ESTOILE NAIANT stylization. The RM I've submitted (which I've linked to another output from the same artist) is beneficial as I'm [1] demonstrating the case is hardly unique to kpop – the artist of the output in question is a British electronic artist, and probably more relevantly [2] testing whether consensus can still form in the absence of any considerations regarding TMRULES/IDENTITY or any other considerations under BLP/etc.
All my rationale focuses primarily on pulling an exhaustive number of examples by which the common name might be determined. In common with all is identifying how the group and/or their work is styled on multiple streaming services – I think I've already said it, but my assertion would in effect be if an artist consistently styles themselves and/or their works with an exceptional stylization and they've pushed that exceptional stylization to a plurality of streaming services or music stores, they're likely to be able to successfully enforce or otherwise assert their stylization across an overwhelming majority of sources and satisfy those criteria, and effectively become the COMMON NAME by which they and/or their works are referred to as. I believe Wikipedia could eventually be able to come a conclusion to generally assume that that is the case, and the onus should be on editors to demonstrate that it isn't. (Failing that, I read it as Wikipedia is willing to be blissfully wrong until editors are willing to put in a non-trivial amount of work/time to demonstrate the standard case? I don't know.) Thanks for yours and @Blueboar's advice. 122141510 (talk) 03:21, 31 July 2024 (UTC)[reply]
You mention streaming services, but I wonder how much of that usage is truly "independent". Do people at the service make editorial decisions or does the site simply accept values from the digital files provided by the artist and display those? In a physical analogy, are we looking at a table of records with an official band poster hanging over it or are we seeing a table of records with a sign made by the store employees? --User:Khajidha (talk) (contributions) 16:46, 31 July 2024 (UTC)[reply]
They aren't independent at all, and hence irrelevant when it comes to determining what reliable independent sources do. Gawaon (talk) 16:51, 31 July 2024 (UTC)[reply]
There's no reason to assume 'reliable independent sources' would intentionally deviate from the conventional way of referring to these groups. More often than not Wikipedia is only the webpage on the front page of search results that doesn't observe the stylizations, regardless of what else populates the first page. As I mentioned, I take this interpretation as meaning Wikipedia are willing to wrong (on purpose? to prove a WP:POINT, maybe? MOSTM doesn't give editors a carte blanche to ignore the COMMONNAME) until other editors are willing to put in a non-trivial amount of work/time to demonstrate the standard case. 122141510 (talk) 00:35, 1 August 2024 (UTC)[reply]
Oppose. Why on earth would we repeal a rule, the entire point of which is preventing promotional over-stylization, just because someone is unhappy that it's interfering, exactly as intended, with them using promotional over-stylization? This is part of a push to force ALL-CAPS style on a bunch of (especially South Korean girl-group) music stuff to mimic logos and other trademark stylizations. But not doing that is the entire purpose of MOS:TM, and related amterial at MOS:CAPS (especially MOS:SIGCAPS and MOS:ALLCAPS), MOS:ABBR, WP:NCCAPS, etc. The proponent is claiming in these cases that the "almost never written except in a particular stylized form" standard has been met, but in every case it is for bands or albums for which no signficant body of native-English sourcing exists at all, just marketing materials, tertiary junk like discography databases, entertainment-news sites with explicit house style to mimic trademarks as closely as possible to please their entertainment-industry advertisers, and Korean, Indian, and other foreign media, with very few exceptions. It simply is not possible for there to be an English-language RS norm to write some band name as FLUFFR when almost all of the tiny number of sources either are not by native English speakers, or are themselves promotional. (In fact, there's so little non-trivial, independent, and actually reliable sourcing that WP:AFD on WP:N grounds is probably warranted for most of them.) Even some of the Korean media outside the entertainment-specific spheres are not going along with these over-capitalizations (i.e., the normal sentence-case usage is very easy to find, in especially pertinent and more independent sources). The proposals also badly fail WP:CONSISTENT policy, in being directly counter to all the other prior RM decisions about such matters.
Next, the heading's question is bogus. There is no conflict with WP:COMMONNAME, which is a policy about what overall name to use (which might be styled various different ways depending on our style guidelines) when there are two or more completely different names. COMMONNAME (part of WP:AT) is what tells us to use David Johansen and redirect from Buster Poindexter rather than the other way around. It has nothing to do with stylization of the name, never has, never will, or MOS simply could not exist (at least not as anything ever applicable to titles, but of course we rely on MoS literally every single day at RM). AT policy and the naming conventions guidelines dependent from it defer to MoS on style questions over and over; this is a system and it works fine. The only "problem" with it – that some individuals can't get the excessive and promotional stylization they desire for the topic they're a fan of (or sometimes a CoI actual representative of) – is no problem at all but is the actually intended benefit to the project in the first place. The sore confusion that MoS is somehow "in conflict" with COMMONNAME is frequent enough (and always has the same answer) that it probably needs to be listed at WP:PERENNIAL, along with several other "trot this out for re-re-re-hash at MoS again" hobbyhorses.
As far as your comments on bad form, I clearly stated my logic and intention. The four requests are different from each other in significant ways, and I notice you did not actually seem to read or speak to the differences in your near-copypaste responses to the four requests (you also asserted incorrect information in some of your responses). As far as everything else you've said, if it's the case that Wikipedia is regularly the only online resource which does not refer to things by their proper name, and the apparent rationale for this is MOSTM, then MOSTM is coming into conflict with COMMONNAME. You've chosen to take as overly hostile an earnest effort to correct a systemic error with this encyclopedia and accuse me of this that and the other, but in this conversation I've made clear I see this as tip of the iceberg. If I was meaning to be disruptive I would've submitted dozens of requests already. Your inability to read and then throw a fit is so typical of this website anymore. 122141510 (talk) 05:44, 1 August 2024 (UTC)[reply]
MOSTM (as currently written) accounts for all of this in its first paragraph. We don’t reject all caps, leet lettering, and other odd stylings… but we are very reluctant to accept them.
IF (and this is a huge “if”) the vast majority of independent reliable sources consistently present a name in all caps, then we know that presenting the name in all caps has transcended mere commercial boosterism. It becomes common usage. Then, and only then, should we accept it.
It takes A LOT of time and effort to establish that the styling has transcended commercial boosterism, but WHEN it has, the guideline says we should accept it. Blueboar (talk) 11:52, 1 August 2024 (UTC)[reply]
Agree that discoverability and participation are issues that affect much of the Wikipedia talk: namespace, but I don't think the solution is to start creating new Villages Pump for individual WikiProjects. Folly Mox (talk) 21:41, 29 July 2024 (UTC)[reply]
@Bogazicili, do you find that those ~10 editors are making bad decisions? If not, then you've already got enough people involved.
I understand the idea of wanting "more", on the emotional side. If I think something is important, then why isn't everyone else showing up? Having a lot of participants validates my belief that this is important. It's like getting a lot of 'likes' on social media: my discussion has 50 people in it, so that means it's important.
However, the point of those discussions is to make decisions, not to help us feel like we're involved in work that other people find important. Google used to put prospective candidates through 12 interviews. However, the answer rarely changed after the fourth interview. [2][3][4] The opinion of just four interviewers was enough in 95% of cases. Eventually, they decided that it was silly to have three times as many people involved as they actually needed, even if those people wanted to feel important. Their hiring process is no longer so burdensome, and is just as likely to make the right choice.
So I ask: Do you really think that we truly need more editors to answer a question about which subject to list? Or are the folks there already doing a fine job and already able to make good decisions? WhatamIdoing (talk) 02:50, 31 July 2024 (UTC)[reply]
I don't think those are unreasonable choices. Car and Ship are level 3, so Train probably should be level 3, too. That's what they chose. I understand your desire to have Climate change be level 2, on par with Earth, Climate, and Geology, but I also understand their decision to keep it on level 3, on par with Weather, Earth science, Atmosphere of Earth, and Pollution. It was not an unreasonable choice, even though it's not the one you wanted. I'm not convinced that involving more people would have changed the outcome. WhatamIdoing (talk) 17:45, 1 August 2024 (UTC)[reply]
Solar system and moon are both level 2, so sometimes something that would be in a subcategory is on the same level with a parent article. I also didn't say involving more people would change the outcome. I am not sure why you felt the need to say that. What I am saying is this: as a principle, core Wikipedia-wide discussions should involve as many people as possible, and should be done on more frequently used places like the Village Pump. Bogazicili (talk) 17:52, 1 August 2024 (UTC)[reply]
Just to give a contrarian (and personal) opinion… I really don’t give a rat’s ass about the various article rating systems. I pay no attention to them.
Now, I do understand that there are editors who LOVE rating articles. I have no problem with that. You do you. I think you are waiting your time, but it’s no skin off my teeth. Just don’t waist MY time with it.
So… I would be very annoyed if the Village Pump was suddenly cluttered up with discussions about article ratings. That wastes my time. Better to have these discussions take place out of sight, on a dedicated page where I can ignore them. End rant. 😉 Blueboar (talk) 20:25, 1 August 2024 (UTC)[reply]
I don't disagree with the principle that many editors should involve themselves in core Wikipedia-wide discussions, but would not characterise as such the importance shuffling within WikiProject Vital articles. Folly Mox (talk) 22:56, 1 August 2024 (UTC)[reply]
I was looking around some pages, and found the now defunct WP:ADCO. I thought that this would be a great idea to bring back in a way, as the amount of RFAs is dwindling, and I believe there is many Wikipedians who would want to start a RFA, but would find it too daunting. I am aware of programs such as WP:RFAPOLL, but believe we need something more. Now I don’t believe we can revive WP:ADCO in its entirety, but I think we can come up with something similar. Thanks, Lordseriouspig05:06, 31 July 2024 (UTC)[reply]
Since new editors very often start out by directing their primary attention toward the lead and infobox—on some articles sometimes receiving almost all their attention—I wonder if it wouldn't be worthwhile to mention very briefly that most information one puts there should be mentioned in the body of the article itself also. I feel bad reverting for this often, and if a chunk of new editors notice this before making their first edits, they may feel better able to continue contributing as they'll get bonked less by moody folks like yours truly.
Even so, I'm not quite sure we can justify it. For one thing, many (most?) will not immediately know what an infobox or lead section are. One would have to write it as a short addendum to
More generally, if someone adds good information to the infobox, and that material should also be in the article (because, no matter what INFOBOXPURPOSE says, that's not always the case), why do you choose to revert it, instead of copying the material to the body of the article? WhatamIdoing (talk) 20:56, 1 August 2024 (UTC)[reply]
I wasn't listing all possible remedies since we all know how editing works here in the lab—I could've just said this but I mostly just meant to say "requires additional work and interference by other editors, whether reverting or revising." Remsense诉21:47, 1 August 2024 (UTC)[reply]
As a regular, I find the UI honestly dull. In an age where the Olympics has a webpage for the purpose of quizzes and games. I find that maybe Wikipedia would be touted as a technological marvel in 2015, but the year is 2024 and, in all honesty, Wikipedia is quite uninspiring. — Preceding unsigned comment added by Usernamesenior (talk • contribs) 19:02, 3 August 2024 (UTC)[reply]
So, your title is "Make the UI more user-friendly", but your actual interest is "make the website something other than an encyclopedia"? Remsense诉19:06, 3 August 2024 (UTC)[reply]
It is a marvel that in 2024 there is a high-profile mainstream website that isn’t filled with ads, flashy junk, and trendy design churn. Well, as long as you think Vector 2022 was an improvement… Barnards.tar.gz (talk) 16:28, 5 August 2024 (UTC)[reply]
There is a great deal of potential in the notion of supporting a quiz/game interface with Wikipedia. It would not be part of Wikipedia per se, but would draw on and depend upon wikipedia. This could be, potentially, the 21st Century Trivial Pursuits. --03:09, 6 August 2024 (UTC) — Preceding unsigned comment added by Ceyockey (talk • contribs) 03:09, 6 August 2024 (UTC)[reply]
There is also a potential for interfacing generative AI into article enhancements in the following way ... Given Wikipedia Article X and Source Y, what propositions would be suitable to pursue for enhancement of the Wikipedia article (X) based on the newly propositioned citation (Y)? The beauty of this is that it provides suggestions to editors about how to contribute rather than working toward AI-based article revisions. Thoughts? --03:16, 6 August 2024 (UTC) — Preceding unsigned comment added by Ceyockey (talk • contribs) 03:16, 6 August 2024 (UTC)[reply]
This is a nice idea. I suppose people can already do this albeit in a clumsy, high friction way now that LLM context windows are large enough to cope with the entire contents of Article X and Source Y. Sean.hoyland (talk) 13:26, 6 August 2024 (UTC)[reply]
But that's not that hard for a human to do. I think the effort of building that infrastructure for mediawiki would outweigh the total effort of doing it the way we do now. Cremastra (talk) 14:06, 6 August 2024 (UTC)[reply]
Bot to block Proxy/VPN IPs (ST47ProxyBot replacement)
Hey folks, I'd like to get some thoughts on an adminbot that monitors RecentChanges and reactively blocks VPN/open proxy IPs it encounters. We used to have ST47ProxyBot which preemptively blocked such IPs, however the bot's operator, ST47, has indicated that they are no longer interested in running this bot. Long story short, there is a plethora of VPN/open proxies on the internet with new operators coming online every day; it has become technically unfeasible to identify and block all of these. Bad actors have been attacking our admin noticeboards with these VPNs/open proxies which has resulted in them being semi-protected for extended durations of time. That said, I'm interested in building an adminbot that monitors RecentChanges (or just the administrator noticeboards) for edits from VPN/open proxy IPs and blocks them (can optionally revert the most recent edit made by these IPs too). Noting for the record that some discussion on this has occurred here (permalink). Courtesy ping for @Robertsky. -Fastily21:25, 8 August 2024 (UTC)[reply]
I don’t have strong feelings against this one way or another. I share the concerns of others that, especially with developments in internet infrastructure over the past decade or two, it is much less simple to block open proxies now. But if an admin bot can accurately evaluate (with a sufficient level of accuracy) and block/revert, so what if it only catches 1% of the actual open proxies? I also think this should be evaluated as a “continuation” of the prior adminbot - even if it has slightly different code, from what I can see there was consensus for this type of adminbot before so absent significant new concerns about the stability/false positives now, should be fine for Fastily or another admin to take over the *task* even if doing it with different code. -bɜ:ʳkənhɪmez | me | talk to me!21:35, 8 August 2024 (UTC)[reply]
Thus far the disruptive IP addresses that have been blocked on the admin boards has proxy-like behaviours stated in the user information tool (that can be seen on the Contributions page). That can be a likely reliable signal/condition to revert and block such IP addresses if they touch on the admin boards. – robertsky (talk) 10:52, 9 August 2024 (UTC)[reply]
Agree with Berchanhimez that this task doesn't seem like it should require a second consensus for approval, but if it does I support it. Folly Mox (talk) 11:28, 9 August 2024 (UTC)[reply]
A bot that monitors recent changes and reactively blocks VPN/open proxy IPs rather than preemptively may be a useful compromise. We already have a bot that monitors recent changes and logs VPNs/proxies at WP:OPD; it seems to log very many but perhaps not all, that will be dependent on the database. As an aside, I’ve never see so many blocked 'anonymizers' on that log, which is almost entirely due to the current disruption.
The current disruption is using a very particular anonymizing network so perhaps a focus on blocking that one preemptively would be helpful in the short term. -- Malcolmxl5 (talk) 18:38, 9 August 2024 (UTC)[reply]
I think we many need to look at some possible ways to fix WP:OR. Apparently, one editor thinks it means you can't use any news media coverage for articles. i think their point is maybe that you can only use peer-reviewed articles to cover current events, since those are published findings? i think.
this whole thing kind of doesn't make a whole lot of sense, to me. anyway, I am trying to decide what to add to WP:OR. i have a few possible drafts, but i wanted to get this section started now. i hope to work on some possible drafts, and then post them soon. However, please feel free to comment now. Sm8900 (talk) 14:01, 9 August 2024 (UTC)[reply]
If the issue is just one editor misunderstanding the existing content then the solution is to explain to them what it actually means. If they cannot or will not understand that then the solution is to take action against that user to prevent their misunderstanding disrupting the encyclopaedia. Only if the misunderstanding is widespread is a rewrite of WP:OR likely to be needed. Thryduulf (talk) 14:09, 9 August 2024 (UTC)[reply]
@Thryduulf, that sounds pretty good. i could use a little heelp, actually. would you be willing to please add some input? you can find the article talk page easily, in my contribs history today. Sm8900 (talk) 14:52, 9 August 2024 (UTC)[reply]
(edit conflict) If we want a misinterpretation that's so wide-spread it has been written into the policy, how about we get rid of most of Wikipedia:No original research#Primary, secondary and tertiary sources? As far as I've ever seen, the distinction between "primary" and "secondary" is often unclear and seldom actually useful versus the nutshell of WP:OR itself, Articles must not contain any new analysis or synthesis of published material that reaches or implies a conclusion not clearly stated by the sources themselves. Even much of what's said in the PSTS section is just as true if you only read "source", ignoring the adjectives. Mostly the section seems a vehicle for people to reject a source for being "primary" (i.e. the opposite of the essay Wikipedia:Primary does not mean bad) instead of having a harder discussion about WP:RS and WP:DUE and the other parts of WP:OR. But I doubt this will go anywhere, too many people value exactly that vehicle. Anomie⚔15:02, 9 August 2024 (UTC)[reply]
@Anomie I agree too. I've lost count of the times that I've had to argue that for objective facts primary sources are often the most reliable sources. Thryduulf (talk) 16:06, 9 August 2024 (UTC)[reply]
I agree too. Secondary sources are fine when we have them, but the current wording seems to disfavour primary ones more than they deserve. Gawaon (talk) 16:45, 9 August 2024 (UTC
here is the kind of comment i have to deal with in opposiition to using perfectly good factual data, from perfectly reliable good sources from newspapers: The text that would be added makes no coherent case or argument. It has no clear theme, thesis or point. It does not show an analysis. This would require secondary sources - preferably of good quality. That would then be encyclopedic content. Research is the analysis of primary material. Drawing together the data is the first step in research. The added text alludes to a thesis, which, if stated, would be OR (where the thesis does not exist in sources). But without this, the text lacks the cohesion and substance that would make it encyclopedic. If the thesis is not presented in sources, it probably isn't noteworthy - or perhaps it hasn't been found. Either way, the addition as made isn't supported.
so this comment is saying that absolutely no data can be gleaned from primary sources such as newspaper accounts, firsthand accounts, etc. really!! this is unbelievable!! is there anything we can do???!!! Sm8900 (talk) 01:59, 10 August 2024 (UTC)[reply]
so by this logic, even a published book would not be able to serve as valid source for self-efident objective facts, such as the book plot etc!!! this doesnt seem reasonable!!! Sm8900 (talk) 02:01, 10 August 2024 (UTC)[reply]
Without more context, that's a discussion that probably needs to happen on the page where it's happening rather than here. "The text that would be added makes no coherent case or argument" is something one cannot judge without knowing the text in question. Gawaon (talk) 06:39, 10 August 2024 (UTC)[reply]
@Gawaon, the talk page is at Talk:Iraq War. they are simply refusing to let me use newspaper articls that clearly show that major national leaders expressed opposition to the war years later. the question of whether that topic is needed is not the focus of the comment above; they are literally rejecting any use of newspaper articles, as clearly shown in the comment above. Sm8900 (talk) 11:12, 10 August 2024 (UTC)[reply]
I believe that news sources are good for basic facts, but their use should mostly end there. It's not that you should never use news articles as sources, but at a practical level the key is contemporary versus retrospective coverage. Real time contemporary sources definitely shouldn't be used to determine notability, provide analysis, explain effects or significance, etc. They lack the scope and context to make that possible. To avoid bogging down discussions every time this comes up, I wrote my full thoughts at User:Thebiguglyalien/Avoid contemporary sources. Thebiguglyalien (talk) 07:31, 10 August 2024 (UTC)[reply]
by this logic, you would never be able to write articles about opinions of major public figures at all. you would not be able to use a newspaper article to glean a public figure's opinions on anything, and you would need to someohow search for some complex thesis article when writing even about the most minor issues. Sm8900 (talk) 11:20, 10 August 2024 (UTC)[reply]
Well, that's kinda the point? If no one else has ever written about the views of some major public figure on some topic in e.g. a book about the topic or the public figure, and the only place we can find that information is in some contemporary news article, then it's probably not important enough to include in an encyclopaedia article. Folly Mox (talk) 13:28, 10 August 2024 (UTC)[reply]
Sm8900, I took a Quick Look at the text you would like to add, and immediately saw why other editors are saying that it violates WP:OR. The text starts with a sweeping statement about the world’s view of the war and then attempts to support that statement by giving examples of politicians sharing that view. The examples are individually (and appropriately) supported by citing news sources, but… what is missing is a source that sums up these examples to reach the initial sweeping statement (a conclusion, even though it is written first).
This is classic original research. We can not take examples A+B+C and state conclusion D … unless we have a source that explicitly states A+B+C=D. This is precisely why WP:PSTS warns that primary sources must be used with caution. It is very easy to misuse them to inappropriately support original research. Blueboar (talk) 12:45, 10 August 2024 (UTC)[reply]
That does not resolve the Original research… the problem is that you (a Wikipedia editor) are the one combining these individual statements by various politicians to form a conclusion. What you need is a reliable secondary source that combines the statements by various politicians to reach some form of conclusion.
Weasle wording “some” also introduces DUE WEIGHT issues: why were the statements by these specific politicians chosen? Do they represent the majority view or are they cherry-picked outliers? Are there politicians who have contrary views?
Again… what you need to look for is a secondary source that notes what various politicians have said about the war, puts what they said into context and sums it up. Doing it yourself (even hedged by weasel wording) is where you engage in the original part of NOR. Blueboar (talk) 13:40, 10 August 2024 (UTC)[reply]
Those kinds of secondary sources don't always exist, depending on the topic. And when reporting politicians positions and views, then published news articles seem totally acceptable as sources. Sm8900 (talk) 22:35, 10 August 2024 (UTC)[reply]
That's the point. If those secondary sources don't exist, then it should not be in the article. To quote WP:PROPORTION from the NPOV policy: An article should not give undue weight to minor aspects of its subject but should strive to treat each aspect with a weight proportional to its treatment in the body of reliable, published material on the subject. For example, a description of isolated events, quotes, criticisms, or news reports related to one subject may be verifiable and impartial, but still disproportionate to their overall significance to the article topic. This is a concern especially for recent events that may be in the news.Thebiguglyalien (talk) 22:50, 10 August 2024 (UTC)[reply]
That sounds vastly exaggerated and non-proportional. Especially for recent events, it'll take years, if not decades, until they (maybe) get reliable coverage in secondary (later insertion: academic) ssources. Academics don't work so fast. Plus many films, series etc. may well get next to no coverage in secondary sources at all, despite meeting our notability criteria. If there are secondary sources, it's best to chiefly rely on them. If not, primary and tertiary sources may well come to the rescue, and that's a good thing. Gawaon (talk) 06:58, 11 August 2024 (UTC), edited 07:25, 11 August 2024 (UTC)[reply]
If there's next to no coverage in secondary sources at all, then it is not notable. Per WP:GNG: "Sources" should be secondary sources, as those provide the most objective evidence of notability. There is no fixed number of sources required since sources vary in quality and depth of coverage, but multiple sources are generally expected. If you think that means Wikipedia would have to ignore most current events, then you're correct. Wikipedia doesn't exist to document news. Thebiguglyalien (talk) 07:08, 11 August 2024 (UTC)[reply]
Okay, I got confused a little bit. Generally I tend to think of secondary sources as academic sources, and I'd say those are indeed among the best sources we have. But I had somehow mentally classified newspaper coverage and such as tertiary sources. However, it seems they are generally considered secondary too. WP:NOR#Reliable sources even says that "magazines, journals ... published by respected publishing houses" as well as "mainstream newspapers" are among "the most reliable sources". So sure, a topic needs sufficient coverage in secondary sources, newspapers included, to get its own article, per WP:GNG. I absolutely agree on that. But note that the GNG is about whether a topic gets its own article, it's not about the article content at all. See WP:NNC. Here we're mostly talking about content, so the GNG doesn't apply. Gawaon (talk) 07:42, 11 August 2024 (UTC)[reply]
While some changes might be needed, I think I would be against "getting rid of most of Wikipedia:No original research#Primary, secondary and tertiary sources." In editing historical topics, I have found WP:PRIMARY useful. Users have, for example, tried to argue that Nathan Bedford Forrest wasn't actually racist or involved with the KKK, tried to argue that Mehmed II committed rape on the floor of the Hagia Sophia, etc., using primary sources. If accounts like these (memoirs, diaries, travel literature, ancient histories, etc.) aren't reinforced or repeated by scholars, they usually don't belong in there. I am definitely not arguing for a blanket ban on journalistic sources; the user you're telling about was clearly misinterpreting it. I am just saying how it has been useful for me.--MattMauler (talk) 14:24, 10 August 2024 (UTC)[reply]
Content assessment tweaks
Since Content assessment was decoupled from individual WikiProjects, I'd like to develop an idea regarding how it can be tweaked. Currently assessments for Stub-class to B-class can be placed on a talk page by any editor, but the manner in which reassessment is done can be a little tricky. If an editor wants to have their article reassessed (such as moved up from Start to C class), where to do this is currently a little convolluted.
This can be asked on the article talk page, but most talk pages on Wikipedia are will not yield a result, as they are either empty or inactive or both. Or it can be asked on a WikiProject page, which is still not a guarantee of getting it answered (also, might defeat the point of unlinking content assessment from WikiProjects in the first place). Or it can be asked on Wikipedia:WikiProject Wikipedia/Assessment – which doesn't make sense technically. Surely WikiProject Wikipedia/Assessment should be about articles relating to Wikipedia, instead of acting as a general catch-all page as it currently does.
My question is – how could this be optimised? For example, should assessment requests be moved to one centralised location? If so, where? Hope village pump can help me here DimensionalFusion(talk)15:44, 10 August 2024 (UTC)[reply]
Other than promotion to GA or FA status, very few editors pay attention to article assessments… so we don’t actually need clear cut criteria or a process for assessment. We can rely on editorial judgement.
If you think an article should be assessed as being in a certain “class”, feel free to mark it so. If someone else disagrees, discuss it on the article’s talk page. Blueboar (talk) 16:11, 10 August 2024 (UTC)[reply]
Yes, and marking an assessment totally independently, without any input from others is and would remain a valid way to assess an article. However, some people may not wish to do this and may want to have an uninvolved editor look at the page. This is the problem I would like to address DimensionalFusion(talk)16:17, 10 August 2024 (UTC)[reply]
(edit conflict) If there is benefit in an editor being able to request someone else take a look at an article and seeing whether they think the quality assessment is correct then I can think of two approaches that might work:
A central location in which to ask.
A template that can put on an article talk page that populates a category.
In both cases WikiProject article alerts should be generated to aid discoverability by editors interested in the relevant topic area.
Whether there is benefit in such a system is a different question, but I think the answer is yes. Even if it's optional in most cases, someone who was heavily involved in rewriting the article or who has a COI with regard to the subject or who is a declared paid editor may want to (in the latter two cases probably should) ask for another editor's opinion. Thryduulf (talk) 16:20, 10 August 2024 (UTC)[reply]
If I come across an assessment that is clearly wrong on an article I am involved with, I simply edit out the assessment. By means that are completely mysterious to me someone eventually comes along and (re)assesses it. Thincat (talk) 10:17, 11 August 2024 (UTC)[reply]
@DimensionalFusion I think @Thincat is saying that if an article they are involved with is rated as e.g. start class but they believe that is clearly wrong they will simply remove the assessment rank, meaning the formerly start class article is now unassessed class. In their experience these articles then get a new rating (that presumably more closely matches their opinion) from somebody else without any additional input from them (i.e. they make no requests anywhere). They don't know how the people who do the new assessment become aware that this needs doing (although my guess is that they're patrolling e.g. Category:Unassessed United Kingdom articles). Thryduulf (talk) 10:39, 11 August 2024 (UTC)[reply]
In my experience that doesn’t tend to lead to articles being reviewed, either because it is a broad topic (leading to a huge backlog) or because it has a very inactive wikiproject DimensionalFusion(talk)10:51, 11 August 2024 (UTC)[reply]
For context, I am primarily an editor in the Simple Wikipedia, although I occasionally edit here. Many Wikipedia readers and editors switch to Simple Wikipedia by changing the domain from "en" to "simple", and back. This works well until you get into categories involving films. In simple wikipedia, "films" are referred to as "movies". In English Wikipedia, the only redirect that redirects you from "movies" to "films" is Category:Movies. I wonder if it would be possible or even a good idea to create every related Film category and create a Movie redirect page for it. For example, Category:1942 movies would redirect to Category:1942 films. This would also go for any templates, articles, etc., that would be related. I think this would be a good idea since this is an often enough redirect target, and the words are basically synonyms. I would also wonder if there is a way to automate this. Thank you. MrMeAndMrMeTalk04:14, 11 August 2024 (UTC)[reply]
WMF
POTY (Picture of the Year) competition needs help!
POTY desperately needs new volunteers who can do the things required to run the competition. With the current state of the committee, it is likely that there will be no POTY this year, as the main member who ran scripts for the competition has burned-out from doing wikipedia tasks and isn't up for it. Others on the committee are also missing in action.
The political evolution of the US is worrying, given that the WMF is based there. What if in a few years the US government takes control of the WMF, seizes its assets, or becomes otherwise hostile? Can Wikipedia as we know it survive without being based in the US? Are there plans for decentralization or redundancy? Sylvain Ribault (talk) 19:08, 18 July 2024 (UTC)[reply]
Without speaking to the political situation, I will note that Wikipedia is backed up on server farms in other countries, and anyone can operate a clone of Wikipedia from anywhere, even if they could not use the name "Wikipedia". Donald Albury20:27, 18 July 2024 (UTC)[reply]
Interesting question. The WMF itself is pretty much entirely centralised, but it's always been pretty good at making it easy to mirror or fork Wikipedia. Our license is of course also a big help. So in this kind of scenario, I imagine preserving the content would be no problem at all, but reassembling the community would be difficult, and rebuilding the kind of financial resources the WMF has (to host, maintain, and develop Mediawiki) would be very challenging indeed. – Joe (talk) 20:42, 18 July 2024 (UTC)[reply]
Whatever dystopian future awaits the US, that the WMF would be taken over by political hacks is 3 or 4 apocalypses removed from reality. Headbomb {t · c · p · b}11:59, 19 July 2024 (UTC)[reply]
I think the main actual obstacle is that Wikipedia's existence depends on a fairly high degree of active maintenence of the MediaWiki software, and also -- most crucially -- that search engines give us a gigantic volume of incoming traffic. Incidentally, the forks that have existed have routinely had trouble with being absolutely slaughtered in Google rankings because their content is all considered by the algorithm to be "plagiarized" from Wikipedia. jp×g🗯️12:26, 22 July 2024 (UTC)[reply]
One of our most important tools, Earwig's Copyvio Detector, depends on access to Google. According to the tool's creator and operator, The Earwig, the WMF has kindly been paying for this Google access. Unfortunately, we've been hampered by a strict limit on the number of searches allowed per day. The Earwig mentioned that there might be a way to work out a special arrangement with Google to increase the cap. Would someone at the WMF be able to pursue this?
In case it helps, this is a vital tool to a number of English Wikipedia processes, and it would surprise me to learn that the sister projects aren't using it as well. We use the tool routinely as part of our new page patrol, articles for creation, contributor copyright investigations, did you know, good article, and featured article processes. Historically, the WMF has taken a special interest in supporting volunteer work that focuses on our legal responsibilities, of which compliance with copyright law is an obvious example. Firefangledfeathers (talk / contribs) 01:34, 31 July 2024 (UTC)[reply]
My understanding is that Google has a hard daily limit of 10,000 API accesses per day for absolutely everyone across the board, without exception. User:Novem Linguae/Essays/Copyvio detectors#Earwig copyvio detector. My impression is that an exception wasn't possible because Google doesn't provide an exception to anyone. Earwig would know best though.
Earwig didn't ask me to do anything on his behalf. He mentioned that "the WMF pays for it, but Google's API terms limit our usage without some kind of special arrangement that I have been unable to get." This was at a discussion at his user talk. I wasn't sure who might be able to negotiate a special arrangement, and I'm not sure it's a possibility, but this was the best place I could think to ask. Firefangledfeathers (talk / contribs) 04:26, 31 July 2024 (UTC)[reply]
A bit odd that Earwig isn't doing the advocating himself, but on the linked user talk page, it does sound like he's asking for some help with this. Would The Earwig be willing to share his contacts at WMF that have helped with this in the past? Sounds like WMF pays for the tool, so there's some accounting/finance/grants contact that knows a little about it. And we also have partnerships people like NPerry (WMF) that I believe has worked with Google before. –Novem Linguae (talk) 04:43, 31 July 2024 (UTC)[reply]
From what I've heard, the WMF contact that Earwig had has since left the Foundation and wouldn't be able to help in this case. You are correct that WMF pays for the tool. I had mentioned this at the Hackathon with staff and it seems there's some resistance in getting the cost of extra tokens funded, although I'm unsure of exactly how the WMF's budgeting process works, so no clue on the impact it has in this situation (considering we don't have a Google liaison to begin with). Chlod (say hi!) 05:20, 31 July 2024 (UTC)[reply]
Even the name of a former WMF employee contact would be helpful. Let's get all this documented so we can start figuring out what WMF departments/teams have assisted in the past. –Novem Linguae (talk) 05:26, 31 July 2024 (UTC)[reply]
Hi all. Firefangledfeathers, thanks for starting the discussion. Novem, sorry if this thread came up a bit strangely. In truth, I struggle a little with motivation these days, so I really appreciate others' help getting the ball rolling. I am still here, though—it comes in waves. (It's also good to involve the community in the tool so the institutional knowledge isn't stuck with me.)
BTW, I am working on more effectively managing automated/excessive tool usage and will soon require OAuth to run searches (see this active thread on my talk). Right now the tool really doesn't have any usage guards or a way to limit individual users' activity, which isn't good when our resources are so limited. It's possible doing that will free up our resources a lot if a substantial fraction of our current usage is coming from malicious crawlers, despite Chlod and I's attempts at blocking them (the tool has been running for over a decade and it's never been this bad, though I have a theory what this is about). Even so, finding a way to increase our search quota will enable us to support some requested features that are current nonstarters, even if the tool's entire current quota could be devoted to it, like checking all new pages.
My main point of contact with the WMF in the past was Kaldari. The last time we spoke about the tool was 2020; since then, the situation has been unclear. (MusikAnimal, do you remember if we've spoken about this?) Last year Runab WMF and DTankersley (WMF) reached out to me to discuss the tool in the context of WMF efforts "to find ways to reduce single points of failure for tools that require a third party API", but after an initial conversation I haven't heard back aside from being told that Deb was moved to another project, so I'm not sure what happened with those efforts.
Frequently we've discussed adding an alternate search backend aside from Google. While Google is really the gold standard for breadth of search coverage, as far as I'm aware—and this is really what the copyvio detector needs, not necessarily quality/intelligence; people have suggested services like DuckDuckGo, but they're really unsuitable because they just republish raw results from Bing with some additional flair that is basically useless for us—something like Bing itself might work as an (automatic) fallback if we exhaust our Google credits for the day. I believe Bing has roughly equivalent pricing/usage limits as Google, but it's been a while since I've looked into it. And we/the WMF would need to establish a relationship with Bing for that to work; I don't know if that's a better idea than attempting to negotiate our Google limits. There are also other options like Yandex (which the tool did use one dark time in the past before the Google relationship and after Yahoo ended their free service... it wasn't great, at least for English results, but it's something that could be looked into for some other language projects, perhaps). Finally, there was a discussion on my talk earlier this year with Samwalton9 (WMF) about adding The Wikipedia Library as another search backend, and I did correspond briefly with someone at EBSCO about this, but again, I haven't heard from either of them about this in several months. — The Earwig (talk) 06:51, 31 July 2024 (UTC)[reply]
So the Google API proxy and the Google account it runs on are wholly part of Community Tech's budget. Kaldari was the contact in the past when they were my manager on CommTech. So the good news is Community Tech is still here, and we are actively maintaining this proxy (I just migrated it to a newer Debian a few days ago). The part that hasn't changed is our quota from Google, and sadly I doubt it will change. We are already paying hefty fines for the quota we have now, but I believe it is also correct that 10K is a strict limit from Google. I can see from the graphs in the API console that we almost always hit that limit within the first 12 hours of each day.
I am working on more effectively managing automated/excessive tool usage and will soon require OAuth to run searches … – that is most certainly the best immediate recourse for addressing this problem. From my years of shielding XTools from web crawlers, I can say with confidence that putting up a login wall by itself should make a big difference. I also think mitigating excessive and automated use is something that would probably be required before we could consider dishing out more money to Google. However again, I don't think such negotiations would get us anywhere anyway :(
As a general note, such "negotiations" are typically done these days via the Partnerships team. I went though them recently when we solidified our partnership with Turnitin. Speaking of which… do others find the "Use Turnitin" option of Copyvios at all useful? Because that's using the old Turnitin account (the new one can't be used outside CopyPatrol), and the last I checked there were still a few million credits left. — MusikAnimaltalk20:52, 1 August 2024 (UTC)[reply]
The Google API Proxy (docs at wikitech:Nova Resource:Google-api-proxy) exists solely to anonymize requests to the Google APIs, should they be used in a fashion that sends personal data such as your IP or user agent. As far as I know, Copyvios has always accessed Google APIs through this proxy.
I'm not aware of any sort of sliding scale as far as pricing goes, and my use of the word "hefty" was relative to my team. However since I made my reply above, I have been informed that the budget is actually not solely from Community Tech, as it was in the past (but we do still maintain the proxy). I don't have any details about internal accounting, I'm afraid. My apologies for any confusion caused. — MusikAnimaltalk19:48, 2 August 2024 (UTC)[reply]
Wouldn't the Toolforge tool itself serve as an anonymizing proxy as long as the Google API requests are being sent via a backend rather than via browser JavaScript? But that's a bit of a tangent :) –Novem Linguae (talk) 22:18, 2 August 2024 (UTC)[reply]
I'm willing to entertain alternate methods for anonymous users to access the tool. I do need some way to attribute usage to a human, though. Any suggestions? I might present a challenge page where you have to answer some question (essentially a CAPTCHA, but one that works without JS). Or I can require anonymous users request a token (that would be saved as a cookie so does not need to be entered with each request). — The Earwig (talk) 00:00, 10 August 2024 (UTC)[reply]
That's a good question, but I can't tell from the documentation whether temporary accounts are able to use OAuth. I would need to test it. (And we may need some other solution in the meantime, before that's deployed.) — The Earwig (talk) 14:25, 10 August 2024 (UTC)[reply]
Feature updates from the Tech News: Stewards can now globally block accounts; Wikimedia site users can now submit account vanishing requests via GlobalVanishRequest; and interface of FlaggedRevs (also known as “Pending Changes”) is improved.
This month’s Wikimedia Research Showcase highlighted the impact machine translation has on both content and readers of Wikipedia and provided interesting insights on how to overcome related challenges. Watch the recording.
The Charts project officially kicked off. The goal of this new initiative is to restore basic data visualization capabilities to the wikis. Check out the project page and follow our progress on Phabricator.
The CampaignEvents extension is now available on Meta-wiki, Arabic Wikipedia, Igbo Wikipedia, and Swahili Wikipedia, and can be requested on other wikis. This extension helps manage and make events more visible. Learn about how to request this extension.
The Campaigns Product & Programs teams have launched a consultation on WikiProjects and other forms of collaboration on the wikis. They want to understand why they work (or don’t work) for some Wikimedia communities, and they want to learn what can be done to improve the experience. Everyone is encouraged to share their feedback.
The Board of Trustees selection pre-onboarding and campaign period is open from July 25 to August 26.
Foundation Trustee Dariusz Jemelniak was appointed to the Governing Board of the European Institute of Innovation and Technology, established as part of the EU’s key funding program for research and innovation.
I am an occasional user of SWViewer, a vandalism patrolling tool that is (in my understanding) partly maintained by the Wikimedia Foundation. I generall like its interface and design, and I have found it to be a useful tool.
I do have one item that I would like to discuss though: I think it would be wise to add a checkbox for whether or not to mark an edit as minor. Currently, the interface allows users to tick a box for "Use undo" when rolling back an edit with a summary. This is good, but it only allows users to revert edits in a way that is marked as minor. I understand that certain wikis, such as the English Wikipedia, have a very narrow understanding of what constitutes a minor edit, and there are times when I want to undo an edit but it is not technically a minor edit. This makes me have to manually go to the English Wikipedia and click the "undo" button there rather than keeping all of this in the SWViewer interface.
Is there a way that the WMF could either:
Not automatically mark edits made while "Use undo" is ticked as minor (i.e. submit them to non-minor edits); or
Allow users to select whether or not their actions are considered to be minor edits (via a tick box)?
Hi, I'm not WMF staff (although I am the Wikimedian of the Year) but I noticed something I thought should have wider community input. Please keep in mind that as far as I'm aware this is in very early stages and there is no guarantee that it will actually be implemented. Also, please be nice. I anticipate that some people will be surprised by what it was being proposed here so I felt like this was an important reminder. Anyways: mw:Wikimedia Apps/Team/iOS/Fundraising Experiment in the iOS App. There is a feedback section towards the end of you wish to give it. I have already commented there. Clovermoss🍀(talk)17:47, 10 August 2024 (UTC)[reply]
This is an example of what is being proposed. Essentially, there would be a donation button near the top right of an article and these would kind of be like Reddit trophies. I think this needs way more visibility than being buried in the depths of mediawiki which is why I'm posting here. Clovermoss🍀(talk)18:52, 10 August 2024 (UTC)[reply]
I would also say it should be reverted to maintain the original intent, but there will also be sources to support the current version of the article, as the new version is literally for another town. The telugu page (te:పోరండ్ల (జగిత్యాల)) has always been about the current (Jagtial) Porandla, as has the associated Wikidata item (wikidata:Q13003257). The original (Ranga Reddy) Porandla is at te:పోరండ్ల (మహేశ్వరం)/wikidata:Q16340753.If the original wording is restored, the thing to do here would be to revert, split off Jagtial Porandla, disambiguate Ranga Reddy Porandla, and then switch the relevant Wikidata entries.(As an aside, the one-up division, te:జగిత్యాల గ్రామీణ మండలం is one of the few Jagtial district#Mandals without an en.wiki article.) CMD (talk) 04:15, 26 July 2024 (UTC)[reply]
How do you determine the "size" of a list (or merging / splitting purposes)?
Ok, this may be a silly and redundant question. So, WP:SIZERULE gives good guidelines for when articles should be trimmed or merged. However, WP:SIZE states that readable prose size only includes "the amount of viewable text in the main sections of the article, not including tables, lists, or footer sections." For the purpose of merging lists, and with the removal of the kb limits (which I had previously used to judge list size) on WP:SIZEhow do you determine the size of a list (as related to existing guidelines stated on WP:SIZERULE) if you wish to merge or split a page? Historyday01 (talk) 13:17, 5 August 2024 (UTC)[reply]
The kb limits on WP:SIZE also applied only to readable prose, nothing has changed in that respect. List splits likely come down to editorial judgement, what best helps a reader. Some lists do still end up breaking other limits like WP:PEIS, but that's not common. CMD (talk) 01:25, 6 August 2024 (UTC)[reply]
Low standards for references on the English Wikipedia
Why does the English Wikipedia allow the creation of articles without reliable sources? For example, if you look at the references for "El amor de mi bohío," you will find databases, blogs and other wikis. The same with Mira que eres linda, the sources are blogspot and Brito EcuRed. That's why many editors whose articles are deleted on the Spanish Wikipedia come to create them here, because the requirements for reliable sources are minimal. I don't think this does any good for Wikipedia's reputation. KokuyoKoychi (talk) 22:25, 5 August 2024 (UTC)[reply]
@KokuyoKoychi, the requirements aren't minimal but enforcement is difficult. Hundreds (or more) articles are created every day. There aren't enough editors to screen each one (although the New Page Patrol makes a valiant effort at doing so). Schazjmd(talk)23:41, 5 August 2024 (UTC)[reply]
The voting period for the Universal Code of Conduct Coordinating Committee (U4C) is closing soon. It is open through 10 August 2024. Read the information on the voting page on Meta-wiki to learn more about voting and voter eligibility. If you are eligible to vote and have not voted in this special election, it is important that you vote now.
Why should you vote? The U4C is a global group dedicated to providing an equitable and consistent implementation of the UCoC. Community input into the committee membership is critical to the success of the UCoC.
Please share this message with members of your community so they can participate as well.
Normally it is not possible to full-text search through the Wayback Machine. However, they do make available certain collections for full-text search, such as the US Government docs collection has 403 million pages. The list of collections currently available for searching:
This is a beta service. There is currently a bug in the interface sometimes it redirects to the home page. If this happens, go to a collection search that is working (such as the US govt docs link above) and use the pull-down menu to navigate the collections. You can also search via URL such as:
The technical village pump is a good place to discuss the implementation details of a design. However to discuss the design itself, this village pump page would be more suitable. isaacl (talk) 21:48, 9 August 2024 (UTC)[reply]
Ban in Azerbaijani Wikipedia
Hello, I would like to complain about the administrators of the Azerbaijani Wikipedia.
The fact is that when I added az:Yenisey (Yenisei) in parentheses to the article its name in the Yenisei language in addition to the Russian term (and of course wrote the source from the 1899 book), I was banned by the Nemoralis administrator. To the question “what Wikipedia rule did I break,” he answered in an arrogant manner, “your account will not be unblocked.” I wrote this message here because I don’t know where to write. I also wrote the message to the Azerbaijani section, but Azerbaijani administrators support each other since for several years in a row these are basically the same people.
Please help me in this situation. At least express your opinion, please.
To make it clearer, I write the difference between the articles:
Normally the standard reply is enwiki has no powers over azwiki (and azwiki over enwiki). But you could try to find an azwiki admin who is active on enwiki. You could ask them about it here, in a neutral ground, maybe also try to find a neutral person on enwiki not from azwiki, to help moderate the dispute. It seems extreme to ban someone over what you describe so either they are bad amins or there is more to the story. -- GreenC19:35, 9 August 2024 (UTC)[reply]
"bad admins" is surprisingly plausible. There are four azwiki admins indefinitely blocked here (Solavirum, Nemoralis, Wertuose, Atakhanli), including the admin who blocked Sebirkhan on azwiki. But Google Translate of the azwiki discussion linked to paints a different picture than an admin cabal supporting each other. * Pppery *it has begun...19:59, 9 August 2024 (UTC)[reply]
Indeed, this editor appears to have continuously ignored advice regarding using old sources for names in article leads and received a one-month block in response. I don't see any indication of foul play, and I say that as the admin who blocked 2/4 of the az.wiki admins listed above from en.wiki. signed, Rosguilltalk20:22, 9 August 2024 (UTC)[reply]
However, I do not understand why I cannot add the name of the Yenisei River in the Yenisei language in brackets, while the name of this river in other languages is added at the beginning (Maybe then we should delete all the names and leave only the official one - Russian). Where should I add this name if not in this Wikipedia article? I consider it important for preserving history. After all, I did not come up with this name. But the administrator deleted it and blocked my account and my IP Sebirkhan (talk) 20:35, 9 August 2024 (UTC)[reply]
As the admin of AzViki, I can say that the user presents the situation differently. The user constantly adds words in the old Azerbaijani language or the old Turkish language to the beginning of the articles, changes the names of the articles. We have repeatedly warned him to use only modern Azerbaijani words, not archaic words. As a result, he was blocked at the very end. And now he allegedly says that he added the word in Yenisei language to the beginning of the article, while he added the version in ancient Turkic language, which is unrelated to the topic. However, the Yenisei language has nothing to do with the ancient Turkic language. And the user does such things many times. The user even once wrote that the word "shogun" is a Turkish word in the Shogun article on AzWiki. Cosmic Bardutora!20:32, 9 August 2024 (UTC)[reply]
It is not true because, A regular azwiki user does not have the technical ability to change article titles. Also I do not use Turkish language in Azerbaijani section.
Everything you write is far-fetched, because I have never written in my life that shogun is a Turkish word or comes from a Turkish word. However, thanks to me, the administrators eventually changed the name of the page Syoqun to Şoqun (which is correct from the point of view of the Azerbaijani language and Japanese language, and also others) and this is a fact if you look at the history of the article. Sebirkhan (talk) 20:41, 9 August 2024 (UTC)[reply]
In the edit Cosmic Bard identifies, you added [[Qədim_türk_dili|Əski türkcə]]: 𐱁𐰭𐰆𐰣, /şöŋün/, which would indeed suggest that the origin of shogun is Old Turkic. signed, Rosguilltalk20:52, 9 August 2024 (UTC)[reply]
You are right, however (even though this is a word written in dictionaries), I thereby pointed out the inconsistency of using the Russian form Syoqun in the Azerbaijani language, in the end we came to a compromise Şoqun. I was not banned for this reason. The azwiki administrator is simply trying to direct the conversation in a different direction. While not banned for this, specifically I received a message about blocking after changing the Yenisei page and the administrator canceled my edits. Sebirkhan (talk) 20:58, 9 August 2024 (UTC)[reply]
You are not blocked just because of the Yenisei River article. Everyone can do something wrong. A user cannot be blocked for one edit. You are blocked because you keep doing things like this. Before that, you wrote the Dnepr River as "Ozü River" in a article, and I warned you about this, that this river is not called Özü River in any source in the modern Azerbaijani language. I will not comment further on this issue here, because it is not EnViki's issue, but AzViki's issue. Cosmic Bardutora!21:08, 9 August 2024 (UTC)[reply]
Works for me Specific examples please. --Redrose64 🌹 (talk) 06:47, 5 August 2024 (UTC)
Two new parser functions will be available this week: 
Done @Novem Linguae: I've promoted this from test to template-gadget; please validate and ping me if any issues. — xaosflux Talk 15:29, 9 August 2024 (UTC)
Polygnotus (talk) 00:30, 10 August 2024 (UTC)
Moved from Wikipedia talk:Village pump
Agree Sm8900 (talk) 15:39, 9 August 2024 (UTC)
_en_el_Palacio_de_Nymphenburg,_M%C3%BAnich,_Alemania35.JPG)
wikimedia.org know if you have any feedback or suggestions for improvement!
![[7]](https://imgs.xkcd.com/comics/wisdom_of_the_ancients.png){kind=link}
