Wikipedia

Wikipedia:Village pump (proposals)/Archive 214

< Wikipedia:Village pump (proposals)
Latest comment: 11 days ago by Matrix in topic Bring dark mode reporting on-wiki.
Village pump (proposals) archive  

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

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

Mass renaming of articles in Category:Attacks on supermarkets in the United States

Latest comment: 1 month ago13 comments6 people in discussion

Hi all. I am proposing the mass renaming of articles in Category:Attacks on supermarkets in the United States to bring them in line with pages in other categories pertinent to attacks in indoor places in the United States, per WP:TITLECON. Pages in this category tend to be named after the year and city/town the attacks take place in, (e.g., 2022 Buffalo shooting, 2024 Fordyce shooting, 2019 El Paso shooting, 2021 Boulder shooting) which does not align with how it tends to be in other categories.

When looking at other categories for attacks on indoor places in the United States, the vast majority either include the name of the business or the type of venue in their name. For example, see the following where the majority of titles include the names of the businesses or type of venue: Category:Attacks on shopping malls in the United States (16 out of 21), Category:Attacks on office buildings in the United States (9 out of 12), Category:Attacks on nightclubs in the United States (14 out of 15), Category:Attacks on hotels in the United States (7 out of 7), Category:Attacks on hospitals in the United States (6 out of 12), Category:Attacks on restaurants in the United States (17 out of 26), Category:Attacks on churches in the United States (13 out of 17) and Category:High school shootings in the United States (50 out of 51). On average, 79.3% of articles include the place name or type in titles, based on those listed above.

Category:Attacks on supermarkets in the United States is an outlier, where only two pages out of ten have the name of the business or type of place in their title, even when reliable sources may commonly refer to the attacks as such, seemingly due to WP:TITLECON within the category. Including the type of place as well as year and location in some article titles will also better suit WP:NCWWW.

Proposed Renames (Based on naming conventions from reliable sources)

Macxcxz (talk) 14:16, 17 September 2024 (UTC)

This should really be done through WP:RM, which then tags the pages and adds them to relevant reports that editors watch. Gonnym (talk) 14:23, 17 September 2024 (UTC)
I know that is typical protocol, but I wanted to discuss it in a singular place first. Multiple discussions over multiple RMs would be confusing. Macxcxz (talk) 14:38, 17 September 2024 (UTC)
Generally speaking, this should only be done with a consensus on the talk page of the article concerned. Mass renaming without a requested move discussion is likely to be reverted.--♦IanMacM♦ (talk to me) 14:39, 17 September 2024 (UTC)
I know, I just want to discuss it. Macxcxz (talk) 14:41, 17 September 2024 (UTC)
RM has a procedure in place for multiple pages as well. You should go read up on it. Gonnym (talk) 15:13, 17 September 2024 (UTC)
Oh I see, I didn't know that was possible. Still, I'd prefer to discuss it here without any actual actions taken first. Macxcxz (talk) 16:33, 17 September 2024 (UTC)
WP:TITLECON is an essay, it's about WP:CONSISTENT, which is just one of the five WP:CRITERIA for titles, and it's the last one, because it's the least important one. I get nervous whenever anyone endeavors to "make all titles consistent."
There are basically two categories of titles based on my understanding of how WP:AT policy is applied: those with a WP:COMMONNAME and those without. For those with a common name, we use that name, regardless of whether it's consistent with anything else. So, Columbine High School massacre is not called "1999 Columbine shooting," and "Pulse nightclub shooting" is not "2016 Pulse shooting" or "2016 Orlando shooting". So for each one you want to change, you'd have to check whether the current title is the common name or not.
For those that don't have a common name, there are four other equally or more important criteria: WP:PRECISE, WP:CONCISE, WP:NATURAL, and WP:RECOGNIZABLE. So, for example, "2019 Jersey City shooting" is certainly as precise, and more concise, and in my view, more natural and recognizable, than "2019 Jersey City kosher supermarket shooting". In my view, if it doesn't have a common name, it should be as short (WP:CONCISE) as possible, using only those descriptors that are needed to be precise. So: "[date] [place] shooting" is fine unless there were two shootings in that year or place. In fact, "[place] shooting" would be better in my view, unless there were multiple shootings at [place].
I don't see any value in adding the word "supermarket" to a title unless it's needed to disambiguate [place].
I don't think we should ever add the brand name of the private business ("Walmart", "Buffalo Topps") where a shooting occurred, unless it's part of the common name (as with the Pulse shooting). It's not nice or necessary to associate the business with a shooting that happened at one of its locations.
My 2c. Levivich (talk) 15:07, 17 September 2024 (UTC)
To clarify, my proposed renames are also based on WP:COMMONNAME, sorry if I didn't make that clear. In regard to 2019 Jersey City shooting, I do note that the page's current name does reflect common name so a rename may not be necessary. The same goes for the 2011 Tucson shooting, hence why I did not propose a rename for that page.
The main reason I even proposed this was because I attempted to rename the 2019 El Paso shooting to 2019 El Paso Walmart shooting based on WP:COMMONNAME, but two people responded (the only people to respond) objecting on the basis of WP:CONSISTENT. I wasn't aware WP:CONSISTENT was considered less important than any of the other criteria, and actually I can't find anywhere that says such a thing, perhaps you know where.
In regard to adding brand names/private businesses, this is already a well-established concept both on Wikipedia and in reliable sources. The vast majority of school shooting articles will include the name of the school, which I'd argue is far more damaging than just naming "Walmart". Certainly regarding the El Paso shooting, "Walmart" is part of the common name based on RS, but as I said before it was apparently a consistency issue to propose that rename.
So, I'm pretty confused. Does common name take priority? I've heard different things from different people now. Macxcxz (talk) 16:21, 17 September 2024 (UTC)
Yeah... welcome to Wikipedia, where if you ask three people, you'll get six answers.   There are very few clear black-and-white rules regarding article titles (or anything else on Wikipedia). Does common name take priority? Yes, usually. As WP:COMMONNAME explains, Wikipedia generally prefers the name that is most commonly used ... as such names will usually best fit the five criteria listed above. So common name will usually take priority because it usually fits the 5 article title criteria the best. That doesn't mean always follow the common name, but it does mean the common name is a very strong factor in this multi-factorial analysis.
As for consistency being low priority, that's more my opinion, or my analysis of how these things usually go, than a "rule" or policy. WP:CONSISTENT itself is written with some rather weak language and caveats, e.g. To the extent that it is practical. And should be consistent does not mean "must be the same." Even "consistent" doesn't mean "the same." WP:CONSISTENT continues, there has been a history of consensus among editors regarding several areas where consistency does not control titling, and the first example given is Disambiguation, which is what you're talking about. The example given in WP:CONSISTENT says just because Georgia (country) has the (country) disambiguator doesn't mean every country article must have one, even though that would be consistent. I think there is a direct analogy here to "Walmart": just because some articles identify the name of the business doesn't mean all articles should identify the name of the business.
But ultimately, titles are decided very much on a case-by-case basis (in large part because a common name analysis is a case by case analysis), so who knows what the consensus will be at that particular RM about the best title for that particular article. Right now I see it's split 2-2. I'd argue with the votes that say that that article shouldn't have "Walmart" in the title because other articles don't, as that argument seems like it directly contradicts the "disambiguator" part of WP:CONSISTENT. Ultimately, it depends on what the consensus will be as to whether, for that particular article, in the inclusion of "Walmart" would better match title criteria, e.g. because it's part of the common name. So there's no clear "right answer," it's a matter of how the people participating in the discussion will weigh the various competing factors involved. Levivich (talk) 16:46, 17 September 2024 (UTC)
welcome to Wikipedia, where if you ask three people, you'll get six answers – I disagree, Levivich! You usually get four answers from three people, unless one of them is socking, in which case you'll get five.   WhatamIdoing (talk) 19:07, 17 September 2024 (UTC)
Overall, I like the idea of a slightly more informative title. After a while, they all blur together ('No Way to Prevent This,' Says Only Nation Where This Regularly Happens), and having some little hint would sometimes be helpful. The use case I'm specifically thinking of is when you're searching for an article. However, I don't feel strongly about this, and I oppose making them all match just for the sake of matching. WhatamIdoing (talk) 19:13, 17 September 2024 (UTC)
A lot of these are just random crime news that don't need their own articles to begin with. Except for the ones that saw major coverage after being resolved, I'd say merge them all into a list. Thebiguglyalien (talk) 20:01, 18 September 2024 (UTC)

Font options

Latest comment: 1 month ago7 comments4 people in discussion

Wouldnt it be great to look at articles in like comic sans WikipedianAncientHistorian (talk) 23:26, 16 September 2024 (UTC)

WP:CSS explains how to install your own custom CSS. Switching to a different font should be relatively straight-forward. RoySmith (talk) 23:38, 16 September 2024 (UTC)
Thanks for the tip honestly wasn't aware it existed WikipedianAncientHistorian (talk) 19:30, 17 September 2024 (UTC)
Wikipedia doesn't specify the font being used for article text; it uses whatever you have configured in your browser for sans-serif text. So feel free to configure your favourite font for use in your browser. isaacl (talk) 00:24, 17 September 2024 (UTC)
oh makes sense thanks WikipedianAncientHistorian (talk) 19:30, 17 September 2024 (UTC)
What if I don't want a sans serif font? Can I set things up to use a serif font in article text? --User:Khajidha (talk) (contributions) 12:54, 19 September 2024 (UTC)
If you change your browser configuration, you can set up any font you want to be used when a web page uses the generic sans-serif CSS property. If you want to do something specific to English Wikipedia, see the web page to which RoySmith referred. isaacl (talk) 18:29, 19 September 2024 (UTC)

Page views link in the Tools menu

Latest comment: 1 month ago50 comments13 people in discussion
 
The Tools menu.
 
Same menu, but with an extra "Page views" link.

Last month, {{Annual readership}} was nominated for deletion. The Graph extension which the template used was turned off on 18 April 2023 due to a security issue. After that, the Annual readership template was changed into just a text with a link to pageviews.wmcloud.org.

Annual readership is currently used on 53,510 talk pages. The consensus on the TfD appears to be that the template should be kept, but noincluded and made invisible, pending a solution for the Graph extension.

In the same TfD, I proposed a "Page views" link in the tools menu as an alternative of sorts. See the included screenshots. Right now, the link to the page views tool is carefully hidden in: Tools -> Page information -> scroll all the way down -> External tools -> Page view statistics. Could we perhaps make the page view link appear more prominently?

I know there are scripts like User:PrimeHunter/Pageviews.js, but it would be nice if the button appears by default, regardless of whether a user is logged in or not. Cheers, Manifestation (talk) 18:34, 7 September 2024 (UTC)

For more info see:
Wikipedia:Templates for discussion/Log/2024 August 25#Extra link in the tools menu?
Few editors, and fewer average readers, are aware that the page views link is on the "page information" page:
Tools menu > Page information > Page views.
--Timeshifter (talk) 19:41, 7 September 2024 (UTC)
For me, the length of the Tools menu makes it harder to find specific items that I'm looking for. Thus I prefer that the page view link remain grouped under the page information menu item. isaacl (talk) 21:18, 7 September 2024 (UTC)
I think the "Print/export" section of the the tools menu could be consolidated and be put on a page called "Print/export". So that would consolidate 3 lines in the tools menu to one link. That would leave room for a page views link on the tools menu. --Timeshifter (talk) 11:04, 8 September 2024 (UTC)
A link to page views is also available in the "External tools" bar near the top of the history page. Thryduulf (talk) 21:21, 7 September 2024 (UTC)
That's a pretty obscure location for the average Wikipedia reader. --Timeshifter (talk) 09:58, 9 September 2024 (UTC)
I don't feel that Page views is that much more important than the other external tools linked in page information and page history. Personally, I use Revision history statistics more. Obviously adding them all would be too much clutter though, so I wouldn't propose that as an alternative. ― novov (t c) 03:12, 8 September 2024 (UTC)
So you feel that "page views" is a little more important? So then it should replace something less important.
Concerning revision history, I assume you are talking about the "View history" link at the top of nearly all pages? I agree that is very important. But we are not asking for the page views link to be put at the top of pages. --Timeshifter (talk) 10:54, 8 September 2024 (UTC)
I'm talking about the Revision history statistics tool, which is also in the page information. What I'm saying is that there's no reason why page views should be added to the tools menu when it's not been proven that it's "special" compared to the other things, and page information is in there anyway. ― novov (t c) 01:51, 9 September 2024 (UTC)

The average Wikipedia reader is more interested in page views than those arcane statistics. --Timeshifter (talk) 09:58, 9 September 2024 (UTC)

I now support the tools menu over other locations to add a pageviews link. But it would require moving many of the links to submenus as with the page menu discussed below. That means scrolling would no longer be necessary to see all the links in the tools menu.
Also, The tools menu is currently on nearly all pages whether one is logged in or not. That is a big advantage over Xtools and the page menu which require enabling gadgets in preferences. And enabling Xtools by default for logged-in users might unduly increase server load. --Timeshifter (talk) 03:06, 15 September 2024 (UTC)

Put page views link in talk header template too

I say do both. But if not in the tools menu, let's start here in the talk header template. We could remove {{annual readership}} from all talk pages, and use this location instead. This way the number of links to page views on talk pages goes from around 53,000 to 726,000 talk pages.

{{talk header}} is on around 726,000 article talk pages out of 6,902,067 articles. {{NUMBEROF|ARTICLES|en|N}}. That is around 11% of articles.

Note that there is room on the left side for a page views link. --Timeshifter (talk) 11:42, 8 September 2024 (UTC)

This talk page header already has a lot of clutter. I am against adding anything else to it; if anything, it should be simplified. ― novov (t c) 01:54, 9 September 2024 (UTC)
{{talk header}} has been developed over a long time. There is agreement on what is there now. So I think you are in the minority on that. Adding a page views link there justifies hiding or deleting {{annual readership}}. So that means less stuff on the talk page. --Timeshifter (talk) 09:51, 9 September 2024 (UTC)
It doesn't help anyone else, but if you personally want a more concise talk page header I recommend adding to your user style:
#talkheader tr:has(> td > .talkheader-body) { display:none; }
this cuts most of it out but leaves the search box. –jacobolus (t) 15:42, 9 September 2024 (UTC)
It is true that the content in the white box isn't at all relevant for experienced editors. I'd be interested to consider a proposal not to display it for those editors. Sdkb talk 03:37, 12 September 2024 (UTC)
Sdkb, proposal not needed, just a doc update. That box (like most else) is already classed, this as .talkheader-help and all you have to do is add .talkheader-help {display:none} to your common.css, and that should do it. (If it doesn't, please ping me from Template talk:Talk header.) Mathglot (talk) 00:42, 13 September 2024 (UTC)
I'm interested in improving the interface for everyone, not just myself. A personal CSS hack doesn't do that. Sdkb talk 07:47, 13 September 2024 (UTC)
Oh, I see; should be pretty straightforward with a new param. If only we had a magic word for the id of the user reading the page, instead of the last one who saved it, we could do it without a param, but alas. Mathglot (talk) 07:54, 13 September 2024 (UTC)
I have recently come to the conclusion that promoting page views information to editors is a bad idea. Here's why: the page views for most articles are very low.
I pulled the page views counts for all of 2023 for a random set of 10,000 articles. 90% of articles get less than 10 page views per day. 70% get less than 1 page view per day. Almost 40% of them get less than 1 page view per month.
Please imagine for a moment that you have created an article, or you decided to improve it. Then you look on the talk page and discover that the number of page views is far lower than you expected. A metric that never really mattered to you before has been put in your face, and now you feel discouraged. Metrics that might align better with your own values (e.g., how grateful a reader was to find information on such an obscure topic) are not available and will not be surfaced to you. We're just going to tell you that 40% of your articles are probably pointless. Or 70%, if you thought one reader a day was enough. Or 90%, if you'd hoped your efforts would help "only" 10 readers a day. My point is, for most articles, this is not a feel-good metric. This is a feel-bad metric, and we should be cautious about promoting it indiscriminately.
BTW, if you'd like to figure out how your favorite page compares, then here are a few key numbers:
  • 100K page views per year: top 1%
  • 10K page views per year: top 5%
  • 1K page views per year: top 20%
  • 100 page views per year: top 40%
WhatamIdoing (talk) 06:23, 12 September 2024 (UTC)
Though I agree that page views can be surprisingly low sometimes, I think your methodology is possibly flawed; editors don't just edit random articles. I would imagine that articles that are edited more tend to get more views, as there is most likely some overlap between reader interest and editor interest. ― novov (t c) 06:54, 12 September 2024 (UTC)
I agree that editor interest is non-random, but that means it will be worse than average for some editors. If your niche happens to be an unpopular one, then you could find yourself looking at evidence of its unpopularity very frequently.
The opposite is also true: if you happen to be impressed with the page views an article is getting, then you might feel the stakes are much higher. There can be no compromise when so many people are going to read this, right? Everything's got to be perfect. Don't be bold; be very, very, very careful. The next thing you know, editors are thinking about the fact that almost a million people read Cancer a year. Someone could die! (I'm going to die. We're all going to die.) We need editors thinking about the work that needs to be done, rather than being focused on the popularity of the page. WhatamIdoing (talk) 07:12, 12 September 2024 (UTC)
I actually do pay attention to page views for articles I work on, but I am comfortable going to the page history to access them. Very low page views for a given article can be disappointing, but every once-in-a-while something in the news will cause a hundred- or thousand-fold spike in page views for such an article, and I then take satisfaction in knowing that we had some background on the topic available to the reading public. Donald Albury 12:18, 12 September 2024 (UTC)
I find this condescending to editors and readers: "We need editors thinking about the work that needs to be done, rather than being focused on the popularity of the page." You, or some committee, shouldn't be determining what is important to editors and readers. I assume now that this is why page views has been made so inaccessible to regular readers and editors. I make decisions on what and how I edit based on numerous factors, including page views. Maybe you have unlimited time to edit. I don't, and so I want to edit what I think makes a difference, and what matters to me. If I have a choice between a popular and unpopular page, and both matter to me, then I will probably edit the popular page more. --Timeshifter (talk) 00:45, 13 September 2024 (UTC)
I doubt that's why Page views isn't that visible; most likely it just wasn't considered that important.
And by definition, any user interface design makes a determination of what's important or not important. People use Talk more than, say, What links here, so it makes sense that the former is more prominent. In such a wide-ranging and community-focused project like Wikipedia there's always going to be a variety of opinions on what exactly that order is.
The closest thing to letting people decide for themselves would be if we just make every action associated with a page buttons of the exactly the same size that are always visible, which would be unbearably cluttered and intimidating to newcomers. ― novov (t c) 02:36, 13 September 2024 (UTC)

novov: Now your veering into ridiculousness. As I previously said average readers and editors are more interested in page views than other statistics. And elsewhere you said you want page views in a separate template, and not as 2 words (Daily pageviews) added to {{talk header}}. Many people do not want a separate template. So that leaves few choices if you really want pages views to be more accessible to average readers and editors. --Timeshifter (talk) 21:57, 13 September 2024 (UTC)

Strong oppose. I am a strong supporter of accessibility of page views information on Talk pages, but this is not he way to go. I won't repeat the reasoning I already gave at Template talk:Talk header, I will just say that I am coming up with a stopgap, template-based replacement for {{annual readership}} until a more permanent solution can be found, and will expose it here shortly for discussion. (I've added DNAU so this doesn't get archived in the meantime.) Please stay tuned. Mathglot (talk) 23:04, 12 September 2024 (UTC)
You haven't stated whether you oppose or support a page views link in the tools menu. Please say so in the previous talk section above. --Timeshifter (talk) 22:09, 13 September 2024 (UTC)
@Timeshifter, where is the evidence for your assertion that average readers and editors are more interested in page views than other statistics? I don't think we have any the evidence that "average readers" are interested in any statistics at all, and what we can reasonably predict about editors is that some will appreciate it and others won't.
It is very easy to assume "I want this; therefore almost everyone wants this". I'm telling you: I don't want this, and because of the page-view distribution curve, I think it is very bad for Wikipedia's future to promote page views. You are proposing that 90% of talk pages carry "proof" that those articles are unimportant. That will not make editors feel happy. It will not make them feel like contributing more. In some cases, it will scare them away from editing. Cancer has a self-contradiction in it. It's hard enough to get someone to edit that article. I don't need "help" in the form of you scaring away editors because you've made sure that they know how many people will see that edit. I very much need "editors thinking about the work that needs to be done, rather than being focused on the popularity of the page", even if you think it's condescending ("an attitude of patronizing superiority or contempt") of me to want editors to WP:Be bold and fix the problems in that article and not to be scared off by your reminder that the page gets read 1.5 times per minute. Editing articles is an anxious business for some people.
Putting the page views on all the pages will make editors feel like someone else (i.e., you) has told them that they should care about this factor. In fact, you think they should care about page views so much that you are trying to force them to see the numbers (or, for now, a link to the numbers) whenever they venture onto a talk page.
You should get to pick the articles that you want to work on. I suggest to you that a page like Wikipedia:WikiProject Politics/Popular pages would be a more efficient way of finding popular articles than clicking on each talk page, but if you like clicking on each page individually, then feel free to click away. What I'm saying is: Don't force your preference on everyone else. WhatamIdoing (talk) 04:19, 14 September 2024 (UTC)
We appear to have a WP:TALKFORK at Template talk:Talk header#Put page views link in talk header template. WhatamIdoing (talk) 04:30, 14 September 2024 (UTC)
 
The XTools PageInfo gadget, as seen when viewing the Jimmy Wales article.

See: Special:Preferences#mw-prefsection-gadgets. Appearance section:

  • "XTools: dynamically show statistics about a page's history under the page heading."

It lists the number of editors, watchers, and pageviews. It names the page creator, and has a link to "full page statistics" that goes here (it is filled in automatically):

For example:

The statistics bar is below both article and talk pages. There are separate stats for the talk page.

Only logged in users see the statistics bar. Turning it on by default would allow all logged in users to see it. If they don't like it they can always turn it off. But if they never turn it on, they will not know that it has a page views link. That is why it should be turned on by default.

I think this should be done, and after people see that the sky will not fall by giving editors this info, then it should be turned on by default for both logged-in users, and all readers. --Timeshifter (talk) 07:32, 14 September 2024 (UTC)

  • I don't think this is a good idea, forcing all editors (and even all readers) to make client-side calls to a volunteer project on every page load is asking a lot, also this gadget causes a screen jump as it waits to load then inserts itself in to the header. — xaosflux Talk 07:44, 14 September 2024 (UTC)
The screen jump doesn't bother me. Pages have screen jumps for other reasons too. People can turn it off if they don't like it. And it is not much of a screen jump. A line or 2.
We can start with logged-in users first and see how that goes. If it is too much of a load on the servers, then set it to only update the numbers once a day.
https://xtools.wmcloud.org is part of Wikimedia, and so I think its servers can handle it if tweaked as needed. --Timeshifter (talk) 08:01, 14 September 2024 (UTC)
Sure it doesn't bother you - and that's why you and others can opt-in to it. A jumpy interface isn't very nice for causal readers. — xaosflux Talk 14:30, 15 September 2024 (UTC)
I don't think these statistics are relevant to the average reader. Or average editor really, I can count the amount of times that I've looked up any of these statistics for the last twenty pages I've edited on zero hands. The same is most likely true for the last two hundred.
To be quite frank, even before it became hidden {{Annual readership}} wasn't on most talk pages. For those pages, the situation was identical to how it was now, so I don't get why this is such a huge issue. ― novov (t c) 09:29, 14 September 2024 (UTC)
It's important to the many people who liked {{annual readership}} while it had the graph of pageviews. Apparently, that does not matter to you. --Timeshifter (talk) 09:36, 14 September 2024 (UTC)
 
Screenshot of the Analysis menu of the Page dropdown.

See: Special:Preferences#mw-prefsection-gadgets. Appearance section:

  • "MoreMenu: add Page and User dropdown menus to the toolbar with links to common tasks, analytic tools and logs".

Unless the tools menu gets some submenus, then I like this solution best of all so far. It avoids any possible server problems (see previous talk section) since it does not show the statistics. And the page menu is short. So there is room for a pageviews link.

The pageviews link needs to be added to the page menu, or the "analysis" submenu.

This way logged-in editors have access to pageviews without having to open another page first (if they even know about it), and then scroll around, and then click the pageviews link.

Since it would be in a menu or submenu, editors are likely to see it as they look at all the menus on pages over time. They don't have to leave the page to click the pageviews link. ----Timeshifter (talk) 22:16, 14 September 2024 (UTC)

No opinion yet on whether or not this proposal should be implemented, but could you please explain why The pageviews link needs to be added to the page menu, emphasis in original? Folly Mox (talk) 23:15, 14 September 2024 (UTC)
I don't know if you have read the previous talk sections. But the goal is to make the pageviews link more accessible. {{annual readership}} has been hidden from view on all pages it is on. So that accessible pageviews link is gone.
Adding the link to the page menu is one solution. --Timeshifter (talk) 01:08, 15 September 2024 (UTC)
The previous talk sections clearly show that this goal is not one that everybody supports, indeed some people have actively opposed adding links to the page menu. There is currently no consensus that we should increase the accessibility of the page views tool at all, nor for a specific way to do that. Thryduulf (talk) 01:13, 15 September 2024 (UTC)
Time, Can you clarify what it is you actually want? A great deal of words have been expended here about adding a *pageviews link*, as in your message just above and many other parts of this multi-section discussion, but is a link what you really want? Or would you rather just have the page views chart itself on the Talk page? I suspect your underlying goal is the same as mine, as I get the impression that you'd rather have the chart but have given up on that idea because it hadn't worked in over a year and was finally hidden recently.
But as I mentioned above (diff), there may well be a way to have a pageviews chart on the Talk page. If you'd rather have the link, then carry on, I guess, but it looks like you are running into a lot of opposition to that approach. My impression is that by continuing to grind away at it, you are doing yourself a disservice and possibly pushing your goal of having easy access to a chart even further away. The more you insist on a link, the more you may also gin up opposition to having the chart, and I haven't raised that idea more formally yet because this discussion has sucked up all the oxygen in the room about this topic and may have also poisoned the well a bit. Please don't make things worse than they already are. I think you are more likely to get what you want, if you let it be for a while, or at least, wait and see if there's a groundswell of support here for your links ideas, which so far has not materialized. Mathglot (talk) 01:50, 15 September 2024 (UTC)
Mathglot. I now prefer a pageviews link in a submenu of the Tools menu that is currently found on all pages whether logged in or not. I like how submenus condense the page menu. The tools menu has no submenus and one has to scroll down the page to see all the contents. So it solves 2 problems to add submenus to the tools menu. {{annual readership}} is only on less than 1% of all article talk pages (53,000 / 7,000,000 articles). I support your efforts to make it work again. But I want more. I hope to contact whoever is involved with the Tools menu directly. That may be more productive. The feedback from this discussion has been useful in seeing what will work. For example, I don't want to add any more server load. Adding a link to a submenu of the tools menu adds no server load. --Timeshifter (talk) 02:17, 15 September 2024 (UTC)
I hadn't read the previous sections as it happens: the edit summary on my watchlist made it appear as if this were a new topic. I'm afraid I'm inclined to agree this doesn't have consensus, and just wondering why this is a need as distinguished to a "nice-to-have, for some people". Personally I think I'd find readily accessible pageviews more demoralising than anything, but if I'm curious Special:PageInfo is right there. (And, for many, and a slightly different application, Special:Impact.)
As an aside, this Xtools menu gadget has no effect on mobile. Folly Mox (talk) 01:51, 15 September 2024 (UTC)
Folly Mox. Special:PageInfo and Special:Impact are not direct links to pageviews for a page. I meant "need" in the sense that for this to work, the pageviews link "needs" to be on the page view menu or submenus. Currently, it is not there. Thanks for the info about the Xtools menu gadget not being on mobile. Another reason not to use Xtools as the means to make a pageviews link more accessible. See my reply to Mathglot a few paragraphs up for more info. --Timeshifter (talk) 02:28, 15 September 2024 (UTC)

Stop

User:Timeshifter, you seem to be suffering from a severe case of IDHT, so to get through to you I need to be a bit more blunt than I like to be. The goal of making pageview links more easily accessible has been rejected by most people commenting above. To you these links are very important, but to most people they are not. Stop trying to find ways of forcing these links on people who don't want them and just find a way to have them yourself. Phil Bridger (talk) 08:26, 15 September 2024 (UTC)

With all due respect to Timeshifter's volunteer passion about this, as well as his good-faith effort to sum up opinions in the next subsection, I have to agree with Phil Bridger here. I think we are well into WP:SATISFY territory, and it's probably time to let it go and choose your battles. At best, try again in a year or so, after the situation with the non-working charts bug (T334940) has been (hopefully) resolved. As for me, I've contributed here all I can, and I am withdrawing from this discussion now, as further comments would either be counter-productive, or prolong it unnecessarily. Best of luck, Mathglot (talk) 21:12, 15 September 2024 (UTC)

Phil Bridger wrote: "The goal of making pageview links more easily accessible has been rejected by most people commenting above." As a point of fact that is incorrect. Most people haven't expressed an opinion. 3 people support the link in the tools menu. 3 are opposed. But I agree that discussion here seems to have petered out. Mathglot, you asked me: "Can you clarify what it is you actually want?" I answered that. I asked you: "whether you oppose or support a page views link in the tools menu." --Timeshifter (talk) 22:27, 15 September 2024 (UTC)

Yes, you did; noted. Mathglot (talk) 22:57, 15 September 2024 (UTC)
It's not about me. That's projection on the part of you two. But hey, I've said what I've got to say. I made some suggestions. I answered questions. I answered your question. I wasn't sure you had seen my question. Of course, you don't have to answer mine. I didn't badger others to answer my questions. I made other suggestions. That's not badgering. What happens next is up to others. I don't edit the tools menu. --Timeshifter (talk) 01:43, 16 September 2024 (UTC)

Many people support {{annual readership}} graph working again including me.

I learned a lot from this discussion which I wouldn't have learned without the discussion. I now only support making the pageviews link more accessible through the tools menu (if submenus added to shorten the menu). The other options were not as good (see reasons in the discussions).

For tools menu:

  • Manifestation
  • Timeshifter
  • jacobolus (in another thread).

Supports talk page editors deciding whether to add a pageviews link in comment, banner, or box. Generally opposed to making it more accessible than that:

  • WhatamIdoing (in another thread).

Unknown as to tools menu with submenus:

  • isaacl
  • Thryduulf
  • Sdkb
  • Mathglot - opposes it in {{talk header}}.
  • xaosflux - opposed to making XTools default.
  • Folly Mox
  • Phil Bridger

Against any better access:

  • novov - (against {{annual readership}} too).
  • Donald Albury - comfortable going to page history for it.

I hope I got everybody's views correctly summarized. --

Note: If you want a pageviews link in your own tools menu see User:PrimeHunter/Pageviews.js. For a pageviews link below all article and talk page titles turn on XTools at the bottom of the appearance section of these gadget preferences. --Timeshifter (talk) 21:57, 16 September 2024 (UTC)

New Page: Snakes Of Egypt

Latest comment: 1 month ago6 comments5 people in discussion
  Resolved

I have to find the snake endemic to Egypt for a project, but there doesn't seem to be one? Can someone kindly add it? Btw not a problem anymore no one needs to reply to this. Irindu10 (talk) 16:19, 21 September 2024 (UTC)

New pages aren't generally proposed, they're just created (i.e. someone could start editing Snakes of Egypt at any time). This isn't likely to happen on a timescale that would be useful to your assignment, and would probably defeat the purpose of the assignment. I'd recommend you try searching for "snakes" "Egypt" on Google Books and seeing what comes up there. If you find anything substantial, maybe you could start the article yourself. signed, Rosguill talk 16:27, 21 September 2024 (UTC)
@Irindu10 If you want, you can take a look at other pre-existing pages listed at Lists of snakes to see how they are structured, as well as the template {{Species table}} for a fancier look. Chaotic Enby (talk · contribs) 16:56, 21 September 2024 (UTC)
Thanks! Irindu10 (talk) 13:58, 22 September 2024 (UTC)
@Irindu10, you can also ask questions about real-world facts (not really about how to edit Wikipedia) at the Wikipedia:Reference desk.
To get you started, you might look into Indotyphlops braminus ("Common Blind Snake", which is a very small snake [a third the length of the common earthworm] that gets its common name from tiny eyes that can realistically see only light/dark) and Walterinnesia aegyptia ("Egyptian Black Cobra"). If your project is literary in nature, then Cerastes vipera is often given as Cleopatra's asp. WhatamIdoing (talk) 17:07, 21 September 2024 (UTC)
There has never been a Category:Snakes of Egypt under Category:Snakes by country, and Category:Reptiles of Egypt was upmerged in 2020 into Category:Reptiles of North Africa, although a list article still exists at List of reptiles of Egypt, consisting entirely of unannotated links, including section headings. Folly Mox (talk) 17:40, 21 September 2024 (UTC)

Ethiopic fonts

Latest comment: 1 month ago5 comments4 people in discussion

Could we add "Abyssinica SIL" to the list of display fonts for Ethiopic script? The supplemental blocks display as tofu for me despite me having a supporting font installed. The only one I can see is Extended-B, which is the one not supported by Noto. (And I do have Noto installed.)

For comparison, wikt:Appendix:Unicode/Ethiopic Extended etc. display in Abyssinica SIL on my browser.

(Abyssinica is free and covers all 5 Ethiopic blocks.) — kwami (talk) 21:57, 19 September 2024 (UTC)

You forgot to link to the page where you experienced a problem. —TheDJ (talk • contribs) 03:09, 20 September 2024 (UTC)
Sorry, the tables in Geʽez_script#Unicode and the pages they link to, e.g. Ethiopic Extended.
The table for Ethiopic Extended-B displays correctly. Ethiopic (Unicode block) is mostly good, but has a bit of tofu scattered in it, e.g. for ሇ. Note that the tofu in the basic block is covered by Noto, as are the extended blocks up to Extended-A, so it almost seems as if Noto is the problem: Both the characters that are not handled by Noto (Extended-B), and those that are handled by more limited system fonts (most of the basic Ethiopic block), display correctly. The ones where Noto might kick in (I'm guessing) display as tofu. But they display fine if I set them to Noto in a text doc. — kwami (talk) 03:28, 20 September 2024 (UTC)
Interestingly, most of these are working for me even though I don't recall installing special Ethiopic fonts. The exception is Ethiopic Extended-B, which for me is a sea of tofu with no characters displaying. Double sharp (talk) 08:42, 20 September 2024 (UTC)
Same goes for me Ca talk to me! 04:33, 24 September 2024 (UTC)

Rethink the extended confirmed right?

Latest comment: 24 days ago20 comments10 people in discussion
Withdrawn as a site-wide proposal per requester below. — xaosflux Talk 22:47, 4 October 2024 (UTC)

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

I originally posted this on WP:VPT but got sent here by Izno. My original message was: Either have a user right that is given only to trusted people without any additional rights attached to it (and with a matching level of protection) or make extended confirmed be given manually. There are too many people gaming the system to be hateful pricks on editors' user pages or to push a POV on CTOPs. LilianaUwU (talk / contributions) 22:34, 30 September 2024 (UTC)

This is barely a proposal at this point. But it is a bad idea, so rather than suggest a further run-around I will explain why here.
I don't believe there is a problem that people are making 500 non-trivial and non-vandal edits just to be "hateful pricks" on talk pages. But, if they are, that seems like a largely-acceptable tradeoff; they can be easily blocked and everybody can move on.
As far as the existence of people pushing a POV on contentious topics; that will never ever stop no matter what the requirement is (at least as long as this is "The Encyclopedia Anyone Can Edit"). Whatever idea you have for "trusted" will also be gamed. It will not help. 500 edits is already a lot (outside of bots and gaming-the-system). And the various "ANI/ArbCom are understaffed" discussions demonstrate that a surplus of volunteers is not a luxury we can assume when designing policies. Walsh90210 (talk) 23:29, 30 September 2024 (UTC)
On top of the issue of it adding a new massive backlog, I'll quote Goodhart's law: "When a measure becomes a target, it ceases to be a good measure". Even if it is only given to trusted users, the users who will care the most about asking for the user right might not be the users that we would want the most, and edits on non-contentious topics won't give a perfect idea of the behavior they might have in more contentious environments. Chaotic Enby (talk · contribs) 08:03, 1 October 2024 (UTC)
This is still not the right forum (and Izno did not explicitly send you here). Please note the header that clearly states This page is for concrete, actionable proposals. Consider developing earlier-stage proposals at Village pump (idea lab). Sdkb talk 07:31, 1 October 2024 (UTC)
But since the discussion has already been moved once, we might as well stick with it here. The downside to choosing VPPR over VPIL, of course, is that we can all weight in with "* Oppose" votes instead of at least pretending to explore the idea.
On the subject matter, I sometimes think we should reduce the 500+30 down to 300+30. There's little statistical difference between 300 and 500 edits; people who make 300 will usually manage the second (whereas people who manage one or two edits usually don't manage 10).
I have seen a small number of editors claim that unnamed[*] others are gaming the system. I have personally seen no convincing evidence of this. Additionally, having fewer folks involved in an ever-greater number of articles violates the principle that "many hands make light work". Something we don't need is a greater percentage of skilled wikilawyers, which is what a manual system will give us.
Something we do need is people with enough self-awareness to realize that, even if we stipulate that my own views are always correct, etc., if I'm running into constant POV pushing around a subject, that could be a sign that the articles are not complying with WP:YESPOV. YESPOV means that the articles need to acknowledge the existence of significant differences in opinions, including in CTOP articles. To name a few of these POVs, consider "some people think abortion shouldn't be described as 'safe' because the baby dies" or "some people think that Israel is perpetrating genocide" or "some people think Donald Trump was the greatest president ever" or "some people think that private citizens shouldn't be allowed to own guns" or "some people fear demographic changes in their society" or "some people think it was unfair to restrict liberty during COVID-19 pandemic just to prevent the virus from spreading". You don't have to agree with any of these to realize that these comments and edits are feedback on how well an article meets people's actual needs. Donald Trump should acknowledge why his supporters think he's great, even though I don't agree with them. Face masks during the COVID-19 pandemic should acknowledge that some people (e.g., lip readers) were harmed by mask use. Writing a decent article that respectfully describes and (when appropriate and WP:DUE) explains the flaws or limitations in these viewpoints really can help, occasionally dramatically. Forcing one POV out of the article, or treating it in a derogatory fashion, is going to produce a steady stream of complaints and attempts to "fix" the perceived problem.
[*] This is not a suggestion to name/shame any individual editors here. WhatamIdoing (talk) 08:37, 1 October 2024 (UTC)
Gaming definitely happens (obvious example), but maybe you mean more that it's not happening as much as is often suggested. Firefangledfeathers (talk / contribs) 12:45, 1 October 2024 (UTC)
Regarding "I have seen a small number of editors claim that unnamed[*] others are gaming the system. I have personally seen no convincing evidence of this."...not that it makes any difference, but gaming the system is not unusual for people trying to tunnel through the EC barrier into the WP:PIA topic area, and Wikipedia kindly provides several tools to help them. This is probably the most impressive example I've seen, but there are plenty of other examples. The topic area is apparently rather good at attracting new editors and people pretending to be new editors. Sean.hoyland (talk) 12:48, 1 October 2024 (UTC)
Regarding "if I'm running into constant POV pushing around a subject, that could be a sign that the articles are not complying with WP:YESPOV", while this is possible hypothetically in a world of rational rule-based agents, in PIA the arrival of large numbers of new users and the amount of POV pushing can often be connected to influence operations on social media and partisan media coverage. It is apparently extremely easy to manipulate people and send them to Wikipedia. Sean.hoyland (talk) 13:17, 1 October 2024 (UTC)
  • Gaming of the extended confirmed restriction is extremely common. It's easy enough to find straightforward examples just by searching the ANI archives, where they usually get reported, and the AN archives, where people often go to request it back when an administrator removes it; often this results in EC being revoked or the user being blocked as a sock (remember, slowing down socks is part of the purpose of EC protection.) Most recently the PIA topic area has produced a lot of it, since the recent conflict has attracted a lot of new editors with strong POVs who are eager to "fix" what they see as problems in its articles, and since it has attracted rampant socking; but it's a universal issue that occurs whenever an EC topic area attracts attention. --Aquillion (talk) 13:40, 1 October 2024 (UTC)
It is probably worth mentioning that while "slowing down socks" is certainly one of the objectives of EC, for the PIA topic area at least where ECR was introduced on 2019-12-20, it does not appear to have had a significant impact in terms of revision counts by identified socks. Sean.hoyland (talk) 15:32, 1 October 2024 (UTC)
The overwhelming majority of ECP articles are per arbcom remedies - if we just decide to weaken ECP threshold what I think is going to happen is: arbcom will just change their remedy again (creating another sweeping broken problem that causes all admins to try to scramble around to enforce it). Now, do we really need all these pages so protected -- good question that could be asked to candidates running for arbcom this year! — xaosflux Talk 14:22, 1 October 2024 (UTC)
Certainly for ARBPIA, in practice, the vast majority of articles covered by ECR are not EC protected. Enforcement is carried out by people and is quite expensive. As far as I can tell, answers to the question "do we really need all these pages so protected" appear to largely depend on the extent to which editors are grounded in the day-to-day reality of a topic area. The more time they spend active in the topic area dealing with non-EC edits/editors, the more likely they are to regard the restrictions as necessary/helpful etc. Sean.hoyland (talk) 15:00, 1 October 2024 (UTC)
This is confusing, "only to trusted people without any additional rights attached to it (and with a matching level of protection)"- if they have no permissions, then what is the point of yet another protection level? — xaosflux Talk 14:12, 1 October 2024 (UTC)
It's so I don't get another transphobic pile of trash vandalizing my user page again. LilianaUwU (talk / contributions) 01:02, 4 October 2024 (UTC)
I see that your userpage been vandalized a lot, and I'm sorry that extended-confirmed protection wasn't enough to stop it. In the absence of a stronger protection level (that you're still able to edit through), I think the following approach should be able to simulate one:
I know this is kludgy, and doesn't completely address the reasons behind your proposal, but I hope it might help you. jlwoodwa (talk) 18:53, 4 October 2024 (UTC)
...this is a 200 IQ play right there. I'll get to it later today. LilianaUwU (talk / contributions) 21:00, 4 October 2024 (UTC)
@LilianaUwU So aside from the workaround above, you still haven't explained much about this project-wide proposal. You want us to create some sort of user group, that contains no permissions (which we can't really do but we could make it contain something like 'read pages') and then also make some new protection level. So what would the point of this new protection level be? What changes are you proposing to the protection policy for its use? It sounds like what you are proposing is to create yet another protection level, and permissions for editing this 6th (more like 8'th) protection level -- and creating a new group that does have permission to make edits at this new level. In which case, this is also a seriously premature proposal. I suggest you close this down, go workshop up all of your new group and protection level suggestions on their own draft pages, then pop back here to get people to provide you feedback on the workshopping, then eventually come back here and propose it for community acceptance.
Now if what you are really after is something along the lines of: My userpage keeps getting vandalized, please help - the suggestion above is an option, or that is something you can ask for help over at WP:AN that wouldn't require a very complicated new scheme. — xaosflux Talk 22:12, 4 October 2024 (UTC)
I'm not sure why I even came here to ask about this when I could've went to AN, honestly. My main thing was about my user page being vandalized. Is there a way to close the proposal? LilianaUwU (talk / contributions) 22:14, 4 October 2024 (UTC)
Marked as archived - this is a huge place, easy to end up in the wrong forum. If there is a continuing problem, please do let us know at WP:AN -- if the admins can't figure out a way to manage disruption they will also know other people that can be brought in. — xaosflux Talk 22:47, 4 October 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Request for check user is meant to be for request for permission

Latest comment: 23 days ago4 comments4 people in discussion
This is not a concrete, actionable proposal. Information on the topic has been provided. — xaosflux Talk 20:33, 5 October 2024 (UTC)

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

OK 132.147.192.240 (talk) 02:21, 28 September 2024 (UTC)

Hi! Wikipedia:Requests for checkuser is inactive, and has been replaced by Wikipedia:Sockpuppet investigations. Also, while the names might be confusing, it isn't a request for permission, as it wasn't to request to become CheckUser, but rather to request assistance from a CheckUser in a specific situation. Chaotic Enby (talk · contribs) 02:25, 28 September 2024 (UTC)
Requests for checkuser access are handled by the Arbitration Committee, see Wikipedia:Arbitration Committee/CheckUser and Oversight for details. It's worth noting here though that it is one of the most restricted rights on the project (for good reason) and cannot (by both policy and technical restriction) be granted to IP editors. Thryduulf (talk) 02:34, 28 September 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Editing Sri Lankan Election 2024 page

Latest comment: 23 days ago3 comments3 people in discussion
This is not a concrete, actionable proposal. The content edit was already made and information on how to discuss content improvements has been provided. — xaosflux Talk 20:35, 5 October 2024 (UTC)

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

Could someone edit this page to show that AKD won. Idk how to edit elections Irindu10 (talk) 15:22, 22 September 2024 (UTC)

Looks like it has already been done. In the future, it is better to ask this on the article's talk page (here, Talk:2024 Sri Lankan presidential election), as it is more likely to be seen by editors more knowledgeable on this specific topic. This page here is for more wide-ranging proposals, rather than to request specific edits. Chaotic Enby (talk · contribs) 02:30, 28 September 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RfC on In the news criteria

Latest comment: 21 days ago1 comment1 person in discussion

There is a request for comment on the In the news criteria at Wikipedia:Village pump (policy) § RfC: In the news criteria amendments. voorts (talk/contributions) 23:01, 7 October 2024 (UTC)

Bring dark mode reporting on-wiki.

Latest comment: 11 days ago32 comments10 people in discussion

The current system is very convoluted. Being on a fourth level subpage on a different wiki with 90% of the comments not being signed, and using an emoji system for distinguishing resolved/unresolved issues makes it a nightmare for a) finding issues, b) responding, and c) asking for more details. It would be easier to have a page like Wikipedia:Dark mode reports so more editors could help fix issues. We should import the page here and archive the MediaWiki wiki page. Thoughts? @SCP-2000, FeRDNYC, and I Am Andumé: as editors involved there on fixing issues (if I've missed someone feel free to ping them). —Matrix(!) {user - talk? - uselesscontributions} 14:42, 5 October 2024 (UTC)

Survey (dark mode reporting)

Following the response from WMF, I think it's a good idea for a survey to check if we want to proceed further. @Xaosflux, FeRDNYC, SCP-2000, Isaacl, Phil Bridger, WhatamIdoing, and Thryduulf: and any other people, please state your position briefly:

Implementation

Okay, the consensus is the people fixing dark mode issues can decide the location, and FeRDNYC has also expressed the current issues with the current system. Dark mode issues are ultimately usually a local problem, and WMF has also said this is technically possible. We would need to do a few things:

  1. Import the MediaWiki page to enwiki with the options "Copy all the revisions for this page" and "Assign edits to local users where the named user exists locally" (this is important for archiving later).
  2. Use User:ClueBot III archiving (User:lowercase sigmabot III relies on signatures which won't work out)
  3. Repoint MediaWiki:Vector-night-mode-issue-reporting-notice-url and make MediaWiki:Vector-night-mode-issue-reporting-preload-content include signatures
  4. Archive the MediaWiki enwiki page.

I think we can start working on this. —Matrix(!) ping onewhen replying {user - talk? - uselesscontributions} 08:57, 12 October 2024 (UTC)

I'm fine doing the transwiki import for this when ready, but I'm not seeing a consensus in the discussion above yet. The "assign local" part is not needed; I doubt anyone at mwwiki will care about that page, we're not going to delete anything there but can just slap a cross-wiki redirect on it. So what next? Someone that hasn't !voted on this above should eventually close this discussion with a result. For the xmlimport part, feel free to ping me at that time. — xaosflux Talk 11:43, 13 October 2024 (UTC)
Fair enough. I'll wait for consensus to develop (I just got impatient since no once was participating). —Matrix(!) ping onewhen replying {user - talk? - uselesscontributions} 11:49, 13 October 2024 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_214&oldid=1253728755"