Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
"WP:PROPOSE" redirects here. For proposing article deletion, see Wikipedia:Proposed deletion and Wikipedia:Deletion requests.
 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:

Discussions are automatically archived after remaining inactive for nine days.

Page views link in the Tools menu

[edit]
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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
That's a pretty obscure location for the average Wikipedia reader. --Timeshifter (talk) 09:58, 9 September 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]

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

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)[reply]

Put page views link in talk header template too

[edit]

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,887,749 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)[reply]

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)[reply]
{{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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]
@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)[reply]
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)[reply]
[edit]
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)[reply]

  • 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
[edit]
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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

Stop

[edit]

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)[reply]

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)[reply]

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)[reply]

Yes, you did; noted. Mathglot (talk) 22:57, 15 September 2024 (UTC)[reply]
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)[reply]
[edit]

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)[reply]

Font options

[edit]

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

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)[reply]
Thanks for the tip honestly wasn't aware it existed WikipedianAncientHistorian (talk) 19:30, 17 September 2024 (UTC)[reply]
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)[reply]
oh makes sense thanks WikipedianAncientHistorian (talk) 19:30, 17 September 2024 (UTC)[reply]
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)[reply]
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)[reply]

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

[edit]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
I know, I just want to discuss it. Macxcxz (talk) 14:41, 17 September 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

Ethiopic fonts

[edit]

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)[reply]

You forgot to link to the page where you experienced a problem. —TheDJ (talk • contribs) 03:09, 20 September 2024 (UTC)[reply]
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)[reply]
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)[reply]
Same goes for me Ca talk to me! 04:33, 24 September 2024 (UTC)[reply]

New Page: Snakes Of Egypt

[edit]
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)[reply]

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)[reply]
@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)[reply]
Thanks! Irindu10 (talk) 13:58, 22 September 2024 (UTC)[reply]
@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)[reply]
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)[reply]

Editing Sri Lankan Election 2024 page

[edit]

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

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=1247893391"