Jump to content

Wikipedia:Village pump (proposals)/Archive 181

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

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

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

RfC: look of Authority Control

There is sufficient support (among A/B voters) to use the new proposed style as a starting point, pending other improvements proposed and discussed on the template talk page. There is currently no consensus on default collapsing behaviour. — Martin (MSGJ · talk) 10:03, 7 June 2021 (UTC)

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


Can the new style of the Template:Authority control, as demonstrated in the articles in this list, be used instead of the current style (used in these)? This is a follow-up of this RfC, which had consensus for the general principles behind the redesign, but didn't have a definitive layout to agree upon yet. Fram (talk) 07:36, 7 May 2021 (UTC)

  • A: the new style as proposed
  • B: the new style, but autocollapsed
  • C: something else

Discussion (look of Authority Control)

  • Support A, second choice B, as RfC initiator. After the RfC, there has been discussion and proposals on the template talk page, with the version as now (temporary) implemented in the "Arts" subtemplate as a compromise between the RfC results and some extras that were wanted (like accommodating multiple IDs from one institution, or keeping the explanatory link for some of the more obscure acronyms). Articles like Pablo Picasso give an idea of how the new look would be: on many articles, it will be smaller of course. There is still disagreement about whether the new version may be implemented now or needs an RfC first, so here we are. If you don't support the new layout, then please indicate how to improve it while respecting the result of the previous RfC. Please don't relitigate the previous RfC though, if possible. Fram (talk) 07:42, 7 May 2021 (UTC)
  • Oppose – gives, in mainspace, way too much prominence to a rather technical aspect: the new design gives even more bandwith to this than the old design. Suggestions:
    1. In #Authority control above the question was raised whether we should have this template at all. That was already one of the points following from the previous RfC: I'd suggest to ask that question in a formal RfC (which may go in another direction than the current informal discussion), before this second RfC on the design goes forward.
    2. At Andy Warhol#External links (just taking the first example of the list proposed in the OP), the new design is shown *uncollapsed* under two collapsed navboxes: for Wikipedia these (internal) navboxes are far more important than the (external) unique identification (which can be handled by WikiData): *as a bare minimum* the new design should be shown collapsed, *at the very least* always autocollapsing when the article contains an internal navbox of whatever kind.
    3. The color scheme of the authority control box (new as well as old design) follows the standard color scheme of internal navboxes: the color scheme should be *different* (as in: a color scheme not normally used by internal navboxes) and *less conspicuous* (colors that draw not attention whatsoever), thus proposing to use only grey-scale background colours in the template (instead of the purplish background colors now). Authority control is a rather technical aspect (not really encyclopedia content as such), and such less colorful background colors would be a better indication for that.
--Francis Schonken (talk) 08:49, 7 May 2021 (UTC)
  • Oppose – even leaving aside that the point of authority control is not the links to AC sites, but the unique identifier values, which this proposed design hides, the new design takes up too much space in too many cases, making multiple table rows where one is currently used, often with a single identifier on each - the proponents of this unnecessary change have acknowledged that they have done no research into how many such cases exist. It also removes links to Wikipedia articles which explain the origins and use of those identifiers (example on template talk page). The close of the previous RfC explicitly stated that there was "not any consensus on the exact form that an improved version might take." Insistence that anyone not approving the new design must provide alternatives is false; unless a better proposal is made and meets community approval, the status quo pertains. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:24, 7 May 2021 (UTC)
    • I don't think you will find many people who agree that the point of AC is the values, not the links. The links without the values (i.e. this proposal, and the one accepted at the RfC) is or can be useful to get extra information; the values without the links would just lead to this template being deleted(or at the very best hidden from view, like persondata in the old days) in the blink of an eye as utterly useless clutter. Nothing was "acknowledged" in the way you claim, and you fail to mention that "one is currently used" is a rather one-sided manner of presenting the current template, where you often have one "row" which is displayed over multiple "lines" anyway (depending on the number of entries obviously, and on your screen width and font size).
    • There is consensus, community approval, for a new layout much like the one proposed now, and there is community approval to get rid of the current version. Opposing the new layout without providing alternatives which respect the result of the previous RfC is just stalling to get the result you want, the already rejected status-quo. Fram (talk) 10:40, 7 May 2021 (UTC)
      • "I don't think you will find many people who agree that the point of AC is the values" Perhaps; perhaps not. But anyone who has taken the time to understand what AC is will know that that is so, and that's what's important.
      • There was consensus for a vague proposal for an unspecified new layout, but as we all know, consensus can change, and now you need to demonstrate consensus for a specific proposal. People can choose that, or an alternative if one emerges, or the status quo if that is deemed to be the best option. So far, it is. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:53, 7 May 2021 (UTC)
  • Oppose The issues discussed on the talk page need to be resolved first: in particular, the new template has a lot more whitespace than the previous one, and it doesn't include wikilinks to the relevant articles (and discussion on that talk page has been needlessly dramatic, which isn't a surprise given the people involved in this rewrite). My preference would be to go back to the previous version, which also showed the ID values (which is useful), and just change the acronyms to the words used by the new template, which meets the consensus from the previous RfC. Thanks. Mike Peel (talk) 10:34, 7 May 2021 (UTC)
    • Auto-collapsing would be even worse, since that would hide the content. Making it smaller, like the old version, is a far better solution. Thanks. Mike Peel (talk) 10:55, 7 May 2021 (UTC)
  • Note: I have added options above, as "it's too big" seems to be the common theme here. @Pigsonthewing, Mike Peel, and Francis Schonken:. Fram (talk) 10:51, 7 May 2021 (UTC)
  • And why has this new design been implemented, without consensus on the 14K articles using {{Authority control (arts)}}? That change described as a "Test" should be reverted immediately. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:06, 7 May 2021 (UTC)
  • Note that, having learned from many previous experiences, I will not respond to comments from Pigsonthewing and Mike Peel, as they seem incapable or unwilling to post about the template without adding snide remarks or outright attacks on the people they don't agree with (just read their replies above, or other related discussions). Please take whatever they write here with a big grain of salt. Fram (talk) 11:10, 7 May 2021 (UTC)
    • Note that this is untrue, however Fram has a long history of doing *exactly what they are claiming of Andy and me* in any discussion about Wikidata. This harassment has been going on for years now. It's generally better to focus on the facts than the drama, but unfortunately they can't help it. Mike Peel (talk) 11:21, 7 May 2021 (UTC)
    • And just 92 minutes later, Fram responds to Mike Peel. I mention this as it needs to be noted that Fram will respond when they choose to; which means that lack of response to other posts (such as my pointing out that their RfC is therefore no longer neutral; or that consensus specifically for what they are now proposing needs to be demonstrated)) is selective, and is not for the (bogus) reason stated immediately above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:01, 7 May 2021 (UTC)
  • Fram, I think it would've been better to do the AC RfC at the top first. If AC is to be scrapped, or changed to a different form altogether, then spending time trying to redesign it is wasted. I think that this RfC is required (or such is felt) is somewhat IDHT - the will of the previous RfC on design was quite clear, so I don't really see why this is necessary. ProcrastinatingReader (talk) 11:16, 7 May 2021 (UTC)
  • Oppose. Consensus has not yet been reached, as requested, @ Template talk:Authority control, so why are we having a premature RfC?
  ~ Tom.Reding (talk ⋅dgaf)  11:52, 7 May 2021 (UTC)
  • Why should there be consensus at the template talk page before starting an RfC here? It was obvious that no such consensus was possible there, with the same few people arguing against each other. The previous RfC (also started without consensus, and boy has that been complained about by you three) clearly showed that the opinion of you three is out-of-sync with that of many other editors. The time has come to gather wider input instead of clashing again and again about the same issues. Fram (talk) 12:15, 7 May 2021 (UTC)
  • So that's one OPPOSE and three SUB-OPPOSES? Would you like fries with that? — JohnFromPinckney (talk) 12:23, 7 May 2021 (UTC)
  • COMMENT - I think this RFC needs to be put on “hold”... it is counter-productive, given that we currently have an open RFC (above) about whether to have any AC templates in our articles. It won’t matter what the template looks like if the consensus in the above RFC is to not have it at all. Blueboar (talk) 12:49, 7 May 2021 (UTC)
    • I don't see an RfC, but obviously if there's a proposal to remove this from 1-point-however-million pages, there would need to be (plus CENT, yada yada). — Rhododendrites talk \\ 13:07, 7 May 2021 (UTC)
      It's not an RfC yet per se. I wanted to 'test the waters', because I knew it would devolve into what it has, but wanted some time for some less involved people to opine, particularly on viable options. I guess by definition it'd be more suitable in the idea lab, but I don't know that place to be successful at achieving much, so wanted to try this. I don't think a normal RfC (i.e. a survey/discussion-style) would be conclusive, in part due to the persistent personalisations, so I'm still thinking on what form it should take. There's also some brainstorming going on by less involved parties and maybe that might help bridge some gaps between different views on this template. In any case, I obviously wanted to take some aspect of the proposal to an RfC... ProcrastinatingReader (talk) 13:21, 7 May 2021 (UTC)
      • Sorry, my bad... There is an ongoing discussion (above) about whether to have (or not have) the template at all, and I assumed it was an RFC. Thanks for pointing out that it isn’t.
So, I will change my comment to: “C” - something else (my preference would be to provide a simple link to Wikidata - similar to how we link to commons for images - instead of hosting the AC stuff directly in our articles) Blueboar (talk) 14:20, 7 May 2021 (UTC)
  • A somewhat reluctant A, I guess. Not collapsed by default, but with whether it should be collapsed left to an article-by-article basis. Definitely open to C, too, if someone has other ideas. I don't fully agree with the closing statement of the last RfC. There was clear support for the RfC statement about making this template user friendly, but most people didn't actually speak specifically to the example provided (and many who did were highlighting issues with it). But that RfC is what we have, and nobody has challenged the close AFAIK. So we have the idea that we must make it more user friendly, and an example to use as a rough starting point for discussion of what that should look like. At the same, I think there are a lot of people who like the idea of user-friendliness but didn't really think about just how big that would make some of these templates. If the design of the old version of the template had one virtue it was being compact, of course. So I suspect the user-friendliness may make ultimately it easier for those who want to remove it from the page to convince others, ironically. We'll see, I suppose. — Rhododendrites talk \\ 13:07, 7 May 2021 (UTC)
  • Support A This RfC constitutes forum shopping (by the opposers of the original RfC, not by Fram) in an attempt to overturn the clear consensus of the first RfC. As I wrote on the template talk page, the [original] RfC shows clear consensus that the sandbox is preferable to the status quo. That consensus should not be overturned by a few vociferous objectors on the talk page. Also weakly support B, on the grounds that, again quoting myself from the template talk page, I [see] no reason to deviate from the standard navbox behavior (of autocollapsing when there are two or more navboxes and not collapsing when there is only one navbox). * Pppery * it has begun... 13:55, 7 May 2021 (UTC)
    • Fram starting an RfC (nor indeed later changing it to be non-neutral) is not me or anyone else forum shopping. When you wrote that on the talk page, I replied [emphasis in original]: The burden is on you to show consensus for the change you propose to make (and not just for a change). Note also that the RfC did not speak at all about the version currently in the sandbox, which was not presented there; indeed, it explicitly stated that there was "not any consensus on the exact form that an improved version might take.". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:54, 7 May 2021 (UTC)
  • A, looking at the examples below. It is much more human-readable, and I'd call it an incremental improvement over the old template. I think the default auto collapsing behavior is fine (collapse when it's not the only footer template). I also think though that we should pursue an RFC based out of the earlier discussion here above, as there are some alternatives (like link to wikidata or an intermediate enwiki page) that could make AC redesign moot. Levivich harass/hound 16:28, 7 May 2021 (UTC)
  • A - while I like authority control templates, I don't like the fact that they're so cryptic. This would be a big increase in usability at a relatively small cost of more "junk" at the bottom of a page. Guettarda (talk) 16:44, 7 May 2021 (UTC)
  • B I don't think our readers actually use this template much, heck I can't remember the last time I actually used an authority control template. This template should stay out of sight and out of mind; if folks really want it they can uncollapse it. Frankly, the whole idea of Authority Control seems like something mostly for internal use, perhaps it would be best to put such templates on talk pages instead. CaptainEek Edits Ho Cap'n!⚓ 21:30, 8 May 2021 (UTC)
  • B to the extent that we're doing this RfC, per CaptainEek. Second choice option A, because something slightly longer and... English... is better than something shorter and machine. ProcrastinatingReader (talk) 12:24, 9 May 2021 (UTC)
  • B As per the comments above. Sea Ane (talk) 19:56, 9 May 2021 (UTC)
  • B seems to the ideal compromise for providing extra and immediately available information to readers, without shoving it in their face. Of course, the more accessible layout is certainly desirable for our readers, who will be surely confused otherwise. Aza24 (talk) 20:12, 9 May 2021 (UTC)
  • B with A as a close second. Per ProcrastinatingReader above. The new version is (I'm guessing) substantially more understandable to the overwhelming majority of people. Ajpolino (talk) 15:55, 14 May 2021 (UTC)
  • B All of the new examples are less bewildering than any of the old ones. Autocollapse allows formatting into logical groups without being offensively large most of the time. Information remains available but unobtrusive. · · · Peter Southwood (talk): 08:22, 15 May 2021 (UTC)
  • A (or possibly C but I don't have a suggestion myself, it's a hard problem!) I oppose autocollapsing: as many have pointed out the term "Authority control" is not well understood outside librarians, and hardly provides an explanation to the average user of why they might want to expand the template. If it starts expanded then at least it's very clear "oh, these are links/cross-references to other sites". Wikipedia is not paper, no trees will die from the extra space taken up, people will just need to scroll a few more millimetres to view the categories or the thrilling legal blurb of the footer. (I appreciate there are more issues with the size on mobile, but the template doesn't display there, and as far as I can tell there's no plans to make it do so.) the wub "?!" 16:52, 23 May 2021 (UTC)

Examples

From the template testcases page:

Old:

new:

old:

new:

-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:21, 7 May 2021 (UTC)

Note: the above examples are fictitious, these ones don't appear on a real article. The RfC made sure that next to the 1 million examples of the old template, there were 14000 examples of the new template to be checked out on actual articles (as the previous RfC example was said to be "cherry-picked"), but the 3 main opposers of all these changes have reverted all efforts to do this, claiming "disruption" (the new version worked just as well as the version they reverted to, and showed the same number of ACs). Basically, the 3 defenders of the status quo are doing everything in their power to disrupt this (and the previous RfC, and the discussions at the template talk page). A very tiring situation, about which I started Wikipedia:Administrators' noticeboard/Incidents#Pigsonthewing et al.. Perhaps this RfC should be simply stopped and restarted then under the supervision of some neutral admins, to avoid further disruption. As it stands, the chances of getting anyone interested in participating in these shambles are slim, which was probably the intention.

The above examples are also, to use the terminology used against the previous RfC, cherrypicked. The testpages also contain some equally fictituous examples:

vs.

And

vs.

Fram (talk) 16:35, 7 May 2021 (UTC)

Note that the large example you mention isn't fictitious, it's the actual authority control template used on Douglas Adams. * Pppery * it has begun... 16:43, 7 May 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Process request: A requested edit template and queue for partially-blocked editors

I partially blocked an editor from article-space today for a three-year history of unreferenced changes and inappropriate categorizations of BLPs. In my advice to the user I started to suggest that they request edits on talk pages, and then realized that we don't have an edit request process specifically for this. We have {{request edit}} for COI editors, and the {{edit protected}} series for pages that are protected, but none (that I know of) for parblocked editors. I ended up suggesting they use {{edit fully-protected}}, but that's a half-solution, and requests with those templates on articles that are not protected are routinely rejected for only that reason.

I propose creating an {{edit partially blocked}} request template (with instructions to reviewers to check the requester's block log, similar to how we advise reviewers to check the protection log for pending changes) which would populate Category:Wikipedia partially blocked edit requests, and adding a sublisting of pages in that category to Wikipedia:Dashboard in the requested edits section. I could do this boldly myself, but creating a new queue could have wide-reaching implications, so I'd like to gauge consensus first. Ivanvector (Talk/Edits) 11:27, 29 May 2021 (UTC)

@Ivanvector: I am amazed that you do not know of Template:Edit partially-blocked. 🐔 Chicdat  Bawk to me! 12:34, 29 May 2021 (UTC)
Putting Chicdat's somewhat unnecessary tone aside, that template seems to be a good solution. It doesn't categorise into a specific category, and I agree with Ivanvector that it should to allow for easy reviewing. I've also created {{edit partially blocked}} as a redirect to match the other edit request templates. firefly ( t · c ) 14:28, 29 May 2021 (UTC)
It's not clear to me that edit requests from editors blocked from editing a given page should be given a separate queue from all edit requests (and thus potentially higher prioritization), given that their contributions have been deemed disruptive for that page. isaacl (talk) 15:06, 29 May 2021 (UTC)
Personally I think it's less about giving them higher priority and more ensuring that they get the higher scrutiny they no doubt require - with a separate queue they are easily identifiable as request that require handling more carefully. firefly ( t · c ) 15:15, 29 May 2021 (UTC)
Also there may be editors who are willing to handle COI edit requsts but not partially blocked edit requests or vice versa making it easier for them to find the ones they want to process. --Trialpears (talk) 15:21, 29 May 2021 (UTC)
True enough that edit requests from editors blocked from a page are likely to be more contentious, and it might be nice to flag this without putting the request into a separate stream where it may jump ahead of other requests. It's not clear to me though if there are a lot of admins unwilling to deal with the usual queue of requests (generally conflict-of-interest situations) that are only looking for contentious requests to process. isaacl (talk) 15:44, 29 May 2021 (UTC)
Putting these requests in a separate stream could just as well result in them jumping behind other requests. It is just an acknowledgement that they are different from other types of request. Phil Bridger (talk) 17:45, 29 May 2021 (UTC)
I'm dubious as to how different they really are in essence. Edit requests using the template are from editors whose edits require additional review for the page in question. Whether that's due to a conflict of interest or a prior dispute, the responding editor is going to have to examine the past history of the requestor and the page to establish context and the best steps forward. isaacl (talk) 23:28, 29 May 2021 (UTC)
Regarding hinting at level of scrutiny, I think once the request is read, even ignoring the different template that is assumed to be used correctly, the request text will make it evident. isaacl (talk) 15:44, 29 May 2021 (UTC)
Who is going to volunteer to fulfill edit requests from partially blocked editors??? I cannot comprehend the notion that there is a person who is disruptive enough that they they need to be blocked from mainspace but we still want them to make edit requests. I mean, just indef them. This isn't a day care, right? Levivich 17:00, 29 May 2021 (UTC)
If they are only partially blocked then the partially-blocking admin has seen a spark of potential redemption. Surely making edit requests is a way towards this? Phil Bridger (talk) 17:45, 29 May 2021 (UTC)
I've used p-blocks this way and I've answered edit requests from them on my user talk. Some people do useful, gnome-ish work, but for whatever reason won't follow particular policies like WP:NOTBROKEN. Requiring review of their edits before going live is a good compromise between losing a useful volunteer and letting reports about them clog up ANI. Technical restrictions like blocks and protection should be sparing and only as much as we need to prevent disruption (i.e., create a net-positive outcome). Blocks are one way to handle WP:CIR issues, but competence is a spectrum and completely prohibiting editing is not always the best solution to the problem. I think adding a (sub-)category for these kinds of requests would be useful for sorting them out per Trialpears. — Wug·a·po·des​ 23:04, 29 May 2021 (UTC)
Indeed I did not know about {{edit partially-blocked}} (or I wouldn't have posted this in the first place, of course) and I appreciate that Chicdat pointed it out. Still, I do think that this sort of edit request ought to be categorized separately from COI and protected requests, since they require a different sort of scrutiny. Not necessarily more, just different. And if they're not being categorized at all, then who is answering them? Ivanvector (Talk/Edits) 23:27, 29 May 2021 (UTC)
The template is a wrapper for the {{Request edit}} template and thus is categorized as an edit request. It's not clear to me that the scrutiny is substantially different: the responding editor needs to familiarize themselves with the background context and determine the best next steps to determine if the edit can gain consensus support, or act as a starting point for an edit that the interested parties can agree upon. isaacl (talk) 23:36, 29 May 2021 (UTC)
I agree, I don't think it's different scrutiny so much as just editor interest. Dealing with COI edits doesn't interest me (partly because I don't know that area of policy well enough to handle requests), and I think protected edit requests are better answered by talk page watchers when possible since they can review the content better than I likely would. So I don't answer edit requests much, but I'd be interested in answering p-block requests if there was a category. Whether that's useful for the project as a whole, maybe, but I like it. — Wug·a·po·des​ 00:06, 30 May 2021 (UTC)
I don't know if I fully agree regarding categorization or requiring the same scrutiny, but insofar as the request to create a template for pblocked editors to request edits, this can be considered resolved. Thanks to all. Ivanvector (Talk/Edits) 18:19, 2 June 2021 (UTC)

Display UTC with current UTC time

I propose that instead of displaying the Time Zone as "UTC" plus an offset, it should be displayed as the current UTC (at time of page load) in addition to a refresh link. 

- Current: UTC+05:00
- Proposed: 04:33, 5 June 2021 (UTC) + 05:00 [refresh]

This format will allow the viewer to easily compute the local current time while avoiding the complexities of trying to dynamically display the correct current time at that place. Nbardach (talk) 04:44, 5 June 2021 (UTC)

Please take the hint: it's not going to happen. Someone looking at the page on 1 July 2021 is going to be totally confused when seeing a cached time such as 04:33, 5 June 2021. Wikipedia does not support dynamic displays and displaying confusing text is not a good replacement. Johnuniq (talk) 04:54, 5 June 2021 (UTC)

@Johnuniq: It already happens on all of the Time Zone pages (ex: UTC-08:00), which each display the Current Time in that Time Zone plus the [refresh] link. Why should this be any different? — Preceding unsigned comment added by Nbardach (talk • contribs) 06:08, 5 June 2021 (UTC)

Hi, MediaWiki developer here. I think displaying the current time is a (technically) perfectly reasonable and trivially achievable proposal to implement on Wikipedia.
I do fully agree with the concerns laid out above in this section and the previous, in so far that it would be absurd to implement this with wikitext in a server-side fashion. However, such thinking is exactly why ideas and technical implementation need to be more separated from one another. Doing this server-side would require software changes to allow minute-level parser cache expiry (which I would not approve), or a fragile community-run purge bot (which I'd likely block). Apart form that, there'd still be the issue of punishing at least one visitor — every minute — with an unusually slow page load due to the server having to parse the page in its entirety. (I say at least one, since visitors will be queued behind one another; with a maximum queue length after which the copy from prior to the purge will be revived and served instead.) And after that, a high likelihood the result would still be off by a few minutes due to clock differences between the server and client, and the time it takes to transfer the data over the Internet. After that, the text would remain static while in the reader's browser and not update. Thus by the time someone actually looked at it, I'd give it a 50% chance of being off by at least two minutes compared to their own clock, growing more stale with every passing second/minute while they scroll up and down the page. So apart from any infrastructure concerns, I think this would offer a slow, confusing, and unprofessional experience to readers; even if it the servers did somehow instantly update it every minute (which they won't).
The appropiate way to implement something like this would be with a few lines of client-side JavaScript (via MediaWiki:Common.js, or a default-enabled gadget). Such script would be very trivial to write, and would not require any modern or complex APIs (I see Intl.DateTimeFormat was mentioned above, but this isn't needed). Assuming we aim for displaying hours and minutes (not seconds) this would not incur any notable performance cost on the browser.
The way I would approach this:

  • The infobox reserves a spot for the clock to be. If your preferred styling results in the spot being noticable if empty, then one could hide this reserved spot in CSS via .client-nojs. Thus hiding it in contexts where there is no JavaScript provided/enabled/supported.
  • The infobox annotates the spot with an HTML data attribute, indicating the offset in a way that is extra easy for JavaScript to pick up. E.g. <p data-tzoffset="-90">Offset: -01:30 <span class="tpl-place-currenttime"><!-- placeholder --></span></p>.
  • The JavaScript would be a small handful of statements to find this element, find the offset, substract it from the current minutes, and then simply render the hour and minutes. The ancient and widely-supported Date#setMinutes browser function even automatically takes care of rolling over the hours and such.

--Krinkle (talk) 23:48, 5 June 2021 (UTC)

  • If someone wants a UTC clock on their screen, they can enable it via gadgets already, it will be available on all screen at all times and can be useful for things like looking at discussion timestamps as well. — xaosflux Talk 03:19, 6 June 2021 (UTC)
  • This doesn't fix the summertime problem discussed above either, as the goal of this is to still compute the local current time and the local summertime state and offset would also be needed to accomplish that. — xaosflux Talk 03:21, 6 June 2021 (UTC)
  • Grateful to everyone, especially the dev Krinkle, for diving deeper on the display of the current time. Not sure how to address Xaosflux's concerns about local summertime states and locality's irregular time zone implementations, but hoping Krinkle and others will have some good ideas. Nbardach (talk) 06:15, 6 June 2021 (UTC)
  • @Krinkle: Your suggestion would work for static UTC offsets, but the original discussion was about times in locations. Many locations need daylight saving time to be taken into account for correct time display. Anomie⚔ 11:55, 6 June 2021 (UTC)
    • @Anomie: I understand, but things like that also affect the offset that the infobox would display today without a live time. I assumed that this is already handled in some way. That information, I would expect, is preprocessed by the template output to inform the JS code the same way it would inform a human today. I don't know what the preferred way to encode this information is nowadays, but wherever/however we do it elsewhere, I suppose we could do it the same here. E.g. add the UTC timestamp of the next switch and encode it into another attribute. Again, this motivated by wanting to improve the way the information is presented even without a live clock. I think I understand better now why you opted for Intl.DateTimeFormat, and perhaps that could still work with the fallback being to hide the destination box. The downside of that approach, however, is that it suggests to me that we haven't actually figured out a way to explain/present this information to readers in general, which to me is the more impactful problem to solve, if we haven't already. --Krinkle (talk) 15:53, 6 June 2021 (UTC)
      • You assume incorrectly. There's no attempt in articles to say what the current timezone offset is, infoboxes just state what the normal and summer offsets are. Which is fine, people who don't already know how DST works can follow the included wikilinks to learn about it. But saying "The current time is 13:20 or 14:20 depending on whether it's DST or not" wouldn't work very well. Encoding a switch in wikitext somehow (probably via a template or module, like we do with Template:Calendar date for some holidays) could work, but would still need mass purging semiannually. Anomie⚔ 17:25, 6 June 2021 (UTC)
    • Could a dev please explain why client-side JS like this wouldn't work? 
          function calcTime(city, offset) {
        // create Date object for current location
        var d = new Date();
        // convert to msec
        // subtract local time zone offset
        // get UTC time in msec
        var utc = d.getTime() + (d.getTimezoneOffset() * 60000);
        // create new Date object for different city
        // using supplied offset
        var nd = new Date(utc + (3600000*offset));
        // return time as a string
        return "The local time for city"+ city +" is "+ nd.toLocaleString();
    }
    alert(calcTime('Mumbai', '+5.5'));
    }
      Nbardach (talk) 18:02, 6 June 2021 (UTC)
      • @Nbardach: That's the general idea of Krinkle's suggestion. But figuring out what to pass for offset for a place like New York is problematic. There it would be -4 from mid-March to the beginning of November and -5 for the rest of the year. Anomie⚔ 00:22, 7 June 2021 (UTC)
        As you've hinted at above, new Intl.DateTimeFormat('en', { timeZone: 'America/New_York', hour: 'numeric', minute: 'numeric' }).format(new Date()) gives the current time in New York, taking into account DST. Doesn't work in older browsers, those could fallback to non-JS behaviour. – SD0001 (talk) 04:23, 7 June 2021 (UTC)
      • Perhaps you can discuss your ideas at mw:MediaWiki_talk:Gadget-UTCLiveClock.js, as it might be a good place to implement it. isaacl (talk) 04:49, 7 June 2021 (UTC)

Two-year range date-of-birth categories

Before I embark on a quixotic quest to create a bunch of categories that could potentially prove controversial, I thought I'd throw it out here for community approval.

Here's the situation. We generally categorize biographical subjects by year of birth (e.g., Category:1965 births). We have thousands of subjects for which we know their age as of a certain date, but don't know which of two potential years was their actual year of birth. For example, Sheri Benson (born 1962/1963), Helena Brunner (born 1957/1958), Matt Galloway (born 1970/1971). Currently all of these subjects are categorized by decade of birth (e.g., Category:1960s births), but I think we could be more precise by creating categories like Category:1962–1963 births. This would also separate out the subjects for whom we have that sort of two-year window from subjects for whom we have much vaguer knowledge that they were born in a certain decade, but could have been born any time in that decade. BD2412 T 04:51, 29 May 2021 (UTC)

That seems unnecessary to me. It would just create a bunch of very short categories, and very short (non-maintenance) categories are usually discouraged. Chicdat (talk) 11:11, 29 May 2021 (UTC)
Why not just categorize them in both years? It's not not accurate, it's just the best we can do based on the best information we have. Categorizing by decade seems like it doesn't cover someone born in say 1959-60, or 1899-1900, and I agree that creating a series of very short categories for all of these unusual occurrences seems like over-categorization. Ivanvector (Talk/Edits) 11:31, 29 May 2021 (UTC)
Putting them in both would be my instinct too, and I'm pretty sure I've seen it before for historical figures though I can't think of examples off the top of my head. —Nizolan (talk · c.) 22:33, 29 May 2021 (UTC)
After some searching I can say that Andrew Marcus is the only article about a single person in two 1980s birth categories, so it basically doesn't happen currently. --Trialpears (talk) 22:37, 29 May 2021 (UTC)
Right, by "historical" I meant pre-20th century but granted I can't find examples right now either. —Nizolan (talk · c.) 22:46, 29 May 2021 (UTC)
Same result for the 1850s but here Max Hirsch (economist) is the only article. --Trialpears (talk) 22:49, 29 May 2021 (UTC)
I'm not really thinking of very old article subjects, as I think the convention of saying 'so-and-so, age' is fairly recent. However, I would consider it problematic to list, e.g., Sheri Benson above in both 1962 births and 1963 births because one of those is factually incorrect, and we know it. I hope to some degree that having range categories like those proposed would lead some editors to dig in and find more accurate date-of-birth information for the subjects in those categories. BD2412 T 00:34, 30 May 2021 (UTC)
@Trialpears: I just realised that I was remembering Wikisource, where the double category is the (automatic) convention, and not Wikipedia, e.g. s:Author:Thomas à Kempis. Confusion on my part, sorry. —Nizolan (talk · c.) 14:23, 30 May 2021 (UTC)
Another option would be to create a set of, e.g., Category:Circa 1965 births, which would include people probably born in (or around) 1965, but would not project inaccurate claims that we know the person to have been born in that specific year. BD2412 T 04:40, 30 May 2021 (UTC)
  • Remember that the purpose of categorization ISN’T to pigeon hole the subject ... it is to aid navigation between articles.
I have no problem listing someone in two “birth year” categories if we are not sure which applies. For the purpose of navigation to and from the article, it is better to be overly inclusive. Presumably the relevant bio article would make the uncertainty about the subject’s birth date clear in the first few sentences. Blueboar (talk) 15:24, 30 May 2021 (UTC)
I have seen such category additions reverted in the past, where there was no source for the specific year. BD2412 T 16:55, 30 May 2021 (UTC)
  • Why is Category:Year of birth uncertain inappropriate in these cases? --Jayron32 15:25, 1 June 2021 (UTC)
  • Oppose using categories that are known to be wrong. If someone was born in 1964 or 1965, you know that one of the categories doesn't apply. —Kusma (talk) 17:55, 3 June 2021 (UTC)
  • If categorizing in both categories is off the table (and I agree with the rationale) then probably they should be categorized in neither. What about a maintenance category for something like Category:Date of birth extrapolated from verified age as of date, and leave it up to editors to categorize in an appropriate existing date range category? Ivanvector (Talk/Edits) 12:13, 6 June 2021 (UTC)
  • The Category:1960s births trick of course only works when the two possible years in question fall into the same decade. I think the best thing would be to just put them in both year categories, and also in Category:Year of birth uncertain. It's not a perfect solution, but a perfect solution doesn't exist and this is good enough. I'm looking at this from the point of view of somebody wanting to write code to do automated processing. Let's say I wanted to find all the people born within 5 years of when Person X was born. With my scheme, we'd find them, and then could do some additional filtering if we wanted. If you take them out of the year category and put them in a dual-year category, you'd have to search all the possible dual-year categories, most of which wouldn't even exist. Likewise with queries like, "who was born exactly 100 years before Person X?". Also, the snot-nosed obnoxious pedant in me immediately thought of the case of an article about a pair of twins, one of whom was born just before midnight on December 31st, and the other just a few minutes later, in January 1st of the next year. Surely that would belong in both categories? -- RoySmith (talk) 14:43, 6 June 2021 (UTC)
Or two centuries. Or millennium. Then there are time zone issues, relative to place of birth. IMO this discussion is an artifact of computer architecture which wants 1 or 0, and has trouble with gradients and nuance. Maybe pick one (best) version of the truth for the black and white stuff like categories, and explain nuance in the body of the article. Creating duplication in categories is breakage IMO. -- GreenC 03:20, 9 June 2021 (UTC)
The original proposal is to avoid duplication in categories by creating a new set of categories like Category:1962–1963 births where the subject is known to have been born sometime during that span. It would work just as well for a Category:1959–1960 births or a Category:1999–2000 births. Articles in those categories would not be in any other date of birth categories. If the subject's actual birthdate was determined, they would be recategorized to the specific year. BD2412 T 04:38, 9 June 2021 (UTC)
Each sibling would only belong in one year. I couldn't see why you would have a combined article unless they were conjoined. And having conjoined twins born in different years would be next to impossible.--Khajidha (talk) 17:11, 7 June 2021 (UTC)
Khajidha, regarding I couldn't see why you would have a combined article unless they were conjoined, see Dionne quintuplets, which is in all of Category:1954 deaths, Category:1970 deaths, Category:2001 deaths, and Category:Living people. -- RoySmith (talk) 02:45, 9 June 2021 (UTC)
I'd think the thing to do in such instances would be to create redirects from the individual names and put the year-of-death categories on the redirects. BD2412 T 03:09, 9 June 2021 (UTC)
Sorry, but if we don't know the exact year of birth, we should not be trying to put them in categories based on exact years. I don't care how much "easier" it makes some things. This strikes me as lying to our readers. It makes no sense to be "easy and wrong". If the two years are in the same decade, I could see a category like Category:1960s births with uncertain years. --Khajidha (talk) 14:00, 7 June 2021 (UTC)

Growth team feature test begins tomorrow (June 8)

Hello everyone -- I'm Marshall Miller; I'm the product manager for the WMF Growth team. I'm following up on @Nosebagbear's post from April 23 about testing the Growth team's features here on English Wikipedia. In short, the Growth team features provide new account holders with important tools to get started: they're suggested articles that need simple edits (based on maintenance templates) and they are assigned a mentor to whom they can ask questions.

In the past weeks, lots of English community members have tried out the features, and we've heard largely positive reactions and ideas. We also have 16 mentors signed up (we don't need more for this test, but we will need more in the future!) After discussing it with the most involved community members, we set a date to begin testing the features on this wiki. Our plan is to start giving the Growth features to 2% of newcomers starting tomorrow, June 8. This means that for all new accounts created starting tomorrow, 2% of them will have the Growth features and the rest will not. Because English Wikipedia gets about 130,000 new accounts per month, we expect this will amount to 2,600 newcomers having the features over the course of the month. They'll mostly be visible in Recent Changes and watchlists by completing suggested edits and asking questions to their mentors. These edits can be found with the tags #Newcomer task, #Mentorship module question, and #Mentorship panel question.

While the test is running, the Growth team will monitor newcomer activity to identify if anything negative is occurring (like an increase in vandalism) -- if something goes wrong, we'll be able to quickly make changes. At the end of about four weeks, we'll reflect on the data and ask mentors about their experiences to decide how to proceed, in terms of whether to increase the number of newcomers who receive the features.

I hope this sounds good to everyone here -- we think we've planned this carefully with community input, but I definitely want to hear if anyone has questions or concerns. I'll plan to post again tomorrow to confirm that the test has started. MMiller (WMF) (talk) 18:42, 7 June 2021 (UTC)

Also would like to mention, please don't be a mentor, there already are more than 15 of them. Oh shoot, Streisand effect. Sungodtemple (talk) 22:10, 8 June 2021 (UTC)
Hi all -- we began the test today, giving the Growth features to 2% of new accounts being created. Please follow along with the progress on the project's talk page! MMiller (WMF) (talk) 04:51, 9 June 2021 (UTC)

Wikipedia should Celebrate Autistic Pride Day

There is consensus against this proposal. Closing per WP:Snowball clause. —pythoncoder (talk | contribs) 13:44, 9 June 2021 (UTC)

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


Upcoming 18th June is Autistic Pride Day. Can wikipedia celebrate that day, such as by showing an infinity badge on the front page? Where is the right forum to discuss this proposal? Regards. RIT RAJARSHI (talk) 03:59, 7 June 2021 (UTC)

@RIT RAJARSHI: Generally there hasn't been much support for celebrating individual events, and I don't think the community would support adding an infinity badge to the main page. I think the best thing you could do would be to have a read of the guidelines for selected anniversaries, and if the event/article meets the criteria to add it to the page for June 18. 192.76.8.73 (talk) 11:25, 7 June 2021 (UTC)
This is an issue dear to my heart, as I am a trustee of a small charity whose mission is to stage plays that raise awareness of autism (and I am deeply honoured to have been invited to become the only trustee without autism), but I would oppose this. I think a slippery-slope argument is valid here. Why shouldn't we do something for Mental Health Awareness Month, or AIDS Awareness Week or International Tea Day, which I am sure are dear to some editors' hearts? The only such day that we should take note of, if it exists, is one to raise awareness of open encyclopedias that anyone can edit. Phil Bridger (talk) 12:50, 7 June 2021 (UTC)
We don't celebrate individual days in a formal way, but relevant submissions of articles following our gazillion other rules can be highlighted on the Main Page on a given day. Did you know allows for special date requests for a given new article, and so does Today's Featured Article. If you have an article that meets the rules and is appropriate for Autistic Pride Day, you'll be welcomed with (fairly) open arms. (18 June this year might be too close, though). —Kusma (talk) 13:09, 7 June 2021 (UTC)
@Phil Bridger: One thing to be make clear; Autism awareness and autism pride isn't same thing. Autism pride stresses on the thing that autistic individuals have right to be ourselves and we do not have to force mask ourselves into a broken version of neurotypicals. We have the infinite potential but for that we need the niche which is accessible for us. We also speak that world needs more of us. We speak against eugenic elimination of genetic diversity. We encourage cognitive diversity. We believe that strength lies in diversity and not in sameness. We say "Nothing about us without us. We share day to day our experience about hidden disability and how the disability doesn't belong to the affected person but it belongs to an inaccessible world. As a person in the spectrum, I feel these messages are missed or omitted in the autism awareness programs; and both are very different.
Now why to spread autism pride? Because awareness is misleading. Awareness often leads to fear about autism. What helps us, is understanding, acceptance and confidence. Yet awareness is a majoritarian (neurotypical) view, funded by neurotypical agencies, governed by mostly neurotypical-led charities. Awareness programs are something about us without us. In contrast, what actually helps us to flourish and expand our potentials, is not promoted by neurotypical authority. It is promoted by our little efforts.
Now I agree its primarily an encyclopedia, but since it perform various anniversaries, an 1 day anniversary would not be a big deal. Regards. RIT RAJARSHI (talk) 13:22, 7 June 2021 (UTC)
This article was presented several times on this day series
So it should be made a regular anniversary. RIT RAJARSHI (talk) 13:30, 7 June 2021 (UTC)
I agree that awareness and pride are different things, but disagree that there is anything bad about awareness, or that it in any way excludes pride. Quite the reverse. Much fear stems from a lack of awareness, and, as I said, I am the only trustee of the charity that I am involved in who doesn't have autism, so it can't be accused of being run by neurotypicals or being a "without us" organisation. Indeed that is a criticism that would be better levelled at Wikipedia if this proposal was agreed. Let's think about what's best rather than indulge in infighting about words, over which we would find it just as difficult to get agreement among diverse people with autism as among diverse neurotypicals. Phil Bridger (talk) 16:26, 7 June 2021 (UTC).
@Phil Bridger: Thank you for all your inputs. "Lets think what's best"... yes definitely, everyone deserves the niche where they can function at best. Instead of moulding oneself. We appreciate the whole diversity (not only autism and ASD), that includes neurotypicals, and we are thankful to the little number of neurotypicals who tries to understand instead of moulding us. RIT RAJARSHI (talk) 02:06, 8 June 2021 (UTC)
  • OPPOSED - It is not our job to promote pride days… no matter how worthy the cause. Posting a DYK or featuring a related article is fine, but placing banners and emblems on our main page is not. Blueboar (talk) 14:13, 7 June 2021 (UTC)
  • Oppose adding any sort of special logos to the MP for any of these condition-recognition-days; however assuming the article is in good shape feel free to drop an edit request at Wikipedia talk:Selected anniversaries/June 18 to have it listed at OTD again. — xaosflux Talk 14:36, 7 June 2021 (UTC)
  • Oppose per others above. I'm glad Autistic Pride Day exists, and it's a great way to help combat stigma/discrimination, but that is simply not our role and this would open up a can of worms. {{u|Sdkb}} talk 14:54, 7 June 2021 (UTC)
  • Oppose. Major NPOV issue, along with other concerns mentioned above. Sungodtemple (talk) 15:27, 7 June 2021 (UTC)
  • Oppose. We already have a process and set of guidelines for determining what gets to go on the main page; we shouldn't be overriding that process to add events with substandard articles simply because they're for a worthy cause - that will open a massive can of worms. If you want to see the event on the main page it should have to go through the same process as everyone else, which in this case will involve fixing up the clean-up tagged under referenced section which caused it's removal in the first place. 192.76.8.73 (talk) 16:01, 7 June 2021 (UTC)
  • Oppose per all Opposes above. Tyrone Madera (talk) 19:23, 7 June 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Archive RfPP reports (again)

It's snowing in June, and withdrawn by proposer. ProcrastinatingReader (talk) 13:11, 12 June 2021 (UTC)

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


Back in April, I proposed that RfPP reports be archived. However, no action was taken on this, and the discussion itself was archived. I was just wondering if this will happen, and if so, when. 🏳️‍🌈 Chicdat  Bawk to me! 11:41, 7 June 2021 (UTC)

Chicdat I'm still not clear on why it is needed. I'm frequently reviewing RFPP and I never felt the need to look into an archive. I also use WP:Twinkle which tells me if the page has been protected before and links to the protections page. The bot will tag some some requests with "Automated comment: A request for protection/unprotection for one or more pages in this request was recently made, and was denied at some point within the last 8 days". Even then I don't go back into the archive to see. I go the page and see if it is necessary now. CambridgeBayWeather, Uqaqtuq (talk), Huliva 00:51, 11 June 2021 (UTC)
CambridgeBayWeather Just because you wouldn't find it useful doesn't mean others wouldn't. 🏳️‍🌈 Chicdat  Bawk to me! 10:11, 11 June 2021 (UTC)

I'm pinging the editors involved in the last discussion. @ProcrastinatingReader, PEIsquirrel, Jayron32, Pppery, Xaosflux, Cyberpower678, GenQuest, Malcolmxl5, CaptainEek, Beeblebrox, Nosebagbear, Fastily, and ToBeFree: 🏳️‍🌈 Chicdat  Bawk to me! 10:11, 11 June 2021 (UTC)

  • That a proposal is archived with no action is usually a good indicator that there is little interest in it. I am not enthused by it. It’s not clear to me how it would be used or what the benefits would be. --Malcolmxl5 (talk) 10:28, 11 June 2021 (UTC)
  • Please explain clearly why this should be done? and, what are the benefits of this action? I thought this was done and put to bed. Right now, this sounds like you want to take clutter from a pile over 'there,' and start a new pile for it over 'here.' But, what is your reasoning, and how is that a benefit in any way to WP? GenQuest "scribble" 12:31, 11 June 2021 (UTC)
  • I'm also struggling to see why we should bother with this? it seems like a change that will simply create hundreds of useless archive pages that no-one is ever going to look at. These aren't like deletion discussions or arbitration enforcement reports where someone might need to pull them up again in 10 years time for a related deletion discussion/arb case/RFC, basically every one of these reports is a standard template and one line sentence, with a template response from an administrator. If a request at RFPP is acted upon then there will be an entry in the protection log for the page which already serves as a reasonable record of what kind of disruption has occurred historically, and if a request for page protection is declined then I fail to see any reason we would need to access it again. The fact that a page wasn't protected 6 months ago should have no relevance at all on a new report - a decision on whether a page should be protected or not should be based on what disruption is occurring now. 192.76.8.73 (talk) 13:30, 11 June 2021 (UTC)
  • My opinion has not changed; I would find such a process completely useless, but will not get in the way of anyone doing the work necessary to make it happen. It serves no purpose to myself, as an admin, in doing my work at RFPP, and provides no benefit in that area. I'm also neither smart enough nor imaginative enough to see how any admin could find any use in such a system, but I'm a pretty low bar in that regard, which is why I won't stop anyone... --Jayron32 13:42, 11 June 2021 (UTC)
  • There was actually a consensus in the previous section; 7 leaning oppose/not useful, 2 support, and 1 indifferent. Combined with unique responses above, that's 9 oppose, 2 support, 1 neutral. ProcrastinatingReader (talk) 13:45, 11 June 2021 (UTC)
  • Archiving the pages makes them available to Search and Whatlinkshere. This has advantages and disadvantages: sometimes forgetting things is better. I haven't seen a convincing use case yet. —Kusma (talk) 13:47, 11 June 2021 (UTC)
  • Meh, but I don't think these are really needed. They don't really set precedent like an xFD does. If it is granted, the protection log can link to whatever the protecting admin wants to link to; if it is declined that won't preclude a non-extremely-short-time-in-the-future request from being able to be reviewed on its own merits. — xaosflux Talk 15:22, 11 June 2021 (UTC)
  • Why not automate adding a summary that includes the permanent link to the RfPP revision ID if the fulfilling admin is taking action from there. This is how the fulfilled WP:RM/TR requests are now tracked without creating archive bloat. -2pou (talk) 15:49, 11 June 2021 (UTC)
  • Again, not sure what problem this would solve. There is already a quite useful protection log for pages. CaptainEek Edits Ho Cap'n!⚓ 18:58, 11 June 2021 (UTC)
  • I agree with everyone above. No convincing reason (or, frankly, any reason at all) has been articulated for why this is necessary. Mz7 (talk) 19:03, 11 June 2021 (UTC)
  • Can someone please withdraw this discussion for me? It's obviously not going to get anywhere, but I am banned from closing discussions, so I can't do this myself. Chicdat (talk) 12:38, 12 June 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Mis-placed RfC to elevate WP:DUCK to guideline status

FYI
 – Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:The duck test#RfC on making this a guideline. This is a regular RfC that would elevate that {{Essay}} to {{Guideline}} status. It really belongs as a WP:PROPOSAL on this page. I suggest that it be shut down there and moved here, actually. If it's worth bothering. We didn't even make WP:BRD a guideline, after many proposals to do so.  — SMcCandlish ☏ ¢ 😼  18:28, 12 June 2021 (UTC)

Make mobile version article segments closeable from the bottom

Moved to Wikipedia:Village pump (idea lab) § Make mobile version article segments closeable from the bottom
20:50, 14 June 2021 (UTC)

The current method of allowing only one link between articles of different languages assumes that a concept that is sufficient to make an article in one language will always be one article in another language, and never multiple articles. However, there are many instances when this is not the case. For example, there is the English Changchun which discusses its history as Hsingking in the same article. However, in the Japanese Wikipedia, Hsingking has one article, while Changchun also has one article. Both Japanese articles are long enough that it seems impracticle to merge them, and it doesn't seem right to make the Japanese Wikipedia change their articles based on the English Wikipedia.

My suggested solution would be to allow articles like the Japanese Hsingking article to link to the section of the English Changchun article that discusses Hsingking. The English article could still link to the Japanese Changchun article, as there is a disambiguation at the top of the Japanese Changchun article that would allow people to make their way to the Japanese Hsingking article. Erynamrod (talk) 16:16, 10 June 2021 (UTC)

@Erynamrod: You're talking about the interlanguage links that appear in the sidebar aren't you (just to be sure that I'm writing about the same thing)? These are currently populated using wikidata, which only supports 1:1 linking of articles and does not support linking to sections, but there is a workaround - you can still use the old style manually entered links. You can only have one link for each language in the sidebar of each article, but you can have multiple pages on other wikis linking to the same article, e.g. to add a link to the Hsingking article on the Japanese article just add something like [[en:Changchun#Manchukuo and World War II]] anywhere on the page. The English article can only have one link in it, so as you note the only way of dealing with it is to have disambiguation on the Japanese side. 192.76.8.73 (talk) 18:03, 10 June 2021 (UTC)
Hsinking is a redirect to Changchun. If you like, you can link the redirect page to the Japanese Hsingking on Wikidata and add a {{Wikidata redirect}}. – Finnusertop (talk ⋅ contribs) 18:44, 10 June 2021 (UTC)
@Erynamrod, if you want the long explanation, see d:Help:Handling sitelinks overlapping multiple items. Whatamidoing (WMF) (talk) 20:43, 15 June 2021 (UTC)
Thanks all. Apologies for not being aware of this issue/discussion already. If I might ask one final question, is there a preference to which solution I use? The link to the redirect or the old style manually entered links? Erynamrod (talk) 09:06, 16 June 2021 (UTC)

Automatic lists of images in rejected or deleted drafts

When a draft is deleted images uploaded to Commons are not always checked and might be left to languish (correct me if am wrong). Checking uploads by new users is currently made more difficult as OgreBot is no longer running.

To help with this, would it be possible to have a bot automatically create a list of images in rejected (or deleted, if possible) drafts? The list could be limited to images uploaded by the creator of the draft, and possible only by new users. Even if the images are acceptable (not copyvios etc.) new users often don't know about Commons categories so the images are left uncategorized.

This would of course require help from someone capable of creating such a bot. MKFI (talk) 17:38, 13 June 2021 (UTC)

The best place to find someone capable of coding bots is WP:BOTREQ. As I understand it, lists are regarded as uncontroversial so you shouldn't need explicit consensus to generate a list of images in rejected drafts. Images used in deleted drafts would require an adminbot I presume but I have no idea what sort of consensus level would be required for one that just generated a list of images used on deleted drafts but the folks at BOTREQ should know. I don't see any issue with it as proposed though. Thryduulf (talk) 20:33, 13 June 2021 (UTC)
Bot request created: Wikipedia:Bot requests#Automatic lists of images in rejected or deleted drafts. MKFI (talk) 19:55, 16 June 2021 (UTC)

The future of the Book namespace

Summary of consensus precedes each sub-sectioned proposal. ProcrastinatingReader (talk) 16:57, 18 June 2021 (UTC)

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

Should the book namespace be deprecated and if so what should deprecation include? --Trialpears (talk) 18:27, 15 May 2021 (UTC)

This RfC will involve several different but related proposals. First of all I will give some history on the book namespace since many editors are likely to be unaware of the namespace. I will also explain the current status and link to some previous discussions (not required reading by any means). Then I will outline a few possible actions each in their own section. When the RfC is closed the consensus for each proposal will be evaluated and hopefully there will be a consensus on how to deal with this zombie namespace. --Trialpears (talk) 18:27, 15 May 2021 (UTC)

User:Trialpears - do you want to fork this discussion over to a special Wikipedia page? Like Wikipedia:Requests for comment/The future of the Book namespace? It is getting a bit long. Aasim (talk) 08:40, 16 June 2021 (UTC)
Awesome Aasim It should get closed shortly (just requested at WP:CR) and I don't see any problem with archiving it early if it is. I don't see page length as a major issue. I don't have a strong opinion here though. --Trialpears (talk) 20:43, 17 June 2021 (UTC)


History (book namespace)

The book namespace was introduced in 2009 as a way to download or print a collection of articles. To do this you use Special:Book to select a collection of articles you want in the book. divide them into chapters and choose some rendering settings. You can also give it a cover image, change the color of the book, choose rendering settings, and divide the articles into chapters.

After this was done you could either purchase a printed copy from PediaPress or download it in a wide variety of formats including PDF using the Offline Content Generator.

Eventually the Offline Content Generator became outdated and unmaintainable. Bugs and security issues could no longer be fixed so the Wikimedia Foundation turned off the book rendering service on all Wikimedia wikis in October 2017. Since then, Wikipedia books have only been available either in physical form from PediaPress or through MediaWiki2LaTeX (de:b:Benutzer:Dirk Huenniger/wb2pdf/manual). The issue with this is that we now require readers to visit a third party site to access our content and either purchase it or wait for a significant amount of time to get access to the book to render if MediaWiki2LaTeX even works properly for you. A large proportion of our books are too long to render and a good chunk of the rest have things like navboxes breaking the renderer and even if it in theory should work I've had times were it randomly stop or I can't download the book for unexplained reasons. If you want to do it locally (which I've heard works significantly better) you will have to do it on Linux or set up a virtual machine. After investing a few hours trying to do this I gave up so I haven't tested that personally. If you want a PDF of an article I would instead suggest using the "Download as PDF" option in the side bar which can reliably give you a PDF version in seconds.

Currently the namespace has total pageviews on the order of a popular portal like Portal:South Africa. This is spread out over a bit over 6000 pages. During a normal month without significant editor activity most books don't get a single view and just 1.5% of books get a pageview a day. The most popular one Book:Fundamental Data Structures gets just 15. It's also worth noting that these figures are significantly inflated by my and others recent maintenance work which has resulted in thousands of these views.

There have been several previous initiatives to hide books from readers, the biggest three being 2019 removal of book creator from side bar and suppression of many links, 2021 removal of remaining links and 2021 deletion of some book related templates. The latter two were basically unanimous decisions.

Books are still considered a community facing namespace and are on help pages often referred to as "community books" and are supposedly being community maintained. They are indexed by search engines. You can create books in the book namespace using Special:Book, but they can also be created in userspace as Category:Wikipedia books (user books). The namespace is listed as unused at WP:Namespace.

PediaPress links to a few of our books at the Catalog, which may or may not be possible to retain if the books are deleted on Wikipedia. It would continue to be possible to use PediaPress as long as Special:Book isn't removed. Either by not saving the book on wiki and saving it at PediaPress or by saving it user space.

The question now is how should we handle books in the future. This could include alternatives from keeping the status quo since it's barely seen by anyone to complete deletion of the namespace including all books within it. --Trialpears (talk) 18:27, 15 May 2021 (UTC)

In 2019 PediaPress implemented a new PDF render, which is used for the "Download as PDF" link, but it is clear in phab:T186740 that book support will not happen.--Snævar (talk) 19:32, 15 May 2021 (UTC)

  • Comment. I'd like to add some further remarks to that. The original agreement was between the WikiMedia Foundation (WMF) and PediaPress. They wrote our original rendering engine, the Offline Content Generator (OCG). They also wrote one for themselves and at first you could download a free PDF softcopy in their format if you did not want to pay for a dead tree. They subsequently withdrew the softcopy option. Meanwhile OCG never worked right. PediaPress's attempts to fix it were constantly overtaken by changes to the templating and other games in both software and user spaces. Also, Wikibooks gained in functionality and content. So the early interest in our books faded. We have twice tried and failed to develop a replacement, MediaWiki2LaTeX is suffering from under-development and Collector, a replacement for OCG promised by PediaPress, has also gone silent since its alpha test site appeared. It has become impossible to know whether a viable in-house renderer would actually attract users; we have never had such a thing, volunteer effort is insufficient to deliver it and WMF have consistently refused to resource its development. I'd suggest that we have reached the crunch decision: is there any point in having both Wikipedia:books here and Wikibooks? Isn't one enough? Fiddling with our dying namespace is merely prolonging the agony. We need to either resurrect it or drive a stake through its heart. Although my preference lies with the former, I am under no illusions that the majority consensus would be for the latter. I used to believe that we owed PediaPress to keep it going, but on reflection they pulled the free downloads of their format from under our feet for expressly commercial reasons, and let us down again over Collector; we owe them nothing any more. I can always maintain book pages manually in my userspace and upload them to MediaWiki2LaTeX or whatever, I don't need anything else. — Cheers, Steelpillow (Talk) 14:04, 16 May 2021 (UTC)

Proposals (book namespace)

Formally deprecate the book namespace

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is a consensus to formally deprecate the book namespace, describing pages within it as historical or not maintained. (non-admin closure) (t · c) buidhe 09:22, 24 May 2021 (UTC)


This would include changing the language used at pages such as Wikipedia:Books, Help:Books and {{Saved book}}. Books in the book namespace would no longer be described as community maintained. --Trialpears (talk) 18:27, 15 May 2021 (UTC)

  • Support This at a minimum should be done. The namespace does not enjoy community maintenance and we should make that clear. Calling it deprecated will make it clear for anyone that books aren't really supported. --Trialpears (talk) 18:27, 15 May 2021 (UTC)
  • Oppose Books still exist, fix the software and books will come back to life. Headbomb {t · c · p · b} 18:42, 15 May 2021 (UTC)
  • Oppose What? Per Headbomb. Throwing out the baby with the bath water. Fix the software! Littleolive oil (talk) 18:47, 15 May 2021 (UTC)
  • Comment @Headbomb and Littleolive oil: The status of fixing the software is that nothing has happend since 2017 and the extension is only bugfix maintained. I can not imagine a developer being willing to spend many weeks or months of work to get this up and going again, especially when the download as PDF feature exist. The amount of pageviews (many of which would not want to download a book) is like I said comparable to one popular portal which I can't imagine any developer justifying spending that kind of time on with 100s of more important projects. If the software is fixed usage may return to pre removal levels. December 2016 the namespace got a bit over 6000 daily pageviews on average which is comparable to a page like Dog. If you want to hold on hope that it will one day be fixed that's reasonable but I thought I should at least explain why I can't see that happening. --Trialpears (talk) 19:04, 15 May 2021 (UTC)
    Your lack of imagination is not ground for the deletion of books. If the PDF renderer works, one could make use of it to batch render collections of articles/books, and that would be a perfectly good basis for book-rendering to build upon. Headbomb {t · c · p · b} 19:12, 15 May 2021 (UTC)
    Or... one could just print multiple PDFs with what we have now? No one uses books, and it seems no really ever did. TP is hardly speculating, if it's easy as you say, why hasn't anyone done it yet? Aza24 (talk) 19:20, 15 May 2021 (UTC)
    Chicken and egg issue. No one uses books because the software is broken. Fix the software, people will use books again. They were decently popular back when the renderer worked. As for "why hasn't anyone done it yet", ask the WMF. Headbomb {t · c · p · b} 12:56, 16 May 2021 (UTC)
    Some data about usage is at User:SD0001/Books. It shows that the vast majority of this namespace has single-digit monthly page views. Most books have very few editors. Max number of distinct editors who have edited a book is 36 for Book:The Beatles. About half of all books have 2 just distinct editors (the 2nd edit mostly being AWB/HotCat). This doesn't indicate that they were decently popular ever. – SD0001 (talk) 19:46, 16 May 2021 (UTC)
    Yes, that's rather normal after all links to books were removed from the mainspace in 2020. See the clear drop in [1], and [2], [3] for examples. Headbomb {t · c · p · b} 21:33, 16 May 2021 (UTC)
  • Support—I just made a book on Gilbert Reaney with one of the external softwares and see nothing of use. In fact, the only differences I see from the PDF & Printable version downloads are a formal table of contents, title page and (for some reason) every single WP link turned into a url to that Wikipedia page in a note. I mean, what nonsense! We shouldn't support something as unhelpful as this, especially when a)there are 3rd party alternatives b)We literally have PDF and printable versions already c)it has remained unfixed for 4 years d)No one even used them when they were functioning! Aza24 (talk) 19:16, 15 May 2021 (UTC)
  • Support - books are like portals: just not in enough demand by readers to be worth spending community resources on. And there are existing services to create PDFs. WikiBooks should be it's own wiki or inter wiki tool, and it can create books from any language wiki not just enwiki; but it's a distraction as an enwiki namespace or enwiki project. Levivich harass/hound 19:21, 15 May 2021 (UTC)
  • Support per nom, Aza24, and Levivich. Books was an experiment that we tried, which is fine. It failed, which is also fine. Let's acknowledge the failure and move on, not continue to waste effort trying to maintain it. {{u|Sdkb}} talk 20:18, 15 May 2021 (UTC)
  • Support as secondary option to deletion for the reasons given in the comment below. ƒirefly ( t · c ) 20:30, 15 May 2021 (UTC)
  • Support There is a real trend hereon WP to hang on to things that don't work anymore, are inactive, etc. It's a bad trend and the book namespace is a perfect example of it. Beeblebrox (talk) 20:50, 15 May 2021 (UTC)
  • Support. As a long time reader and on-off IP editor I've had a few attempts at using the book namespace over the years, but each time it has been a universally terrible user experience. It's common to find books that have significant NPOV, weight, and design issues, and let's not kid ourselves that the book namespace is community maintained - it's not. It's a dumping ground for people's personal book projects which are occasionally fixed up by a passing wikignome. To illustrate this let's have a look at the user experience for finding a book on a random topic that any encyclopedia should be able to cover well - "European history"
Extended content
  • So, to start Book:European history doesn't exist, not as a book, nor as a redirect to something relevant. Not a good start in terms of ease of searching when the mainspace equivalent (European history) has existed since 2002 and averages over 1000 page views a month. The internal search engine turns up 3 books with overlapping focus - in a community maintained namespace surely duplicate pages should be merged?
    • The first book that turned up was Book:EuropeHistory, which illustrates all the worst problems with books. Created by a single user in 2009 - 2011, the only edits since have been the occasional bit of wikignomery. Massive due weight problems: why does the roman empire get a total of 4 articles, while the European union gets 134? Why is there no mention of world war II? What is cruft like List of tallest buildings in the European Union, Galileo (satellite navigation) and European Union acronyms, jargon and working practices doing in a history book? This is massively out of date and has been abandoned since it's user created it - despite covering the European union in an inordinate amount of detail there's no mention of Brexit?
    • The second book that turned up is Book:History of Europe. This has better focus IMO, but it consists only of a chronological list of articles with no attempt to sort the content into chapters. Created by a single user in 2010, only edits since have been wikignomery and an aborted attempted merge, so the book is missing anything that happened in the last 10 years.
    • The final book that turned up is Book:Europe1. This is the best of the bunch in my opinion - it has a well defined chapter structure, a reasonable amount of articles and is relatively up to date (though that's just because it was created more recently, again it was created by a single author in 2017 and has seen only gnoming edits since). Even as the best of them I still don't see how it offers a better user experience than History of Europe, which sorts the same articles into the same basic time periods and is much more readable, and at this title it isn't something that readers are going to be able to easily find. The last two sections of this book are duplicated (and have been since creation 4 years ago) seemingly without anyone noticing.
  • Having now found a reasonable book I have a few options to read it - I can either click through each of the articles in the list using it as a poor substitute for a summary style article or list, I can muck about setting up a Linux virtual machine to export the pages to latex then compile that to a pdf, or I can pay a third party company to print me a paper copy of an electronic encyclopaedia that will be outdated in a couple of years. Who is this aimed at? People who can't access the website reliably but can download enormous pdf files on a regular basis? People who can't afford internet access but can spend $$$ on print on demand books? People who need an easy to use book creation wizard but know how to set up Linux and use latex? I just don't see what demographic this is targeting.
  • Overall the book namespace is just not a good or useful experience for readers, and there is no sign of any community actively curating these books. I would support depreciating the community book namespace and moving all books in it to the userspace of the original creator, as in my experience in 95% of cases they will be the only person to have actually added any content to the book. 192.76.8.91 (talk) 21:05, 15 May 2021 (UTC)
  • Support and all the ones below too. I find the "just fix it" argument weak. If somethings been broken for this long and no one wants to fix it, its probably not worth fixing. I am struggling to see the value of this namespace even if it did work properly. Aircorn (talk) 21:49, 15 May 2021 (UTC)
  • Support. Please! Gog the Mild (talk) 21:59, 15 May 2021 (UTC)
  • Oppose for lack of any benefit in doing so. Nemo 22:00, 15 May 2021 (UTC)
    The benefit is that more editorial time gets spent on articles, which is what matters in the long run. – SD0001 (talk) 10:12, 16 May 2021 (UTC)
  • Support - This has been broken for years. There doesn't seem to be much of a push to fix this, and per Aircorn, this isn't really looking like a thing a whole lot of people want. If a few users desire something like this, they can do it in their userspace, but as a whole, the book namespace seems to be dead. Hog Farm Talk 23:01, 15 May 2021 (UTC)
  • Support. It's a feature that never gained much traction and is obsolete now. -- RoySmith (talk) 00:20, 16 May 2021 (UTC)
  • Support. —¿philoserf? (talk) 02:09, 16 May 2021 (UTC)
  • Support. Nobody seems interested in maintaining any of this. If volunteers apply, perhaps it could be revived one day. For now, let it continue in userspace. — Alexis Jazz (talk or ping me)
  • Support per evidence presented as well as IP192's. --Izno (talk) 03:27, 16 May 2021 (UTC)
  • No Vote on the one hand, it's been broken for years and nobody has cared to fix it. Also, this feature should really be in user-space (for individual users' books) or project space (for collaborative efforts on topics). While it should be a good idea, I'm not sure we want to encourage people to do churnalism publishing of "Wikipedia content books" on self-publishing platforms. No vote myself, but unless somebody comes up with an idea to improve the usage of the namespace this will certainly pass. User:力 (power~enwiki, π, ν) 03:31, 16 May 2021 (UTC)
  • Support deprecating the namespace. As others have said the namespace is a failed experiment, I just don't understand the utility in maintaining these as a community. Some users are still interested in creating books, sure, they can do so in userspace – there is no need for community maintenance which is a waste of resources over something which the readers don't care about. – SD0001 (talk) 07:07, 16 May 2021 (UTC)
  • Support This is a broken namespace and massive waste of time. — Preceding unsigned comment added by Jackattack1597 (talk • contribs)
  • Oppose I oppose anything that uses the word "deprecate" — GhostInTheMachine talk to me 14:07, 16 May 2021 (UTC)
  • Support, but archive the content. —Kusma (t·c) 14:13, 16 May 2021 (UTC)
  • Oppose As this seems to be a technical matter controlled by PediaPress and the WMF/MediaWiki, governed by a legal contract between them, then this is none of our business. If editors or readers do not find the facility useful then they are not required to use it. Andrew🐉(talk) 17:27, 16 May 2021 (UTC)
  • Support. (1) Books are out of scope. The feature is peripheral to our purpose and should not be maintained as critical infrastructure, either technically or editorially. (2) re: "fix it", any intrepid volunteers or businesses can do so without the book namespace. (3) Books are already deprecated, per the above history. That we update our documentation should be uncontroversial. (4) Separate from this discussion, I would be curious to learn what positive impact (readership or wider audience) has come from Books during its existence. czar 18:18, 16 May 2021 (UTC)
  • Support: I'll lay my reasoning out once and refer to it in each subsequent comment. I support all progression towards ridding ourselves of the book feature. No-one has given a convincing use-case worthy of all the volunteer time that is still going into it (which is hardly a large proportion of what is done on the site, but still a substantial number of raw hours). 192.76.8.91 lays out brilliantly some examples of how there is no convincing use-case for at least much of the content. A tiny proportion of casual readers have heard of it. It's not good for people with good internet, or with bad internet. It doesn't relate to how people actually browse and read articles. And finally, we are not preventing anyone from implementing this functionality properly, and even for profit—so long as the CC-BY-SA attribution legally required is given. — Bilorv (talk) 22:10, 16 May 2021 (UTC)
  • Support This is a new topic for me and I've read your reasoning and all the comments above carefully. I am not persuaded by "it's a bug so fix it!" near the top. Clearly the facts speak for themselves, in my view. The book format is not working, but on top of that, the book format is not popular or well used. I think it's time to draw down the curtain, empty the orchestra pit, and switch off the foyer lights, for the show is over. doktorb wordsdeeds 22:18, 16 May 2021 (UTC)
  • Support this is the minimum that should be done. I thought about this for some time, and your reasoning seems solid. Personally, PDFs seem like a much better solution than books, and the only difference I see is a Table of Contents. Through looking at pageviews, books also seem rarely used. EpicPupper (talk) 04:14, 17 May 2021 (UTC)
  • Support per 192.76.8.91. First of all, the software doesn't work. That is to say, the software is broken, and doesn't work. That is to say, working is something that the software, in this situation, does not do. We have PDF rendering, which does basically every single thing "books" were supposed to do, except it actually works. So then we are left with "the book namespace", which is... just a bunch of random very badly put together lists of articles? The fact of the matter is that, not only does the namespace receive virtually no views and no edits, the content in it is almost all far below what we'd consider to be Wikipedia quality. The question then becomes why we're formally endorsing, in the voice of the community, some random namespace where random people throw random articles together with no peer review or consensus procedure, and giving it the veneer of respectability. Sad! jp×g 04:34, 17 May 2021 (UTC)
    It is wholly wrong to suggest that "We have PDF rendering, which does basically every single thing "books" were supposed to do." It falls very short of book functionality as implemented by the old OCG. It processes only a single article (not much worse than my web browser's standard web-page-to-PDF print option handles Wikipedia articles). A book renderer also needs to pull in every article from the contents list and adjust chapter titles as per the contents list. In order to comply with the legal requirements of our licensing, it then has to collate and append the users from the entire histories of all the articles into one massive Copyrights section. Then again for the images from the Commons. Finally, it must render to PDF, paginate, and add the page numbers to the Contents list. For some reason the false meme that "PDF creator does it all" is quite widespread and many refuse to acknowledge its utter falsehood (Indeed, failure to address it was the principal reason our own developer community has consistently failed, but that is another story). — Cheers, Steelpillow (Talk) 10:31, 17 May 2021 (UTC)
  • Support per Levivich above, and per BlueRaspberry's deletion comment below. We should move to avoid wasting precious volunteer hours on projects that are not well-enough supported to survive. Ajpolino (talk) 05:53, 17 May 2021 (UTC)
  • Support - I've been here for six years and I have never edited the book namespace, even in an administrative capatcity. Anarchyte (talk) 10:45, 17 May 2021 (UTC)
  • Support an interesting experiment that didn't catch on. I don't see any point in spending any resources on it at this stage. Hut 8.5 19:50, 17 May 2021 (UTC)
  • Support This is an encyclopedia, books belong to Wikibooks. So how about moving the books to Wikibooks instead of deleting them? -Killarnee (C•T•U) 17:22, 18 May 2021 (UTC)
  • Support We are an encyclopedia, not a bookstore. Books are just not in high enough demand from our userbase to be worth the outsized editor time required. AdmiralEek Thar she edits! 17:53, 19 May 2021 (UTC)
    What time is required by our outsized editor? — GhostInTheMachine talk to me 18:10, 19 May 2021 (UTC)
  • Support. Unmaintained features should be removed. Sandstein 07:09, 20 May 2021 (UTC)
  • Oppose Deprecation is half-baked nonsense, it will confuse the heck out of visitors and book enthusiasts will keep right on adding books to it anyway. We really do not want a "hidden" wiki stitched into the one that anyone can read. — Cheers, Steelpillow (Talk) 08:58, 20 May 2021 (UTC)
  • Support. This is just formalising what's currently the case: these aren't maintained by the community, the software doesn't work, and barely anyone views the books. Realistically it doesn't seem that any of these things will change. the wub "?!" 13:56, 23 May 2021 (UTC)
  • Support Although it gives me no great joy to say this, we should have deprecated portals and we should deprecate books, to trim the number of namespaces.  – John M Wolfson (talk • contribs) 14:37, 23 May 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Noindex the book namespace to hide it from search engines

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
Tracked in Phabricator
Task T283522
There is a clear consensus to noindex the book namespace to hide it from searches. (non-admin closure) (t · c) buidhe 09:23, 24 May 2021 (UTC)


This would occur by changing the MediaWiki configurations and prevent Wikipedia Books from showing up in search results. Books would still be reachable with Wikipedia's internal search function. --Trialpears (talk) 18:27, 15 May 2021 (UTC)

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

Remove the option to save in the book namespace from the book creator

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
Tracked in Phabricator
Task T283523
There is a consensus to remove the option to use this tool to create books in the book namespace. (non-admin closure) (t · c) buidhe 09:31, 24 May 2021 (UTC)

This would be implemented by changing a simple MediaWiki configuration setting as documented at mw:Extension:Collection#User rights for saving books. The book namespace would still be editable and it would be possible to move books from user space there or manually create a book using wiki text and then use the book creator. --Trialpears (talk) 18:27, 15 May 2021 (UTC)

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

Drop support for book class from WikiProject assessment

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is consensus to remove support for the Book class from WikiProject assessment, and to delete the associated categories. ProcrastinatingReader (talk) 16:57, 18 June 2021 (UTC)

This would involve emptying and deleting the categories at Category:Book-Class articles and editing the associated templates to not support the book namespace. --Trialpears (talk) 18:27, 15 May 2021 (UTC)

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

Delete all books within the book namespace

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is consensus to delete the Book namespace. It will still be possible to store books in userspace. Overall, the sentiment of participating editors was that the concept is a failed experiment and it's time to let go. Some editors opposed the proposal saying that the functionality should be fixed rather than removed; other editors said that the functionality has no realistic prospect of having development resources allocated to it, and also believed that other issues would be a better use of developer time.
Editors felt that it should still be possible to access books currently in this namespace. Two options were presented to achieve this: the ability to WP:REFUND pages on request, and archival by moving pages in the Book namespace to another namespace. There seems to be a rough consensus that the first approach will be satisfactory, although this can be put to further discussion if there is disagreement. If a deletion route is taken then steps should be taken, preceding deletion of the namespace and its pages, to ensure that administrators will be able to provide copies of the deleted page in response to a WP:REFUND request. ProcrastinatingReader (talk) 16:57, 18 June 2021 (UTC)

WP:REFUNDs to user space would be possible. If all books are deleted the namespace should be uninstalled if deemed appropriate by the developers. This would remove it from lists of namespaces in places like Special:Search and Special:RecentChanges and allow pages like Book – A Novel to be located at the correct title. Special:Book will continue working like normal and saving books in user space is still possible. PediaPress would continue to work except for possibly the catalog depending on their implementation. --Trialpears (talk) 18:27, 15 May 2021 (UTC)

  • Neutral It would be nice to never have to worry about the namespace again and to remove the possibility of vandalism staying for months or the namespace containing a safe harbor for unsuitable pages. There is however some non-zero value from some of these pages for a small number of users. Since the previous link hiding combined with proposals here (mostly noindexing) would prevent people from accidentally coming to the namespace I believe it's fine to leave it like this. While we would still have a small amount of vandalism going uncaught for months, vandalism on a page with just a handful of views isn't that bad. --Trialpears (talk) 18:27, 15 May 2021 (UTC)
  • Support Each of these proposals is making the namespace more and more like a second user namespace and less and less a functioning namespace (to the extent it ever was one). Once each of these are implemented, there will be no meaningful difference between books in the book namespace and books in the user namespace, and thus no reason to keep them separate. I would suggest userfying books whose creator is still active rather than deleting them, however. This renders all of the above proposals moot, so I'm not commenting in any other sections * Pppery * it has begun... 18:36, 15 May 2021 (UTC)
  • Oppose This is an overreaction to a software issue. The solution is to fix the software, not throw out the baby. Headbomb {t · c · p · b} 18:41, 15 May 2021 (UTC)
  • Oppose. Fix it rather than remove it. Littleolive oil (talk) 18:50, 15 May 2021 (UTC)
  • Support per nom. I'm convinced 99.99% of our readers don't know about or have ever used books. Most of those who have probably clicked on them accidentally... We already have built in options (PDF & printable version), as well as 3rd party options, for the truly desperate 0.01%. Aza24 (talk) 19:24, 15 May 2021 (UTC)
  • Support - per my comments in support of deprecation. Userfication, where practical, makes sense as an alternative to deletion. Levivich harass/hound 19:25, 15 May 2021 (UTC)
  • Support per nom, Aza24, and Pppery. — Ched (talk) 20:06, 15 May 2021 (UTC)
  • Support with userification, per Pppery. {{u|Sdkb}} talk 20:25, 15 May 2021 (UTC)
  • Support as first option - I do not see the software becoming functional any time soon, and personally I feel developer time could be better spent elsewhere. As such, there is no point in keeping the namespace around. ƒirefly ( t · c ) 20:28, 15 May 2021 (UTC)
  • Support the history of this project is littered with ideas that were given a fair chance and just didn't work out in the long run. Nobody is going to come along and magically fix all the software issues for a sidelined,disused project that so few find useful. There are far more important and actually useful things for both the community and the staff to be doing. Let's just admit the obvious, this is over. Those people that really want them they can still have them in userspace. Beeblebrox (talk) 21:01, 15 May 2021 (UTC)
  • Oppose - Wikipedia:Featured and good topic candidates/Nomination procedure instructs that books be created as part of the process for nominating featured and good topics. Some of the books will have some historical value through featured and good topics. I don't think blanket deletion of all is a particularly good step, although many are useless. Hog Farm Talk 21:04, 15 May 2021 (UTC)
  • Sort of support - I think it would be better to move the books to the userspace of the original creator, rather than outright deletion, but I agree with removing them from a public facing "Community maintained" section if the encyclopaedia. 192.76.8.91 (talk) 21:23, 15 May 2021 (UTC)
  • Oppose because the "books" are just collection of links, which work perfectly fine with adequate software. Users can still use them right now to produce their own derivative products, e.g. for Kiwix or PediaPress. Nemo 22:00, 15 May 2021 (UTC)
  • Support, per nom and Firefly. Gog the Mild (talk) 22:02, 15 May 2021 (UTC)
  • Oppose, don't hide history. At least get a bot to move it all to subpages of Wikipedia:Books/Old/ or something so the connection to Featured Topics stays comprehensible. —Kusma (t·c) 22:32, 15 May 2021 (UTC)
    • ?? The featured and good topics are barely connected to the books—they provide no more connection than the topic box itself. They're not even displayed in the topic boxes. Aza24 (talk) 22:44, 15 May 2021 (UTC)
      • I still think that some of these may have some historical value. Not a majority, but some. I don't think nuking an entire namespace indiscriminately is going to be helpful here. I support deleting most of these, but I'm not convinced the blanket approach is the best route as some of these may be historically useful and need more attention before deletion. Hog Farm Talk 22:58, 15 May 2021 (UTC)
      • Aza24, they were in the not so distant past: [4] By all means delete those that do harm, but don't delete everything just because it's not "useful" anymore. —Kusma (t·c) 23:03, 15 May 2021 (UTC)
    • I guess it's worth noting that not all featured topics have an associated book. Checking ~20 random topics only a bit over half had one. --Trialpears (talk) 23:30, 15 May 2021 (UTC)
  • Support per above. ~ HAL333 23:56, 15 May 2021 (UTC)
  • Support. The feature is dead and has been for a long time now. The foundation devs have a huge backlog of other bugs which they aren't fixing, and there is no reason to believe they are going to start on this any time soon. The dev time is anyways better served elsewhere. --Gonnym (talk) 00:00, 16 May 2021 (UTC)
  • Support deletion Feature is not supported, never was well supported, and there is no plan to support either in terms of software or volunteer community organization. I have made books in the past and later felt that the process was disappointing. Since it was an option in Wikipedia, I assumed that it was useful, when in fact, the process gets no support, is not part of a tool suite of other useful functions, and does not give benefits that I expected. Unless somehow someone shows evidence of an existing active book development and maintenance community, and unless there is a plan to make a serious Wikimedia community request for Wikimedia Foundation financial investment in this tool's development, then I say delete what exists and remove the option so as not to distract anyone else from more useful and supported tools. Keeping unsupported tools around is not a benefit. The books function as I know it could be recreated as some kind of tool in Wikidata for sharing lists of articles to run reports on them, print them as a book, or coordinate translation of important articles across languages. By putting this in Wikipedia instead of Wikidata the machine readability benefits are not there. Blue Rasberry (talk) 00:06, 16 May 2021 (UTC)
  • Meh and kind of leaning oppose although mass userfication would be fine. These are already very difficult to stumble across, and if the proposals above trend as they currently are it will become essentially impossible to do so. Basically these are nowhere facing, but there's no need and nothing to be gained by hiding history. If people feel things will somehow be tidier without an extra namespace then sure userfy them, but really once these are unfindable any further steps, be they deletion, userfication, etc. sound like extra work for no discernible benefit. Regards, 31.41.45.190 (talk) 01:38, 16 May 2021 (UTC)
  • Meh, also, get rid of the book namespace. Nobody seems interested in maintaining any of this. If volunteers apply, perhaps it could be revived one day. For now, let it continue in userspace. Mass userfication should work. Any "books" that are clearly garbage could be deleted. — Alexis Jazz (talk or ping me)
  • Oppose for now - if the namespace is deprecated this might be good to do next year. Doing it right now is too soon. User:力 (power~enwiki, π, ν) 03:21, 16 May 2021 (UTC)
  • Support the end objective of remove the namespace given the evidence presented. I think deletion of the books should occur, but perhaps only after they have been moved out of the namespace so that REFUNDs can indeed take place. --Izno (talk) 03:23, 16 May 2021 (UTC)
  • Support – This feature is not supported, and no one has any good reason devote the time necessary to make it work. We should not leave a mess like this around, like an abandoned ruin. I support deletion, which will simply be representative of the reality that the 'Book' namespace is and has been dead for a very long time. RGloucester — ☎ 04:10, 16 May 2021 (UTC)
  • Support the end objective of removing the namespace. However, to preserve the history per Hog Farm and Kusma, I would prefer "archiving" these and moving them to a location like like the subpages of "Wikipedia:Books/Old/" or something. – SD0001 (talk) 07:44, 16 May 2021 (UTC)
  • Note: Before any actual deletion occurs, the pages should all be properly tagged so any interested parties are notified. The deletion notice should not be at the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of the Leopard." (I'm wondering whether I should write a WP:LEOPARD essay). —Kusma (t·c) 08:40, 16 May 2021 (UTC)
    Kusma Sure. I'm guessing you want the almost thousand Category:Book-Class articles sub cars tagged as well? Worth noting that WP:CENT and the village pumps really isn't at the bottom of a locked filing cabinet stuck in a disused lavatory while books not getting a single view most months are. --Trialpears (talk) 09:23, 16 May 2021 (UTC)
    Would adding it to {{Saved book}} with namespace detection be sufficient? That would save like 12k unnecessary edits. --Trialpears (talk) 09:33, 16 May 2021 (UTC)
    Trialpears, ideally we just move the whole book namespace back to where it came from (used to be subpages of Wikipedia:Book), then we can avoid notifying people. (For casual users, I think anything other than their talk page and watchlist could just as well be on Alpha Centauri). —Kusma (t·c) 09:56, 16 May 2021 (UTC)
    I've now added a custom deletion notice through the templates {{Saved book}} and {{Category class}}. --Trialpears (talk) 19:48, 16 May 2021 (UTC)
  • Support, with proper warnings for interested parties (eg the book's creator). Let's just kill this failed experiment off. Remagoxer (talk) 11:45, 16 May 2021 (UTC)
  • Oppose This is a little extreme, I support deprecating the namespace, but not deleting everything in it.Jackattack1597 (talk) 13:04, 16 May 2021 (UTC)
  • Support but prefer if we could proactively archive them all to somewhere accessible to regular users before deleting the namespace, rather than requiring that books individually go through the WP:REFUND process after deletion. I don't see a lot of value in preserving them, but all else being equal, it's better not to erase history. Colin M (talk) 13:50, 16 May 2021 (UTC)
  • Comment This is the only important decision in this RfC, it is the endpoint of the death by a thousand cuts the others are perpetuating. Let's just get on with it, one way or the other. Whichever way this goes, we have to accept that we are voting on whether to revive or kill the initiative. — Cheers, Steelpillow (Talk) 14:20, 16 May 2021 (UTC)
    Subsequently you oppose because "it's useful" even though it doesn't work. "Let's get on with it", indeed. Izno (talk) 15:47, 16 May 2021 (UTC)
    @Izno: Why so snarky? Have I upset you or something? Darn, where's the cup of tea template when you need it? — Cheers, Steelpillow (Talk) 15:13, 18 May 2021 (UTC)
    It's not snarky to say "Let's just get on with it"? :) Izno (talk) 19:52, 18 May 2021 (UTC)
  • Oppose I find the Books feature useful; I would use it more if it still worked as well as it used to. I shall be sad to lose it. — Cheers, Steelpillow (Talk) 14:20, 16 May 2021 (UTC)
  • Oppose Too much for now. Revisit when the future of the technology is clear. We currently have 51,546 books in user space and only 6,198 in Book space, so "just" move all of the books in Book space to a sub-page of the user that created them. — Preceding unsigned comment added by GhostInTheMachine (talk • contribs)
    The future is clear: the technology is dead and will not be resurrected at this point. --Izno (talk) 15:46, 16 May 2021 (UTC)
    We are probably talking about different things. The gadget that collects articles worked when I tried it. The gadget that converts these article lists into a PDF worked when I tried it. The question here is should we delete all books within the book namespace and I think we should just move them. Once the namespace is empty, then we have the option to turn it off — GhostInTheMachine talk to me 11:52, 17 May 2021 (UTC)
  • Oppose As this seems to be a technical matter controlled by PediaPress and the WMF/MediaWiki, governed by a legal contract between them, then this is none of our business. If editors or readers do not find the facility useful then they are not required to use it. Andrew🐉(talk) 17:30, 16 May 2021 (UTC)
    I do not think there ever was any legal contract - both sides have behaved far too off-hand for that. Besides, whatever the WMF may or may not have signed up to without telling us is nothing to do with us - there's no mention of such a thing in the code of conduct etc. If the WMF were to have a sudden "Oh, sh*t!" awakening and change their tune, that would be their problem not ours. — Cheers, Steelpillow (Talk) 17:43, 16 May 2021 (UTC)
    Unless I am massively misunderstanding something, any contract between the WMF and PediaPress has absolutely no bearing on whether we have a specific namespace on enwiki or not, nor on whether we choose to deprecate the feature given that it hasn't been working properly for years. ƒirefly ( t · c ) 17:44, 16 May 2021 (UTC)
  • Support with no rush—give an ample window for anyone who wants to repurpose the content to do so and delete at the end of that generous period. czar 18:27, 16 May 2021 (UTC)
  • Prompted by Iznos comment above I have looked into what happened when the education program namespace was temporarily uninstalled. While the namespace was uninstalled it was impossible to access or undelete pages (even for admins). To avoid this all books should be moved to Wikipedia:Books namespace before a possible deletion to avoid this technical issue this time around. --Trialpears (talk) 21:41, 16 May 2021 (UTC)
  • Strong support: per my reasoning above. We need to solve the problem at its root. A refund process or archive of the namespace (on another wiki? Even just a nod towards some fork of Wikipedia on a guideline page?) should be made for individuals who have been using the namespace for personally helpful activities—I don't want to delete what you've worked on, but I don't want to be broadcasting it as reader-facing content. — Bilorv (talk) 22:10, 16 May 2021 (UTC)
  • Transwiki them to English Wikibooks per m:Keep history. Many of these are useful and we have a WMF project that can easily house them. We should not delete them and hope someone decides to dig around our dead namespaces before starting a new effort. Instead, we should move the content to an appropriate place: Wikibooks. — Wug·a·po·des​ 23:03, 16 May 2021 (UTC)
    Wugapodes That really won't work. The books in the book namespace aren't the same type of book wikibooks focus on. While Wikibooks also contain some of this type of books as well at wikibooks:Wikibooks:Collections they won't work since Wikibooks don't contain the Wikipedia articles these books consisted of. If this was done they would literally just be useless lists of red links. I can't imagine Wikibooks would want that. --Trialpears (talk) 23:13, 16 May 2021 (UTC)
    Ah so I was confused about how the software worked. I thought the books namespace held the output of the program (you can tell how much I use the namespace) but yes, looking through them they would be largely useless to wikibooks unless we copied all the articles over too which would be a bad idea. I've struck my comment. I'm fine with whatever as long as the content is recoverable in the future. — Wug·a·po·des​ 23:44, 16 May 2021 (UTC)
    I think that the book ns is and always will be pointless. But why can't the related articles stay here and the links can easily be changed? -Killarnee (C•T•U) 17:35, 18 May 2021 (UTC)
    The book creator is designed to work on pages that are all within the same wiki - when you use it to create or edit a book it adds a banner at the top of the page that you can use to add articles to your book as you browse. I don't know if it would work with cross wiki links, but it really isn't intended to be used in that manner. Also being blunt for a minute, the book namespace is full of crap and I would strongly oppose dumping our rubbish on another wiki with the expectation that they'll either have to preserve it and maintain it for us or turn it into something worthwhile. Is wikibooks going to want Book:Blakfacts: Volume 4.5, which starts with a section on "Short Little Black People"? How about it's companion Book:Blakfacts Volume 12:, which is literally just someone's list of top Africans? Is anyone going to read Book:American Holocaust which is 50% about the extinction of the American bison and 50% about the colonisation and oppression of the native Americans? Is wikibooks going to want Book:Pirates1 a world first in the cosmology/piracy/sci-fi genre? What about Book:Political Alternatives, which lists "valid alternatives to the current political system" which consists entirley of links to articles on socialism? Is anyone ever going to read Book:Gemology and Jewelry, an unsorted 500 article long book including everything vaguely related to jewellery, or Book:Ancient Monuments In The UK, a 350 article long book on ancient monuments in the UK. What's the inclusion criteria that was used to select articles for Book:Core biographies (A–D), is it just some readers list of their favourite articles? Do you want a book containing countries that were featured articles in 2012? Don't worry Book:Featured Country Articles has you covered. I already talked through my experience of searching for a history book above, but the vast majority of the namespace is abandoned personal projects that we should not be presenting to readers as "community maintained". If they're going to be kept then userfying them to the userspace of the original creator is probably the best way of dealing with them IMO. 192.76.8.73 (talk) 22:00, 18 May 2021 (UTC)
  • Support per nom and extended discussion above. EpicPupper (talk) 04:17, 17 May 2021 (UTC)
  • Support provided there's some path to refund requested material. Ajpolino (talk) 05:53, 17 May 2021 (UTC)
  • Oppose. The reason the Book namespace is filled with garbage isn't because books are a bad idea, it's an artifact of historical factors (primarily the book rendering service being fucked up). If there is no longer an influx of crappy books (i.e. disabling the feature to make them easily), I think it would be easy to clean them up and write good ones. jp×g 06:30, 17 May 2021 (UTC)
  • Oppose - No reason to obscure them from public sight. No-indexing and the removal from certain forms of the search engine is more than adequate. — Godsy (TALKCONT) 07:02, 17 May 2021 (UTC)
  • Support Or what about moving the pages to Wikibooks instead of deleting all the pages? -Killarnee (C•T•U) 17:25, 18 May 2021 (UTC)
    See the replies to Wugapodes, who made an identical suggestion a few comments up. * Pppery * it has begun... 17:28, 18 May 2021 (UTC)
  • Oppose I often use the Book tab to track changes for specific topics. I get far more use out of this than the Watchlist. Dobbyelf62 (talk) 23:27, 18 May 2021 (UTC)
    Presumably you could use a userspace book (which won't be affected by this proposal) or Special:RecentChangesLinked for the same purpose. * Pppery * it has begun... 02:43, 19 May 2021 (UTC)
  • Support with the goal of removing the namespace clutter. Also fine with moving to an archive location in another namespace as a few have suggested e.g. Wikipedia:Books/Old. the wub "?!" 13:56, 23 May 2021 (UTC)
  • Support if they can't/shouldn't be moved to WikiBooks  – John M Wolfson (talk • contribs) 14:42, 23 May 2021 (UTC)
  • Support Which other wiki uses this namespace? We're the only one that uses it, and it's currently deprecated. We can download pages as PDFs, and there's already another wiki for books. Why keep a namespace that's not used? I think one possibility would be to delete all pages in the Book namespace and to blacklist the namespace. It would be a lot easier than deleting the namespace. If all pages in this namespace do get deleted, please refund all of my edited pages in book ns, and in book talk ns as well if those get deleted. 54nd60x (talk) 03:03, 25 May 2021 (UTC)
  • Oppose Wikipedia:Books are very useful, they logically group and consolidate articles and information in a streamlined and *accessible* manner that cannot be done elsewhere in the encyclopedia. They offer quick links to important services for our readers like the ability to download them as PDF versions (see Book:Jane Austen for example). Additionally, the Book_talk pages come with some vital tracking tools like Template:Book report which gives us a good overview of all the statuses (cleanup, non-free media, etc) of each article within each book. Click "show" in the template to see full functionality and see also Book talk:Jane Austen as an example. Whatever technical action or solution you choose to apply, please *do not delete* our wonderful Wikipedia Books. Remember the WP:READER. Thank you, History DMZ (HQ) † (wire) 15:53, 28 May 2021 (UTC)
Oppose for historical reasons. Books should be deprecated instead and left at that. Tyrone Madera (talk) 20:13, 28 May 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
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.

Post-close

I've started a small follow up discussion with my concrete proposal of how to implement this at Wikipedia:Village pump (technical)#Implementation of book namespace deletion. --Trialpears (talk) 07:51, 19 June 2021 (UTC)

Note: Not sure where to register disagreement, but I'll put it here. User space for this is problematic, because Book-namespace books were community endeavors, and had multiple editors. Before the book namespace existed, community books were hosted at Wikipedia:Books/Foobar. This is where their resting place should be as well. Headbomb {t · c · p · b} 16:05, 19 June 2021 (UTC)

@Headbomb Not sure what you are disagreeing with. The closure doesn't say anywhere that books will be moved to userspace. – SD0001 (talk) 19:51, 19 June 2021 (UTC)
Moved to Wikipedia:Village pump (idea lab) § Good articles and Featured articles
 – No clear proposal. Sungodtemple (talk) 13:22, 21 June 2021 (UTC)

Change the partial block message to be orange or yellow instead of red

This proposal is clearly successful, and at this time, I think we should transition to talking about how we're going to implement the proposal. Mz7 (talk) 19:12, 11 June 2021 (UTC)

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

Tech note: this is about styling the child div box .mw-contributions-blocked-notice-partial .mw-warning-with-logexcerpt in Special:Contributions that displays this text when a user is partially blocked.

If at all possible, I think that we should change the partial block notification box from red to either orange or yellow in order to differentiate partial from full blocks. This would be helpful to reduce confusion - most obviously for sysops who might not notice the message says "partially blocked" instead of "blocked" and not take action on disruptive editors, but also for other patrollers who might refrain from reporting a problematic editor if it seems at first glance like they have already been blocked. This was brought up a couple months ago, but there was not a substantial amount of discussion beyond determining that it may be technically possible to do something like this. Aspening (talk) 03:02, 1 June 2021 (UTC)

I agree - the present notice looks too much like a siteblock. This is particularly confusing when encountering partial blocking on ranges. Acroterion (talk) 03:10, 1 June 2021 (UTC)
Some notes for nerds are in here. See the mini-hatnote above for what the specific box is being disucssed
  • @Aspening: can you be more specific, exactly what templates/messages/etc do you want to change? (I have no idea what the partial block notification box is referring to). For example, here is a recent partially blocked user - what specifically do you want to change? This may very well not require a full VPPR discussion to make a color tweak. — xaosflux Talk 14:51, 1 June 2021 (UTC)
    Xaosflux: Aspening is probably referring to the red box on the top of this page: Special:Contributions/Ioannesko Sungodtemple (talk) 14:53, 1 June 2021 (UTC)
    @Xaosflux: I'm referring to the box that appears on the user's special:contributions page that says "This user is currently partially blocked." I am suggesting that that box should be orange or yellow for partial blocks to reduce confusion per the reasons listed above by myself and other users. 331dot also brings up a good point that yellow is more cautionary, so I'm now leaning more towards having this box be orange. Aspening (talk) 14:57, 1 June 2021 (UTC)
    @Aspening: OK, so that box is wrapped in a class, "mw-contributions-blocked-notice-partial", but itself is in a div with classes "warningbox mw-warning-with-logexcerpt mw-content-ltr". The second of those classes is being used for the styling from common.css. The message itself is from MediaWiki:sp-contributions-blocked-notice-partial. So adjusting the color style is not super-easy, but markup can be added to the message very easily (see example at testwiki:Special:Contributions/Example~testwiki). Would markup something like that be enough to address your concern? — xaosflux Talk 15:11, 1 June 2021 (UTC)
    @Xaosflux: Possibly - I think a color change would be preferable, but if that is difficult or impossible I think that emphasizing the partial block in that way could be satisfactory. Aspening (talk) 15:17, 1 June 2021 (UTC)
    @Aspening: I added the emphasis to to the text at least for now. Coloring may be blocked on a technical challenge as there is a class collision with mw-warning-with-logexcerpt there. Perhaps someone else has a technical idea that isn't an ugly hack. — xaosflux Talk 15:29, 1 June 2021 (UTC)
    Uh, is it an ugly hack to just overwrite it with .mw-contributions-blocked-notice-partial .mw-warning-with-logexcerpt {border-color:#fc3;background-color:#fef6e7;}? I didn't think that was verboten in CSS practice, but I'm no expert... Writ Keeper ⚇♔ 15:36, 1 June 2021 (UTC)
    @Writ Keeper: I only said "may" :) Something like that could work, putting in hyper-specific styles in the common.css isn't ideal, but we don't have much else to work with on this message so may be the way. — xaosflux Talk 15:47, 1 June 2021 (UTC)
    The box is yellow per the MediaWiki defaults. Our common.css code is making it red. So having another rule to put it back to yellow may not be unreasonable. – SD0001 (talk) 15:52, 1 June 2021 (UTC)
    @SD0001: I'm not disagreeing with the color choices, just that applying layer after layer of overlapping css via common.css isn't ideal (even when it is the only tech option), that specific implementation isn't a hard blocker. That we are currently styling on "warning-with-logexcerpt" there isn't ideal either, but it is what it is. If this proposal keeps trending towards support we can mock up some technical solutions. — xaosflux Talk 16:04, 1 June 2021 (UTC)


Technical implementation

DONE
Implemented by Xaosflux (non-admin closure) dudhhrContribs 20:44, 21 June 2021 (UTC)

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


@Xaosflux, Aspening, Writ Keeper, and SD0001: I can see in your collapsed conversation that there is a potential MediaWiki:Common.css hack that could do this (e.g. to change the red back to the default yellow), but it seems more discussion on the technical implementation is needed. What would be necessary to implement this proposal? Mz7 (talk) 19:12, 11 June 2021 (UTC)

Testing on testwiki (testwiki:MediaWiki:Common.css) - waiting for update to populate it. — xaosflux Talk 21:07, 11 June 2021 (UTC)
Test cases:
  1. Normal block: testwiki:Special:Contributions/Xaosflux2
  2. Partial block: testwiki:Special:Contributions/Xaosflux2a
@Mz7: that what you are looking for? — xaosflux Talk 21:12, 11 June 2021 (UTC)
@Xaosflux: Ooh, yeah. That looks really nice. Mz7 (talk) 21:27, 11 June 2021 (UTC)
 Doing... — xaosflux Talk 21:49, 11 June 2021 (UTC)
 Done @Mz7: see live example at Special:Contributions/Example. If there are any issues please post at MediaWiki_talk:Common.css#pblock-style. — xaosflux Talk 21:58, 11 June 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
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.

Proposal: Implement extended confirmed users into the Implicit member of: like autoconfirmed users

Moved to WP:VPI § Extended confirmed users group management

— xaosflux Talk 13:38, 23 June 2021 (UTC)

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