Some boxes like notifications that an article may be merged or split might not be something a passing user would want to know. Perhaps having those contained within a pre collapsed box would be better. Or maybe a generic notification that there are administrative (or something) things to be aware of and going to the article talk page gives more information.

2600:6C4E:1200:1E85:B409:AC04:8255:CFA1 (talk) 16:26, 15 February 2023 (UTC)

Every reader is a potential editor, and if they don't know what might need fixing in an article, they can't do it. 331dot (talk) 16:38, 15 February 2023 (UTC)

Also, this would be in violation of MOS:COLLAPSE. Collapsed content can often be harder to access for readers on mobile devices and particularly on screen readers. Joseph2302 (talk) 16:43, 15 February 2023 (UTC)

Hello all. Myself and User:Ser Amantio di Nicolao have been adding 'Use ... English' maintenance templates (e.g. Template:Use British English) to articles that deserve them en masse utilising AutoWikiBrowser, however another admin has suggested that we gain consensus before continuing doing this. I believe the argument against was that it's [neither] necessary or desirable to place that tag on tens of thousands of articles (see this short discussion). A bot was suggested to carry out this purpose, however I believe that the nature of these tags, i.e. garnering context from the article itself, requires a human edit. Neither of us see anything undesirable about adding this maintenance template per se, however we both paused our efforts until some sort of discussion had been had. Any comments on this would be most welcome. Thank you and best wishes. SɱαɾƚყPαɳƚʂ22 (Ⓣⓐⓛⓚ) 19:58, 6 February 2023 (UTC)

I would tend to agree that these edits are unnecessary, and making thousands of unnecessary edits is undesirable. Unless there has been some kind of editing history on a particular article that would suggest this template is needed, then it is probably better not to add it. PS, I note that it seems to be classified as a maintenance template, but it really is not a maintenance template because no maintenance is required on these articles. — Martin (MSGJ · talk) 20:24, 6 February 2023 (UTC)

To be frank, I think the problem is with the template. What purpose does the template serve? Perhaps the idea is so discrepancies like a ((Use British English)) article containing "color" (not "colour") are automatically identified, but I'm not convinced that this is worth the wikitext it takes up at the top of the page. There must be a better way to do this. I can't really fault the editors here for adding a tag to applicable articles, but I don't think their actions are useful. — Bilorv (talk) 21:41, 6 February 2023 (UTC)

I see the value in having an explicit statement that a given variety of English is used on an article when it is not obvious which should be used (Seattle and Tony Blair are obvious, Acre isn't), especially if the article has had to be actively cleaned up from multiple varieties. I think bots can (or at least would have the capability to) standardise in some cases, e.g. adding or removing the spell=us parameter from ((convert)). Thryduulf (talk) 22:42, 6 February 2023 (UTC)

Over half the audience won’t care either way, as they are neither British nor American….. ;) —TheDJ (talk • contribs) 00:02, 7 February 2023 (UTC)

If only there were a way to make everyone happy. There could be a setting in your preferences asking what your preferred ENGVAR is and words like col(o|ou)r, defen(se|ce), etc. were templated to conform to your ENGVAR regardless of the topic's ENGVAR. Number templates could default to lakh and crore instead of thousands and millions for our Indian readers. To me, that is more useful than slapping ((Use British English)) on top of a page. –Fredddie™ 01:13, 7 February 2023 (UTC)

Not a bad idea, but only if it could be done via some widget or script in your browser, and not if it's visible in the Wikicode, which would pollute the code in a way making it harder to maintain, and likely would have other knock-on effects. Mathglot (talk) 02:02, 7 February 2023 (UTC)

Because of things like torch/flaming torch/flashlight, or truck/bogie, it's difficult to do an automated straight substitution without additional markup in the source text in some fashion. Variations like "licence/license" are tricky too, since the spelling depends on whether or not the word is a noun or verb. isaacl (talk) 17:40, 7 February 2023 (UTC)

Years ago we had a system (date preferences) in which you could set the format in which dates would be shown in your preferences. It required that all dates be wikilinked in a specific pattern. It was deprecated because it was clumsy, and only worked if you were logged in. Remember, users who are not logged in (most of our readers) do not have preferences available. Donald Albury 02:08, 7 February 2023 (UTC)

If the only downside is that "it doesn't work for IP users", then I think that's not a major problem. IP users already miss out on all sorts of benefits, and it's by their own choice. If they are "forced" to view articles in whatever the default English is, I would say that is extremely minor inconvenience. Specifically: implementing Fred's idea would not make any IP user's viewing experience worse than it is now; it would only improve the experience of other users. I don't see a downside to this. Mathglot (talk) 02:15, 7 February 2023 (UTC)

It works perfectly on the Chinese Wikipedia, where you do not need to log in to switch between simplified and traditional Chinese (and a few sub-varieties). —Kusma (talk) 09:10, 7 February 2023 (UTC)

I thought it was deprecated because of MOS:OL and, on the developer side, concerns over cache-splitting. Anomie⚔ 14:29, 7 February 2023 (UTC)

• Disagree A number of articles have popped up on my Watchlist, with edit summaries saying, "Use Ghanaian English". Now, I'm not surprised that Ghana has its own variety of English, but honestly, that notice on the page does only one thing wrt my editing at the article: it discourages it, and waves me off, since I haven't a clue about Ghanian English, and even if it's pretty close to Commonwealth or some other English, as soon as I have it under my belt, then the next article that hits my list is going to say, "Use Liberian English", and now I'm going to have to start using that? I've got about all I can handle dealing with US, UK, OZ, NZ, Canadian, and Oxford English, and I'm willing to go out on a limb once in a while for a worthy article in Caribbean or maybe Nigerian English. But as for articles in Ghanaian English and Liberian English and Pitcairn English and all the rest, count me out; someone else can go edit those articles in that case; it's more effort than I'm willing to offer. Mathglot (talk) 01:54, 7 February 2023 (UTC) Clarifying: agreeing with the STOP sign from the admin; disagreeing with placing any more of these. Place the bot in reverse, and have it undo all the ones it did. Mathglot (talk) 01:57, 7 February 2023 (UTC)

  Lol, I thought that was a joke but ((Use Ghanaian English)) is real and is used in 2402 pages, for example Accra added on 29 January 2023. That is beyond crazy. I would like the wikitext to tell me whether to use color or colour (or whether to revert an edit that changed that spelling), but adding stuff like Use Ghanaian English has no point beyond increasing one's edit count. Johnuniq (talk) 02:30, 7 February 2023 (UTC)

  Not a joke. Most of them have scrolled off my Watchlist but I found this recent one at Kwame Nkrumah. Worse, are these two recent examples:

  rev. 1136291731 at Accra, with the edit summary, "Use Nigerian English" (Accra is the capital of Ghana), and

  rev. 1136292968 at Cape Coast, with the edit summary, "Use Nigerian English" (Cape Coast is a major port in Ghana).

  That's just carelessness. Can someone help me set up an AWB run, so I can place one Trout on Ser Amantio's Talk page for each incorrect edit summary, and a big, golden mega-trout for starting this without consensus? That could be eight thousand trouts, but it's healthy protein, and could help the global supply. Mathglot (talk) 02:45, 7 February 2023 (UTC)

  I've long wished that the people who have the idea that every country in the world needs to be flagged for its own variety of English would include in these templates' documentation an explanation as to how exactly those varieties actually do vary from American or Commonwealth English when written in an encyclopedic register. I see no need to care about varieties that differ only in slang, or in colloquial registers, or in spoken pronunciation (at least until "SpeakGPT" exists to make natural-sounding spoken versions of articles in an appropriate accent), or the like. Anomie⚔ 14:38, 7 February 2023 (UTC)

  The issue is that documenting all of the differences would be tedious and no one is interested in doing the work (true for documentation in general). Most of the time this probably isn't a big deal if someone puts "color" or "lorry" into an Australian article there are enough Australian editors that they will be converted to "colour" and "truck" with no documentation needed; there's probably also enough Kiwis around that instances fjord will be converted to fiord without us needing to document that peculiarity of NZ English anywhere. On the other hand I'd be surprised if we had even a handful of regular Ghanian editors so without documentation changes will happen only slowly.

  It's also best to remember that some national varieties of English are tagged separately solely to be polite. There's no functional difference between British and Irish English when written in an encyclopedic register; Likewise for Indian and Pakistani English, but the shitstorm that would ensue from trying to replace all transclsuions of the Irish template with the British one, or the Pakistani one with the Indian one far outweighs any benefit. As a practical matter tools can be instructed to treat the two identically, and it's actually easier for new editors to manually tag correctly per TIES when tag names directly match country names anyway. 74.73.224.126 (talk) 16:14, 9 February 2023 (UTC)

  I'm not sure that even that isn't a solution in search of a problem. Surely it's better to have sourced content with Us and Zs in incongruous places than to not have the content at all? HJ Mitchell | Penny for your thoughts? 17:46, 9 February 2023 (UTC)

  Agree, in fact I suspect most pages are not fully MoS compliant, and in general MoS issues are pretty far down the priority list of editorial standards. 74.73.224.126 (talk) 17:56, 9 February 2023 (UTC)

  I like my articles to look pretty and be neatly formatted and consistent throughout. But most of all I like them to be informative. HJ Mitchell | Penny for your thoughts? 17:59, 9 February 2023 (UTC)

• Disagree, not seeing what the value of these templates is. The dmy and mdy templates actually have purpose, interacting with the citation templates. The documentation of Template:Use British English says that all it does is add a category, in which case all it does is duplicate the talkpage notices (themselves not always a great use of screen space). CMD (talk) 06:29, 7 February 2023 (UTC)

  Playing Devil's advocate here a bit: there is a legit value, imho, in having some of them, some of the time: for cases where MOS:TIES doesn't apply but MOS:RETAIN does apply, it's useful to have had someone else go through the article history before me and figure out what the stable usage was at the beginning or has been up till now, so I don't have to figure it out for myself for every article. I wonder if those templates, in articles where there's consensus that they really do help, would work better in an WP:EDITNOTICE, than as a inline template in the article? We don't really need to know what version of English it is, unless we decide to edit it. Mathglot (talk) 10:05, 7 February 2023 (UTC)

  There is some value some of the time, but that is already provided for by the talkpage templates (which are indeed sometimes put in edit notices). CMD (talk) 15:41, 7 February 2023 (UTC)

• I think these are mostly make-work edits and aren't helping editors. Unless a page has had a recurring issue that has since been resolved about dialects this isn't helping editors - and may actively discourage casual editors who should be most concerned with adding relevant verifiable content, not which spelling their prose used. Further, most any massive templating shouldn't be done except by a bot - it just annoys watchers and recent change patrollers. — xaosflux ^Talk 14:45, 7 February 2023 (UTC)
• Deciding on a variant of English to use, and harmonizing a whole article onto it, is good practice when you're trying to bring an article to GA or FA class, but I don't see the point of doing it en-masse. As a side note, while I have no interest in telling anyone what to do, I just don't understand why so much of Wikipedia has turned into menial busywork. Why is it that the vast majority of articles I come across are substantially unchanged from ~2010-2013, save from Wikignoming? Surely article expansion is more rewarding? DFlhb (talk) 19:30, 7 February 2023 (UTC)

  Exactly. Ppl seem very busy 'standardizing' things to a level that is never achievable (for long) in a public editing model by thousands of (imperfect and untrained) people. It is better to accept certain imperfections and mistakes of the users. It is part of what makes it a wiki. —TheDJ (talk • contribs) 21:58, 7 February 2023 (UTC)

• Disagree, per Xaosflux. I can sympathise with the intent, but mass changes can very easily become disruptive and there's no pressing need that justifies it in this circumstance. XAM2175 ^(T) 12:33, 8 February 2023 (UTC)
• No mass addition, although the templates can be useful on a case-by-case basis. Like Mathglot above, if I see "Ghanaian English" I would be quite reticent about touching the article. And FWIW, our Indian articles are generally dreadful, not just for lack of sourcing, but because of the abysmal strings of characters which I understand are supposed to pass for "Indian English". I think the weird capitalisations are mistakes, but they're so predominantly "wrong" (to my USian eyes), that I wonder if there's not actually a system. The grammar, meanwhile, just seems sloppy. Summary: templates are useful, added individually and selectively, but would be even more useful if, as above, there were some clue about what they mean. Stop adding these by bot. — JohnFromPinckney (talk / edits) 14:36, 8 February 2023 (UTC)
  • We have a long article on Indian English, which in most cases is like British English, but this is a second language to most users, and exists in several registers. Academic Indian prose is virtually the same as British, or intended to be so, but most of our Indian editors aren't academics, and lean towards the colourful Indian form of journalese, just as huge numbers of American editors do towards their local version. Johnbod (talk) 15:49, 8 February 2023 (UTC)
• No mass addition. Whilst I did appreciate ((Use British English)) being added to 5-10 articles I started (as I usually add them myself), I don't see a general need to add them, particularly when it's not clear to the majority of people what the differences between some of these are. E.g. Despite being English, I'm not really sure what the differences between British, Indian, South African English would be (other than Indian articles might use lakh/crore). Joseph2302 (talk) 16:32, 8 February 2023 (UTC)

  @Joseph2302: a tiny point but I believe that you shouldn't use lakh/crore per MOS:COMMONALITY, the idea being (correct me if I'm wrong) that an Indian reader will still understand "100 million" but a non-Indian reader is unlikely to be familiar with "10 crore". — Bilorv (talk) 11:08, 16 February 2023 (UTC)

• No mass addition, especially for the more specific variants. I agree with Xaosflux's comments about these are mostly make-work edits and aren't helping editors and may actively discourage casual editors who should be most concerned with adding relevant verifiable content, not which spelling their prose used. Among other things, some of these templates such as ((Use Trinidad and Tobago English)) strike me as not helpful - our article on Trinidadian and Tobagonian English seems to be describing it as essentially a dialect more than a standard variety. I don't think anyone would consider ((Use Southern American English)) to be useful, and several of these strike me as a similar level of over categorization. Hog Farm _Talk 19:41, 8 February 2023 (UTC)
• Oppose Far too nuanced a matter to use any mass addition method. --Jayron32 14:14, 10 February 2023 (UTC)
• Insufficient data How is the decision made as to which language template is added?? · · · Peter Southwood ^(talk): 15:13, 11 February 2023 (UTC)
• No mass addition because as per Mathglot the templates run a risk of deterring editors who feel they can't write Pakistani English, so their use should be kept to an absolute minimum. They should only be used to relay the result of discussion where there has been disagreement and it's been resolved. Elemimele (talk) 15:57, 13 February 2023 (UTC)

Hi dear Wikipedians!

I am a car fanatic and I have a request. Please can you make some car manufacturer logos available for use on different Wiki languages when creating articles:

• Cadillac: Cadillac_(logo).svg
• Chevrolet: Chevrolet_(logo).svg
• Donkervoort: Donkervoort_1.jpg
• Lancia:

Lancia_logo_2022.png

• Land Rover:

LandRover.svg

Since these logos are the best logos for each of these companies and are with the highest quality and when an user of a different Wiki wants to create an article about these car manufacturers, which is missing on that Wiki and wants to use these logos, can't use them.

Thanks FLORIKRUJA (talk) 19:37, 15 February 2023 (UTC)

FLORIKRUJA Non-free images cannot be used cross-wiki, but nothing is stopping you from uploading a local copy if the home wiki allows non-free media. Der Wohltemperierte Fuchs ^talk 19:39, 15 February 2023 (UTC)

What you are proposing would be a violation of copyright laws. We are not about to leave ourselves open to lawsuits like that for cross-platform convenience. As Der Fuchs points out, different language Wikipedias have different rules about non-free media use in certain limited circumstances. --Orange Mike | Talk 21:33, 15 February 2023 (UTC)

Also, WP is not for advertising. YTKJ (talk) 21:55, 16 February 2023 (UTC)

The reason copyrighted media cannot be uploaded cross-wiki, is that their use is subject to local laws, not American law. For example, "fair-use" provisions don't exist in many countries. On the French Wikipedia, copyrighted logos can be used, but copyrighted screenshots are illegal with no exception (even low-resolution). There may be jurisdictions where the use of copyrighted logos is illegal too. That's why these files are local to each language-specific Wikipedia. DFlhb (talk) 22:12, 16 February 2023 (UTC)

I think that’s just covered by fair use Dronebogus (talk) 01:13, 17 February 2023 (UTC)

I wonder whether it is worth making a proposal for WikiProjects to make their assessments of list articles more specific? If one goes to the article "List of pastries", one can see it was rated "List class" by WikiProject Food and Drink. This tells us WHAT this article is, but does not tell us its quality. My proposal is to introduce the following ranking for Wikipedia lists:

        Q. Contains Questionable Entries
        Start class. Needs to be more comprehensive
        C. Reasonably comprehensive and accurate, but still requires more work
        B. A very good list
        A. Contains accurate information, covers a good range of entries and 
        provides parameters for information that would not normally be accessible 
        from categories or articles. 

I shall look forward to hearing thoughts on this proposal. YTKJ (talk) 21:02, 14 February 2023 (UTC)

WP:MHA#SCALE has something like this already. The reason it's not more widely adopted is probably because other WikiProjects don't see the need and/or there's not enough interest. —pythoncoder (talk | contribs) 02:30, 15 February 2023 (UTC)

I'd strongly support adopting the MILHIST List ratings wholesale (and frankly, that's more likely to obtain consensus than this proposal; I wish this had been brought up at WP:VPI first, to obtain consensus on which list-ratings to propose).

MILHIST's approach just makes far more sense: lists and articles are both subject to the same flaws (sourcing, completeness, comprehensiveness, writing quality), so there's little reason to only have two assessment grades for lists. DFlhb (talk) 22:20, 16 February 2023 (UTC)

I can second this proposal. Now that we are working on globalising ratings, we should definitely consider ways to standardise as many quality ratings as possible. —CX Zoom[he/him] ^{(let's talk • {C•X})} 11:26, 19 February 2023 (UTC)

Thank you User:pythoncoder. I see that there are some lists, such as List of songs recorded by Adele or List of works by Dorothy L. Sayers that have been give the distinction of being "Featured Lists". This is a step in the direction of what I am proposing, but I wondered whether other lists should also be ranked. This might help WikiProjects see which lists require more work. YTKJ (talk) 18:08, 15 February 2023 (UTC)

Earlier this year, I opened up a discussion at the Idea Lab to create buttons that would automatically skip to the top or bottom of a page if you pressed them. It seemed that it should be made into a preference based on the discussion, and I think that this should now be made into a formal proposal, and that is to create a preference for skipping to the top/bottom buttons. Should this be made into a preference? ‍ ‍ Helloheart ‍ ‍ 01:37, 23 February 2023 (UTC)

@Helloheart we can't just "create a preference". We can make an opt-in gadget, but step one is writing it. Good news: you (or anyone) can start on that now as a userscript. Once it is ready, we can look in to making a test gadget run with it. — xaosflux ^Talk 01:55, 23 February 2023 (UTC)

Note, there are several "to top" and "to bottom" scripts you can try already listed at Wikipedia:User scripts/List. — xaosflux ^Talk 15:09, 23 February 2023 (UTC)

Ok, so for me, there's a lot not to like about the new layout.

But someone else can start that eventual RfC : )

I just want to focus on one very specific thing: the talk link being moved to a drop down.

Hiding the talk link is a very very bad idea.

We operate on the consensus model here.

Hiding the talk link just reinforces that edit-warring is the way to go.

And no, I really don't care what some off-site discussion was - so I don't need to hear an WMF employee breezily tell me that a talk page link was determined to not be important on Wikipedia. I'm happy to engage in discussion, but don't blow us off by referring elsewhere as if this project does not matter please. (As an aside, and this goes far beyond this simple RfC - But just thought I'd mention that while I respect the WMF in general - I think it's very important - but I'm really not happy about how things seem to be being pushed through, with fewer and fewer discussions being allowed to be "open" for anyone to participate.)

Anyway, if we weigh importance, I think it's easy to agree that the talk link is more important than the watchlist link. So if space really is the issue argued, then swap them. Or maybe combine "alerts" and "notices" to save space. Or whatever other ideas people may have.

Whatever the case, un-hide the talk link. - jc37 19:30, 19 January 2023 (UTC)

RfC Discussion

• @Jc37, I'm not sure what you mean. The talk page link is just below the page title. — Qwerfjkltalk 20:37, 19 January 2023 (UTC)

  I think they mean the link to their own user talk page, which is indeed now in a dropdown (unless you have new talk page messages, in which case it's more prominent like before). Matma Rex talk 21:13, 19 January 2023 (UTC)

  @Matma Rex, I see. But people still get the big yellow notification that they have messages, so I don't see the problem. — Qwerfjkltalk 21:22, 19 January 2023 (UTC)

  anything - anything that reduces the visibility and/or ease of accessing the talk page is a bad idea. We want people to discuss. We want people to respond to talk page concerns about their editing. Not to get frustrated because they can't find the link, and thus not engage. There are innumerable reasons that hiding the talk page link is really bad. Even just from the optics of suggesting that talk pages are uninportant. I understand that this may seem an innocuous change for some, but when I consider years - decades - worth of dispute resolution, among many other things, this just really really seems an incredibly bad idea.- jc37 21:46, 19 January 2023 (UTC)

  @Jc37, so your problem is that people might get talk page message, dismiss that notification, and then not know how to find their user talk page and respond? — Qwerfjkltalk 21:59, 19 January 2023 (UTC)

  One, of several. Anything we can do to get people using talk pages, the better. We've repeatedly seen that initial talk page usage helps bridge the learning curve gap for people to turn into regular editors. It's part of why we encourage the community aspect of Wikipedia. Learning how to thread discussions on a talk page can lead to being confortable to add to lists, to add references, and just merely feeling comfortable to edit a paragraph on a page. These are called "gateways" for a reason. - jc37 22:14, 19 January 2023 (UTC)

  Most newcomers are using the Reply button, so they don't have to count colons any longer. The learning curve is essentially flat.

  The Editing team, as a result of mw:Talk pages consultation 2019, considered ways to make talk pages more visible, but it's tricky, and I don't think that they got very far. You don't want the "Talk" tab at the top to be more prominent than the article tab. You also don't want it to be more prominent than the Edit button. So at best, it's in third place. In terms of your own User_talk: page specifically, I think that Growth's Newcomer homepage work has made some difference there. Whatamidoing (WMF) (talk) 23:37, 19 January 2023 (UTC)

  I appreciate all that. I do. But all I need do is look at the default signature for editors to see that Wikipedia sees the value of a talk page link. (And yes, I'm aware that mine isn't there - user pages are important too : )

  But anyway, if it's in third place, then watchlists decidedly aren't. And while I may have done some looking around to find out the difference between notices and alerts, I doubt the average person would know, or care.

  tried and failed doesn't = push through anyway. I understand the idea of the perfect is the enemy of the good - Wikipedia is a work in progress after all. but something like this is different, we're being asked to swallow the watermelon whole, with no changebacks allwed due to fait accompli." what's done is done" and all that.

  I'm not merely complaining to the air, I've actually proposed some suggestions and welcome others. (not adding "support/oppose" sections was intentional). So if you have any ideas for a way forward, I'd be happy to hear them. - jc37 23:54, 19 January 2023 (UTC)

  I don't think that I want to get in the middle of whether the talk page or the watchlist is the more important thing to show. I imagine that most editors want both.

  But now I'm not sure that we're talking about the same thing. At the top of an article, volunteer-me sees these options:

  Article – Talk – Read – Edit – Edit source – View history – Watchlist star – More menu – Twinkle menu

  This is what I see in the new Vector 2022. Are you seeing something different? Are you not seeing the "Talk" item right next to "Article"? Whatamidoing (WMF) (talk) 21:45, 20 January 2023 (UTC)

  @Whatamidoing: I think Jc37 is referring to one's personal user talk page (), which is in the dropdown menu for , rather than a page's talk page (). —Tenryuu 🐲 ( 💬 • 📝 ) 22:30, 20 January 2023 (UTC)

  You also don't want it to be more prominent than the Edit button. Yes I do. Levivich (talk) 16:54, 21 January 2023 (UTC)

  I think that in the end, anything that improves or makes more efficient the talk page in a non-obnoxious manner should be implemented. In particular, I believe that the talk page is one of the biggest catalysts for recruiting new editors, and if they see a place where not only their voice matters but they can participate in a discussion with consequences they can see, I think we've done a good job at recruiting a new editor. Put another way, to know that the change you helped to support 10 years ago can still be found on the website is, for lack of a better term, a magical feeling. InvadingInvader (userpage, talk) 21:46, 31 January 2023 (UTC)

  Very few editors make their first edit on a talk page. Whatamidoing (WMF) (talk) 01:11, 1 February 2023 (UTC)

• Let editors have the option to unhide the Contributions link, too. Some1 (talk) 01:32, 20 January 2023 (UTC)

  @Some1 and @Anarchyte - see Wikipedia:Village_pump_(technical)#Customizing_button_shortcuts_in_top-right_menu_area? for a userscript an editor can use to add contributions to the page top. — xaosflux ^Talk 01:03, 21 January 2023 (UTC)

  The userscript is better than nothing I guess, thanks xaosflux! Some1 (talk) 01:14, 21 January 2023 (UTC)

• Support - adding the ability to choose which buttons appear outside of the user dropdown menu would be a drastic improvement. Anarchyte (talk) 08:08, 20 January 2023 (UTC)
• This RFC is a bit misleading in the title, "Talk" in general is not in any menu, this is only about the link to someone's own usertalk page. This is also something that is skin-wide, so would really need to be changed upstream. I don't see this as severely breaking the consensus building model, as most consensus building discussions don't take place on personal user talks, but on article talks or project pages, both of which are already accessible. — xaosflux ^Talk 12:32, 21 January 2023 (UTC)

  The title is: "restore "talk" from drop down" - that is exactly what this is about. the talk link in the drop down. Nothing there misleading at all. - jc37 08:32, 22 January 2023 (UTC)

• FWIW, started talking about maybe making a gadget for this (see Wikipedia:Village_pump_(technical)#Customizing_button_shortcuts_in_top-right_menu_area?). However it would be opt-int. — xaosflux ^Talk 15:38, 21 January 2023 (UTC)

  Should not require Javascript. - jc37 08:32, 22 January 2023 (UTC)

• Support: There is a huge gap between search box and "CX Zoom" at the top, which could've been utilised in better ways. Talk pages should absolutely be visible on up there in order to assist new editors find a link to there. —CX Zoom[he/him] ^{(let's talk • {C•X})} 16:17, 21 January 2023 (UTC)

  This is exactly what I was saying about the "log in" button for unregistered users. Whether logged in or not, the WMF seems intent on wasting that space and forcing us to live with it. —pythoncoder (talk | contribs) 17:56, 1 February 2023 (UTC)

• Support, per CX Zoom. Also support restoring a link to an editors contributions. BilledMammal (talk) 07:38, 2 February 2023 (UTC)
• As someone who has been using Timeless, I can say that having the user links in a dropdown does not cause me any issue today, and it's second nature to click these links through a dropdown. (I'll move to Vector22 on desktop probably Soon, just have to get off my preferences butt, and mobile Whenever it actually supports mobile.) Oppose accordingly. "Supports" and "opposes" aren't really valuable here. Discussing why you want a link in X or Y position might be, but is still squarely in the realm of design, especially (as I'm sure they will) as they start turning to making the skin friendly(er) for mobile. It might be valuable to decide on what the most valuable links are in the dropdown, rather than having RFCs for this that and the other thing, and see if there can't be some thought put into displaying certain links at certain widths (perhaps as icons, though I know the group that hates the dropdown is probably a concentric set with the group that hates icons). In general though, this dropdown is provided for the set of people who already do have access to scripts, so they always have a workaround to what is/isn't displayed. Izno (talk) 21:08, 4 February 2023 (UTC)

Moved to Wikipedia:Village pump (policy)#Make Wikipedia:Requested moves/Closing instructions a guideline

 – Levivich (talk) 17:56, 26 February 2023 (UTC)

Proposal: Apply extended-confirmed restriction and one revert restriction through general sanctions to all topics relating to gender identity, including transgender and non-binary gender

There are currently ARBCOM sanctions on topics related to gender and sexuality as described at WP:GENSEX. This allows uninvolved administrators to apply and enforce restrictions on related articles and editors in this topic area. Unfortunately, it seems that this is not sufficient to prevent widespread disruption in the topic area. Gender identity is highly contentious and causes significant disruption, and that's unlikely to change any time soon. Furthermore, this topic area is among those most capable of causing real world harm. For these reasons, I'm proposing the creation of community-authorized WP:ARBPIA-equivalent restrictions for this subject. This would entail:

• Standard contentious topics sanctions as previously established
• Extended confirmed restriction that disallows IP editors and new accounts to edit articles on these topics or participate in discussions on them outside of the "Talk:" namespace
• One revert restriction that limits all editors to a single revert in 24 hours (unless it's to enforce the previous point or remove clear vandalism)

It would not replace or change the ARBCOM GENSEX sanction, but it would supplement it in this specific area with ECR and 1RR. To my understanding, this is the highest level of restriction in use under general sanctions, and it currently applies to Palestine–Israel, the Syrian Civil War and ISIL, and cryptocurrency. Before any RfC is created, I'm posting this proposal here to determine:

• Whether support for this exists
• If so, at what scope; whether a more limited scope such as transgender BLPs, or more broadly into LGBT topics
• If there are any stipulations or other considerations that would need to be addressed in a hypothetical RfC
• That I didn't completely misinterpret how all of this works

If there is support for this proposal, then the next step would be to create an WP:AN RfC to formally authorize these sanctions. Thebiguglyalien (talk) 19:59, 22 February 2023 (UTC)

WP:WikiProject LGBT studies has been notified of this discussion. Thebiguglyalien (talk) 23:41, 22 February 2023 (UTC)

Note, saw this before the notification went out, though I am active in that WikiProject. I'm a pretty active editor across many GENSEX articles, if I'm not patrolling recent changes for any sort of vandalism or disruptive editing, you'll likely find me on a talk page somewhere hashing out content. I've some remarks on each of the three proposals:

1. This seems largely redundant. GENSEX is already a CTOP area through the past ArbCom cases and motions listed on WP:GENSEX.
2. On the surface this isn't a bad idea. As you've alluded to, it would prevent drive-by article space disruption by both IP editors and new accounts, which would certainly cut down on certain types of disruption like inserting deadnames or mass pronoun changes of BLPs, or spurious accusations based on typical anti-LGBT+ canards. However I'm not sure it would actually solve the current overall problems in the content area. From my perspective, one of the biggest problems is that we have a set of established behaviourally problematic editors in this content area, all of whom to my knowledge are extended confirmed, that this restriction would not directly affect.
3. A blanket 1RR seems overly draconian to me. As a tool to prevent disruption, it has its uses on a targeted per-article basis, but as a blanket "all articles are now subject to 1RR". 1RR has by its nature a stabilising effect on articles sure, but that also has the effect of making rewrites, and major additions or removals significantly harder for all involved.

In terms of actually fixing what's currently broken in GENSEX, I don't think that this would have the desired effect. I'd also be concerned at the unintentional side effect of scaring off good faith new editors from this area. Maybe I'm wrong though, and I'd be interested to hear from editors in the other content areas you've identified that have these restrictions if they find that those restrictions have actually helped that content area, or if they've just moved the trouble spots elsewhere. Sideswipe9th (talk) 00:17, 23 February 2023 (UTC)

@Thebiguglyalien, here's how I'm understanding your proposal.

• You believe that 99.75% of all registered editors should be banned from editing or writing articles about trans people.
• 99.75% of all registered editors should be banned from joining this discussion, or any discussion like it, because it's not in the Talk: namespace.
• If a celebrity reveals a different gender identity today, then only the top 0.25% of editors should be allowed to make our articles comply with MOS:GENDERID. The other 99.75% of editors should be warned and blocked if they try to help out.
• Editors attending edit-a-thons (such as Art+Feminism) and students in organized classes (there are more 4000 students in more than 300 classes running right now) should be banned from editing anything even remotely related to gender. We should definitely cancel any groups that want to write about women's health or women's politics, because someone might have to decide whether to write "the woman's uterus" or "the uterus", and that's gender-related.

And the justification for this is: People who have already achieved not only ECR, but Wikipedia:Unblockable status, can and do perpetuate gender-related disputes for years, while an IP can be blocked out of hand and pages can be protected to prevent them from editing entirely. Right? WhatamIdoing (talk) 18:55, 27 February 2023 (UTC)

• The OP has asserted that WP:GENSEX restrictions are inadequate to stop disruption, but there are no diffs or links to anything to back up that assertion. If we're going to supercede the existing ArbCom sanctions scheme, shouldn't we at least have evidence that the current sanctions are not working? --Jayron32 19:26, 27 February 2023 (UTC)

I'd support adding WP:ARBECR to WP:GENSEX. ARBECR has helped in the WP:PIA and WP:APL and the community recently authorized it for WP:RUSUKR, WP:KURDS, and WP:ARBAA. GENSEX has the same problem with socking/drive-by/inexperienced editors as the other topic areas. For examples of current sanctions not working, just look at the two ANI threads in the GENSEX topic areas right now (which, in my view, have been disrupted by non-ECR editors, on both "sides" of the issue). I think the "99.75%" figure is a lark; most registered accounts never edit; we have 40 million registered accounts; half of them (20 million) never made any edits; only 2 million made 10 edits; only 450k made 100 edits; only 100k hit ECR. And yes, I think it's a good idea to not allow new editors to edit in our most-contentious contentious topics. I'm much less sure about 1RR being effective or necessary; I think I'd only be in favor of that upon a showing that there is so much edit-warring in this topic area that the usual 3RR isn't working. Levivich (talk) 19:34, 27 February 2023 (UTC)

Looking at both discussions at ANI (One involving Newimpartial and one involving Tranarchist), and neither has significant disruption from anyone that wouldn't already qualify for ECR. Well over 90% (and possibly vanishingly close to 100%) of the text in those two ANI discussions, involve well experienced editors. I have spent 5+ minutes paging through them, and while I'm sure a small number of comments in those discussions may be from new or "drive-by" editors, I can't at first glance identify any obvious ones, the vast bulk of the text in those discussions is from very experienced Wikipedia editors. You're going to need better examples than that. If nothing else, your examples have served to show places where it isn't a problem; it's clear evidence against needing any ECR sanctions, since so little of those discussions is taken up with any such people. --Jayron32 20:22, 27 February 2023 (UTC)

@Jayron32: OK, look here (whole page, top to bottom), perhaps a better example of significant timesink from multiple non-XCs. Levivich (talk) 23:36, 27 February 2023 (UTC)

Here's a complete list of the edit counts for every person who's ever edited that talk page, in order by the number of edits made to that page (which, BTW, they would all still be allowed to do under this proposal):

• 22K edits + 14 years
• 350 edits + 6 years
• 1300 edits + 1 year
• 19K edits + 4 years
• 7K edits + 15 years
• 250 edits + 1.75 years
• (sock)
• 31K + 5 years
• (IP) 1 edit
• 300 edits + 2 years
• 3800 edits, 7 years
• 95K + 13 years
• 5K edits + 1 year

That's 13 editors. Ignoring the sock, there are only three registered accounts and one IP that would be banned from editing, and all of them could reach extended-confirmed by spending a couple of hours doing some kind of trivial high-volume editing mindless, like removing dead links from ==External links== sections. Also, the IP and one registered account has made just one edit to the talk page, and another has made only three, so if your goal is to reduce the number of comments, I suggest that excluding the people who don't post much anyway is not going to make much difference. WhatamIdoing (talk) 23:55, 27 February 2023 (UTC)

That's missing the forest for the trees. The edits by the non-XC editors on your list prompted the edits by the XC editors on your list, and wasted their time. There are 8 threads on that talk page:

1. Started by a sock with 14 edits who argues with several editors before getting blocked
2. different non-XC 1AM with poor understanding of sourcing
3. same
4. same
5. productive thread by XC editors
6. different non-XC with poor understanding of sourcing
7. IP general complaint about bias
8. Third non-XC with poor understanding of sourcing

All but one thread wasted editor time. It was a lot of time wasted. Levivich (talk) 00:03, 28 February 2023 (UTC)

Unless I'm missing something, if ARBECR was applied to the GENSEX content area we'd still have to respond to those threads on article talk pages in some way. ARBECR would only prevent article space disruption, and to a lesser extent related discussions in the project namespace. Sideswipe9th (talk) 00:07, 28 February 2023 (UTC)

Yes, this is true. ARBECR would not actually prevent this particular type of disruption (unproductive talk page discussions). I'm just pointing to this as an example of disruption in the topic area by non-XC editors. But look at the article history and you see non-XC editors also having to be reverted there (even by you in some cases, lol), which seems like most of the last six months of edits to that page. I think they're wasting your time Sideswipe but I would take your word for it (and that of other regulars in the topic area) if you thought different. Levivich (talk) 00:13, 28 February 2023 (UTC)

I've already put forward my thoughts on the initial proposal above. ARBECR is not a bad suggestion per say, we do get a lot of disruptive drive-by article space edits that need some sort of cleanup and this would put an instant stop to that. But for actually fixing what I see as broken in the GENSEX content area, I don't think it would actually address any of the root problems. Sideswipe9th (talk) 00:20, 28 February 2023 (UTC)

You're right, that it doesn't stop all, maybe not even most, disruption. But I see the success of ARBECR in, for example, the Holocaust topic area right now. This controversial high-profile paper comes out, it's all over Twitter and such, it should be bringing in a bunch of new editors and IPs POV-pushing from all angles, but it's not, because all those pages are ECP'd. So if you look, for example, here, here, or here, you still see editors arguing about stuff, maybe disruptively maybe not, but it's experienced editors. What you don't see is the non-XC wasting people's time on talk pages, even though the talk pages aren't ECP'd, but the articles are, and that makes the difference. I think ARBECR is noticeably reducing the amount of disruption there otherwise would be in that topic area right now. Compare with Seymour Hersh or Killing of Tyre Nichols--both high profile but not ECP'd--and you see a lot more disruption there. Levivich (talk) 00:38, 28 February 2023 (UTC)

Maybe it's because I'm too tired right now, but it seems like you're saying that ECPing all of the mainspace pages in a contentious content area also has a measurable decrease in disruption in the related talk space? Is this something specific to the examples you've provided, or is it also reflected in other ARBECR areas? Sideswipe9th (talk) 00:44, 28 February 2023 (UTC)

Yeah you've got me right: mainspace ECP reduces talk page disruption. I've also seen it in WP:ARBPIA, like Israel. There you see the same thing as in the Holocaust articles: a long, often quite contentious, content dispute on the talk page amongst a number of experienced editors, but not really any disruption by non-XC editors. The article is protected, the talk page is not, and there has been a major escalation in violence in that conflict in the real world in the past month or two, and you'd expect this big influx of new editors, but it's just not there. Which lets the experience editors focus. To my eyes, when I look at Holocaust or Israel/Palestine talk pages, they look very different from gensex talk pages, it's a more focused and productive form of disruption :-D Levivich (talk) 00:48, 28 February 2023 (UTC)

Interesting! In that case, I would be open to at least trailing it for 6 to 12 months to see what sort of effect it has. If it does result in the same lessening of disruption on talk pages as well as in articles, I wonder if perhaps it might bring some of the other behavioural problems from other long term editors into sharper focus. As if it does, then it would also indirectly help solve what I see to be one of the root problems in the content area.

There's a few procedural niggles that I and probably a few other editors would need some clarification on. Because GENSEX deals with identities, the delineation between when an article is or is not covered under it is a bit more fluid than other content areas. For example how do we handle BLPs where notable person John/Jane Doe comes out as trans or non-binary and changes their name? Sure I can now slap a GENSEX alert onto the talk page, but would I also be able to go to RFPP and say "BLP subject, came out as trans, article now covered under GENSEX ARBECR" and straightforwardly get the page protected? And how would we handle articles that contain or could contain GENSEX content, but where GENSEX isn't the primary topic? For example man, woman, pregnancy, vaginoplasty, phalloplasty. Sideswipe9th (talk) 01:03, 28 February 2023 (UTC)

Articles that are in, or that enter, the topic area scope can be tagged. I don't think ECP is applied just as a matter of course, but if/when there is disruption, the RFPP request will get approved as a no-brainer, and often will be indef instead of temporary so you only have to ask once. For articles that aren't mostly in-scope but have some in-scope content, those I don't think usually get indef ECP'd, sometimes temporary ECP, but reverting a non-XC editor is a 3RRNO, so it's still very easy to enforce. Similarly, non-XCs can post "constructive comments and make edit requests" on article talk pages, but they can't vote in RFCs, RMs, AFD, RSN, BLPN or any other project discussion. It also stops non-XCs from creating new articles in scope (in theory, NPP catches it, but if not, it can be CSD'd). Levivich (talk) 01:14, 28 February 2023 (UTC)

In re "I think the "99.75%" figure is a lark; most registered accounts never edit" for @Levivich: If you want to count only registered editors who have successfully completed an edit (a number that is smaller than the number who tried), then extended-confirmed excludes about 99.2% of all registered editors. That still excludes a lot of editors. WhatamIdoing (talk) 00:00, 28 February 2023 (UTC)

That's no more convincing than pointing out the pool of XC editors is over 64,000. There are lots of editors. Most are not extended confirmed. Even more are not autoconfirmed. Even more have never made an edit. That doesn't mean anything, and portraying it in terms of "percentage of editors excluded" is rhetoric, not logic. The logic is to exclude inexperienced editors; that fact that 99% of registered accounts are inexperienced is besides the point, since 87% of registered accounts don't currently edit anyway. We have like 50k active editors out of 40+ million accounts, so that's 87.5% (I think) of editors do not currently edit. It's just an example of "lies, damned lies, and statistics." Levivich (talk) 00:16, 28 February 2023 (UTC)

• I have to agree with Levivich… the proposal is overkill, and would result in many editors (who are not editing disruptively) being restricted from contributing. I see no evidence that our current restrictions and cautions are not working. Therefor, I must Oppose. Blueboar (talk) 20:16, 27 February 2023 (UTC)
• Yup, overkill. What is actually needed is broader enforcement of Wikipedia policies (e.g. WP:NPOV, WP:RS etc) in BLPs generally, and firmer action against those who use such articles as political battlegrounds. Picking out specific topics to police such content over misses the point - we shouldn't be allowing it to happen anywhere. At some point, I suspect Wikipedia will be obliged to implement restrictions on editing biographies of living persons generally, but until that happens, we should be enforcing existing policy consistently, which this proposal clearly won't do. AndyTheGrump (talk) 01:18, 28 February 2023 (UTC)
• Everything GENSEX-related reminds me of the hand-wringing that occurred around 2007 over intelligent design (which seemed to take over the entire 'pedia), and then a few years later, the hand-wringing that occurred over climate change, a content area brought well under control by the dedication of Femke and Co. The problematic editors make the headlines (ANI), but we have a bevy of very experienced editors holding down the fort. Editing in this area is no better and no worse than in any other areas. Deal with problematic editors as they come up; don't paint the entire topic area with too broad of a brush. No need to freak out because we happened to have two threads at once at ANI. SandyGeorgia (Talk) 01:46, 28 February 2023 (UTC)

Statistics

Within articles covered by WP:WikiProject LGBT studies:

• 68.7% of edits are by extended-confirmed editors
  • 5.3% of edits by extended-confirmed editors are reverted
  • 32.3% of edits by non-extended-confirmed editors are reverted
• 78.3% of edits are by auto-confirmed editors
  • 7% of edits by auto-confirmed editors are reverted
  • 18.5% of edits by auto-confirmed but not extended-confirmed editors are reverted
  • 38.4% of edits by non-auto-confirmed editors are reverted.

BilledMammal (talk) 01:26, 28 February 2023 (UTC)

How does that compare to BLPs, and to Wikipedia articles generally? AndyTheGrump (talk) 01:36, 28 February 2023 (UTC)

To compare it to BLP's I either need a template or category that marks them as those; unfortunately, I haven't been able to find one. If you know one then I can get those figures for you. For all Wikipedia articles, see this query. It hasn't returned yet, and note that it doesn't cover as long a period of time as the LGBT studies one in order to keep the run time reasonable. BilledMammal (talk) 01:58, 28 February 2023 (UTC)

Category:Living people? Levivich (talk) 02:07, 28 February 2023 (UTC)

Thank you, Quarry:query/71867. BilledMammal (talk) 03:01, 28 February 2023 (UTC)

BLPs

• 69.5% of edits are by extended-confirmed editors
  • 3.7% of edits by extended-confirmed editors are reverted
  • 20.2% of edits by non-extended-confirmed editors are reverted
• 78% of edits are by auto-confirmed editors
  • 5% of edits by auto-confirmed editors are reverted
  • 14.5% of edits by auto-confirmed but not extended-confirmed editors are reverted
  • 39.7% of edits by non-auto-confirmed editors are reverted.

All Articles

• 69.3% of edits are by extended-confirmed editors
  • 3.6% of edits by extended-confirmed editors are reverted
  • 18.3% of edits by non-extended-confirmed editors are reverted
• 78.9% of edits are by auto-confirmed editors
  • 4.8% of edits by auto-confirmed editors are reverted
  • 13.8% of edits by auto-confirmed but not extended-confirmed editors are reverted
  • 37.6% of edits by non-auto-confirmed editors are reverted.

BilledMammal (talk) 03:01, 28 February 2023 (UTC)

Are you still taking requests? Could I interest you in running that for articles that are tagged as specific CT topics, like maybe AP2? I'm curious how other CT topics look. Levivich (talk) 03:17, 28 February 2023 (UTC)

I don't know a category that would allow me to determine AP2, but I've done:

• Afghanistan, Pakistan, and India
• Kashmir
• Kurds
• The Troubles

If there are any others you want me to run, or category that would be suitable for AP2, I can run those as well. BilledMammal (talk) 05:07, 28 February 2023 (UTC)

Thanks! I guess talk pages for all CTs are in Category:Wikipedia pages about contentious topics, but I don't see categories for specific topics, which is too bad, the template could subcategorize by topic. Levivich (talk) 05:22, 28 February 2023 (UTC)

I've run one for that category, but I wouldn't consider it a reliable baseline because that template isn't used consistently; it is more likely to be included on contentious articles within the topic than less contentious ones, and because of this the results will overestimate how contentious these topics as a whole are. BilledMammal (talk) 05:39, 28 February 2023 (UTC)

(60% of Pakistan edits reverted??) Thanks for this. If I'm summarizing all of the above correctly:

• For all articles on Wikipedia, edits by WP:XC editors (>500 edits) are reverted ~4% of the time, editors between WP:AUTOC and WP:XC (10-500 edits) 14%, non-AUTOC (<10 edits) 38%
• For WP:BLPs, that breakdown is XC 4%, AUTOC-XC 15%, non-AUTOC 40%
• For (some but not all) WP:CTs, XC 8%, AUTOC-XC 28%, non-AUTOC 59%
• For Kashmir, Kurds, Afghanistan, Pakistan, and India, XC 5-9%, AUTOC-XC 23-34%, non-AUTOC 40-57%
• For WikiProject LGBT studies, XC 5%, AUTOC-XC 19%, non-AUTOC 38%

Does "non-AUTOC" include IP edits? Levivich (talk) 06:11, 28 February 2023 (UTC)

Oh, that was an error; 60% of edits are made by extended confirmed editors, 18% are reverted.

non-AUTOC includes IP edits, and your summary looks correct to me. BilledMammal (talk) 06:45, 28 February 2023 (UTC)

Be careful or they're gonna ban us again Levivich (talk) 07:07, 28 February 2023 (UTC)

And what dark magic are you using to conjure these statistics? Levivich (talk) 01:38, 28 February 2023 (UTC)

Quarry; the query for the above is here. BilledMammal (talk) 01:58, 28 February 2023 (UTC)

Hello everyone, I have dealt with spams on newly created pages for a while. I believe they are in the likely patterns,

1. a new user registered
2. shortly added spam links, email address and something like that on their user pages, user sandboxes or user talk pages.

Could we add a filter for tagging them with specific edit summary? For example, new users adding links contain their own usernames or new users adding links on their subpages. It will be better for us to deal with spams. -Lemonaka‎ 18:24, 3 March 2023 (UTC)

We already do this sort of stuff. Edit filter 80 is a spam throttle for adding the same link over and over, Edit filter 149 flags edits where the link matches the username. If you have a specific type of spamlink that a regex-based filter may catch that these aren't, Wikipedia:Edit filter/Requested is the place to go. --Jayron32 19:32, 3 March 2023 (UTC)

@Jayron32 Hi, thanks. I have checked logs of 149 and found they are focused on article namespace, however, most spams are coming from user namespace and subpages of that. Could we expand this filter? Or shall I request on Wikipedia:Edit filter/Requested -Lemonaka‎ 09:44, 4 March 2023 (UTC)

Oh, I found that, [[1]] -Lemonaka‎ 09:54, 4 March 2023 (UTC)

Per MASSCREATION and WP:SEMIAUTOMATED, I request permission to mass-create articles pertaining to villages and municipalities in Turkey, including templates and categories. After creating many articles, was advised to seek permission for such semi-automated creations. Discussion here here. Semsûrî (talk) 17:40, 28 February 2023 (UTC)