So, as I understand it, IP editors & brand new accounts can not create new articles. But that hasn't stopped them from trying. Every night Wikipedia:Database reports/Orphaned talk pages is generated which is a list of orphaned talk pages, mostly created by IP accounts, where there is no accompanying article. Sometimes the talk pages just have random comments but often there is the draft of an article. This is not a huge problem, since I've been checking it, there are anywhere from 5-15+ pages listed each day. But it does happen daily and I wonder if the IP account page creation ban should be extended to article talk pages, especially since they are not associated with any existing articles. Occasionally, these orphaned talk pages are in redirect, category or draft space but they are primarily in article space.

Thoughts, comments, objections? Liz ^{Read! Talk!} 05:14, 27 July 2021 (UTC)

I'd tenatively oppose this, pending more information, since IPs could just as well be making a legit talkpage comment on a not-yet-existing talkpage of an existing page. Do we have data about total talkpage creations by IPs to see what fraction of that is the problem we might want to solve? You said the orphaned talkpages are "mostly created by IP accounts". Should we just limit their creation to admins? DMacks ( talk) 05:45, 27 July 2021 (UTC)

Just to be clear, is the question whether to prohibit IPs from creating any article talk page, or just ones for which there is no associated article (e.g. Talk:Like this one)? If the latter is technically feasible, then perhaps doing it might indeed reduce some spam, but we should not be stopping unregistered users from creating talk pages for articles that already exist, given the vital role of talk pages in the editorial process. Mz7 ( talk) 07:15, 27 July 2021 (UTC)

I agree with @ Mz7. ― Qwerfjkl talk 07:26, 27 July 2021 (UTC)

I also agree with Mz7. Further, if IP editors are prohibited from creating talk pages then the message they see when attempting to do so must, very prominently, link to the places they are likely intending to be - i.e. draftspace, WP:TEAHOUSE, Wikipedia:Sandbox, etc. Thryduulf ( talk) 10:42, 27 July 2021 (UTC)

I agree that we shouldn't be preventing IPs from creating talk pages for existing articles, but that creation of orphan talk pages in mainspace is almost never appropriate or useful. However, I don't think an edit filter can be made that checks for the existence of a different page (e.g. to create an edit filter that restricts creation of orphan talk pages in mainspace to autoconfirmed users). If it is in fact possible I would support such a move. IPs creating draft articles in such places will only end up being confused when they get deleted - it is in their own interest that they be redirected to Draft: space or elsewhere. firefly ( t · c ) 11:18, 27 July 2021 (UTC)

question: Is it ever appropriate to have a talk page with no associated article? Asked another way, should everyone (not just IP) be prevented from creating a talk page that doesn't have an existing article? RudolfRed ( talk) 17:36, 27 July 2021 (UTC)

Is it ever appropriate to have a talk page with no associated article? Yes. Talk page archives (e.g. Talk:Cuba/Archive 1 exists, Cuba/Archive 1 doesn't) and GA reviews (e.g. Talk:Ink wash painting/GA1 exists but Ink wash painting/GA1 doesn't) are the most common instances I can think of (whether they have an "associated article" depends on interpretation), but there are very occasional other uses (e.g. in the very early days of Wikipedia, the talk page of a deleted article is often the only place a deletion discussion was documented) - see Category:Wikipedia orphaned talk pages that should not be speedily deleted. I can't think of a reason why an IP editor would need to create any of these (and any exceptions will be so rare any attempt to codify them will massively outweigh the effort of just asking someone who can), but autoconfirmed users at least do need to be able to. Thryduulf ( talk) 18:58, 27 July 2021 (UTC)

If it is feasible, then I support preventing IPs from creating TPs without an associated article per Mz7’s example. If we outright prohibit them doing so it undermines WP:BRD, as once an IP’s edits are reverted in an article without a TP, their only options are to edit war (possibly communicating through edit summaries) or to walk away. Cavalryman ( talk) 22:58, 27 July 2021 (UTC).

• We do not currently have a technical tool available that would allow for:

IF( 
 (USER IS IP) AND
 (ACTION=CREATE PAGE) AND
 (NAMESPACE=TALK) AND
 (NEWPAGETITLE NOT LIKE "NEWPAGETITLE/*") AND
 ("TALK:(BASEPAGENAME:NEWPAGETITLE)" EXISTS) AND 
 (PAGE (main):NEWPAGETITLE NOT EXISTS)
  )
THEN DISALLOW CREATION;

• (or something resembling that pseducode). If we wanted to stop creation of all new talk pages by unconfirmed editors, that would be trivial to do. — xaosflux ^Talk 23:13, 28 July 2021 (UTC)

  The (NEWPAGETITLE NOT LIKE "NEWPAGETITLE/*") line could possibly be omitted, as IP editors shouldn't need to create new talk page archives and while I haven't looked I doubt they are frequent initiators of GA nominations. I get the impression from your tone though that this would not make a material difference to the ability to implement the proposal? Thryduulf ( talk) 23:51, 28 July 2021 (UTC)

• Yup, this is technically impossible in the software AFAIK. But you could request an adminbot to CSD such pages automatically. ProcrastinatingReader ( talk) 23:28, 28 July 2021 (UTC)

  I would oppose deleting these pages without human review, as they could contain viable drafts, help requests, and other things where the only problem is being in the wrong place. Thryduulf ( talk) 23:47, 28 July 2021 (UTC)

• Per Mz7. It would be nice if the software prevented talk pages eligible for G8 from being created by non-autoconfirmed accounts. If you can get the WMF to do that (or can do it yourself) you have my blessing. Without that, the status quo of "letting them do so and having an admin mop them up every day or two" is the best option. I agree with the above suggestions that we can't trust a bot to do those deletions. User:力 (power~enwiki, π, ν) 23:50, 28 July 2021 (UTC)
• If it were possible, I would support, but it seems to be impossible with our current technology. I'd be interested in what the volume of bot deletions would be, but like others I'm wary of biting IPs who post viable content only to have it instantly deleted. — Wug· a·po·des​ 00:09, 29 July 2021 (UTC)
• As others have expressed concern about this limiting legitimate edits, which I share, how about this idea? Either software (unlikely, but maybe there is some feature I am unaware of that would make this possible) or an adminbot (would likely need adminbot to get around salt/blacklist) automatically creates talk pages for new article-space pages a set, but relatively short (i.e. 1 hour) time after page creation. It could even be just a blank page created. This would allow editors not auto-confirmed (or IP) to make edits to legitimate article talk pages (of articles that exist) while still preventing orphaned talk pages from being created. I share the concerns about automatic deletion, but since talk pages can be deleted when an admin deletes the associated page, I cannot find any reason that automatically creating them via bot would be a problem. This also has the benefit of removing the “creating a new page” fear that some may have, and it could also be used to apply a talk page banner or other message automatically, or even categorize into “unfinished talk pages” or similar for editors to clean up and finish the “header” material. -bɜ:ʳkənhɪmez ( User/ say hi!) 15:43, 31 July 2021 (UTC)
  • Since I forgot to explicitly say, if such a bot were implemented, then creation of talk pages by non-auto-confirmed accounts (or even higher) would be a viable option and I would support it if a method to not hamper legitimate creations (either my bot suggestion or otherwise) is implemented at the same time. -bɜ:ʳkənhɪmez ( User/ say hi!) 15:45, 31 July 2021 (UTC)

Sdkb, do you wanna take care of the phab ticket? -- Trialpears ( talk) 09:25, 4 August 2021 (UTC)

Sure, filed phab ticket: phab:T288161. We'll see how it goes. {{u| Sdkb}}  ^talk 19:36, 4 August 2021 (UTC)

I missed this whole discussion, but with regards to performance: this will greatly be improved in the coming year or so once we roll out CodeMirror 6. You can follow phab:T259059 for updates. — MusikAnimal ^talk 16:26, 5 August 2021 (UTC)

Specific proposal: Replace ClueBot edit summary of "Reverting possible vandalism by [username]" with less judgemental "Edit by [username] not accepted" (or some other bland edit summary that you all can come up with. Details follow.

We all love ClueBot, it is this astounding machine, it is essentially always correct about when an edit is bad, and it's very very helpful in patrolling and keeping our articles free of nonsense. When it does delete a contribution, it leaves a nice and non-accusatory notice on the contributors talk page. That doesn't mean ClueBot is absolutely perfect, and I think that its edit summaries could be improved.

About, I dunno, 95% of the edits ClueBots flags are vandalism. The other 5% are bad edits, worthy of and needful of being deleted, but not actually intentional vandalism. These shouldn't really be tagged as vandalism or possible vandalism (ClueBot always leaves an edit summary of "Reverting possible vandalism by [username]".) Not a huge deal, since the edits are pretty bad even if in good faith, but not absolutely ideal, and easy to change I would think? It could just say "Edit by [username] not accepted" or "Reverting edit per ClueBot algorithms" or something that doesn't say "vandalism".

So, for the first time ever, I just saw ( here) ClueBot roll back some edits by a new and possibly promising user User:Franco tradisionele disse that were actually reasonably OK. There were several misspellings (contributor is ESL), and no sources, and whatever else, and ClueBot got triggered, but the information itself was Wiki-standard and it was the kind of new-user edits that you can work with, and the kind of editor that you can work with. I am not complaining about that. I'm gobsmacked that people were able to make something so amazing, and even if it happened more often I'd still be a ClueBot fan. I'm just talking about the edit summary.

So, in this one case, the new editor was wrongly called a vandal, and this violates the First Law of Robotics if one takes "injury" to include "insult". (Or possible vandal, which's not much better, anymore than "you're possibly an asshole" from a human colleague is not really neutral). The user was surprised and confused by this and it would be understandable if she was upset. Yes I know that its just one person (so far, that I know of), but still.

So couldn't we petition to have the edit summary just changed to something more bland and judgemental (and that, since simply describing an action, correct 100% of the time rather than 95%)? Am I missing something here, or is this worth even worrying about, or is there too much downside? What say you? Herostratus ( talk) 20:05, 19 July 2021 (UTC)

I say "Reverting edit by [username]" to be more neutral. "Edit not accepted" makes newcomers think ClueBot is perfect, which it isn't. Sungodtemple ( talk) 20:39, 19 July 2021 (UTC)

There isn't a nice way to be told by a robot that your edit was so problematic it's been reverted. New editors will have no idea what ClueBot does, and why it might revert them. The important thing is to be directed to somewhere that explains the situation, and what you should do about it. Perhaps "Edit triggered a problem detected by ClueBot; editor, please see your talk-page for an explanation" or something similar Elemimele ( talk) 20:54, 19 July 2021 (UTC)

I don't see this as particularly useful as a user may question why the edit has not been accepted to which the response would be: suspected vandalism. So it would just be adding confusion to the reverts. Terasail ^[✉️] 00:12, 20 July 2021 (UTC)

Please link to prior conversations around this so that others can at least see the somewhat lengthy debate around the matter:

• User talk:ClueBot Commons/Archives/2021/July#WHOOP WHOOP TERRAIN TERRAIN
• User talk:ClueBot Commons/Archives/2017/December#Proposed change to standard wording

For this specific proposal for this specific messaging, Oppose as it does not contain the word "revert" or "vandalism" and is therefore likely to cause problems with other automated tools looking for one of those specific words in edit summaries to identify reverts. -- Cobi^{( t| c| b)} 00:40, 20 July 2021 (UTC)

OK. Including "revert" is fine with me, but you're saying that one robot has to use the word "vandalism" so that another robot can understand that dif. Even it is not vandalism. As it isn't, 5% of the time. Needs of robots trumps need to be as welcoming as possible seems to be what you are saying? Herostratus ( talk) 00:55, 20 July 2021 (UTC)

Oh, and don't forget people, ClueBot also leaves a message on the user's talk page. IIRC this message is fine, it doesn't mention vandalism, notes that it might be wrong, and so on. Probably because on a talk page message you're not limited to a short string. But because the contributor's name is link in the edit summary (which it has to be), the person is also drawn to the edit summary. How about maybe "Edit reverted, see your talk page"? Herostratus ( talk) 01:05, 20 July 2021 (UTC)

• Oppose any "not accepted" verbiage. 1) This could be suggestive that the edit was never published, when it was. 2) This suggests that edits are normally going through some sort of acceptance review, which they are not. — xaosflux ^Talk 02:06, 20 July 2021 (UTC)
• Oppose. To the proposals points directly, I do not believe you can add "insult" to the First Law of Robotics until you cross into some form of Harassment, which is certainly not within ClueBot's capabilities or current wording. With 1RR and friendly wording ("Report False Positive? Thanks, ClueBot NG"), ClueBot is doing its job while being as friendly as possible. Furthermore, as mentioned by Cobi in the previous discussion on ClueBot Commons, another person coming up to you and calling you a "possible asshole" is comparing apples to oranges here. It's also a major escalation in severity that, again, does not apply to a robot saying the same thing to everyone.

Now, it is my opinion that ClueBot uses phrasing I believe any reasonable person would not take offense to. The "possible" qualifier implies that the revert, be it done by a human or bot, could be in error. This is the same verbage I would see used in any other ambiguous situations - "possible phishing" in my mail client, "possible spam," on my phone's call screen, "banned for possible cheating" in a video game. It implies that there is room for error and to seek assistance and/or take caution in your further actions.

That all said, the primary reason I oppose such a change is strictly technical - changing even minor things will break someone's workflow. Other tooling expects this wording from ClueBot. Creating change here does not create a net benefit for something I do not see as an existing problem. -- SnoFox^{( t| c)} 07:32, 20 July 2021 (UTC)

A forgotten point from my original oppose: As for what the message should contain, I think it is important for robots to inform humans as to why they're taking action. Simply removing the reason, as suggested, will create even more confusion. If you are unfamiliar with ClueBot, what is more obvious than specifying exactly what it thought you did? Wikipedia has a word for it - it's vandalism. We should use that term, not try to sugarcoat it or hide it. The current text is succinct and as friendly as possible given the technical restrictions around edit summaries. -- SnoFox^{( t| c)} 07:55, 20 July 2021 (UTC)

• Oppose both proposed wordings here. The "not accepted" wording is highly confusing because it inaccurately suggests we have some kind of approval process for edits to be accepted. I also don't like the "check your talk page" type wording because it obscures the reason why the revert was performed and I think that it would make the page history difficult to follow - in 10 years time you're going to be directing people to messages that likely don't exist anymore. I think there could see some benefit to modifying the message to make it more explicit that the actions were being performed by a bot (perhaps add something like "this action was carried out by an automatic computer program" before the link to submit false positive reports?) but I don't think the current wording is particularly problematic or offensive. 192.76.8.91 ( talk) 16:00, 20 July 2021 (UTC)

No - ClueBot makes it clear that it is possible vandalism. Possible being the key word. It means it could not be vandalism, but ClueBot is only making a statistical guess. Aasim ( talk) 02:27, 22 July 2021 (UTC)

I would suggest something along the lines of "Reverted edit by [user]: Non-constructive" ― Qwerfjkl talk 16:02, 22 July 2021 (UTC)

Arbitrary break (ClueBot edit summary)

So let's see, at this point we have...

• Original proposal (by me) was "Edit by [username] not accepted"
• Next editor suggested "Reverting edit by [username]" (which is better IMO)
• Next editor suggested "Edit triggered a problem detected by ClueBot; editor, please see your talk-page for an explanation" (which is even better IMO, but there are possible length issues)
• Next editor is OK with keeping current ("possible vandalism") as this gives clear reason.
• Next editor is OK keep with keeping current as the word "vandalism" must be kept in for benefit of other robots
• Next editor is only opposed to "not accepted" language (not clear if OK with current)
• Next editor is OK keep with keeping current as any change could disrupt other robots (also, no reasonable person minds any of their edits being called "possible vandalism")
• Next editor is OK with keeping the current, altho adding "this action was carried out by an automatic computer program" might be good
• Next editor is OK with the keeping the current, basically.

It looks pretty even, but a big sticking point is the fear that other programs (or whatever else is including in "workflow") would be disrupted. Big if true, but how big is this really? I'm asking. What do these other programs or workflows do? Important stuff, or paper-shuffling? Counting how many edit summaries contain the word "vandalism" and stuff like that? That's good for reports like "2.1% more edit summaries use the word 'vandalism' in April", and that's OK but it's really just bean counting.

I myself seldom use the revert buttons, or the word vandalism; I often (not always) just restore the previous version and give a hand-written explanation and/or use "revert test edit" (there are a non-zero number of useful editors here whose first edit looks like vandalism but was probably just testing to see if you really could edit an article just like that, and assuming good faith is recommended). So anyway, my revert edit summaries seldom contain the world "vandalism" even if it probably is, so... am I breaking other robots? Am I messing up people's workflows? Should I not do that? Is there a guideline somewhere to that effect? (FWIW Wikipedia:Edit summary legend seems to support the use of "rvv" for vandalism reverts, so maybe you need to talk to those people too.)

Or do these other robots only care about what other robots are doing, not what we meat units write? Well for goodness' sakes why? This sounds sketchy, don't you know how that sort of thing ends up? (BTW we know that the First Law of Robotics prevents a robot from assaulting you, wouldn't it also prevent it from saying "Eat my dust, touchhole"? I think the Science Police would say so. Emotional injury is injury.)

"Revert" is fine, an editor at User talk:ClueBot Commons/Archives/2017/December#Proposed change to standard wording averred that "many tools key off of the regex '/^revert/i'", which, OK, keeping the string "revert" in it makes sense anyway as a purely descriptive human-readable characterization of what happened.

Anyway, I'm struggling to think what the actual problem here is. Help me out here. Show me an important robot that requires the use of insults to function, that can't be rewritten or dispensed with, and you'll get my attention. Herostratus ( talk) 15:45, 22 July 2021 (UTC)

ClueBot NG reads edit summaries from other users here and here. That could definitely be updated for ClueBot NG itself, but this shows that it isn't an unusual thing to do for other tooling. A quick search of Wikipedia itself reveals this user's monobook.js and another here keys off of edit summary messages like this -- no idea what it is doing with that data, though. There are more: [5] [6] [7] [8] and the examples keep coming if I keep trawling through the search results. And that's not even off-wiki. There are a ton of tools with off-wiki source code and those would need to be checked, too. -- Cobi^{( t| c| b)} 04:28, 23 July 2021 (UTC)

The problem is that the edit summary that is being proposed by you the original poster seems to be very vague. It gives no reason why, it is far less helpful explaining what is going on to other editors, and it will confuse the editor who made that edit as they will have no understanding why their edit was reverted.

I would favor replacing "Possible vandalism" with "Possible unconstructive edit" but for the most part, the edit summary is very clear.

"Reverting possible vandalism by $2 to version by $1. Report false positive? Thanks. Cluebot NG (Bot)"

The message delivered also makes it very clear that the bot sometimes makes mistakes. And for the size of the wiki, I think having a bot help revert vandalism at the cost of catching some false positives is understandable. Aasim ( talk) 21:49, 22 July 2021 (UTC)

• Oppose. There will always be some small percentage of ClueBot edits that will be mistaken, which is why its edit summary includes "possible", but a 95% (or whatever it is) success rate is good enough that there's more of a downside from making the bot less clear/direct about what its doing than there is an upside from the extreme assumption of good faith. {{u| Sdkb}}  ^talk 00:06, 23 July 2021 (UTC)
• Oppose I have no problem with the 5% that might get their feelings hurt. 95% correct flagging is well past an acceptable threshold. This is not an issue worth much discussion time. GenQuest ^"scribble" 22:53, 24 July 2021 (UTC)
• Oppose. It is important that invalid reverts have a clear and accurate description. When cluebot gets it wrong we want people to understand and confidently revert cluebot. The various alternatives raise a serious risk of people seeing a bad cluebot edit, presuming the edit is somehow legitimate or authoritative, and believing they should not touch it. Even worse, research has shown that unexplained reverts are a real killer on new users. This proposal would inadvertently cause new users to give up, feeling powerless because their edit is "not accepted" for no comprehensible reason. Alsee ( talk) 08:41, 31 July 2021 (UTC)
• The summary of Cluebot NG's task is very clear: an anti-vandal bot that tries to detect and revert vandalism quickly and automatically. Changing the edit summary made by the bot doesn't achieve anything, and will just lead to more confusion, IMO. All vandalism is unconstructive, but not all unconstructive edits are vandalism. So no, the "not constructive" suggestion doesn't work either. pandakekok9 ( talk) 05:11, 4 August 2021 (UTC)
• Oppose, the current message is fine ("possible" vandalism). Stifle ( talk) 16:34, 9 August 2021 (UTC)

Should {{Vital article}} be integrated into {{Article history}}? ~ HAL 333 21:03, 23 July 2021 (UTC)

• Support as nominator to limit talk page clutter. The current Vital article template takes up a relatively large amount of room for the required text: "This is a level-# vital article in this subject." ~ HAL 333 21:03, 23 July 2021 (UTC)
• You're suggesting a merger with {{ Article history}} and not {{ talk header}}? If so I feel you should change the header to avoid confusion. Either case I have some issues but I don't see it as a complete non-starter. -- Trialpears ( talk) 21:20, 23 July 2021 (UTC)
• I think that most of the time the WikiProjectBannerShell is the best place for this information on crowded talk pages. User:力 (power~enwiki, π, ν) 23:01, 23 July 2021 (UTC)

• Support Consider this more appropriate than WikiProjectBannerShell or talk header. Hawkeye7 (discuss) 00:06, 24 July 2021 (UTC)

• comment I just wish someone could convince me that "vital article" is meaningful with good, well followed criteria. Doug Weller talk 09:22, 27 July 2021 (UTC)

I 100% agree with Doug Weller, selection of what are deemed to be vital articles seems to be pretty arbitrary, and further I don’t really see value of the list any more. Cavalryman ( talk) 23:17, 27 July 2021 (UTC).

• I suggested this at the idea lab last year; SandyGeorgia had some thoughts at the time convincing me against it, and might be interested in this discussion. ProcrastinatingReader ( talk) 00:10, 28 July 2021 (UTC)

• Add to WikiProject banner shell only-- should not be cluttering talk pages at all. Thanks for the ping; my opinion is formed by having watched efforts like this come and go over about 15 years. Like so many of the earlier Wikiprojects that attempted to classify articles by importance, this is ... no more than a currently-popular WikiProject that is likely to be replaced in a few years by the next iteration of a scheme from a different group of editors. (In most areas I edit, it is apparent that the choices aren't always logical, either.) This should be added only to the WikiProject banner shell, as merely another Wikiproject that is likely to be replaced somewhere down the road. I agree with both Doug Weller and Cavalryman that the selection seems to be entirely arbitrary, and not really reflective of ... much of anything (same was true of similar past projects). It should not be added to either talk header or article history, rather just another WikiProject, rolled into that banner shell. SandyGeorgia ( Talk) 19:03, 28 July 2021 (UTC)
  • I hate to argue with the person agreeing with me that WPBS is the right location, but I don't think it's fair to call WP:VA a transient and arbitrary project. It is the sole successor of the earlier "CD" projects, after people realized that nobody needed a CD with part of Wikipedia (the various Kiwix projects can fit all of Wikipedia -- at least all the text). Also, at least at the higher-importance levels has been repeatedly picked over for non-arbitrariness. User:力 (power~enwiki, π, ν) 23:55, 28 July 2021 (UTC)
• Add to WikiProject banner shell per others mentioned above and I agree with 力 about Vital article being useful and I make use of it myself. Huggums537 ( talk) 19:30, 30 July 2021 (UTC) Strike and switch to...
• Oppose per comments by Sdkb. Also, I didn't realize my previous vote would involve collapsing. Huggums537 ( talk) 14:18, 9 August 2021 (UTC)
• Comment I have integrated {{ Vital article}} into {{ WikiProjectBannerShell/sandbox}}, and editors can see some examples. Should this be closed that way, let me know and I can make it live. Otherwise the same kind of coding can be used in {{ article history}}. — Wug· a·po·des​ 23:33, 30 July 2021 (UTC)

  @ Wugapodes: can we move it into the collapse? ProcrastinatingReader ( talk) 19:38, 6 August 2021 (UTC)

I think I would support the move into the collapse. Cavalryman ( talk) 13:06, 9 August 2021 (UTC).

• Comment I think this proposal is thinking along the right lines, but ultimately I can't support. The vital article banner takes up an entire banner just to communicate one small piece of info, which isn't necessary, especially considering many vital articles will have many other banners. But it's not part of an article's history, so it doesn't fit there, nor is it a topic-based WikiProject in the same way as the projects that get collapsed into the WikiProject banner. It should ultimately be consolidated into something, but I'm not sure whatever that thing is is ready yet. {{u| Sdkb}}  ^talk 15:06, 3 August 2021 (UTC)

  Sdkb, Would you support integration into {{ talk page header}}? Shibbolethink ^{( ♔ ♕)} 13:32, 13 August 2021 (UTC)

• Question, given the vital article list is the domain of a single WikiProject, shouldn’t the vital article banner just be considered a standard WikiProject banner and placed inside the WikiProject banner shell along with all other pertinent WikiProject banners? Cavalryman ( talk) 03:41, 4 August 2021 (UTC).

  I don't think so. The WikiProjects listed in the banner are all content projects—people look to that banner to answer questions like "To what content areas does this article relate?" and "Where can I find other editors knowledgeable about this topic?" The vital article notice is included on talk pages for an entirely different reason, and answers the totally different question "How important is this topic?". {{u| Sdkb}}  ^talk 19:47, 4 August 2021 (UTC)

  A WikiProject is a group of people who want to work together to improve Wikipedia. The group of people who want to improve Wikipedia by working together is a WikiProject, too, even if their area of effort is in identifying broad subject areas rather than everything about a single subject area. See also Wikipedia:WikiProject Articles for creation, which also doesn't have a narrow content area, and Wikipedia:WikiProject Disambiguation, whose focus is on improving Wikipedia in all articles. WhatamIdoing ( talk) 19:20, 6 August 2021 (UTC)

• Oppose mainly because as far as I can tell the vital articles project is just the priority list of a few people, hardly something that rises up to "talk page banner" importance. OTOH, adding it to the Article history template is OK for me. Jo-Jo Eumerus ( talk) 19:43, 6 August 2021 (UTC)
• Oppose. Keep it where it is. My personal opinion of vital articles is that they are a somewhat useful indicator, used in various places for getting a very rough idea of what our most important articles are. The decisions made there should never influence what happens in article space, or indeed the main page, other than as an indicator, but I think it's fine to have a small talk-page banner indicating that the article in question has been selected.  —  Amakuru ( talk) 13:24, 13 August 2021 (UTC)

Many navigational templates includes links to non-article content at the bottom of the template. This can include useful categories, portals, outlines and more which should not be removed. A typical example of this from {{ Canadian Forces Air Command units}} below this comment.

My concern is about these links including WikiProjects as these clearly contradict MOS:LINK which states In articles, do not link to pages outside the article namespace. These pages are not reader facing and should be kept out of articles.

Given their high usage, I estimate about 34,000 articles are affected, I thought it was best to make sure there is consensus for removal even though they are clearly against the manual of style. WT:LINK, WT:CLN and Template talk:Navbox notified -- Trialpears ( talk) 16:01, 8 July 2021 (UTC)

• Support removal of Wikiproject links, as wiki projects are not reader facing. -- Asartea ^{Talk | Contribs} 16:08, 8 July 2021 (UTC)
• @ Trialpears:, I disagree with your reasoning. If you think these links violate MOS:LINK, then MOS:LINK needs to be clarified (although I think it is obvious that it is talking about links in the text). We routinely link to non-articles through templates. All of our cleanup templates do so, for example. Most navboxes have a self-link (which goes to the template namespace). — Kusma ( talk) 16:13, 8 July 2021 (UTC)

  Oppose wholesale removal. In your example, I find the link pointless, but I'm not sure I do so in 34000 articles that you haven't presented here. — Kusma ( talk) 16:15, 8 July 2021 (UTC)

  Kusma You're probably right about it being intended for inline links. Guess confirmation bias set in when looking for the policy/other page about linking to non-reader facing pages. The list I based my estimate on was Special:WhatLinksHere/File:People_icon.svg which is uses of the icon usually placed besides these links in mainspace. It's not a perfect list at all, but should be good enough for discussion. Could you come up with a case where a WikiProject link would be beneficial? I checked a few dozen of the pages before starting this discussion and all of them were similar to the one shown above with just as little utility. As with essentially all template edits, these changes shouldn't be done fully automatically either, but have human review to make sure they are appropriate. -- Trialpears ( talk) 16:28, 8 July 2021 (UTC)

  I don't have a concrete example in mind where a link currently exists (I might like a WikiProject link for smaller projects, say, on Template:Doctor Who), but generally we should be open to showing the collaborative nature of our project and consider having links in navboxes or similar that invite the reader into the backstage area. Given that most portals (our other reader-facing namespace that can be linked to) are display only showcases these days, additionally linking to Wikiprojects makes some sense. (I'd prefer portals to be much more integrated with WikiProjects and be much more about collaboration than about displaying our finest work, but I'm probably in the minority even among the two dozen people who still care about portals). — Kusma ( talk) 16:37, 8 July 2021 (UTC)

• One concern - a lot of our Wikiproject’s are essentially moribund. Do we really want to point readers to moribund project pages? Blueboar ( talk) 17:34, 8 July 2021 (UTC)
  • This is a good point, we really shouldn't be.... Aza24 ( talk) 16:04, 9 July 2021 (UTC)
• Reluctant support I love the idea of linking to WikiProjects, especially for more specific templates, like {{ William Shakespeare}} or {{ Richard Wagner}}, but the age of WikiProjects has really been disappearing for sometime now, and in general linking is probably a net negative. Aza24 ( talk) 16:04, 9 July 2021 (UTC)
• Categories and portals are both reader-facing, so I oppose disallowing linking to them in navigation templates. I support disallowing links to WikiProjects; it's just not an appropriate thing to do. {{u| Sdkb}}  ^talk 07:53, 10 July 2021 (UTC)
• Strongly oppose removing links to categories and portals, these complement the content of the navigational template. DuncanHill ( talk) 08:07, 10 July 2021 (UTC)

  @ Sdkb and DuncanHill: I fully agree that categories, portals and other reader facing pages are good links and do not want them removed, just WikiProject links. I've made some slight modification to my original statement to make sure this is clear. -- Trialpears ( talk) 08:18, 10 July 2021 (UTC)

• Strong oppose per Kusma. It's possible that there are some links on some templates that are poor value, but the place to discuss these is at the level of the individual template not trying to legislate them away wholesale. Thryduulf ( talk) 11:52, 10 July 2021 (UTC)
• Portals seem like poor value (to readers and to editors in maintenance) in general to me, but I suppose that's another discussion. I think the WikiProject links are probably a good thing. ProcrastinatingReader ( talk) 12:14, 10 July 2021 (UTC)
• Strong oppose per Aza24 Thryduulf. This is just yet another bad edit to the MOS made in 2021. We've always linked to files, portals and categories. MOS:DRAFTNOLINK was only supposed to prohibit linking to the draft space. Suggest its removal from the MOS instead. Hawkeye7 (discuss) 12:19, 10 July 2021 (UTC)

  Hawkeye7 Perhaps we're misunderstanding each other? We've indeed always linked to files, portals and categories and I think we should continue to do so, but I don't feel WikiProject links are appropriate to do the same with. Also Aza24 described their comment as "reluctant support" which is quite far from your comment. -- Trialpears ( talk) 12:24, 10 July 2021 (UTC)

  Ooops. Wrong user. Corrected. We always have, and should continue to do so in spite of the MOS. I understand your proposal is more limited than the MOS, which bans images from articles, but I do not endorse this approach. Hawkeye7 (discuss) 12:35, 10 July 2021 (UTC)

  While I still strongly oppose MOS:LINK, and therefore any action based on it, I do accept the arguments of Sphilbrick and Blueboar that the links to Wikiprojects are editor facing and not reader facing. However, I am not convinced that all navigational templates are on article pages and not Wikipedia or Talk pages. Hawkeye7 (discuss) 20:47, 10 July 2021 (UTC)

  There are a not significant amount of navboxes intended for Wikipedia, Help and Template namespaces, but since the rationale doesn't apply there these should not be removed. If someone uses a navbox in a discussion (as I did above or in ER for example) I don't see a reason to have a link there but not in articles. It's technically possible but will likely be a cause of confusion for essentially no benefit. -- Trialpears ( talk) 21:50, 10 July 2021 (UTC)

  Nearly every page has at least one, including this one. Hawkeye7 (discuss) 21:29, 12 July 2021 (UTC)

• Note… Wikiprojects are usually linked to on article TALK pages. This is appropriate as Wikiprojects are “editor oriented” not “reader oriented”. Blueboar ( talk) 13:10, 10 July 2021 (UTC)
  Thus… I Support removing links to Wikiprojects from article space, but would Oppose removing them from talk pages if that is proposed. Blueboar ( talk) 20:06, 22 July 2021 (UTC)
• Partial oppose If you take a glance at MOS:LAYOUT, you can see that we define the elements of an article as following into four groupings: 1 before the article content, 2 article content, 3 appendices, 4 end matter. Technically, navigation templates are part of the fourth grouping and therefore part of the article, but I think when one reads the prohibition against linking outside the article namespace in articles, many would think the emphasis is on the second grouping, the article content. If a reader is in the middle of reading the article content, and comes across a linked item, it is reasonable for them to expect that the link will bring them to a different article which contains more detail about the linked item. However, they might be surprised if that link brings them to a list of categories or a portal. In contrast, if you are at the bottom of an article and see a navigation template, with a link called "category", or a link called "portal", you would hardly be surprised to be brought to a list of categories or a portal. Invoking the principle of least astonishment, I think most readers would be astonished to find a link to a list of categories or portals embedded in the article content but would not be at all surprised to see that in a navigation template.
  My initial thinking was to simply oppose this proposal and accept the navigation template as shown, but I am persuaded by the comments of Sdkb that wiki project should be handled differently. While I find more value in wikiprojects than I do in portals in general, I note that portals are reader facing while wikiprojects are more oriented for editors so I think our convention of mentioning wikiproject on article talk pages is the better location of such links.-- S Philbrick (Talk) 13:12, 10 July 2021 (UTC)
• There is an old RFC about this......that resulted in the removal of Wikiprojects all over. Moxy- 14:24, 10 July 2021 (UTC)
• Given that I imagine all new editors started as readers, I think there is value in trying to let readers know that there is an infrastructure to support those who are interested in specific areas, and thus draw them into the corresponding Wikipedia community. That being said, I'm not sure a link labelled "WikiProject" is a great way to do that. I suspect many will not understand what it means. Perhaps User:MMiller (WMF) on the growth team (for those who are unaware, Wikipedia:Growth Team features has info on current features being developed) can tell us if there has been any investigation in trying to guide new editors, based on the pages they've visited as readers, to find communities of interest? isaacl ( talk) 21:26, 10 July 2021 (UTC)
• Oppose we do need a whole-scale re-thinking of navigational boxes; they have a 1990s-web vibe that isn't necessarily correct, though there is certainly some benefit to their current usage. As the status quo, if people pay enough attention to notice a "WikiProject" link, I don't see that as harmful. User:力 (power~enwiki, π, ν) 21:30, 10 July 2021 (UTC)
• Support removal. I definitely can imagine cetain cases where linking to a WikiProject is beneficial for the reader, but that's what the talk page of a template can be useful for; particularly multiple WikiProjects. There are also many projects where a WikiProject is so vaguely broadly, for example the Canada WikiProject listed in this example that it's not super useful, or where it's inactive, which is a negative experience. I do think WikiProjects/Portals need to be rethought, but do not think Navigational templates are it. Shushugah ( talk) 16:16, 11 July 2021 (UTC)
• Support removal of links to wikiprojects from nav templates (and more generally from mainspace articles), per nom and the others above. Levivich 19:33, 11 July 2021 (UTC)
• Support. Extra clutter and not worth promoting in article space, although specific WikiProjects that are still active and want it could keep links on major pages as long as it stops being the default. ─ ReconditeRodent «  talk · contribs » 01:41, 12 July 2021 (UTC)
• Support removal of WikiProject links per nomination. I don't see any situation where a WikiProject is useful to a reader — they're for editors and should stay on editor-oriented pages. Tol | talk | contribs 04:20, 12 July 2021 (UTC)
• Oppose — This feels like an inobtrusive way to invite readers to become editors. Just as navboxes have V T E: View Talk Edit, and every page has an edit button, categories of content should have a small way to join the editing community. Now, as to what content they land upon at the WikiProject in question, there is much to improve. (For what it's worth, I also feel actively hostile to the MOS-lawyering cited as justification here since we have numerous objects at the footer that are non-articles.)-- Carwil ( talk) 19:42, 16 July 2021 (UTC)
• Oppose - largely agree with Carwil on this. I wouldn't say WikiProjects aren't reader-facing. Many of them provide useful tools for finding articles, understanding the way articles are written, etc., not to mention providing resources to help newbies orient themselves to thinking about editing in a particular area. That makes it quite different from, say, ANI or the spam blacklist or any one of the other pages that are decidedly not there to welcome new users. That's not to say WikiProjects should always be included either, of course. Base it on whether the WikiProject is at least semi-active and/or whether it has a useful landing page. — Rhododendrites ^talk \\ 21:12, 16 July 2021 (UTC)
• Weak oppose as I generally think we should invite readers to see more of the editing process. Elli ( talk | contribs) 00:50, 19 July 2021 (UTC)
• Strong Oppose - these links are an invitational way to get people involved in understanding and editing Wikipedia. Are we going to remove Portal: links as well? Perhaps MOS should be amended to deprecate non-article links in article text (where they would interfere with the intent of creating an informative article on the current subject); while allowing appropriate Wikipedia:Wikiproject and Portal: links in article titles, sidebars, navboxes and other supporting infrastructure, where they encourage users to explore the topic more widely, and perhaps get involved themselves.-- Verbarson ( talk) 09:06, 19 July 2021 (UTC)
• Oppose per Rhododendrites, isaacl, and the first paragraph of Sphilbrick's comment on MOS:LAYOUT. — Wug· a·po·des​ 19:47, 22 July 2021 (UTC)
• Strong support – Mainspace navigational templates are public-facing and WikiProjects are very much not. It may be useful to be encouraging readers to become more involved in the editing process, but WikiProject links are not an especially useful way of doing that given that most WikiProjects have fallen into disuse. (Reviving WikiProjects may be an advantageous endeavour, but any such efforts will have to start with active editors.) And the inclusion of links that are all-but-useless to 99.9% of users in navigational templates is just poor design. 207.161.86.162 ( talk) 23:20, 22 July 2021 (UTC)
• Oppose: for reasons above-stated: this feels like an unobtrusive way to invite readers to become editors. Only the most interested and detail-oriented readers will notice them anyway. Also, a wholesale removal denies the chance of each Navbox to be individually evaluated. In short, the negatives of removal outweigh the positives of non-removal. If anything should be done, would be to refine the Manual of Style. Thank you. Al83tito ( talk) 03:06, 24 July 2021 (UTC)
• Strongly Oppose – Per the other users above and also WP:IAR. I think that including these links in the navigational templates are a great way to introduce readers to the relevant WikiProjects and recruit new editors. There is practically no other way for new readers to learn of or find the WikiProjects (outside of a direct interaction with a user who is already a member of the said WikiProject) outside of these links. I think that removing these links will do more harm over the long run than they could ever benefit the project. A lot of WikiProjects are suffering from inactivity and user retention issues, and this would just be another nail in the coffin for those WikiProjects. And if the wording in WP:MOS is an issue, than perhaps that policy page should be modified so that it clearly allows this. We've been doing this for many years with virtually no problem at all, and I see no reason to change tact just because of a strict reading of WP:MOS. Also, WP:IAR exists. If and when a rule prevents us from improving the site, we should disregard it. And modify it, if necessary. LightandDark2000 🌀 ( talk) 22:10, 24 July 2021 (UTC)
• Support Project links are a different beast, as highlighted by many above. Wikiproject links should only appear to the casual reader, if ever, on the talk pages. Regards, GenQuest ^"scribble" 14:12, 25 July 2021 (UTC)
• Oppose WikiProjects are useful, both for finding articles about a specific topic and for helping/encouraging new users to edit in that area. I'd also argue they can help established editors find new WikiProjects they might be interested in. Remagoxer ^(talk) 09:04, 28 July 2021 (UTC)
• Support removal of Wikiproject links. They are not reader-facing pages and shouldn't appear in article pages. Reducing Nav-template-clutter even a little is also desirable. Regarding some of the oppose arguments, I agree with the general idea of wanting people to peek-behind-the-curtain and hopefully join us but I don't think wikiproject links are the way. Alsee ( talk) 07:54, 31 July 2021 (UTC)
• Oppose I remember first time I found WikiProject Chemistry. Afterwards, I could not find it again. I didn't know about the talk pages (they are hidden for a new user - normally comments are after the article), or the different name spaces and so on... Christian75 ( talk) 15:32, 1 August 2021 (UTC)
• This is a good example of WP:IAR usage. Clearly, it's a problem with MOS:LINK, not the navigational templates. It's not like we're linking to WikiProjects so blatantly in the article body (which is what MOS:LINK wants to prevent in spirit, I think). If a reader find those links, it's most likely that they already have the potential to be an editor, not merely staying as a reader. We should help them reach their potential. pandakekok9 ( talk) 05:18, 4 August 2021 (UTC)
• Oppose I started reading this, entirely expecting to support. But that link in the template is so nice-looking and non-obtrusive, and it's MILHIST which is actually an active Wikiproject. I think this should be determined on a case by case basis, and to the extent it conflicts with MOS:LINK, MOS:LINK should be changed, not this usage. I would oppose linking to non-active/marginally active wikiprojects. As to how you define that, I don't really know, but that's what localized discussions are for. Calliopejen1 ( talk) 22:13, 10 August 2021 (UTC)
• Support removal of WikiProject links, as non-reader facing pages. Per Alsee, and others. Mathglot ( talk) 22:00, 14 August 2021 (UTC)

Hi comrades. I would like to propose a short addition to a particular paragraph of a MOS guideline, off the back of a discussion about compatibility of practice with that guideline. I've found WP:PROPOSAL, but that seems to deal with really substantial policy/guidance proposals. What is the correct procedure for proposing a small addition to a MOS para? Thanks DBD 12:38, 17 August 2021 (UTC)

Have you raised it at the Talk page for the MoS in question? DonIago ( talk) 13:49, 17 August 2021 (UTC)

That's where the prior discussion was happening. Is the correct procedure then just to start a new section? No templates, tags or what-have-you? DBD 16:21, 17 August 2021 (UTC)

It can depend on the magnitude of the amendment and whether other editors feel that any level of escalation is needed (i.e. get consensus for your amendment before editing the MoS), but I've had changes to the MoS be proposed on the Talk page, encounter no or easily-resolved concerns, and then made the edit. Do make sure that even when it appears you have a consensus that you give it a reasonable amount of time (5-7 days is good) before making the actual edits, in case there's any late-breaking worries about them. Hope this is helpful! DonIago ( talk) 17:02, 17 August 2021 (UTC)

That's reall helpful. Thanks loads DBD 18:26, 17 August 2021 (UTC)

The tap to display equations in the math and physics articles is EXTREMELY ANNOYING. it is impossible to read an article without constantly tapping. Just display the damn equations.— Preceding unsigned comment added by 2600:1700:3f7a:66a0:ec58:294e:5e43:7f52 ( talk) 14:54, 16 August 2021 (UTC)

This is a problem with MediaWiki on iOS. For now, you can switch to the desktop site. 2600:100F:B125:3055:FDBC:91B8:8484:BD84 ( talk) 18:49, 17 August 2021 (UTC)

What should we do to all foreign-language interface messages (like MediaWiki:Abusefilter-disallowed/de)? Should we:

• Keep all of the foreign-language messages, or
• Delete all of the foreign-language messages, or
• Keep some, but delete others

This is following up from an MFD where there was consensus to keep the messages but get wider input in the village pump. I have been procrastinating this due to university, but I think it is finally time to debate it. Aasim ( talk) 22:53, 18 July 2021 (UTC)

I am going to start by quoting myself: Per Wikipedia:Miscellany_for_deletion/MediaWiki:Noarticletext/es, as an English language Wikipedia, it is entirely pointless to have personalized messages in [foreign languages] as it is expected that those contributing have a decent command of English. In summary: In order to contribute to this project, you need to have enough of a command of English to understand all the English-language system messages and policies that we put there, and translating these messages will probably just encourage non-fluent English speakers to contribute to this project in broken English, rather than contributing to their own language Wikipedia fluently without problems. Aasim ( talk) 22:56, 18 July 2021 (UTC)

Also, courtesy ping the users who participated in the MFD: @ Pppery @ Xaosflux @ Zoozaz1 @ Godsy @ Davey2010 @ Kusma @ Elli

And the previous MFD: @ SmokeyJoe @ Robert McClenon @ Gioguch Aasim ( talk) 23:14, 18 July 2021 (UTC)

Survey (foreign-language interface messages)

• Case-by-case per my comments at Wikipedia:Miscellany for deletion/MediaWiki:Abusefilter-disallowed/de. — xaosflux ^Talk 00:12, 19 July 2021 (UTC)
  • For anyone not wanting to dive in, here is an example: We have a page, MediaWiki:Blockedtext/en-gb that will display to users that set their interface language to en-gb; now we really don't encourage the use of this language here - but if this page were deleted instead of those users seeing our customized message there they would get the mediawiki default. We certainly don't do this for all messages in en => en-gb, but for the most important ones we do. This can also be useful for certain default messages that are displayed to our editors that are using very popular languages such as MediaWiki:Abusefilter-disallowed/de. — xaosflux ^Talk 10:10, 19 July 2021 (UTC)

    @ Xaosflux I think you misunderstood what I was asking. I was asking about foreign-language interface messages, not English dialect localizations. That would mean that MediaWiki:Blockedtext/en-gb would not be in the scope of this discussion. Aasim ( talk) 02:25, 22 July 2021 (UTC)

    @ Awesome Aasim: even so, still case-by-case. There are certainly cases where these could be useless, however the prime sample you opened this discussion with is an example of one that certainly could be useful - as without it our editors with de interface set (for example cross project editors) would not see our localized version - but instead the mediawiki default. — xaosflux ^Talk 09:43, 22 July 2021 (UTC)

• Keep most - these seem more useful to keep around than to delete. Elli ( talk | contribs) 00:41, 19 July 2021 (UTC)
• Case-by-case. Way too many interface messages of way too variable quality and usefulness to judge as a group. E.g. The various Copyrightwarning messages which haven't been translated should probably be deleted, as an English message is probably worse than the default translated message in that situation, but the contents messages are fine and have no mediawiki default. 192.76.8.91 ( talk) 03:38, 19 July 2021 (UTC)
• Keep most, at least those that are visually integrated in the wiki UI (page headers, footers, sidebars etc) that is otherwise also localized in the user's language of choice. People are entitled to use the Wiki interface in any user language they choose. It's got nothing to do with not being able to use English fluently – I, for instance, have occasionally edited as a guest on numerous other Wikipedias, including my native German one, but I still keep the interface in English in most of them, out of pure habit. If we have enwp-specific strings that are meant to be integrated in this localizable UI, then it's only proper to also have these strings localized. Of course we can't commit to keeping everything translated into every language Mediawiki supports, and we shouldn't bend over backwards trying to achieve that, but if we already have those translations, what harm does it do to keep them and thereby maintain better user experience for some visitors? I'm less convinced about those that are meant to be displayed as part of metadata inside articles, for example all those "cite error" components. Fut.Perf. ☼ 10:40, 19 July 2021 (UTC)
• Keep all as a default, being in a foreign language is generally a reason to keep them. (Lots of reasons for people who don't read English well to participate here). Use MFD to discuss individual pages that are problematic for reasons other than being interface messages in a foreign language. — Kusma ( talk) 10:49, 19 July 2021 (UTC)
• Keep all by default, without prejudice to individual discussions at MfD if any are problematic for a specific other reason. Simply being in a foreign language is not a reason in and of itself for deletion. Thryduulf ( talk) 11:09, 20 July 2021 (UTC)
• Keep all – Wikipedia, or rather, English Wikipedia, is part of a larger community of projects under the Wikimedia umbrella that includes over 300 other Wikipedias, not to mention other sister projects. Wikipedia:Wikimedia sister projects has this to say:

  Wikipedia encourages links from Wikipedia articles to pages on sister projects when such links are likely to be useful to our readers, and interlingual crosslinking to articles on foreign-language editions of Wikipedia whenever such links are possible.

In addition, the Welcoming committee also has tools available to address new users in their own language, when their English isn't up to snuff for contributing here; here's a list. While neither of these cases is quite the same as this one, nevertheless it's clear that English Wikipedia intends to be welcoming to speakers of other languages under various circumstances, and in that spirit, this case should be no exception. Mathglot ( talk) 01:11, 22 July 2021 (UTC)

• Keep all unless there's specific cause to delete. I have occasionally had reason to visit foreign-language wikis. There are a variety of kinds of valuable edits that do not require knowledge of the local language. It's helpful if as much of the interface as possible remains readable. Alsee ( talk) 08:02, 31 July 2021 (UTC)
• Keep all unless they have a specific problem. As detailed below by Whatamidoing, if we delete the messages then users with that interface language will usually not see an English message, they will see the MediaWiki default for their language. MediaWiki:Abusefilter-disallowed/de links to Wikipedia:Edit filter/False positives like our customized English version MediaWiki:Abusefilter-disallowed. If we delete it then users with German interface will see translatewiki:MediaWiki:Abusefilter-disallowed/de, a German translation of translatewiki:MediaWiki:Abusefilter-disallowed which tells the user to contact an administrator. We don't want the user to do that. Default MediaWiki messages are written for all MediaWiki installations so they don't link local wiki pages and don't mention local policies and features. We should translate more of our important customizations to common languages, not delete the existing translations. PrimeHunter ( talk) 22:27, 31 July 2021 (UTC)

Background (foreign language interface messages)

For anyone who doesn't know what's being talked about:

All the little pieces of text in the user interface (i.e., not the articles, but things like words on a button) are called " system messages". They are almost always written in English originally, put into the MediaWiki software code, and then translated at a separate website, TranslateWiki.net.

For example, when you make an edit, there's big blue button for saving your changes. You're probably used to seeing the button say "Publish changes". The button's text is stored in a MediaWiki message called MediaWiki:Publishchanges. If you have your language preference set to English in Special:Preferences, then you will see "Publish changes". If you have your language preference set to something else, then you will see the translation (from TranslateWiki.net) for that language. Fun trick: For your account, it says Publish changes. (That trick shows a different version to each reader. For nearly all of us, that sentence will be English. If you want to see what another language looks like, then click here to see this page in Russian or here to see this page in Japanese.)

That's the normal system. Now let's talk about customizing it for all editors at this wiki.

Imagine that you're the largest wiki in this history of the world, and you think that the generic wording somewhere should be different. You probably don't want to touch MediaWiki:Publishchanges, because Here There be Lawyers (seriously – they care about that button) and you definitely don't want to change the copyright notices, but you might very well want to change some messages, such as the text displayed when you visit a non-existent page, or (since our documentation is more extensive than average), you might want to add a link to a help page that exists at this wiki but not at any others. You've thought it through, and your change isn't a general improvement that would help everyone, so you only want to change it here at the English Wikipedia, for all users of this one wiki. That's do-able, if you have the necessary user rights. You edit the MediaWiki system message page to contain your new text (in HTML, not wikitext). This local message page will override the normal text.

Now here's the problem – and why those pages translated exist: You've replaced the message in English. But there are almost 300 other languages that people might have set their preferences to, and none of them see your new custom message, because you've only written the English one. For example, MediaWiki:Noarticletext looks like this in various languages:

You can see that we have customized the English version, but all of the others are showing the MediaWiki default, translated into that language. If you want the custom version showing even for people who have set their UI to a different language, then we'd (re-)create MediaWiki:Noarticletext/es, MediaWiki:Noarticletext/de, MediaWiki:Noarticletext/fr, etc., with the text that we wanted them to see. The question in this RFC is: Do we want to keep those translations of custom pages?

BTW, if you are fluent in more than one language, and you'd like to help with translations, please contact me. I can help you get started. Whatamidoing (WMF) ( talk) 21:46, 19 July 2021 (UTC)

@ Whatamidoing (WMF): (will have to look up the many phab tickets) but its been argued (by me and others) that what should be fixed for a subset of this problem is the variant fallback behavior (i.e. If MediaWiki:Foo has been initiated, and the variant hasn't been initiated, then show the base language. So if Mediawiki:Foo exists and MediaWiki:Foo/en-CA doesn't, but someone has en-CA set - show them the base on an en project instead off falling back to the mediawiki default). As far as the other problems, see my note above about how it is useful to have a local version of certain pages such as the abusefilter reject message in popular languages that x-wiki editors may be coming from. The question above isn't about is any specific one of these good or not though, it is asking if the community wants to nuke ALL of them without further consideration, which I think is a very bad idea. — xaosflux ^Talk 21:55, 19 July 2021 (UTC)

While publishing an actual "translation" of something missing such as MediaWiki:Publishchanges is certainly a good idea, it is not the solution for a page like MediaWiki:Abusefilter-disallowed which augments the default with styling. (An entirely new solution for that with variables and classes COULD work but that is well beyond the scope of this discussion). — xaosflux ^Talk 22:00, 19 July 2021 (UTC)

I have no opinion about whether the existing pages should be deleted, or whether more should be created. My main opinion is that if you can't figure out what a system message actually is, it'll be difficult to form an opinion about anything else.

There was some work done a year or two ago about "circular" fallback languages – pt vs pt-br is a primary example. I'm not sure that it gets applied in this situation, however. In the en-ca/en-gb examples, however, it might probably be faster to make a list of customized messages and transclude the custom version into the "translated" page name. Whatamidoing (WMF) ( talk) 03:45, 20 July 2021 (UTC)

We've done that on the more "important" local messages like MediaWiki:Blockedtext/en-gb, though it is a kludgy hack and has challenges with passing the variables. — xaosflux ^Talk 09:53, 20 July 2021 (UTC)

@ Xaosflux: we can do this with a local bot, right? Say for any MediaWiki: customisations, have a bot create all the en-* pages to transclude the main one. ProcrastinatingReader ( talk) 00:17, 28 July 2021 (UTC)

@ ProcrastinatingReader: well, it would have to be an admin bot, and some require parameters to be handled in unusual ways preventing normal transclusion. It would be much better to fix the language variant fallback tree upstream (thus also fixing it for everyone that uses mediawiki). — xaosflux ^Talk 00:29, 28 July 2021 (UTC)

@ Xaosflux: I'm happy to write up the bot if some admin is willing to run it. It'd be better in the software, of course, but probably better have some fix for it than have it be bugged. We could always delete them in the future if an upstream fix ever happens. Do you know what phab task this is BTW? ProcrastinatingReader ( talk) 10:11, 28 July 2021 (UTC)

@ ProcrastinatingReader: it certainly isn't as simple as adding a transclusion on every MediaWiki:Foo/en-gb of MediaWiki:Foo - like I mentioned anything everything with parameters may need to be handled in a different way. phab:T229992, phab:T162008, and possibly others outline the problem. Ideally at least an option should be available to define a local fallback scheme such that uninitiated messages in certain languages (esp language variants) can fallback to a specified language (e.g. en-gb --> en) instead of to mediawiki default. — xaosflux ^Talk 14:46, 28 July 2021 (UTC)

+1 @ Whatamidoing (WMF). Thanks for giving clarity for what I am proposing. Aasim ( talk) 17:52, 20 July 2021 (UTC)

Similar to HTML Tidy, a bot or tool to improve the layout and indent style of markup. .... 0mtwb9gd5wx ( talk) 04:01, 17 August 2021 (UTC)

@ 0mtwb9gd5wx: I'm not sure what you're asking here - could you give a few more details on what you are proposing? Mediawiki already included a HTML cleaner that fixes a lot of invalid markup, and anything that the parser can't fix automatically is tagged by the wp:linter for wikignomes to fix up. If you're referring to edits that make no changes to the rendered HTML of a page but make the wikitext look nicer - that is called Wp:Cosmetic editing and bots that exclusively make them are expressly forbidden per WP:COSMETICBOT. 192.76.8.74 ( talk) 04:26, 17 August 2021 (UTC)

@ 192.76.8.74: Like pretty printing for programming languages, there could be a tool that receives MediaWiki markup and formats it via standard rules, as a server-side tool, to present, to the editor, an alternative to browser-heavy syntax highlighting, similar to https://refill.toolforge.org/ or https://refill.toolforge.org/ng/ . .... 0mtwb9gd5wx ( talk) 04:52, 17 August 2021 (UTC)

unfortunately there isn't really such a tool possible, as whitespace is very important in wikicode (unlike in most other programming languages). There is a syntax highlighter tool available in the editor though; the , left of "Advanced" in some toolbars (not the pencil icon on the far right). If "New wikitext mode" or "Automatically enable all new beta features" is enabled at Special:Preferences#mw-prefsection-betafeatures then it is available on the menu icon . — TheDJ ( talk • contribs) 08:11, 17 August 2021 (UTC)

@ TheDJ:@ 192.76.8.74:Actually, some pretty formatting is possible, such as:
<ref name="N">NEWLINE{{cite web |last1=L |first1=F |title=T |url=U |website=W |access-date=D}}NEWLINE</ref>
and naming refs then putting cites between refbegin and refend. .... 0mtwb9gd5wx ( talk) 00:36, 24 August 2021 (UTC)

There is a discussion at WP:TFD regarding the merging of some 16000 political party templates into one meta module. Your input would be appreciated. Primefac ( talk) 11:38, 26 August 2021 (UTC)

goes to:

• https://uslaw.link/citation/stat/80/92

and mentions:

• https://www.govtrack.us/congress/bills/89/hr8030

it needs to also point to:

• https://www.congress.gov/bill/89th-congress/house-bill/8030

also, is there a template for congress bills ?

{{uscongress bill|house|89|8030}}

.... 0mtwb9gd5wx ( talk) 04:45, 27 August 2021 (UTC)

Template_talk:USStat may be the correct venue for this request. Template:USBill may be the template you seek. Folly Mox ( talk) 05:54, 27 August 2021 (UTC)

Moved to Talk:Main Page § Add Albanian Wikipedia to the bottom of English Wikipedia page - section 50.000 articled

 –  ―  Qwerfjkl talk 15:16, 28 August 2021 (UTC)

The biographies are in 3 levels. I think it would be beneficial to split them off into their own list with 5 levels rather than the current list. If you oppose this, I would like to know your thoughts on adding in-between levels such as level 3.5 or level 4.5. I look forward to your comments. Interstellarity ( talk) 14:56, 27 August 2021 (UTC)

Please see the previous discussion on the vital articles talk page here. One editor suggested opening up the discussion here for greater visibility. Interstellarity ( talk) 15:01, 27 August 2021 (UTC)

• Oppose for the same reasons I and others opposed at the previous discussion. The Vital Articles lists are hard enough to maintain at their present size without expanding them further, and I've seen no justification for this other than as a way to create more room in (i.e. expand) the sets. {{u| Sdkb}}  ^talk 16:36, 27 August 2021 (UTC)
• Oppose. As I see it, the main purpose of WP:VA is to identify sets of 100, 1000 and 10,000 articles which are considered the most important, to help endeavours like WP:The Core Contest, classify the quality of our most important articles, and also to give editors a hand in choosing which articles to prioritize for work. None of that benefits from splitting the list into people and non-people though. Rather, it just creates inconsistency with editors having to check both lists, with perhaps lower participation by those selecting the articles. Note that Wikipedia is not split along these lines in any other area - we don't have Featured articles / Featured people, or Articles for deletion / People for deletion. Finally, to address some specific points:
  • I can see the argument that biographies and non-biographies are hard to compare with each other as to which is more important, the same goes for any other diverse categories. Evaluating which of Jupiter, World War II, Clothing and Christianity is the most "vital" is almost meaningless, but the VA project still lumps them together.
  • It's been said that an advantage is the freeing up of 127 new slots for articles at level 3, but that's not something I think we want. Per Sdkb the lists are intentionally kept at specific levels, and if the 1000 level 3s are not enough then either look at level 4, or get consensus to expand it to 1200.
  • As for needing to classify people into 5 separate levels, I again don't see the need or rationale for that. Looking at Wikipedia:Vital articles/Level/5/People/Writers and journalists, I already don't know who the majority of those are, and I think they rightly represent the lower bound of vitality. Yes, they're important people, but anyone below that shouldn't be classified as such IMHO, and the exercise becomes increasingly unwieldy and arbitrary too. A desire to add a level 6 probably exists in other areas too, but I'd oppose that for similar reasons.
  • In summary, I think the VA process has worked well down the years, and this large-scale split down the middle wouldn't be beneficial. Cheers  —  Amakuru ( talk) 08:07, 28 August 2021 (UTC)
• Comment: I am neutral on this, but the project pages should be placed under Wikipedia:WikiProject Vital Articles if it is needed to get rid of unnecessary essay templates. They are unintentionally undermining, they don't encourage to edit pages when the opposite is needed. Interstellarity's project has already been useful. Currently Level 5 needs more development and alternative listing would be useful in finding the most vital biographies and for example listing them alphabetically. -- Thi ( talk) 15:42, 28 August 2021 (UTC)

Copied this over from Village Pump (Technical) because it was posted to the wrong place. I want to get community consensus on this here to send it to Phabricator...

In the preferences settings under the first tab named "User Profile" there is a section about: Gender used in messages, where a user can specify to be addressed by gender neutral, feminine, or masculine pronouns, and when another user hovers over the username the chosen pronouns will be displayed as he/him or she/her along with the user rights and other user groups of the user as well as their edit count and some other basic information about the user.

However, there is a technical issue with this feature that makes the preference appear to be biased in nature where the feature appears as if it doesn't work at all if a user chooses that they wish to remain gender neutral because if this option is chosen there is simply nothing at all displayed when you hover over the username, and there should be at least something such as they/them to indicate the user has made the choice and the feature is working.

I propose we add they/them to the feature to avoid the appearance that the preference is biased against people who choose to remain gender neutral, and to ensure that all editors will have a way of knowing the feature actually works. Huggums537 ( talk) 19:03, 30 July 2021 (UTC)

[I need to make an amendment to this proposal to avoid any confusion on what it is about. I first brought it to Village Pump (Technical) because this is mostly about the feature technically not functioning properly where it will not display the choice of the user if they choose "Gender unspecified". This is not so much about the bias against they/them pronouns, but I thought I might throw that in there because it also incidentally appears to look that way. However, my main concern is the functionality, which can easily be solved with a simple text modification.

Therefore, I amend my proposal to modify the text as suggested by King of Hearts and Trappist the Monk in the manner described by Writ Keeper so that it shall say, "Gender unspecified" or "Unspecified gender" on the popup.]

As for they/them, y'all can debate about whether or not that makes it in until the cows come home for all I care. Huggums537 ( talk) 21:36, 30 July 2021 (UTC)

• Agreed, there should be a fourth option. We shouldn't force "they/them" pronouns on people who simply haven't made a choice, so we need to distinguish between actively neutral vs. passively neutral. -- King of ♥ ♦ ♣ ♠ 19:27, 30 July 2021 (UTC)
• By when another user hovers over the username the chosen pronouns will be displayed as he/him or she/her along with the user rights and other user groups of the user as well as their edit count and some other basic information about the user, I assume you're talking about Navigation Popups? That's a locally-maintained gadget, not a piece of the Mediawiki interface, and so changes to it would not go through Phabricator; instead, an intadmin would need to make the requisite changes at MediaWiki:Gadget-popups.js (specifically, line 4185, where an option other than he/him or she/her would need to be added, and line 7276, where a corresponding l10n string would need to be added. KoH's suggestion of an explicit difference between "they/them" and "unspecified" is a different matter, of course, but that would be neither sufficient nor necessary to add they/them support to NavPopups; changes to the script would still need to be made regardless of whether such a Phab ticket were filed. Writ Keeper  ⚇ ♔ 19:35, 30 July 2021 (UTC)

  Writ Keeper, I think this sounds correct. So, the changes under the new proposal would simply be to add "Gender unspecified" to the navigational popup so that it matches the current choices already being offered in the preferences and will show up in the popup the same as the other two choices. Huggums537 ( talk) 23:18, 30 July 2021 (UTC)

• ( edit conflict) I don't know what you mean by when another user hovers over the username the chosen pronouns will be displayed as he/him or she/her along with the user rights and other user groups of the user as well as their edit count and some other basic information about the user. I've never experienced that. I'm not really sure that I want to.

  Regardless, I don't particularly want to be addressed with they/them/their because there is (thankfully) only one of me. Alas, the default radio button 'Unspecified' doesn't really mean 'Unspecified'. So, for me the fix is to do as you say for those who prefer singular plural pronouns to select that and make 'Unspecified' really be 'Unspecified'. Or, better, dispose of the options altogether and stop the attempt to put us all into neat little boxes.

  — Trappist the monk ( talk) 19:40, 30 July 2021 (UTC)

  Sounds like the Wikipedia:Tools/Navigation popups extension. For you it's unspecified. A lot of people would refer to you as "they" by default, consequently, unless there are better pronouns to use for a person whose gender is unspecified/unknown(?) ProcrastinatingReader ( talk) 20:02, 30 July 2021 (UTC)

  Trappist the monk, I don't want to put anyone into "neat little boxes", but I do want to give everyone the options to choose, not dispose of them. So, that is why I support the idea King of Hearts has suggested about adding a fourth option to distinguish between active or passively neutral, and the way that could be accomplished is by integrating your idea of adding an option of "unspecified gender" right along with they/them, he/him, and she/her. That way a user has complete choice over how they wish to be addressed. Huggums537 ( talk) 20:57, 30 July 2021 (UTC)

  Trappist says she prefers not to be referred to as they and also doesn't want to specify any pronouns; that's cool. I won't refer to her as they.

  Without those neat little boxes, we end up with a default setting. That default setting has on the internet often been he/him. Allowing us to place ourselves into those neat little boxes means I don't get (too often) called he/him, which over the decades has become quite tiresome. The default setting moving toward singular they is IMO quite productive, but for those who both reject they and refuse to specify, each of us should feel free to come up with her own default setting. :) —valereee ( talk) 13:46, 3 August 2021 (UTC)

• See MediaWiki talk:Yourgender § July 2021 follow up from UTJW for discussion on the idea of the MediaWiki software having an option for users to specify that they do not wish to be addressed by a pronoun. ("Unspecified" was added to the text in the user preference setting based on the discussion.) There is a related Phabricator ticket. isaacl ( talk) 20:26, 30 July 2021 (UTC)

  Isaacl, except that "unspecified gender" does not appear when you hover over the username. As I mentioned before, it is just blank and shows nothing giving the appearance that it does not work for users who have decided to choose this option. At the very least, the text should be altered to say, "Unspecified gender" the way Writ Keeper has suggested. That way it will still be in compliance with the previous discussion while solving part of the problem as well. Huggums537 ( talk) 21:03, 30 July 2021 (UTC)

  Yes, I read your original post regarding what is presumably displayed by the navigation popups extension (perhaps you could confirm this). isaacl ( talk) 21:24, 30 July 2021 (UTC)

  Isaacl, sure, when I choose he/him or she/her my choice appears in the popup, but when I choose "Unspecified" nothing at all appears.... Huggums537 ( talk) 21:44, 30 July 2021 (UTC)

  So you're confirming that the popup in question is being displayed by the navigation popups gadget that you have enabled? isaacl ( talk) 21:59, 30 July 2021 (UTC)

  I'm only confirming the popup doesn't display all the options. I will try to verify which tool is producing the popup if I can, but I figured experienced editors around here would already know which one produces the information when you hover over a username, and Writ Keeper suggested it was the navigation extension and that sounds correct to me because I looked at the code and it has related information in it... Huggums537 ( talk) 23:30, 30 July 2021 (UTC)

  Isaacl, Ok, I think I have confirmed it is the navbox gadget. Huggums537 ( talk) 08:40, 31 July 2021 (UTC)

• they…

  This user considers singular they standard, modern, informal English usage, so avoids it on Wikipedia.

  ― Qwerfjkl talk 20:35, 30 July 2021 (UTC)

• How does this same thing keep going in circles?? The literal options for this value are already: unspecified, male, female. This is a language setting, and is part of software used globally - including in languages that only use gendered nouns (e.g. Userio vs Useria for "User"). This proposal is very vague and seems to be the XY problem - are you really trying to change the mediawiki software, or do you really want someone to just recode the local gadget? — xaosflux ^Talk 22:51, 30 July 2021 (UTC)

  Xaosflux, This is actually a simple and uncontroversial edit I'm proposing with no changes to the existing values in the mediawiki software. All I'm asking for is that when a user chooses "Unspecified" for gender neutral preferences that something will show up in the popup to indicate they have made that choice the same way it pops up he/him or she/her if someone chooses the male or female preferences. Currently, nothing at all shows up in the popup for "Unspecified". However, we could add two little words that say, "Gender unspecified" into the popup and that would at least show something that indicates a user has made that choice. It's not that complicated. Huggums537 ( talk) 23:08, 30 July 2021 (UTC)

Unspecified is the default at Special:Preferences. If a user has never touched or looked at their preferences then Unspecified is marked. There is currently no way to tell whether a user has deliberately chosen Unspecified or never done anything. The popup is only seen by registered users who have enabled "Navigation popups" at Special:Preferences#mw-prefsection-gadgets, a script made at the English Wikipedia by the editors. It's disabled by default and cannot be used by unregistered users. It would be possible for popups to say "Gender unspecified" instead of saying nothing, but popups has no way of knowing whether the user chose that or never chose anything. That would require a change in the MediaWiki software. PrimeHunter ( talk) 23:28, 30 July 2021 (UTC)

PrimeHunter, But why does it have to matter to anyone else if a user chose the option or it was defaulted to them in order for the option to be displayed like the others? Huggums537 ( talk) 23:36, 30 July 2021 (UTC)

Why does it have to matter that someone chose masculine or feminine pronouns? — Wug· a·po·des​ 00:45, 31 July 2021 (UTC)

Wugapodes, Don't ask me why it matters, ask whoever decided to inform everyone else of these pronouns with the popup information, but also decided to withhold the information about the non-use of any pronouns no matter if it was decided by default or not... Huggums537 ( talk) 02:42, 31 July 2021 (UTC)

My point being that you're fine with respecting the choice of those who choose a non-default option, but seem to not care about those who chose the neutral option. You may not care, but others do. — Wug· a·po·des​ 02:56, 31 July 2021 (UTC)

Wugapodes, these assumptions of what I do or do not care about are, and should be irrelevant to the discussion because what I care about has no effect whatsoever on the simple insertion of plain "Unspecified gender" text, and the text itself does not care one way or the other either, nor does the insertion of the text imply about any caring one way or the other since the text itself applies to both options so your point about what I do or do not care about seems rather moot. Huggums537 ( talk) 03:48, 31 July 2021 (UTC)

To be clear, "neutral" meaning that some people don't want the system referring to them with gendered language at all. You haven't explained how being told something is unspecified is helpful compared to just not specifying it. — Wug· a·po·des​ 03:01, 31 July 2021 (UTC)

Wugapodes, I've explained repeatedly in great detail that the plain and simple advantage of the proposal is making it visible so others can see it. If the helpfulness of that over just leaving it invisible like an unwritten law or unspoken rule isn't obvious, then I don't know what to tell ya. Huggums537 ( talk) 03:56, 31 July 2021 (UTC)

A better response here would have been that it doesn't matter if someone chooses male or female because the pronouns get displayed either way, and it should be the same with "gender unspecified" that it doesn't matter if someone chooses it, or the default chooses because the same chosen option gets displayed either way. Huggums537 ( talk) 11:55, 7 August 2021 (UTC)

No changes need to be made to the Mediawiki software if you disregard the idealism that somebody needs to know if the user made the choice or it was defaulted to them. You said the navigation popups would have no way of knowing, but I think the navigation popups would be the very least concerned about needing to know that so it would be no problem to just add "Unspecified gender" to the display and it will show up either way whether a user chooses it, or it gets defaulted to them. Simple. Easy. Huggums537 ( talk) 23:54, 30 July 2021 (UTC)

• It keeps going in circles because a tool is misusing grammatical gender to infer personal gender which are different despite their overlap (see Grammatical gender#Grammatical vs. natural gender). The software setting is designed to serve a specific purpose in internationalizing system interface messages, but we use it on EnWiki as a stand-in for the particular gender someone chooses to perform. This leads to repeated conflict when our cultural beliefs about personal gender don't line up with how the rest of the world's languages use noun classes. Unless MediaWiki or the gadget distinguish personal gender from grammatical gender, I would expect these discussions to continue going around in circles. ( edit conflict) — Wug· a·po·des​ 23:18, 30 July 2021 (UTC)

  Wugapodes, None of that makes any difference here since the proposal doesn't affect any changes to the international software. It only affects the local English Wikipedia Navigational popup so that the popup matches what the international software already says, and becomes visible to other users. It keeps going in circles because people keep seeing problems with this, and they aren't getting solved correctly. Huggums537 ( talk) 07:45, 31 July 2021 (UTC)

  Correct, this is why it should be removed, as its usage is incorrect. If people want to identify (gender or pronouns) somehow, they can write that on their talk page, we should not infer it from information we use for grammatical gender in the software language. — TheDJ ( talk • contribs) 16:50, 31 July 2021 (UTC)

  TheDJ, yeah just removing it alltogether if you can't please everyone is a novel solution, but then it deprives everyone of the feature. With this host of brilliant minds we have among us, surely we could come up with something to display that would be acceptable to everyone? I'll take any suggestions at this point. Surely there must be someone here with a better idea than mine for the display popup? Huggums537 ( talk) 19:28, 31 July 2021 (UTC)

  No we wil not come up with something acceptable to all. This is the internet. Therefor, less is more. — TheDJ ( talk • contribs) 07:26, 1 August 2021 (UTC)

• I swear. People on this site are way too freaked out about gender issues man. There really should be no big deal about simply letting other people know that a gender hasn't been specified... Huggums537 ( talk) 00:06, 31 July 2021 (UTC)
  • Some people do specify a gender, choosing the neuter. Ignoring people who try to explain that isn't going to build consensus. If you want to be pedantic, the lack of a "he" or "she" is a way of letting you know that a gender hasn't been specified because it's not specified. It's not ambiguous, and changing it will just annoy a different group of people. Pretending this is simple won't make it so. — Wug· a·po·des​ 00:45, 31 July 2021 (UTC)

    Wugapodes, adding the text "Gender unspecified" to the popup is not ambiguous either, and it isn't changing anything. It's only as simple as making the choice visible to others. The argument that not making the choice visible to others is your invisible sign that they have made the choice would be a great one if people could see invisible signs, but pretending people can see invisible signs won't make it so. Huggums537 ( talk) 03:21, 31 July 2021 (UTC)

• For context, there was discussion on what text to display instead of the previously-used icons in phab:T284783, "NavPopups should not use ♂♀ icons to describe how one wants to be addressed". isaacl ( talk) 04:40, 31 July 2021 (UTC)

  Isaacl, I think graphical icons representing gender are irrelevant to a discussion about adding text with an unspecified gender. Also, adding "Gender unspecified" was a new idea never even talked about in that discussion. I have struck adding they/them from the proposal, and that is the only relevance I can see there might have been from that discussion, so I see no real context there. Huggums537 ( talk) 07:09, 31 July 2021 (UTC)

  In addition, I would just like to note that I wish I would have been able to participate in these other discussions because I darn sure would have mentioned something to these proponents of the idea that gender matters in other languages, and we need to take that into account when considering our software/language/gender etc. decisions. My message to them would be a very simple one; "This is English Wikipedia, not X-language Wikipedia". Perhaps nobody else thought of that answer in previous discussions. I didn't go through them in great detail, but glanced over it enough to get the idea that people were making a fuss about how gender is approached in other languages such as Spanish. 07:25, 31 July 2021 (UTC)

  The discussion touched on why nothing is displayed when the "unspecified" option is selected in the user preferences, thus I provided a link for anyone interested in the context. The navigation popups gadget is deployed on other language Wikipedia and thus must be able to accommodate their requirements as well. isaacl ( talk) 14:26, 31 July 2021 (UTC)

  Ok, I guess that's fair enough context. However, I seem to be getting conflicting information about the nav popup gadget since other users have implied it's a tool local to the English Wikipedia only, suggesting it's use is different from the Mediawiki software where the preferences are used internationally. Huggums537 ( talk) 16:58, 31 July 2021 (UTC)

• According to Wikipedia:Database reports/User preferences#Gender (two years old), 98% of registered users have not specified gender. I assume it's lower for active users but the vast majority of unspecified are not real-life gender-neutral people but just users who haven't seen the option (it didn't always exist) or don't see a good reason to specify their gender. I don't think popups should use space on that, and I think many popups users do realize that if no gender info is shown then it's because the user hasn't given it. Displaying "Gender unspecified" may make users worry about whether they ought to specify their gender when they don't want to. I support just continuing to say nothing when nothing is specified. PrimeHunter ( talk) 09:51, 31 July 2021 (UTC)

  PrimeHunter, sure, to some negative nelly it might make users worry, but positive polly tells me there is every bit as good of a chance that the display may make users more aware that they have the option, and they very well may be more grateful that they have been shown they can now choose if they want to. I also think there are more than plenty enough users who don't realize that if they choose "gender unspecified" it will show nothing [there is any meaning at all behind nothing being shown] so enabling visibility is well worth it. Huggums537 ( talk) 11:17, 31 July 2021 (UTC)

  @ Huggums537: Or maybe they'll feel compelled to leave it blank but now be unable to? If they object to having "they/them" next to their name, the only thing they can do is change to "he/him" or "she/her". Gone is the option to blank it. That's a problem. Convince the devs to add a fourth gender preference and then maybe something can be done here. As is, this is unworkable. ProcrastinatingReader ( talk) 12:26, 31 July 2021 (UTC)

  ProcrastinatingReader, I *think* you are describing a problem that already pre-exists and trying to ascribe it to my proposal because users who might object to having they/them next to their name already have no other choice but to change to he/him or she/her if they want something different. Adding "Gender unspecified" to the popup display does not affect that, it only puts on display what currently already exists. Perhaps it's not my proposal that's unworkable, but the underlying preferences my proposal would represent that's unworkable. Huggums537 ( talk) 13:27, 31 July 2021 (UTC)

  From my perspective, I only came here to perform the ordinary task of enabling the display of simple user information, but I an not able to go ahead and do so because those who came before me already implemented the unworkable system that doesn't seem to allow that to happen. Huggums537 ( talk) 20:02, 31 July 2021 (UTC)

• Comment I think others from previous relevant conversations would benefit from being pinged to this discussion. Especially those that were specific to this exact particular topic such as [20] where a user brought up the exact same issue on Jimbo Wales talk page, and several users responded there including; Cullen328, Indy beetle, Sdkb, TheDJ, Floquenbeam (noping set), RGloucester, valereee, Khajidha, and Xaosflux. The other most pertinent conversation was: MediaWiki_talk:Yourgender#July_2021_follow_up_from_UTJW, where the only real new contributors were Whatamidoing (WMF) and SandyGeorgia. Both of these conversations focus on pretty much the same issue, and I think this is a good place to get it resolved now. If it says, "Gender unspecified" in the popup, then it would simply be an exact match to what we have already decided would be there in the preferences. The only difference is that it would now be visible to others, and I think this more transparent approach is much better. What are we hiding anyway? Huggums537 ( talk) 11:09, 31 July 2021 (UTC)
• Maybe I'm missing something, but the options here are 1) display "they/them" in pop-up, encouraging others to refer to the person as they/them; 2) display nothing in the pop-up, encouraging others to refer to the person as they/them, because that is the normal thing to do for most English speakers. It feels like we're being asked whether to print " This page intentionally left blank" or just leave the page blank. –  Joe ( talk) 11:33, 31 July 2021 (UTC)

  Joe Roe, those are the same old tired options of yesterday. There is a brand new brilliant option out now that is the wave of the future! Add "Gender unspecified" to the popup display. Huggums537 ( talk) 11:59, 31 July 2021 (UTC)

  Ah, I did miss something then. In that case, that falls afoul of a very good point made in phab:T284783: someone's gender does not equal how they want to be referred to. That's why the popup now has the pronouns directly, rather than an indication of personal gender. If somebody indicates that they want to be referred to as they, that doesn't mean that their gender is unspecified. Silence really seems to say more than words here. Or another option could be to let people customise what is included in the popup? –  Joe ( talk) 12:08, 31 July 2021 (UTC)

  You didn't miss anything. I was just tryna be funny. Silence really seems to say more than words here. Adding "Gender unspecified" doesn't "say" anything less than silence currently does. In fact, it says more because it informs other users of information that many were not aware of before. The point about whether somebody wants to be referred to as they or not is moot in this case because that has already been decided for us by default. All we are trying to determine in this discussion is if we want to display that decision or not. It's really that simple. If we stand by our decision, then we should have no problem putting that decision on display. Huggums537 ( talk) 13:01, 31 July 2021 (UTC)

• Whether one wants the software to refer to them by gendered pronouns or not, that choice could not, and would not mean one wants the software to publicly refer to them by the phrase 'unspecified gender', 'unspecified gender' is not a pronoun, and 'unspecified gender' is not a public statement they are being asked to make, however vague and ambiguous that would be, they are only being asked if they want a gendered public pronoun in communications. -- Alanscottwalker ( talk) 15:30, 31 July 2021 (UTC)

  Alanscottwalker, whatever one chooses the software to "refer" to them as when they are asked to pick a username could not, and would not mean one wants the software to publicly refer to them by the phrase, "User". "User" is also not a public statement they are being asked to make either. Yet, "User" appears twice in the nav popup and many other places across Wikipedia (very prominently on a userpage) because it is simple descriptive data used to convey information. So it is with adding "Gender unspecified". This idea that anyone is somehow being "referred" to something against their will is just ridiculous. Nobody is bitching about being "referred" to as "User" against their will, and rightfully so. It's getting way out hand. Huggums537 ( talk) 17:50, 31 July 2021 (UTC)

  They are a User. That's the word for anyone who uses a website. If anything, this proposal is what's ridiculous, and no need to bitch, at all. Alanscottwalker ( talk) 19:33, 31 July 2021 (UTC)

  Alanscottwalker, some really strange and far out weirdos might argue with you that they aren't a "User" at all. They might say they don't "use" anyone, and it offends them to be "referred" to as a "User". Just think about that for a moment because it's essentially the same strange argument that says one doesn't want to be "referred" to as "Gender Unspecified". Yet, "Gender unspecified" is just words to describe anyone who has that option enabled just as "User" is just a word to describe anyone who uses a website. So, hopefully you can see what I'm talking about when I say that kind of argument is "ridiculous". Huggums537 ( talk) 20:41, 31 July 2021 (UTC)

  Unconvincing -- one seems intentionally or inevitably unlikely to arrive at anything like hope, through a comment that begins with what looks like trolling or baiting, followed by irrelevant other stuff exists, and mangling of referent with respect to pronouns. -- Alanscottwalker ( talk) 12:55, 1 August 2021 (UTC)

  Alanscottwalker, I've participated very heavily in this thread, interacting with at least 95% of the participants, and nobody else has complained or suggested anything about trolling or baiting aside from yourself. Unfounded accusations against other editors can be seen as personal attacks. However, since you have not outright accused me of anything, I'm willing to forgive you this trespass if you are willing to understand that making such a suggestion is almost just as bad as making the accusation itself, and avoid doing it again in the future. Thanks. Huggums537 ( talk) 14:50, 1 August 2021 (UTC)

  The only thing unfounded would be that PA suggestion, my comment was on contribution, not person, founded in the prior comment. That your other comments may also be alot is no relief. Your arguments have not convinced apparently any of the others either; for my part, I've tried to explain, but I think we are at or passed any useful further discussion, here. -- Alanscottwalker ( talk) 15:32, 1 August 2021 (UTC)

  Agreed. ― Qwerfjkl talk 15:40, 1 August 2021 (UTC)

• Oppose: no real reason to do this. ― Qwerfjkl talk 15:56, 31 July 2021 (UTC)
• i have said what i wanted to say about this before. I also have no illusions this discussion will be resolved to everyone’s liking. — TheDJ ( talk • contribs) 16:12, 31 July 2021 (UTC)
• Hi! I made the Navigation Popups change that switched from the symbols to the current display of pronouns per Phab ticket T284783. I would be similarly happy to implement the result of this current discussion. Anyway, while I understand why you'd want "gender unspecified" in there, from what I can see from this thread and the previous linked discussions, there's no consensus for such a move. Heck, I think a pretty decent way to express an "unspecified" preferences setting is simply by not specifying a gender in the interface; I also agree with the rest of what Wugapodes said above. Tangentially, we could introduce a new preference specifically for pronouns and that would solve some issues, but people would just object that we already have a preference for that. Also, my worst-case estimate for how long that work (PHP, database, etc etc) would take is "forever", based on previous experience. So... not sure what to do, but I'll keep following the discussion. Again, feel free to ping me if anything gets decided, although I see the precise code change necessary has already been identified above by Writ Keeper. Enterprisey ( talk!) 08:00, 1 August 2021 (UTC)
• As Wikipedians, we have no gender. As humans (behind our accounts) we're either male or female. You can't change your XY or XX chromsome combinations, no matter what you identify as. GoodDay ( talk) 15:15, 1 August 2021 (UTC)
• I would support having a fourth option per User:King of Hearts, such as the following:

  She/Her - shows she/her in the nav popups

  He/Him - shows he/him in the nav popups

  They/Them - shows they/them in the nav popups

  Unspecified - empty/blank/nothing appears in the nav popups like it currently does right now

  That way editors who "actively" choose to use the pronouns They/Them will now have an option to see 'they/them' in the nav popups for their usernames if they wish; while editors who don't care enough or don't want to have their pronouns listed on Wikipedia can use the 'Unspecified' option. In both cases, the system will use the singular 'they' for the 'They/Them' and 'Unspecified' options, but the nav popups will show they/them for the former option and as blank/empty for the latter option. I also oppose any explicit "Gender unspecified/undisclosed/withheld, etc." wording in the nav popups; nothing should appear in the nav popups pronouns spot for the Unspecified option. Some1 ( talk) 16:27, 1 August 2021 (UTC)

  Support this proposal for a fourth option. – There is a difference between preferring to have one's gender identity undisclosed and actively expressing a nonbinary identity through the use of they pronouns. They pronouns should not be imposed on those who prefer to have their gender identity undisclosed on Wikipedia. RGloucester — ☎ 16:39, 1 August 2021 (UTC)

• The pursuit of an inclusive editing environment demands that we respect editors' gender identities. It does not demand that we let editors rewrite the English language. The singular they has achieved widespread use in English as a singular pronoun that does not connote anything about the person's gender, and as an English-language website, I really struggle to see any issue with us using it that way. {{u| Sdkb}}  ^talk 18:41, 2 August 2021 (UTC)

  Sdkb, the great irony of this argument is that it proudly waves the banner of inclusive editing high and mighty for a minority group of gender identities, while simultaneously excluding a majority group of "singular they" English speakers and writers it admits has achieved widespread use as evidenced by the Wikipedia link. This does nothing to further the cause of "inclusive editing" and makes the minority group appear to be hypocritical. Huggums537 ( talk) 02:36, 3 August 2021 (UTC)

  Huggums, in the three days this discussion has been open, you've commented 37 times. It's okay to engage the discussion, but there's a limit past which you go into WP:BLUDGEON territory. Please be mindful of that. If you are going to reply, please be clearer about your argument; I do not follow your point. {{u| Sdkb}}  ^talk 02:45, 3 August 2021 (UTC)

  Having just read your comment again, I think I might have totally misinterpreted it as being against using "they", when it is actually ok with using "they", and totally responded incorrectly. A thousand apologies. I shall strike it from the record since it was a misunderstanding. Huggums537 ( talk) 03:10, 3 August 2021 (UTC)

  Yes, my comment is in favor of singular they. Thanks for the striking; perhaps it's me who needs to be clearer. {{u| Sdkb}}  ^talk 14:58, 3 August 2021 (UTC)

• Support the proposal to have allow a fourth option of completely unspecified if the User's wishes to. We should not impose singular they on user's who do not want just like we should not impose generic he. We should allow flexiablity. As someone who rejects the use of my gender pronouns on Wikipedia (as my gender pronouns are not relevant to my editing here), whilst also rejecting "they" it is frustating to be forced into one, allow the flexiablity to have none. Regards  Spy-cicle💥  ^Talk? 20:59, 2 August 2021 (UTC)
• Simply remove the gender output from the popup gadget – it is not necessary. This would save a whole load of debate now and in the future. — GhostInTheMachine ^{talk to me} 09:09, 3 August 2021 (UTC)
• Singular They -- already abled? Noticed in examining [21], that the User on the right, in the Popup display is able to convey 'he' and 'they'. The pop-up, shows, quote: "Personal pronoun: he/his, singular they is OK too." So there might already be flexibility for rendering "they" or other pronoun choices, too. Enterprisey, Xaosflux or others familiar with pop-up, is that explained somewhere? Alanscottwalker ( talk) 13:33, 3 August 2021 (UTC)

  @ Alanscottwalker: nav pops does a few things; for your example of User:Reyk, they have set their interface to male - and navpopus uses this to populate the value in the top left corner of the popup. Navpops also provides some preview-text of a page, in this case the user has put the prose Personal pronoun: he/... on to his userpage, and navpopus has fetched it and delivered it in the preview section at the bottom of the box. — xaosflux ^Talk 14:00, 3 August 2021 (UTC)

  Ah, Thanks! So there is a way to get 'they' or something else in the popup. Is there a way to know what the popup will fetch and make sure it fetched that? -- Alanscottwalker ( talk) 14:14, 3 August 2021 (UTC)

  @ Alanscottwalker: I wouldn't count on it - NavPopups is primarily designed as an aid to fetch a popup for articles, it certainly is possible that it could fetch and include things based on keywords in the wikitext of userpages. However, it would bloat the script and require those wanting to use it to wave magic chickens over their userpage. The script is here: MediaWiki:Gadget-popups.js. It generally will include the first few lines of text on any page. — xaosflux ^Talk 14:39, 3 August 2021 (UTC)

  So, is that it fetches the first "uncoded" prose on the page? -- Alanscottwalker ( talk) 15:05, 3 August 2021 (UTC)

  @ Alanscottwalker: mostly (it will fetch wikilinks), the goal around it is mostly to fetch the lead of an article, so it tries to skip templates, etc. — xaosflux ^Talk 00:17, 4 August 2021 (UTC)

  Xaosflux and Alanscottwalker, I have also noticed it will capture the first image [and Wikilink] on the userpage as well. [See my popup for example.] So, if someone in the LGBTQ community wanted to fly an image of a rainbow flag, they could do that if they wanted to trouble themselves with setting up their userpage that way. Also, thanks Alan for sharing the link and bringing this up. Huggums537 ( talk) 08:40, 4 August 2021 (UTC)

  That gets me thinking... maybe you could write {{PrefersPronoun|(insert whatever pronouns)}} on your userpage and popups will replace its current display with that. Thoughts? Enterprisey ( talk!) 08:07, 4 August 2021 (UTC)

  @ Enterprisey: seems like that would be quite an edge case, keep in mind that statistically most editors don't use navpopups, and even less editors would discover and use magic keywords on their userpage to feed in to it (also would probably need some sort of input validation to prevent garbage values from messing up navpop). — xaosflux ^Talk 09:56, 4 August 2021 (UTC)

  I would suggest that an addition be made to Wikipedia:Tools/Navigation popups/FAQ (not that that is terribly easy to find). I would need help with technical wording/links, but something like:

• "Pronoun preference display:

  A User has a choice in ________ to choose gendered pronouns (she/he, her/his), otherwise the system defaults to singular they. When the User chooses gendered pronouns, their choice is displayed in popups. Another way to display various pronoun choices in popups, including neutral pronouns, is to configure your User Page so that the first untemplated prose on the page states something like, 'Personal pronouns: (your pronoun preferences, here).' "

  Alanscottwalker ( talk) 15:11, 4 August 2021 (UTC)

  Edge case it may be, but that's a weak argument given that it would be incredibly useful for people who actually need it. I can personally assure you that the Popups code is enough of a trainwreck that a few more lines of code won't "bloat" anything. Anyway, I just found Category:Pronoun user templates, so going through those and having Popups read them (in addition to allowing custom pronouns - but because that appears at the beginning of the popups message, people might use them as generic statuses!) Enterprisey ( talk!) 18:14, 4 August 2021 (UTC)

  I'm not opposed to it, as it is a opt-in script afterall. — xaosflux ^Talk 18:44, 4 August 2021 (UTC)

  Ahh, it's possible I misunderstood. I thought you meant "edge case" as in "too much of an edge case to be worth supporting", but if you meant "edge case" as in "we should do this in preferences and/or make it more visible to the user because 'a niche template to influence a niche gadget' is very undiscoverable and thus useless to most people", yes, I completely agree. Enterprisey ( talk!) 22:00, 4 August 2021 (UTC)

  Enterprisey, if I understand things correctly, a user can already use the popups as a generic status by simply adding the status before the first line of text on the userpage, right? Huggums537 ( talk) 06:44, 5 August 2021 (UTC)

• Like others have written the existing messages are written so that if an user does not define a gender it is assumed that is because of privacy reasons, not gender ones. If this proposal gets through, it does need to create/edit all messages with the gender magic word and reword them from being worded for privancy conserned editors to editors that do not define themselves as either male or female. If that is not done, then we end up with an mess where gender neutral users get fustrated with inappropriate messages. This is not just a matter of pronouns, some messages are worded in a specific way based on which pronoun should be used.-- Snævar ( talk) 23:43, 3 August 2021 (UTC)

  A few comments scattered throughout this discussion have made claims about what the purpose of the gender preference setting is. I've been looking at this off and on for a couple of months now, and I've come to some conclusions: The first is: This setting doesn't exist because of English. The second is: It's not really about your identity.

  Languages being what they are, every language has its own idea of how to cope with write about gender. Some few, including English, pay little attention to it compared to others. In some, linguistic nods to the gender of the speaker and/or the subject is pervasive. Russian is a typical example of this. You'll see in some Special:Log pages a statement like "WhatamIdoing moved Tyop to Typo". In Russian, you have to assign a grammatical gender to the verb for this sentence. You have to write "WhatamIdoing she-moved Tyop to Typo" or "That guy he-moved Tyop to Typo". There is not "neutral-moved" option in Russian. You either have to know, or you have to use the unspecified-gender default for that language.

  In the event that you are writing about someone whose gender is unknown to you, different languages take different approaches. In English, we often default to singular they if personal pronouns are necessary, but mostly pronouns aren't necessary, and gender doesn't otherwise affect English grammar. In Russian, I understand that they (currently/still) default to masculine for unknown subjects. In German, even if you know the person's gender, you use the grammatical gender that belongs to the noun, rather than the person: "Die Person moved her page; der Editor edited his page; das Neue needs help with its question" – using all three personal pronouns to refer to the same person.

  Main message: The point of this setting is to enable automated messages to make sensible grammatical choices in every language. For this setting to be functional, it needs to correspond to grammar needs. It is possible to construct an grammatically correct sentence in English with any of the three existing options. Therefore English doesn't need a fourth grammar option. (Swedish might; their four pronouns are roughly he/she/it/other it.) If you want an option for announcing your personal identity, then it really shouldn't get mixed up in this translation-focused setting. Whatamidoing (WMF) ( talk) 20:06, 6 August 2021 (UTC)

  • Hear, hear! To my understanding this is 100% accurate. Further, the impression I got from people who were deeply into working on these translations is that the existing three options are sufficient to the purpose for basically all languages.
    Note that, even if you're speaking English, the same value of the preference needs to be used for people who have their interface language set to Klingon or Sindarin or Simlish or whatever. While some languages have distinctions between animate/inanimate (e.g. "it"), formal/informal, adult/child, and the like, these can probably be ignored in the interest of not having a confusingly complex preference that wouldn't make much sense in many languages. "It", for example, seems likely to only really be relevant for people who don't want to anthropomorphize bots.
    Personally, I see the recent changes to the preference texts described at MediaWiki talk:Yourgender as a step backwards, as they seem to have confused people into thinking there's a meaningful distinction between "unspecified" and "specified the neutral default". All the preference is intended for is literally "How should MediaWiki describe you grammatically?", and it doesn't matter whether MediaWiki uses "they" because you haven't specified or because you specifically chose "they" or because you chose "they" because you didn't want to pick "he" or "she". That's also how Popups should represent it, in whatever specific manner the developers of that tool want to realize that. Anomie ⚔ 03:25, 7 August 2021 (UTC)
  • What if you don’t want MediaWiki to refer to or describe you at all? Is there an “opt out”? Blueboar ( talk) 12:04, 7 August 2021 (UTC)
    • Not really, you can't hide your actions from others. The only solution is to not make any actions in the first place. Note that even creating an account is an action, which will generate a log entry along the lines of "User account X was created", so you'd have to start by not creating an account. Anomie ⚔ 12:49, 7 August 2021 (UTC)
      • Before this thread closes, I'd like an opportunity to point out that the proposal was not aimed at changing any grammatical structures of the gender settings, and the whole point of it all was only to merely make all of the currently existing settings visible in navigational the popup, which currently excludes the default singular they pronouns setting, but includes the male/female pronouns settings. However, there is no good reason for the excluding the visibility of the setting if the grammatical functionalities of the settings are the same regardless of whether the setting is visible in the navigational popup or not. Huggums537 ( talk) 17:01, 28 August 2021 (UTC)

  With all due respect to the freedom of choice and everything related, I oppose all of these suggestions, including the fact that we're even discussing it, for the simple reason that we are dealing with anonymity. We are not face to face discussing things - we don't even know who we're collaborating with, for Pete's sake. This isn't a university campus - it's a virtual community of anonymous volunteers, all of whom are supposed to be here to help build the encyclopedia. Why are we focusing on gender and not the work and reason we're here? If the article isn't gender-related, move along. We don't have time to go check pronoun preferences of anonymous editors when we're in the throws of an important discussion that is directly related to building this encyclopedia. We should not have to focus on the volunteers. I do believe that being respectful toward one another is expected, regardless of race, color, creed or gender - none of which we know because of anonymity, and I'm happy not knowing. Everyone's time here is valuable and deserves equal consideration. Most of all, I dread the thought of an editor forgetting the proper pronoun of an anonymous editor they oppose in a TP discussion, and then find themselves at the dramah board because they used the wrong pronoun. I've already seen that happen. There are too many variables, and we have far too many wikilawyers on WP. I'll share the advice I got from an admin when I was feeling offended: "grow thicker skin". Atsme 💬 📧 13:42, 7 August 2021 (UTC)

  With all due respect Atsme, those were people purposefully and intentionally misgendering someone over an extended period of time, which I'm pretty sure you already knew. There's no need to be an alarmist. Mistakes are occasionally made, and I've never seen that escalate to what you're "afraid of". If it ever did, it would be dismissed almost immediately. Symmachus Auxiliarus ( talk) 00:54, 8 August 2021 (UTC)

  Atsme, you've also oversimplified the entire conversation into being merely about focusing on anonymous volunteers and their gender in order to justify a position opposing the entire discussion on the basis it's not related to building Wikipedia. However, the very fact that so many have participated here with their thoughts and opinions regarding privacy, and rights to choose as well as gender is ample evidence there are issues in this discussion that are of importance to Wikipedians, and obviously worth considering in a community discussion, otherwise we wouldn't participate at all. I see no valid reasons for any support of you implying a spirit of building Wikipedia while simultaneously dismissing a whole community for their participation in the discussion - keeping in mind that community discussion itself is an important part of "building an encyclopedia". Without discussion there is no consensus, without that, there's no Wikipedia to build. Huggums537 ( talk) 07:31, 8 August 2021 (UTC)

  Symmachus Auxiliarus, I was not referring to that case. Huggums537, I understand and sympathize with your concerns, but the bottomline hasn't changed. We are here to focus on editing, not editors. We did not volunteer our time for any other purpose than to help build the encyclopedia; i.e., create content, copyedit articles, stop vandalism, help newbies edit articles, etc. We are not a social platform to advocate for social issues, and there is also WP:RGW. Those are things we dedicate to the time we spend in real life, not here on WP as editors who have graciously volunteered our valuable time to help build the encyclopedia. We are either going to choose anonymity (all the way around which would include gender), or choose to make our real life identity known. Which is it? Beyond that, there should be no obligation for us to be anything beyond polite (collegial) and helpful. Anything short of that, such as launching hurtful PAs and creating unambiguous disruption at an article or other WP venue, would be actionable, but that is why we have administrators. It is also not an editor's responsibility to act as "thought police". Perhaps this essay will help put things in perspective, as it did for me (rather shockingly) when I first read it; it applies to all of us. I have adopted a sticks and stones approach to words because it is a more realistic approach to living in the real world. Atsme 💬 📧 16:11, 8 August 2021 (UTC)

  Atsme, it seems to me the only one here focusing on other editors, advocating for (or against) social issues, or righting the great wrong of not building an encyclopedia is actually yourself. I personally strongly disagree with Wikipedia:Wikipedia does not need you (even though I respect the author), for the very simple fact that there would be no Wikipedia without "you". The only real world purpose that type of essay serves is to scorn [ostracize] others. Even you admit it was "rather shockingly" put into your perspective, and I think someone would almost have to be in a state of shock allowing for [adopting] such a perspective. However, some other essays (with far less shocking perspectives) worth considering are: Wikipedia:Editors matter and Wikipedia:Wikipedia is a community. Huggums537 ( talk) 19:55, 8 August 2021 (UTC)

Survey (alternatives)

• What do editors contributing here think about some alternative wording other than what has been suggested in this proposal that we could use in the navigational popup display to indicate to others that the neutral option has been selected? A few examples that come to my mind are:
  1. Gender undisclosed
  2. Gender withheld
  3. Neutral pronouns
  4. No pronouns selected

Huggums537 ( talk) 01:04, 1 August 2021 (UTC)

• Support option 3 or 4 as these do not use gender language, and refer only to the pronoun usage just as the he/him and she/her model does so this is more in line with past discussions about how this whole thing is about language, and how pronouns are used rather than gender. Huggums537 ( talk) 01:27, 1 August 2021 (UTC)
• Option 5, none of the above. In other words, leave it as it is. As I tried to communicate above, there's no reason to fiddle with the pronoun display. —  JohnFromPinckney ( talk / edits) 09:59, 1 August 2021 (UTC)

  JohnFromPinckney, I have not seen where you tried to communicate above... Huggums537 ( talk) 13:31, 1 August 2021 (UTC)

  Exactly. I haven't written anything at all before this. What do you suppose that communicates? —  JohnFromPinckney ( talk / edits) 05:36, 3 August 2021 (UTC)

  JohnFromPinckney, Ok, yeah you got me. That was pretty good bait for fishing man. Huggums537 ( talk) 06:22, 5 August 2021 (UTC)

  This response gave me a good chuckle Sdrqaz ( talk) 00:03, 6 August 2021 (UTC)

• Option 5, none of the above. This is not about specifying gender, but specifying pronouns. There is no way in natural English to easily avoid using pronouns for somebody. The only viable options are (a) leave it as he/him, she/her, they/them; (b) introduce more options to choose from (e.g. sie/hir); (c) have free text boxes where people write in what they want for each part of speech; or (d) a combination of a+c or b+c. In all cases there would need to be either a default (which would be they/them) or a requirement for people to explicitly choose before being allowed to edit (this is incompatible with allowing unregistered users to edit). While I would happily support a, b or d (and maybe c) this is not what is being proposed here. Thryduulf ( talk) 11:15, 1 August 2021 (UTC)

  Thinking more about this, unless there are changes to the current three options, then all of 1, 2 and 4 imply that only he or she are valid options and so should be opposed as actively harmful and 3 is essentially the status quo - default to gender neutral unless someone has actively chosen something else. Thryduulf ( talk) 13:41, 1 August 2021 (UTC)

• Support options 3 or 4 per Huggums537. Ideally we would have a free text option where people can choose whatever pronouns they want in order to accommodate the less common options without us needing to enumerate them all and maybe miss some valid options. Unfortunately, that would need some policing as I'm sure that the "attack helicopter" weenies would try to have their idea of "fun" with it. That doesn't seem to be an option here anyway as all we know is that the user has chosen one of three options. Without further information about what the user wants, 3 or 4 is the best we can do. -- DanielRigal ( talk) 13:15, 1 August 2021 (UTC)
• None of the above - I don’t want anything to appear about my gender or my pronouns when you hover over my name. I don’t want it to say “this user did not choose” or “unspecified”, or anything. I like the fact that if you do not click a button, nothing appears. Blueboar ( talk) 14:29, 1 August 2021 (UTC)

  Blueboar, If you do click the button nothing appears also... Huggums537 ( talk) 14:40, 1 August 2021 (UTC)

Ah... Don't care what does or does not happen when you do click a button, as long as nothing appears when you don't. Blueboar ( talk) 15:01, 1 August 2021 (UTC)

Is the problem that we need more than just three buttons for people (those who want to these click buttons) to click on? Blueboar ( talk) 15:52, 1 August 2021 (UTC)

Blueboar, I think a lot of people are saying that is a problem, yes. Huggums537 ( talk) 06:17, 5 August 2021 (UTC)

• Comment - What if an editor identifies as a Banjo? Does it really matter? GoodDay ( talk) 17:21, 1 August 2021 (UTC)

I would assume (perhaps incorrectly) that a banjo would want “it/its” displayed as its preferred pronoun when someone hovers over its username. Or at least have that as an option. Blueboar ( talk) 17:35, 1 August 2021 (UTC)

This comment, especially considering the context of its author, appears to be mocking individuals who identify as non-binary. That's absolutely unacceptable. {{u| Sdkb}}  ^talk 18:31, 2 August 2021 (UTC)

That may be inferring a bit too much in the comment in my view, for all I knew it could referring to the adage On the Internet, nobody knows you're a dog (or "banjo"). To my knowledge, GoodDay does not have a history of mocking indivduals (but you are welcome to prove otherwise). Regards  Spy-cicle💥  ^Talk? 16:12, 6 August 2021 (UTC)

Completely meaningless whether GoodDay has a "history of mocking individuals" or not. At worst it's an uncalled for comment mocking other users, and at best it adds absolutely nothing to the conversation. Aza24 ( talk) 20:00, 7 August 2021 (UTC)

This is a known transphobic joke. Assuming good faith, GoodDay should probably heed their own advice and bow out of this discussion and any other discussions pertaining to gender identity. Isabelle ^🔔 13:35, 8 August 2021 (UTC)

Indeed, I'm not a fan of Wikipedia bending political correctness to the breaking point, on this topic. Thus my overall reluctance to participate in such discussion. Now, please folks, no more pinging me :) GoodDay ( talk) 13:51, 8 August 2021 (UTC)

• Support option 4 the usage of completely unspecified if the User's wishes to. We should not impose singular they on user's who do not want just like we should not impose generic he. We should allow flexiablity. As someone who rejects the use of my gender pronouns on Wikipedia (as my gender pronouns are not relevant to my editing here), whilst also rejecting "they" it is frustating to be forced into one. Just simply allow the flexiablity to have none. Regards  Spy-cicle💥  ^Talk? 20:59, 2 August 2021 (UTC)

  Please don't duplicate your comments.― Qwerfjkl talk 21:21, 2 August 2021 (UTC)

  Spy-cicle, Hi. It appears you are now supporting two different option 4's. The 'option 4' mentioned in the prior section is different from this. Alanscottwalker ( talk) 13:52, 3 August 2021 (UTC)

  To clarify Alanscottwalker as the first discussion question was not clear. I support any option which allows users to have an unspecified gender/gender pronoun (or the option to opt out entirely) whilst allowing those who choose an unspecified gender/gender pronoun to have the option to not have "they/them". Hope that helps. Regards  Spy-cicle💥  ^Talk? 15:55, 6 August 2021 (UTC)

• Question: Is there a way to NOT have any “default” setting (at all)? Blueboar ( talk) 14:20, 3 August 2021 (UTC)

  @ Blueboar: no, even if the schema for this database value were expanded to allow "nul" as a value - something would still be the 'default' (even it is were "nul"). The current default is unspecified. — xaosflux ^Talk 15:01, 3 August 2021 (UTC)

Ah... THAT'S the problem. Blueboar ( talk) 16:36, 3 August 2021 (UTC)

• Option 5, fix MediaWiki settings I've used Nav Pops for years. At some point I noticed that there was a male or female symbol in the popup (they were recently changed to he/she). I also noticed that some users (like myself) didn't have a symbol, because they had not chosen their gender (pronouns). There is no need to clutter the tiny popup with any additional "gender unspecified" text, because most users who use the gadget will eventually understand how it works. If you don't see he/she, you can use "they", or check the editor's user page to see if they have more information about their preferences there. However, I do think it would be best if the MediaWiki settings had a fourth option, so that there would be a real option for users who want to actually choose something else than male/female pronouns. Then the Nav Pops gadget could show "they" for those who had really chosen it. - kyykaarme ( talk) 19:41, 3 August 2021 (UTC)
• Support 3 and 4: users who have not specified their gender should default to "unspecified" and have nothing render in the popup. Users whose pronouns are they/them should be able to select that setting so that "they/them" appears in the popup. "Not disclosed" and "withheld" both fall under "unspecified" unless we want this to be used for soapboxing. Ideally we would have a fifth free text setting which would tell popups to render whatever the user specifies but that the software would treat the same as gender neutral (for templates and whatnot), but without admins being able to override the setting this would be an open door to vandalism. Ivanvector's squirrel ( ^trees/ _nuts) 15:06, 5 August 2021 (UTC)
• Oppose all - per my discussion above. Atsme 💬 📧 14:09, 7 August 2021 (UTC)
• Oppose all - We're supposed to be here to make an encyclopedia, not to do random junk. 50.201.228.202 ( talk) 15:16, 7 August 2021 (UTC)

  50..., for what its worth - absolutely none of any part of this discussion will have any impact of editors without accounts. — xaosflux ^Talk 17:24, 7 August 2021 (UTC)

• Oppose all per my comment above. Despite being labeled a survey, this section does not have the possibility of reaching an actionable consensus, since any survey that leaves out the status quo option is inherently leading. {{u| Sdkb}}  ^talk 17:56, 7 August 2021 (UTC)

  Sdkb and Stifle, I did not think to add the status quo as one of the selections, and wasn't intentionally leading anyone. Would either of you consider choosing an option if the status quo was also a choice? Also, do you think everyone would be okay if I retroactively add the status quo to the selection in order to avoid leading anyone? Huggums537 ( talk) 22:41, 9 August 2021 (UTC)

  After more than 13 responses? No, way too late. —  JohnFromPinckney ( talk / edits) 22:54, 9 August 2021 (UTC)

  Ok, that's fine since it doesn't need to be there anyway because I have observed that plenty of other people have been able to choose the status quo option without the selection being made available to them and without them making any insinuations about anyone leading them either. So, it should seem fairly obvious in anyone what good faith that the option is not truly needed anyway. Huggums537 ( talk) 23:10, 9 August 2021 (UTC)

• Oppose all per Sdkb. Stifle ( talk) 16:30, 9 August 2021 (UTC)
• Support the four options proposed by Some1. Clovermoss (talk) 22:38, 18 August 2021 (UTC)

Discussion: Optional user generated choices

There has been some conversation above between Xaosflux, Alanscottwalker and Enterprisey about enabling a user generated script, or maybe simply placing a notice letting users know they can generate their own popup if they choose to alter their userpage. I also noticed users such as Valereee were in favor of such an idea while Kyykaarme and TheDJ suggested people check userpages indicating this might be a viable option for such users. I'd like to get thoughts from the community on this option as well. Whatever the outcome of this entire thread, I've already recently enabled this option on my own userpage as an example that can be seen if you hover over my username and have the navigation gadget enabled in your preferences. Huggums537 ( talk) 11:45, 7 August 2021 (UTC)

@ Huggums537: I currently use the {{ User They them pronouns}} infobox in my profile to let others know my preference. Right now, that's the best option, seconded only to have one's pronouns in their signature (which I'd rather not do, for aesthetic reasons). I think that having a way to transpose that information to the pop-up gadget would just make things easier for all. I personally use the pop-up to check other user's pronouns when talking to someone I haven't talked to before. Isabelle ^🔔 13:40, 8 August 2021 (UTC)

Isabelle Belato, yes, I'm also using the same userbox for my selection as well. However, the selection doesn't appear in the nav popup either. I had not thought of putting it in the signature. That's a novel idea, but I rather like approach I'm currently using to add the line of text to my userpage and allow nav popups to fetch it for me because it solves my problem, and it looks like nothing I've suggested in my proposal is going to pass, but hopefully the community will put a notation somewhere to let others know they can do the same thing I've done if they choose to. Huggums537 ( talk) 18:10, 8 August 2021 (UTC)

I have started a 2021 RfA review and accompanying RfC to identify what issues, if any, there are with RfA. Interested editors are invited to participate. Best, Barkeep49 ( talk) 01:41, 29 August 2021 (UTC)