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.


RfC: Enabling collapsible templates on the mobile site

There is consensus to enable the gadget. Overall, there is agreement to have the feature be opt-out, albeit with slightly weaker support than implementation generally. Participants often expressed the benefits of feature parity on desktop and mobile. Some editors commented that in the long run, they would prefer a solution in MediaWiki core or skins, although they endorsed the gadget as an interim measure. (non-admin closure) Frostly (talk) 03:50, 30 October 2023 (UTC)[reply]

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

Should a JavaScript gadget be installed and enabled by default to enable collapsible templates on the mobile site? — Alexis Jazz (talk or ping me) 09:35, 3 September 2023 (UTC)[reply]

Background (enabling collapsible templates on the mobile site)

When users of the mobile site encounter content in a collapsed template, they always see the content in an uncollapsed state with no way to collapse it. On some pages this can result in a long list to scroll past. For example, compare the "official status" section in the infobox of the article about the English language on the mobile site with the same article on the desktop site.

This has been a longstanding issue, phab:T111565 has been open since 2015. In response to myself and @Izno, @Matma Rex (who works for the WMF) said the following: As there are people opposed to making this change in MediaWiki core, I would suggest doing it in your wiki's MediaWiki:Common.js or a gadget, as long as your community finds that agreeable.

The reason some oppose making the change in MediaWiki core is the "fat finger problem", some people may have difficulty to tap short links titled "Hide" or "Show". The proposed gadget alleviates this issue by enforcing a minimal link element width of 6em.

The gadget can be tested on betacommons. If any bugs or serious issues with the gadget surface the deployment will be delayed until those issues are resolved. Similar to WP:ENOM, if the gadget is deployed this will be done in waves. — Alexis Jazz (talk or ping me) 09:35, 3 September 2023 (UTC)[reply]

Survey (enabling collapsible templates on the mobile site)

Discussion (enabling collapsible templates on the mobile site)

@Xaosflux, there are actually quite some use cases. ((Sidebar with collapsible lists)) for example is disabled on mobile because mobile can't collapse anything. As a result, any content that is shown using that template is inaccessible on mobile. ((Sidebar with collapsible lists)) is transcluded nearly 90.000 times. While this template won't suddenly become visible with this gadget (it uses the nomobile class), editors will be able to decide on a case-by-case basis if such a sidebar should also be visible on mobile which can be viable once collapsible elements are made available. For another example of an even longer list of countries in an infobox, see IPhone 14.
Some numbers on performance impact: the gadget is currently just 911 751 bytes and gets cached in localStorage. Measuring how long the script takes to load on a page without collapsible elements is difficult because a duration of less than 1 millisecond is hard to measure accurately. — Alexis Jazz (talk or ping me) 11:09, 3 September 2023 (UTC)[reply]

I'm pretty sure that discussion has already occurred that it was appropriate to not show this content on mobile; if it isn't it should be just fixed. — xaosflux Talk 15:20, 3 September 2023 (UTC)[reply]
Xaosflux, if at some point collapsible elements become available on mobile, like with this gadget, the editorial decision could be made on a per-article basis. There are other considerations regarding sidebars and navboxes, but there would be options. The status quo for existing usage of ((Sidebar with collapsible lists)) wouldn't change, but for existing usage a parameter could be implemented to suppress the nomobile class or it could switch to a different template. Module talk:Sidebar/Archive 6#How to override "class=nomobile" to display sidebar in mobile view? is an example where this could be done. According to that thread, "nomobile is used because the old class vertical-navbox is already hard-coded to be removed on mobile, but I wanted to change that class name to reflect the name of this module and because it was shorter for the purposes of TemplateStyles, so I added nomobile as a result." It doesn't say why, but the fact nothing can be collapsed on mobile will surely be one of the reasons for this.
nomobile is actually a hack, quote from User talk:Jon (WMF)#nomobile is my current annoyance today: "as the Minerva maintainer I'd love to remove the `nomobile` class in the Minerva skin eventually. Now all that said I wouldn't rely on `nomobile` at all to be honest. It was a short term fix for a long term problem. If you are using TemplateStyles just add a media query and display: none anything that you don't want to show on mobile and avoid the class entirely. There's no need to rely on it. Sure this will increase the HTML payload of mobile, but leave that to us WMF staff - we can always add rules for DOM-heavy elements at a later date."
The overall sentiment seems to be that navboxes should be enabled on mobile. See also phab:T124168. In what exact form is TBD, but one thing seems clear: without the ability to make elements collapsible on mobile, it can't ever happen. As a side note, the proposed gadget has one extra trick up its sleeve: it enables the creation of elements that are collapsible on mobile but don't become collapsible on desktop. This would make it possible to make long lists or tables collapsible on mobile only, potentially saving mobile users from some lengthy scrolling. Update: this mobile-only feature has been commented out for now and may be revisited if the gadget gets enabled as a default gadget. This gadget now more purely aims to replicate the functionality of the desktop site without alterations. — Alexis Jazz (talk or ping me) 01:32, 4 September 2023 (UTC)[reply]
The reason these don't display on mobile is partially the display. But a bigger reason is that navboxes do not suit the mobile need, which is predominantly get in and get out with the desired fact. This quality, combined with the basically useless and usually quite large HTML downloaded just to inevitably not need a navbox is why these are "disabled". (Why yes, MobileFrontend does rip them fully out of the HTML.) IznoPublic (talk) 15:45, 6 September 2023 (UTC)[reply]

Question - As a Gadget, would this be enabled for logged-out users? –dlthewave ☎ 14:35, 3 September 2023 (UTC)[reply]

Dlthewave, the way I phrased the proposal ("installed and enabled by default"), yes. However, if many votes include the condition that it be made opt-in I would consider that a valid outcome as well. If it would be enabled by default it would allow editors to assume the feature is available to mobile users when writing templates and articles which won't be the case if it's opt-in, but c'est la vie. If the proposal passes (without opt-in condition) the gadget will be deployed in waves. At first it'd be enabled for admins only and every week or so another group would be added: WP:extendedconfirmed, wp:autoconfirmed and finally everyone (including logged-out users). — Alexis Jazz (talk or ping me) 01:44, 4 September 2023 (UTC)[reply]
Good! I wasn't quite sure how gadgets worked, wanted to make sure it would eventually be available to all users. –dlthewave ☎ 02:44, 4 September 2023 (UTC)[reply]
Dlthewave, a gadget is a collection of JavaScript and/or CSS pages, similar to WP:User scripts. Unlike user scripts, they are centrally governed in MediaWiki:Gadgets-definition. Some gadgets, for example mw:Reference Tooltips, have the "default" parameter set in MediaWiki:Gadgets-definition, those are enabled and loaded by default. The wording "enabled by default" in the proposal refers to the default parameter in Gadgets-definition. — Alexis Jazz (talk or ping me) 06:57, 4 September 2023 (UTC)[reply]

Thanks for working on this. I left some suggestions for the implementation at Wikipedia talk: MakeMobileCollapsible.

Before enabling the gadget, please consider whether the "mobile-only collapsible" feature is really desirable. Personally I think we should avoid adding any mobile-only and desktop-only features these days, to avoid confusion for people who only use desktop or only mobile and see different things. It might also lead people to use collapsible elements in cases where other approaches would be better (per MOS:COLLAPSE): moving the content to a separate section (which are already collapsible on mobile, and easier to navigate using the TOC on desktop), or to a separate page – and since it would be mobile-only, the desktop power-users might not notice it.

And while we're talking about MOS:COLLAPSE, it will need some updating about the mobile support. Matma Rex talk 12:33, 4 September 2023 (UTC)[reply]

Matma Rex, interesting points. I added the "mobile-only collapsible" feature because it was easy and I believe there is a difference between mobile and desktop here: scrolling is more labor-intensive on mobile devices as you have no page up/page down keys and dragging the scrollbar is more difficult without a mouse or touchpad. If it turns out the feature goes unused or causes people to use less optimal approaches it could be removed easily and any existing uses could be updated by a bot in that case.
Header levels above level 2 don't become collapsible on mobile. I guess the only way to find out if it's a good idea is to just see if and how people would use it. If people don't use it or only use it when other approaches would be better, it could be scrapped at a later point. Btw, one way to use that feature is to combine mw-collapsible with mw-collapsed-mobileonly, resulting in a collapsible element on both mobile and desktop but which is only collapsed by default on mobile. I also think mobile-only collapsing could be an alternative for the nomobile class in some cases. — Alexis Jazz (talk or ping me) 13:32, 4 September 2023 (UTC)[reply]
Firefox won't even let me drag the scrollbar. It only supports manual scrolling. On the pages I linked to in my not-vote, it might take me forty or sixty seconds to scroll all the way down to what I'm tryna read. Usually I end up all the way at the foot of the page and have to work my way back up, but too aggressive of an upscroll will – alas – trigger a page reload. Anything to help ameliorate this would be quite welcome. Folly Mox (talk) 18:11, 4 September 2023 (UTC)[reply]
While we're on this tangent, adding a collapsibility to level three subheadings, defaulted to uncollapsed, would be pretty nice. Some of those get real long, and it would be convenient to collapse them if I'm editing them one after another. Folly Mox (talk) 18:31, 4 September 2023 (UTC)[reply]
I agree with Matma Rex here: let's not introduce mobile specific behavior, especially since that's not the primary point of the change we're trying to make here. (And were you going to do it, using the same class namespace as core functionality is a bad idea "mw-".) IznoPublic (talk) 15:51, 6 September 2023 (UTC)[reply]
@Matma Rex, what specifically needs updating about MOS:COLLAPSE? IznoPublic (talk) 15:48, 6 September 2023 (UTC)[reply]
For example this part: "the mobile version of the site, which has a limited set of features and does not support collapsing". Matma Rex talk 16:50, 6 September 2023 (UTC)[reply]
It... Doesn't, still. We just went from "displays nothing" to "displays everything", so I think that statement remains valid. (Perhaps less than obviously the context of that section ignores MF collapsing whole sections.)
As for limited set of features for mobile, yeah, less true, but also not totally relevant to that section, so removing it in toto might be called for. Izno (talk) 00:20, 7 September 2023 (UTC)[reply]
Oh, "will need". Missed the auxillary verb. Izno (talk) 00:36, 7 September 2023 (UTC)[reply]
Matma Rex, following your and Izno's comments, I commented out the mobile-only collapsing feature for now. If the gadget gets enabled by default I plan to open a discussion on enabling it again. Maybe in some more limited form, like only changing the default collapse state on mobile. For now, the gadget just aims to replicate the collapsing functionality from the desktop site. — Alexis Jazz (talk or ping me) 12:34, 7 September 2023 (UTC)[reply]
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 Module:Find sources - replace New York Times with Associated Press

Currently, the only media outlet in Module:Find sources/templates/Find sources is the newspaper The New York Times (nytimes.com). Should we replace it with the news agency Associated Press (apnews.com)? Previous discussions here and here. starship.paint (RUN) 04:18, 9 September 2023 (UTC)[reply]

Survey (Find sources: NYT vs AP)

Discussion (Find sources: NYT vs AP)

  • Are these the right metrics? Without expressing a preference for any of the choices, I'm not sure the metrics given above are what we should be prioritizing. First being paywall; we should strive for the most neutral and accurate sources, not the most free-as-in-beer. Unlike media (such as images or sound), for which we prefer freely-licensed content as we host and display that content directly, news sources should be the most accurate available, as it is in many other areas in Wikipedia that are not news-oriented. Next is international coverage— the "countries operated in" statement is not quite accurate. For example, NYT has actively staffed bureaux in many countries but that's more of a logistics matter; they will send reporters to any country in the world as needed and permitted. And I found at least three different figures in different areas of the AP site so I'm not sure what is going on there. Finally, I fear that a lot of this is moot because many news organizations' public-facing search capabilities are often terrible. As a test, I took the first linked term in today's WP:ITN (Tharman Shanmugaratnam) and tried it with both the AP and NYT search. The AP search returned nothing and the NYT search returned a lot of things, yet notably none of them relevant to the ITN item in question. Are we focusing on the right issues here? Orange Suede Sofa (talk) 05:59, 9 September 2023 (UTC)[reply]
    https://www.reuters.com/site-search/?query=Tharman+Shanmugaratnam
    https://www.bbc.co.uk/search?q=Tharman+Shanmugaratnam RZuo (talk) 06:23, 9 September 2023 (UTC)[reply]
https://www.nytimes.com/2023/10/23/pageoneplus/editors-note-gaza-hospital-coverage.html
so much for "NYT's factual reporting is neutral", "by far the best and most comprehensive US newspaper source", "enviable world-level reputation for fair and accurate reporting"... lmao.--RZuo (talk) 20:27, 23 October 2023 (UTC)[reply]
  1. ^ "GERALDINE'S NEW RECORD; MADE YESTERDAY AT THE NEW RACE TRACK. A MOST SUCCESSFUL OPENING DAY AT THE FINEST RACE TRACK IN THE WORLD". The New York Times. 1889-08-21. ISSN 0362-4331. Retrieved 2023-09-14.
  2. ^ Nast, Condé (2012-02-23). "The Beauty and Tragedy of Hungary's Supple Stringbike". WIRED. Retrieved 2023-05-27.

Enable RC patrolling (aka patrolling for edits)

This is something that has been bothering me for years now. Many other wikis have patrolling for edits in recentchanges and watchlist and it drastically improves efficiency of vandalism patrollers. Edits done by autopatrolled users automatically gets marked as patrolled, reverted and rolled back edits also automatically get marked as patrolled too (as there is no need to be reviewed again) but also when someone reviews an edit and it doesn't need to be reverted, they can mark the edit as patrolled which avoids double, triple or more reviews by others.

You can enable the filter to only look at unpatrolled edits (or combine that filter with other filters, such as ores damaging ones). The software for it already exists and this feature is enabled in Wikidata, Commons, French Wikipedia, Italian Wikipedia, Dutch Wikipedia, Chinese Wikipedia, Portuguese Wikipedia and Vietnamese Wikipedia (Wikis with above >1M articles) and many more wikis.

One concern was that it might start a massive backlog of edits needed to be reviewed (like pending changes) but the patrolled status gets purged after 90 days so no large backlog will be made (and it's better than status quo where there is no status stored). It was enabled in here in January 2005 but some people didn't like the "!" it adds next to unpatrolled edits. That was almost nineteen years ago when we didn't have ores or highlighting or filtering in RC/Watchlist. We can change that exclamation mark if people want it to or completely hide it (I can make the software changes necessary if there is consensus for anything different). That's not really an issue now.

What do you think? Ladsgroupoverleg 17:39, 10 October 2023 (UTC)[reply]

.Oppose If you believe something might be wrong you should check it yourself, not rely on other editors. Either this user right is limit to a small group, making it ineffective, or a larger group, opening it up to all kinds of abuse. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:36, 11 October 2023 (UTC)[reply]
I think you're wrong. You can choose to ignore this system and still check every change (do *you* check every change now?). You'll give the patrol right to your trusted users, with the possibility of having the right removed if they're no longer trusted; patrol actions are logged, and you can easily tell who marked each change as patrolled. Can you say that *every* change has been seen by someone (trusted) now? I'm pretty sure a user with, say, 2000 clean edits is a good patroller candidate, someone I'd trust. But I'd still sometimes take a look, even if the change was marked as patrolled. Nothing to lose here, trust me! Ponor (talk) 03:25, 15 October 2023 (UTC)[reply]
@ActivelyDisinterested, you say If you believe something might be wrong you should check it yourself, not rely on other editors, but there's nothing in this proposal that would prevent you from doing exactly that. So why the opposition? WhatamIdoing (talk) 01:09, 16 October 2023 (UTC)[reply]
I didn't say "I should check", maybe I should have said "should be checked". This system and many other recent discussion on similar things would mean that editors are relying on other editors for verification. That shouldn't happen, it's fundamentally wrong.
This has nothing to do with currently checking all edits, the question is trusting current edits. I don't blindly trust current edits, no editor should, but this would directly implement a system of doing exactly that. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 12:11, 16 October 2023 (UTC)[reply]
Our current system works like this:
  • Alice looks at Special:RecentChanges and looks at the diffs for edits 1, 2, 3, 4, and 5. She wasn't sure about edit 2, but she didn't think it was bad enough to revert. Maybe someone else will look at it.
  • Bob looks at Special:RecentChanges and looks at the diffs for edits 1 and 4.
  • Chris looks at Special:RecentChanges and looks at the diffs for edits 1, 2, and 4.
  • David looks at Special:RecentChanges and looks at the diffs for edits 1 and 4.
Result: Nobody looks the diff for edit 6 or 7. Four people have checked edits 1 and 4. Two people have checked edit 2. One person has checked edits 3 and 5. If you wrote it out in order, editors looked at diffs 1111223445XX.
Imagine that we instead said:
  • Alice looks at Special:RecentChanges and looks at the diffs for edits 1, 2, 3, 4, and 5. She marks edits 1, 3, 4 and 5 as okay, but isn't sure about edit 2.
  • Bob looks at Special:RecentChanges and looks at the diffs for edits 1 and 4, just like he always did.
  • Chris looks at Special:RecentChanges, turns on the filter so they can see what others haven't already accepted, and looks at the diffs for edits 2, 6, and 7. Chris marks edit 7 as okay, but isn't sure about edits 2 or 6.
  • David looks at Special:RecentChanges, turns on the filter so he can see what others haven't already accepted, and looks at the diffs for edit 2 and 6. David – who wouldn't have looked at either of these diffs under the previous system – is able to resolve the question about edit 2 but leaves edit 6 in the queue for another editor.
In this scenario:
  1. Any editor can still look at whatever they want, like Bob did.
  2. Any editor can voluntarily focus on the un-patrolled edits, like Chris and David did.
  3. The result is that more people look at the uncertain diffs, and somewhat fewer editors look at the obviously good edits. If you wrote it out in order, editors looked at diffs 1122234456667.
What I'm not hearing from you is any reason to believe that requiring all editors to randomly checking RecentChanges is a better system (as measured, e.g., in the percentage of diffs that get looked at by an experienced editor) than having the old system plus allowing some editors (i.e., those who want to) to check specifically the ones that other editors haven't indicated is okay. Adding this system takes nothing away from you. Why do you want to take away the opportunity to use a different system from the editors who want to use it? WhatamIdoing (talk) 17:42, 16 October 2023 (UTC)[reply]
I was going to say almost the same. We like to think that every change gets 'seen' by someone, but in reality I'm observing a lot of propaganda, wp:refspam, false statements, original research (...) being added and never reverted. This system will raise some red flags for those edits, especially as they get closer to the 30 day limit. Ponor (talk) 18:28, 16 October 2023 (UTC)[reply]
Nothing you added changes my point. It isn't, and has never been, about what editors can check and again it has absolutely nothing to do with what I can check.
As you have just said the purpose is for editors to not have to check obviously good edits. But that is just a backwards way of saying editors won't check edits based on the reliablity of other editors, and is directly in opposition to how things should be done.
Nothing you have said, nor anything anyone else has said in support of the proposal, changes that this change would have a large negative effect on the project. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:29, 16 October 2023 (UTC)[reply]
Or as an exaple.
1) Editor A marks a edit as approved
2) Editor B sees that editor A has marked as approved and doesn't check it.
3). FAIL -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:31, 16 October 2023 (UTC)[reply]
That could only happen if everyone is using it (I rate this as being exceedingly unlikely), and it could only make things worse if we additionally assume that Editor B does nothing (e.g., reviewing other edits and therefore finding other problems; I rate this as unlikely).
But again: Why should you get to effectively ban other editors from using this tool? Nobody's going to force you to use it, but why shouldn't other editors be permitted to do so, if they wanted to? WhatamIdoing (talk) 18:47, 16 October 2023 (UTC)[reply]
Other editors shouldn't use it because using it would have a negative impact on the project, for the reasons I have outlined (a few times). This is again, for the second time, nothing to do with my using it or not. Please stop trying to twist my words in that way.
The situation in my last comments happens every time an editor doesn't check an edit because another editor they trust "approved" it. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:10, 16 October 2023 (UTC)[reply]
The situation in your last comment happens only if no editors check an edit because another editor they trust "approved" it. It does not happen when some editors move on to other, unscreened edits.
This is already being done by anti-vandalism tools such Huggle, and the situation you hypothesize is already not happening. Why do you think that having one more tool doing this will create your situation, when your situation has not materialized through the tools that are already doing this? WhatamIdoing (talk) 21:03, 16 October 2023 (UTC)[reply]
Some or most makes absolutely no difference, as I have already stated about whether the right is given to a large group or a small one. Also the suggest 2000+ edits for an editor in good standing is not a small group, it would just be the new watermark to reach for POV pushers.
This is not done by current tools, or at least to my knowledge, at the moment edits are highlighted as potentially bad by an algorithm. This would mark edits as "good" in the opinion of an editor, the inverse of the current situation.
I've shown using your own example that there is a problem. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 21:36, 16 October 2023 (UTC)[reply]
This is done by existing tools. Some of them, including Wikipedia:Huggle, set up a feed with the idea that it's better to check all edits once than to check some of them multiple times and some of them never.
This green button is used in Huggle to mark an edit as a "Good Edit".
If the edit is cleared by one Huggle user, then it's not shown to other Huggle users. See mw:Manual:Huggle/Quick start#Controls, especially the green icon associated with the words "Clicking on the green pencil with the checkmark will flag the edit as a good edit."
You don't have the user right necessary to use Huggle, so I'm sure you've never personally seen it, but it's still happening whether you've seen it or not. WhatamIdoing (talk) 01:38, 17 October 2023 (UTC)[reply]
I don't care for such things, due to the many issues such things cause. If this is already happening it's not something we should encourage, as per my previous statements. Making a bad situation worse, doesn't make it better. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 12:32, 17 October 2023 (UTC)[reply]
So:
  • it's been happening for years, and
  • you believe it causes many issues, but
  • you can't point to a single example of any issue it's ever caused.
Okay. WhatamIdoing (talk) 17:52, 18 October 2023 (UTC)[reply]
Or as an example. (1) Editor A marks a edit as approved (2) Editor B sees that editor A has marked as approved and doesn't check it. (3). FAIL
The issue with this reasoning is that patrol actions are logged, and you can easily tell who marked each change as patrolled, quoting Ponor. In other words, there's accountability. Make a few mistakes, fine (page watchers probably couldn't have caught it either), you'll get some feedback and learn. Make consistent mistakes and your RC patrol right is revoked. DFlhb (talk) 23:24, 16 October 2023 (UTC)[reply]
So great we now have to have watchers for the watchers. How about instead don't have such a system, and all editors are watchers of all edits. I made a similar point in my original statement. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 12:34, 17 October 2023 (UTC)[reply]
You don't need to watch the watchers. No one in other wikis do that, there are many ways to surface incorrect patrol including highlights, people who don't use the edit patrolling, etc. Ladsgroupoverleg 14:08, 17 October 2023 (UTC)[reply]
That other wikis don't do something I feel they should do is the epitome of OTHERSTUFFEXISTS. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:28, 17 October 2023 (UTC)[reply]
In you list of checks, 1122234456667. The problems is that 3 and 5 could be the edits with issues, but because everyone takes Alive as a reliable source they are not checked again. This change creates an environment where editors are trained to think in ways that the opposite of how they should think about the situation. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:41, 16 October 2023 (UTC)[reply]
Sorry, I should have specified from the beginning, from my viewpoint as the omniscient narrator that edits 2 and 6 were the suspicious edits. WhatamIdoing (talk) 18:49, 16 October 2023 (UTC)[reply]
So yes, your suppositions are correct if you control all the variables. But life is not like that. In a real world situation were you are not the "omniscient narrator" edits 3 and 5 could be the edits with problems, and your system would mean they are not checked when they should be. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:05, 16 October 2023 (UTC)[reply]
Edits 3 and 5 weren't checked in the existing system, either. WhatamIdoing (talk) 01:23, 17 October 2023 (UTC)[reply]
Maybe, maybe not. But this system ensures they are not, because it's a system that trains editors to not check such edits. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 12:35, 17 October 2023 (UTC)[reply]
At most, it would "train" the ~9,000 of admins and editors who have rollbacker rights to divide the workload rationally. The rest of us – more than 100,000 editors each month – wouldn't be able to use it. WhatamIdoing (talk) 14:53, 17 October 2023 (UTC)[reply]
It would train them to do something I have repeatedly said I feel is a negative the project. That you don't have the same opinion is obvious, that you don't seem able to take onboard that I disargree is verging of IDLT territory. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:27, 17 October 2023 (UTC)[reply]
I have no idea why my opposition in particular has gained so many replies, but I've had enough of it. I won't be replying to any further comments. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:30, 17 October 2023 (UTC)[reply]

Discussion (Enable RC patrolling (aka patrolling for edits))

Could someone comment on the other large wikis that the proposer is referencing? Do they have a large editor base that is similar to en-wiki? The smaller wikis of my acquaintance tend to have sufficiently few highly active editors that triaging patrolling by the "have I heard of this editor" method is a rational strategy.

Also, could an admin active in permissions comment on how much scrutiny is given to rollbackers? My guess is not enough to grant this kind of right, but I don't work in this area. Espresso Addict (talk) 00:45, 12 October 2023 (UTC)[reply]

They are mentioned in the proposal Ladsgroupoverleg 10:22, 12 October 2023 (UTC)[reply]


Two notes:

@Ladsgroup, have you talked to your colleagues in Tech, just to make sure that the servers won't fall over if this is enabled here? WhatamIdoing (talk) 00:54, 16 October 2023 (UTC)[reply]
@WhatamIdoing yeah, specially since this is enabled in wikidata (which has a massive flood of edits) which caused issues in 2017 and I overhauled how the data is stored around that time and now it's quite healthy. Ladsgroupoverleg 12:11, 16 October 2023 (UTC)[reply]

What is the proposed workflow for a bad edit? If User:Vandal serves up spam and User:Helpful reverts the addition, is the first edit marked as patrolled because it's been assessed, or left unmarked because it wasn't approved, or marked in some other way as bad but dealt with? What if the first edit isn't marked "reverted"? (Perhaps the second edit also fixes a typo, or it keeps part of the first edit because it mixed useful information with a spammy citation.) Certes (talk) 11:14, 18 October 2023 (UTC)[reply]

@Certes If it's a rollback, it automatically gets marked as patrolled by the software itself. I think that is also the case by manual revert but not 100% sure. But conceptually a reverted edit is a patrolled one since there is no further action is needed. Ladsgroupoverleg 14:05, 18 October 2023 (UTC)[reply]

Should this be mentioned in CENT or if there is a wikiproject for patrolling (I couldn't find one), notify its members? Ladsgroupoverleg 14:22, 18 October 2023 (UTC)[reply]

The most relevant one would probably be WP:CVU. Alpha3031 (t • c) 22:32, 18 October 2023 (UTC)[reply]
done Ladsgroupoverleg 14:44, 20 October 2023 (UTC)[reply]

RfC about the criteria for existence of emoji redirects

Shortcut

What should be done with emoji redirects, particularly with emoji redirects that are found to represent vague concepts that are not well reflected on Wikipedia? Utopes (talk / cont) 02:52, 16 October 2023 (UTC)[reply]

Initial options
  • Option 1: All emoji redirects should target lists of symbols by default, such as emoji which appear on Supplemental Symbols and Pictographs or Symbols and Pictographs Extended-A.
  • Option 2: Emoji redirects should only target pages where the emoji is directly mentioned or referred to, such as Face with Tears of Joy emoji. All other emoji should instead exist as redirects to relevant lists of symbols.
  • Option 3: Emoji redirects should only target pages where the emoji's depiction is deemed unambiguous, such as 🔥 being a redirect to fire. All other emoji should instead exist as redirects to relevant lists of symbols.
  • Option 4: Emoji redirects should only target pages where the emoji's depiction is deemed unambiguous, such as 🔥 being a redirect to fire. All other emoji with ambiguous designs should be deleted, and not target lists of symbols.
  • Option 5: Emoji redirects should only target pages where the emoji is directly mentioned or referred to, such as Face with Tears of Joy emoji. All other emoji redirects should be deleted.
  • Option 6: Delete all emoji redirects.

Update: The options have been recontextualized. If an article mentions or refers to an emoji, such as Face with Tears of Joy emoji, it is currently practiced to have the emoji in question (😂 in this instance) exist as a redirect to such page. This is the status quo for these situations, which is not being disputed. This RfC was intended to address the gray area where there isn't a perfect match for a target, so I've narrowed the options as follows:

For emoji redirects that don't have an associated article in existence, should we:

— Preceding unsigned comment added by Utopes (talk • contribs) 16:45, 16 October 2023 (UTC)[reply]

Background

Over the last several months, there have been several Redirects for Discussion entries at increasing frequency about the justification for the existence of emoji redirects. At this point, there are often several different discussions happening on a weekly basis, which often boil down to the same general viewpoints about how to deal with redirect emojis as a whole. Some past discussions that have recently closed in September and early October include the following: RfD on 🤪, RfD on 🙀, RfD on 🤭, RfD on 👩%E2%80%8D💻, RfD on 💨, RfD on 🫸, among many discussions which were also ongoing during this period, as well as many others which have cropped up and still have not been closed. The only precedence which has been recorded is in an RfD subset page which documents the common outcomes of discussions, and under the section for WP:REMOJI. During recent discussions, however, this documentation has been challenged and dated, particularly relating to emoji that can be depicted and interpreted differently on multiple platforms and different people, and whether or not a redirect is necessary for these emoji in the first place. Comments on this matter would be appreciated to help determine whether or not all emoji should inherently be considered as "likely search terms" and automatically exist as redirects, or whether there should be criteria for inclusion for emoji redirects to exist in the first place. Utopes (talk / cont) 02:52, 16 October 2023 (UTC)[reply]

Survey (Emoji redirects)

Option 2 is my second choice. I strongly oppose Option 8. We should not have to create entire DAB pages for emojis. We're not emojipedia. And, as a side comment, there is a tendency at RfD that the "definition" of the emoji as listed in unicode is the end-all of potential interpretations. Edward-Woodrow • talk 19:45, 16 October 2023 (UTC)[reply]
And also, I maintain that emojis are unlikely search terms, that we're not emojipedia, and that we should have to provide results for people pasting emojis into the search bar for who-knows-what reason. But consensus seems unlikely to swing that way. Edward-Woodrow • talk 19:48, 16 October 2023 (UTC)[reply]
I'm now in favor of finalizing a list of emoji and retargeting them all there. Draft:List of emojis (faces) looks excellent! -- Tavix (talk) 19:51, 20 October 2023 (UTC)[reply]
I support that too, given that it clears up the ambiguities effectively. Edward-Woodrow • talk 19:57, 20 October 2023 (UTC)[reply]

I've added a partition here, as the options' wording has been adjusted. For the suggested Options 7 and 8 proposed above, Option 8 now more closely aligns with the current Option 2 (minus the redlink clause), whereas Option 7 would be the rejection / opposition of all other options, and to deal with redirects on a case by case basis. Utopes (talk / cont) 16:50, 16 October 2023 (UTC)[reply]

The new option 2 does not closely match option 8 as it is missing the important clause about emoji with multiple article matches (e.g. 🔴 → Red Circle (a disambiguation page), 🥙 → Stuffed flatbread (a set index)) as well as the redlink clause. Thryduulf (talk) 18:07, 16 October 2023 (UTC)[reply]
@Thryduulf:. Apologies for the delay, I've been extremely busy this last week and wasn't able to properly return until addressing the RfC situation that has since formed.
For what it's worth, I said that the new option 2 was more close to the Option 8 as suggested, but not exactly due to the redlink clause. It was more close due to the narrowed range of "only emoji redirects without articles". As for the rest of Option 8's contents, I didn't (and still don't particularly) agree that the "multiple article matches" is important as stated to include within the text of the Option (to otherwise differentiate it from Option 2), because the intent of Options 2&3 was to be the catch-all options for any other article possibilities beyond databases or deletion respectively. Because of this, set index articles and disambiguation pages would fall under this if appropriate, because from my point of view the 4 options presented were wholly encompassing of all possibilities. There were essentially 2 proposed criteria, with 2 fully-encompassing binary solutions to deal with them. While the first binary of "keep (at database) or delete emoji redirects where no other target is appropriate" is present in the form of 1&2 versus 3&4, the second binary would be the one that this interpretation is relevant to: Options 1 and 4 suggested to treat ALL emojis the same regardless, whereas Options 2 and 3 proposed that emojis should be treated differently on a case-by-case basis depending on how the image is depicted. From my point of view, Option 8 has the same intention as that, but keeps going with extra examples that to me seem as if it would still be supported by Option 2's solution. The only difference, however, is the mention of red-linked emojis, which I see to be a different subject matter entirely which falls outside the scope of the 2 x 2 binary options. Set index articles are still articles, so I don't see how that is different from the provided example of 🔥 to the fire article. 🥙 still unambiguously depict a Stuffed flatbread, which happens to be a set index article. To me it seems like yet another valid example.
I'll concede that this intention behind the Option could have been confusing, however, as only the fire was shown to explain what it might look like. Furthermore, I guess it can be said that "maybe this type of RfC question shouldn't have been designated with options to begin with". In removing options entirely, this could allow for more involved possible solutions. To me though, this broad path did not feel correct or needed, as there are a seemingly small number (2) of crossroads that needed solutions (such as whether or not a gray area exists). Open forums can work well in RfCs, but here it would effectively be picking and choosing different emoji to assign with different solutions... that all still match the same overarching precedent that "there IS no precedent and each should be dealt with on a case by case basis, depending on whether a regular article, set index article, or a disambiguation page seems to be most appropriate from the depiction". These all fall under the same umbrella, and can be summed up without needing to declare which styles of articles that can and can't be targeted, effectively declaring criteria to set index, criteria to disambiguate, criteria to red-link and etc.
Because of this, I feel like I once again lean back towards the thought that the 4 options were sufficient enough. The second binary option posed by 1&4 vs 2&3, in my eyes, was essentially asking to choose between "There is no gray area (treat all the same, i.e. 1&4)" or "There is a gray area (case by case, i.e. 2&3)". At the risk of duplicating my words, there is no gray area between the two binary conclusions of "there is gray area" or "there isn't". If there's ANY gray area, the latter option (represented by 2&3) would seem to me to be sufficient to capture that, which is what the proposed Option 8 does. The only difference, because of this, would appear to be the redlink clause, which wasn't a part of the two binaries (and also feels to be a different can of worms because emoji's without articles will never be red, as they will appear the same regardless of whether they are an article or not. The cases of emoji with associated articles is easily countable (exactly 8 as of now) so the referred-to cases of emoji that could receive articles but don't have them already feels like it should be a separate topic for "which redirects should be deleted to encourage article creation")
I do wish in hindsight that I could have painted a better picture with clearer intentions behind the option description, because I did feel when putting this together that the 4 options listed sufficiently covered the two main goals of the RfC. I think that focusing on just the new 4 to begin with would have made things a lot easier to wrap heads around, because shifting the goalpost inward was still a shifting of the goalpost. But even then, it seems to me that from the beginning, Option 8 was still covered within the worlds of combining old Option 2 and old Option 3 (making Option 8 a warranted combo-solution at the time). Post-revision, though, it looked to me as if Option 2 was just it, minus the redlink clause. As for the other alternative suggestion, Option 7 was just in opposition towards using an RfC to come up with a solution, which seems to be a paradox and was only given a number for formality. (It's certainly a valid position to be opposed to using the RfC to prescribe a universal solution, but voting for an Option called "7" through the means of the RfC would still be prescribing a universal solution of "no universal solution"... The text is more closely akin to a "none of the above" pathway. I guess it could be given a number for ease of reference, but it certainly falls squarely outside of the proposed grid of 6 solutions -> 4 revised solutions.)
It seems that this RfC may be restarted, which is fine and definitely understandable. I was talking with the User King of Hearts in the discussion section, which was the very first message in the RfC which is where the 4-option alternate setup was first proposed. The conversation between us developed throughout the evening, and I implemented the suggestion on the same day the RfC started. Because the context behind the change was completely available, I believed that restructuring the votes based on the immediate RfC feedback would be uncontroversial as the context behind the change was all quickly accessible, and I figured that collapsing the original options and partitioning the original votes would make things clear moving forward. I did not expect the older alternatives solutions to carry over past the partition line, but this was on me for not clearly structuring the vote options to begin with. I do think a vote will eventually happen on this topic in some capacity, but using this space to figure out what to cover in the future emoji-redirect RfC seems like what will happen at this juncture, whether it is more of an open forum, a series of yes/no propositions, or what have you. Utopes (talk / cont) 07:54, 28 October 2023 (UTC)[reply]
@Utopes: I've only skimread your comment (tl;dr applies) so apologies if I've missed anything, but the "grid" you keep talking about needing to fit things into seems completely arbitrary? That multiple keep are supporting options not in your first or revised set suggest that the considerations left out are important. As for changing options midway through an RFC, that's rarely not going to result in confusion. Thryduulf (talk) 09:58, 28 October 2023 (UTC)[reply]
No worries, I'm going to be heading to bed soon but it was something I had on my mind after seeing the direction things went in regards to the RfC post-option refinement. This could be my misinterpretation as well, but I feel cumulatively we may be saying the same thing in regards to Option 2 vs 8, possibly. Option 2 as above is written "Retarget to pages where the emoji's depiction is deemed unambiguous". The emoji 🔴, to this effect, unambiguously refers to a red circle. Therefore, my view of Option 2 is that it would suggest this emoji be redirected to Red Circle. Such target happens to be a disambiguation page, but it is a page nonetheless, hence why I viewed Option 8 to be redundant on this factor (and in part was why I was concerned things were getting out of hand with the 2 vs 8 😅). If this interpretation of Option 8 is correct and the same as how you described it here, I feel now could be a worthwhile time to workshop and prepare for a potential RfC redo, as the option switch certainly did not make it easier by any means, although I underestimated its negative effect. Utopes (talk / cont) 10:12, 28 October 2023 (UTC)[reply]

Discussion (Emoji redirects)

Notifying @Edward-Woodrow:, @Lenticel:, @Gonnym:, @Thryduulf:, @Tavix:, @Enix150:, @Illusion Flame:, @MicrobiologyMarcus:, @Yoblyblob:, @TartarTorte:, @Hey man im josh:, @Qwerfjkl:, @Ivanvector:, @Polyamorph:, @Rosguill:, @A smart kitten:, @Pppery:, @ClydeFranklin:, @BDD:, whom have weighed in on one of the currently ongoing emoji redirect discussions. Utopes (talk / cont) 03:15, 16 October 2023 (UTC)[reply]

@Utopes: I'm not sure the options are set up optimally. It should be completely uncontroversial that emojis with articles should target those articles, such as Face with Tears of Joy emoji, no matter which option we choose for the rest. Then we have four options for emojis without articles: a) redirect all to Unicode block (same as your 1 & 2); b) redirect to unambiguous subjects, else default to Unicode block (same as your 3); c) redirect to unambiguous subjects, else delete (same as your 4); d) delete all. -- King of ♥ ♦ ♣ ♠ 03:21, 16 October 2023 (UTC)[reply]
@King of Hearts: I think you're probably right in the sense that a delete-all option would be a beneficial "nuclear option", so I will go ahead and add that. With that out of the way, in that case, would your suggestion be to remove Option 1 or 2 and shift everything else up? My reasoning for including a difference between #1 and #2 was to have an option that was close to nuclear while allowing some valid exceptions, i.e. "emoji redirects are only valid to articles about emoji". I think this differs from Option 1, which I felt would be the standard nuclear option that is directly opposite of mass-deletion, using the stance that "emojis shouldn't ever be redirects to topic articles, and should only ever target lists of symbols (because emoji are symbols)".
If you think its too uncontroversial, I'll strike it out, but wanted to make sure I was understanding your thought process first. Utopes (talk / cont) 04:19, 16 October 2023 (UTC)[reply]
@Utopes: I think there are way too many options now, which just makes it more confusing. And the problem is that outside of Options 2 and 5, it is unclear what is being proposed for emoji redirects to direct targets. Instead there are two orthogonal questions: 1) If there is an article on an emoji (as the subject of the article), should the emoji redirect to that article? (Note that this question does not ask what to do if the answer is no. I assumed the answer here is obviously yes, but maybe it's not so obvious and it doesn't hurt to ask.) 2) For all emoji redirects that have not been explicitly allowed under the previous question, what should be the criteria for inclusion? (Here we have my four previously proposed options.) -- King of ♥ ♦ ♣ ♠ 08:31, 16 October 2023 (UTC)[reply]
I see what you mean. I think the current option setup made a bit more sense in my head than in practice. I viewed there to be three different "priorities" that emoji redirects could have. They could be treated as "symbols" and symbols only, they could be treated as the image they depict, or they could not be dealt with at all (and deleted). In other words, a "Yes", a "Yes, AND", and a "No". In general, I feel like 6 options is likely the "maximum" number to be able to wrap around (especially if its fundamentally a 3x2), although it also depends on the options themselves. Option 1 and 6 might have been too extreme of choices by ignoring obvious alternatives to mass-deletion/redirection, and unnecessarily add complexity because of it, so I'll take your advice and re-contextualize the solutions. Utopes (talk / cont) 16:28, 16 October 2023 (UTC)[reply]
fwiw, I don't think I received this ping, not sure anyone else did. signed, Rosguill talk 13:48, 16 October 2023 (UTC)[reply]
No, pings only work when they are signed in the same edit. The ping edit was not signed. -- Tavix (talk) 14:38, 16 October 2023 (UTC) [reply]
Huh, I didn't realize that the ping's functionality depended on a signature; I put the ping-list together after setting things up to alert people that it's live. At this rate, I'm not sure whether it would be worth it to re-send the pings though. Utopes (talk / cont) 15:46, 16 October 2023 (UTC)[reply]
At this point it can't hurt. Notifying @Edward-Woodrow:, @Lenticel:, @Gonnym:, @Thryduulf:, @Tavix:, @Enix150:, @Illusion Flame:, @MicrobiologyMarcus:, @Yoblyblob:, @TartarTorte:, @Hey man im josh:, @Qwerfjkl:, @Ivanvector:, @Polyamorph:, @Rosguill:, @A smart kitten:, @Pppery:, @ClydeFranklin:, @BDD:. Edward-Woodrow • talk 19:57, 16 October 2023 (UTC)[reply]
Comment I think this has completely spiraled as a result of the numbers changing and I'm not sure what information we can glean from the current state of the RfC. microbiologyMarcus (petri dish) 13:45, 18 October 2023 (UTC)[reply]
Support closing the RfC and workshopping a second one here. Edward-Woodrow • talk 19:37, 18 October 2023 (UTC)[reply]

Some1 I like the idea of a list of emojis, as a middle ground between targeting the literal meaning and targeting the block. That would also give us room to note different meanings (at least those that reliable sources discuss). Here's my vague idea for what an entry would look like:

😨 Fearful Face (U+1F628) used to x or sometimes y.

Edward-Woodrow • talk 21:30, 17 October 2023 (UTC)[reply]

@Tavix, Gonnym, Thryduulf, Enix150, and Utopes: what do you think of that idea? Edward-Woodrow • talk 21:31, 17 October 2023 (UTC)[reply]
There are 3,664 emojis as of the latest update so if such a list would be created, it would probably be needed to split into a few pages, but in general I'm not opposed to anything that can make the target more clear. Gonnym (talk) 08:37, 18 October 2023 (UTC)[reply]
I agree with Gonnym. It should have a link to the relevant Wikipedia article, so perhaps something like:
😨 Fearful Face (U+1F628) see Fear.
The link should be to the article(s)/dab/etc that most closely matches the definition, unless we have reliable sourcing that it is used for some other/additional meaning (otherwise it's WP:OR). Thryduulf (talk) 09:57, 18 October 2023 (UTC)[reply]
Here is an initial attempt Draft:List of emojis (faces). Gonnym (talk) 10:59, 18 October 2023 (UTC)[reply]
@Gonnym, that looks good to me, though it might be worth adding images as well. I'm seeing boxes for a few of them. — Qwerfjkltalk 19:43, 21 October 2023 (UTC)[reply]
I like this, but is there any reason we can't do this out of the previous emoji block articles (just adjust their format)? Skarmory (talk • contribs) 21:17, 23 October 2023 (UTC)[reply]
At this point I think it's probably best to wait until the new version is completed and then propose a merge or redirect. Thryduulf (talk) 21:52, 23 October 2023 (UTC)[reply]
Would blanket redirect of all emojis to a table with anchors to the specific emoji and then the descriptions, with interwiki links not be the best use case then? I've begun workshopping a draft in the draftspace: Draft:List of Emojis microbiologyMarcus (petri dish) 15:16, 26 October 2023 (UTC)[reply]
I would probably support Option 2-prime Redirect to list of ... meanings. Compare A, X, 7, !, Æ. Some emoji only have one notable, natural meaning; others might have a "literal" meaning and multiple notable figurative meanings; in the latter case, yes there should be a disambiguation page. And if there's a group of closely-related emoji with similar meanings and history, it might be appropriate for each to be a redirect to an anchor-within-a-table within an article about the group. DavidLeeLambert (talk) 21:07, 26 October 2023 (UTC)[reply]
I really like the way Wiktionary (you know, the project where glyphs-as-glyphs are in-scope) handles these. Compare wikt:🥙, wikt:🤾, wikt:🔴. —Cryptic 22:27, 26 October 2023 (UTC)[reply]
Two of those currently don't have entries, but, yes, I agree I like wiktionary's approach (they're freer because unlike us, they are a dictionary). An option is to retarget them all to wiktionary (which been done with a few already, I think). Edward-Woodrow • talk 12:01, 27 October 2023 (UTC)[reply]
Part of my point is I like the way Wiktionary handles them even when it doesn't have entries - for one-character-long entries in their main namespace, they transclude wikt:Template:character info on wikt:Mediawiki:Noarticletext. —Cryptic 04:14, 28 October 2023 (UTC)[reply]

Hebrew in Latin

Hello, I’ve noticed that many Hebrew words are transcribed wrongly. For example, on of the cities in Israel is transcribed <Holon> instead of <H̱olon>, so are many other places in Israel. I suggest changing all names according to this very list: https://hebrew-academy.org.il/2022/06/27/%d7%a8%d7%a9%d7%99%d7%9e%d7%aa-%d7%94%d7%99%d7%99%d7%a9%d7%95%d7%91%d7%99%d7%9d-%d7%91%d7%99%d7%a9%d7%a8%d7%90%d7%9c/

This isn’t only for English, but for any language that uses the Latin alphabet – French, German and even Turkish. מושא עקיף (talk) 03:19, 21 October 2023 (UTC)[reply]

The general rule on English Wikipedia is to use the name most commonly used in reliable English-language sources, even if that differs from the official transliteration. In the case of Holon/H̱olon, it seems as though the transliteration without the diacritic is common and the usage is in line with our usual policy Caeciliusinhorto (talk) 13:18, 22 October 2023 (UTC)[reply]

Reopen Wikipedia:Books page since the concept of a "Wikipedia Book" still exist

Whether a Wikipedia Book was created using the Book Tool or not, this page needs to be reopened immediately even if the namespace was removed or if the tool is not working. The more general concept of a Wikipedia Book still exists. ModernDaySlavery (talk) 20:26, 21 October 2023 (UTC)[reply]

The page tell us about a tool and namespace that are no longer functioning or available. Book tool no longer functions and namespace deleted. Moxy- 22:53, 23 October 2023 (UTC)[reply]
Book tool still does function, just the PDF functionality doesn't function. Also I removed references to the namespace. Also if you want I can even add the book tool is no longer supported (even only a feature of it isnt supported) but the concept of a book made of wikipedia article is very important and therefore the page should still continue. ModernDaySlavery (talk) 23:00, 23 October 2023 (UTC)[reply]
As the Book Creator no longer generates copies of Wikipedia books, its primary working feature directs users to order printed Wikipedia books from PediaPress, a third-party company. Editors in discussion valued the user experience of Wikipedia readers over the business prospects of PediaPress. Moxy- 23:37, 23 October 2023 (UTC)[reply]
It does generate Wikipedia books just not in PDF form. See User:Lasertrimman/Books/Hart / OSI. In addition there is also MediaWiki2LaTeX that allows you to download Wikipedia Books. Also like I said the concept of a Wikipedia Book remains, a Wikipedia Book doesn't even need to be created by the Wikipedia Book tool, it just refers to a collection of Wikipedia articles. Creating a new Article for the concept doesn't make sense. ModernDaySlavery (talk) 23:57, 23 October 2023 (UTC)[reply]

Stepanakert/Khankendi

An unrecognized state in Nagorno-Karabakh no longer exists, the city of Khankendi is completely under the control of Azerbaijan, they even hung a state flag there. But the Armenian moderator cancel edits about renaming the city, leaving the unrecognized and irrelevant name “Stepanakert”. Please make the title "Khankendi" in the article 109.87.192.15 (talk) 09:17, 22 October 2023 (UTC)[reply]

Per Wikipedia:Official names, we do not change the name of an article just to recognize an official name. The naming of the article should be in accordance with the provisions of Wikipedia:Article titles#Deciding on an article title. Discussion about renaming the article should continue on the article's talk page. Donald Albury 12:03, 22 October 2023 (UTC)[reply]

To create an Editor Communication Feedback noticeboard

See also: Wikipedia:Village pump (proposals)/Archive 116 § Do Away with RFC/U

Communication is crucial in society in general and Wikipedia in particular as an essential part of the editing and consensus process. As such I was thinking it would be a good idea to have an Editor Communication Feedback noticeboard. Therefore, I propose creating it to promote good communication between editors. Currently there is no place to discuss communication between editors, except as a disciplinary issue. I am aware there used to be a Requests for comment/User conduct project but my proposal is diametrically different and addresses the main points of contention of that former venue.

From the discussion to discontinue said RfC/Uc,

The community is of the opinion that it no longer serves a useful purpose, that it has a tendency to prolong disputes without helping their resolution, suffers from a lack of participation, attracts biased input, and that it pales in comparison to other processes. There is no consensus for any specific replacement, nor that finding one is required before deprecating RFC/U. Other components of the dispute resolution process should be used, such as ANI and ArbCom. There are some legitimate concerns regarding those alternatives, specifically that ANI isn't well equipped to handle long term issues while at the same time the bar for ArbCom is quite high, meaning a lack of proper venue for handling certain kind of disputes, but they don't justify maintaining a system recognized as inefficient (in those cases too).

The noticeboard would be for constructive and positive feedback, neither as an instrument to impose sanctions, nor to further disputes, nor to condemn.

  1. The purpose of the noticeboard would be to promote (not enforce) good communication between editors.
  2. The objective of the discussions would be to provide neutral feedback to editors on how to improve communication, what could have been done better in the thread being analyzed, what could have been avoided, what strategies could be used in the future.
  3. The noticeboard should not be used for negative actions against editors such as evidence in disciplinary proceedings.
  4. Some rules,
    1. Provide respectful and constructive feedback, avoiding attacks or condemnation.
    2. Limit participation in the analysis discussions to extended confirmed editors.
    3. Barring from the discussion analysis participation of editors involved in the dispute wouldn't participate in the discussion. Any doubts about the motives or objectives of their communications would have to be figured out by those participating in the discussion because after all if they can't figure it out, that signals there was a communication roadblock.
    4. Barring from the discussion analysis editors who have had disputes or edit warring with the editors whose thread is being analyzed would be restricted from participating in the discussion.
    5. Restricting editors who may act as proxies of editors who have had disputes with the editors whose thread is being analyzed advising them not to participate in the discussion.
    6. Participating editors should avoid taking any given disputing editor side.

Thinker78 (talk) 19:48, 22 October 2023 (UTC) Edited 22:03, 22 October 2023 (UTC)[reply]

Pinging @Cenarium, Robert McClenon, and Jehochman:, main participants of the former RfC about the User Conduct forum. Thinker78 (talk) 19:51, 22 October 2023 (UTC)[reply]
Rules 4.3, 4.4, and 4.5 do not parse.
If rule 4.5 is interpreted as forbidding proxying for another editor, it may do more harm than good, if it allows editor C to claim that editor B is proxying for editor A.
More generally, if rules 4.3, 4.4, and 4.5 all exclude editors, the result may be that there may be as much quarreling over whether editors are excluded as discussion of the original topic. Robert McClenon (talk) 20:50, 22 October 2023 (UTC)[reply]
Rule 4.3 has littler room for misinterpretation or different interpretation. Rule 4.4 could be instead barring in the discussion editors who have had edit summary or talk page interactions with the editors in dispute, so as to reduce the risk of disputes in the interpretation. Rule 4.5 would advise proxy editors from intervening but that would be a honors system because difficult to establish who may want to proxy. Then as long as rules 1 and 6 are respected, there would be less risk of an issue even if they are secretly proxying for the interests of other editors.
Although of course, no system is perfect. Regards, Thinker78 (talk) 22:14, 22 October 2023 (UTC)[reply]
It is true that there seems to be only one interpretation of what 4.3 is trying to say. It still doesn't parse. Robert McClenon (talk) 03:44, 23 October 2023 (UTC)[reply]
A key challenge with the former requests for comments on user conduct process was that there was no incentive for the user in question to read any of it. I'm not clear how your proposal addresses this. With your proposed rule 3, the incentive is also reduced for participation by anyone if it means that either poor behaviour on the proposed noticeboard cannot be discussed in other venues, or if specific poor behaviour discussed on the proposed noticeboard cannot be discussed in other venues. isaacl (talk) 23:39, 22 October 2023 (UTC)[reply]
  1. "there was no incentive for the user in question to read any of it". The WP:Dispute resolution noticeboard also has the same issue. In fact, it states, "You are not required to participate". The proposal is to promote good communication. Certainly not everyone would want to read the analysis but certainly many others may. It would be one more tool for those editors in the dispute resolution process and also those interested in improving or seek feedback in their communication.
  2. "poor behavior on the proposed noticeboard cannot be discussed in other venues". Rule 3 doesn't state this, it is about the threads themselves of the noticeboard not being used in disciplinary proceedings. The behavior of course can be discussed wherever.
Regards, Thinker78 (talk) 00:29, 23 October 2023 (UTC)[reply]
Without addressing how to provide incentives for the user to engage, I do not feel you have addressed a main point of contention with the RfC/U process.
If someone lays out poor behaviour X, Y, and Z in a thread on the proposed noticeboard, then someone later raises these behaviours at the incidents' noticeboard, the subject can claim via rule 3 that since the behaviour was already discussed, no sanctions should be given. This is a disincentive for others to use the noticeboard, which will reduce its effectiveness. isaacl (talk) 04:03, 23 October 2023 (UTC)[reply]
"Poor behaviour" would be addressed by newly minted rule 7: Include about the issue a brief, neutral statement or question. Therefore, poor behavior wouldn't be accepted as a neutral statement or question about the issue.
Should rule 3 be discarded? Regards, Thinker78 (talk) 04:38, 23 October 2023 (UTC)[reply]
Discussing what could have been done better in the thread being analyzed, what could have been avoided will result in discussing undesirable behaviour. isaacl (talk) 18:34, 26 October 2023 (UTC)[reply]
That's one of the objectives, with the aim to improve communication between editors. Regards, Thinker78 (talk) 22:18, 26 October 2023 (UTC)[reply]
Exactly; thus your proposed rule 7 is a non-sequitur to the concern I raised. isaacl (talk) 22:49, 26 October 2023 (UTC)[reply]
No because although the editors in the noticeboard would discuss communication issues that may include undesirable behavior, it doesn't mean that they should state it is undesirable behavior or that editors should refer to the case as undesirable behavior. Check also rules 2 and 4.1. Regards, Thinker78 (talk) 22:57, 26 October 2023 (UTC)[reply]
Yes, I quoted rule 2. Discussing what could have been done better in the thread being analyzed, what could have been avoided is equivalent to discussing behaviour that is undesirable, as it should have been avoided and could be improved. A basic tenet of providing effective feedback is to identify the concern. isaacl (talk) 23:10, 26 October 2023 (UTC)[reply]
Yes but it is not necessary to state that it is undesirable behavior. It should be stated in neutral or positive terms for constructive criticism what could have been done better or how it could be better. After all, behavior that is undesirable for some is desirable for others. Regards, Thinker78 (talk) 02:23, 27 October 2023 (UTC)[reply]
Proposed rule 3 doesn't rely on whether or not something is called undesirable behaviour; it bars use of any of the discussion no matter how it's worded. That's why proposed rule 7 isn't relevant to my concern.
Regarding constructive criticism: saying a behaviour should be avoided is equivalent to saying (in the speaker's view) that it is undesirable. Clearly describing problematic behaviour can still be constructive, with the commenter providing clear reasoning, and ideally based on common agreed-upon principles. isaacl (talk) 04:01, 27 October 2023 (UTC)[reply]
Should rule 3 be discarded? Regards, Thinker78 (talk) 04:34, 27 October 2023 (UTC)[reply]
I can't picture how this would work in practice. If parties are snarking at each other, and someone steps in to criticise their communication skills, is that really going to mollify them? I have a feeling it would just open up a new frontier in the dispute, probably moving the discussion even further away from content. Barnards.tar.gz (talk) 20:58, 23 October 2023 (UTC)[reply]
That would ring true about any other noticeboard though. Besides, the Feedback noticeboard would analyze a discussion only if editor (s) involved in the discussion brings the case (although they would not participate in the discussion). Regards, Thinker78 (talk) 22:14, 23 October 2023 (UTC)[reply]

Article renaming

CLOSED
This discussion is better served locally, at the Talk Page of the article, not here. Forum Shopping is frowned upon. Perhaps, consider an RfC at that page GenQuest "scribble" 03:33, 26 October 2023 (UTC)[reply]

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

Hi, my problem is the article renaming of Dobrujan Tatar, we did make some discussions, but there is no result. Where I think it's better to rename it to "Dobrujan Tatar language". But everytime it's rejected, for the first time it was called "Dobrujan Tatar", we did make a discussion, there was the result "Dobrujan Tatar dialect", for the second discussion was actually not result to find (but there was an Idea, called "Dobrujan Tatar dialects"). And also I think the name "Dobrujan Tatar dialect" was wrong. Zolgoyo (talk) 22:15, 22 October 2023 (UTC)[reply]

@Zolgoyo: Consensus is that that is not the right name for the article. Edward-Woodrow • talk 21:21, 23 October 2023 (UTC)[reply]
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.

Signature wiki markup

OP is currently indef blocked. If someone else wants to re-propose this go ahead and unarchive. — xaosflux Talk 18:39, 25 October 2023 (UTC)[reply]

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.

Increase the character limit for signatures if it is wiki markup. Wiki markup is far longer than regular text making the current limit rather stifling, especially if you are using many formattings/templates. G'year talk·mail 22:41, 22 October 2023 (UTC)[reply]

Then don't use so many formattings, and do not use (unsubsted) templates, parser functions, images, and so on . See Wikipedia:Signatures#Length for why the current technical limitation is embraced by our signature guideline, so even though you've apparently found a way around it you're not allowed to make use of it. Anomie⚔ 11:42, 23 October 2023 (UTC)[reply]
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.

Elon Musk

Again, let's not WP:FEED the (off-site) troll, shall we? Edward-Woodrow • talk 20:40, 25 October 2023 (UTC)[reply]

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.

It usually isn't a good idea to feed the trolls or fan the flames, but should editors draft a formal response to Musk's increasing attacks on Wikipedia? He is, after all, one of the most influential people in the world — ironically according to the "mainstream media" that he hates. Musk has always been critical of Wikipedia (and by extension, the WMF), but recently he has been mounting an all-out attack on the platform formally known as Twitter: [1] [2] [3] [4] [5] [6] [7] [8]. InfiniteNexus (talk) 17:01, 23 October 2023 (UTC)[reply]

I say no. He's the ultimate troll. Jimbo has done a fine job of responding on his own. – Muboshgu (talk) 17:05, 23 October 2023 (UTC)[reply]
Ignore. It’s all hot air. Loads of people gripe about Wikipedia. He can join the queue. Barnards.tar.gz (talk) 19:15, 23 October 2023 (UTC)[reply]
Ignore. Musk is just scared. The Banner talk 00:34, 24 October 2023 (UTC)[reply]
There's around a thousand admins. We can edit the main page. That's a million dollars each. Who's with me?! ScottishFinnishRadish (talk) 01:33, 24 October 2023 (UTC)[reply]
Unfortunately for you, the 12 interface admins, who can modify the MediaWiki files and change the name of the site everywhere, have a better chance of claiming the money. Plus, it's almost 100 million each - who could blame them? BilledMammal (talk) 01:37, 24 October 2023 (UTC)[reply]
Brb, opening a request at WP:BN. ScottishFinnishRadish (talk) 01:39, 24 October 2023 (UTC)[reply]
Keeping it that way a full year is absurd. Would he pro-rate the payment so that we could just do it for a day and get $2.74 million? jp×g 04:34, 24 October 2023 (UTC)[reply]
Never heard of him. Levivich (talk) 02:29, 25 October 2023 (UTC)[reply]
Hear! Hear! GenQuest "scribble" 17:40, 25 October 2023 (UTC)[reply]
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.

Automatically put RfCs that are 30+ days old to WP:CR

WP:RFCEND says that by default, Legobot will assign a 30-day period to an RfC and then "forget" about it. I have encountered some unclosed RfCs in the archives. Currently, to create a request, a user must manually submit it to CR. Because most discussions are closeable at the 30-day mark, it would make sense to list all of these "old discussions" so that people direct their attention to them. Can someone write a piece of code that would contain the following info:

See WP:WHENCLOSE. Not everything needs a formal close, and if everybody has moved on without one then that's usually a sign one wasn't needed. Also, some discussions are very much not mature at the 30 day mark. Together this means that this proposal would fill up WP:CR with discussions that don't need closing (yet) making it harder for prospective closers to find the ones that do. Thryduulf (talk) 19:56, 26 October 2023 (UTC)[reply]

2023 Israel–Hamas war has an RFC

2023 Israel–Hamas war has an RFC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. BilledMammal (talk) 01:50, 27 October 2023 (UTC)[reply]

Rule that will cover anachronistic informations in the articles

At the moment there is an RFC with a question whether ”Christopher Columbus was an Italian explorer” or ”Christopher Columbus was an Genoese explorer”. One of the editors noted that this has been discussed for 20 years. Given that there is a possibility that mention of modern nations in the context of historical figures is an anachronism, as far as I know from my editorial experience this is not acceptable in articles given that time context in which a person lived must be used. I think there should be a rule that will solve this question. This same rule should determine the guidelines in which it must be proven that some information is anachronism. While the second part of the rules would determine what is done in such cases. Considering that without this rule we have uneven articles, I think that this rule is inevitable and necessary. The same rule will apply to all cases of anachronism in articles. I think that debating some things for 20 years does not make sense, it is better to adopt a new rule that will make the work of editors easier.

I am asking interested editors are you in favor of adopting a new rule which will concern the problem of anachronism in the articles? If necessary, I will write a new rule myself and put it up for discussion.

Mikola22 (talk) 08:20, 27 October 2023 (UTC)[reply]

I might be sleepy, but I don't understand what exactly is being proposed here. We shouldn't have anachronisms in articles? We have to provide a source when removing anachronisms? We should have anachronisms when they help the general reader understand a topic in a specific historical context that is not well understood by non-specialists? Folly Mox (talk) 11:08, 27 October 2023 (UTC)[reply]
Wikipedians argue indefinitely about a lot of things, it's kind of our thing. I don't think we can come up with a blanket rule on how to deal with anachronisms. For example, the vast majority of articles on archaeological sites describe them as being located in a modern country, which is technically anachronistic, but it wouldn't be very helpful for readers to learn that Nibru was a city in Kengir. It needs to be decided with on a case by case basis, following the lead of reliable sources. – Joe (talk) 12:21, 27 October 2023 (UTC)[reply]
@Folly Mox and Joe Roe: There is no rule on Wikipedia regarding information which are out of time context. Let's say a certain historian from Rome and the Roman Empire is presented as an Italian in the article. And now for 20 years there has been a debate whether he was Italian or Roman. I think that in such case it would be good to have a rule or guideline that we can refer to, so that the article contains information in accordance with the sources and time context. Furthermore, we now have a situation where the time context is respected in some articles and not in others. The situation is anarchic in this regard. If something else needs to be clarified, feel free to ask. @Joe Roe In any case, everything depends on the sources, if 5 RS says that a person from the first century is Roman and 5 RS says that he is Italian, we won't going to debate for 20 years about who he was? If something is an anachronism and this is determined by the opinion of editor majority, then we cannot keep this information in the article. For now, such informations are legitimate because there is no guideline that would regulate this situation. Mikola22 (talk) 12:58, 27 October 2023 (UTC)[reply]
Even if there was agreement on whether any particular item is an anachronism, it would be extremely difficult to write guideline or policy that encompasses all topics in a way that captured the many possible nuances out there. Suggesting that an editor majority overrules reliable sources is even more unlikely to be a solid basis for policy. Nationality is a particularly tricky topic, MOS:NATIONALITY has some existing guidelines. CMD (talk) 13:57, 27 October 2023 (UTC)[reply]
Regarding 'editor majority overrules', I meant in the sense that guideline or policy which concerns anachronism exist. If that guideline or policy defines anachronism as forbidden, it would be sufficient that some RFC establish that some information is anachronism, and such information would gain legitimacy for removing from the article. Mikola22 (talk) 18:13, 27 October 2023 (UTC)[reply]
I think I understand the proposition now, but I'm not sure I would support it. For one thing, it shouldn't take an RFC to determine if something is anachronistic. A reliable source should suffice, although I accept there may be edge cases where published experts disagree. The other thing is that anachronism can be helpful to anchor understanding in a familiar context, as Joe Roe mentions, and as is also common in my topic area, early China, where toponyms are almost universally located with respect to present-day geography, names are written in modern Chinese characters, etc.
Whether a particular instance of anachronism is helpful enough or necessary enough to be present in an article, and whether it needs to be called out as anachronistic and where: these are questions that RfCs can answer, but usually only after normal editing and normal discussion, I feel. Folly Mox (talk) 20:19, 27 October 2023 (UTC)[reply]
I always look at the RFC in which the arguments must be consistent with the sources. And in that sense anachronism would be determined on the basis of sources in which would be written that some information is not in accordance with the time context. I know from Christopher Columbus sources where one RS states that Christopher Columbus is not Italian because Italy did not exist at that time. But in the article he is presented as Italian although there are many sources which talk about him as a Genovese. So this information are not enough by itself to remove anachronistic name Italian from the article. But if there was a rule which determines this question, the Italian fact would be replaced tomorrow. It wouldn't even need RFC in a wider sense. This rule can also regulate question of old toponyms etc in a manner that is acceptable for today's time. Some information can also be excluded, etc. Mikola22 (talk) 03:52, 28 October 2023 (UTC)[reply]
Huh? What source states he was not Italian? Walrasiad (talk) 06:17, 28 October 2023 (UTC)[reply]
Christopher Columbus by Ernle Bradford, first page[10] Mikola22 (talk) 06:23, 28 October 2023 (UTC)[reply]
It doesn't say Columbus was not Italian. It uses some rather careless wording to emphasize that individual loyalties may be parochial. But Italy existed. Indeed, Genoa was a fief of the Kingdom of Italy. Walrasiad (talk) 06:36, 28 October 2023 (UTC)[reply]
He uses wording in the context of anachronism. However, this is not the issue we are dealing with here, so it is not really important. Mikola22 (talk) 07:31, 28 October 2023 (UTC)[reply]
It illustrates that editors have different interpretations of sources, and what is or is not anachronistic, and how different terms are used in different contexts. That's what talk page discussions are for. Walrasiad (talk) 14:46, 28 October 2023 (UTC)[reply]
That's a 50-year-old book. Levivich (talk) 20:36, 28 October 2023 (UTC)[reply]

Shorten most clean up messages to two sentences

This proposal might be a bit radical, however, I do think this is necessary for reasons to be explained. In my opinion, current clean up templates are longer than it should be and is an example of instruction creep. Most templates in Wikipedia:Template index/Cleanup should be simplified to two sentences (within the realm of the proposal's spirit):

  1. stating the problem, and
  2. saying "Please improve this article if you can" and link to other policy/guideline/how-to pages/resources (including the removal notice).

This is because the content after the first sentence are either a truism for Wikipedia in 2023 like:

or just a redundant rephrase of the first sentence:

Making the clean up template shorter will make the template less BITEy to newcomers and easier to gloss over by editors, which in turn will increase the likelihood that the issue mentioned in the template itself will be fixed. The template should not be a place to exhaustively list possible actions to deal with the issue, because we can add link to other resources that would talk about the problem in much more nuance than any template tag can do.

However, I think it might be controversial to remove the "Please improve this article if you can" phrase. This is because even now many readers have no idea that you can edit Wikipedia and they can help fixing the problem itself (but see below for a counterpoint).

There is precedence that shorter clean up messages does not reduce the context of the cleanup problem:

CactiStaccingCrane (talk) 15:12, 28 October 2023 (UTC)[reply]

I think it might be controversial to remove the "Please improve this article if you can" phrase. This is because even now many readers have no idea that you can edit Wikipedia and they can help fixing the problem itself (but see below for a counterpoint). What did you intend as the counterpoint? That Template:Multiple issues hides each template's call to action in favor of its own call? Or that inline templates are just a word or two but link to a page that hopefully has a call to action? Anomie⚔ 16:36, 28 October 2023 (UTC)[reply]
Multiple issues. Sorry if I haven't clarify it in the proposal. CactiStaccingCrane (talk) 04:11, 29 October 2023 (UTC)[reply]
Some of these cleanup templates are overly-long and repetitive. Please help improve these templates by removing any overly-long or repetitive content. Levivich (talk) 20:41, 28 October 2023 (UTC)[reply]
Yeah, strongly support. The simpler the better. DFlhb (talk) 08:26, 29 October 2023 (UTC)[reply]
Hmm, if the proposal is so obvious, should I just... do it? CactiStaccingCrane (talk) 15:36, 29 October 2023 (UTC)[reply]
  • I think I no Disagree with this, not necessarily because passers-by wouldn't know you can edit Wikipedia, but because the fairly frequent, dispersed reiteration of such is important to demonstrating the culture. If I can project back, I think seeing the relatively common beckonings for contribution made it much more likely that I would eventually end up contributing.
  • I don't think additional terseness makes articles less BITEy, quite the contrary, actually.
— Remsense聊 19:28, 29 October 2023 (UTC)[reply]

RFC could use some additional input

This infobox discussion on Georges Feydeau is wrapping up and could use some more input. All feedback is welcome to help find a consensus. Thanks! Nemov (talk) 19:35, 30 October 2023 (UTC)[reply]

Categories