Wikipedia:Village pump (proposals)/Archive 197

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

---

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Can we retire the outdated 2000s Wikipedia slogan "Anyone can edit"?

To the Wikipedia staff members and users. Over the 20 years that Wikipedia was in business. I noticed that you have a slogan in the main page "The Free Encyclopedia anyone can edit" I personally have issues with that Wikipedia slogan. "Anyone can edit" and here's why.

I've noticed in the news articles concerning Wikipedia vandalism being caused by visitors not logged in or sometimes even the Wikipedia users who misuse and abuse the Wikipedia articles or POV Pushers with Agendas causing trouble and article vandalism or taking advantage of the slogan "Anyone can edit"

Also the slogan "Anyone can edit" is misleading and confusing for newcomers on Wikipedia and that concerns me very much as I'm very against vandalism and misinformation on Wikipedia. And I'm worried about the Wikipedia security being vulnerable.

So, I have a proposal for the entire Wikipedia staff and users, to retire and replace the outdated slogan. Can we replace the 2000s slogan "The Free Encyclopedia anyone can edit" to a brand new slogan for the 2020s Wikipedia website? Here's my proposal slogan ideas. "The Free Encyclopedia respect in edit", "The Free Encyclopedia respect for Wikipedia", "The Free Encyclopedia members only", "The Free Encyclopedia respect for articles"

Also, in the future I think we the Wikipedia Staff and Veteran Users need to at some point stop allowing unsigned visitors to edit Wikipedia pages whenever they want because it's harder to protect the thousands of Wikipedia articles when we allow unsigned visitors to randomly edit pages, especially if they do prank articles or spam it with dangerous website link scams or attack the pages with profanity or slander or vandalism or fake information. If we make it a requirement to have Wikipedia members only. Then it would be easier to protect the Wikipedia articles and if the Wikipedia user is not following the rules and is out of control, we can block them.

Let me know what you think. I really want to see Wikipedia staff members including the CEO change their 2000s Wikipedia slogan "Anyone can edit". If the Wikipedia staff members and users have any good ideas for replacing and retiring the slogan "Anyone can edit" let me know because I'm ready to see a new slogan on Wikipedia that's up to date since "Anyone can edit" slogan is no longer considered acceptable for 2020s Wikipedia website. CrosswalkX (talk) 13:17, 10 December 2022 (UTC)

The slogan is time-tested and historically important, and should stay. Please realize that "Anyone can edit" doesn't mean that anyone's edit will stick, or that an editing vandal won't get reverted and banned. It just means that anyone can edit one of Wikipedia's pages, which is 100% true. There is a vast difference between "can" and "permanent". As for IP users, there seems to be a consensus that, on a whole, IP edits have more value to the encyclopedia than not, so the slogan "Anyone can edit" would remain true until that consensus changes. Question: What do you call an IP Wikipedia user? Answer: A Wikipedian. Randy Kryn (talk) 13:23, 10 December 2022 (UTC)

This right here. The phrase is still 100% true and appropriate, just that editors have to be aware that anyone else can undo their edit too, particularly if it is not constructive or vandalizing. Masem (t) 15:29, 10 December 2022 (UTC)

Yes, quite. "Anyone can edit" includes other people, as well as you (I mean "you" as the person who reads the slogan, not anyone in particular). Phil Bridger (talk) 21:00, 10 December 2022 (UTC)

@Randy Kryn the line "anyone can edit" could reasonably be viewed to be true even if the Community moved to no IP editing (though I remain with the retain majority unless and until IP masking substantially impairs things), so long as no new limits on account creation were imposed. Although the current scale of proxy blocks (peer2peer, new apple relay etc etc) is actually a more reasonable question to if the line remains accurate Nosebagbear (talk) 11:31, 12 December 2022 (UTC)

Hello Nosebagbear. True, but that requires that a person who, say, saw the obvious error that was in the lead of Niece and Nephew for 2 years and 8 months (see the talk page section at or near the bottom, quite the "how did that last so long?" long-term error), wants to fix it, but doesn't have time to leave the page, figure out how to make an account, make an account, come back to the page, and edit the error while learning how to sign in and having no intention of ever editing Wikipedia again. Just fixing the error the second they read it, without the rigamarole, makes the wording "Anyone can edit" a bit more real in practice. Randy Kryn (talk) 13:01, 12 December 2022 (UTC)

Oh I agree (if I didn't then given the benefits of individuals then having accounts, it would be an absolute no-brainer to scrap it) Nosebagbear (talk) 13:54, 12 December 2022 (UTC)

Is an IP or a normal account better for avodiing being data mined? I think don't change the anyone can edit, but do fix underlying issues

I just did a trial and maybe there are some tweaks we could do.

1. The editing a page warning is intext

You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to a username, among other benefits.

2. When you save a page, there is no prompt to create an account, or the option to say don't ask me again

3. On user page

"This edit has been prevented because you attempted to edit a user page other than the one associated with your account. Please note that unregistered and newly registered editors cannot modify other editors' user pages. If you would like to contact this editor, please do so at the editor's talk page. If this is your user page, you can log in to edit it. Note: If you are an experienced user seeing this message, you might have tried to add or remove from the page, which can only be done by the user themselves or an administrator."

Wakelamp d[@-@]b (talk) 10:31, 27 December 2022 (UTC)

About #2: Past research indicated that if you asked people to edit an account before publishing their changes, they abandoned their edits. I don't know if research was done for a prompt after editing, but there's the additional problem that (a) your IP would already be exposed and (b) the account creation would be permanently, temporally associated with the IP edit. The more active the wiki, the smaller the problem (if lots of IPs edit today, and lots people create accounts today, then there's a chance that someone else's edit or account creation will happen in between your two logged actions), but at small wikis, which might see only a dozen actions a day, it would be very obvious that the edit made at 10:01 by an IP was associated with the account created at 10:02. Whatamidoing (WMF) (talk) 21:31, 3 January 2023 (UTC)

"Past research indicated that if you asked people to edit an account before publishing their changes, they abandoned their edits." Do you remember if the account prompt was done post edit or pre-edit?

Use case with post edit and pre edit options

A/Alice (a brand new editor at IP address XYZ) selects edit for page ABCD

B/ Intext warning appears "You are not logged in. Your IP address ..."

Alternate Pre Edit/ Change the intext warning a prompt (switchable off in preferences) saying how many edits have done this at IP

C/ Alice completes their edits

D/ They select publish button

D 'Alternate Post Edit/ Choice of create account or publish.'

E/ ABCD is updated, ABCD history is updated, with editor details

E1/ If Alice chooses to create an account, then limbo for 5 minutes Wikipedia:Reviewing_pending_changes , and then it is it is published as an IP. But then the issue is contention

E2 'as above but, Contention'

Placeholder / Save to a placeholder account then update to real account in 5 minutes

Alternate Alice : Existing contention process occours after they save account, if they give up default is done

Alternate Bob Warning : "Hi Bob, Alice is creating an account to publish their edits - please wait 5"

Alternate Bob has to fix : Same as Bob Warning, but Alice has priority, existing editor Bob is reverted if there is contention

F/ Alice can not claim these IP edits later. Wakelamp d[@-@]b (talk) 11:00, 4 January 2023 (UTC)

This was a pre-edit prompt. As I said, I don't know whether any research was done on post-edit prompts.

A same-as-edit prompt (which you propose) could add the account registration form into the same page (for the 2003 and 2010 wikitext editors). You could see:

• "You are not logged in. Your IP address ..."
• The editing window
• The edit summary
• A small form for registering an account (new)
• The license statement
• The big blue Publish changes button

Whatamidoing (WMF) (talk) 01:23, 5 January 2023 (UTC)

This article [1] from august seems to say that "Anyone can edit" is alive and constructively kicking. Gråbergs Gråa Sång (talk) 15:18, 10 December 2022 (UTC)

The proposed alternatives appear to be written in very poor English. While we do have great respect for edits and articles, when referring to "respect", a noun, it is necessary to use a modifier like "with". BD2412 T 16:44, 10 December 2022 (UTC)

"In the past, I have made no secret of my disdain for Wikipedia's famous motto, 'Anyone can edit.' But I realize, only now do I truly understand what it meant. Not everyone can become a great editor; but a great editor can come from anywhere." – Ratatouille (film), I think. Thebiguglyalien (talk) 18:38, 10 December 2022 (UTC)

I like your slogan better. Hawkeye7 (discuss) 20:09, 10 December 2022 (UTC)

I've always described Wikipedia to my friends as "the encyclopedia anyone can try to edit". _signed, Rosguill ^talk 20:42, 10 December 2022 (UTC)

The proposed alternatives aren't better and "respect" makes absolutely no sense in this context.... But a good point is raised on its redundancy. Why do we even still need "the free encyclopedia anybody can edit"? It's not the early 2000s anymore, everybody knows what Wikipedia is and that they can edit and that's free. In some ways it cheapens the site and asserts that we're amateurish and unreliable. I would be in favour of removing the slogan entirely and simply "Wikipedia encyclopedia". When fundraisers come around, people know that they have to contribute to help keep it free.♦ Dr. Blofeld 21:26, 10 December 2022 (UTC)

Well, since the word Wikipedia is a blend of wiki and encyclopedia, isn't encyclopedia redundant too? Gråbergs Gråa Sång (talk) 23:52, 10 December 2022 (UTC)

Thebiguglyalien, is that really a quote from the film? Thanks. Randy Kryn (talk) 04:25, 11 December 2022 (UTC)

The movie is about a chef that believes "anyone can cook". I replaced the chef's name with Wikipedia and the word cook with edit. Thebiguglyalien (talk) 04:31, 11 December 2022 (UTC)

How about “anyone can edit, that doesn’t mean anyone SHOULD” -Remy Dronebogus (talk) 15:30, 1 January 2023 (UTC)

A dewiki contributor once wrote: "can" in "The encyclopedia that anyone can edit" is ambiguous: Everyone may, but not everyone is able to. Anyway, I don't see any reason to change the logo, and I think your other suggestions are quite faulty as well. The Citizendium model has already been tried, and we all know how that worked out. You're always welcome to fork if you think you've found a better way. 74.73.224.126 (talk) 04:09, 11 December 2022 (UTC)

As with any brief statement / slogan, it isn't perfect / all-explaining. But such is the norm for such, including very useful ones such as this one. IMO leave it as is. North8000 (talk) 00:39, 11 December 2022 (UTC)

Short and sweet, and conveying the correct sentiment, it still works for me. I can think of nothing better. Paul August ☎ 00:53, 11 December 2022 (UTC)

• Dr. Blofeld makes three important points. That said, either deliberately or unintentionally "anyone can edit" has always been misinterpreted (like several founding principles) and used by ideologues as a barrier against change. There is no doubt whatsoever that Wikipedia is indeed the encyclopedia anyone can edit - in the true sense that no qualifications of any kind, whether professional, academic, intellectual, or social, are required. There are nevertheless a few ifs and buts and WP:ACPERM is a prime example how early ideology can and must be open to change. According to one Wikipedia, the introduction of registration has had a significant positive impact; anyone can still edit but like most other editable websites or ones on which comment is allowed, registration is the norm. Look at it like 'the car anyone can drive, but to be used on a public road it needs a licence plate'. Kudpung กุดผึ้ง (talk) 02:36, 11 December 2022 (UTC)

• As with most brief slogans, there are implied parentheticals: "Wikipedia is the encyclopedia that anyone can edit (as long as they follow Wikipedia's policies and guidelines)" and "Wikipedia is the encyclopedia that anyone can edit (as long as they do not behave like a complete jackass)". Cullen328 (talk) 02:53, 11 December 2022 (UTC)

Yes, it assumes good faith. I agree with that. I don't think that "anyone" was ever intended to include vandals and the like. Zero^talk 12:01, 12 December 2022 (UTC)

Just playing devil's advocate, if we were to make a change, we could shift to something along the lines of "Wikipedia: written by millions, read by billions". BD2412 T 14:41, 12 December 2022 (UTC)

Weaker stance since that suggests not all readers can become editors, which is what we do want to encourage. Masem (t) 14:44, 12 December 2022 (UTC)

(ec) I like that, but I doubt it is true. Yes we have had millions of accounts created and millions of IPs used for editing. But if we could count the number of people who'd made all those edits, would we really have millions of different actual people? Maybe we would, but once you take out all the people who haven't written the current version of Wikipedia because their only edits have been reverted as vandalism, unnotable, spam or unsourced, then no, I'm pretty sure the number of people who've written at least some part of the current pedia is less than a million. ϢereSpielChequers 14:52, 12 December 2022 (UTC)

More than 10 million registered accounts have made at least one edit here at the English Wikipedia, plus IP editors. I think the slogan suggestion from @BD2412 is factually accurate as well as being a good slogan.

If we were specifically concerned about "anyone", I'd like to see something along the lines of "The encyclopedia written by the general public". I want the slogan to indicate that Wikipedia is not written by trusted experts. WhatamIdoing (talk) 16:53, 12 December 2022 (UTC)

@WereSpielChequers: I have zero doubt that the number of people who have made at least one productive edit to Wikipedia is over a million. I wonder if there is some way to confirm this, though. BD2412 T 16:55, 12 December 2022 (UTC)

That’s a… well, bluntly, terrible slogan that only works for enwiki, is barely even true (there’s millions of users but active, constructive editors is in like the hundreds of thousands and that’s generous) and puts popularity over content. Dronebogus (talk) 15:37, 1 January 2023 (UTC)

• Credit to User:Lowellian who first used this phrase in 2004! Archived in Wikiquote and still provocative! Bluerasberry (talk) 15:23, 12 December 2022 (UTC)

That's interesting Bluerasberry here's the full text:

Welcome to Wikipedia, a free-content encyclopedia in many languages that anyone can edit. In this English edition, started in January 2001, we are working on 6,913,975 articles. Visit our Community Portal to find out how you can edit an article, or experiment in the sandbox.

From which I take that to mean the emphasis was on articles and not necessarily the labyrinth of around 5,000 policies, guidelines, and other help pages and essays, many of which are not only redundant but also contradictory. There's almost enough in there for a degree course in Wikipedia governance. Kudpung กุดผึ้ง (talk) 15:39, 12 December 2022 (UTC)

I think it is fine (that is the nature of a wiki). It is also informational for readers, like caveat emptor. Alanscottwalker (talk) 16:25, 12 December 2022 (UTC)

The slogan is fine. Anyone can edit Wikipedia provided that they are not setting out to cause trouble.--♦IanMacM♦ ^{(talk to me)} 17:59, 12 December 2022 (UTC)

I'll join with those who are uncomfortable with the current slogan, because it's well known not anyone can edit Wikipedia. While once the solid truth, by now it is more of a marketing slogan than the truth. But as others have pointed out, it's a better slogan than others proposed. (My best suggestion would be, "The encyclopedia everyone is invited to edit". This indicates that while we invite contributors, some would-be contributors -- due to attitude, competence, or vested interests -- may not be allowed to stay.) I doubt we will come up with a better slogan to satisfy enough of us (aka a consensus), but I hope we acknowledge there is an issue & consider how to update it & what the new wording should be. -- llywrch (talk) 23:06, 20 December 2022 (UTC)

I have reservations about the slogan. I support registration as it would stop one thing that hit me as a presumed "trusted" editor. Mass range IP blocks. I was not only a victim of one I was also globally blocked. I never did get resolution (possible cell phone edit) as to why it happened so imagine a new editor?However, if we are going to continue to support IP edits then mass IP blocks should be severely limited and not permanent.

When a slogan becomes "time-tested and historically important", even if there are flaws, it cannot just be retired. It has to be replaced with something the vast majority of the community considers appropriate. Until that accepted version materialized it should remain as is. -- Otr500 (talk) 10:21, 29 December 2022 (UTC)

The idea that the statement that "anyone can edit" is "well-known" is palpably untrue. Surely all of us have encountered people who have no idea of who edits articles, and are bemused and amazed when it is explained to them that, literally, anyone can edit it. The slogan needs to stay. Not everyone can edit well, or have their edits retained, but that is another matter entirely. Ghmyrtle (talk) 13:14, 29 December 2022 (UTC)

• No. Don’t change the slogan. One, and most obviously, this is a huge waste of time that can’t just be done on a whim; two, the current slogan is extremely iconic— changing it would be a marketing fiasco akin to New Coke (“Newikipedia?”); three, it’s not wrong, with the caveat that Wikipedia:Competence is required and the more obvious exception of blocked users. Dronebogus (talk) 15:34, 1 January 2023 (UTC)
• No. Don’t change the slogan per Dronebogus. Anyone can edit ... if they have a computer and an internet connection, and if they are literate and have a clue. The slogan does not say that anyone's edit will be retained. Johnuniq (talk) 02:35, 2 January 2023 (UTC)

Vector 2022 deployment update

Cross-posting for a better visibility: in the technical section, the Web team has posted an update on the deployment of Vector 2022. We will also be having three open meetings for anyone wanting to ask questions. Thanks! SGrabarczuk (WMF) (talk) 19:20, 10 January 2023 (UTC)

New bot to change wikilinks following a requested move

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I started a BRFA yesterday for PuggleBot, where @Anomie thought this would require wider discussion, and suggested I brought it here and see if people think this could be a good idea. So, what this bot would do:

Following a successful requested move, this bot would change the wikilinks to the moved page if necessary. For example, if Foo was moved to Foo (bar), and Foo (disambiguation) was moved to Foo, the bot would change all links to Foo to [[Foo (bar)|Foo]], so the link continues to go to the right place. Originally, I was planning to run it on all successful moves, including ones where the changes would be near-cosmetic. However, I believe I have figured out how to skip them, but it's something I would have to test.

So, what do you think? It would be run once a day at first, and hopefully after a bit I could transition it to automatic operation, but this isn't something I'm thinking about at the moment. If anyone has questions about it, please ping me and let me know! Thanks, echidnaLives - talk - edits 23:30, 3 January 2023 (UTC)

@echidnaLives: I primarily update linked articles when there are RM discussions involving dab pages created or moved. My experience thus far is that there would be portions of these linked articles being linked wrongly and would require an editor to correct the links. Just one example of the many I had closed (recalling offhandedly, primarily because of the number of links that had to be worked on): When I closed the discussion for Australian, there were 400+3,000-4,000 articles requiring editors to sort into the various possible articles, Australia, Australians, etc.

If implemented, I suggest that the bot skips changing wikilinks for requested moves discussions which result in a dab page occupying one of the original titles under discussion, so that editors can resolve the links manually postmove. – robertsky (talk) 00:09, 4 January 2023 (UTC)

@Robertsky I completely understand this. If it was implemented, I don't think I would skip them completely though, as the bot would be supervised and I would be ready to fix any issues that come up almost immediately, but I would rethink it if it ever does become automatic. But in more complicated situations, including ones like Australian, it would definitely not be done by the bot. As you said, these situations are too advanced and need attention from editors themselves. Thank you for your feedback, echidnaLives - talk - edits 00:19, 4 January 2023 (UTC).

@echidnaLives: I actually don't see the need to update the wikilinks beyond these dab page related moves except for what @The Banner said on changing links in the Template space. Or when another article occupies the original title. Are there any other considerations for implementing this bot task? – robertsky (talk) 03:58, 4 January 2023 (UTC)

@Robertsky I believe it would be useful in most dab related moves, just not the ones where it may be a different intended page based on the context, like Australian. For example, this move. The old title is now held by a disambiguation page. However, since that title has been established for a long time, all links to it are intended for the now-moved page, and aren't meant to link anywhere else. Does that make sense? Thanks, echidnaLives - talk - edits 04:17, 4 January 2023 (UTC)

My issue with automating the editing from Eddie Lewis (English footballer) to Eddie Lewis (footballer, born 1935) in the linked articles is that there may have been editors incorrectly linking to Eddie Lewis (English footballer) in the first place when the 1935 footballer article was there, for one reason or another, when they meant to link to Eddie Lewis (footballer, born 1926). I had encountered similar issues when closing similar requests (evidently, the page move was clearly needed in those cases). I can't find the exact RM discussion that I had closed now, but there was one which had 10-ish links to "Article A (B)" which was moved to "Article A (B, C)", and half of them were actually to a different topic "Article A (B, D)". – robertsky (talk) 04:45, 4 January 2023 (UTC)

You raise an important point, and it's something I certainly should of considered more. However, I still think this bot could work well, it probably need more supervision than I first thought it would (which is fine). Maybe in AWB (assuming it has bot access) I could set the edit-delay to 3~ seconds (or longer), allowing me to look over it and decide whether it's good or not, and allowing me to look further and skip if necessary, echidnaLives - talk - edits 04:57, 4 January 2023 (UTC)

I note my main concern was that the original proposal said the bot was intended to run automatically for every closed RM with little human input. If an experienced human is instead choosing only those targets that are safe and non-cosmetic to bot-update (and what displayed text to update them to when not already piped), I have much less concern about it. OTOH, it seems people already do that much in a semi-automated manner with AWB, which raises the question of whether a dedicated bot is needed. Anomie⚔ 03:19, 4 January 2023 (UTC)

@Anomie I believe a dedicated bot would be helpful, and while this could be done with AWB, having the dedicated bot would allow me to check the list of RMs, quickly sort out the unnecessary RMs and let it run, allowing me to do other things and not have to keep clicking "save", "save", "save" a lot. The bot would also be helpful for people without access to AWB, and people who might forget about it or just not do it.

Sorry for the confusion about the cosmetic edits, I originally believed they couldn't be filtered out, but I believe I have somewhat figured out how to do it. However, I will have to test it out first to confirm this. Thanks, echidnaLives - talk - edits 03:37, 4 January 2023 (UTC).

Quick note: articles wouldn't have to be removed manually often. As I mentioned, I am pretty confident I'll be able to automatically filter out all of the cosmetic pages. The only ones which would need filtering out are very complicated situations like the Australian one mentioned by robertsky before, where a different link may be necessary depending on the context. echidnaLives - talk - edits 04:24, 4 January 2023 (UTC)

Having worked on this task for years, wherever a page is moved because the title is actually ambiguous, there are usually a handful of errors uncovered through the disambiguation process. I'm not saying that it would be impossible for a bot to be set up to fix incoming links correctly, but it would basically need to be an AI. BD2412 T 04:42, 4 January 2023 (UTC)

@BD2412 Does my reply above address this issue? If not, could you explain the errors a bit further? As I said above, I believe this task can work well, but it probably needs more supervision than I expected. Thanks, echidnaLives - talk - edits 04:59, 4 January 2023 (UTC)

I have a bot approved for AWB access for fixing disambiguation links. I use it for this purpose in a very reserved manner, and only after finding very specific patterns in the course of manual disambiguation of rather large sets. BD2412 T 05:28, 4 January 2023 (UTC)

@BD2412 This bot would essentially do the same thing, with supervision, daily on closed requested moves. At it's core, it would just do the normal thing you could do in an AWB task (or your bot), but configured so it runs on the necessary pages, with basic settings that would allow it to work most of the time, and for the times it doesn't, I'll be ready to step in straight away if the link doesn't need replacing/bot is having a different error.

So basically, it wouldn't be adjusted to skip the situation that @Robertsky brought up before.(Robersky's comment from above: My issue with automating the editing from Eddie Lewis (English footballer) to Eddie Lewis (footballer, born 1935) in the linked articles is that there may have been editors incorrectly linking to Eddie Lewis (English footballer) in the first place when the 1935 footballer article was there, for one reason or another, when they meant to link to Eddie Lewis (footballer, born 1926).). But, my close supervision will allow me to easily skip these links, and only edit the ones required. Thanks, echidnaLives - talk - edits 06:09, 4 January 2023 (UTC).

Some thoughts would be interesting to hear how you see these scenarios working.

• Say we have an article called Wikipedia that was mostly about the Wikimedia Foundation with a small Section on Wikipedia. So, we move Wikipedia-> Wikipedia Foundation. In this case, we would want the redirect to be to [[Wikimedia Foundation#Wikipedia]], how would it handle that?
• Sometimes is preferable to leave the redirects, because the original title is a plausible future article, but we're moving it to a 'parent' topic. In a few years someone replaces the Wikipedia redirect with an actual article; and we have to manually go through and find all the [[wikimedia foundation|wikipedia]] links and change them back again. If they were left as a redirect, we wouldn't have this problem. JeffUK 15:06, 4 January 2023 (UTC)

Hello @JeffUK, thanks for your questions. These scenarios would not be handled by the bot as [[Wikipedia]] is still redirecting to the intended location. However, if it was decided that Wikipedia (the encyclopedia) is not the primary topic, and is moved to Wikipedia (encyclopedia) with Wikipedia (disambiguation) moved to Wikipedia, that’s when the bot would change links. This is because links to [[Wikipedia]] are supposed to be for Wikipedia (encyclopedia), but are now linking to the disambiguation page. There are more simple examples above. Thanks, echidnaLives sock - talk - edits 15:35, 4 January 2023 (UTC)

I have my reservations on this. First let's take the following example before proceeding. The pages are moved in the following order:

• [[Foo]] → [[Foo (something)]]
• [[Foo (disambiguation)]] → [[Foo]]

1. The proposed bot will change all incoming links of [[Foo]] to [[Foo (something)]], not controlling for the fact that [[Foo]] has incoming links that should've ideally been to [[Foo (other thing)]] & [[Foo (third thing)]], but were linked "mistakenly" to the base page. Blind changes would direct people to wrong destinations.
2. A pagemover might manually modify the links, unaware of the bot's existence. They modified [[Foo (disambiguation)]] into [[Foo]]. How will the bot ensure that this manually modified [[Foo]] is not converted into [[Foo (something)]]?

—CX Zoom[he/him] ^{(let's talk • {C•X})} 08:38, 5 January 2023 (UTC)

Thanks @CX Zoom for asking this, I completely understand the fact that you have reservations about this.

This example brings up valid points, the first of which discussed above. As I will be supervising the bot when it goes through it's process, meaning if I come across this situation, I can easily stop it from making the change. In all situations, when I or the bot is unsure about a link, it would be skipped, as it's worth having a DAB link instead of the wrong link.

For the second point, this is something I have thought about. Typically, I don't think this would be an issue. I've never encountered any closer doing this, as there would be no reason for them to do that. However, if the context seems weird (for example, if I saw a hatnote that says This article is about (page). For other uses, see [[Foo]], obviously it wouldn't be a good idea to change it. Although, if this has happened in the main content part of an article, then it would be the same as your first question. I would be supervising and ready to stop it.

If you have any more questions, please ask! Thanks, echidnaLives - talk - edits 08:57, 5 January 2023 (UTC).

Thanks for your reply @EchidnaLives. If you just want to fix the links with manual oversight, then I have no issues with it. It would basically be WP:DISAMASSIST but faster and more efficient. Is that right? —CX Zoom[he/him] ^{(let's talk • {C•X})} 09:10, 5 January 2023 (UTC)

@CX Zoom Yes, that's pretty much it. The main reasons I want to use a bot account are listed in my response to Kusma below, and AWB allows me to create a system to automatically list the RMs that may need attention (although, the list would still be checked to avoid doing the wrong pages, as discussed above.) Thanks, echidnaLives - talk - edits 09:33, 5 January 2023 (UTC)

This is a bad idea for a bot, as it is likely to cause accidental wrong links. A hundred links to disambiguation pages (easy to find and not hard to fix) is preferable to a single wrong link (nearly impossible to find). —Kusma (talk) 08:55, 5 January 2023 (UTC)

Hello @Kusma. I agree, having a bot do this automatically would be a very bad idea, but please see my responses above. The bot would not be doing this un-supervised, as that would result in a lot of accidental links like you said, and I would stop this edits straight away. The first half of my response to CX Zoom and my response to BD2412 both explain this more in-depth. If you have any other questions, please let me know! Thanks, echidnaLives - talk - edits 09:02, 5 January 2023 (UTC)

If you're checking every edit manually (which sometimes requires pausing and thinking), you don't need a bot for this. If you're not checking every edit manually, you shouldn't do this at all. Disambiguation fixing is not a task for bots and requires care and attention (quite often, 95%+ of the links need to go to one page, but that is not nearly enough to just send all to that page). —Kusma (talk) 09:19, 5 January 2023 (UTC)

@Kusma I would be checking all the edits, but I would like to use a bot account for it. With bot access in AWB, it makes it a lot easier to go through it semi-automatically (with manual supervision), and as it would be making a lot of edits (maybe 15 or so a minute while running), a bot flag would be useful, as I wouldn't want to spam recent changes. But you are right. A bot account is not completely necessary to do this, just makes it a lot easier to work with. Hope that clears it up a bit. Thanks, echidnaLives - talk - edits 09:30, 5 January 2023 (UTC).

If you want to do 15 edits per minute on a task like this then I must oppose strongly (there is no way you can be careful enough at that rate). Something that could potentially have errors should also not be hidden behind a bot flag. —Kusma (talk) 09:38, 5 January 2023 (UTC)

@Kusma 15 edits was probably a bit optimistic. At the end of the day, there isn't a set rate for this. I would need to test out the configuration, and see what speed I can do it at where I can be confident that mistakes aren't happening. You are 100% right about me needing to be extremely careful with this task, and that would be priority number 1. I also understand what you mean about hiding the edits behind a bot flag, but I don't really see any way around this. All bots can make mistakes, especially this one, but when every edit is being checked by a human who knows that their doing, I think this can balance it out. As I have mentioned before, any edit where there's any possibility of a mistake being made, is skipped, and I think that's an important part of having any chance for getting this approved. With that said, if this does end up going to a trial and it appears like hiding the edits behind a bot flag is a risk, then (I assume this can be done) the bot would be run without a flag, but just be added to the AWB bot list.

Your questions and criticisms are really helpful, so if you have any more, please let me know. Thank you, echidnaLives - talk - edits 09:54, 5 January 2023 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Number of women in ministry - Infobox government cabinet

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Suggestion to update the current Infobox government cabinet template to include a field to enter the number of women in the ministry (n) and the % of the ministry that are women to provide people an idea of the diversity of a government's ministry at a glance. Auseditor4you (talk) 03:59, 5 January 2023 (UTC)

That would seem to be advocating for a particular agenda, rather than to be simply informative. I would oppose this. Zaathras (talk) 04:29, 5 January 2023 (UTC)

Representation is not an agenda. Auseditor4you (talk) 05:47, 5 January 2023 (UTC)

As a suitable alternative: number of men, number of women, number of people who identify as non-binary Auseditor4you (talk) 05:48, 5 January 2023 (UTC)

This is a piece of information that people now seek - https://www.npr.org/2022/05/31/1102105392/australias-new-prime-minister-albanese-appoints-record-10-women-to-his-cabinet Auseditor4you (talk) 05:51, 5 January 2023 (UTC)

Such information can be added to the body of the article about that specific cabinet, but certainly not added to all cabinets around the world. ✠ SunDawn ✠ (contact) 05:59, 5 January 2023 (UTC)

Not an appropriate use of an infobox. We base article content on what reliable sources say on the question (which will clearly vary from subject to subject), and not on our own research into 'diversity'. If it matters in say an Australian context, it can be discussed in the article body - citing the sources necessary to provide proper context. AndyTheGrump (talk) 05:55, 5 January 2023 (UTC)

• Oppose. Wikipedia is here to provide information, not to WP:RIGHTGREATWRONGS, and also not a place for WP:ADVOCACY. "Diversity" information is not critical information about government cabinets, and inclusion is unnecessary. Suppose a specific cabinet gets mainstream coverage about its diversity (or lack of diversity). In that case, it could be included in that cabinet's article, but not on the infobox that will affect all government cabinets worldwide. "Diversity" also begs more questions, why it must be about women? What about religious vs. non-religious? What about majority religion vs. minority religion? What about race? Etc. We didn't have a field for "religious composition" or "race composition" in the government cabinet infobox, I don't think we should have one for gender diversity. ✠ SunDawn ✠ (contact) 05:57, 5 January 2023 (UTC)

  I agree, on a case by case basis it might be due weight to include some sort of statistic on some intersection of members, but it varies by country as to which if any is most relevant. e.g., the Sunni/Shia split in Iraq is particularly pertinent, in New Zealand the Māori representation is specifically legislated etc. etc. We already have List_of_legislatures_by_female_members and Women_in_government which I think would be more useful for readers who are looking to compare and contrast governments globally on this one specific metric. JeffUK 11:10, 5 January 2023 (UTC)

• Oppose - while it may be appropiate to include suitable analysis in the body of an article on things like diversity if it is WP:DUE and suitably sourced from reliable sources, the infobox isn't the place to present this sort of detail.Nigel Ish (talk) 23:55, 5 January 2023 (UTC)
• Oppose - As others have mentioned, we can not focus on women as an indicator of diversity at the expense of other indicators of diversity. And if we go down this rabbit hole, and list some indicators but not others, which do we exclude? LBGTQ+ percentages? racial/ethnic breakdown? religious breakdown? Ableness? Etc. etc. We would have to stop at some point or the infobox becomes too unwieldy. And no matter where we stop, there will always be some other group that will be upset if their particular brand of diversity is not represented (how DARE we omit the percentage of Gingers in government!)

So, no… better to not attempt to indicate diversity via the infobox at all. Blueboar (talk) 00:46, 6 January 2023 (UTC)

• Oppose and SNOW close GREATWRONGS, if you want to promote women’s rights on Wikipedia write and improve articles about them, don’t reduce them to a percentage slapped onto unrelated articles. Dronebogus (talk) 14:35, 6 January 2023 (UTC)
• Oppose not because the information is inappropriate in all cases, but because the infobox is a poor tool for discussing it. If gender equality is something that needs to discuss, then the prose of the article is the best place for it, NOT the infobox. --Jayron32 14:43, 6 January 2023 (UTC)
• Oppose. In most cases, there is no reason to mention it. If there is any need, discuss it in the article. And raw percentage is also a bit misleading - for a too-highly male government to add some women in minor positions - they can boost the percentage, but relatively meaningless; the body of the article can also discuss this. Animal lover |666| 15:53, 10 January 2023 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Correcting Page edit

Hello every body,

Someone has edited the page "USM F.C.", that is in the start about a Malaysian club, linked about Universiti Sains Malaysia, inserting informations about Ulsan Citizen FC I presume, who already is existing. Can someone see if my propositions is correct, and in all case, the best is to restore the information about the Malaysian club and to fork the infos about the Korean club to somewhere else, whether on Ulsan FC, if it's that, or on an other page.

Thanks. Anas1712 (talk) 20:02, 8 January 2023 (UTC)

I don't know if this belongs here, but I believe you are correct in your suggested line of action. At first glance the article about the Malaysian club seems to have been hijacked, but it seems that most of the added information is from the pre-existing Ulsan article, so this may just be a case of highly misguided editing. I would revert the non-relevant info and would try to engage the other editor(s) in the talk page as a first step. 65.88.88.62 (talk) 16:29, 9 January 2023 (UTC)

Believe I've fixed this. An IP editor added the squad of current South Korean club Ulsan Citizen FC to the article about the defunct Malaysian club USM F.C.. Have reverted back to the last clean version of the USM F.C. article, if the IP returns then will explain it to them (though they haven't edited under that IP since September). Joseph2302 (talk) 11:57, 13 January 2023 (UTC)

RFC: Enforceability of the Universal Code of Conduct

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

The Wikimedia Foundation has announced that January 17 begins voting on a second attempt to obtain approval of Enforcement Guidelines for the Universal Code of Conduct. There has been no such voting on the content of the Universal Code of Conduct itself.

The primary intended outcomes of this RFC are:

• for the community to consider this prior to casting a vote on the Enforcement Guidelines;
• informing the Foundation of any portion of the community who will not approve Enforcement Guidelines unless a Code of Conduct is approved first;
• the Foundation perhaps reconsidering whether to obtain community approval for Code of Conduct itself.

Is the Universal Code of Conduct enforceable even if the Code itself has not been formally approved by the community? Alsee (talk) 04:46, 13 January 2023 (UTC)

Responses: Enforceability

• Oppose. I will never approve Enforcement without approval of a code itself. The current Code of Conduct is botched, and without consensus the Code has no legitimacy. Consensus is especially NECESSARY as the Code is almost entirely worthless and ineffectual without active community support for it. Repeated attempts by the WMF to "improve" and re-vote the Enforcement Guidelines can never fix those fatal flaws. The WMF needs to stop trying to steamroll forwards, it is necessary to back up and let the community develop a new Code which actually gets consensus approval. Alsee (talk) 09:30, 13 January 2023 (UTC)
• This RfC seems founded on a rather narrow understanding of "approval". The UCoC was approved by the WMF Board of Trustees, the legal custodians of this project, who we play a part in selecting. Not all decisions are subject to consensus of editors and local policy specifically recognises acts of the WMF Board as one of those exceptions. The UCoC isn't the first policy to come via this route and we can enforce it with or without guidelines, just like we enforce the Terms of Use, for example. – Joe (talk) 10:12, 13 January 2023 (UTC)

  @Joe Roe even if we take accept everything you said as a given, the WMF is actively seeking community approval here. I, and anyone else, are invited to vote against the Enforcement Guidelines if we wish. We are also invited to explain why we voted that way, and to explain what it would take to get us to change our vote. If it becomes clear that continued revisions of the Enforcement Guidelines are not going to change the vote outcome, they are going to have to reconsider the path forwards. Given that they are actively seeking community approval, and given that any Code of Conduct would be almost entirely worthless and ineffectual without active community support, I believe they would be far more inclined to work with the community rather than attempting to fight the community on this. Alsee (talk) 18:09, 13 January 2023 (UTC)

• Oppose. The UCoC is well intentioned and contains many sensible rules. However, a similar and more tailored set of rules is already approved and enforced by the English Wikipedia community. The UCoC provides a model which smaller communities may choose to adopt, perhaps even by default, but neither the code nor the new police force that comes with it would be helpful to enwp. Certes (talk) 11:53, 13 January 2023 (UTC)
• Support. This RFC doesn't really seem in order, however, I agree with Joe Roe. The Code of Conduct should certainly be workshopped with editors but, in the end, the Wikipedia website and the Foundation and its legal agents or assignees can reasonably assume a baseline level of a Code of Conduct that protects their legal, as well as ethical and financial, obligations to their beneficiaries or fiduciaries or what have you. Any attempt to prevent such a thing from existing or being enforced seems to be to me not really possible let alone worth attempting to bring about. Andre🚐 19:46, 13 January 2023 (UTC)
• I think it was a mistake of the foundation's board to not get community ratification of the code itself. It was a mistake to not do it at the end of its drafting (before the Enforcement Guidelines started being drafted) and it was another mistake to not do it as part of the Enforcement Guidelines vote. However, it was not a policy violation either of the global policies or of enwiki's policies as Joe Roe points out. So we're in a situation of it was worse than a policy violation, it was a mistake territory. This means enwiki doesn't get to decide, without being asked, that the UCoC isn't policy even though we definitely should have been. Best, Barkeep49 (talk) 20:38, 13 January 2023 (UTC)

  There is a fundamental disagreement here between the community and the WMF. I suspect it will go onto the back burner until the WMF decides to take action of which we disapprove, á la Framgate. At that point, some editors will meekly roll over, whilst the rest of us will tell the WMF to stick UCoC up their corporate arse and retire noisily. Certes (talk) 22:06, 13 January 2023 (UTC)

• I appreciate that some editors won't want to enforce a code of conduct that the English Wikipedia community has not approved, and that some editors may choose to leave the community. Regarding the specific question in its current form, though ("Is the Universal Code of Conduct enforceable even if the Code itself has not been formally approved by the community?"), the answer is yes. No one can force editors to take actions on English Wikipedia to enforce anything, of course, but global policies can be set by the global community (for example, see meta:Linking to external advertising accounts) or through the authority of the Wikimedia Foundation (such as the wmf:Terms of Use). isaacl (talk) 22:34, 13 January 2023 (UTC)

  Indeed: enforcement would have to be through the WMF interfering by making edits (or other actions such as office blocks) on enwp. I don't see anyone here volunteering to do that work for them. Certes (talk) 23:09, 13 January 2023 (UTC)

• Oppose. I agree with everything User:Barkeep49 says above, except the conclusion. If it was a mistake and you don't want the mistake repeated you have to speak up. Frederick Douglass expressed it like this: If there is no struggle there is no progress … Power concedes nothing without a demand. It never did and it never will. Find out just what any people will quietly submit to and you have found out the exact measure of injustice and wrong which will be imposed upon them. Following his crystal-clear logic, there is no choice but to oppose. There is another reason to oppose as well: subject the UCoC to community vetting, and it will become a more robust, less ambiguous document. It will become better. Andreas JN466 00:34, 14 January 2023 (UTC)
• Comment Keep in mind the possibility of Wikipedia firing WMF and replacing them with somebody who isn't going awry. We're the ship that their ivory tower rides on. The mere concept might provide some perspective. A revision of the serious flaws in the bylaws which allowed the ivory tower problem to happen would prevent a repetition. North8000 (talk) 04:56, 14 January 2023 (UTC)

Discussion: Enforceability

Shouldn't the arguments about the validity of ratification be in the responses section rather than the RfC prompt itself, in line with WP:RFCNEUTRAL? — Red-tailed hawk _(nest) 04:58, 13 January 2023 (UTC)

Red-tailed hawk First, I hope you don't mind that I slid this into the new section as I created a Discussion section. Getting this RFC right was a bit messier than I anticipated.

Are you referring to "validity of ratification" regarding the Code or the Enforcement Guidelines? And were you concerned with the mention that concerns exist with the Code (without getting into any such concerns), or the part where I try to clarify what sort of outcomes I thought this might have? Alsee (talk) 05:20, 13 January 2023 (UTC)

If this is something like an up-or-down !vote on Does the community endorse the UCOC, as written, and authorize enforcement of the UCOC by local administrators in a manner that treats the UCOC as English Wikipedia policy?, then that question should be the prompt. The whole explanation regarding "there are concerns about the code" should probably be in one's rationale for supporting/opposing the enforcement or endorsement of the UCOC, rather than in the prompt itself. — Red-tailed hawk _(nest) 05:34, 13 January 2023 (UTC)

Red-tailed hawk, this RFC is intended essentially as communication between community and WMF. Staff are working on assigned jobs, and I see the WMF having bad habit of deciding some stage is "complete" despite some fatal problem, then they pathologically proceed with subsequent stages attempting to finish the assigned job.

What I was hoping for for here was lots of people to taking note of imminent Enforcement vote, hoping they they consider the unapproved-Code issue significant, hoping lots of people decide to vote against the Enforcement Guidelines, and then my key goal was to go talk to to the WMF and (hopefully) show them strong results here, convincing them that AGAIN revising the Enforcement-Guidelines for a 3rd vote would be futile.

I didn't want to get into the Code itself here, and I didn't want to establish any sort of directive to admins. At this stage I didn't want a concrete clash between the community and WMF. At this time the WMF is seeking community approval to complete their assigned task. I want them to realize that the only path forwards towards community approval is to back up and re-open a stage that they consider "competed" and "closed". Alsee (talk) 06:20, 13 January 2023 (UTC)

Makes sense. — Red-tailed hawk _(nest) 06:24, 13 January 2023 (UTC)

@Red-tailed hawk do you still think the RFC needs revision? Considering that no one has replied yet, I'm open to any sort of suggest for improvement. Alsee (talk) 06:28, 13 January 2023 (UTC)

Something like Should the English Wikipedia community ratify the text of the UCOC itself prior to voting on enforcement guidelines? is more succinct, I think. Not sure EnWiki is entirely the right scope, but I think I understand the reason for the RfC you're launching. — Red-tailed hawk _(nest) 06:32, 13 January 2023 (UTC)

@Red-tailed hawk umm, that's succinct but also runs into various interpretation problems. Trying to fit the intent here into a nice clean standard "RFCNEUTRAL" format is a mess. I'm getting tempted to scrap the "proper" RFC format, disclaiming any intent for an RFC style closure, and just stating what I'm trying to accomplish - inviting people to sign up on a collective message to the WMF saying we will never vote in favor of Enforcement Guidelines without a consensus-approved Code first. Would I make a mess trying to take a non-standard approach? Or does that sound like a solution here? Alsee (talk) 06:50, 13 January 2023 (UTC)

I've tweaked the phrasing a bit, but I'll leave it mostly as-is. Alsee (talk) 09:25, 13 January 2023 (UTC)

RfCs usually pose a question that the participants discuss. The question can be open-ended for general discussion, though most of them make a specific proposal. As currently worded, particularly with numbered points 2 and 3, it sounds like you are trying to promote a specific viewpoint and find supporters for it. There's nothing wrong with that in general, but typically RfC introductions are worded to allow for different outcomes, rather than assuming a specific outcome. This might reduce the effectiveness of step 3 in your list. isaacl (talk) 17:02, 13 January 2023 (UTC)

Can someone link previous enwiki & meta discussions on the UCoC and its Enforcement Guidelines? Thanks Fun Is Optional (talk page) (please ping on reply) 12:13, 13 January 2023 (UTC)

There have been many. meta:Template:Universal Code of Conduct/Navbox is a good starting point. – Joe (talk) 16:41, 13 January 2023 (UTC)

As of late, the relationship between the WMF and "the community" has improved drastically (see Wikipedia:Fundraising/2022 banners and Wikipedia:Page Curation/2023 Moderator Tools project). We had the first vote on the enforcement guidelines because we made a politely-worded request. This prompted a detailed response from the BoT, including a commitment that [b]oth the UCoC and the enforcement guidelines (after ratified), will also be open for review and voter-endorsed amendments annually. When we voted last year on the enforcement guidelines, it passed. The board responded by convening a revisions committee to address the concerns of the minority of people who opposed the guidelines, and they changed the UCoC itself based off of similar concerns. They have already shown plenty of good faith. I think an open letter requesting the promised amendment process on the UCoC itself followed by a ratification vote on the entire document is the most productive way forward. One final note: one of the recommendations from the Enforcement Guidelines Revisions Committee was that the UCoC be added to the Terms of Use. A consultation with legal about this (and some other modifications) is scheduled to begin on February 21. HouseBlaster^talk 04:33, 14 January 2023 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Extend Wikipedia:Do your own homework to article talk pages

I have been patrolling article talk pages for quite some time. I have seen all sorts of things happen on them, but one of the biggest issues are WP:NOTAFORUM violations. The main problem that I will be focusing on in this post is people treating article talk pages like a help desk. The revision history of Talk:Essay is a good example of the problem I am pointing out. It seems like these kinds of inappropriate discussions also occur on talk pages about academic subjects, such as Talk:Mathematics, Talk:English language, and Talk:Social studies (let me know if there are other talk pages that I have missed). Currently, the information page in question only pertains to the reference and help desks. I would like it to be extended to article talk pages. That would allow edit notices to be placed on the talk pages to redirect people asking for homework help.

Although the related problem I am going to talk about in this paragraph is about people trying to communicate with article subjects, I think it relates to people trying to get other editors to do their homework for them. People have been posting homework questions to Talk:ChatGPT, Talk:OpenAI, and Talk:Chatbot because they think they are communicating with the AI that will answer their questions for them. The first two listed have not gotten them in a while since they are currently protected (since the pages have been protected for quite a while, do you think I should request unprotection?). If my proposal gets accepted, I can combine it with an edit notice saying that article talk pages are not for communicating with the subject. SunilNevlaFan✨ 19:27, 12 January 2023 (UTC)

It's not necessary to be overly-prescriptive in Wikipedia:Do your own homework. Feel free to kindly tell commenters that article talk pages aren't for answering questions about the article's subject or related matters. isaacl (talk) 21:52, 12 January 2023 (UTC)

I would be surprised if there's a lot of it. I doubt if talk page commenters would answer questions within the timeframe demanded for homework, and so completely as to satisfy tthe teacher. Surely there are better places for homework answering than WP? Wehwalt (talk) 23:19, 12 January 2023 (UTC)

Maybe a template or a semi-automated message that directs people to the reference desk would be beneficial. Thebiguglyalien (talk) 23:21, 12 January 2023 (UTC)

Many edits of this kind will likely blow past any and all notices, but it might help at least somewhat on particularly problematic pages. If possible I'd like to limit the notices to IPs and non-autoconfirmed, but I'm not sure whether edit notices support that selectivity. If not, edit filters might work for selective notices. Alsee (talk) 00:54, 13 January 2023 (UTC)

Given the problem of banner blindness, personally I don't feel there's enough of an issue, nor enough benefit gained in having an edit notice solely to discourage editors from using article talk pages for purposes other than improving the article. isaacl (talk) 05:04, 13 January 2023 (UTC)

I feel that it would be a benefit even if only a few off-topic editors were to heed the edit notice. It looks like there are some talk pages listed above with weekly problems and any reduction in problems would also mean a reduction in editors having to remove the problematic conversations. --Super Goku V (talk) 11:20, 14 January 2023 (UTC)

Banner blindness kicks in really, really quickly. Occasional questions that are ignored are not, in my view, a problem. Do you have any examples of talk pages that are difficult to use for article improvement as a result of many posts unrelated to improving the corresponding article? Plus I don't see any evidence that an edit notice is going to deter someone who isn't able to infer from context that no one is answering questions about the article's subject on the talk page. isaacl (talk) 04:46, 16 January 2023 (UTC)

The problem to me isn't that the questions are being ignored, but that these violations also have to be removed regularly to keep the talk pages clear. Right now, the words revert or reverted appear 63 times in the last 200 edits to Talk:Mathematics. Talk:English language is worse with it appearing 160 times in the last 200 edits. It is clear that there is a problem, not just occasional incidents. Personally, we should try to avoid protecting talk pages if we can find an alternative solution. --Super Goku V (talk) 09:40, 16 January 2023 (UTC)

I went through the last 500 edits for Talk:Mathematics and looked at all the edits that removed text (other than the archiving bot). I agree there's a significant test-edit issue on that page. Leaving aside three posts that appear to be in a foreign language that I didn't try to translate, I counted about five posts that might be problems to solve, but to be honest, given the numerous non-productive, non-sequitur edits, I assume they were just one of those and not good-faith attempts to ask a math question. Thus I don't think an edit notice will help. (I spot-checked a very small number of the reverts on Talk:English language; in that sample, they were all non-productive, non-sequitur edits.) isaacl (talk) 18:32, 16 January 2023 (UTC)

Alright then. Maybe the only thing that can be done is to protect the talk page like ChatGPT and OpenAI or to leave them alone and just keep reverting, I guess. --Super Goku V (talk) 06:43, 17 January 2023 (UTC)

RfC: Quality Wikipedia rather than "building the encyclopedia".

no idea what this is supposed to be, but it’s not a proposal Dronebogus (talk) 12:30, 18 January 2023 (UTC).

The living truth.. some parts of the community don't want high quality, they only want quantity, called "building the encyclopedia", and want to prohibit anonymous users from editing. These users would then be forced to register, and could be backtraced through their username and action taken against them in real life or online. I, for many, would rather see a quality wikipedia evolve. What is your opinion on this matter ? 194.223.29.253 (talk) 11:36, 18 January 2023 (UTC) This is a confused complaint and not a proposal. I suggest closing it. PrimeHunter (talk) 11:50, 18 January 2023 (UTC) Yes, this is not the correct place - that may be Wikipedia:Village pump (miscellaneous) or if it is fleshed out a bit into an idea Wikipedia:Village pump (idea lab). Now we're here I would ask why not just let individual editors concentrate on what they want to work on. That leads to both quality in some areas and quantity in some. Registration is a completely separate issue. Phil Bridger (talk) 12:11, 18 January 2023 (UTC) {Moved unsigned comment from inside top template. Discussion had been closed.) I believe the user is proposing a Wikipedia with impartiality: 'freedom from bias".— Preceding unsigned comment added by 118.208.122.36 (talk)

Graphic images in Vector 2022 search results

May be of interest to editors:  You are invited to join the discussion at Wikipedia talk:Vector 2022 § Graphic images in Vector 2022 search results. ProcrastinatingReader (talk) 15:40, 18 January 2023 (UTC)

Provide an option to revert to the old site design

Wikipedia's new redesign attempts to align with trendy 'modern' themes, to the setback of usability. Why is there now a large amount of whitespace to the left and right of the page? That's space that could be used for text, content, or links, but is rather now an empty void. And I must also now make an unnecessary click to access the sidebar links or my talk/contribution pages.

This change is, in my opinion, detrimental to the site's usability. I therefore propose an option is provided to logged out viewers to return to the old site design. 78.151.201.169 (talk) 21:52, 18 January 2023 (UTC)

Why not make an account? Then you can revert to the old version, or disable fixed width in the new version. Garuda3 (talk) 21:54, 18 January 2023 (UTC)

phab:T91201 is blocking this (there is currently nowhere for logged out users to store a preference). As such, this is a non-starter; see Wikipedia:Village_pump_(technical)#Vector_2022_deployment_update and/or Wikipedia talk:Vector 2022 for more on this. — xaosflux ^Talk 22:29, 18 January 2023 (UTC)

I didn't see that fixed width thing, thanks! Selfstudier (talk) 22:34, 18 January 2023 (UTC)

@Selfstudier: in Special:Preferences#mw-prefsection-rendering uncheck "Enable limited width mode". — xaosflux ^Talk 23:10, 18 January 2023 (UTC)

There is further discussion, including a solution which works for readers who are not logged in, at Wikipedia talk:Vector 2022#Use 2010 Vector as an IP. Certes (talk) 13:22, 19 January 2023 (UTC)

Should we have a more intuitive word for resizing images than "upright"?

[copied here per request from main VP talk page. — kwami (talk) 18:36, 19 January 2023 (UTC)]

Despite sizing images in absolute pixels being deprecated, that's how most of our images are. I think part of the problem might be that "upright" is not an intuitive parameter name. It certainly took me long enough to figure it out. When used on its own, "upright" makes perfect sense for scaling to 75% (of user default) for imgs in portrait orientation, but once you get to "upright=1.5" for wide images it's pretty much gibberish. I think if we introduced a more intuitive label, such as maybe "scale", we might have more success with people switching over. ("Upright" would continue to be supported, of course, but we'd have a more-easily memorized term as well.) I thought I might make a request at phabricator.wikimedia.org, but wanted to run it by here first. Would people support this, and would anyone prefer a different word than "scale"? — kwami (talk) 01:12, 15 January 2023 (UTC)

Sounds good, for those who are still learning to write Wikisource. Of course, most editors who joined in the past few years are inserting and adjusting pictures by Visual Editor, so they have no need to learn the markup language anyway. Jim.henderson (talk) 21:19, 16 January 2023 (UTC)

[made a Phabricator request here.]

@Kwamikagami: can you propose this change at WP:VPR? As I have said in the phab task, the technical part of adding an alias is easy, I have "scale" ready to commit. But they may not approve it if they think there is insufficient support for this. So proposing a specific word "scale" or something else at VPR and getting consensus for it will increase the likelihood of this being approved. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 18:29, 19 January 2023 (UTC)

Okay, copied here. — kwami (talk) 18:42, 19 January 2023 (UTC)

For what it's worth, support! 🐶 EpicPupper ^{(he/him | talk)} 00:23, 20 January 2023 (UTC)

Its not really a scaling parameter either and it is intended that it can be used without argument to call out an image that show be displayed/formatted as upright than lengthwise. We would need more tech support to implement a scale parameter (eg where scale=0.5 means display at 50%). Masem (t) 00:32, 20 January 2023 (UTC)

But that is exactly what it means: "Upright=0.5" means display at 50%. I'm proposing "scale=0.5" as more intuitive phrasing for display at 50%. — kwami (talk) 00:38, 20 January 2023 (UTC)

As for the comment above that most new editors use Visual Edit and don't need to know the code, people reviewing edits will still see it, won't they? When I change pixels to upright for a wide image (say 400 or 500px to uprigt=1.5 or 2), people occasionally revert me with the edit summary that "upright" is only used for upright (portrait) images. So I suspect that a more intuitive word like "scale" would be useful even for people who use Visual Edit. — kwami (talk) 19:42, 20 January 2023 (UTC)

If memory serves, VisualEditor doesn't support this anyway, because the future of the |upright parameter was unclear back when they were deciding what to put in the Media dialog box. Obviously, it hasn't been removed since then, but I'm not sure that you need to worry about VisualEditor at this stage. Whatamidoing (WMF) (talk) 21:39, 20 January 2023 (UTC)

But visual editor is exactly the problem.

When an editor simply clicks on an image in an article and drags it to a larger or smaller size, the underlying code uses "px" (specific pixel size) instead of "upright".

My personal experience, and thus for proposing this is that, as a newer editor, I edited ~30 articles using the visual editor before I realized that this was happening. It seems like a straight-forward upgrade to the visual editor (to apply upright instead of px). By the way, I went back and modified those 30 edited articles using "upright". I have since noticed many articles with specific "px" instead of upright and manually fix those myself; so this seems to be a fairly widespread problem.

I can no longer do the easy thing of clicking on the corner of an image, I must now go from visual editor to the old editor and then somewhat guess what upright size to specify.

If someone wanted to implement "scale" in this similar manner, that would be fine with me too. Countercheck (talk) 15:51, 16 March 2023 (UTC)

Perhaps we could have

"scale = 50%"

as even more intuitive. (Though perhaps people might confuse this 50% of preferred image size with 50% of the page width?) — kwami (talk) 20:24, 16 March 2023 (UTC)

RfC: Should Wikipedia return to Vector 2010 as the default skin?

Moved to Wikipedia:Requests for comment/Rollback of Vector 2022

 – InfiniteNexus (talk) 01:09, 21 January 2023 (UTC)

New language suggestions

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hi Wikipedia users and admins!

I have a proposal. Please can you add these languages to Wikipedia in order for them to have their separate Wikipedia links:

• Ancient Greek (The earliest form of Greek language which is still studied today)
• Proto-Albanian (The earliest form of Albanian language which is studied from some language scholars)
• Svan (Kartvelian language spoken in Western Georgia) - since there are Wikipedia language links for Georgian and Mingrelian, this is missing too.

I would be so happy if you will take my request into consideration.

Thanks HELGAPRV (talk) 10:35, 21 January 2023 (UTC)

If you’re suggesting new language editions for Wikipedia, isn’t a proposal for English Wikipedia, it’s a proposal for Metawiki, and the first two are probably going to be rejected because they aren’t commonly spoken (creating Wikipedias for dead or constructed languages died out a while back because their purpose is more hobbyist than educational). Dronebogus (talk) 12:25, 21 January 2023 (UTC)

(edit conflict) @HELGAPRV: this page is only about the English Wikipedia, to request projects in other languages see meta:Requests for new languages; please note this is not a trival process and unless you are willing to champion such a project it likely won't start soon. — xaosflux ^Talk 12:28, 21 January 2023 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Making dark mode more accessible

Hello, haven't edited here in a while but I feel like if we're gonna change the site layout, it might also make sense to make dark mode more accessible to users. Specifically, it should be available without needing to make an account and also at least shouldn't buried deep in the Gadgets menu, it should just be in the Appearance settings like you'd expect it to be. SemiHypercube 19:03, 20 January 2023 (UTC)

• @SemiHypercube, that's because it's a community-supported imperfect gadget. Someone said at VPT that V22 makes a WMF dark mode more likely. — Qwerfjkltalk 22:00, 20 January 2023 (UTC)

I'd refactor this proposal as "put dark mode explicitly on the road map for the default skin". It's possible, now we let's make it so. This would free up the time of the people who work sporadically on less official dark mode options. – SJ +

An interesting way to do this for the new skin might be to make use of the prefers-color-scheme media query. I'd be way of changing old skins in this way though, at least without an opt-in. Anomie⚔ 11:56, 22 January 2023 (UTC)

prefers-color-scheme is the way to go. There shouldn't be so many different ways for enabling dark mode for each website, and cookies/accounts shouldn't be needed to keep them enabled. Looking at the MDN article you linked, all major browsers support the media query. small jars tc 22:26, 22 January 2023 (UTC)

Hi @SemiHypercube:, thank you for your feedback. Please look at this section of our FAQ and this answer.--Patafisik (WMF) (talk) 11:30, 23 January 2023 (UTC)

prefers-color-scheme is indeed one way to do this, but it doesn't allow switching on demand, If I remember correctly, so we still need some additional work for that mode. But the more important thing is that the skin sort of needs to support CSS variables in order to be able to scale switching the color schema. CSS variables are currently supported by some 96% of the user base's browser, and I think its pretty achievable with the new skin setup to introduce them, with a few weeks/months of work (currently not planned nor budgeted). But we should not forget that much of the CONTENT is completely not dark mode compatible and fixing that is a separate issue. —TheDJ (talk • contribs) 12:35, 23 January 2023 (UTC)

Block edits that that introduce a paragraph break followed by a change to article text

The 'diff ' for an edit should reflect all the changes made in that edit. However, if a paragraph break is added to pre-existing text and, in the same edit, changes are made to the text immediately following the break (prior to the next break), the text changes do not show up in the diff. For example, in this edit, I added a paragraph break and also changed "firmament" to "dome" following the break; the text changes are not visible in the diff unless one compares the original text to the changed material word by word. To avoid this, the text changes and the paragraph break need to be made in separate edits. I propose that edits changing both at once be blocked and the editor be advised that two edits are required. Alternatively, the software might be changed so that changes to both somehow show up in the diff.
Peter Brown (talk) 22:06, 21 January 2023 (UTC)

Improving the diff sounds like a good proposal, and better than preventing legitimate edits. There are a few tools around that provide alternative diffs. For example, User:Cacycle/wikEdDiff (available as a gadget in Preferences) handles your example edit above well. Certes (talk) 23:07, 21 January 2023 (UTC)

There's currently a project ongoing at the WMF to improve the diffs in this scenario: m:Community Wishlist Survey 2022/Better diff handling of paragraph splits. Disallowing these edits it seems would do more harm than good. Matma Rex talk 08:06, 22 January 2023 (UTC)

This really is an issue with the diff highlighter. Making two edits instead of one would flag the change when viewing a single edit diff but not when viewing the two-edit diff. —Kusma (talk) 09:04, 22 January 2023 (UTC)

I would oppose blocking the edit. Even with an explanation it may confuse newer editors as to why their edit was not allowed. I had to look twice to see what the problem was. Improve the diffs. CambridgeBayWeather, Uqaqtuq (talk), Huliva 18:35, 22 January 2023 (UTC)

• Strong oppose we should not block an edit that could be legitimate over some text highlighting in that tool, the edit is fully reviewable. Follow up on phab:T7072 / phab:T156439 as desired. — xaosflux ^Talk 17:16, 23 January 2023 (UTC)

RfC: Replace "Talk" tab on all WP pages with a "Correspondence" tab

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

We do not use vocal input on the tab. To be true to life, the tab should be labelled "Correspondence", or is it too big a word for most? It may help "de-warp" the world.! 203.213.42.40 (talk) 17:01, 23 January 2023 (UTC)

"Talk" is understood to mean interact, in a broad sense. In this case, interactions of interested users about the subject article 71.105.141.131 (talk) 17:42, 23 January 2023 (UTC)

Oppose. Unnecessary, and in virtually all cases people will understand that the talk namespace is just Wikipedia's version of an article-specific moderated Chat room. The Night Watch (talk) 00:45, 24 January 2023 (UTC)

Oppose. Almost everyone understands what "Talk" means in an online context, much like we don't disparage people for saying writing comments on here. —Tenryuu 🐲 ( 💬 • 📝 ) 00:49, 24 January 2023 (UTC)

Oppose As explained by others, the meaning of "talk" here is exactly what it actually is. Sincerely, North8000 (talk) 01:08, 24 January 2023 (UTC)

Oppose. "Talk" is jargon, but it's concise and easily learned. Lest anyone expect the tab to read the article out audibly, helpful clarification appears when hovering over the word. We also have millions of links to Talk:Foo, User_talk:Bar, etc. If we did change, we'd use "Discussion" to match other language wikis.

Certes (talk) 01:16, 24 January 2023 (UTC)

Oppose. Unnecessary change to well-known Wiki terms. There is nothing to gain for this change, and the confusion it created will be massive. ✠ SunDawn ✠ (contact) 02:41, 24 January 2023 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Prohibition on the locking of user talk pages

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I extremely loathe how some administrators, people who are supposed to actively communicate with the rest of the Wikipedia community, become so fragile that they use their admin privileges to lock their talk pages. These are people who voluntarily signed up to run and be elected as Wikipedia admins; folks who are to aid and engage with the rest of the community for the betterment of the free encyclopedia, yet some of them instead attempt to do the opposite and actively avoid communicating with the broader Wikipedia community. I've seen one admin lock their page with a 30/500 protection, which effectively means that only the 99th percentile of Wikipedia editors can communicate with them. I've seen an editor literally create a banner stating that on their talk page, they don't want anything else beside bot comments, barn stars, and Featured/Good article announcements pertaining to any of the articles that they created. These are people who have the power to choose whether or not an article should exist, the power to block individuals, the power to rollback, the power to lock pages, and with all that power, they effectively shelter themselves from any feedback and input from the rest of the community out of what I can only assume to be a combination of mental fragility and a Russian ego.

I think that with the exception of extremely peculiar circumstances, the locking of a user's talk page should be banned. This is literally an attempt to shut down meaningful discussion about you and your role on this site for no real good reason. Any admin that locks their page should be ostracized and booted out. Knightoftheswords281 (talk) 22:29, 20 January 2023 (UTC)

There are very real reasons why one might have a protected user talk page, such as a WP:LTA repeatedly posting oversightable information on one's talk page. Rather than leaving it to the antivandalism folks to clean up each instance of oversightable information being dumped, contacting an oversighter to oversight the information, and then repeating this process until the LTA is simply exhausted for the day, it is sometimes better to semi-protect user talk pages so that antivandalism work doesn't take so much editor time that could be spent elswhere. For that reason, I oppose a strict prohibition on protection admin user talk pages, though I agree that admins should be willing to accept feedback from IP editors and newer editors. — Red-tailed hawk _(nest) 23:39, 20 January 2023 (UTC)

• Nonsense. See WP:DENY. Johnuniq (talk) 01:20, 21 January 2023 (UTC)

  I'm not exactly sure what your point is?

  I think there's been a severe misunderstanding in what I mean: I'm not advocating for a total ban of locking user talk pages, since I believe that under certain circumstances, as I originally stated, there are certain moments where a temporary lock may need to be instated, like other users in this thread stated (@Zaathras - I do not begrudge any admin who, besieged by a bunch of internet losers, locks out new or IP editors for a time. and @Meters - And it's not just admins who sometimes need to have their talk pages protected). I support the temporary lockdown of certain pages due to long-term abuse and the like.

  When I criticize admins for locking their talk pages, I'm primarily talking about the admins who have indefinitely locked their pages under a 30/500 or proudly proclaim at the top of their talk page that essentially only bot comments are allowed on their talk page. You can't justify this since this is basically locking out most, if not all of Wikipedia community over some loser vandals and trolls who occasionally take command of an imaginary B-45 from their semen/cheeto-stained couch in their mother's basement and firebomb an admin's talk page MOVE style because they reverted their edits on Jenna Ortega's article boasting about how they lasted 12 seconds in her. Are we really going to make good-faith editors suffer forever because of some fools who will wound up getting blocked soon anyway? Admins shouldn't permanently sever their interaction with the community they lead over the Wikipedia equivalent of Redditors - salty trolls with no life. Knightoftheswords281 (talk) 02:28, 21 January 2023 (UTC)

  Indef ECP on a user talk page requires a really good reason, and there only a couple cases I can think of where the extent of vandalism by (auto)confirmed accounts is so great that the burden on the community caused by vandalism outweighs the inaccessibility of the page to newer uses who the admins are interacting with—even for a temporary ECP. If there is a particular ECP that you disagree with on a particular talk page, feel free to discuss it with the admin who implemented it and, if you can't reach agreement with that admin, to make a request for decreasing the protection at WP:RFPP (if the page is ECP protected due to an arbitration enforcement action, the place to go to appeal the ECP would be WP:ARCA or WP:AE).

  Proclaiming that only bot comments are allowed on one's talk page is inconsistent with WP:ADMINACCT (as Joe notes below), and I'm not sure where you're seeing that, but that would probably be worth bringing up for community discussion if the protection is causing a problem. — Red-tailed hawk _(nest) 05:44, 21 January 2023 (UTC)

• Admins take a lot of heat for the actions they have to perform, blocks, topic bans, article deletions, etc... I do not begrudge any admin who, besieged by a bunch of internet losers, locks out new or IP editors for a time. Zaathras (talk) 01:46, 21 January 2023 (UTC)

• I also oppose this. And it's not just admins who sometimes need to have their talk pages protected. Meters (talk) 01:54, 21 January 2023 (UTC)
• The policy on this issue, WP:UTPROT, already says what you're suggesting: that user talk pages should only be protected under rare circumstances. If there are any particular administrators you're concerned about, the obvious first step would be to ask them about it. You may well find that they have better reasons than you think. Extraordinary Writ (talk) 02:31, 21 January 2023 (UTC)
  • Yes, there apparently is a misunderstanding of what is being proposed, and it's not surprising, when the OP's header is Prohibition on the locking of user talk pages and their summary of the proposal is Any admin that locks their page should be ostracized and booted out. We're responding to what was written. If the OP is actually concerned about edge cases that violate WP:UTPROT this rant wasn't making the point. Meters (talk) 03:06, 21 January 2023 (UTC)
• You're not doing yourself any favours with the rant (because yes, administrators volunteertheir time to help Wikipedia and like all volunteers are obligated to communicate precisely as much as they want to communicate, no more). But unless there are exceptional circumstances EC-protecting a user page would be against WP:UTPROT and in my opinion also WP:ADMINACCT. Since these are already policies, if you're concerned that someone isn't following them, the first step is to ask them about it, and if that fails ask for a second opinion at WP:AN. – Joe (talk) 05:07, 21 January 2023 (UTC)

• So looking through Protected pages I see there is one admin who has extended confirmed protection on their talk page (it's near the bottom of the list). I don't see anything indicating that you discussed it with them before coming here. Nor did you notify them that this discussion was taking place. I'll let them know.

I tried looking through indefinite semi-protected but that is harder as a non-admin moving a protected page in their user space gets listed. But even there I didn't really see any problems. Most admins seem to be protecting other talk pages or their archives.

"...proudly proclaim at the top of their talk page that essentially only bot comments are allowed on their talk page." Can you point out who these admins are? That does need dealing with.

This seems like overkill for one persons talk page. CambridgeBayWeather, Uqaqtuq (talk), Huliva 19:23, 22 January 2023 (UTC)

• The OP's user page suggests that they are in school; from that I assume that they are young. From their contributions history, I see that they are relatively inexperienced as a editor here, and have not perhaps seen the darker side of what some LTAs like to do. We should go easy on them. Let me say this though: Knightoftheswords281, you know not of what you speak. In every case I have ever looked at, there has been a good reason for the protection. If you have a specific example of a case where you believe an admin has improperly protected their talk page, we can of course look into that, individual cases do not mean that the general practice is inappropriate. Best Girth Summit _(blether) 19:29, 22 January 2023 (UTC)

The general rule is that page protection should be at the lowest level and for the shortest amount of time needed to deal with a problem. The other general rule is that admins need to be accessible for communication, and should have thick skins to ignore most of the random crap tossed in their direction. But there are limits. My willingness to discuss my actions doesn't mean I'm willing to be a punching bag.

If an admin is dealing with ongoing disruption on their talk page, there's absolutely nothing wrong with protecting their talk page to the extent needed to deal with the problem. I'd raise an eyebrow at an admin whose talk page was protected at a level higher than semi and/or for any significant amount of time. I'm not saying such a thing couldn't be justified, but it would be rare.

Looking at my own talk, I see I've semi-protected it three times, for a week each time. I also notice that I managed to go the first 16 years of my adminship without ever needing to protect it at all. So either my skin isn't as thick as it used to be, or I've just started pissing people off more in the past couple of years :-) -- RoySmith (talk) 20:33, 22 January 2023 (UTC)

I think this should be closed now (and should have been closed sooner) if the poster doesn't give diffs so that we can see what, if anything, this is really all about. We are told that some admins "become so fragile that they use their admin privileges to lock their talk pages". Let's see some evidence of that, because current policy is that they should only do so in extremis. Phil Bridger (talk) 20:54, 22 January 2023 (UTC)

The most egregious example is User talk:Trillfendi, which at the top boldly reads As of Indigenous Peoples' Day 2019, these are the ground rules around these parts: do not leave messages here unless it pertains to article creation, a Good Article nomination, an automated comment from a bot, a barnstar, an invitation to join a WikiProject, requesting help, or something important. Anything else will not be entertained. DISCRETION IS ADVISED. This is the example I was using when I meant . I've seen an editor literally create a banner stating that on their talk page, they don't want anything else beside bot comments, barn stars, and Featured/Good article announcements pertaining to any of the articles that they created..

Sure you could argue that the requesting help, or something important. segment vindicates them, however, considering that after this rule was implemented, there was only one or two organic responses in their talk page is demonstrative of the effect. Even the user talk pages that are locked behind a 30/500 still receive somewhat notable traffic.

@CambridgeBayWeather @Extraordinary Writ @Girth Summit @Joe Roe (mobile) @Johnuniq @Meters @Red-tailed hawk Knightoftheswords281 (talk) 21:29, 22 January 2023 (UTC)

I asked you which admins were saying they would only permit bot edits. Trillfendi isn't an administrator. I cut that list to start at "ta" so as not to have to dig through every admin. So again, are there any admins that say they will only permit bot edits on their talk page. Right now this whole section is about one admin and they haven't commented here. CambridgeBayWeather, Uqaqtuq (talk), Huliva 21:45, 22 January 2023 (UTC)

Meh. This started out talking about admins protecting their talk pages. Trillfendi isn't an admin, I don't see why this applies. I believe that WP:ADMINACCT applies to any editor who performs admin-type actions. In Trillfendi's case, she's a pending changes reviewer, so I'd expect she'd be willing to entertain queries on her talk page about PC reviews she'd done. Beyond that, if she wants to filter what types of messages she wants to get, I think that's pretty much up to her. -- RoySmith (talk) 21:49, 22 January 2023 (UTC)

As has been noted above, Trillfendi isn't an admin, so didn't apply protection to their own page. Whoever did probably had a good reason. What is this complaint about again? Girth Summit _(blether) 21:54, 22 January 2023 (UTC)

What protection? I can't see any evidence that her page is or was protected. Hawkeye7 (discuss) 22:50, 22 January 2023 (UTC)

Trillfendi is not an administrator. And honestly, I can't blame her for wanting to restrict the contents of her Talk Page. Non-admins certainly have every right to do so. 🌈WaltCip-(talk) 14:01, 23 January 2023 (UTC)

• "This is literally an attempt to shut down meaningful discussion about you and your role on this site" is littterally a violation of AGF. Drmies (talk) 23:21, 22 January 2023 (UTC)

Trust me, @Knightoftheswords281, there's a very obvious bunch of reasons why some people, admins or otherwise, may need to lock their user talk page. LilianaUwU ^{(talk / contributions)} 00:11, 23 January 2023 (UTC)

There's one admin, once CU, and one non-admin editor that I know of off the top of my head that need their user talk pages either semi protected or extended confirmed protected, because of the level of abuse and harassment they receive (or received prior to protection) daily. If an user's talk page is protected, there is almost always a very good reason for why it is. Sideswipe9th (talk) 00:31, 23 January 2023 (UTC)

This proposal is meaningless and wouldn't change literally any policy if enacted, so why are we even here? casualdejekyll 19:51, 24 January 2023 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RfC on establishing a policy exclusively for British monarch article titling (withdrawn)

We propose that English, Scottish, Irish and British monarchs from William II of England onwards should always conform to the "[Name][Ordinal] of [Country]" or "[Name], [Queen/King] of [Country]" format, without exception.

Reasons given by Tim O'Doherty

1. It should not matter if the shortened version, e.g. "Elizabeth I" is more commonly used. The article titles for UK monarchs are becoming inconsistent, a violation of the policy WP:CONSISTENT which states "We strive to make titles on Wikipedia as consistent as possible with other titles on similar subjects." This means that if passed, all British monarch's pages should be moved to the aforementioned format, e.g. Elizabeth I → Elizabeth I of England

2. Far more monarchs use the aforementioned format rather than the "[Name] [Ordinal]" format: 27 do, with only 12 not and 2 using neither format, those being James VI and I and Queen Victoria.

3. If moved, the old titles would become redirects (e.g. Elizabeth I would still redirect to Elizabeth I of England) so that the everyday Wikipedia user has the same ease of navigation between the articles.

4. The guideline WP:SOVEREIGN states "kings, queens regnant and emperors and empresses regnant who are known as "first name + ordinal"...have article titles in the form "{Monarch's first name and ordinal} of {Country}"." We propose to make this policy specifically for British monarchs.

5. If accepted, this policy should override WP:COMMONNAME on future RMs concerning such articles for the reasons mentioned above, and the fact that this is written specifically for British monarchs (and therefore have their pages in the best interest) whilst COMMONNAME does not.

6. Articles for monarchs that reigned from 1087 to 1707 should be titled "[Name] [Ordinal] of England". Articles for monarchs that reigned from 1707 to 1801 should be titled "[Name] [Ordinal] of Great Britain". Articles for monarchs that reign/ed from 1801 to the present day should be titled "[Name] [Ordinal] of the United Kingdom".

Reasons given by GoodDay

7. Elizabeth II & Charles III are most associated with the United Kingdom, they lived & live in that realm. Elizabeth II is buried in the UK, Charles III & his successors will most likely (in future) also be buried in the UK. Note - Because the UK is the primary resident realm? it has no governor-general.

Notes

Tim O'Doherty (talk) 17:20, 2 January 2023 (UTC)

Discussion - Articles on UK Monarchs

I have no great interest in this topic, as I can support anything that makes it obvious what the title means, but I must say that I am very wary of anything that uses the words "always" and "without exception", especially if those words are bolded and especially if we immediately have to have exceptions spelt out in footnotes. It seems that this proposal is to apply "without exception" except in the cases where we have exceptions. Phil Bridger (talk) 17:40, 2 January 2023 (UTC)

There is a clarification, not an exception. If you want the article titled James I of England and VI of Scotland then be my guest, but the reason as to why there really shouldn't be any exceptions is because this proposal is to bring consistency to British monarchs' articles. One exception leads to another, two exceptions is a precedent and then consistency unravels once more, which defeats the point. Tim O'Doherty (talk) 17:45, 2 January 2023 (UTC)

William the Conqueror is an exception. Why does this proposal only start with William II, if not to create an exception? Phil Bridger (talk) 19:12, 2 January 2023 (UTC)

I'm not maliciously creating an exception; it's easier to just begin with William II because he is the first monarch after the Norman Conquest to be styled with ordinals. I could add William the Conqueror, but he would just end up in point 2 as another that doesn't follow any other format, so there wouldn't be much point in it at all. Tim O'Doherty (talk) 19:24, 2 January 2023 (UTC)

I can think of no reason whatsoever why Wikipedia would need a policy on this particular matter. How is it any different from any of the umpteen other things that people find it necessary to bicker about? You can't create an encyclopaedia by formulating endless rules... AndyTheGrump (talk) 18:00, 2 January 2023 (UTC)

But there is a need for consistency. Having RMs for monarchical articles every other week doesn't build an encyclopaedia either. It does no harm to have a policy on it. Tim O'Doherty (talk) 18:06, 2 January 2023 (UTC)

You could write an essay/guideline, if it's good, people will buy into it even if it's not a policy. Selfstudier (talk) 18:10, 2 January 2023 (UTC)

Yes, but it's not ideal as policy overrides guidelines and so, again, it defeats the point of creating a fixed standard for the titles. This policy proposal only really works if it is policy rather than guideline, otherwise I may as well not bother with it. Tim O'Doherty (talk) 18:19, 2 January 2023 (UTC)

I guess one concern I'd have is that this would effectively override the recent Charles III RM, which gained very wide participation before being closed in the negative, on whether to move the article to Charles III of the United Kingdom, discussion here, with the RM close upheld here, with the closer on that review (who has since passed an RfA) noting that the participation in the RM was "abnormally heavy". Possibly that result should be respected here.--Wehwalt (talk) 18:17, 2 January 2023 (UTC)

I admit that did cross my mind (I even supported Charles III rather than Charles III of the United Kingdom) but I do think that broader consistency is more important than the result of an RM on one page. If this RfC is heavily interacted with as well, then that will sort the matter. Tim O'Doherty (talk) 18:23, 2 January 2023 (UTC)

I doubt you'll get quite the number of opinions in such a short period ... would the policy ensure that the old names (say Charles III) remain redirects? I suspect there will be some seeking equal treatment for Charles III of Spain etc (as in the RM), who will be anxious to make Charles III a disambiguation page, as they suggested in the RM. Wehwalt (talk) 18:39, 2 January 2023 (UTC)

Yes, they would, as point 3 states. Tim O'Doherty (talk) 18:43, 2 January 2023 (UTC)

But William III and George I and George II and probably others point to disambiguation pages so there's still going to be inconsistency. Wehwalt (talk) 19:02, 2 January 2023 (UTC)

That comes down to whether they are the primary topic or not, which is out of my control. Tim O'Doherty (talk) 19:03, 2 January 2023 (UTC)

• The policy that governs this is our WP:AT policy, which does list Consistency as one of the factors we must consider when determining the best title for an article. However, the policy makes it clear that we must also consider Recognizability, Naturalness, Precision, and Conciseness - and I am not at all sure that the proposal takes those other factors into consideration. Indeed, my experience is that, of these five factors, Consistency is arguably the weakest (the one most often over-ridden by the others). Blueboar (talk) 19:21, 2 January 2023 (UTC)

Issues I thought of immediately, there may be others:

• This is claimed to apply to English, Scottish, Irish and British monarchs from William II of England onwards. But it is not obvious why William II of England is a sensible starting point for Scottish monarchs or for High Kings of Ireland. It is also not clear why Welsh monarchs are not included.
• The argument for retaining William the Conqueror as an exception might legitimately apply to later monarchs such as Robert the Bruce. There are other Scottish, Welsh and Irish monarchs who are primarily known by names outside this pattern such as John Balliol and Owain Glyndŵr. There is also the case of Mary, Queen of Scots, who is almost never called Mary I, even though Scotland did have Mary II.
• After the Statute of Westminster, the Crown is split, so it is not clear that George V, Edward VIII, George VI, Elizabeth II and Charles III should be treated as monarchs solely of the United Kingdom.
• While James VI and I is treated as an exception, the parallel cases of James VII and II and William III and II are not treated as exceptions.
• British Monarchs started referring to themselves as monarch of Great Britain in 1604, long before the Act of Union. It is not clear whether this proposal intends to refer to these as kings and queens of Great Britain, of England, Scotland and Ireland, of England and Scotland, of England, of Scotland or something else.
  • If they are to be called monarchs of something other than Great Britain it is not clear how Queen Anne fits in to this, given that she was monarch at the time of the union that created the Kingdom of Great Britain.
  • If they are to be called monarchs of something other than England and Scotland or England, Scotland and Ireland it is not clear how James VI and I fits in to this, given that he had been King of Scots for 35 years by the time he inherited the English throne.
• It is not obvious why Scottish kings should be of Scotland and not of Scots.
• It is not obvious why Irish high kings should be King of Ireland and not High King of Ireland.
• There is an issue with Henry the Young King, who by this standard should presumably be Henry, King of England, a name that nobody will recognise.
• There is a question of whether Henry VI of England, by this standard should also be listed as a King of France, given the circumstances of the dual monarchy of England and France.

It appears to me that this is a proposal that tries to create consistency where consistency is not necessarily desirable, and thus I am inclined to oppose it. Kahastok talk 19:23, 2 January 2023 (UTC)

Nobody's claiming that George V to Charles III are soley British Monarchs. We're merely pointing out that they've resided in & are mostly associated with the United Kingdom. It's not often (for example) that we read or hear about "King Charles III of Tuvalu" or "Queen Elizabeth II of Saint Lucia". GoodDay (talk) 19:35, 2 January 2023 (UTC)

• We did not mean Monarchs of England, Scotland and Ireland as the monarchs of the separate kingdoms, but monarchs of Britain that were at some point monarchs of those countries (e.g. George IV was King of the United Kingdom, which included England, Scotland and Ireland, but not the individual kingdoms of said countries). We are not dealing with monarchs who were only monarch of Scotland or Ireland, e.g. Mary, Queen of Scots. I did provide the list in the original statement, but apologies if the wording was not clear.
• All those examples listed are from the individual kingdoms, so see the paragraph above.
• They are primarily known as monarchs of the UK rather than the countries in the Commonwealth, as their leads state (e.g. "Elizabeth II (Elizabeth Alexandra Mary; 21 April 1926 – 8 September 2022) was Queen of the United Kingdom and other Commonwealth realms" puts clear emphasis on the fact that she was Queen of the United Kingdom).
• They are not treated as "exceptions" because their articles are not titled as such...
• I am not the one responsible for this. Monarch's articles from 1604 to 1707 practically always have "of England" after then, e.g. Charles I of England, Charles II of England. I am simply continuing this, so the problem is not with this proposal.
  • It is clear how Queen Anne fits into it as her article is called "Anne, Queen of Great Britain" and should continue to be titled as such.
  • The proposal says that "James VI and I" should remain the title of his article.
• See paragraph one of this reply.
• See paragraph one of this reply.
• Apologies for not listing Henry the Young King in the first note. The proposal does not cover him.
• No, similar reasoning as given in the third paragraph of this reply. Tim O'Doherty (talk) 19:56, 2 January 2023 (UTC)

I'm afraid that the proposal that then becomes, they all have to be consistent with this pattern, without exception except the ones that do not have to be consistent with the pattern.

If there is some great need for consistency here, then James VI and I becomes a huge problem because the proposal admits that it remains as is, which is inconsistent with all the others. I do not think you can claim to be creating consistency without resolving that. And I feel your proposed guideline really needs to clear up the question of all of period from 1603-1707 if it's aiming to enforce consistency. I don't think saying well they're all already at [Name] [Ordinal] of England so they don't need to be covered is adequate - not least because I feel a guideline on this point should at least consider the fact that they were also Kings and Queens of Scots.

I also don't see why the proposal should cover pre-Union monarchs from England, but not pre-Union monarchs from Scotland, Wales and Ireland. I note that only two articles for English pre-union monarchs are within scope and not already of the form [Name] [Ordinal] of England or [Name], King of England. These are James VI and I and Elizabeth I. And since James VI and I is excluded anyway, it's not obvious to me that adding Elizabeth I adds much. Perhaps if your proposal started from Queen Anne instead of William II it might better cover what you intend it to cover and get rid of a lot of the exceptions and oddities?

And I am still concerned that there is a problem with acknowledging the UK and not the other Commonwealth Realms - at least after 1931. You say that the article starts with Elizabeth II... was Queen of the United Kingdom and other Commonwealth realms - well the implied article name in that case would surely therefore be Elizabeth II of the United Kingdom and other Commonwealth realms, which feels a bit of a mouthful. Kahastok talk 21:15, 2 January 2023 (UTC)

Why are you concerned? If we had to choose one of the realms, it would be the United Kingdom. I doubt a RM proposal to move to "Charles III of Australia" or "Charles III of Canada" would garner much support. Last time I checked, his coronation is going to be held in London, UK. It's not going to be repeated 14 more times, in each of the other realms' capitals. GoodDay (talk) 21:54, 2 January 2023 (UTC)

I do not accept that we necessarily have to choose one of the 15 realms, and I feel that there are significant problems with doing so. Kahastok talk 17:38, 3 January 2023 (UTC)

Just like before, you & I are likely never going to agree on this topic. GoodDay (talk) 17:48, 3 January 2023 (UTC)

When was "before", exactly? I'm fairly certain I've never discussed naming of these articles before on Wikipedia, with you or otherwise. Kahastok talk 18:23, 3 January 2023 (UTC)

I have said that monarchs from 1087-1707 should by titled "[Name] [Ordinal] of England". I view James I as a sensible transition monarch between the pre-Union monarchs and the monarchs that reigned after the Union of the Crowns; it addresses that he was King of Scotland, but also the first King of Scotland to be King of England as well. The alternative is James VI of Scotland and I of England or James I of England. At a push, I'd go for the latter, but that would, no doubt, cause Scottish Wikipedians to (rightfully) protest, which is a situation best avoided and a situation that should be treated with tact.

It only covers monarchs of England before 1603 because that is what the policy was written to do. There is no issue that needs fixed with Scottish monarchs, so no need to cover them in a policy.

I used the opening sentence to rebut what you had said about the proposed titling not covering the other realms, I did not intend to imply that Elizabeth II's article should be called "Elizabeth II of the United Kingdom and other Commonwealth realms" as that is a pretty obvious violation of WP:CONCISE. Tim O'Doherty (talk) 23:27, 2 January 2023 (UTC)

If the Scots rightfully protest at James I of England, why is it not equally rightful that they protest at Charles I of England?

And, when I read It only covers monarchs of England before 1603 because that is what the policy was written to do I see a circular argument. It covers the period from 1087 because it covers the period from 1087.

You say there is no issue that needs to be fixed with Scottish monarchs, but so far as I can see the articles for Scottish monarchs show just as much variation as English ones. If we allow William the Lion, for example, why not also allow Richard the Lionheart? If anything Scottish monarchs show more variation than English ones.

Overall, I find this proposal worryingly anglocentric. For those monarchs who were equally king or queen of multiple countries, we need to find a way of naming the articles that does not treat countries that are not England as unimportant. Kahastok talk 17:38, 3 January 2023 (UTC)

I'd rather we had William I of Scotland, keep Richard I of England & have William I of England, Catherine II of Russia, Frederick II of Prussia, Mary I of Scotland, etc. Not the nickname titles. GoodDay (talk) 17:44, 3 January 2023 (UTC)

The "nickname titles" - by which I assume you mean names that don't fit your pattern - tend to score quite highly in terms of the naming criteria. And in some cases - like English kings from before 1066 - they're pretty much the only names we have. History doesn't always fit a pattern and it doesn't always do to try to shoehorn it into one. Kahastok talk 18:23, 3 January 2023 (UTC)

Can we momentarily bring this back to the proposal rather than debating on monarchs of different kingdoms? The fact is that the monarchs that this proposal covers are not known by epithets and all employ ordinals in their current titles. Monarchs of the Kingdom of Scotland (before 1603), Russia, and Prussia are irrelevant. We don't need to debate on whether we should use epithets or ordinals because they all already use ordinals. The discussion is on whether or not we should have a consistent policy on UK monarch titling. Tim O'Doherty (talk) 18:44, 3 January 2023 (UTC)

I do not accept that monarchs of Scotland are irrelevant. Because if there is a problem with English and post-1603 Scottish monarchs, then there is also a problem with pre-1603 Scottish monarchs. If there is not a problem with pre-1603 Scottish monarchs, then there is also not a problem with English and post-1603 Scottish monarchs. It makes no sense to me that we should have a special guideline for English and post-1603 Scottish monarchs that does not apply anywhere else, including Scotland before 1603.

I would add as a separate point that I am concerned that this may in practice be an WP:RM that has not been adequately notified to the affected articles. Yes, the proposal is that a separate RM would be required, but that RM would surely come, and this proposal essentially defines the outcome of the RM. So the risk of accepting this is that we do an end run around the standard RM process and its notification requirements.

I'm going to boil this down I guess. I oppose because (a) I don't think this specific point needs its own separate guideline, (b) I don't think the proposed move targets are appropriate and (c) because of procedural concerns. Kahastok talk 23:04, 3 January 2023 (UTC)

I'll notify the concerned articles with RMs if this passes. If this doesn't pass, they'll just have to be withdrawn anyway as the policy to back them up won't exist.

Also, the monarchs of Scotland pre 1603 aren't irrelevant, but that's not what this proposal was written to cover. The are an entirely different case-sensitive can of worms. I am not proposing, for example, that Mary, Queen of Scots be moved to Mary I of Scotland. I would need to write a different proposal on it to cover those cases. Tim O'Doherty (talk) 23:12, 3 January 2023 (UTC)

Nobody is suggesting that countries outside of the UK are unimportant (they all get fair treatment within the article body) but the alternative is to have such articles titled things like "Elizabeth II of the United Kingdom, Canada, Australia, New Zealand, South Africa, Pakistan, Ceylon, Ghana, Nigeria, Sierra Leone, Tanganyika, Jamaica, Trinidad and Tobago, Uganda, Kenya, Malawi, Malta, The Gambia, Rhodesia, Barbados, Mauritius, Fiji, The Bahamas, Grenada, Papua New Guinea, the Solomon Islands, Tuvalu, Saint Lucia, Saint Vincent and the Grenadines, Belize, Antigua and Barbuda and Saint Kitts and Nevis". We can't have them all. Tim O'Doherty (talk) 18:52, 3 January 2023 (UTC)

@Tim O'Doherty, I appreciate all the work you've put into this, but I'm struggling to see what it means in actual practice. Consider George III: Are you proposing that the article be moved to George III of England? George III of Great Britain? George III of Great Britain and Ireland? George III of the United Kingdom? Or something else? A firm rule would work best if we all knew what the result was supposed to be. WhatamIdoing (talk) 21:59, 3 January 2023 (UTC)

Its previous title, George III of the United Kingdom. GoodDay (talk) 22:04, 3 January 2023 (UTC)

It would be George III of the United Kingdom. If you want a list of all the new names that would be if the proposal is accepted, I'll gladly write them down in my second sandbox. If not, point 6 provides some instruction on the point you've raised. Tim O'Doherty (talk) 22:13, 3 January 2023 (UTC)

Note to everybody: the list of titles under the proposal if accepted is here. Tim O'Doherty (talk) 22:38, 3 January 2023 (UTC)

In Australia, this will be taken as a polemical political statement, arguing against the de jure status of Australia as a monarchy. This alone would be enough for me to oppose under our WP:NPOV policy. Hawkeye7 (discuss) 19:42, 2 January 2023 (UTC)

Saying this is against NPOV is surely a bit of a stretch. All monarch's articles address that they are monarch of the Commonwealth realms. They are known as monarch of the United Kingdom, and if you find this proposal problematic, then surely you must also find WP:COMMONNAME problematic too, which argues for the common name, which is what "of the United Kingdom" is. This "problem" already exists too; take Charles II of England as an example. He was king of Scotland and Ireland as well, but nobody is arguing that that is against NPOV. The issue that you take with it is not exclusive to this proposal. Tim O'Doherty (talk) 20:02, 2 January 2023 (UTC)

I personally think that including some sort of country in the article name would be ideal under WP:NPOV/WP:GLOBAL, because, and this may surprise some people, countries other than England exist. I just have no clue what country name that would be, in some cases, and this proposal seems to create more problems then it solves. casualdejekyll 20:22, 2 January 2023 (UTC)

Not really a problem. The Stuarts 1603-1707, are more recognisable as English monarchs. Meanwhile, after the Union Acts, George I to Charles III, are more recognisable as British monarchs. GoodDay (talk) 22:02, 2 January 2023 (UTC)

Utter waste of time. Firstly this is a MOS issue, not a policy issue. Secondly the point of MOS is to provide a standard framework for consistency, where it cannot provide that consistency, it just causes more trouble than it solves. Thirdly, any time you proscribe something and say "this is the way it must be done" and even before the ink is wet you have a dozen exceptions, it's just a deliberate act of riling people up at that stage. No, god no. Only in death does duty end (talk) 21:31, 2 January 2023 (UTC)

It absolutely is not a MoS issue as we already have WP:AT which isn't a part of the Manual of Style. Furthermore, there are topic-specific titling guidelines, none of which are in the MoS. This is just another topic specific AT regulation, to say it should be in the Manual of Style when none of the others are and then calling it an "utter waste of time" is not really justifiable. And I'm not saying "this is how it should be done"; you could say that about any policy. I'm suggesting it as a proposal for the way it might be done, and if passed as policy, then yes, it should be done that way. Tim O'Doherty (talk) 22:13, 2 January 2023 (UTC)

• Oppose per all of the abovementioned objections, this is a clear case of a solution in search of a problem. Roger (Dodger67) (talk) 22:32, 2 January 2023 (UTC)
• Oppose. Firstly this does not need to be a policy - if there is a problem that needs solving (and I'm not convinced there is) then a naming convention is the way to go. Secondly, there is almost never a good reason for a policy to prohibit all exceptions and require absolute conformity (WP:CSD is the only one not dealing with legal issues I can think of). Thirdly, even if there was a problem that needed solving, required a policy to solve it, and required there to be no exceptions to that policy, this proposal would not (per pretty much everyone above) solve it. Thryduulf (talk) 10:19, 3 January 2023 (UTC)
• Oppose. I don't see anything wrong with sticking to WP:DAB, for example, Henry VIII is clearly primarily the Henry the Eighth, and Henry III is clearly ambiguous, so gives a disambiguation page, this seems correct and entirely unsurprising to me. If someone wants consistency in a list, for instance, then pipe links are perfectly acceptable for this. (e.g. a list of Kings of England would have Henry II, but a list of Henries would have Henry VIII of England) JeffUK 15:22, 3 January 2023 (UTC) (Struck by me, see below)
• Oppose the unusually harsh absolutism language is completely undone by the growing list of exceptions/clarifications. This will just be used to aggravate editors especially new ones and should not be policy. Slywriter (talk) 22:36, 3 January 2023 (UTC)

  In case you haven't seen, you can view the list of titles here if you are concerned about the "undo[ing] of the proposal. Cordially, Tim O'Doherty (talk) 22:42, 3 January 2023 (UTC)

  That doesn't improve the situation. In fact, it highlights the arbitrary nature of choices. Elizabeth I is Queen of England and Ireland, yet Ireland is dropped. I'm sure there are reasons obvious to proposers but this just seems like a blanket attempt to codify a particular desire, rather than actually improve the encyclopedia. Slywriter (talk) 22:56, 3 January 2023 (UTC)

  Elizabeth I is remembered much more for being Queen of England, then Queen of Ireland. Besides, her being Queen of Ireland is already mentioned in the intro & infobox of her page. So we don't need Ireland mentioned in the article title. She resided in England, not Ireland. GoodDay (talk) 23:01, 3 January 2023 (UTC)

  It's not my choice. Henry VII was Lord (King) of Ireland, and yet he is Henry VII of England. I'm simply making all of the articles consistent with one another. Tim O'Doherty (talk) 23:02, 3 January 2023 (UTC)

• Oppose. Policies should provide general rules on article content, rather than attempting to lay down the law for a single subject. Absolutely no evidence has been offered to demonstrate that there is any specific issue here that requires such exceptionalism. AndyTheGrump (talk) 23:22, 3 January 2023 (UTC)
• Agree (sort of.) I think there is actually a case of Systematic Bias here, and maybe WP:Recentism? If we say, for example, that 'Charles III' is THE 'Charles III', because of course he is, he's the one we see on the telly all the time. That elevates the specific Charles III who's most known in western culture to some higher level than others. I think the suggestion is valid, IF there are other sovereigns who are titled in the same way, we should not have 'primary article' pointing to one of them. For example, there is no other Elizabeth I, so we do not need to be more specific that Elizabeth I. I don't know if this is the problem the proposers were aiming to solve, but I do think it is something worth at least considering. I don't think this should be specific to English/British sovereigns, it should be across the board that multiple sovereigns with the same styling get the same treatment. This is pretty much what Wikipedia:Naming_conventions_(royalty_and_nobility)#Sovereigns says already. JeffUK 10:43, 4 January 2023 (UTC)

  By my reckoning, as the only articles where there is another monarch primarily styled with the same name, only Georges 3,4,5 and 6, and Charles III should be renamed to the styling recommended above (But with deference to the recent move discussion, Charles III should be left alone) and having all the King Georges in the same format does seem eminently sensible.

  Elizabeth I & II, William IV, Queen Victoria, and Edward VII&VIII are entirely unambiguous as sovereigns, so don't need disambiguating. Henry VIII is borderline as there was another Henry VIII who later because king, but I think he was the 8th Duke, and 4th King... so probably Henry VIII stays too. JeffUK 12:39, 4 January 2023 (UTC)

  @JeffUK I'm confused as you partially contradict yourself (Charles III should be renamed ... Charles III should be left alone), but you seem to arguing that each article's title should be determined individually (sometimes with reference to other English/British monarchs of the same name) based on their ambiguity with other topics. This is basically the status quo and exactly the opposite of the proposal, which is to establish a single format that every article in the set must follow without regard to other factors like primary topic or (lack of) ambiguity. Thryduulf (talk) 12:54, 4 January 2023 (UTC)

  Yes, hence the 'Sort of'. I'm ignoring the way it's been worded and focusing on the intent; I do find some merit in more strongly suggesting (Maybe in the naming convention) that articles are titled using the normal format if there are other sovereigns with the same style, even if they are less well known. There should, as always, be no absolutes. JeffUK 14:45, 4 January 2023 (UTC)

  It shouldn't matter if the monarchs are unambiguous. It does no harm to add "of England/of Great Britain/of the United Kingdom". In fact, in most cases, it does quite a lot of good. Tim O'Doherty (talk) 21:41, 4 January 2023 (UTC)

• Oppose: Like the rest of the opposers, I don't see any compelling need for a specific naming convention for a very narrow set of articles to be enshrined in policy. This seems like unnecessary policy creep which would open the door to naming policies on every other narrow set of articles that someone or other gets a bee in their bonnet about. Despite being justified by reference to WP:CONSISTENT and including the phrases "always" and "without exception" in bold in the proposed text, there are already several exceptions enumerated in the text of the proposal; this does not suggest to me a policy which should be enacted without exception, and recent (well-attended!) move requests have clearly come to a consensus which contradicts this proposal, which also suggests that it does not represent community consensus. We already have Wikipedia:Naming conventions (royalty and nobility): if more specific guidelines for UK royalty are really desired, write a supplement to that. Caeciliusinhorto-public (talk) 15:45, 4 January 2023 (UTC)
• Oppose, consistency in following WP:COMMONNAME is more important than consistency between article names. WP:CONSISTENT was boldly changed last year; I have just undone this change and returned to the less prescriptive language that has served us well before. —Kusma (talk) 22:12, 4 January 2023 (UTC)

I undid your change there, as it did't seem to have consensus to be made. GoodDay (talk) 22:28, 4 January 2023 (UTC)

@GoodDay: Please do not revert unless you can give a substantial reason why you disagree with an edit, see WP:DRNC. For the record I can see no indication of any formal consensus for the edit I reverted, either, and I disagree with it because foolish consistency is something that Wikipedia has been good at wisely avoiding for 20 years. —Kusma (talk) 22:38, 4 January 2023 (UTC)

I reverted you, because the change had been in place for quite sometime. Your (today) alterations appeared as an attempt to influence the discussion 'here'. It just doesn't look good, to make alterations on a related page, in the middle of a Village Pump RFC. GoodDay (talk) 22:42, 4 January 2023 (UTC)

That's why I was very open about making this revert. But perhaps this discussion can serve as a counterpoint to the edit I reverted and you reinstated. —Kusma (talk) 09:09, 5 January 2023 (UTC)

There is nothing foolish about consistency. If you or I had a physical, paper and ink encyclopedia in front of us, then all the titles of the entries there would be consistent with one another: not have arbitrary and random inconsistencies between them. Tim O'Doherty (talk) 22:58, 4 January 2023 (UTC)

The real world has arbitrary and random inconsistencies in it. Names of Chinese people, for example, are sometimes commonly written in Chinese order, sometimes in Western order (consider Ang Lee versus Wong Kar-wai for two people in the same category of "film directors"). Enforcing consistency there would just make our article titles unrecognisable. Of course consistency is nice, but not if it leads to article names that nobody in the real world uses. —Kusma (talk) 09:06, 5 January 2023 (UTC)

I do not believe that Chinese names in the Chinese/Western order is analogous to this. Sure, some Chinese people may be better known by the name put one way or the other, and I am not arguing for or against the use of either. However, the consistency proposed here makes article titles more recognisable. I defy you to look at any of the titles here and say that they are unrecognisable. Tim O'Doherty (talk) 16:39, 5 January 2023 (UTC)

They aren't unrecognisable but the consistency you favour makes some of them less recognisable (not more as you claim), particularly Queen Victoria → Victoria, Queen of the United Kingdom. The real world being messy and inconsistent, partly due to the regnal titles being inconsistent (and your list being inconsistent and using the full area for some but only a partial one for others really doesn't help that), and so the common names (which are the most recognisable by definition) are messy and inconsistent. Thryduulf (talk) 17:19, 5 January 2023 (UTC)

But, as the proposal says, the common names shouldn't matter in this very narrow, isolated instance. Victoria, Queen of the United Kingdom provides all the information of Queen Victoria and more: she was a Queen, of the United Kingdom, called Victoria. And the point of only using the "partial" area: that does not make the titles inconsistent. I can't very well have "Henry VII of England, France and Ireland" or "Elizabeth II of the United Kingdom and Commonwealth realms". While the titles may not include every single country they ever ruled over, a.) if they did, they would be less, not more consistent, b.) too long, and c.) unrecognisable and impractical for the everyday user. Tim O'Doherty (talk) 17:31, 5 January 2023 (UTC)

The goal of the article title is not to provide information, it is to identify the topic of the article. Consistency is only beneficial if it aids this goal, which is why WP:COMMONNAME is the ruling factor and we don't make titles longer than they need to be. Your proposal does say that the common name shouldn't matter in this instance, but none of your justifications for why it shouldn't matter have convinced me (or pretty much anyone else) that this is beneficial to the project, let alone that it needs to be a policy more rigid than almost any other.

Yes, using every single country would make the titles too long and less recognisable (but not unrecognisable) but they would be more consistent than your proposal which sometimes uses all and sometimes uses a subset - which is only a problem if your goal is consistency. Thryduulf (talk) 19:40, 5 January 2023 (UTC)

Maybe a good idea, but a bad idea to make a mere good idea mandatory. And unthinkable to make a policy dedicated to this. Sincerely, North8000 (talk) 19:48, 5 January 2023 (UTC)

• Oppose and Alternative proposal: All time-wasting renaming proposals for British monarchs should be forbidden from now until the end of time. Johnbod (talk) 23:16, 5 January 2023 (UTC)

  Oppose alternative proposal. Tim O'Doherty (talk) 23:33, 5 January 2023 (UTC)

• Oppose Because this is a foolish consistency. WP:COMMONNAME should be the more important principle in this case. --Jayron32 14:47, 6 January 2023 (UTC)
• Oppose This proposal attempts to fix what isn't broken. I restate the concerns I expressed in questions above, including that it attempts to reverse a RM on Charles III that failed overwhelmingly and thus expresses a recent consensus. This seems a good candidate for a close per WP:SNOW.--Wehwalt (talk) 15:32, 6 January 2023 (UTC)

Withdrawn by nominator It is clear now that this proposal will not become policy; therefore, I withdraw the proposal myself as the nominator per WP:SNOW. I may one day write a "softer" version as just another standard naming convention that will have to be re-submitted after a time sufficient to make sure there will be a new consensus, but that time is clearly not now. I accept the results of the RfC, and I thank all participants involved, whether they agreed with me or not. Cordially, Tim O'Doherty (talk) 19:41, 6 January 2023 (UTC)

• Oppose for the numerous reasons mentioned. Graham (talk) 20:44, 16 January 2023 (UTC)

  It's been withdrawn. Tim O'Doherty (talk) 21:14, 24 January 2023 (UTC)

Font size of the show/hide buttons in Template:Collapse and Template:Collapse top

I'd like to increase the font size of the [show]/[hide] buttons in Template:Collapse and Template:Collapse top to the same size as their title text. It is currently smaller than usual, which also causes it to be vertically misaligned. I filed an edit request first but folks thought this required discussion.

For reference, the templates:

Collapse

Collapse top

Matma Rex talk 09:46, 24 January 2023 (UTC)

@Matma Rex they look vertically aligned to me, how are they off? — xaosflux ^Talk 11:19, 24 January 2023 (UTC)

@Xaosflux On my screen there is significantly more space below the buttons than above them: https://phabricator.wikimedia.org/F36457042 Matma Rex talk 11:32, 24 January 2023 (UTC)

@Matma Rex it looks like there isn't an equal size above and below the text line in the entire horizontal element, notice more space under the letters than above them here - are you sure this a font-size issue and not the 2em manual padding that is only on the top of the block? — xaosflux ^Talk 14:59, 24 January 2023 (UTC)

@Xaosflux I mean… you're saying that there are other ways to adjust this, and I don't disagree, but this is the one I like the most. Matma Rex talk 15:22, 24 January 2023 (UTC)

@Matma Rex no I was suggesting that the entire text line is not vertically aligned in the box, regardless of the font size - the 100% size text is also not vertically aligned. — xaosflux ^Talk 15:26, 24 January 2023 (UTC)

I don't see a vertical difference in Vector 2010 in my browser. Is this skin-dependent? Does it happen only in the beta Vector 2022 skin, which is still going through various tweaks to fix font sizes, white space, and other significant display bugs? The font sizes in these templates have been the same for at least seven years, maybe more than twelve years, and the templates are used on more than 50,000 pages, so any changes should be for a good reason. I welcome details on the conditions under which this misalignment happens, and changes in the sandbox along with testcases that show better alignment using the same font sizes. – Jonesey95 (talk) 15:32, 24 January 2023 (UTC)

I think it depends on what you're looking at. If you look at phab:F36487116, you can see that the baseline of the "Collapse" title and the square brackets are aligned, but the baseline of the word "show" is elevated. The tops all look vertically aligned. Whatamidoing (WMF) (talk) 23:16, 24 January 2023 (UTC)

Thanks for the detailed screen shot. This shows that the outer brackets appear to be on the same line as the "Collapse" title, which makes sense, and that the word "show" is centered within the brackets, which also makes sense. – Jonesey95 (talk) 05:26, 26 January 2023 (UTC)

Borgward on Boarisch Wikipedia

Hi dear Wikipedia users and admins!

I have a request. I want from someone to create Borgward article on Boarisch (Bavarian) Wikipedia Borgward. It has been created many times there, but it was deleted with unspecific reasons. I would like to see this article there, so anyone who understand this language and requests the article to be kept there and not to be deleted anymore, please do it for me.

Thanks 188.172.109.176 (talk) 22:14, 27 January 2023 (UTC)

Please note that the various language versions of Wikipedia are independent projects. Each has unique rules about what is and is not accepted as an article. We here at the English version have no say over what is accepted at the German version. In other words, you are complaining at the wrong place. We can not help you. Blueboar (talk) 22:24, 27 January 2023 (UTC)

While what Blueboar said is true, I want to make it clear that "but it was deleted with unspecific reasons" was misleading. The article was removed as it was a problematic machine translation from an article on one of the different versions of Wikipedia. For the English Wikipedia, there is a policy called WP:MACHINETRANSLATION that explains the problems with articles that are machine translated into English. I would say that the German Wikipedia likely has an comparable policy. --Super Goku V (talk) 17:05, 29 January 2023 (UTC)

Migrating inline references to a separate 'References' space

It would be very beneficial to editors if inline references could be migrated to a separate 'References' space (possibly for storage in WikiData). Here's a few benefits:

• Frequent bot edits of references would no longer choke up our watchlist and bury potential vandalism.
• Edits of an article wouldn't be hampered by masses of inline references, making the job of editing text more difficult. All there would be are standardized reference identifier tags, possibly with modifiers such as page ranges.
• There would be no need to edit the entire article to add a named reference at the bottom. That would reduce the number of edit collisions.
• Reference edits could be converted to an input form, rather than requiring arcane knowledge of various templates.
• Article reference format could be unified by a single format control at the top, much like the date format is now.
• A large existing Wikipedia library of references would allow convenient re-use, rather than needing to copy a reference over and over.

Just some thoughts. Praemonitus (talk) 17:34, 29 January 2023 (UTC)

Most of the above may be implemented now at the discretion of editors. There is WP:LDR, WP:NAMEDREFS and WP:SFN that cover issues raised above. Visual editing tools also help. The idea that Wikipedia references could be valid Wikidata or data in a Wikipedia Library is a non-starter. Wikipedia references are not formally validated for reliability, contextual integrity or accuracy (occasional informal checks by concerned editors are hardly sufficient). Until such happens as a standard part of referencing/article submission, they are as unreliable as the rest of Wikipedia or Wikidata.

However I agree that edits (including, and especially structured edits such as some of the Wikipedia short and full citation methods) could be best represented by data-input forms. That is however another discussion. 204.19.162.34 (talk) 18:00, 29 January 2023 (UTC)

I already use many of those methods, so I don't see them as a complete solution. But I'm fine with not using WikiData; just have them on a separate page for parallel editing. Praemonitus (talk) 18:54, 29 January 2023 (UTC)

Inline references are generally superior because they don't get out of sync with a separated section as the article is edited. Moving references to Wikidata is a terrible idea - we rely on these citations to meet our core policy burdens, they need to be in the article and a part of the article's editing history. Exporting that to a separate project where they can be separately changed (or vandalized) will cause many problems. MrOllie (talk) 18:26, 29 January 2023 (UTC)

Inline references tend to gum up the works when you want to edit the text. I only find them acceptable in low usage and at the end of paragraphs. Praemonitus (talk) 18:52, 29 January 2023 (UTC)

This is great in theory (I use BibTeX in the real world) but no good on Wikipedia in practice. We used to have {{cite doi}} with citation data stored in subpages but that system was deprecated, and there is a lot of opposition to the Wikidata version {{cite Q}}. Better to keep critical information like citations in the article. —Kusma (talk) 18:48, 29 January 2023 (UTC)

• "There would be no need to edit the entire article to add a named reference at the bottom. That would reduce the number of edit collisions." is wrong. Migrating references to a different location means any additions need two edits, one at the location where the reference is used, and one at the external reflist, doubling the potential chances of "collisions". Regarding your issues regarding wikitext confusion, have you tried using WP:VISUALEDITOR? CMD (talk) 18:08, 31 January 2023 (UTC)

Organize a citation edit-a-thon for WP:Vital articles

I originally raised the edit-a-thon proposal to the WikiProject Vital Articles, but because in combination of the WikiProject's inactivity and that the edit-a-thon would touch on a lot of WikiProject's core articles, I think that the proposal should be seen by a wider Wikipedian community. Editors can add articles that is not in the Vital list, as long as the article is covering a topic just as broad as many of the vital articles listed.

The edit-a-thon would focus on making the information inside Vital articles verifiable, by citing uncited statements, checking cited claims and removing unreliable sources. Once an article is fully cited, a 25% source spotcheck (check 1 source for every 4 sources) will be done before the article is officially marked as complete. The drive should initially work through the list in small 3-5 articles per batch, though this number can change depending on the edit-a-thon's activity.

Here are a fair number of tools and pages that can be used by drive participants to speed up their works:

• Bad source detectors: User:SuperHamster/CiteUnseen, User:Headbomb/unreliable, User:Novem Linguae/Scripts/CiteHighlighter (you can combine CiteUnseen + Headbomb's script, or CiteUnseen + CiteHighlighter)
• Wikipedia:Reliable sources/Perennial sources as a rough indicator of quality
• Wikipedia:The Wikipedia Library for free access to paywalled sources
• Wikipedia:WikiProject Resource Exchange for people to email you paywalled sources
• Help:Find sources for sourcing suggestions

CactiStaccingCrane 15:23, 1 February 2023 (UTC)

Should non-free images be allowed in search results?

 You are invited to join the discussion at Wikipedia talk:Non-free content § Non-free images in search results (redux). {{u|Sdkb}} ^talk 16:06, 2 February 2023 (UTC)

English main page language selection

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

The English main page comes with a new layout. But I was unable to find a link or button to switch to another language. My suggestion: Include a "Select Language" link in the left-hand area that provides this option. 2001:16B8:B3FC:AA00:501A:A217:F853:748B (talk) 09:49, 31 January 2023 (UTC)

Hi, the language switch option has been moved to the end of the main page. —CX Zoom[he/him] ^{(let's talk • {C•X})} 09:59, 31 January 2023 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Further discussion on what to do with the language selector may be warranted on WP:VPIL, since WMF doesn't know either. See phab:T293470 or come talk to me for more details. Izno (talk) 21:21, 4 February 2023 (UTC)

RFC: Vector 2022 and Mobile

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Should Vector 2022 replace Minerva on the mobile English Wikipedia site (en.m.wikipedia.org)? Aasim - Herrscher of Wikis ❄️ 23:00, 2 February 2023 (UTC)

Background

On 18 January 2022, shortly after Wikipedia turned 23 years old, the Vector 2022 skin was turned on for all users on desktop using Vector 2010 and all logged out users. That has garnered a lot of criticism from both logged-in users and logged-out users alike. Some of the criticism is based on design choices like fixed-width, extreme white, simplified icons, and a mobile-like design on desktop. Some of the comments supporting Vector 2022 notice features such as the pinned table-of-contents and buttons, as well as the extensive UX research conducted by the Wikimedia Foundation.

Please note that there is no easy way to change the mobile skin, for logged out readers and logged in readers alike, without using ?useskin=skinname. The V22 skin also still needs more work to remove unnecessary buttons on mobile like the table of contents which does absolutely nothing, as well as the readdition of icons like the edit section icon. Please also note that this is only about mobile and the outcome may have no effect on desktop. To preview what Vector 2022 would look like with the Mobile Frontend enabled, please see this page. You should open the F12 developer tools and click the "toggle device emulation" button to view what the skin will look like on various mobile screen sizes.

RFC: Should Vector 2022 replace Minerva on the mobile English Wikipedia site?

Support

Click here to reply (Discussion tools must be enabled in Preferences):User:Awesome Aasim 23:00, 2 February 2023 (UTC)

Support as nom. The reason I support this is to get mobile users used to Vector 2022 before, in the future, all the tools on desktop like the VisualEditor and the DiscussionTools all work on mobile. The only tools that currently work on mobile properly through the mobile frontend are extremely limited, like a wikitext editor by mobile frontend. It's a slow change to unify the mobile and desktop experience. Very few companies are using dedicated mobile sites anymore, and having a mobile site in search results when you are expecting the desktop view and vice versa can greatly impede the user experience. Aasim - Herrscher of Wikis ❄️ 23:00, 2 February 2023 (UTC)

Oppose

Click here to reply (Discussion tools must be enabled in Preferences):User:Awesome Aasim 23:00, 2 February 2023 (UTC)

Strong oppose. V22 has not been suited for mobile, especially not for phones. The width has a minimum, the pop-ups look weird, weird font sizes everywhere as well as using too much performance and maybe memory. There's also the editor and the abundance of whitespace in v22. Aaron Liu (talk) 01:26, 3 February 2023 (UTC)

Oppose – I quickly pulled up Vector 2022 on my phone, and it's clear that it is not designed for mobile in its current state. The page still loads at a desktop width, so the font is tiny and there is minimal responsive design (i.e., the TOC still takes up space on the left). Moreover, without any indication from the WMF that they intend to support Vector 2022 as a mobile skin, I don't think it's worth attempting the change by ourselves. RunningTiger123 (talk) 06:02, 3 February 2023 (UTC)

Neutral

Click here to reply (Discussion tools must be enabled in Preferences):User:Awesome Aasim 23:00, 2 February 2023 (UTC)

• Don't care, but am annoyed that such relatively inconsequential matters are placed on a central noticeboard, instead of serious, long-standing issues such as the years-old bugs that prevent mobile users from receiving notifications or the VE numeric ref names issue, which, imho, are way more important to the project in the long run, than this purely cosmetic, I-like-blue-but-you-like-green sort of issue. Putting on my (rarely used) curmudgeon hat, I recommend a procedural close, and a WP:TROUT to those who thought it was worth spending time on this, rather than on more important things. Mathglot (talk) 23:40, 2 February 2023 (UTC)

  I disagree that the proposal should be procedurally closed at this moment. Was the Vector 2022 skin at all perfect when I suggested that it be deployed? Of course not. Some of the major bugs could have quick fixes right now such as removing the ToC button while using Vector 2022 Mobile Frontend, but long-term should really focus IMHO unifying the mobile and desktop site so that mobile users have access to desktop tools, and vice versa. Aasim - Herrscher of Wikis ❄️ 00:39, 3 February 2023 (UTC)

  These aren't things that lack consensus. There is consensus to do so but it has not been done and this isn't about wiki configuration. I'm also pretty sure it falls under WP:CONEXCEPT Aaron Liu (talk) 01:27, 3 February 2023 (UTC)

RFC Discussion

Why here?

I was told on WP:VPIL that it would be best to create it on the village pump proposals rather than on Wikipedia:Requests for comment/Rollback of Vector 2022. If you think this should go somewhere else such as a new page or a subsection of this mentioned RfC please feel free to move it. Aasim - Herrscher of Wikis ❄️ 23:00, 2 February 2023 (UTC)

Proposal is premature

The Vector 2022 skin has not been designed for use on mobile devices, thus it's too soon to discuss changing the default skin for the mobile site. isaacl (talk) 23:25, 2 February 2023 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Incorrect date above?

The RFC just above here says "On 18 January 2022, shortly after ..." Isn't that year wrong? David10244 (talk) 07:25, 4 February 2023 (UTC)

Yes, but that's kind of irrelevant for a closed proposal... Izno (talk) 21:19, 4 February 2023 (UTC)

I want to figure out what would I need to do if I want to reopen this proposal in the future? It might have been a case of Wikipedia:TOOSOON. Maybe when WMF adapts the Vector 2022 skin to Mobile Frontend this can be reopened. Aasim - Herrscher of Wikis ❄️ 16:58, 7 February 2023 (UTC)

When you can actually use it like Minerva on a phone, yes. Aaron Liu (talk) 17:02, 7 February 2023 (UTC)

Wikidata lists

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

(non-admin closure) There is no consensus to permit the use of wikidata lists in article text at this time change the consensus status quo treatment of wikidata lists. Andre🚐 03:52, 1 February 2023 (UTC) (clarify that I am not finding a consensus to blanket ban or to endorse, but no consensus to expressly permit anything that isn't already permissible.) Andre🚐 23:37, 1 February 2023 (UTC)

---

Should mainspace lists where the contents are pulled from and maintained at Wikidata be allowed or disallowed? Fram (talk) 07:25, 19 September 2022 (UTC) (edited same day at 13.35, see start of discussion section)

Summary (Fram)

There are a number of lists where the contents are pulled from Wikidata through Template:wdtable row, with specific subtemplates for different types of content. The result can be seen e.g. here. The Wikipedia-only version of the same list can be seen here. Previous RfCs (see Wikipedia:Wikidata#Appropriate usage in articles have already agreed that "Wikidata should not be linked to within the body of the article except in the manner of hidden comment" and that it is "not appropriate to use Wikidata in article text on English Wikipedia ", but allowing Wikidata in infoboxes and de facto also many in external links templates. Previous lists where not only the contents, but even the entries were Wikidata driven have been disallowed in the mainspace as well.

The new type of lists has a number of disadvantages compared to enwiki-based lists, i.e.

• it isn't maintainable here but requires going to another website with another interface, making it harder for most people (for the data)
• requires editing templates or creating new ones for the layout
• Has issues with e.g. sorting, see for example here where (with the current Wikidata data) sorting on the "opened" column gives a random "Apr 1998" data inbetween the blank dates, and sorts "17 Apr 1968" before 1917 and so on. This example shows also a typical issue with getting data from Wikidata like this, the formatting. Wikidata has "April 1998", so I suppose the "Apr 1998" entry is formatted in a template. This makes it again harder for regular editors to maintain or layout such articles.
• Similarly, at Talk:List of dams in Saga Prefecture an editor asked to remove the image column from the article, as they were unable to do this under the Wikidata format. This required the creation of a new template, instead of simply editing the article. Fram (talk) 07:41, 19 September 2022 (UTC)
• There are other more minor issues, like the name appearing in the list being the Wikidata label, not the enwiki article name, or the sourcing being inadequate (Wikidata items referenced to some Wikipedia version, often outdated (e.g. some of the entries on List of islands of the Isles of Scilly use the 2001 census instead of the 2011 census our articles use, indicating the glacial speed of update Wikidata often has) Fram (talk) 09:03, 19 September 2022 (UTC)
• See for example List of learned societies in Australia, with issues from the start (e.g. one entry with the incorrect Wikidata title instead of the correct enwiki title, and entries which don't even belong there like the Austronesian Formal Linguistics Association), and then made worse by an editor who probably couldn't figure out how to correctly add an entry[2]. This type of list is not editor-friendly at all. Fram (talk) 12:38, 19 September 2022 (UTC)

Summary (MSGJ)

Thank you for starting this discussion and inviting me to present an alternative viewpoint. First, some background for those who may not be familiar with Wikidata. This Wikimedia sister project, launched in 2012, is designed to hold data for use by Wikipedias and other sister projects. Its use on the English Wikipedia is not at all new - it has been used extensively in infobox templates for many years now - so its use in data tables and lists should not be surprising to Wikipedia editors. I really thought and hoped that the "us and them" attitude towards Wikipedia and Wikidata had diminished over the years.

Being designed for this purpose, Wkidata offers many advantages over conventional wikitext for storing reliable data, including:

• Numerous constraints which can catch incorrect data, such as incorrect units, a date of death before a date of birth, etc.
• A very user-friendly interface (almost certainly easier than editing wikitext for new editors). For example, compare how you would update the height of a dam on wikitext version compared with on Wikidata.
• Ability to use powerful queries to find information.
• And probably most importantly, improvements to the data by one project will be of benefit to all projects.

All data on Wikidata can (and should) be referenced, just as it is on Wikipedia. All changes can be monitored via RecentChanges (if you have the appropriate option selected).

The use of a template to produce the rows of the table has several advantages, including:

• The template allows any column to be overridden by locally defined content. For example on List of Welsh mathematicians the "Notes" column is entirely local content.
• The wikicode to produce rows and columns, which is complex for many editors, is conveniently separated from the content of the table.
• A column can be added or removed from the table by making a single change to the template, rather than dozens of changes to the wikitext.
• The pencil icon links straight to where the data is stored.

Finally, a word on the previous discussions about the use of Wikidata on Wikipedia. A table is not classed as "article text" so the prohibition on using Wikidata for article text is not relevant here. And, regarding the linking to Wikidata, the only link is the pencil icon mentioned earlier which is widely used and accepted in infobox templates. — Martin (MSGJ · talk) 17:04, 19 September 2022 (UTC)

Discussion (Wikidata lists)

• @Fram: Two things: this is asking whether they're allowed, not whether they should be allowed. Is this about getting clarity of where past decisions have landed us, or deciding whether they should be allowed? If it's really just asking whether they're allowed, the list of reasons why they're bad seems out of place. If it's asking whether they should be allowed, you may want to edit the initial statement. The other suggestion is sort of dependent on the first, but you may want to separate the summary of where consensus stands from specific arguments about what our policy should be. The latter isn't so much a summary as arguments supporting one outcome. — Rhododendrites ^talk \\ 13:00, 19 September 2022 (UTC)
  • Well, it's kind of a double question; are they allowed viz-a-viz the previous RfCs, and should they be allowed or not? I guess the second is more important than the first, as it's not intended as a "you did something that wasn't allowed" but more of a "this is how we'll proceed from now on". I'll change the RfC accordingly. Fram (talk) 13:35, 19 September 2022 (UTC)
• Initial thoughts (should I be creating my own section per above?): I have mixed feelings about Wikidata lists. On the bad side: technical limitations. Some of the things Fram lists seem like they could be fixable, but for others it's a matter of better integration of Wikidata in Wikipedia (in the sense of editing). The current templates, which send would-be editors to a Wikidata page with no explanation, are a bit clumsy (but, granted, an early step in the process). On the good side: I can see at least two good uses for Wikidata in Wikipedia lists. The first is as a starting point. If you want to make a lists of dams in a given place, that's something Wikidata has data for, and pulling from Wikidata could save a lot of time vs. hunting it down and formatting it yourself. Then you could convert it to wikitext and move on. I don't expect that's very controversial, though. The second case is when Wikidata pulls from databases that are more easily kept up-to-date than a Wikipedia list. We have an awful lot of out-of-date lists, and if it's an appropriate topic, why not let Wikidata gnomes keep it up to date? We just need more sophisticated templates to allow for flexibility in display and for fixing errors without sending someone on a journey to Wikidata. So I guess part of my answer (although per above I'm not sure which question I'm answering) is: yes, at some point these are useful, and I'd encourage people to shift the discussion from a binary yes/no to figuring out (a) in what contexts they're useful, and (b) if the current setup is inadequate, what changes to the interface and/or templates would be needed to ensure we can take advantage of this data in those cases when it's useful? — Rhododendrites ^talk \\ 13:23, 19 September 2022 (UTC)

  Thanks for this very astute comment. I will happily admit that the template can be improved (e.g. sorting on dates which is mentioned earlier), and any suggestions will be much appreciated — Martin (MSGJ · talk) 18:07, 19 September 2022 (UTC)

  Rhododendrites I agree. If we have concerns about referencing, then use reputatable source checker to confirm them and colour/flag them differently (red = dodgy etc).If we want to see who did the edit change in Wikidata then create a combined history search, if they are coi change the colour.

  WIkidata would be useful for

  • Detecting scam/bankrupt smaller companies/pheonix - they are better setup for receiving feeds from regulators/credit agencies
  • Structured validated data in infoboxes: we could get rid of categories, and instead have a search based on the infobox.
  • Allowing readers to view chnages over time in table data in an article (which would act an an open alternative to statista ) - What were the top 5 exporters of truffle in 1932? Or does Template:Graph:Chart or similar already cater for that?
  • Allowing preferred data formatting in tables to be seperated from validdated data. (Sep rather than Sept, or my bugbear of non date in date fields). Wakelamp d[@-@]b (talk)

  Wakelamp d[@-@]b (talk) 02:40, 22 November 2022 (UTC)

• My understanding from past RFCs is that we continue to be extremely wary of Wikidata, and have limited its use… but that, within those limits, it can be used.

That said, I don’t think we have been very clear as to what exactly those limits ARE. We need to spell them out clearly. Do we have a guideline or policy section covering this? Blueboar (talk) 13:55, 19 September 2022 (UTC)

I don't think its specific use in lists/tables has been put to RfC before. The closer of 2013 discussion wrote "There is a valid point raised that while running text is clearly not suitable for Wikidata use, it might be worth discussing use in tables specifically – but no consensus regarding this has been reached in this discussion." — Martin (MSGJ · talk) 18:09, 19 September 2022 (UTC)

• I would think that this is disallowed per the previous RfC, which stated that it is not appropriate to use Wikidata in article text on English Wikipedia. A list article is still an article. I've actually come across some of these lists before and wondered why they were using {{Wdtable row}} instead of {{Wikidata list}}. The presumable reason is that {{Wikidata list}} produces an error when used in mainspace due to the results of that RfC and others. The use of {{Wdtable row}} in mainspace articles strikes me as a clumsy workaround to skirt consensus. Spicy (talk) 16:31, 19 September 2022 (UTC)

  Yes, a list is an article but the values in a table are not "article text", which I take to mean prose. Some tables combine values and prose, e.g. List of Welsh mathematicians, and the template will only produce the content for the values and not for the prose. — Martin (MSGJ · talk) 18:12, 19 September 2022 (UTC)

• I'm of a mind that we shouldn't encourage them, and don't personally use them, but if someone wants to put together say a rather exhausting list of plant species or something, Wikidata may simplify the process. If someone finds a clever way to use them, why stop them? I agree with Rhododendrites that we should focus on where they're best used and how to improve their usage. CaptainEek ^{Edits Ho Cap'n!}⚓ 16:54, 19 September 2022 (UTC)
• I agree with Rhododendrites - tables pulled from Wikidata are suitable for some uses and not from others. Where they are suitable I see no justification for either prohibiting or requiring their use (treat it like ENGVAR or citation styles: either version is acceptable, don't change without both a good reason and consensus). Where they aren't suitable obviously they shouldn't be used, but I hope nobody is advocating for that. We should work on making the integration better so that the problems identified are fixed rather than saying the first version is not perfect so go away and never come back again. I also suggest that developing a set of guidelines about where Wikidata tables are and are not appropriate for use to be a much better use of editors' time than arguing about whether they should or should not be used at all. Thryduulf (talk) 22:30, 19 September 2022 (UTC)
• In theory, I'm fairly open to tables containing entries from Wikidata. In practice, I'd like to see more working and non-working examples. I think there are a few other language Wikipedias with deeper Wikidata integration, but perhaps I am mistaken and that is all just infoboxes. There are also a lot of things where information is rather fuzzy, making Wikidata difficult to use. It is easy to annotate uncertain dates and debates around them in wikitext; learning how to do that on Wikidata is rather hard and certainly unintuitive for people used to Wikipedia. —Kusma (talk) 08:18, 20 September 2022 (UTC)

  Thanks for your comment. I am of the opinion that only a clear-cut value can be appropriately used from Wikidata. Anything which requires clarification or explanation should be locally defined. There are a couple of approaches I have used in these cases.

  • For example on List of castles in Ireland#County Clare, the imprecise build date of Ballyhannon Castle is locally specified via |c5=c. [[1490 in Ireland|1490]]<ref>{{harvp|Westropp|1899|p=351}}</ref>
  • And on List of lighthouses in Scotland, I clarified the build date of Southerness Lighthouse by adding a footnote to the value from Wikidata via |c5+={{efn|Built in 1748 but not lit till 1800. Rebuilt in 1844.}}

  — Martin (MSGJ · talk) 16:01, 21 September 2022 (UTC)

• I'll perhaps expand on my rationale later, but fundamentally, I support Wikidata-derived tables being allowed. It all comes down to implementation — if done well, the appearance to readers will be exactly the same as a manually generated article, and the Wikidata-derived one will be far more future-proof. {{u|Sdkb}} ^talk 06:03, 21 September 2022 (UTC)
• The only argument presented by people in favor of using Wikidata continuously (as opposed to using it once to generate a list) seems to be making things easier to keep up to date. But most uses of Module:Wikidata table are timeless: lists of dams, lighthouses, and castles, etc. don't need much updating (other than adding new entries if they are built, which still needs to be done manually in the Wikidata version), so in those cases that argument is not convincing. On the contrary, there's been no refutation to several of Fram's points above which amount to the fact that it will almost always be possible to further optimize such a list with local tweaks because humans are better at this then co. So what's the harm in detaching from Wikidata and letting that be done? I'm not seeing it.
  For the few that aren't timeless (List of Brazilian mathematicians, List of Welsh mathematicians and List of Polish mathematicians seem to be the only ones), there is a slightly better case for using Wikidata, and I haven't come to a strong opinion either way. * Pppery * _{it has begun...} 17:43, 21 September 2022 (UTC)

  For me it is not only about the creation of the lists, but the future updates and improvements too. I do not expect these lists to stay the same for ever more - I really hope they will be expanded with more information and better references. I believe this is both easier and better in the Wikidata version. Easier, because of the structured environment which lends itself to data import and verification. Better, because the knowledge will be shared among all language Wikipedias. — Martin (MSGJ · talk) 19:19, 29 September 2022 (UTC)

• I would have thought the prohibition applied to lists and tables as well, but if that's not the consensus I would support extending the prohibition to lists and tables. No problem with using Wikidata to initially populate a table or list, of course; the onus is on the editor to make sure it's reliable data as with any edit. The problem of "sneaky vandalism", as I think Fram named it years ago, is real -- changes to Wikidata are not easily visible which means you may not know when your article has been vandalized, and even if it's detected a user who can edit here may be unable or unwilling to learn the quite different interface there. Re Rhododendrites' comment that it would be OK to have a table sourced to live Wikidata, knowing that the gnomes over there would keep it up to date -- I don't think anyone would be OK without outsourcing our table data to, say, Fishbase, for certain tables, so why would we be OK with it with an intermediary? Mike Christie (talk - contribs - library) 22:40, 21 September 2022 (UTC)

  Sneaky vandalism is a problem that can occur with any type of list. With watchlist integration, while not perfect, I can effectively patrol all changes to data which affect these articles. So I do not really accept that changes on Wikidata are invisible or hard to catcher than on Wikipedia. — Martin (MSGJ · talk) 19:23, 29 September 2022 (UTC)

  When I last tried "Show Wikidata edits in your watchlist" it added an incredible amount of noise that made the watchlist unusable. Has that changed? Johnuniq (talk) 01:25, 30 September 2022 (UTC)

  Yes, a couple of years ago. WMDE did the work, so it's probably documented at Meta-Wiki. The volume and relevance of notified changes seems to depend on the subjects that you're watching, so I suggest trying it out and seeing what you think for yourself/your own subjects. I feel like volunteer-me gets a surprisingly large number of notifications for Apology (act) and Apologia, but less than I expect for other subjects, like Lymphoma. Most of the changes I see are changes to the linked articles (e.g., someone creating an article at another language's Wikipedia about lymphoma). Whatamidoing (WMF) (talk) 22:32, 30 September 2022 (UTC)

  It's probably fair to say that there are still too many entries that make it through the filter. I don't need to know when someone changes the Bangladeshi label or adds a sitelink to the Hebrew Wikipedia. Really the only ones needed are those which affect the display of the relevant article, although an option to display all changes might be useful for some editors. — Martin (MSGJ · talk) 14:34, 1 October 2022 (UTC)

• Question, if I wish to change or amend something in a table that uses Wikidata to generate info, would I have to go to Wikidata to make the edit, or can it be done using the edit mode here in WP? Say something simple like a style correction. Blueboar (talk) 01:46, 30 September 2022 (UTC)

  Taking the eventualist view, with future interface improvements, yes, you'll be able to stay on Wikipedia. Also, it's worth noting that tables generated through Wikidata are less likely to have errors to begin with because there are fewer elements being created manually. {{u|Sdkb}} ^talk 03:47, 30 September 2022 (UTC)

  So your "yes, you'll be able to stay on Wikipedia" is actually a "no". Deciding on the current status of such lists based on what might happen one day, perhaps (Wikidata is 9 years old, so it's not as if such changes happen rapidly) is not a good idea. So, @Blueboar: you indeed have to go to Wikidata to edit the info, Wikipedia edit mode won't help you. And Sdkb, your "less likely to have errors" doesn't seem to make much sense either, the elements are created manually at Wikidata or manually at enwiki, no reason why one would be less likely to have errors (on the one hand, Wikipedia has more editors and thus more vandals: on the other hand, vandalism on Wikidata is much more likely to stay undetected, see e.g. here where it took a full month until someone noticed that the page "Punjabi" had been moved (retitled) to "josh saunders", or here where it took more than a month for someone to notice that "Aaron Ramsey" was moved to "Penalty in the UEL final". Fram (talk) 07:37, 30 September 2022 (UTC)

  The reason Wikidata-derived tables have fewer errors is that, when you're adding a row through Wikipedia, you need to add both the data and the formatting, and each of those is a potential spot to mess up. I'm sure we've all seen tables that have an extra column used only in one row because someone put an extra "|-". When you're adding information on Wikidata, however, all you have to worry about is the data. And even there, constraint violations can help identify errors that Wikipedia would not have been able to flag, and data imports can help a single experienced editor add large amounts of high-quality information (rather than relying on piecemeal contributions by many different editors, any one of whom might mess up). {{u|Sdkb}} ^talk 15:26, 3 October 2022 (UTC)

  That's a rather anti-wiki position you take there. "relying on piecemeal contributions by many different editors" is what makes Wikipedia, and excluding these editors from pages is a good argument against Wikidata lists, not for them. (Never mind the countless times experienced editors made completely incorrect or botched mass updates of info on Wikidata of course). Fram (talk) 16:07, 3 October 2022 (UTC)

  I'm absolutely a fan of crowdsourced editing or I wouldn't be a Wikipedian. What I'm not for is forcing information that can be more efficiently handled in bulk to be handled piecemeal. That's why I oppose the wholesale deletion of template namespace, and also why I support the use of Wikidata. Neither of those things make me anti-wiki. Regarding the potential for errors in Wikidata imports, that potential exists in normal editing, too. I think the anti-wiki position would be to say that we should prohibit a type of editing entirely just because it's not done properly 100% of the time. {{u|Sdkb}} ^talk 18:18, 3 October 2022 (UTC)

  the wholesale deletion of template namespace Strewth!! Was that actually proposed? When? — GhostInTheMachine ^{talk to me} 19:15, 3 October 2022 (UTC)

  I'm using it as a hyperbolic analogy here, but there are certainly examples of resistance to template usage for things like census data that I'd say fall at a milder point along the same spectrum. {{u|Sdkb}} ^talk 20:54, 3 October 2022 (UTC)

  And in at least one proposal to implement a list from Wikidata that I examined, the one list of items here would have been replaced with code that got items from dozens of different pages at Wikidata. In other words, the attack surface for vandalism would have been multiplied dozens of times, and manual checking of Wikidata items would have been dozens of times more difficult than looking at wikitext here. Johnuniq (talk) 09:12, 30 September 2022 (UTC)

  • If I need to go to WD to edit WP… that is a deal breaker for me. So put me down as still opposed. Blueboar (talk) 11:26, 30 September 2022 (UTC)
• I remain extremely sceptical about the value of using Wikidata directly in articles for anything, although obviously compiling a list/table using Wikidata, and then disassociating it, is completely acceptable. As is using it in project space, and potentially talk pages. It makes editing the content nearly impossible for those not used to Wikidata, and it makes watching the page for changes completely impossible. ETA: For instance, List of Welsh mathematicians, linked above as an example, contains entries with three inline sources for things like date of birth, presumably unnecessary (and if the sources disagree, this should be footnoted), and has abbreviated months, which is not Wikipedia style but can't be edited within the Wikipedia page. The repeated edit links are also obtrusive. Espresso Addict (talk) 05:44, 1 October 2022 (UTC)

  Thanks for your comments.

  1. MOS:DATES suggests that abbreviated dates like 2 Sep 2001 or Sep 2, 2001 are acceptable in tables. I think the full unabbreviated dates would take up too much space in most tables.
  2. Do you have any suggestions to make the edit links less obtrusive? They are necessary to allow editors to change the values, but are only currently visible to logged in users.
  3. The maximum number of references is set at 3 and could be reduced further.

  — Martin (MSGJ · talk) 14:32, 1 October 2022 (UTC)

"Sep" as an abbreviation for September looks very odd in UK English, which would appertain to a list of Welsh people. The problem is the lack of easy-to-understand customisation. If I have five sources for a dob, I can choose to include only say no 3 because it is reliable & accessible, or put in two sources because one is highly reliable but not readily accessible, and another less reliable but accessible, &c&c. I have absolutely no idea how to do that within Wikidata, and no desire to have to learn a new and cumbersome editing interface. Also using things like n/a for the death date of a living person feels disrespectful. No clue how to make the edit links less prominent; I dislike them in infoboxes, but there's usually plenty of whitespace there to absorb them. Perhaps if they only showed in edit mode, somehow? And how are logged-out editors supposed to amend things? Espresso Addict (talk) 23:44, 1 October 2022 (UTC)

@Espresso Addict: absolutely. If you are curating a list/table to such a degree then you will almost certainly want to forgo the convenience of the template and gain the greater flexibility. But 99% of lists are not like this, many of which are a bare list of links without additional information or references. For these, the template can produce a nice looking table with more detail, and is more likely to stay up to date. PS I use "Sep" all the time as an abbreviation for September, and it doesn't look odd to me! — Martin (MSGJ · talk) 15:51, 3 October 2022 (UTC)

• Unless it can be altered on ENWP without going to Wikidata, I am in line with the previous consensus that wikidata imported content should not be used in article space except under the very limited exceptions. If it can be amended on ENWP and draw through to Wikidata, all my concerns disappear. Keep in mind those exceptions exist precisely because of the issues with Wikidata, chiefly its another project with its own rules and policies, its own admins, far less active users to combat deliberate vandalism, BLP violations etc. Importing lists that include living people is most BLP-watchers nightmare when you have to go to other projects to rectify it. (The same issues exist with imported commons content but at least thats relatively simple to fix). Being able to alter the content as it displays on ENWP, while on ENWP, without having to go to another project would seem to be something the WMF's tech tech could spend some time & cash doing (hint, its not difficult as anyone who has worked with a data warehouse and multiple databases knows) instead of whatever waste of time they are concentrating on. Only in death does duty end (talk) 16:22, 1 October 2022 (UTC)
• Frankly, I read the spirit of the various RFCs on wikidata as being pretty clearly against their use in making articles - so the claim that a table isn't "article text" and so it is fine to make tables from wikidata ... strikes me as very much a rules-lawyering type of statement. I wish that the proponents of wikidata would quit pushing it in such ways - it doesn't help their "cause". Ealdgyth (talk) 13:29, 3 October 2022 (UTC)

  The past RfCs have explicitly considered Wikidata use in tables and found no consensus on the question, so I'm not sure where you're getting that it goes against their "spirit" other than that you're reading your preferred opinion into them. Your idea of "pushing" can just as easily be flipped: I wish that those who fail to see Wikidata's potential would quit resisting it in such ways. {{u|Sdkb}} ^talk 15:19, 3 October 2022 (UTC)

Its more that we do see the potential ... for abuse. And there needs to be either a strong mitigation or exceptional reason in place to ignore that risk. Which when it comes to wikidata, there rarely is. Only in death does duty end (talk) 16:47, 3 October 2022 (UTC)

Particularly for lists that include BLPs, there is potential for BLP violation going unnoticed; a particularly common form of vandalism is to state a living person is dead, or less malevolently, to believe unreliable sources and assume incorrectly that death has occurred. This happens time and time again, and requires careful oversight. Espresso Addict (talk) 22:13, 3 October 2022 (UTC)

• No, Wikidata has been repeatedly banned from the body of the article. Every time a Wikidata-activist tries to shove Wikidata into the body of the article there is always consensus against it, they can't even get consensus for infoboxes. That's stuck in no-consensus. It appears that the only way to stop the recurring and disruptive creeping rollout-contrary-to-consensus by Wikidata-enthusiasts is to entirely shut off the calls to Wikidata in Wikitext itself. As long as it's available they just keep cooking up new ways to shove it out unilaterally. Alsee (talk) 06:50, 7 October 2022 (UTC)

  Additional note: lists [] are articles, and we have established consensus against linking to Wikidata anywhere in the body of the article. All of this content may be immediately deleted from any list or other article as a consensus action, as these tables massively spam Wikidata links. In theory the templates could be revised to eliminate the Wikidata links, however I hope/believe that the wikidata-enthusiasts here would not be so perverse as to advocate a blatantly broken and blatantly harmful result. It would be practically impossible for ANYONE to edit the page via Wikipedia OR Wikidata, as the wikitext contains nothing but jibberish and there would be no pencil link to edit via Wikidata. Alsee (talk) 19:57, 6 December 2022 (UTC)

• Additional issue: editing of tables like this in Visual Editor is nearly impossible and gives, for the few things it can do, very poor results. I tested this with List of dams in Tochigi Prefecture. Compared to "normal", non-Wikidata lists, here I can only add a new line at the top, not anywhere else in the list, and the result is badly formatted. I don't know if the WD list template can be changed to solve these issues, but if not, I don't think it is acceptable to introduce new things into Wikipedia which are incompatible with Visual Editing (even though I loathe it, it is used by a fair percentage of people and many new editors, and making it impossible for them to edit a type of articles is not anything that should be tolerated). Fram (talk) 10:04, 13 October 2022 (UTC)

  That could be partially mitigated through proper use of TemplateData. {{u|Sdkb}} ^talk 14:06, 13 October 2022 (UTC)

  How so? My remark about the template is not that an editor won't know that they need to add the wikidata template or add a Qnumber, but that even with that information, you can't produce a good result in VE. Perhaps I am missing something, but I don't think Templatedata can solve or even mitigate the underlying technical issue. Fram (talk) 14:26, 13 October 2022 (UTC)

  VisualEditor at this point is capable of doing anything with templates that source editor can do, I believe. Having good TemplateData makes the interface easier for editors. {{u|Sdkb}} ^talk 17:56, 13 October 2022 (UTC)

  Have you actually tested this, e.g. with List of dams in Tochigi Prefecture? Try to add e.g. a new dam in the middle of the list, or to move one of the existing entries up or down. TemplateData won't change anything about this functionality. Fram (talk) 18:32, 13 October 2022 (UTC)

  This is a valid point, and I have made a start on creating TemplateData for this template, which can be observed on List of dams in Tochigi Prefecture. I do not know if rows can be added in different places, but I will seek advice on this. — Martin (MSGJ · talk) 12:08, 14 October 2022 (UTC)

  Thanks. Adding entries anywhere in the list is just one of the issues, you e.g. also can't delete the existing ones, and when you add a new line at the top (using the Wikidata template) it only fills the first cell, instead of filling the table as it should (no idea if this list is exhaustive, I stopped testing after this). Templatedata helps at editing the already existing lines (though not removing them or moving them inside the table), but does nothing to make the editing of the table possible. Just tested again at List of dams in Toyama Prefecture, and the new Templatedata is good (e.g. overriding an existing row label), but no solution to the fundamental issue. Fram (talk) 12:47, 14 October 2022 (UTC)

• Thanks for the interesting discussion. I came here after participating in Wikipedia:Articles for deletion/List of CryEngine games and Category:Video games by game engine, and I was pointing people to here to see if a bigger discussion could be had. However this discussion is interesting with respect to the deletion discussion, as one suggested solution to prevent information being deleted was actually using WikiData to store the information, and not need categories or lists, and for users who are interested they could pull the data out of Wikidata. I've read with interest everyone's positions, and I agree with user User:Rhododendrites and User:CaptainEek. We should absolutely not force people to use them, but if editors use them appropriately that is also fine. I feel that inboxes and tables are good uses. Perhaps *not* inline text *for the moment* - we need to still make Wikipedia useful to casual editors and this is likely a step too far. However a table in the text is fine. With the original RfC being done in 2013 (as noted above), it is likely a good time to revisit the topic. I think we should use structured data in tables to help WP articles, and the benefit is that using it consistently means that updating information in WikiData updates it on all language Wikipedias (?potentially even other wikis such as WikiVoyage). The downside is single point of failure; however also single point of fixing - this may need other policies e.g. only logged in edits on WikiData. However may be better for consistency than some pages in WP where information on the same topic is markedly different as pages have not all be updated simultaneously. The application to lists for data is something I'm equivocal about. I hate a lot of list pages and think they should be better categorised, however there are supporters and detractors to this method of organisation as well. I do not like deleting referenced information, and if there was a way of archiving and easily searching it via WikiData I would be all for that. It would be nice if in future a "WikiData Explorer" page type was created where we could just pass it a search string to autogenerate data so we could get rid of lists. This is one for the future. However in the meantime I think we need to at least try improving our use of structured data - not ban but also not force its use. And if it doesn't work go back to normal tables. I quite like the WikiData sourced list of dams provided by the OP. Out of interest for User:Fram - I looked at the example you gave at List of learned societies in Australia. It was interesting as I think the table is generated by passing individual IDs - my futurist hat btw would be looking at this and saying in future it should be "table = learned society + based in australia -> autogenerate table with these fields". Why is this not a case of taking the ID code pointing to the wikidata entry out of there? This kind of error would also be made if manually creating the table, and isn't a commentary on why not to use wikidata for information. It's more a comment on how if you're not careful incorrect information can be put in any type of table, and what I get out of this is that if we truly passed a query to a database (if we made sure we had properly structured data) the presented information would be "better". Or have I missed the point here? - Master Of Ninja (talk) 07:42, 14 October 2022 (UTC)

  Thanks for sharing your comments.

  • No one is suggesting using data for inline text, and I can't think of a situation when that could be appropriate.
  • The reason that each row of the table is produced seperately is to allow human editors to override the data with locally defined content.
  • I agree completely with your comments on keeping tables updated.
  • There are all sorts of ways to browse Wikidata already, and Wikipedia is not really needed for that. See wikidata:Wikidata:Tools/Visualize data for ideas.
  • I can see the possible benefit, if someone is searching for a list which we do not yet have on Wikipedia, of linking to an automatically generated list. But there would be a lot of technical and policy issues to navigate.

  — Martin (MSGJ · talk) 12:21, 14 October 2022 (UTC)

• Not only does Wikidata have questionable sourcing and verifiability policies not fully compatible with Wikipedia, but I wonder if folks would consider whether it's worth the trouble to make editing list pages even more complicated than they already are? I hate having to jump back and forth between Wikipedia and Wikidata just to manage interwiki links, and it would be an absolute nightmare if it was allowed to make up significant chunks of actual list content. Just say no to more complex articles, so we can focus more on encyclopedic content and less on formatting or template garbage. As for the idea that Wikidata is easier to edit than Wikipedia... I am highly skeptical of this claim, given that I think the average person couldn't even define what a knowledge graph is, much less find out how to add a statement to a Wikidata page. For new and anonymous editors in particular, it is likely extremely confusing to click edit on a cell in a Wikipedia list and then be taken to the read mode of an entirely different website that 99% of our readers have probably never heard of at all. Steven Walling • talk 20:41, 17 October 2022 (UTC)
• On a procedural note: it seems clear from previous RFCs that existing consensus is toward disallowing Wikidata use in articles. It should almost certainly be removed from any existing lists unless and until a new consensus supporting it develops. Steven Walling • talk 21:01, 17 October 2022 (UTC)
• Sorry for late comment but I only just saw this discussion. As an occasional compiler of lists of power stations in non-English speaking countries I support the use of Wikidata in lists. There are often new or retired power stations and keeping such a list up to date in 2 languages is too much work without Wikidata. Chidgk1 (talk) 19:10, 30 October 2022 (UTC)

  But I just looked at the template mentioned and I am pretty sure I will not use it as it seems more work than {{Wikidata list}}. I will just leave the English article out of date unless {{Wikidata list}} is allowed here Chidgk1 (talk) 19:47, 30 October 2022 (UTC) *

  It might be easier for some editors to pull data from WD, but using it in a WP article can make it impossible for other editors to edit.

To share my own experience … I went to WD and simply could not figure out how to edit it. I don’t even understand its basic structure, much less it’s coding. I was completely baffled. The thing is, Wikipedia is supposed to be an encyclopedia that anyone (including me) can edit. When an article pulls data from WD, it means that I simply can not edit that data. That is a fundamental flaw. Blueboar (talk) 19:51, 30 October 2022 (UTC)

This unfortunately is my experience too. The idea of Wikidata seems so good, put having tried to use it the implementation of that idea is terrible. That is aside from the implementation of interfacing in Wikipedia to Wikidata. The chances of a new editor trying to edit a Wikipedia page being aware, let alone able, to edit Wikidata to achieve there edit is zero. I have also struggled with trying to edit Wikidata, and having to do so to fix minor issue is a major headache. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:03, 5 November 2022 (UTC)

• Strongly support allowing the use of Wikidata and {{Wikidata list}} in lists. I'll make my case in the first paragraph, and respond to opposition in the second one.

• Wikidata gives us an enormous advantage: structured data. It'll be highly beneficial to transition more content to Wikidata anyway, thanks to the fantastic meta:Abstract Wikipedia project. It improves verifiability and reliability across Wikipedias (since all data is in one place); allows editors from all languages to contribute to the same database, which automatically gets updated across all Wikipedias (reducing Anglo-centric bias); and will likely help these very low-visibility articles stay "fresh". Using more structured data is vital to reducing our maintainability burden, saves tons of time with adding images and data on separate Wikipedias, and future-proofs the encyclopedia for projects like Abstract Wikipedia.
• Most of the counterarguments I've seen result from current deficiencies in Wikidata. That doesn't mean we shouldn't use it; we should seek to improve it. It's a collaborative Wikimedia project too, not some kind of exogenous imposition. Some Wikidata pages can't be edited by even established editors here, who lack user rights on Wikidata, due to semi-protection; that should be fixed by switching to a "pending changes" or "edit request" model. Wikidata being edited on a separate website, not here, is a good thing, since it makes it clear that people are changing the structured data, not its presentation. I find {{Wikidata list}}s significantly easier to edit. Some criticized Wikidata's verifiability policy, but they're explicitly based on enWiki's guidelines.

I'm only addressing whether Wikidata should be blanket-banned in tables/lists; not whether it should be mandated. Page-specific consensus still reigns; I just don't want the consensns of a few dozen editors here (you gotta concede this is a low-visibility page) to bind our hundred thousand active editors. DFlhb (talk) 09:30, 8 November 2022 (UTC)

Unfortunately the discussions to include also have low participation as well, and of course WP:LOCALCONSENUS. Maybe it's time to have a site wide discussion of somesort. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:45, 8 November 2022 (UTC)

This is a sitewide discussion. * Pppery * _{it has begun...} 17:50, 8 November 2022 (UTC)

Nevermind. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:14, 8 November 2022 (UTC)

• I should start with a disclaimer that I primarily (really, these days *exclusively*) edit on Wikidata and have 200k edits there between me and my bot account. So my comment is not from the perspective of an ENWP editor (although I do read ENWP regularly). That said, I obviously support usage of Wikidata on all Wikipedias, as the Wikidata community - in collaboration with many other WPs including ENWP - has invested a lot of time and energy into collecting a fairly massive depot of data, with citations (though, citations are admittedly somewhat less common in Wikidata vs ENWP currently, sadly) and images. Having the ENWP community and many smaller Wikipedias involved in the collection and validation of the data has been a huge help over the years. It seems that a lot of the concerns here are around tooling and software issues that can ultimately be fixed by improvements to the templates, the Lua scripting tools, and other improvements to the MediaWiki and Wikibase codebases. It'd be a shame to miss out on the ability to optimize list maintenance and leverage data across all language Wikipedias rather than improve the tooling itself. Unfortunately, I admittedly don't have a great solution for getting those improvements to happen short of either convincing WMF folks of its importance or doing it ourselves. Nicereddy (talk) 17:36, 19 November 2022 (UTC)

  Is there any evidence that the existence of Wikidata lists on the English Wikipedia actually inspires people to make useful edits to Wikidata, rather than just give up? * Pppery * _{it has begun...} 17:51, 19 November 2022 (UTC)

  Is there any evidence to suggest the opposite? Nicereddy (talk) 18:18, 19 November 2022 (UTC)

  The fact that people such as Blueboar in this very discussion have complained about being unable to figure out how to make the needed edits to Wikidata is good enough evidence for me. * Pppery * _{it has begun...} 18:21, 19 November 2022 (UTC)

  Yup… as I said above, I took a look at editing WD and quickly became too confused to continue. Quickly gave up. Blueboar (talk) 18:36, 19 November 2022 (UTC)

  More confused than the first time you tried to navigate a template-filled Wikipedia article pre-Visual Editor? The most difficult thing about editing Wikidata is knowing which properties to use. With a list, however, you're typically just working with one or two that have been predefined. I'm curious where the complexity was? (Not saying there can't be a learning curve, but it doesn't seem too advanced for the average Wikipedian. — Rhododendrites ^talk \\ 13:54, 21 November 2022 (UTC)

  I can't reply for Blueboar, but for me, yes, it is very confusing: and comparing it with a "template-filled Wikipedia article" is not really fair. One can easily create an article on Wikipedia, and then start learning the ropes. On Wikidata, the complexity jumps are a lot larger in my view. I just took a link from one of the lists we discuss here, Anthropological Society of Victoria, Wikidata link. When I try to add the year it was founded, I suppose I need to use "inception". So far, sp good. Then add a reference to the year 1934: some properties I can find through gambling, some others I have no idea what they are called so I can't add them. IF I then want another fact from the same reference (e.g. the first chairperson, Henry Gencoult-Smith), then I have to readd the same fields all over again, and I'm rewarded with a pink box around the name because Wikidata doesn't have that name yet. Adding a reference on enwiki is a lot simpler. Then it merged in 1976 with the Archaeological Society of Victoria (A) to form the "Archaeological and Anthropological Society of Victoria" (B). Is this "part of (merged with)"? No, it merged with (A), but this property seems to expect (B). Or was it "merged into"? No, that only applies if (B) had already existed before the merger. And so on, and so on... Fram (talk) 14:21, 21 November 2022 (UTC)

  One can easily create an article on Wikipedia - For a newbie? Without Visual Editor? some others I have no idea what they are called so I can't add them - sort of like Wikipedia categories, or Wikipedia templates, or Wikipedia help pages, or Wikipedia style conventions. then I have to readd the same fields all over again - When you create multiple Wikipedia articles, you do not have to create the same sections, infoboxes, etc. again? rewarded with a pink box around the name because Wikidata doesn't have that name yet like linking to a red link? I'm not trying to pretend as though Wikidata is a delightful and intuitive interface. Figuring things out is a pain, like Wikipedia was for the non-savvy in its early years. Of course, you can just write something on Wikipedia where you can't on Wikidata, but we don't typically take kindly to people just writing something around here these days (unformatted, with the wrong tone, without references, etc.). Wikipedia has a lot more to understand when it comes to rules, conventions, expectations, etc. Wikidata is frustrating for its lack of obvious properties, but that's 90% of what a typical user does on Wikidata -- find/create an item, find a property, insert a value, repeat. I just have a hard time thinking that anyone could put in a tiny fraction of the time it takes to become a savvy Wikipedia playing with/learning to understand Wikidata and still have trouble updating a list. If we expected people to develop data models, propose new properties, and sync up metadata fields while importing a new database, then sure, but updating a list is just a couple simple properties. Would it be better if it were integrated into Wikipedia and more intuitive? Sure, but I just don't see the people slinging nested template parameters and quoting style guides as the "it's too hard to search for a property and insert a value" type. — Rhododendrites ^talk \\ 02:58, 22 November 2022 (UTC)

  The last few times I added/updated properties in Wikidata, as I recall I went down a rabbit hole to ensure that all the corresponding Wikidata items were in place to document the citation. I don't know if this has gotten easier since then. It's a large overhead that has discouraged me from editing Wikidata further. isaacl (talk) 21:07, 19 November 2022 (UTC)

  I have struggled with making Wikidata edits in the past, to the point where I have now given up trying to do so in the future. Loopy30 (talk) 23:23, 19 November 2022 (UTC)

• Unless you can edit Wikidata lists on Enwiki, I'd be against using them in articles. There's this from 2013 that says that local editing is planned, but it's still not a thing nearly a decade later apparently. ♠JCW555 (talk)♠ 18:01, 19 November 2022 (UTC)

  You can't (yet!) edit Wikidata from within Wikipedia - the project is mw:Wikidata Bridge but it seems to have stalled. However the Wikidata item is just one click away from the Wikipedia article. It's a bit like images which are hosted on Commons - they are also one click away. I don't see why this should be a barrier to using Wikidata as we are well accustomed to working with Commons. — Martin (MSGJ · talk) 20:32, 22 November 2022 (UTC)

  I don't do anything with images, so this comparison to Commons isn't applicable to me. Bottom line: I feel like everything on English Wikipedia should be editable on English Wikipedia, including lists and tables. I shouldn't have to go to another site to edit tables/lists on Wikipedia. ♠JCW555 (talk)♠ 20:49, 22 November 2022 (UTC)

• Note: I have nominated Template:Wdtable row for deletion because, whatever one's opinion about Wikidata lists, I don't believe a template which is incompatible with Visual Editor editing should be allowed. All opinions welcome at the TfD of course. Fram (talk) 09:33, 30 November 2022 (UTC)

  Note: The discussion was closed as keep. {{u|Sdkb}} ^talk 03:56, 9 December 2022 (UTC)

• I edit at Wikidata, but I think that making an article solely based on an auto generated list is laziness. An auto generated list might complement an existing article but should not be the sole content of one. My only exception would be if the list was so large it would not fit on the main topic's article page. RPI2026F1 (talk) 03:03, 6 December 2022 (UTC)

  I tend to agree, and yet a "lazy" list is probably better than no list at all, and a maintained list is definitely better than an unmaintained list. The best lists we have tend to combine data and prose. — Martin (MSGJ · talk) 07:25, 6 December 2022 (UTC)

  I never said we should ban lazy lists, I just said they should be merged in with the main topic unless the size of the autogenerated list prevents it from being included in the main topic. RPI2026F1 (talk) 02:17, 9 December 2022 (UTC)

• Strong oppose, As a massive proponent of One version of the truth in real life; I'd love to say I like this idea. But I don't think it will work practically; I have 3 main issues
  • Verifiability. Wikidata has a different value of 'Truth' than Wikipedia. The 'List_of_dams_in_Kanagawa_Prefecture' fails WP:V on face value (no references), and worst of all, it fails WP:V covertly, people will see 'Wikidata' and assume it's right, but if you dig 3 or 4 clicks into the 'reference' you see things like the 'Elevation' of 'Doshi Dam' being 'referenced' to 'Cebuano Wikipedia' (No article link, no 3rd party source) and the height being referenced to the ENW article (and Wikipedia:Wikipedia_is_not_a_reliable_source) . This could be fixed in wikidata with the reference being changed to the original source, but even then, experienced editors will find it hard to see that the data is poorly referenced and have to click each record individually to see the sourcing. Worse, readers looking for the original source so they can validate the information for themselves (as many students are told to do, for example) won't know where to start. Why would they click a 'pencil' to edit something, to find the source?
  • We might not WANT one version of the truth; using wikidata breaks WP:Consensus on content; what if, hypothetically, the editors on wikipedia agree that 'Doshi Dam' is 117 Metres tall, but the WikiData editors disagree? (Or more likely agree on a different definition of 'Height', for example)
  • Using templates breaks the flexibility of the article, editing a template is a massive pain; say we decide by consensus that (random example) 'Dams in the UK' should have a 'Nation' column, it would be impossible for the average visual editor user to make this happen, especially if we want to add facts that aren't on WikiData. JeffUK 15:05, 3 January 2023 (UTC)
    • It's routine to make Wikidata-based templates not include statements that are either unsourced or sourced only to a Wikipedia; this is already done, for example, in {{Infobox person/Wikidata}}. Facts that aren't on Wikidata (though they can and should be added to Wikidata, of course) and those that are at variance with what Wikidata records are also routinely included in Wikidata-based templates; same example applies. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:13, 3 January 2023 (UTC)

      That's less of an issue for single instance things like info boxes though; as it's 'opt-in' per property/parameter; and once a person has a sourced biographical property, it's unlikely to become unsourced. However, if you have lists of things, where some of them have a source for one particular property, and some don't (and new entrants may appear in either state) you either end up with a list page that's missing loads of entries, or someone has to manually fiddle with the wiki markup to hard-code sourced data back in again (then you get some entries which update automatically, and some that don't, which is absolutely the worst possible case), or the editor must go to WikiData to add the information over there and I don't think participation in another site should be mandatory. Either way it's a barrier of entry to editing boldly. JeffUK 19:01, 3 January 2023 (UTC)

  @JeffUK you raise the issue of cross-wiki disagreements, using dam height as a random example. If I may suggest better examples, we seriously do not want cross-wiki warring on things like nationality or gender. I've dealt with more than enough Russians shoving "Jewish" into Nationality fields, and I sure as heck don't want to waste all my time warring with transphobe-majority communities. Alsee (talk) 00:39, 7 January 2023 (UTC)

  So your preferred approach for a project that aims to document all of human knowledge is to shut out non-English speakers because some of them have objectionable views? {{u|Sdkb}} ^talk 06:26, 7 January 2023 (UTC)

  I have no idea where that strawman came from. I said, quote, do not want cross-wiki warring. Cross-wiki warring is especially disruptive. "Non-English speakers with objectionable views" aren't locked out of anything. They are free to argue their case on whatever wiki they actually edit.

  On a related note, I am appalled that the WMF was so clueless and misguided as to deploy the existing Wikidata integration such that Wikidata edits BYPASS/OVERRIDE our local page protections. If an infobox (or anything else) uses Wikidata, a vandal/troll/POVwarrior can defeat our Full-Page-Protection by shoving arbitrary text into a field on Wikidata and purging the linked Wikipedia page. Not only does it bypass page protections, it's impossible for a Non-admin to fix it without going to Wikidata. In other words it is effectively for most editors to fix it at all, because most editors have no idea Wikidata even exists. Alsee (talk) 06:34, 10 January 2023 (UTC)

  That is truly awful. BUT It did make me wonder whether we could do something similar in the other direction as an initial step; make it impossible to change end wikipedia referenced data in Wikidata (protect a section). (Actually, Is that possible to do in wikipedia?)

  All up, the way the different Wiki systems integrate is very unclear at least to me.

  For instance

  * Are there permanent integrations in wikidata to external databases, or is everything a once off?

  * When I look at the references on Wikidata, the top level URL is listed but not the source. I would have expected a recipe/script, and an auto check for updates.

  * There are a lot of items with 0 references if an infobox has no reference for something, does it get created in Wikidata as a 0reference? Can you tell that this has happened

  * If there is conflicting Wiki data between say en and de different wikipedia, which does es choose?

  * If editors are using translation software and dumping it in to their wikipedia, is Wikidata needed? (although machine translated pages that are never updated is another issues) Wakelamp d[@-@]b (talk) 10:13, 10 January 2023 (UTC)

  @Wakelamp,

  • Anything in Wikidata is stored on Wikidata, i.e. the data may have been obtained from an external database at some point, but it will not be automatically updated unless via a bit
  • I'm not sure what you mean by this - as far as I know, references are just a URL
  • Again unclear, but I think you are referring to how data from Infoboxes is exported to WD. Typically the tools for this just say [imported from page foo at oldid bar]
  • If you're referring to the data on WD, it is the same for all languages. If you're referring to importing data, this is done manually (semi-automatically), so a user will choose.

  — Qwerfjkltalk 21:04, 10 January 2023 (UTC)

  One of the differences between MediaWiki (the software behind Wikipedia, largely developed by the WMF) and Wikibase (the software behind Wikidata, largely not developed by the WMF) is that Wikidata entries can have multiple answers for the same point. To use the example started by @JeffUK, Wikidata can simultaneously say that the height of Doshi Dam is 177 m, 194 yd, 600 ft, and 175 m, with separate sources cited for each number, and an editor-chosen priority level for which one (if any) should be preferred. It is not necessary to have only one version of "the truth" in Wikidata; you can instead choose which one you believe is most relevant. Whatamidoing (WMF) (talk) 22:55, 11 January 2023 (UTC)

  Of course, this doesn't solve the problem, as the template has to decide which of the multiple conflicting sources of truth to show (or show all of them). The module being discussed here seems to do the latter approach, which may not be what is wanted locally. * Pppery * _{it has begun...} 01:33, 12 January 2023 (UTC)

  @Alsee, surely the is like templates, even if most editors are less familiar with it. I don't think it's within the WMF's responsibility to decide who this is used in articles - this can be done locally. — Qwerfjkltalk 20:57, 10 January 2023 (UTC)

• My concerns have already been brought up repeatedly above, but I oppose the creeping in of content that fundamentally cannot be verified and edited on Wikipedia. Wikidata might be more user friendly in isolation, but it's not on Wikipedia, which makes it extremely user-hostile. The use of WikiData has absolutely crept past community accepted bounds and should be reined in. Der Wohltemperierte Fuchs ^talk 01:26, 12 January 2023 (UTC)

Poor tooling

The arguments here are transferable to a number of other sister projects, like Commons, which suffer from many more problems than enwp and wikidata, including low adminship, tooling, limited i18n and yet it is the standard way to insert images in enwp, despite the built in tooling that enwp has for hosting files. If the goal is to solely focus on enwp and screw other language editions of Wikipedia, then yes wikidata/commons can feel like overkill at times. Wikidata is one of the few projects, that leverage the knowledge and expertise of non English editors, that can directly benefit enWP, and likewise allow english editors to benfit other language editions. We should celebrate that instead of admonishing it. I am sympathetic to many comments here, about difficulty in editing, and leave the recommended/preferred solution per specific articles (list of plants versus evolving breaking news section). ~ 🦝 Shushugah (he/him • talk) 15:25, 8 November 2022 (UTC)

Absolutely. A lot of systemic bias toward the English-speaking world tends to come through in discussions like this, with editors failing to realize how much content we lack in non-English speaking areas and how much Wikidata could help us there. Reminder: Two thirds of all topics covered on Wikipedia don't have an article in English. {{u|Sdkb}} ^talk 16:12, 8 November 2022 (UTC)

Yes! Thank you for making this point. ENWP is able to be self-sufficient due to the large English-speaking community, but that isn't true of many languages outside the top 10 or 15 largest Wikipedias. Being able to pull data from Wikidata to get up-to-date information is really useful for smaller communities, and having the large community of ENWP helping verify and maintain that information along with the Wikidata community and the communities of other language WPs would be a huge boon. Nicereddy (talk) 17:26, 19 November 2022 (UTC)

If this is the outcome you'd like the I suggest listening to user issues with using Wikidata and the issue that Wikidata can cause to Wikipedia. That way more editors will start and continuing using Wikidata. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:31, 22 November 2022 (UTC)

I expect few, if any, opponents are going to see 'new tooling' as solving anything. However anyone could of course start an RFC to determine whether the new tools lead to a more favorable change in consensus, if/when such 'new tooling' actually exists. Until then we have the inherent downsides of using Wikidata combined with tools and support that even Wikidata-advocates acknowledge are bad. Alsee (talk) 17:49, 9 December 2022 (UTC)

I like the idea of a new tool/data type - if the problem is edit control, referencing, and different guidelines, Why couldn't we just use a wikidata structure in a separate instance linked to enW?
Maybe there is some money as Wikidata has now got an extra USD 2.4 million in the updated Annual Plan 22/23 budget as part of the 17 to 28 % increase in funding "representing inflationary and other year-on-year costs" Do people know why it is such a priority for WMF? Is it auto create of articles using lambda functions in other languages, or high status because of GLAM projects, or selling access, or ,,,??? Wakelamp d[@-@]b (talk) 06:55, 10 December 2022 (UTC)

@Wakelamp while a local Wikidata instance would solve issues with administrative control, referencing, policies&guidelines, that would wipe out the entire argument in support of it. The entire rationale for stripping this content completely out of EnWiki's control was to create a single shared global database. The justification is for other wikis to benefit from any work we do editing Wikidata, and for us to benefit from work done by others there. Creating and using a local version would leave us with all of the increased complexity and difficulties of the additional system, in exchange for pretty much no purpose or benefit for anyone.

While I may disagree with Wikidata enthusiasts on the cost-benefit trade-off of using Wikidata here, I'm pretty sure they'd hate the idea of local instances. I understand the benefits they're trying to pitch. They want to suck up as much data as possible into a single centralized system... and to pipe that data out to as many places as possible. A local instance defeats the entire point. It's all about pushing everyone to become a Wikidata editor, centrally editing everything at Wikidata. Their project is so super-duper amazingly great that they think everyone at every Wikipedia on the entire planet should be feeding and serving their project. Alsee (talk) 03:31, 12 December 2022 (UTC)

@Msgj @Fram Many of the comments are about process (reliable references, etc ) and systems (how can we update in enWikipedia transparently, history) and single source of truth (Wikidata was in part created using enWikipedia data, GLAM databases).

What would you both think of having an interim option of en wikipedia having it’s own wikibase instance updated by en editors using our guidelines?

Looking at the opposite direction from en WP to Wikidata, @Ser Amantio di Nicolao @User:BrownHairedGirl. I think you both do a lot of categoriustion, and my apologies in advance if i am incorrect.

Is Wikidata the reason for the increase in complex intersection categories in Wikipedia? And what do you if the categoristion/infoboxes/lexemes (?) are different between the 2 systems? ~~ Wakelamp d[@-@]b (talk) 10:46, 17 December 2022 (UTC)

I'm very reticent about getting involved here, but I do think we have to look at this from the perspective of a typical Wikipedia reader, and their experience. They almost certainly arrive via Google, and all they do is read. They never use categories explicitly, and tend only to look at lists if they googled for a list. They use links to jump to related articles, and disambiguation pages if their Google search wasn't specific, but that's about it. They look at an article as an integrated whole, and it would never occur to them that the infobox isn't part of the article, or might be following a different set of rules about referencing and data-integrity. There is no logic whatsoever in deciding that a birthdate in an infobox can be derived from wikidata but outside an infobox it can't; from the reader's perspective, both are just birthdates in an article. But our readers do care about being given accurate data. The point about wikidata is that if the world is behaving properly, a lot of French editors will be noticing problems in French data and correcting them; if we decide to go our own way and use our own data, all those French corrections will pass us by, and we'll carry on showing bad data, relying on a tiny number of English-language editors who happen to have a foot in French matters. Or, in the less-likely event of one of those English editors spotting a problem with a French data-item, our correction won't benefit the French Wikipedia. Together, we can curate data much better. Elemimele (talk) 10:27, 22 December 2022 (UTC)

I agree in principle that it would be awesome if we have one repository of verified facts that we could use in multiple projects. But in reality, Wikidata has 23,890 active users, Wikipedia has 116,976 active editors, and consistently more than 50,000,000 unique visitors (devices) every day who can become an editor the second they see something that they know is wrong. That's a hell of a lot more eyeballs finding and fixing incorrect data. and reducing barriers to entry for those millions of people to make edits is surely the most important? Of course if we could have some way to integrate them, such that a 'data list' on Wikipedia is synchronised with wikidata, which in turn can be consumed by other wikis, that would be awesome, but the technology isn't there right now. JeffUK 10:55, 4 January 2023 (UTC)

@JeffUK the issue is worse than that. stats.wikimedia.org puts Wikidata "active editors" at 12 thousand, but Wikidata editor stats are severely inflated. Edits on other wikis, such as page moves, may trigger bot clone-edits updating Wikidata links to those pages. Those bot edits get attributed to the person who made the edit elsewhere. They have only a few thousand genuine active editors and over a hundred million Wikidata-items. Wikidata culture is primarily about sucking up as much data as possible, preferably with bulk bot edits. The actual community far too small to meaningfully patrol content quality or vandalism, even if they did consider it a priority. They have few content policies. The only reason they created a fig-leaf BLP policy is because their long-standing failure to create one was dragging their reputation through the gutter. Alsee (talk) 04:53, 7 January 2023 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Post closure discussion on Wikidata lists

• Andrevan, just to clarify/confirm, this is a no consensus outcome? {{u|Sdkb}} ^talk 06:40, 1 February 2023 (UTC)

Good question… is “lack of consensus” the same as “no consensus”? Blueboar (talk) 12:30, 1 February 2023 (UTC)

No consensus to change the existing consensus of past RFCs. Andre🚐 15:38, 1 February 2023 (UTC)

So the existing consensus at prior RFCs still stands. Blueboar (talk) 17:02, 1 February 2023 (UTC)

Yes Andre🚐 17:08, 1 February 2023 (UTC)

Thanks for closing, but I think the wording needs clarifying. As I pointed out above, there is no previous consensus on using Wikidata in tables, so this does not get us anywhere different as there is no previous consensus to go back to. The close of the 2013 discussion includes There is a valid point raised that while running text is clearly not suitable for Wikidata use, it might be worth discussing use in tables specifically – but no consensus regarding this has been reached in this discussion. — Martin (MSGJ · talk) 19:58, 1 February 2023 (UTC)

There is a previous consensus on using Wikidata in tables. It's Wikipedia:Bots/Noticeboard/Archive 13#Re-examination of ListeriaBot and Template talk:Wikidata list#"Not permitted" in mainspace. * Pppery * _{it has begun...} 23:36, 1 February 2023 (UTC)

It's funny I had also drafted a comment saying "Thanks for closing" and requesting the closing text be more clear, as there was clearly a dispute over how to interpret the previous consensus. However on reconsideration, I hoped that no consensus to permit was sufficiently clear. It is not possible to read this as allowing Wikidata lists, as that opposite interpretation would have required no consensus to prohibit phrasing.

In any case, this closure has already resulted in an editing conflict. Andrevan I thank you for your close, and I request a more clear close-text to avoid further conflicts. Specifically are editors (1) prohibited from converting Wikidata lists to non-wikidata? (2) Are editors prohibited from creating new wikidata lists? Or (3) both are permitted. Alsee (talk) 20:42, 1 February 2023 (UTC)

There is no consensus to permit using wikidata in article text. My understanding of the prior consensus is that the prior consensus did not permit wikidata in article text. I don't see any consensus here to change the status quo. No specific consensus was reached to allow use in tables, but I didn't review the previous close to see if the use in tables was permitted, but I'm guessing if it wasn't expressly prohibited, then existing usage of it could be justified under whatever prior justification existed. It's a no consensus close with no change to the existing status quo and no new resolution obtained as to new usage of wikidata. Andre🚐 21:12, 1 February 2023 (UTC)

My understanding of the prior consensus is that the prior consensus did not permit wikidata in article text. This is false. Some of those opposed to Wikidata use tried to imply that, by saying it would run counter to, as one !voter put it, the spirit of the various RFCs on Wikidata use, but that was heavily contested. {{u|Sdkb}} ^talk 23:21, 1 February 2023 (UTC)

If you are asking me to vacate the close I will vacate it, but the close was a no consensus for any new proposal being enacted close. If the existing state of things was a limbo then it should still be in limbo. I will admit that in the section of the RFC that discussed this I took the word of the participants on the state of the status quo ante, but it didn't factor into this close being a no consensus one. If you really think someone else would close this differently, I am happy to revert myself. Andre🚐 23:29, 1 February 2023 (UTC)

I don't see a need for you to vacate the close currently; I suspect a different closer would arrive at the same no consensus result. {{u|Sdkb}} ^talk 23:32, 1 February 2023 (UTC)

For me, the ambiguity lies not in the statement that it is not appropriate to use Wikidata in article text on English Wikipedia, but in the fact that a table is structured content and not article text. The 2013 discussion specifically excluded tables in its close, so there is certainly no existing status quo in this respect. If the closer had written article article prose then it would have been clearer still. — Martin (MSGJ · talk) 23:38, 1 February 2023 (UTC)

Lists are article text. Tables (unless images) are article text as well. Article text does not need to be in prose form. Blueboar (talk) 00:35, 2 February 2023 (UTC)

Well that's not how I understand the term. And why else would Coren (the closer) specifically contrast running text with tabular content? Infoboxes are mini-tables, and the usage of Wikidata on them is widely accepted. — Martin (MSGJ · talk) 08:16, 2 February 2023 (UTC)

@MSGJ you are attempting to argue that calling wikidata in lists was previously permissible, but you are forgetting the consensus banning Wikidata links in the body of the article. There is no interpretation of this RFC or any other RFC granting an exception to that ban. That leaves the options of (1) accepting elimination of these lists, or (2) eliminating wikidata links from these lists and then we can resume debate on how to interpret other past RFCs. Alsee (talk) 15:37, 8 February 2023 (UTC)

Ping RexxS and MSGJ. I get about sixty subpage hits for Special:PrefixIndex?prefix=Template:Wdtable_row. After significant-but-incomplete spotchecking, you two appear to be the primary or sole people editing these templates and deploying them to articles. I was wondering whether either or both of you were willing to accept responsibility for restoring all affected articles to a non-wikidata state? And whether you would be willing to tag all these templates CSD G7 author-requests-deletion once they are no longer in use? Alsee (talk) 19:27, 1 February 2023 (UTC)

RexxS has not - alas - edited for two years. It might be said that if something they did has persisted for that long, then there is consensus for it to be so. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:28, 1 February 2023 (UTC)

Either that or it simply flew under the radar. I suspect the latter is more likely. * Pppery * _{it has begun...} 23:36, 1 February 2023 (UTC)

The closing statement is pretty jarring given the discussion it intends to summarize. If there's any consensus to be found here, it's that many people have reservations about Wikidata lists, and many people see the potential to use them in certain circumstances, and only a handful of people want either a total ban or blanket permission. There are so many opinions here with extended conditions, qualifications, thoughts, and suggestions, that I don't see anything like consensus for a simple thumbs up or thumbs down (which the closing statement grants, given no clear prior position). If this really needs closure (and I'm not sure that it does), probably just "no consensus" with a recommendation to narrow the question to be about certain cases/uses. Also, as an aside, the Community Wishlist is going on now. If you want better tooling, this may be a good time to propose it. If anyone knows of any really good ideas to address Wikidata editing through Wikipedia, I'm happy to be canvassed to that proposal. — Rhododendrites ^talk \\ 21:10, 1 February 2023 (UTC)

"Many people have reservations but see the potential but NOTNOW" is akin to my reading. There's no consensus to permit new things. If there are gray areas before there are gray areas now. The intention is not a consensus for a thumbs down but no consensus for a thumbs up. I'm happy to vacate the close and let someone else close if there are concerns, though. Andre🚐 21:13, 1 February 2023 (UTC)

• I've amended the close to address this discussion. Let me know if you have further concerns. I am sorry that this outcome isn't very useful but I do not see how it can be closed other than a no consensus for a new proposal to be enacted regarding wikidata lists. Andre🚐 23:39, 1 February 2023 (UTC)

Display assessments on inactive wikiproject banners

Background for assessments on inactive wikiproject banners

A wikiproject is considered inactive if there has been no significant activity for three months. The wikiproject templates that appear on talk pages of associated articles are often changed to invoke {{WPBannerMeta/inactive}} instead of {{WPBannerMeta}}. This has the effect of suppressing display of the quality ratings. Instead of a banner like:

the wikiproject template now displays a message like:

The template no longer assigns the article talk page to assessment categories for the project. This was discussed at some length at Wikipedia:Village pump (miscellaneous)/Archive 73#Improper handling of assessment for inactive WikiProjects, with general agreement that there was no reason to suppress quality and importance assessments because the project was not particularly active.

Proposal about assessments on inactive wikiproject banners

This is to propose:

• Modify {{WPBannerMeta}} to accept an |inactive=y parameter, and if present note that the project is inactive, but display assessments in the same way as active projects
• Modify {{WPBannerMeta/inactive}} to invoke {{WPBannerMeta}} passing all the standard parameters plus the |inactive=y parameter

Note that the inactive project categories like Category:Start-Class Ruritania articles and Category:Low-importance Ruritania articles may have been deleted after they became empty, so will have to be restored. There are about 340 inactive projects, so this will take some effort, and possibly could be partially mechanized. Aymatth2 (talk) 15:14, 22 January 2023 (UTC)

Discussion about assessments on inactive wikiproject banners

Comments? Aymatth2 (talk) 15:13, 22 January 2023 (UTC)

• Support. To clarify from previous discussions, the assessments are not just suppressed (hidden), the are detached and no longer included in the total assessment scheme for articles that have only inactive project banners (example: Talk:Ork (Warhammer 40,000), within the scope of defunct WH project and without any active WP project banners, was rated as start, but now is considered unassessed). _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 17:42, 22 January 2023 (UTC)
• Partial support per my reasoning on Wikipedia:Village pump (miscellaneous). I support the display of the quality assessment on the template. But I do not support the recreation of hundreds of categories deleted over many years. I have put some code on Template:Inactive WikiProject banner/sandbox which will display the class rating and also repopulate the PageAssessments database, which will mean that most of the tools should work correctly. — Martin (MSGJ · talk) 20:36, 22 January 2023 (UTC)

  *Oppose. This strikes me as a waste of time. Just because there hasn't been a recorded action by a project for three months, doesn't mean that the assessments need to be, well, assessed differently. If they were valid when they were posted, they are very likely valid now, and someone could come along any time and renew activity at the particular project. If the assessments strike someone as needing to be revised, then revise them, but that doesn't require changing the template content in that way. We should be making it easy for projects that have temporarily gone quiet to become active again, not rush to sweep them out the door. --Tryptofish (talk) 22:58, 22 January 2023 (UTC)

  @Tryptofish, I read the proposal as doing what you suggest, and don't understand why you oppose. —Kusma (talk) 23:10, 22 January 2023 (UTC)

  You're right, and I struck what I said. I misread it. Sorry for my mistake. --Tryptofish (talk) 23:12, 22 January 2023 (UTC)

• Support per what I should have understood from the start. --Tryptofish (talk) 23:12, 22 January 2023 (UTC)
• Support making assessments independent of project activity. Ideally assessment should not be connected to WikiProjects at all, but we certainly should not delete the working infrastructure just because a project seems dormant. —Kusma (talk) 23:08, 22 January 2023 (UTC)
• Weak oppose, I guess. The inactive project banners give the impression that the project assessments are not being maintained because the associated project is inactive and have therefore been deactivated. This is silly, as normally, quality assessment and other banner flagging (such as needing infoboxes or images) is updated for all project banners by an editor who usually has nothing to do with any of them, and often this editor will make the importance assessment too, even though they're usually just guessing based on what the article says about its topic. With a couple of exceptions, such as WP:MILHIST's A-class reviews, messing with the project banners is not a project-related activity. Consequently, WP banners for inactive projects are pretty much redundant, unless the goal is to use the inactive projects' banners as a proxy for "Article condition by topic" categories, in which case I think the correct way to move forward is re-open that functionally fully and retire {{WPBannerMeta/inactive}}. —Compassionate727 ^(T·C) 04:24, 23 January 2023 (UTC)

  We could convert project templates that use {{WPBannerMeta/inactive}} to instead use {{WPBannerMeta|inactive=y}}. But the main assumption is that if an article has been assessed, there is no reason to drop the quality and/or importance assessment when the project goes inactive. I imagine some projects sporadically become inactive and later become active again. If a project is deleted, that is a different question. Aymatth2 (talk) 15:08, 23 January 2023 (UTC)

  Unless the parallel discussion on VPI is successful :) — Martin (MSGJ · talk) 15:18, 23 January 2023 (UTC)

  As someone who does a fair number of quality assessments, I don't really treat it as a Wikiproject activity. And since all the projects mostly use the same scale, I'd support just creating a global assessment system (with importance remaining within WikiProjects' domain). —pythoncoder (talk | contribs) 02:50, 24 January 2023 (UTC)

  @Pythoncoder that is exactly what we are discussing at Wikipedia:Village pump (idea lab)#Project-independent quality assessments. If that passes this whole proposal is moot — Martin (MSGJ · talk) 12:38, 25 January 2023 (UTC)

  Not really because importance parameters still continue to exist for most projects. And no proposal has been floated to deprecate them yet. —CX Zoom[he/him] ^{(let's talk • {C•X})} 18:24, 25 January 2023 (UTC)

  A rating for how important an article is to an inactive/defunct project? That would be absolutely useless information, unless the project is revived — Martin (MSGJ · talk) 19:28, 25 January 2023 (UTC)

  @Compassionate727 I am not sure I understand why you oppose this? For me, per the reasons explained at the Wikipedia:Village pump (miscellaneous)/Archive 73#Improper_handling_of_assessment_for_inactive_WikiProjects, one of the main issues is that the current way we are doing so consings numerous, perfectly fine assessments, to oblivion, as soon as a project is declared inactive. For articles for which this was the only banner present, those assessments become removed from the assessment scheme and the the page will now show as unassessed in the assessment scheme (see links in my comment a bit above). Any solution to fix this glaring error is a step in the right direction, no? _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 04:50, 25 January 2023 (UTC)

• Weak support, but the third banner is my personal favorite as it both addresses the presence of the WikiProject and preserves its older ratings. It would be nice, however, to see when the WikiProject was declared inactive. InvadingInvader (userpage, talk) 21:49, 31 January 2023 (UTC)

  In an attempt to find how many articles may be left unassessed due to inactive project banners I have created a tracking category Category:Articles possibly without an active WikiProject. It might take a few days to populate and then we'll see what there is — Martin (MSGJ · talk) 21:03, 25 January 2023 (UTC)

  @MSGJ: I think it includes articles with an active project but not assessed. E.g. Talk:9th Annual BFJA Awards- Aymatth2 (talk) 16:56, 28 January 2023 (UTC)

  It's only looking for banners of the form {{WikiProject... - a rather crude search with many false positives. Probably not worth keeping unless I can improve the regex — Martin (MSGJ · talk) 20:49, 28 January 2023 (UTC)

• Support, assessing is a lost art, and mostly ignored even in active WikiProjects. Abductive (reasoning) 08:44, 29 January 2023 (UTC)
• Support. Just like Abductive, I've seen plenty of active WikiProjects where the assessments are woefully out of date. People tend to remove assessments from talk pages for projects with inactive banners; but let's say I want to revive a WikiProject, or turn it into a task force; do I now need to manually reassess thousands of articles? It's silly. DFlhb (talk) 09:23, 29 January 2023 (UTC)

  People remove assessments from talk pages for projects with inactive banners? I've not seen this, and I'm not sure why anyone would do this. CMD (talk) 18:24, 31 January 2023 (UTC)

• Comment. It is often the case that members of a wikiproject make edits and improvements in the filed covered by the wikiproject, but whatever method the person who decides to mark it inactive uses to detect activity does not notice these edits and improvements. Thus the inactivity marker is wrong. Jc3s5h (talk) 18:41, 31 January 2023 (UTC)
• Support Assessments (mostly quality, not so much importance) can still be of value to editors outside of the Wikiproject, regardless of its status. Pinguinn 🐧 10:29, 3 February 2023 (UTC)

  If an article already has active projects containing assessments, is there any benefit in adding the (duplicate) assessment of an inactive project? — Martin (MSGJ · talk) 10:45, 3 February 2023 (UTC)

  Only if the assessments would differ, which can occasionally happen with quality but is far more common with importance. Pinguinn 🐧 11:37, 4 February 2023 (UTC)

• Oppose along the same lines as Compassionate. Having inactive values displayed (you could sell me on categorized) is inevitably makework for the users who come along and find assessments differ between projects. One might call these nuisance edits (because we shouldn't have to make them), as we maintain a system that there are even people who have considered tearing it down entirely. Izno (talk) 21:15, 4 February 2023 (UTC)
• Support per all the lengthy discussions we already had at WP:VPM and earlier, where I was a participant. Let us not lose all the assessment data, which makes it incredibly difficult for (a) new interested editors to reactivate a project, and (b) statisticians to find where Wikipedia is putting out our best and needs more attention. —CX Zoom[he/him] ^{(let's talk • {C•X})} 16:54, 7 February 2023 (UTC)
• Comment I would say the "supports" have it. If the proposal below, #Project-independent quality assessments is accepted, this change could be implemented at the same time. That would alleviate the concerns of the two "opposes", since quality ratings would generally move up into the {{WikiProject banner shell}}, maintained for all projects.The iImportance rating does not need much maintenance: if the subject is mid-importance to a project it will generally remain mid-importance regardless of how the article evolves. Aymatth2 (talk) 21:08, 7 February 2023 (UTC)

  Yes, absolutely the proposal below will help immensely. In that case we are not relying on inactive banners to give us anything valuable anymore, right? — Martin (MSGJ · talk) 21:36, 9 February 2023 (UTC)

• COMMENT I think it should display importance but should suppress quality display. The quality would not be updated unless there is some other wikiproject also signed on to the page. The importance would usually not change much unless some drastic event happened in the real world. However quality shifts with editing. -- 64.229.90.199 (talk) 03:22, 8 February 2023 (UTC)

  Who actually cares what importance an article is to an inactive project? That rating is of use to that particular project alone, and does not reflect importance of the article generally. — Martin (MSGJ · talk) 21:29, 9 February 2023 (UTC)

  People may care about the importance of a topic to a topic area, which is represented by proxy via the wikiproject that is aligned with the topic area. This may spur them to improve higher importance articles, or even revive the project. When I say suppress display of quality, I still think they should be categorized, to maintain banner functions, just not displayed in the banner. -- 64.229.90.199 (talk) 05:16, 11 February 2023 (UTC)

• Oppose The assessment and importance information implies that the article's status is being maintained. If the project is defunct, that isn't true. The assessment and importance data can be recovered from the talk page history if the project gets restarted again, so that seems like a non-starter in terms of problems for me. --Jayron32 19:12, 9 February 2023 (UTC)

  @Jayron32 You are missing a key point: may articles are assessed (maintained...) by people who are not members of the project. I've assed many articles for many wikiprojects without being their member, and I don't see why I shouln't be allowed to do so, nor why should my assessment be blanked once a relevant WikiProject becomes inactive? _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 07:55, 10 February 2023 (UTC)

  The assessment is not blanked, not is it hidden in the talkpage history. It remains right there in the untouched wikicode. Whether a project is active or inactive has zero bearing on editing its article quality assessment parameter in any particular article. CMD (talk) 08:28, 10 February 2023 (UTC)

  @Chipmunkdavis But the problem is that right now the assessment is not piped to the aggregate assessment data, as the categories are deleted. We are also loosing information on statistics of past assessmensts. Ex. once Project Foo is declared inactive, the desctruction of the category system means that all of articles that were assessed just by Project Foo revert to "unassessed" in the main stats for how many assessed articles we have, and the table matrix for how many articles Project Foo tagged and how was it assessed is destroyed as well. See example I give in my support vote at the very top. _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 05:33, 11 February 2023 (UTC)

  That's understandable, but the assessment is not blanked. It remains on the article talk page, and high-level category tweaks will be able to immediately pick up on all that existing data if desired. CMD (talk) 05:53, 11 February 2023 (UTC)

  @Chipmunkdavis Well then, my point is that it is desired and they should do it. Plus, what's wrong with the low-level categories? They hurt noone and were useful. I would like to know what were and are the breakdowns of articles assessed by some defunct projects. Why is that knowledge denied to me and others? _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 06:09, 11 February 2023 (UTC)

  No, Piotrus, I got that point abundantly it just didn't affect my vote on this proposal. See the vote below, however, for perhaps a more relevant view of what I do or don't get about your key point. --Jayron32 15:34, 10 February 2023 (UTC)

• Support granted a page supported by only inactive projects is going to have its rating checked marginally less frequently, but at the end of the day the error rate isn't going to be dramatically different and if once in a blue moon a project does get reactivated because a new enthusiastic group of editors comes to us then all the better. The whole point of placing quality assessments in the banner shell is that a stub is a stub regardless of which project is assessing, and if we really wanted to we could create a taskforce dedicated to checking all pages that have no associated active project; in fact tools could probaly do most of the work, flagging for review only those pages who's quality rating is suspect. 74.73.224.126 (talk) 19:32, 9 February 2023 (UTC)

  Isn't that exactly what the proposal below is going to resolve? I agree that all articles should have a rating, but the rating of an inactive project is not going to help much, if there are other banners of active projects on the page. — Martin (MSGJ · talk) 21:31, 9 February 2023 (UTC)

  The point is that baring certain idiosyncratic rankings (e.g. the MILHIST list stuff) the quality should be the same throughout. It doesn't help much, but it's harmless and potentially beneficial in that it both facilitates reactivation of a project if interested editors emerge and offers a different way to explore content. In the past when I was more active I sometimes sought out low-hanging fruit by looking at WikiProjects covering topics of interest and seeing which high and top importance articles were stubs; usually those were excellent candidates for expansion with sources that were easy to find. I doubt I'm the only one to ever explore content that way, and a project doesn't need to be active for that kind of organization to be helpful. 74.73.224.126 (talk) 04:28, 10 February 2023 (UTC)

Remove reversions from a user's edit history

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Something needs to be done about egotistical Wikipedia users spamming reversions on the most minor of revisions of articles in order to up their edit counts. These individuals are so lost in their desire to be in the top leagues of edits that they have lost scope of the quality of Wikipedia articles in lieu of their own quantity of edits as some kind of competition. I would suggest that we remove reversions from a user's edit history, and also use say an amount of words removed directly from previous edits by another user in order to prevent loopholes such as filibustering by simply deleting the previous user's text. Those who want to revert harmful content immediately should be rewarded simply by knowing they're doing the right thing, rather than their own selfish desire to be seen as the biggest editor on the site.

Eddiehimself (talk) 23:23, 10 February 2023 (UTC)

Not seeing reverts in edit histories would be a very poor idea. They're as important to examine as other edits. Anyway, mindless reverting isn't a good way to build up an edit count, there are much easier and more effective methods. CMD (talk) 02:53, 11 February 2023 (UTC)

Please provide diffs to show that this is happening. We cannot act on such generalities. Phil Bridger (talk) 09:11, 11 February 2023 (UTC)

Edit count isn't a measure of competence, effort or general goodness. If anyone uses it in that way then we need alternative metrics rather than filtering the edit history. Hiding reversions could be unhelpful, especially if it conceals bad reversions of good edits. For example, User:Bad replaces an article by "poop", User:Good restores it, then User:Bad repeats the vandalism. The third edit is a revert, but it's one we need to see when we spot another of User:Bad's misdeeds and look at Special:Contributions/Bad to see what else they broke. Good reversions should be encouraged, along with good typo fixes and other minor but useful contributions. Certes (talk) 11:43, 11 February 2023 (UTC)

Eddiehimself, If you can establish that this is a real problem, it would be better to keep a separate count of reverts, but they must be counted as explained above. Whether it would be worth the effort is another matter. If someone is reverting you for no good reason, that can be looked into. If someone is reverting you for good reason you should make better edits. If you don't know why someone is reverting you ask them, though any reversion without an edit summary to explain it is inherently suspicious. · · · Peter Southwood ^(talk): 15:35, 11 February 2023 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Should edit filter managers and helpers be allowed to view Special:log/titleblacklist?

I have a few basic reasons for proposing this:

1. It can be useful for vandalism patrol, as well as monitoring false positives produced by the title blacklist.
2. I see no reason why someone trusted to view private filters and their logs can't be trusted to view the log of a publicly viewable blacklist. It's not like an EFM will suddenly go rogue and create a bunch of nonsense pages.

137a (talk • edits) 14:48, 10 February 2023 (UTC)

This seems to be currently a technical matter for the devs. See https://phabricator.wikimedia.org/T68450 --Jayron32 15:32, 10 February 2023 (UTC)

@137a as noted by Jayron32 this proposal (which would effectively be "Give (titleblacklistlogs) access to group x, group y") is useless. Not even admins who have this permission can see this, because it isn't logged at all. — xaosflux ^Talk 11:13, 12 February 2023 (UTC)