View source for Wikipedia:Village pump (proposals)/Archive 190

{{Wikipedia:Village pump/Archive header}}

== Can projects ignore manuals of style ==

[[:MOS:DATETOPRES]] was created at least three years ago. A discussion was held in August and September 2019 [[:Wikipedia talk:WikiProject Football/Archive 127#MOS:DATETOPRES]] that determined that the project could implement the full term but {{user|GiantSnowman}}  stated that the project should [[:WP:IAR]] and that they should "keep it out". No further action was taken and they essentially ignored the manual of style. I was alerted to the change and opened a discussion ([[:Wikipedia talk:WikiProject Football/Archive 151#Infobox style update]]) in February 2022 but was shot down, again with GiantSnowman being the most vocal in opposition. I raised it on the MoS's talk page [[:Wikipedia talk:Manual of Style/Dates and numbers#MOS:DATETOPRES in infoboxes]] and there has been some discussion. It was subsequently raised by other editors [[:Wikipedia talk:WikiProject Football/Archive 152#MOS:DATETOPRES]] in April.

The question is, can a project just ignore the manual of style? If the MoS is not appropriate, should it be changed or removed? [[User:Walter Görlitz|Walter Görlitz]] ([[User talk:Walter Görlitz|talk]]) 05:47, 1 May 2022 (UTC)
:Apparently the issue concerns edits [[Special:Diff/1083117278|like this]] which changed "2020–" to "2020–pres." Looking at [[WT:WikiProject Football/Archive 152#MOS:DATETOPRES]] and [[WT:Manual of Style/Dates and numbers#MOS:DATETOPRES in infoboxes]] suggests that "The editor in question knows that but chooses to ignore". It is a really bad idea to wage war against an active wikiproject over trivia like this. In fact it is disruptive and if continued should result in blocks. You know the procedure—get a centrally published RfC to agree with you (and add it to [[WP:LAME]]) or leave the wikiproject alone. [[User:Johnuniq|Johnuniq]] ([[User talk:Johnuniq|talk]]) 06:55, 1 May 2022 (UTC)
::Bingo. Firstly, DATETOPRES is a guideline and not compulsory. Secondly, I have been editing for 16+ years and in that entire time I have never seen it in use by various WikiProjects; I had not realised that DATETOPRES is very recent and therefore Walter was trying to enforce this new guideline on existing article styles. Thirdly, it appears to be Walter and Walter alone who is trying to enforce this, despite clear opposition. Ergo - the MOS should be tweaked to reflect the long-standing practices on Wikipedia. [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 07:51, 1 May 2022 (UTC)
::: The history at the first discussion shows that several in the project agreed to change it to "present" but GiantSnowman is the most vocal opponent. [[User:Walter Görlitz|Walter Görlitz]] ([[User talk:Walter Görlitz|talk]]) 14:02, 1 May 2022 (UTC)
::::and yet as you can see here, others (outside of the various WikiProjects as well) agree with me that the MOS should be amended to reflect the long-standing editing conventions, and not the other way around (that you are the ONLY editor trying to enforce). [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 14:21, 1 May 2022 (UTC)
:Very short and easy answer - no they can't. [[User:Gonnym|Gonnym]] ([[User talk:Gonnym|talk]]) 07:55, 1 May 2022 (UTC)
:The parts of the MoS that do not enjoy wide consensus should not be enforced. As football biographies are a large part of Wikipedia's BLPs, the MoS should reflect how they are written. Mass changes should only come with a wide consensus including the people who do the day-to-day work on the articles. —[[User:Kusma|Kusma]] ([[User talk:Kusma|talk]]) 08:27, 1 May 2022 (UTC)
::If it doesn't have wide consensus - the agreement of the projects - then it should be removed from the MoS. [[User:Hawkeye7|<span style="color:#800082">Hawkeye7</span>]] [[User_talk:Hawkeye7|<span style="font-size:80%">(discuss)</span>]] 10:51, 1 May 2022 (UTC)
::: But if there is no valid reason to ignore the MoS, then the project should follow it. That is the case with DATETOPRES and FOOTY. If they have a valid reason, let's see it. The only reason I have seen offered is there are a lot of articles to change, and for that, there are bots, editors with AWB and many, many volunteers. Is there another reason? [[User:Walter Görlitz|Walter Görlitz]] ([[User talk:Walter Görlitz|talk]]) 19:50, 1 May 2022 (UTC)
*A LOT depends on the size of the WikiProject in question. A consensus to IAR among the members of a small WikiProject (with very few active members) would carry very little weight. A consensus to IAR among the members of a very large WikiProject (with hundreds of active members) should carry significant weight. [[User:Blueboar|Blueboar]] ([[User talk:Blueboar|talk]]) 12:20, 1 May 2022 (UTC)
*Re "If the MoS is not appropriate, should it be changed or removed?" Neither, it should be ''ignored''. It's really hard to get anything changed around here. We have a lot of rules that are either silly, objectively bad, or micromanaging. I try to ignore three rules before breakfast every day, it keeps me young. "Very short and easy answer - no they can't". I mean, they ''are'', so I guess they can? I suppose you mean ''may'nt'', but I mean it's a wiki not the DMV. The less telling other people how to write, the better. Consistency is way overrated, you'd be surprised how little the readers care about that. [[User:Herostratus|Herostratus]] ([[User talk:Herostratus|talk]]) 13:23, 1 May 2022 (UTC)
** That I have no problems if there is a good reason to ignore it, but "the project is large and it would take a bot (or a lot of individual effort) to modify all of articles" is not a valid counter-argument. Since consistency is overrated, then why can't an individual editor ignore all rules and correctly apply the MoS on articles they edit against the project's own ignoring of the MoS? [[User:Walter Görlitz|Walter Görlitz]] ([[User talk:Walter Görlitz|talk]]) 14:02, 1 May 2022 (UTC)
**:Or ignore both the MOS and the project's guidelines? Once you start ignoring the MOS, why stop at the Wikiproject? [[User:Peter coxhead|Peter coxhead]] ([[User talk:Peter coxhead|talk]]) 14:09, 1 May 2022 (UTC)
**:Indeed that strawman is not a valid argument, but nobody has argued with the amount of effort required. —[[User:Kusma|Kusma]] ([[User talk:Kusma|talk]]) 14:25, 1 May 2022 (UTC)

I'm no expert, but my understanding is that we should follow guidelines unless there is a consensus ''not'' to follow them. You don't need a consensus to follow guidelines. Also, for what it's worth, it takes at least two people to engage in a [[WP:LAME|lame edit war]]. That being the case, you probably shouldn't accuse someone else of being lame, if you're taking part in that same war. If the disputed issue doesn't matter, don't debate it. If it does matter, don't accuse others of being lame for believing that it matters. [[User:Instant Comma|Instant Comma]] ([[User talk:Instant Comma|talk]]) 16:20, 1 May 2022 (UTC)

The intro of MOS essentially says that with it sometimes be ignored, and even MOS itself is merely a guideline. What the actual question is is whether a project can make up a rule that conflicts with MOS. But editors should feel triply free to ignore any rule made up within a project, and quadruply so if it conflicts with MOS.   So IMO it's a bad and pointless idea for a project to try to make such a rule, or imply that others are compelled to follow it. <b style="color: #0000cc;">''North8000''</b> ([[User talk:North8000#top|talk]]) 17:45, 1 May 2022 (UTC)

:to clarify - there are ''multiple'' WikiProjects that do not follow this rule, which was introduced (according to Walter) only 3 years ago (i.e. long after the various WPs had already started their standards/MoS. So it's not that the WPs don't comply with the rule, it's that the rule did/does not match how editors actually edit (if that makes sense?) [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 18:30, 1 May 2022 (UTC)

Can anyone explain why this actually matters? [[User:AndyTheGrump|AndyTheGrump]] ([[User talk:AndyTheGrump|talk]]) 18:32, 1 May 2022 (UTC)
:it doesn't - but Walter has been engaging in a disruptive campaign to change how multiple WikiProjects and probably hundreds if not thousands of editors edit tens/hundreds of thousands of articles, for some reason. [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 18:34, 1 May 2022 (UTC)
::And, you know, saying that using common sense will lead to chaos is not a good look -- the "If you allow gay marriage, next people will be marrying telephone poles" type argument. Most slopes are not slippery and we have, I hope, the sense that God gave sheep to know when to draw lines. Some people feel more comfortable when rules are always rigidly adhered to, and fine -- in ''their'' writing they are free to keep a list of Wikipedia rules on their desk and make sure that every one is followed. Give the rest of us the courtesy of the same freedom (I speak of rules where it's not really important (like the current case); there are some MOS rules that everyone ought to follow, and the borderline is debatable and always will be). Let Wikiprojects set their own rules, or indeed have a rule that says "you may do such-and-so as you think best". [[User:Herostratus|Herostratus]] ([[User talk:Herostratus|talk]]) 18:48, 1 May 2022 (UTC)
::: Well if it does not matter, whey exactly is an admin (in this case GiantSnowman) reverting?
::: It clearly matters to you GS. The MoS is clear and there is no valid reason to ignore it. The only disruptive element is the one who continually removes a correctly applied manual of style because you don't like it. I follow one team. I have correctly applied the MoS to the current players of that team and that is in no way disruptive. I am not forcing the project to change their way of editing a few hundred articles, but i's clear that you have no valid reason to ignore the rule, and so ignoring it is disruptiuve to the whole project. [[User:Walter Görlitz|Walter Görlitz]] ([[User talk:Walter Görlitz|talk]]) 19:39, 1 May 2022 (UTC)
::::You (alone) say there is no valid reason to ignore it - I (and many, many others) say there is no benefit in following it. [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 20:53, 1 May 2022 (UTC)
:{{replyto|Walter Görlitz}} {{tq|The question is, can a project just ignore the manual of style?}} [[WP:LOCALCONSENSUS]] says not. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 20:32, 1 May 2022 (UTC)
::The question is… when dealing with a large WikiProject disagreeing with one of our more obscure MOS guidelines, which actually represents ''wider community'' consensus? There is an argument for saying that ''occasionally'' project consensus can actually be “wider” than guideline consensus. This is something WP:LOCALCONSENSUS does not consider. [[User:Blueboar|Blueboar]] ([[User talk:Blueboar|talk]]) 20:50, 1 May 2022 (UTC)
:::This is far wider than that - it is multiple WikiProjects that have been editing in this manner since long before the 'rule' came into effect. [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 20:50, 1 May 2022 (UTC)
{{od}} Can somebody please persuade Walter to stop single-handedly [https://en.wikipedia.org/w/index.php?title=Lucas_Cavallini&diff=prev&oldid=1085664514 trying to force] the MOS on articles when there is clear opposition to the same? [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 20:59, 1 May 2022 (UTC)
:At the top of this guideline it says, "It is a generally accepted standard that editors should usually attempt to follow, though it is best treated with common sense, and occasional exceptions may apply." How about using a bit of common sense when it comes to things that have worked perfectly well ever since Wikipedia was founded? [[User:Phil Bridger|Phil Bridger]] ([[User talk:Phil Bridger|talk]]) 21:22, 1 May 2022 (UTC)
:I agree with Walter. The fact that the MOS is apparently followed in this instance by the entire project except for a few projects shows that there is widespread consensus to follow the MOS and that these few projects are trying to use a LOCALCONSENSUS to ignore it. The project benefits with a consistent style; it just looks more professional. The MOS is a style guide for the project {{tq|that editors should usually attempt to follow}}. While {{tq|occasional exceptions may apply}}, that does not mean it should be ignored by whole projects. [[User:MB|<b style="color:#034503">MB</b>]] 21:27, 1 May 2022 (UTC)
:: Perhaps the question is can someone persuade GiantSnowman to stop reverting the MoS when it is correctly applied?
:: With that stated, I have not seen the discussion at the manual of style, nor a rationale for its widespread implementation. With that said, I have also not seen a rationale for its exclusion by a handful of sports projects. [[User:Walter Görlitz|Walter Görlitz]] ([[User talk:Walter Görlitz|talk]]) 22:26, 1 May 2022 (UTC)
:::then what are the acceptable 'occasional exceptions'? I also think you saying "the MOS is apparently followed in this instance by the entire project" is misleading, as it implies that editors are actively and deliberately following the MOS, which is not the case. How many editors know about it? How many bear it in mind when editing? You will note that Walter is the only one actually going around trying to enforce this. That shows that only one editor actually follows the MOS... [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 08:33, 2 May 2022 (UTC)
::::Are you seriously twisting "occasional exception" into all the thousands of articles within a particular project?  An "occasional exception" should be justified with a good reason, not just because "we have always done it that way". And yes, an editor writing in compliance with the guideline, even if not realizing what they are doing is per a specification, and perhaps just following how they see something done in most other articles, is still following the MOS. [[User:MB|<b style="color:#034503">MB</b>]] 19:06, 2 May 2022 (UTC)
:Per [[WP:CONLEVEL]], {{tq|participants in a WikiProject cannot decide that some generally accepted policy or guideline does not apply to articles within its scope}}. If a WikiProject wants an exemptions from the policy or guideline then they should open a general discussion requesting a consensus for that exception. [[User:BilledMammal|BilledMammal]] ([[User talk:BilledMammal|talk]]) 00:26, 2 May 2022 (UTC)
::there is a discussion here...and many are saying 'the MOS' does not need to apply. [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 08:31, 2 May 2022 (UTC)
*Of all the examples of overreach in the MOS, this has to be at or near the very top. I can't imagine that this was a big enough issue to require a hard and fast rule that every article must follow, with no exceptions. Does anyone actually think readers get confused by seeing "2002-" in an article? Or is this is an example of MOS-types setting rules with no regard for common sense? [[User talk:Vaulter|<span style="color:#F67280; font-family:Sans-Serif">'''-- Vaulter'''</span>]] 01:44, 2 May 2022 (UTC)
*:exactly. I have been editing for 16+ years, at no point has any reader expressed confusion in this regard. [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 08:31, 2 May 2022 (UTC)
*::@[[User:Vaulter|Vaulter]], @[[User:GiantSnowman|GiantSnowman]], I believe that it will be confusing for people using [[screen reader]] software.  You could ask [[Wikipedia talk:Manual of Style/Accessibility]] to be sure, but I believe that these are the results (Wikipedia article first, screen reader voice second):
*::* 2002 = two thousand two
*::* 2002– = two thousand two
*::* 2002–2022 = two thousand two two thousand twenty-two
*::* 2002–present = two thousand two present
*::Since "2002" (i.e., one year only) and "2002–" (i.e., twenty years) are read out the same way, it could be very confusing and misleading.  [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 03:07, 5 May 2022 (UTC)
*:::At last a substantive comment, rather that the "my project's more important than yours" stuff. In my screen reader (the free one that comes with Linux Mint) I get similar results, with "2002" and "2002–" reading the same way, ignoring the "–". If this happens in the screen readers most commonly used by people who actually need them then it seems like a good reason for our football articles to be changed. [[User:Phil Bridger|Phil Bridger]] ([[User talk:Phil Bridger|talk]]) 07:00, 5 May 2022 (UTC)
*::::I agree too. I'd also say the MOS should be updated to mention the accessibility concerns rather than the current vague statement to "not use incomplete-looking constructions." [[User talk:Vaulter|<span style="color:#F67280; font-family:Sans-Serif">'''-- Vaulter'''</span>]] 15:49, 5 May 2022 (UTC)
*:::::this is a fair point about accessibility - but what about '2002–pres.'? [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 17:51, 5 May 2022 (UTC)
*::::That's a great point, but this sounds like it might need to be applied more widely. Generally, this says that dashes should be avoided? "Since 2002" would sound better than "2002 present" or "2002 president" so perhaps we could use something like that instead? How do screenreaders read "3 August 1976–5 September 2001"? —[[User:Kusma|Kusma]] ([[User talk:Kusma|talk]]) 23:20, 5 May 2022 (UTC)
*:::::An excellent idea. [[User:MichaelMaggs|MichaelMaggs]] ([[User talk:MichaelMaggs|talk]]) 10:54, 6 May 2022 (UTC)
*::::::@[[User:Kusma|Kusma]], I believe that is read out as "three August nineteen seventy-six five September two thousand one" (or perhaps 'one thousand nine hundred seventy-six' for the first year).  [[WT:ACCESS]] is a better place to ask, if you want a solid answer instead of a guess. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 19:21, 6 May 2022 (UTC)
*:::::::@[[User:WhatamIdoing|WhatamIdoing]], thank you. I don't currently have the time or energy to pursue this. But if dashes are not read at all, we should perhaps replace dashes that mean "to" either by the word "to" or by a fancy template that produces a dash or the word "to" depending on whether it is in standard or in screenreader mode. We should definitely attempt to have a MOS that improves accessibility where possible. —[[User:Kusma|Kusma]] ([[User talk:Kusma|talk]]) 19:48, 6 May 2022 (UTC)
*::::::::When I asked about it, a blind editor told me not to worry about it, because it was normal and expected all over the web.  I decided to write the words out (in prose) anyway.  I did not feel encouraged to make a big deal out of it, and it's certainly not worth edit warring over, but it seemed like an easy way (for me) to be slightly clearer, and it's really no extra effort (for me).  You might find it useful to keep this in mind while you're editing for the next month or two, and see what kinds of situations you encounter.  It's useful to know the range of situations before trying to make any big changes. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 23:26, 6 May 2022 (UTC)
*I don't see why this is causing so much huff. WikiProjects do ''not'' have [[WP:OWNERSHIP]] over articles. MOS is a central matter to be determined by the community at-large. If a small minority of editors have made a change to MOS that others disagree with (and this I think has happened before), including members of a WikiProject, the appropriate response is to take it to the relevant MOS talk page and/or open an RfC. If it's so obvious that so many editors clearly disagree with a change, this should not be difficult to achieve. The WikiProject members can all have their say on said talk or in said RfC. -[[User:Indy beetle|Indy beetle]] ([[User talk:Indy beetle|talk]]) 08:50, 2 May 2022 (UTC)
**Sigh… Agreed… if there are editors who can’t accept a simple “ignore”, then we probably do need to hold an RFC to determine whether the current language of [[WP:DATETOPRES]] needs to be amended. [[User:Blueboar|Blueboar]] ([[User talk:Blueboar|talk]]) 13:56, 2 May 2022 (UTC)
* '''Repeal'''.  [[:MOS:DATETOPRES]] is improper because:
*# According to the OED, "pres." is an abbreviation for "president" not present.  The suggested usage is therefore not standard English.
*# The present is imprecise or indeterminate because it is constantly changing.  It would be better to specify the time of writing, which is not the same as our articles are not updated in real-time.
*# The discussion above indicates that it lacks consensus
*# [[WP:CREEP]]
:[[user:Andrew Davidson|Andrew]]🐉([[user talk:Andrew Davidson|talk]]) 19:22, 2 May 2022 (UTC)
::Agree with it being removed or amended. [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 20:15, 2 May 2022 (UTC)
*[[WP:CONLEVEL]] explicitly says WikiProjects can't overrule global consensus, but just because something is written in the MOS doesn't mean it's global consensus. One has to see if the specific MOS rule was added after a widely-advertised RFC (per the global consensus of [[WP:PGCHANGE]]), or if it was a bold edit. If it's the result of a widely-advertised RFC, then it's global consensus, and WikiProjects can't exempt themselves, no matter how large; they'll need to start a new RFC to see if [[WP:CCC|consensus has changed]]. If on the other hand the rule was added in a bold edit, then a large WikiProject not complying is evidence that there isn't global consensus for the bold addition in the first place. I'm not sure which is the case here. [[User:Levivich|Levivich]] 19:25, 2 May 2022 (UTC)
*:FYI it's multiple WikiProjects that 'ignore' it, not just one... [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 20:16, 2 May 2022 (UTC)
*::It was boldly added with [https://en.wikipedia.org/w/index.php?title=Wikipedia%3AManual_of_Style%2FDates_and_numbers&diff=prev&oldid=705051302 this edit] in 2016. It has been there a long time, so there is an argument for [[WP:IMPLICITCONSENSUS]], but there is no evidence of a global consensus. [[User:Hawkeye7|<span style="color:#800082">Hawkeye7</span>]] [[User_talk:Hawkeye7|<span style="font-size:80%">(discuss)</span>]] 20:37, 2 May 2022 (UTC)
*:::which post-dates the way that the WikiProjects in question have been editing by at least 10 years... [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 10:57, 3 May 2022 (UTC)
*::::Unfortunately, there is no rationale provided for the change either. [[User:Hawkeye7|<span style="color:#800082">Hawkeye7</span>]] [[User_talk:Hawkeye7|<span style="font-size:80%">(discuss)</span>]] 06:04, 5 May 2022 (UTC)

As Indy beetle says, the best way forward is to have a discussion to establish consensus. Unlike the [[Wikipedia:Manual of Style/Organisms#Capitalization|species capitalization question]], I feel the visual effect on the reader is small. Thus I think possible options could include "keep the same as originally written" or "follow local consensus of interested editors for the article". In an ideal world, sure, it'd be nice if everything was consistent. I think it could be a reasonable choice, though, to say the benefit/effort ratio isn't worth it for this case. [[User:Isaacl|isaacl]] ([[User talk:Isaacl|talk]]) 21:01, 2 May 2022 (UTC)

* Rules should reflect current consensus. If they don't, we need to fix them. "Ignoring" them because they bother us ''without'' discussing them is simply not a sensible option because a) why have them in the first place and b) how can we expect new users to do right when we don't even follow our own rules? Please open a formal challenge to the MOS guidance at the relevant talk page. -[[User:Indy beetle|Indy beetle]] ([[User talk:Indy beetle|talk]]) 00:54, 3 May 2022 (UTC)
*:Agreed.  Perhaps the rule has its uses but its scope is narrower than MOS implies and needs to be clarified. [[User:Certes|Certes]] ([[User talk:Certes|talk]]) 01:06, 3 May 2022 (UTC)
*:Sure, that's what I said: we should discuss the matter to establish consensus, and update the guidance accordingly. The consensus view could be to have a fixed rule, or flexible rules. Whatever it is should be clarified. [[User:Isaacl|isaacl]] ([[User talk:Isaacl|talk]]) 15:26, 3 May 2022 (UTC)
* Since it seems that it was added without a proper RfC, ignore it for now and leave it up to the WikiProjects. It's more important to have consistency between subjects (like football articles or military articles) than it is to have consistency between all ~6.5 million articles. The former lies up to the respective WikiProjects and can be decided on their talk pages. Wasting our time discussing something as trivial as this is a poor use of our time. [[User:Why? I Ask|Why? I Ask]] ([[User talk:Why? I Ask|talk]]) 01:15, 3 May 2022 (UTC)
** As a coordinator for the MilHist project, I must object. The problem is that mindset effectively gives WikiProjects special powers which they explicitly do ''not'' have. To quote [[Wikipedia:WikiProject|the information page]]: {{xt|WikiProjects are not rule-making organizations, nor can they assert ownership of articles within a specific topic area. WikiProjects have no special rights or privileges compared to other editors and may not impose their preferences on articles. A WikiProject is fundamentally a social construct: its success depends on its ability to function as a cohesive group of editors working towards a common goal.}} In practice we tend to defer to subject expertise for certain matters which tends to coalesce in certain groups, but projects do not simply get to decide what rules apply for articles in their field and what do not. That has to be allowed by the community at large. MOS are rules. If they are bad rules, then let us make them good rules! -[[User:Indy beetle|Indy beetle]] ([[User talk:Indy beetle|talk]]) 04:35, 3 May 2022 (UTC)
**:The MoS is a ''guideline'', not a hard rule. As it clearly says at the top: {{xt|it is best treated with common sense}}. The MoS is designed to make the pages more accessible for the reader. Something like this only deals with minor aesthetics, at best. And the latter note is why Wikipedia has such a hard gathering and retaining experts in specific fields. Because this pseudo-bureaucracy works against them. Let the WikiProject with the most experts in the subject best decide how to move forward in their respective fields (unless, as I said, it creates major accessibility issues). No one has control over any Wikipedia article; that includes people that tout the MoS as the final say. Discuss matters on the respective articles or the WikiProjects that maintain the articles. I point you toward [[WP:CREEP]]. [[User:Why? I Ask|Why? I Ask]] ([[User talk:Why? I Ask|talk]]) 06:30, 3 May 2022 (UTC)
***Well, if we're simply going to ignore the MOS when we [[WP:DONTLIKEIT]] because we're too lazy/special to put in the bare minimum of effort to change it, we might as well scrap the whole concept. Yes, we should treat MOS with common sense, but why don't we actually try to make the MOS common sense (by securing widespread agreement on its text)? That seems way more in the spirit of avoiding CREEP. The sheer amount of resistance to this idea of simply dropping some comments off at a talk page makes me suspect that the people here who object to the MOS guidance are actually worried that it does have consensus, and don't want to find out for sure. -[[User:Indy beetle|Indy beetle]] ([[User talk:Indy beetle|talk]]) 11:06, 3 May 2022 (UTC)
***:Some of us (me) have attempted to amend the MOS to reflect this - and been reverted. [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 11:42, 3 May 2022 (UTC)
***:@[[User:Indy beetle|Indy beetle]]'s arguments are persuasive. It can't be right that whole swathes of articles are subject to repeated reverts when editors attempt to follow the MOS, with reverting editors relying on the often unwritten 'customs' of WikiProjects who [[Wikipedia:WikiProject|according to the information page]] lack any authority ({{green|"WikiProjects have no special rights or privileges compared to other editors and may not impose their preferences on articles"}}). The MOS is of global scope, and if an argument is being made that certain classes of article should have special rules applied, those special rules should be discussed in an RFC and added to the MOS if it transpires there is global (not WikiProject) consensus to do so. [[User:MichaelMaggs|MichaelMaggs]] ([[User talk:MichaelMaggs|talk]]) 13:04, 3 May 2022 (UTC)
***:Obviously, it doesn't have complete global consensus or else there wouldn't be so many people opposed. Both WikiProject Guidelines and the MoS are simply recommendations. Case-by-case bases are what works best. As the MoS FAQ page points out: {{xt|It is not a mandatory policy that editors must assiduously follow.}} [[User:Why? I Ask|Why? I Ask]] ([[User talk:Why? I Ask|talk]]) 16:56, 3 May 2022 (UTC)
:If it's in the MOS, it is presumed to have consensus and should be followed. If a particular project does not like it, it is up to them to start a discussion to have this item either amended or outright removed from the MOS. Unless and until that amendment/removal, anyone is free to edit an article to adhere to MOS and anyone reverting such edits is to be considered acting against consensus. --[[User:Khajidha]] ([[User talk:Khajidha|talk]]) ([[Special:Contributions/Khajidha|contributions]]) 13:20, 3 May 2022 (UTC)
::Except the MOS is a) not compulsory and b) was added without consensus and against standard editing for many editors. [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 13:26, 3 May 2022 (UTC)

IMO they are both optional guides. MOS is a collection of hundreds of items, most of them coming from at most local consensus, and many from small discussions or bold edits.  And so as a whole it certainly doubly has has no global consensus for the reason described and also that the context for inclusion decisions was that they were going into a mere guideline, and one which further softens itself in it's intro.    And a project guide is just from one project.  So, as a reference, if a binding rule is  100% influential, the MOS is like 40% influential and a prominent widely used project guideline is like 39% influential.  So while MOS might be slightly more influential, IMO nobody should be forcing MOS-based changes to content written in accordance with a heavily used project guideline based on that 1% difference.  Sincerely, <b style="color: #0000cc;">''North8000''</b> ([[User talk:North8000#top|talk]]) 14:09, 3 May 2022 (UTC)
*It's untenable that we would allow a new rule to be boldly added to MOS and expect others to start an RfC to remove it, no matter how long the new rule has been there. If it was boldly added it can be boldly removed. People don't watchlist PAGs, there ought be no silence or implied consensus there. There is another thread going on somewhere about whether RFCs should be required for PAG changes and the answer is yes for substantive changes, and this is why. [[User:Levivich|Levivich]] 14:18, 3 May 2022 (UTC)
*:Exactly - the pre-2016 version should be restored, and if people want to change that, ''they'' start a RFC to do so. [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 15:32, 3 May 2022 (UTC)
*The wider issue here is that WikiProject Football seems to have developed a bit of a habit of putting themselves in opposition to project-wide consensus. This was an underlying factor in [[Wikipedia:Arbitration/Requests/Case/GiantSnowman]], and now we have: this thread; [[Wikipedia:Administrators' noticeboard#Admins can ask questions too]], where it was proposed that [[WT:FOOTBALL]] should be consulted before football AfDs (which we require nowhere else in the project); and today I've closed a bunch of AfDs with participants insisting on voting based on a guideline ([[WP:NFOOTY]]) that no longer exists. Active WikiProjects like [[WP:FOOTBALL]] are fantastic for our coverage and I wish there were more of them, but as others have pointed out, they're not policy-making organs or editorial boards. If the members of a WikiProject disagree with a project-wide policy, the answer is to engage with the project-wide policy-making process, not try to ignore it. If it doesn't go your way, then you just have to accept that. And I don't say this to admonish [[WP:FOOTBALL]], I say it to warn them. We've seen WikiProjects developing this silo mentality before and it tends to end with ArbCom cases, sanctions, and good editors leaving the project with hard feelings. That isn't good for anyone. &ndash;&#8239;[[User:Joe Roe|Joe]]&nbsp;<small>([[User talk:Joe Roe|talk]])</small> 14:37, 3 May 2022 (UTC)
*:What relevance does my personal ArbCom case from over 3 years ago have to this current issue? Have you even read this thread which makes it clear that the 'rule' was introduced without consensus in 2016 and that it was done so long after a number of WikiProjects had already developed their MOS? There are clear grumblings about this situation from many outside the various WikiProjects. The only thing that "isn't good for anyone" is comments like yours which seem to tar all members of a WikiProject with the same brush. [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 15:36, 3 May 2022 (UTC)
*::{{xt|There are clear grumblings about this situation from many outside the various WikiProjects.}} Great! Let's go do something about it! -[[User:Indy beetle|Indy beetle]] ([[User talk:Indy beetle|talk]]) 16:03, 3 May 2022 (UTC)
*:::We kinda already are! [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 16:16, 3 May 2022 (UTC)
*::To put it in simple terms for you, what links the two is [[WP:OWNERSHIP]]. &ndash;&#8239;[[User:Joe Roe|Joe]]&nbsp;<small>([[User talk:Joe Roe|talk]])</small> 07:27, 4 May 2022 (UTC)
*:::Useful contributions only please. [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 18:07, 4 May 2022 (UTC)
* Would it be possible to provide a template that displayed the hyphen (to save space) but the text "to present" (for screen readers)? [[User:Hawkeye7|<span style="color:#800082">Hawkeye7</span>]] [[User_talk:Hawkeye7|<span style="font-size:80%">(discuss)</span>]] 21:57, 5 May 2022 (UTC)
*:An excellent suggestion.  {{tl|Screen reader-only}} may be useful here.  I don't see its converse {{tl|Except screen reader}} but, if the dash is visible and silent, we don't need one.  [[User:Certes|Certes]] ([[User talk:Certes|talk]]) 23:52, 5 May 2022 (UTC)
*::yes, this seems like a fantastic compromise. [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 10:39, 6 May 2022 (UTC)
*The idea a WikiProject can ignore parts of MOS without question seems very troubling to me considering how many aspects of MOS relate to the reading experience (both ability to read and ease of comprehension) for disabled readers. I think establishing a precedent WikiProjects can just do what they want and WP:OWN articles (not how it works) in such a way that could dismantle some of these disability protections seems like a seriously unwise idea to me.— [[User:Ixtal|Ixtal]] <sup>( [[User talk:Ixtal|T]] / [[Special:Contributions/Ixtal|C]] ) </sup> &#8258; <small> Join [[WP:FINANCE|WP:FINANCE]]! </small> 08:14, 6 May 2022 (UTC)
* {{u|Kusma}} has made the best suggestion in this thread which is to use "Since 2002" in preference to either "2002-" or "2002–pres". That's much better for people using accessibility screen readers than the existing MOS rule, and is short enough to be used generally, including infoboxes. I'd like to see an RFC updating [[MOS:DATETOPRES]] to include that, while making it clear that it's not open to any WikiProject to carve out general exceptions. [[User:MichaelMaggs|MichaelMaggs]] ([[User talk:MichaelMaggs|talk]]) 11:14, 6 May 2022 (UTC)
*:But the MOS by its very nature is not compulsory, so unsure why you are complaining about general exceptions - oh and your suggestion will simply result in arguments between 'since 2002' and '2002–pres'. [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 11:17, 6 May 2022 (UTC)
*::No, "Since 2002" ''replaces'' both "2002-" and "2002–pres" in [[MOS:DATETOPRES]]. "2002–present" stays, but I don't see people wanting to use that in an infobox. As to your other point, what you position as a right of a Wikiproject to make its own rules independently of MOS, I call [[WP:OWNERSHIP]]. There's no need to reply to every post here with the same argument. [[User:MichaelMaggs|MichaelMaggs]] ([[User talk:MichaelMaggs|talk]]) 11:31, 6 May 2022 (UTC)
*:::I'll stop replying when people actually start reading the MOS in question and the points raised by many editors (including many those outside the multiple WikiProjects in question). Accusing others of OWNership is incredibly ABF and shows the weakness of your argument/position. [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 11:41, 6 May 2022 (UTC)
*::::Maybe someone could make a regex search to figure out how many articles actually use the "–pres" option, before we argue any more about what to do with it. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 19:35, 6 May 2022 (UTC)
*:::::(I will be interested in knowing how often it is used in sortable tables, because "2002–pres" sorts very differently from "since 2002", which is an option that is otherwise very appealing to me.) [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 19:38, 6 May 2022 (UTC)
{{od}}I mean, I'm not seeing how any of this is tenable since "present" changes every day at midnite, and certainly becomes untrue in many articles every year, and in at least one article on most days I'd guess. I have seen lots of articles where it says "the song is scheduled to be released in 2017" and so on. It's fairly common. So I mean "present" is often useless and sometimes wrong. "present (as of [year])" is what's required.

There is {{tl|asof}}, but that can't be used in infoboxes, and it's already used on 72,000 pages and how many editors are we going to assign the job of checking each of these every year or so? If you have like "1993-present (as of 2022)" then  you warn the user that the info may no longer be current (which "present" alone does not) and also exactly how non-current it is, and you provide editors coming across the material to know if it's OK to let slide ("as of 2021") or possibly take a look at updating ("as of 2004"), without populating a huge category which (I'm guessing) doesn't even differentiate between data from last year and date from the Clinton Administration. I myself ''occasionally'' will see a an "as of 2008" and do a quick check to see if the given status is still current and update it to "2022" if that's appropriate. I suppose other editors gnaw away at this too, albeit slowly I'm sure. Using just "present" doesn't tell us if this is needed.

I used to work with a guy who would write "latest version" on the media for each new iteration of an app, heh. Isn't using just "present" a little like that?

TL;DR: why is "present" ever used alone, and why would any rule suggest doing that??? [[User:Herostratus|Herostratus]] ([[User talk:Herostratus|talk]]) 01:09, 7 May 2022 (UTC)
* I tried to see how often "-pres" is actually used in articles. Regex search for a 4 digit number followed by one of the various types of dashes and "pres" or "pres." or "present" gives only [https://en.wikipedia.org/w/index.php?search=insource%3A+pres+insource%3A%2F%5B%5E-%5D%5B0-9%5D%7B4%7D+*%28-%7C%E2%80%93%7C%E2%80%94%7C%5C%26ndash%5C%3B%7C%5C%26mdash%5C%3B%7C%5C%7B%5C%7B--%5C%7D%5C%7D%7C%5C%7B%5C%7Bndash%5C%7D%5C%7D%7C%5C%7B%5C%7B%E2%80%94%5C%7D%5C%7D%7C%5C%7B%5C%7Bmdash%5C%7D%5C%7D%7C%5C%7B%5C%7Bem%5B-+%5D*dash%5C%7D%5C%7D%7C%5C%7B%5C%7Bnsndns%5C%7D%5C%7D%7C%5C%7B%5C%7Ben+*dash%5C%7D%5C%7D%7C%5C%7B%5C%7B%E2%80%93%5C%7D%5C%7D%29+*pres%28%5C.%7Cent%29%3F%2Fi&title=Special%3ASearch&profile=advanced&fulltext=1&ns0=1 1,450] results. [[User:ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ|ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ]] ([[User talk:ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ|talk]]) 06:17, 7 May 2022 (UTC)
*:OK, this is great research - because given the hundreds of thousands of sports biographies alone which will use year spans (plus tens of thousands of other biographies as well), this clearly shows that the MOS is essentially ignored by ''everyone'', not just the 'few WikiProjects' that some are pointing the finger at. As I have stated many times, the MOS should be changed to reflect the clear wide/long-standing usage by editors. [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 07:50, 7 May 2022 (UTC)
*::Very few of them are "<code>–pres</code>"; almost all of them (98%?) are "<code>–present</code>".  You can see the abbreviation in the last row of the table at [[Colorado Buffaloes men's basketball#Record by coach]]. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 20:44, 16 May 2022 (UTC)
*:::Still shows that it is barely used. [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 21:02, 16 May 2022 (UTC)

:Yeah, I sort of agree. "to present" becomes more clearly wrong when not updated than "since 2000", and the same is true for the variants with a dash. —[[User:Kusma|Kusma]] ([[User talk:Kusma|talk]]) 07:23, 7 May 2022 (UTC)
::I don't think that out-of-date information is generally a problem with our articles about footballers, at least those who play in Britain or in the top leagues in major footballing European countries. We usually have, in my experience, editors falling over each other trying to update the articles every time they play a match, often not even waiting until the match is over. [[User:Phil Bridger|Phil Bridger]] ([[User talk:Phil Bridger|talk]]) 07:56, 7 May 2022 (UTC)
:::Not sure this is also true for, say, Congolese politicians. If we have a rule, it should consider the needs of the less active topics as well. —[[User:Kusma|Kusma]] ([[User talk:Kusma|talk]]) 09:31, 7 May 2022 (UTC)
:I'm finding it a bit crazy how many people are saying that MOS is ''optional''. Yes, it is a guideline, but one that we should keep too. If the guideline isn't suitable, then it should get changed. If, however, a particular WikiProject, or even a set of editors don't believe it applies to them, then that's not cool. Maybe a better topic would be if this part of the MOS is suitable. I can't say I've ever seen it before, and is worth discussing. Best Wishes, '''[[User:Lee Vilenski|<span style="color:green">Lee Vilenski</span>]] <sup>([[User talk:Lee Vilenski|talk]] • [[Special:Contribs/Lee Vilenski|contribs]])</sup>''' 19:31, 9 May 2022 (UTC)
::Previous attempts to remove or amend the MOS - which, I repeat, was introduced without consensus - have been reverted. It is clear from this thread that the MOS format is barely used, and as such it should be removed to reflect the clear real-life editing. [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 21:05, 10 May 2022 (UTC)

:Further on the history discussed above: as noted, the [https://en.wikipedia.org/w/index.php?title=Wikipedia:Manual_of_Style/Dates_and_numbers&diff=prev&oldid=705051302 15 February 2016 edit] that added this provision to the MOS did not state any rationale for it (it was added along with some uncontroversial changes that were carefully explained in the edit summary). There ''was'' a [https://en.wikipedia.org/wiki/Wikipedia_talk:Manual_of_Style/Dates_and_numbers/Archive_154#YYYY%E2%80%93present contemporaneous discussion], but it didn't yield anything remotely close to a consensus. Especially strangely, on 2 March 2016, the same editor who added the DATETOPRES provision stated that they "violently agree that Francis's summary of the problems with 'present' is correct (as far as it goes; there are others). Just the fact that lots of people do it doesn't make it a good idea." So unless I'm profoundly misreading that exchange, it appears that even the editor who added the DATETOPRES language did not, on reflection, agree with it. In any event, given that there was never even a local consensus among MOS regulars for this change -- a change that would only have been noticed by someone carefully watching every revision to the page -- I think it should clearly be '''removed'''. -- [[User:Visviva|Visviva]] ([[User talk:Visviva|talk]]) 02:35, 22 May 2022 (UTC)
::Agreed. [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 18:12, 24 May 2022 (UTC)
:::I went ahead and changed the advice from "write 2001–present" to "write 2001–present (as of 2022)". I didn't change the advice to use just "pres." in space-constrained cases, as I don't know how that should be handled. [[User:Herostratus|Herostratus]] ([[User talk:Herostratus|talk]]) 03:28, 3 June 2022 (UTC)
::::It should be removed, as numerous editors have said here. [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 07:38, 3 June 2022 (UTC)

== "Fix" Wikipedia Adventure by adding buttons to progress in "click on edit button" steps ==
{{archive top}}
{{moved to|Wikipedia:Village_pump_(technical)#Fix_Wikipedia_Adventure_by_adding_buttons_to_progress_in_"click_on_edit_button"_steps}}
After some updates, [[Wikipedia:The Wikipedia Adventure|the Wikipedia Adventure]] can no longer progress after clicking on the edit button. While I don't know about the hooks of the guided tour, I know that we could easily add buttons that say "Clicked!" to have the tour progress itself instead of waiting for an event that never comes. [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 06:27, 4 June 2022 (UTC)
{{archive bottom}}

== Edit summary field - make drop down ==
{{tracked|T6716}}
I've had a quick look at archives and can't see that this has been discussed? The Edit summary field (described elsewhere as a "text box, not a drop down box") is annoying as the text scrolls sideways, hence some is 'invisible'. With the advent of 1,000 character summaries, could this usefully be made to drop-down, to show multiple-lines, perhaps with a side scroll bar?--[[User:Rocknrollmancer|Rocknrollmancer]] ([[User talk:Rocknrollmancer|talk]]) 20:11, 29 May 2022 (UTC)
:{{re|Rocknrollmancer}} edit summary should be limited to 500 characters still; just checking though - seems like you don't want a "drop down" type of control, but you want the input box to be taller with wrap-around text (a la [[phab:T6716]])? — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 14:22, 31 May 2022 (UTC)
::Yes, that's what I tried to imply {{U|Xaosflux}}; it could show perhaps three lines at any time with auto word-wrap. I've had this (difficulty) with (off-Wiki) feedback webforms showing only part of the message, Eon energy being recent (actually contracted-out to a metrics analysis specialist), when I anticipated that it was single-line only, so composed it into a draft webmail field then pasted in, although there was no character count down, so I was guessing. That's what prompted this post. Thanks. [[User:Rocknrollmancer|Rocknrollmancer]] ([[User talk:Rocknrollmancer|talk]]) 16:46, 31 May 2022 (UTC)
:::{{re|Rocknrollmancer}} thanks for confirming, looks like this is something that would have to be fixed upstream in mediawiki software, not something we can do here on the English Wikipedia.  There is a task ([[phab:T6716]] that has been open for a '''very long''' time to change the from an input box to a textarea box that would support either a scroll bar or text wrapping.  You can comment on T6716 directly. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 18:33, 31 May 2022 (UTC)
::::@[[User:Rocknrollmancer|Rocknrollmancer]]: Enable a gadget in [[Special:Preferences#mw-prefsection-gadgets|your preferences]] to show some common summaries. [[User:TSOPar|TSOPar]] ([[User talk:TSOPar|talk]]) 17:20, 5 June 2022 (UTC)

== Proposal: Change the Wikipedia logo to rainbow colors for LGBT Pride Month ==
{{archive top|[[WP:SNOW]]. {{nac}} [[User:EpicPupper|🐶&nbsp;EpicPupper]] <sup>(he/him &#124; [[User talk:EpicPupper|talk]])</sup> 23:02, 8 June 2022 (UTC)}}
Many websites are adding rainbow colors to their website. I think Wikipedia should as well. Not sure what a logo would look like, but worth discussing. [[User:Interstellarity|Interstellarity]] ([[User talk:Interstellarity|talk]]) 00:40, 8 June 2022 (UTC)

:[[Gay_pride#LGBT_Pride_Month|Pride Month]] is celebrated at different times in different countries. [[User:AndyTheGrump|AndyTheGrump]] ([[User talk:AndyTheGrump|talk]]) 00:44, 8 June 2022 (UTC)
:'''Oppose''' per AndyTheGrump, and also [[m:Logo#Temporary logo variants]] and [[phab:T304314|this]] Phabricator ticket. [[User:EpicPupper|🐶&nbsp;EpicPupper]] <sup>(he/him &#124; [[User talk:EpicPupper|talk]])</sup> 01:04, 8 June 2022 (UTC)
::Note that these links don't ban the practice of celebratory logos, they ban the practice of celebratory logos using local CSS.
::No general comment on the proposal. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 01:46, 8 June 2022 (UTC)
:::Yes, they don't ban the practice of celebratory logos, they strongly recommend against the practice of celebratory logos for holidays. [[User:EpicPupper|🐶&nbsp;EpicPupper]] <sup>(he/him &#124; [[User talk:EpicPupper|talk]])</sup> 01:59, 8 June 2022 (UTC)
:'''Oppose''' this well-intentioned idea, because every month is Think Of Us Month for some cause or other, many of them equally worthy.  To be fair, we'd give each of them equal prominence – impossible in the year with only 12 months – and would never show our "normal" logo.  It is better to feature related articles, pictures, etc. via the main page selections.  [[User:Certes|Certes]] ([[User talk:Certes|talk]]) 11:32, 8 June 2022 (UTC)
:'''Oppose''' I'm not in support of this as it isn't "about Wikipedia", and doesn't apply to all of our readers.  While WMF is headquartered in the US, our readers are world-wide and this is a US-specific awareness event. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 12:47, 8 June 2022 (UTC)
::Possible option - if there is a special editing drive for the locality (like a "Edit-a-thon for improving articles on United States [[:Category:LGBT scientists|LGBT Scientists]]") a geo-notice might do. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 12:51, 8 June 2022 (UTC)
:'''Oppose''' Beyond the event, too US/Western centric in every respect. <b style="color: #0000cc;">''North8000''</b> ([[User talk:North8000#top|talk]]) 12:50, 8 June 2022 (UTC)
:'''Oppose''' Wikipedia is not for promotion of anything, regardless of the cause/event. [[User:Hog Farm|Hog Farm]] <sub> ''[[User talk:Hog Farm|Talk]]''</sub> 16:49, 8 June 2022 (UTC)
:I remember seeing a similar proposal recently for "official" recognition of another awareness/pride week/month, and think the same of this one. Interested people are welcome to have a drive to improve articles related to the subject at this time or any other time of year, but it should not come with any official imprimatur. [[User:Phil Bridger|Phil Bridger]] ([[User talk:Phil Bridger|talk]]) 18:55, 8 June 2022 (UTC)
:It was {{diff2|1087471272|this}}. [[User:Phil Bridger|Phil Bridger]] ([[User talk:Phil Bridger|talk]]) 19:02, 8 June 2022 (UTC)
::There was also similar proposal one a while ago for autism awareness month. [[User:Curbon7|Curbon7]] ([[User talk:Curbon7|talk]]) 19:04, 8 June 2022 (UTC)
:'''Oppose'''. The only time it is appropriate for Wikipedia to collectively endorse any cause is when that cause pertains to our ability to build an encyclopedia (e.g. things about copyright or freedom of speech). As wonderful a cause as Pride is, it does not pass that bar. Editors can of course still show their individual support for Pride on their userpages and in their signatures. <span class="nowrap"> <span style="font-family:courier">-- [[User:Tamzin|<span style="color:#E6007A;">Tamzin</span>]]</span><sup>[''[[User talk:Tamzin|<span style="color:#E6007A;">cetacean needed</span>]]'']</sup> (she/they)</span> 20:48, 8 June 2022 (UTC)
::Yes, they can obviously show their support there, but such support is pretty empty unless they also work on improving related Wikipedia articles. [[User:Phil Bridger|Phil Bridger]] ([[User talk:Phil Bridger|talk]]) 21:40, 8 June 2022 (UTC)
*'''Oppose''' As pointed out, a promotion of a US-centric cause that is unrelated to Wikipedia and would open us to endless promotion of various deserving causes. [[User:Meters|Meters]] ([[User talk:Meters|talk]]) 21:47, 8 June 2022 (UTC)
{{archive bottom}}

== Substitute int: messages ==
{{Moved from|Wikipedia:Village pump (technical)#Substitute int: messages}}
The <code><nowiki>{{int:filedesc}}</nowiki></code> and <code><nowiki>{{int:license-header}}</nowiki></code> belong on Commons which is a interlanguage wiki. I claim that they don't belong here on enwiki and requested they be substituted at [[WP:BOTREQ#Substitute messages]] but {{ping|Novem Linguae}} wanted consensus so I post it here to get it.[[User:Jonteemil|Jonteemil]] ([[User talk:Jonteemil|talk]]) 16:03, 8 June 2022 (UTC)

:Yeap, just double checking. Any objections to subst-ing all these with a bot? There will be [https://en.wikipedia.org/w/index.php?search=file%3A+local%3A+insource%3A%2F%5C%7B%5C%7Bint%3A%28filedesc%7Clicense-header%29%5C%7D%5C%7D%2Fi&title=Special%3ASearch&go=Go&ns0=1 about 4000 pages affected] in the File namespace. If no objections I will file a BRFA shortly. Thanks. –[[User:Novem Linguae|<span style="color:limegreen">'''Novem Linguae'''</span>]] <small>([[User talk:Novem Linguae|talk]])</small> 18:38, 8 June 2022 (UTC)
{{block indent|em=1.6|1=<small>Notified: [[Wikipedia talk:Files for discussion]]. –[[User:Novem Linguae|<span style="color:limegreen">'''Novem Linguae'''</span>]] <small>([[User talk:Novem Linguae|talk]])</small> 18:48, 8 June 2022 (UTC)</small>}}<!-- Template:Notified -->
*No way. The <code><nowiki>{{int:...}}</nowiki></code> markup is a means for obtaining messages from the MediaWiki: namespace that are adjusted for the reader's language preference (int = internationalised). If you have never altered your language pref, <code><nowiki>{{int:filedesc}}</nowiki></code> emits [[MediaWiki:Filedesc]]; if you have it set to de -Deutsch, you will see [[MediaWiki:Filedesc/de]], and so on. Since it is dependent upon the ''reader's'' pref setting, any bot run will enforce the language setting of the bot. Why is this not at [[WP:VPR]], anyway? --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 19:41, 8 June 2022 (UTC)
*:Moved. –[[User:Novem Linguae|<span style="color:limegreen">'''Novem Linguae'''</span>]] <small>([[User talk:Novem Linguae|talk]])</small> 20:04, 8 June 2022 (UTC)
*:I'm sorry, but I'd like to note that this is the ''English'' Wikipedia, not a multi-lingual wiki like Wikimedia Commons or Meta. [[User:EpicPupper|🐶&nbsp;EpicPupper]] <sup>(he/him &#124; [[User talk:EpicPupper|talk]])</sup> 20:24, 8 June 2022 (UTC)
*::Sure, content and discussions should be in English, but that doesn't mean editors must use an English-language interface to edit English Wikipedia. [[User:Isaacl|isaacl]] ([[User talk:Isaacl|talk]]) 20:54, 8 June 2022 (UTC)
*:::We generally expect content in wikitext to be in English. I don't think any multi-language users should have any expectation that File space acts differently. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 21:43, 8 June 2022 (UTC)
*::::I agree that it wouldn't be in the minimal set of necessary features, and that users speaking other languages shouldn't expect it to be. Nonetheless, providing internationalization hooks and localization into other languages is a welcoming feature to offer, particularly for English Wikipedia which has a lot of editors that are non-native English speakers. [[User:Isaacl|isaacl]] ([[User talk:Isaacl|talk]]) 22:59, 8 June 2022 (UTC)
*{{anchor|intexample}} On occasion, I post messages with an <nowiki>{{int}}</nowiki>-based invitation to read it in another language (<code>{{int:interlanguage-link-mul}}</code>), and an invitation to translate it into another language (<code>{{int:please-translate}}</code>). Ideally, these should show in the user's interface language ([https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&uselang=fr#intexample see in practice]). The presumption is that there are users who may be more familiar with languages other than English. Does this proposal concern just the two mentioned examples, or all usages of int? [[User:Xeno (WMF)|Xeno (WMF)]] ([[User talk:Xeno (WMF)|talk]]) 23:19, 8 June 2022 (UTC)
*If ain't broke, don't fix it. To the best of my understanding, the existence of <code><nowiki>{{int:  }}</nowiki></code> messages isn't causing any harm, so no need to remove them. If there is a harm being done, I'm open to the idea of removing them. <span class="nowrap">&#8212;'''[[User:CX Zoom|CX Zoom]]'''[he/him]</span> <sup class="nowrap">([[User talk:CX Zoom|let's talk]] • {[[Special:Contributions/CX Zoom|C]]•[[User:CX Zoom/X|X]]})</sup> 08:10, 10 June 2022 (UTC)
*:{{re|CX Zoom}} The thing is there is a bot that removes double headers and it didn't recognise a "Summary" header followed by a "int:filedesc" header as something wrong. So it actually does cause some harm.[[User:Jonteemil|Jonteemil]] ([[User talk:Jonteemil|talk]]) 08:57, 10 June 2022 (UTC)
*::Sounds like a bot that isn't making a "good" edit, that should be fixed in the bot. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 10:04, 10 June 2022 (UTC)
*Doesn't seem like this an issue, and is actually marginally helpful for readers with their interface languages set to anything other than English? — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 10:06, 10 June 2022 (UTC)
*'''Oppose''', has potential uses for people from other language Wikipedias looking at our images who can figure out more easily whether they are appropriate for re-use elsewhere. No actual harm has been demonstrated (bugs in bots should be fixed in their source code, not worked around in the whole wiki). —[[User:Kusma|Kusma]] ([[User talk:Kusma|talk]]) 11:16, 10 June 2022 (UTC)

== RfC: Bot to blank old IP talkpages ==
{{closed rfc top
| status = 
| result = Near-unanimous consensus in favor of this proposal, subject to [[WP:BRFA]] approval as usual. [[User:Levivich|Levivich]] 22:13, 10 June 2022 (UTC) <small>([[Wikipedia:Non-admin closure|non-admin closure]])</small>
}}


Should a bot be used to blank old IP talkpages which:
* Have not received any messages in the last 5 years
* The IP is not under active blocks (including range blocks)
* There have been no edits from the IP in the last 5 years
Pages that meet this criteria will be blanked and replaced with {{tl|Blanked IP talk}}, which reads
{{Blanked IP talk}}
—[[User:ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ|ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ]] ([[User talk:ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ|talk]]) 04:31, 10 May 2022 (UTC)

; Background
There are millions of IP talkpages with vandalism warnings received since the earliest days of Wikipedia. Recent vandal warnings serve a useful purpose, but warnings from very long ago are detrimental as there is a high chance that the IP address would have shifted to different users. Stale warnings and other messages will confuse legitimate new editors editing from that IP seeing it apparently directed at them. Blanking the page and replacing it with {{tl|Blanked IP talk}} template will avoid confusing legitimate editors, while still allowing access to potentially useful edit history.

Other benefits of this task will include uncluttering the [[Special:WhatLinksHere]] data for pages across all namespaces. Stale IP talkpages contains millions of links to articles, policy pages and their associated redirects, User pages, User talk pages, templates etc,. They will be cleaned up with this task.

This will involve the bot editing at least 1.5 million pages. If consensus is found for this proposal, I (or anyone else) can use a bot to implement it, subject to the normal [[WP:BAG]] approval from the [[WP:BRFA|Bot request for approval]] process.

Here are some sample edits: [https://en.wikipedia.org/w/index.php?title=User_talk:123.27.165.190&diff=prev&oldid=1087069616], [https://en.wikipedia.org/w/index.php?title=User_talk:123.2.111.245&diff=prev&oldid=1087069457], [https://en.wikipedia.org/w/index.php?title=User_talk:123.2.115.235&diff=prev&oldid=1087069532] —[[User:ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ|ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ]] ([[User talk:ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ|talk]]) 08:22, 11 May 2022 (UTC)

=== Survey (iptalk blanker bot) ===
* '''Support''', as proposer. I believe the criteria is a safe base for a bot to work from. We can discuss the bot's techincal implementation details, its handling of edge cases and see if any minor changes are necessary during the [[WP:BRFA]] process. [[User:ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ|ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ]] ([[User talk:ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ|talk]]) 08:37, 11 May 2022 (UTC)
* '''Support'''. I understand some concerns raised in the discussion, and think that we can proceed cautiously by having such a bot begin by focusing on ''very'' old IP talk pages (e.g., the IP has neither edited nor been blocked for over 12 years, and the page has not been touched in that time), and once those are done, evaluate any surprises and move the limit up a year, and proceed that way until we get to the five year range. [[User:BD2412|<span style="background:gold">'''''BD2412'''''</span>]] [[User talk:BD2412|'''T''']] 05:54, 12 May 2022 (UTC)
*'''Weak support''' I still have reservations over the matter, as I noted in the [[WP:VPIL]] discussion, but at least I have a sense that those reservations are also in the minds of the BotDevs and will be taken into account.  --[[User:Jayron32|<span style="color:#009">Jayron</span>]][[User talk:Jayron32|<b style="color:#090">''32''</b>]] 18:08, 13 May 2022 (UTC)
* '''Oppose''' Not worth it, especially given that IP masking is happening soon. [[User:Pppery|* Pppery *]] [[User talk:Pppery|<sub style="color:#800000">it has begun...</sub>]] 18:13, 13 May 2022 (UTC)
*:[[One does not simply walk into Mordor|One does not simply]] get to roll out IP masking. Major changes like that take a long time to happen. Many things about it is still not clear and WMF has yet to give a timeframe for implementation. Even after IP masking is rolled out at some point, stale IP talkpages will continue to pose a maintenance burden. A substantial portion of the existing [https://fireflytools.toolforge.org/linter/enwiki millions of Lint errors] is because of IP talkpages. [[User:ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ|ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ]] ([[User talk:ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ|talk]]) 19:19, 13 May 2022 (UTC)
*'''Support''' - seems a reasonable approach and looks like it's being handled sensibly. [[User:Andrew Gray|Andrew Gray]] ([[User talk:Andrew Gray|talk]]) 17:43, 14 May 2022 (UTC)
*'''Support'''. I see no reason as to why decade old IP talk pages shouldn't be templated out automatically, saving much time and manual effort, I sometimes find in RecentChanges. <span class="nowrap">&#8212;'''[[User:CX Zoom|CX Zoom]]'''[he/him]</span> <sup class="nowrap">([[User talk:CX Zoom|let's talk]] • {[[Special:Contributions/CX Zoom|C]]•[[User:CX Zoom/X|X]]})</sup> 18:08, 14 May 2022 (UTC)
* '''Support'''. There is indeed too much of a maintenance burden with these old IP talk pages. Blanking them / Blanking with template will reduce this while also making the what links here a bit more useful again. --[[User:Gonnym|Gonnym]] ([[User talk:Gonnym|talk]]) 20:18, 14 May 2022 (UTC)
* '''Neutral'' I guess. Is this an actual problem, or a solution in search of a problem? I personally haven't experienced this as a problem ''for me'''. Maybe it's OK to see that there've been vandal warnings going back ten years, as this could indicate that it's like a static IP for a school, if being aware of that even matters... which probably not. I suppose it's more just clutter, and  cleaning up clutter is OK too. Not important IMO, but perfectly OK to do if desired. [[User:Herostratus|Herostratus]] ([[User talk:Herostratus|talk]]) 22:29, 23 May 2022 (UTC)

=== Discussion (iptalk blanker bot) ===
:I think I still prefer a subst'd type version of that simple template, so as to not add over a million instances of a template out there (which drags along another template, which drags along a module, etc). — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 10:40, 10 May 2022 (UTC)
::My preference for using a transcluded template is that if we have to change something due to future software changes (say the <code><nowiki>{{FULLPAGENAMEE}}</nowiki></code> magic word or some table markup), we can just update one page instead of having a bot go around changing substed uses. If the associated templates and modules are a concern, a compromise will be to hardcode {{tl|Blanked IP talk}} to not use any other templates and modules. However note that every template and module used by {{tl|Blanked IP talk}} is already used heavily enough to be under full protection. [[User:ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ|ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ]] ([[User talk:ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ|talk]]) 11:06, 10 May 2022 (UTC)
:::I have gone ahead and hardcoded most of the template, with no change in text. Previously it used 7 other templates and modules, now it uses only one. When reading this page from mobile, I realised the old template did not render in mobile due to it using <syntaxhighlight lang="CSS" inline>tmbox tmbox-notice</syntaxhighlight> classes. Now it renders in mobile too. [[User:ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ|ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ]] ([[User talk:ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ|talk]]) 16:39, 15 May 2022 (UTC)
:Question, what if the IP talk page hasn't received any actual warnings in 5 years, but their talk page got vandalized by another IP or a user before that 5 years happened, and no one noticed? Maybe the bot should look to see if there were any new warnings placed on the talk page in 5 years? ― [[User:Blaze Wolf|<b style="background:#0d1125;color:#51aeff;padding:1q;border-radius:5q;">Blaze&nbsp;Wolf</b>]][[User talk:Blaze Wolf|<sup>Talk</sup>]]<sub title="Discord Username" style="margin-left:-22q;">Blaze&nbsp;Wolf#6545</sub> 14:13, 10 May 2022 (UTC)
::The idea is to remove all stale messages from inactive IP talkpages, not just warnings. This is why {{tl|Blanked IP talk}} uses the word "messages" instead of "warnings". If the page has received any edits within the last 5 years, the bot will ignore it. [[User:ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ|ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ]] ([[User talk:ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ|talk]]) 14:48, 10 May 2022 (UTC)
FYI, there's {{tl|Old IP warnings top}} and {{tl|Old IP warnings bottom}} for IPs that are quite likely shared. Then again, shared IPs probably wouldn't go for five years without a talk page message. --[[User:I dream of horses|I dream of horses]] [[Special:Contribs/I dream of horses|(Contribs)]] [[User talk:I dream of horses|(Talk)]] 20:52, 10 May 2022 (UTC)

:I use those templates regularly when I see lots of old warnings, and I think that it is a better solution han just blanking them out, but I also wonder if this whole idea will be moot if/when the WMF rolls out [https://meta.wikimedia.org/wiki/IP_Editing:_Privacy_Enhancement_and_Abuse_Mitigation IP masking]. [[User:Beeblebrox|Beeblebrox]] ([[User talk:Beeblebrox|talk]]) 21:10, 10 May 2022 (UTC)
:: Might it make more sense to wait for IP masking, give it a year or so, then '''delete''' every IP talk page? They're not going to be used any more. And even for users with the "unmask IP" right, the old unused IP talk pages will be less and less useful as months go on, given the dynamic nature of most IPs. [[User:Suffusion of Yellow|Suffusion of Yellow]] ([[User talk:Suffusion of Yellow|talk]]) 21:23, 10 May 2022 (UTC)
:::Deletion of things other than routine warnings risks deleting important information. Also, IP addresses aren't going away completely for a long while. Also, an old proposal thing maybe of interest: [[WP:OLDIP]]. -- [[user:zzuuzz|zzuuzz]] <sup>[[user_talk:zzuuzz|(talk)]]</sup> 21:35, 10 May 2022 (UTC)
:::Once masked identities are introduced, unregistered editors won't be looking at IP talk pages anymore but instead looking at their own talk pages. Thus the old IP talk pages won't have to be deleted to avoid confusion, and I think should be kept to preserve any discussions. [[User:Isaacl|isaacl]] ([[User talk:Isaacl|talk]]) 22:30, 10 May 2022 (UTC)
:::: That goes to the second reason for templating these pages. The discussions contain links—''millions'' of links. Links to articles, links to disambiguation pages, links to user pages and user talk pages, links to Wikipedia policy pages. Cleaning up incoming links across multiple namespaces for pages that tend to accumulate bad links is burdened by the clutter of links to decade-old messages from long-abandoned IP talk pages.  [[User:BD2412|<span style="background:gold">'''''BD2412'''''</span>]] [[User talk:BD2412|'''T''']] 23:26, 10 May 2022 (UTC)
:::::@[[User:BD2412|BD2412]] that sounds like an argument for ''clearing'' those pages - not really for why adding a million instances of a template is the best solution. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 23:32, 10 May 2022 (UTC)
:::::: An intentionally templated page is immediately distinct from a page blanked for reasons unknown. IP editors sometimes blank the warnings they receive; in my experience, they ''never'' template them. I do agree, by the way, that these can not be ''deleted'', as the edit history may contain useful information. [[User:BD2412|<span style="background:gold">'''''BD2412'''''</span>]] [[User talk:BD2412|'''T''']] 23:35, 10 May 2022 (UTC)
:I'm pretty sure we won't need to keep most of those messages. When it comes to schools, there's actually a high chance that the IP address will remain assigned to the same organisation. We frequently block schools for five years because they've shown that they can be that static. They can even get re-blocked without any new talk page messages. I can see a situation where a school comes fresh off one of these blocks to a freshly blanked talk page. I don't think that's necessarily a problem, but I also don't think it's fully recognised by this proposal. In an ideal world, we'd probably want to check when a block was made or expired. -- [[user:zzuuzz|zzuuzz]] <sup>[[user_talk:zzuuzz|(talk)]]</sup> 21:17, 10 May 2022 (UTC)
:: The proposal would exclude blocked pages from templating, but could be expanded to exclude pages that have come off a block within, say, the past three or four years. Ultimately, the vast bulk of pages we are dealing with are IPs that have actually never been blocked, but received a warning or a caution once or twice many years ago, and were never used again. That is pure clutter. I would certainly not be opposed to developing a protocol which starts with the most decrepit pages, and works up from there in a relatively slow and methodical fashion. [[User:BD2412|<span style="background:gold">'''''BD2412'''''</span>]] [[User talk:BD2412|'''T''']] 23:30, 10 May 2022 (UTC)
::As BD2412 says (who have been doing this semi-automated for some time), the proposed criteria is enough for vast majority of IPs. I can set the bot to ignore pages having {{tl|Schoolblock}} even when the IP is currently not blocked or check for block expiry date for pages having school block template. We can discuss these kind of cases and other technical implementation details when the BRFA is filed.  [[User:ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ|ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ]] ([[User talk:ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ|talk]]) 02:53, 11 May 2022 (UTC)

'''But when...''' were [[m:IP Editing: Privacy Enhancement and Abuse Mitigation|IP addresses going away altogether]]?—[[User:Bagumba|Bagumba]] ([[User talk:Bagumba|talk]]) 11:58, 31 May 2022 (UTC)
* Won't the changeover to [[meta:IP Editing: Privacy Enhancement and Abuse Mitigation|masked IP addresses]] make this task obsolete? Not sure it's worth it to edit millions of pages if the problem will be going away shortly. –[[User:Novem Linguae|<span style="color:limegreen">'''Novem Linguae'''</span>]] <small>([[User talk:Novem Linguae|talk]])</small> 10:18, 2 June 2022 (UTC)
*:It will not be going away ''shortly''. Beta testing for IP masking has only just begun since last week. Other large scale WMF initiavites like Reply links took 1 year to go from beta testing to full roll out. IP masking is a much more drastic change and will surely take much longer for full implementation. As discussed above, there are other benefits from this task, namely uncluttering WhatLinksHere and reducing Lint errors backlog, that will relevant post IP masking. [[User:ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ|ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ]] ([[User talk:ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ|talk]]) 11:37, 2 June 2022 (UTC)
{{closed rfc bottom}}

== Numbering system of archives ==
{{ hmbox
| class   = unresolved
| image   = Purple arrow down.svg
| message = Moved {{#if:|back&nbsp;}}from {{#ifexist:Wikipedia:Village pump (technical)|{{format linkr|Wikipedia:Village pump (technical)}}|<nowiki />Wikipedia:Village pump (technical)}}
| extra   =  {{#if:|<!-- Fake signature to fix archiving: [[user:example]] ([[user talk:example|talk]]) {{{3|}}} -->}}
}}
On May 14, I created a template protected edit request at [[Template talk:Archives#Template-protected edit request on 14 May 2022|Template talk:Archives]], which would allow specifying the starting number for archives, including /Archive 0. The request was applied after two hours by [[User:Terasail]].

On June 3 I opened another one, this time at [[Template talk:Talk header#Template-protected edit request on 3 June 2022|Template talk:Talk header]]. Although the first request was fulfilled, this one was met with a lot more discussion regarding the appropriateness of /Archive 0 and whether or not the edit that would allow such a use should be applied. I believe a continuation of such discussion should continue into a more centralized discussion, since it was suggested that the consensus was to not make the edit at {{tl|Talk header}}, and not whether a user should be able to number their archive as such.

In my opinion, I believe it is a reasonable request to allow /Archive 0, but the previous discussion at <nowiki>{{Talk header}}</nowiki> has also pointed out that starting from 0 can be confusing, unintuitive, and illogical. I totally agree that article talks should never have archives starting from zero, however,

'''Should we forbid numbering an archive as /Archive 0 in userspace?'''
{{numbered list|Yes.|No, but the templates should not support them at all.|No, but {{tl|Talk header}} should not support it. {{tl|Archives}} is fine.|No, and the templates should support this use.}}

Pinging users at the previous discussion: {{ping|Paine Ellsworth|FlightTime|Bsherr|Mathglot|Shibbolethink|Sdkb|p=}} <span style="font-family:Iosevka,monospace">0x[[User talk:0xDeadbeef|<span style="text-transform:uppercase;color:black">'''Deadbeef'''</span>]]</span> 10:32, 9 June 2022 (UTC)

:1, it can be confusing. [[User:EpicPupper|🐶&nbsp;EpicPupper]] <sup>(he/him &#124; [[User talk:EpicPupper|talk]])</sup> 21:24, 9 June 2022 (UTC)

'''3''': I don't think that it should be forbidden to start archiving from 0 in userspace (Other namespaces should start at 1), if you ask me you can count how you like in userspace. I added it to {{T|Archives}} since it seemed reasonable to me and it is a supported feature for {{T|Archive list}}. Indexing from 0 is pretty standard for computing and it didn't really raise any concern for me. {{T|Archives}} and {{T|Talk header}} serve different purposes and while {{T|Talk header}} is less appropriate for user talk, {{T|Archives}} is perfectly appropriate and the template itself is designed to offer the most customizability and I think it should be kept with the option to set it to a custom value while it is probably best to not add it as a feature to {{T|Talk header}} [[User:Terasail|<span style="color:#088; font-weight:800;">Terasail</span>]][[User talk:Terasail|<sup><span style="color:#000;">'''[✉️]'''</span></sup>]] 11:40, 9 June 2022 (UTC)

:Is this not more for VPR/VPP than technical though? [[User:Terasail|<span style="color:#088; font-weight:800;">Terasail</span>]][[User talk:Terasail|<sup><span style="color:#000;">'''[✉️]'''</span></sup>]] 11:49, 9 June 2022 (UTC)
::I'm not sure. Feel free to move it. <span style="font-family:Iosevka,monospace">0x[[User talk:0xDeadbeef|<span style="text-transform:uppercase;color:black">'''Deadbeef'''</span>]]</span> 11:52, 9 June 2022 (UTC)
:Did you mean {{tl|Talk header}}? <span style="font-family:Iosevka,monospace">0x[[User talk:0xDeadbeef|<span style="text-transform:uppercase;color:black">'''Deadbeef'''</span>]]</span> 11:53, 9 June 2022 (UTC)
::Ah yes I did [[User:Terasail|<span style="color:#088; font-weight:800;">Terasail</span>]][[User talk:Terasail|<sup><span style="color:#000;">'''[✉️]'''</span></sup>]] 11:54, 9 June 2022 (UTC)
*'''4''': I can see some reasonable use cases for "/Archive 0" and that in all talk namespaces. Sometimes I find an extant talk page with years old topics that no one responds to, that could've been much better dealt with at a parent talk page. So "let's redirect it to the parent talk page" is an obvious belief. But where do the existing topics go? One could just aggregate them all to "/Archive 0" of the parent talk page, if the parent talk page has already gotten an "/Archive 1" of its own. <span class="nowrap">&#8212;'''[[User:CX Zoom|CX Zoom]]'''[he/him]</span> <sup class="nowrap">([[User talk:CX Zoom|let's talk]] • {[[Special:Contributions/CX Zoom|C]]•[[User:CX Zoom/X|X]]})</sup> 13:37, 9 June 2022 (UTC)
*: Further, specifying a starting number like "Archive 2020" is okay too (in user talk namespaces), considering that people like me like categorising topics according to year. But maybe we're only discussing about "Archive 0" thing? <span class="nowrap">&#8212;'''[[User:CX Zoom|CX Zoom]]'''[he/him]</span> <sup class="nowrap">([[User talk:CX Zoom|let's talk]] • {[[Special:Contributions/CX Zoom|C]]•[[User:CX Zoom/X|X]]})</sup> 13:42, 9 June 2022 (UTC)
*::The use case of yearly archives such as yours would also be included here since they require a {{para|start}} parameter in order to be detected by the templates. [[User:Terasail|<span style="color:#088; font-weight:800;">Terasail</span>]][[User talk:Terasail|<sup><span style="color:#000;">'''[✉️]'''</span></sup>]] 14:35, 9 June 2022 (UTC)
*'''3'''. In my recent work with article talk pages I found that there were a few valid applications for a 0th archive. There were a few instances where a merge of two articles resulted in editors creating an "/Archive 0", or archives that were "0.1, 0.2, 0.3" and so on, so as to accomodate the discussions on the merged article's talk page. However, imho these limited applications were very few and far between. Since the Talk header template is widely used on article talk pages, but used far less on user talk pages, #3, which allows editors to use the Archives template with the {{para|start|0}} parameter, is sufficient. And there is also the ability to fork the Talk header template onto a user talk subpage, add the 0th archive facility and then transclude the subpage to one's user talk page. Just a thought. '''''[[User:Paine Ellsworth|<span style="font-size:92%;color:darkblue;font-family:Segoe Script">P.I.&nbsp;Ellsworth</span>]]'''''&thinsp;,&nbsp;[[Editor|<span style="color:black">ed.</span>]]&nbsp;[[User talk:Paine Ellsworth|<sup>put'r&nbsp;there</sup>]] <small>14:45, 9 June 2022 (UTC)</small>
*:@[[User:Paine Ellsworth|Paine Ellsworth]], may I propose allowing setting the parameter only in the "User talk" namespace? We could detect if someone is using the parameter and error out when used in other namespaces. <span style="font-family:Iosevka,monospace">0x[[User talk:0xDeadbeef|<span style="text-transform:uppercase;color:black">'''Deadbeef'''</span>]]</span> 07:30, 11 June 2022 (UTC)
*::That's a good question. I know that sensors can differentiate among namespaces like mainspace and userspace, however I'm not sure that they can differentiate one talk space from another. If they can, then I don't see why it couldn't work. Are you averse to putting the Talk header template on one of your user subpages and making it work that way? '''''[[User:Paine Ellsworth|<span style="font-size:92%;color:darkblue;font-family:Segoe Script">P.I.&nbsp;Ellsworth</span>]]'''''&thinsp;,&nbsp;[[Editor|<span style="color:black">ed.</span>]]&nbsp;[[User talk:Paine Ellsworth|<sup>put'r&nbsp;there</sup>]]&nbsp;<small>08:15, 11 June 2022 (UTC)</small>
*:::Maintaining a separate template creates too much burden. I don't intend to have a copy in my user subpage if it can be avoided as that would look like using Wikipedia as a web host to me. <span style="font-family:Iosevka,monospace">0x[[User talk:0xDeadbeef|<span style="text-transform:uppercase;color:black">'''Deadbeef'''</span>]]</span> 08:42, 11 June 2022 (UTC)
*::::Forgive me as I have no clue what kind of "burden" that would be. I don't use Talk header, however I do use other templates on subpages and transclude them to my talk page to customize their usage, so I guess it's just "different strokes for different folks". The only problem with forking a template to your userspace is that future improvements to the main template would be missed, and over time unless you keep up with it, the template in your userspace doesn't look the same as the main template. That can be a small problem I guess. '''''[[User:Paine Ellsworth|<span style="font-size:92%;color:darkblue;font-family:Segoe Script">P.I.&nbsp;Ellsworth</span>]]'''''&thinsp;,&nbsp;[[Editor|<span style="color:black">ed.</span>]]&nbsp;[[User talk:Paine Ellsworth|<sup>put'r&nbsp;there</sup>]]&nbsp;<small>12:45, 11 June 2022 (UTC)</small>
*'''No''', people are free to manage their talk archives any way they like. If there is popular demand for templates helping with certain types of archive organisations, our templates should be adapted as necessary. —[[User:Kusma|Kusma]] ([[User talk:Kusma|talk]]) 15:22, 9 June 2022 (UTC)
*'''No''', you can start from minus three if you want. Whether it's worth adapting templates to edge case user behavior is a separate question. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 19:42, 9 June 2022 (UTC)
*'''Wait, we are talking about userspace?''' As in one's talk page archives? I mean I archive my talk page myself by hand, and at one point I did number my archives as "1, 2, III, Delta, 6, Berlin". I have since grown up and now use a normal numbering system, but isn't that my business? If it's ''article'' talk pages you mean, I think that staring any sequence at zero is likely to throw people who aren't programmers? You don't often see "page 0" etc. Books use i, ii, iii before page 1 and maybe that could be used? [[User:Herostratus|Herostratus]] ([[User talk:Herostratus|talk]]) 21:23, 9 June 2022 (UTC)
*'''4''': User talk pages belong to the user, so they should for the most part do anything they want. Updating templates to support any starting value would not take that long, and it might as well be done. What would the harm be? [[User:Sungodtemple|Sungodtemple]] ([[User talk:Sungodtemple|talk]]) 00:52, 10 June 2022 (UTC)
**That "harm" might be determined by usage. The Talk header template is widely used on article talk pages, but I've only seldom seen it used on user talk pages. So to me it makes sense to not give that template 0th archive sensing capability. So again, either users can transclude the Archives template, which already has 0th archive sensing, or they can fork the Talk header template to their user talk subpage, give it 0th sensing, and then transclude the subpage to their talk page. No harm, no foul. '''''[[User:Paine Ellsworth|<span style="font-size:92%;color:darkblue;font-family:Segoe Script">P.I.&nbsp;Ellsworth</span>]]'''''&thinsp;,&nbsp;[[Editor|<span style="color:black">ed.</span>]]&nbsp;[[User talk:Paine Ellsworth|<sup>put'r&nbsp;there</sup>]]&nbsp;<small>02:48, 10 June 2022 (UTC)</small>
*'''Uhhhh''' as to the question of "Should we forbid numbering an archive as /Archive 0 in userspace", '''no''' - who cares They can call their archives whatever they want as long at it isn't blatantly disruptive or obviously trying to hide revision histories, if they want to use User_talk:X/Archive_Jan-Mar_1999, */Archive 0, or */Some_of_my_old_messages - I don't care.  As far as the hidden question: should we maintain templates for edge cases? '''probably not'''. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 15:42, 11 June 2022 (UTC)

== Make [[Main Page]] responsive by replacing tables ==
{{atop|header=Passed|result=There is [[WP:SNOW|clear]] consensus to adopt the proposal. {{nac}} <span style="color:#AAA"><small>&#123;{u&#124;</small><span style="border-radius:9em;padding:0 5px;background:#088">[[User:Sdkb|<span style="color:#FFF">'''Sdkb'''</span>]]</span><small>}&#125;</small></span> <sup>[[User talk:Sdkb|'''talk''']]</sup> 16:10, 11 June 2022 (UTC)}}
The [[Main Page]] [https://en.wikipedia.org/w/index.php?title=Main_Page&action=edit uses tables] in order to split the blue and green boxes into columns and to split Today's Featured Picture with its description text. Because tables are used, when the screen width of the page is small, the columns do not collapse to become one column '''on non-responsive skins like Vector'''. This is a proposal to switch the tables to use CSS flex so that they are responsive and do collapse. The resulting page and code can be viewed [[User:Izno/Sandbox/MP2|here]].

''Ping to those who participated in the [[Talk:Main Page/Archive 203#Use Flex columns instead of table|original discussion]]:'' @[[User:Ravenpuff|Ravenpuff]] @[[User:Stephen|Stephen]] @[[User:Izno|Izno]] @[[User:Xaosflux|Xaosflux]] [[User:Lectrician1|Lectrician1]] ([[User talk:Lectrician1|talk]]) 01:54, 2 June 2022 (UTC)
* I support this change. I have personally found the width listed (875px) to be a reasonable break point. --[[User:Izno|Izno]] ([[User talk:Izno|talk]]) 21:54, 2 June 2022 (UTC)
*'''Support''' (Isn't this a web standard by now?) [[User:Levivich|Levivich]] 01:30, 3 June 2022 (UTC)
*:Using tables for layout was obsolete a long time ago... But it's been a challenge to get a consensus to change. (The silver lining is that by now, all supported browsers support the latest CSS layout models.) [[User:Isaacl|isaacl]] ([[User talk:Isaacl|talk]]) 02:15, 3 June 2022 (UTC) 
*::As far as I can remember, every attempt to get rid of tables has been part of a larger attempt to change 37 different things on the Main Page all at once (if not from the beginning, then by having people say "well, while, we're doing this, let's do ____, too"). If this proposal is limited to JUST changing away from tables and making the final appearance as nearly identical as possible, it might succeed. --[[User:Khajidha]] ([[User talk:Khajidha|talk]]) ([[Special:Contributions/Khajidha|contributions]]) 11:56, 7 June 2022 (UTC)
*:::In recognition of the difficulty in getting support for new visible changes, there have been proposals to modernize the implementation without affecting content/design layout changes on regular width screens. The rise of users with narrow screens on mobile devices, though, has given a concrete reason to make such changes. See the discussions linked to by Izno. [[User:Isaacl|isaacl]] ([[User talk:Isaacl|talk]]) 15:48, 7 June 2022 (UTC)
*::::If it makes no visible difference on regular width screens and only does this very specific thing on narrow screens, I would support it. Just don't try to go into the "let's add today's featured portal over here, and a link to requests for adminship here, and a ZX Spectrum emulator over there, and a random number generator over here, and.....". --[[User:Khajidha]] ([[User talk:Khajidha|talk]]) ([[Special:Contributions/Khajidha|contributions]]) 19:00, 7 June 2022 (UTC)
*'''Support''', this makes a great deal of sense and we should expect and design the site to be viewed by users on screens of all sizes. [[User:Seraphimblade|Seraphimblade]] <small><sup>[[User talk:Seraphimblade|Talk to me]]</sup></small> 02:07, 3 June 2022 (UTC)
* I support having a responsive design that can adapt to different screen display widths. [[User:Isaacl|isaacl]] ([[User talk:Isaacl|talk]]) 02:15, 3 June 2022 (UTC)
*'''Support''' [[User:EpicPupper|🐶&nbsp;EpicPupper]] <sup>(he/him &#124; [[User talk:EpicPupper|talk]])</sup> 02:32, 3 June 2022 (UTC)
*'''Support''' responsive main page is brilliant. This should have been done eons ago. – [[User:SD0001|<span style="font-weight: bold; color: #C30">SD0001</span>]] ([[User talk:SD0001|talk]]) 12:02, 3 June 2022 (UTC)
*'''Support''' obviously [[User:MichaelMaggs|MichaelMaggs]] ([[User talk:MichaelMaggs|talk]]) 12:35, 3 June 2022 (UTC){{pb
}}{{multiple image
 | image1 = 
 | alt1 = Screenshot of the main page with the Monobook skin
 | caption1=Monobook
 | image2 = 
 | alt2 = Screenshot of the main page with the Vector skin
 | caption2 = Vector
}}
*'''Support''', clear improvement for those who don't log in or can't use superior skins like Monobook. —[[User:Kusma|Kusma]] ([[User talk:Kusma|talk]]) 12:50, 5 June 2022 (UTC)
*:It is ironic that an 18 year old skin is more responsive than the current default, at least in this regard. &ndash;&#8239;[[User:Joe Roe|Joe]]&nbsp;<small>([[User talk:Joe Roe|talk]])</small> 16:55, 5 June 2022 (UTC)
*::Regarding Vector particularly, [https://phabricator.wikimedia.org/phame/post/view/286/should_vector_be_responsive/ this recent blog post by a WMF engineer] may be of interest. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 00:40, 6 June 2022 (UTC)
*'''Support''', long time coming. Good usability is good. -- [[User:Visviva|Visviva]] ([[User talk:Visviva|talk]]) 16:33, 5 June 2022 (UTC)
*'''Support'''. Damn, really? I knew the main page was overdue a modernisation, but not 15 years overdue. And as a broader point, I don't think stylistic issues like this should be subject to local project consensus. We're encyclopaedia editors, not web developers or designers. The WMF and MW devs should have a free hand to make incremental upgrades to prominent pages like this. &ndash;&#8239;[[User:Joe Roe|Joe]]&nbsp;<small>([[User talk:Joe Roe|talk]])</small> 16:44, 5 June 2022 (UTC)
*:The main page design isn't fixed by the MediaWiki software, which makes sense given the wide variety of installations for which it can be used. While I agree it would be better to delegate implementation details to technical experts (be they volunteers or paid staff), for better or worse, there tends to be a feedback loop between implementation and visible design features, which I believe has fueled a reluctance of some vocal members of the community to agree to defer. [[User:Isaacl|isaacl]] ([[User talk:Isaacl|talk]]) 20:31, 5 June 2022 (UTC)
*::I mean the implementation and what it looks like. All we should be concerned with is the content. &ndash;&#8239;[[User:Joe Roe|Joe]]&nbsp;<small>([[User talk:Joe Roe|talk]])</small> 21:53, 5 June 2022 (UTC)
*:::Well, so far this discussion has been refreshingly free of "it's not broken for me, so why fix it" comments. Perhaps the increasing number of mobile device users has helped overcome community reticence to change. [[User:Isaacl|isaacl]] ([[User talk:Isaacl|talk]]) 22:12, 5 June 2022 (UTC)
*::::Well, in this case it is more that this works pretty well everywhere, except for Vector - and the skin maintainers aren't going to fix it on their side so we may as well. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 22:23, 5 June 2022 (UTC)
*:::::As I recall, past proposals would have worked well everywhere also. I think there's a greater understanding that a design that better supports narrow screens is of ever-increasing importance. [[User:Isaacl|isaacl]] ([[User talk:Isaacl|talk]]) 00:33, 6 June 2022 (UTC)
*:The reason this discussion is occurring is because there have been at least two attempts to add this main page responsive behavior for Vector without an active consensus and at least one user complaint. You can see the complaints in archives [[Talk:Main Page/Archive 192#Main page is broken|192]] and [[Talk:Main Page/Archive 198#Undiscussed change to display of the Main Page|198]]. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 00:37, 6 June 2022 (UTC)
*::smh we've been discussing this for four years. This is how we end up being decades behind the rest of the web. Thank you, {{u|Lectrician1}}, for bringing this home. [[User:Levivich|Levivich]] 03:47, 6 June 2022 (UTC)
*'''Support''' a responsive design. [[User:Gonnym|Gonnym]] ([[User talk:Gonnym|talk]]) 17:07, 5 June 2022 (UTC)
*'''Support''' an update is clearly required. [[User:Robertsky|– robertsky]] ([[User talk:Robertsky|talk]]) 17:32, 5 June 2022 (UTC)
*'''Support''' - while I use Monobook exclusively (due to finding Vector butt-ugly) I'm always on board for making pages that newer editors/readers are very likely to see more readable.  —[[User:Jéské Couriano|<i style="color: #1E90FF;">Jéské Couriano</i>]] [[User talk:Jéské Couriano|<span style="color: #228B22">v^&lowbar;^v</span>]] <sup><small>[[Special:Contributions/Jéské Couriano|a little blue Bori]]</small></sup> 21:49, 5 June 2022 (UTC)
[[File:Izno's responsive homepage screenshot.png|right|thumb]]
*'''Support'''.  But, I've got a question.  When I view the desktop version of Izno's sandbox on my phone, it's still in two-column mode.  When I resize a window on my real desktop to the same width, it does the responsive thing and goes into single column mode.  What's happening here?  -- [[User:RoySmith|RoySmith]] [[User Talk:RoySmith|(talk)]] 01:06, 6 June 2022 (UTC)
*:@[[User:RoySmith|RoySmith]] are you viewing it using mobile frontend like most phones would use (en.m.wikipedia.org)? Are you setting your phone to use "desktop" mode, and if so - are you logged in and have a skin selected? The link above is good for seeing "Is how '''I''' look at the mainpage normally going to be OK" - but if you want to see a difference you really need to be using the only main condition it matters, legacy vector - such as loading the sanbox [https://en.wikipedia.org/wiki/User:Izno/Sandbox/MP2?useskin=vector with this link]. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 01:11, 6 June 2022 (UTC)
*::Yup, desktop mode (as seen in the URL bar of the screenshot), logged in as RoySmith-Mobile, Vector legacy selected in that account's preferences. -- [[User:RoySmith|RoySmith]] [[User Talk:RoySmith|(talk)]] 02:52, 6 June 2022 (UTC)
*:Basically, the operating system resolution of smartphones is large enough these days such that the check for "greater than 875 px" returns true. The blog post I linked above in re to Joe explains some of it. There isn't really a way to fix that issue besides the change suggested in that blog post (I guess if you can find the 'zoom' button on your smartphone's browser, that would 'fix' it, but I'd have to look hard for the one on Firefox). [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 01:56, 6 June 2022 (UTC)
*::I'm not (by any means) an expert on CSS, but isn't that what using em instead of px is supposed to solve? -- [[User:RoySmith|RoySmith]] [[User Talk:RoySmith|(talk)]] 03:00, 6 June 2022 (UTC)
*:::I am pretty sure not, since ems are still based on some relation to a root font-size. Your browser is the one that decides to display this size of text on mobile (Firefox does the same in Vector on mobile, so you're not alone). Either (mobile) browsers need to improve their understanding of the default appearance (or attempted appearance) of web pages (e.g. heuristics based on included CSS or something) or Vector needs to have the change suggested made. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 04:28, 6 June 2022 (UTC)
*::::But isn't the whole idea to make it relative to the font size?  Instead of "go into 1-column mode on windows less than 875px", it's "go into 1-column mode on windows less than 70 typical character widths?"  I tried it in [[User:RoySmith/Sandbox/MP2]].  Seems to do the right thing on both my desktop and my phone. -- [[User:RoySmith|RoySmith]] [[User Talk:RoySmith|(talk)]] 13:34, 7 June 2022 (UTC)
*:::::I've learned something. :D [https://adamwathan.me/dont-use-em-for-media-queries/ Safari < 15] is bugged when text zoomed, which is [https://steve-adder.toolforge.org/?wanted=Mobile+Safari&wanted=Mobile+Safari+UI%2FWKWebView&wanted=Safari&start=1&end=14 4%] of our views, but apparently [https://zellwk.com/blog/media-query-units/ Safari at some age is broken with px media queries also].
*:::::I can take a look at this. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 01:45, 8 June 2022 (UTC)
*:::::Ok, so your version doesn't work the way you think it does. All that happened is that you chose a wider (70em) break point. 55em, which is about 860px in Vector (and close to it in others), displays the same behavior as a breakpoint of 875px. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 02:09, 8 June 2022 (UTC)
*'''Support'''. Uncontroversial modernization. [[User:MarioGom|MarioGom]] ([[User talk:MarioGom|talk]]) 07:38, 10 June 2022 (UTC)
*'''Support''' - baby steps for the front page but progress is progress. [[User:Retswerb|Retswerb]] ([[User talk:Retswerb|talk]]) 03:38, 11 June 2022 (UTC)
{{abot}}

== Lots and lots and lots of hidden text ==

Wikipedia has countless articles for which some text was added at some point, and then contested in some way not by being deleted, but by being ''hidden'', often with a note (also hidden) explaining the reasoning for which the text was hidden (e.g., 'I don't think the source supports this' or 'this is off topic'). I find this to be a very bad practice, since this hidden text seems to be quickly forgotten about, and just stays on the page indefinitely. We also have metric tons of hidden links to deleted images, equally useless. I propose that we '''document''' all the pages that have blocks of text that were initially visible but were made hidden, and '''make a project''' of moving those from the articles to their talk pages for discussion. I think some of this can probably be done by a bot, but unfortunately only a small proportion, due to the potential for incorrectly moving appropriate uses of hidden text. However, it needs to be done, one way or another. [[User:BD2412|<span style="background:gold">'''''BD2412'''''</span>]] [[User talk:BD2412|'''T''']] 01:24, 14 May 2022 (UTC)
:I agree that it's clearly bad practice just to hide questionable text.  As i recall, i used to remove it and put it on the talk page for discussion if i questioned some sentence(s); at some point i stopped, but perhaps i'll start again.  How can we document such pages and text, {{u|BD2412}}?  Is there some auto- or semi-automated way?  If so, i'll happily take some of this on.  Happy days ~ '''[[User:LindsayH|Lindsay]]'''<sup>'''[[User_talk:LindsayH|H]]'''[[User_talk:LindsayH|ello]]</sup> 08:05, 14 May 2022 (UTC)
:FYI [https://en.wikipedia.org/w/index.php?sort=random&search=insource%3A%2F%5C%3C%21--%2F&title=Special:Search&profile=advanced&fulltext=1&ns0=1 here] is a (somewhat slow) regex query that will give a random sample of mainspace articles with HTML comments. I checked 20 and counted 7 that seemed to contain removed text, with the other 13 being legitimate annotations/documentation. I don't see how any automated process could separate these two categories. Even if the content of the comment looks like wikitext, it might just be example syntax (you see this a lot in infoboxes - e.g. <code><nowiki>| closed_date = <!-- {{End date|YYYY|MM|DD|df=y}} --></nowiki></code>). [[User:Colin M|Colin M]] ([[User talk:Colin M|talk]]) 15:54, 14 May 2022 (UTC)
:I think some hidden text is useful in preventing certain good-faith edits that are a hindrance. As an example that I just came across, [[Alejandro Mayorkas]] has hidden text in the political party parameter of the infobox indicating that a source would be needed before people reflexively add the party of the president who nominated him. I do not understand why deleted images have been left in articles with hidden text, those should be removed. &ndash;&nbsp;[[User:Muboshgu|Muboshgu]]&nbsp;([[User talk:Muboshgu#top|talk]]) 15:56, 14 May 2022 (UTC)
:I would support a proposal that would take the hidden test to the talk page and annotate with sufficient details e.g. comment date, commenting editor. [[User:Ktin|Ktin]] ([[User talk:Ktin|talk]]) 19:18, 14 May 2022 (UTC)
:: I have some thoughts on these. First, I think the hidden text on removed images are there to remind people that there ''was'' an image there, and perhaps a new one could be added at that location, but I would be glad to see all of those messages flat-out deleted, and I think that could be done by a bot because they have a repeated format. Editors can see for themselves where an image would be useful in an article, and what good is the notice of removal after years have passed? As to the hidden text reflecting an editing dispute, that is more complicated, but I think that we can generate a list of most likely instances of text that should be removed. Something that has sat in the article for several years, is lengthier than typical example syntax, and contains Wiki links and formatting, would be a strong candidate to check first. [[User:BD2412|<span style="background:gold">'''''BD2412'''''</span>]] [[User talk:BD2412|'''T''']] 19:39, 14 May 2022 (UTC)
:A related [[anti-pattern]] is the unterminated or incorrectly terminated comment.  This is picked up by report 5 in [[WP:WikiProject Check Wikipedia/List of errors]], which currently lists 600 offenders.  It does pick up the case when correctly terminated comments follow later, e.g. <code><nowiki>&lt;!-- Badly terminated comment > Smith is an [[actor]] who did some [[film]]s. &lt;!-- Valid comment --></nowiki></code>, which quietly hides the intervening wikitext.  [[User:Certes|Certes]] ([[User talk:Certes|talk]]) 19:56, 14 May 2022 (UTC)
:: Yes, I think we need to go after all of these issues. [[User:BD2412|<span style="background:gold">'''''BD2412'''''</span>]] [[User talk:BD2412|'''T''']] 23:51, 14 May 2022 (UTC)
::: Yeah I agree with OP's points. My one caveat is that I personally have not seen this, at least not very much. That's just me tho. Yes move to talk page is correct fix IMO. Support a well-written bot or whatever else would help. [[User:Herostratus|Herostratus]] ([[User talk:Herostratus|talk]]) 22:24, 23 May 2022 (UTC)
:::: I just found [https://en.wikipedia.org/w/index.php?diff=560702747&oldid=560698097&title=Fuchsia this example] today. The text in this case is a reference that purportedly has a broken link, which was hidden with a note saying that the link appears to broken. This hidden text had been sitting in the article for nine years (until today). I probably see more of this than the average editor because I sweep for ref tag errors, which include those in hidden text. [[User:BD2412|<span style="background:gold">'''''BD2412'''''</span>]] [[User talk:BD2412|'''T''']] 23:47, 27 May 2022 (UTC)
:I don't recall having moved article text into html comments in recent years, but I don't see a reason why this should be considered a bad practice. After all, when you simply remove text, you're effectively hiding it in the page history, and when you move it to the talk page, you're hiding it from view of anyone except those looking at the talk. In fact, putting that text in an html comment makes it more visible to editors who engage with the relevant bits of the article. I don't think there's a need for any project here, and moving text out of (or into) html comments is best left to the regular, article-specific, editorial activity. – Uanfala ([[User talk:Uanfala|talk]]) 11:37, 31 May 2022 (UTC)
::If there is an issue with the text, it should be brought up in the talk page, not hidden in the article itself where no one will notice unless they edit the same exact section. This is extremely bad practice. [[User:Gonnym|Gonnym]] ([[User talk:Gonnym|talk]]) 11:53, 31 May 2022 (UTC)
:::It seems that what you refer to as "extremely bad practice" is an instance of good targeting: a commented out passage will always reach the people it's aimed at: those editing the relevant section, whereas a talk page post may initially be better visible to a larger audience, but has less chance of getting noticed by the people it's intended for (I don't think many of us have the habit of systematically scouring the talk page and its archives before making an edit to an article). – Uanfala ([[User talk:Uanfala|talk]]) 12:21, 31 May 2022 (UTC)
::::The article is not a place to discuss anything. If you comment text out, what will the next person do? Reply there? If you have concerns, bring it up in the talk page. [[User:Gonnym|Gonnym]] ([[User talk:Gonnym|talk]]) 12:26, 31 May 2022 (UTC)
:::::Of course that's not the place for threaded discussions. But if you use an html comment, you're not starting such a discussion: you're just flagging up an issue and leaving interested others the opportunity to resolve it (by e.g. uncommenting and correcting, or removing altogether). I'm not saying this is the best method, but it certainly has its uses. If we're going to start bulk moving commented out text to the talk page, the net result will be the substitution of one (at worst) small problem with another (likely bigger) one. – Uanfala ([[User talk:Uanfala|talk]]) 12:35, 31 May 2022 (UTC)
:::::: {{re|Uanfala}} There are instances of blocks of text that have been hidden for ten or twelve ''years'' or more, apparently completely forgotten, while the rest of the article has likely completely changed around them. [[User:BD2412|<span style="background:gold">'''''BD2412'''''</span>]] [[User talk:BD2412|'''T''']] 01:11, 5 June 2022 (UTC)
:::::::To the best of my knowledge, this has ''never'' been a standard, accepted practice for editing. On the occasions when I have seen it used I have simply removed the content, it's just clutter in the edit window at that point, and article histories are a thing for anyone who wants to see what an article used to say, but no longer does. [[User:Beeblebrox|Beeblebrox]] ([[User talk:Beeblebrox|talk]]) 02:47, 5 June 2022 (UTC)
:A lot of hidden things are useful (comments about likely pitfalls, for example to warn people against linking a non-notable person to someone else with the same name). That kind of hidden text should stay there indefinitely (also, editnotices don't work everywhere, so hidden text must be used sometimes). I don't mind a cleanup project going through hidden text, but it needs a lot of human triage whether hidden text should (a) be removed outright (b) be put on the talk page or (c) stay there forever. —[[User:Kusma|Kusma]] ([[User talk:Kusma|talk]]) 12:47, 5 June 2022 (UTC)
::[[User:Δ]] has [https://betacommand-dev.toolforge.org/reports/hidden_comments/ generated a report] indicating the total volume of just those hidden text blocks that are over 1,000 characters. Although it is a bit difficult to parse, suffice to say that runs to about 40,000K. [[User:BD2412|<span style="background:gold">'''''BD2412'''''</span>]] [[User talk:BD2412|'''T''']] 06:03, 6 June 2022 (UTC)
:As to the points on standard practice using hidden text to leave notes in the article has been part of the [[Help:Cheatsheet|cheatsheet]] for nearly a [https://en.wikipedia.org/w/index.php?title=Help:Cheatsheet&oldid=524549111 decade]. I don't see a reason to remove these en masse, but a tracking category could be useful. - LCU '''[[User:ActivelyDisinterested|ActivelyDisinterested]]''' ''∆[[User talk:ActivelyDisinterested|transmissions]]∆'' °[[Special:Contributions/ActivelyDisinterested|co-ords]]° 16:18, 11 June 2022 (UTC)
:: Beyond the sheer volume of instances, there is no consistency between them. There are instances of hidden text that I have seen where a few sentences or a few paragraphs are hidden without any note in the text or explanation in the edit summary, or where a note in the text is itself ambiguous or unhelpful. We have instances of that type and many others that have been sitting in article wikitext for over a decade. [[User:BD2412|<span style="background:gold">'''''BD2412'''''</span>]] [[User talk:BD2412|'''T''']] 18:42, 11 June 2022 (UTC)
*First step: sweep for hidden text and add a template to the talk page header that says "this article has hidden text", to alert editors. Then go through them and remove/move the text. We should also document in a PAG somewhere that hidden text should not be used as a way to communicate. [[User:Levivich|Levivich]] 18:55, 11 June 2022 (UTC)
*: A lot of my content space work has been in an area of history which spawned a number of pop culture artefacts, and as such I regularly see hidden text in the form of "please do not introduce additional information about this person's role in video games" or similar. See for example [[Lady Zhen#In popular culture]]. I think a hidden text edit notice exactly where a good faith editor is likely to introduce or change material against consensus is the most perfect way to communicate, rather than a years-old discussion centralised on a wikiproject or whatever. Good targeting, per users Uanfala and Kusma above. I don't think the practice necessarily needs to be discouraged in all cases. [[User:Folly Mox|Folly Mox]] ([[User talk:Folly Mox|talk]]) 19:02, 11 June 2022 (UTC)
*:: I think what we need to aim for is removing hidden ''content''. If there is a sentence or a paragraph or a reference that is purely article content with a note questioning its validity or utility, that should not be kept hidden perpetually. [[User:BD2412|<span style="background:gold">'''''BD2412'''''</span>]] [[User talk:BD2412|'''T''']] 19:04, 11 June 2022 (UTC)
*:::Yes, hidden notes are a great way to highlight things where good faith editors are likely to make changes that aren't desired (not just because of consensus but also because something seems counter-intuitive for some reason, etc). However they should not be used to hide content - that should either be removed completely, moved to the talk page or tagged as appropriate to the situation. Sometimes noting what content has been removed (and why) can be useful but not the content itself. The trick is distinguishing the two. [[User:Thryduulf|Thryduulf]] ([[User talk:Thryduulf|talk]]) 19:29, 11 June 2022 (UTC)

{{Clear}}
== RFC: Move [[Main Page]] to [[Wikipedia:Main Page]] ==
{{archive top|Nope. {{ping|Lynvir}} please research the many, many, discussions that have occurred on the topic first; including topics from [[Wikipedia:Perennial proposals#Move the Main Page to another namespace, such as "Wikipedia:" or "Portal:"]]. Then, if you are extremely serious, workshop this up somewhere first. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 10:07, 21 June 2022 (UTC)}}
Should we make the homepage [[Wikipedia:Main Page]] rather than mainspace? It will be nice as minspace is for encyclopedic content only and the English Wiktionnary has already done so. [[User:Lynvir|Lynvir]] ([[User talk:Lynvir|talk]]) 09:47, 21 June 2022 (UTC)

=== Survey ===

=== Discussion ===
{{archive bottom}}

== RFC: Shut down [[Wikipedia:Administrative action review]] ==
{{atop|IAR Involved Close - no one wants this RfC. Those of us who think it was a bad idea are content to see if it actually takes off or if it dies. Those who thought it was a good idea don't want it marked historical yet and have an issue with the format of this RfC. The only thing everyone seems to agree on about this is that having an RfC about whether or not to mark it historical is something we don't need now. When all the interested parties agree this isn't a formal discussion worth having at this point; thats when you stop the discussion. I've already voted, so if anyone other than the IP who started this wants to revert me, go ahead, but my reading of the consensus is that there is nothing controversial about closing this now. [[User:TonyBallioni|TonyBallioni]] ([[User talk:TonyBallioni|talk]]) 19:52, 12 June 2022 (UTC)}}
=== Background (Administrative action review)===
[[Wikipedia:Administrative action review]] (XRV) was created following [[Wikipedia:Requests for adminship/2021 review/Proposals#Passed: 6C Administrative action review]]. To start with, this board has nothing do with improving RFA, so many people who were not interested in RFA did not see the original proposal, as mentioned by [[User:Risker]] and [[User:TonyBallioni]] in the discussion section of the proposal. 6 months after creation and long discussions on the talk page later, the scope of this page is still unclear. It has hardly ever been used and still has "This is a newly created process and norms are still being established." on top. Many users have opined that XRV is a duplicate to [[WP:AN]] and its inactivity supports this notion. XRV has not received edits for the last 3 months except for test edits. There is nothing that XRV can do that cannot already be done at [[WP:AN]] with input from a wider audience. XRV is clearly a failed experiment and I propose that it be formally deprecated and marked as historical. There is already too much bureaucracy in wikipedia, pointing users to an unused and redundant process is unhelpful. [[Special:Contributions/2409:4071:D9A:88D6:11AA:2ACF:EA4C:C433|2409:4071:D9A:88D6:11AA:2ACF:EA4C:C433]] ([[User talk:2409:4071:D9A:88D6:11AA:2ACF:EA4C:C433|talk]]) 09:18, 11 June 2022 (UTC)

=== Support (Administrative action review) ===
*'''Support''' I don't think XRV has done anything to support its founding as a solution to improve RFA's; it's birth from [[Wikipedia:Requests_for_adminship/2021_review/Proposals#Passed:_6C_Administrative_action_review|this RfC]] predicted that {{tq|if it turns out to be useless it will naturally die}}, and it so it has. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 11:49, 11 June 2022 (UTC)
*Put me here if this RfC continues — it failed because it is duplicative and the only reason to use it is to prove a point that it is needed. That being said, I agree with {{u|Kudpung}} below that the better outcome would just be to let it wither away in obscurity, so I don't really oppose a procedural closure of this RfC. Actually think a procedural closure might do more to speed up the death of it since there will be less fighting over whether to save it or not. [[User:TonyBallioni|TonyBallioni]] ([[User talk:TonyBallioni|talk]]) 19:04, 12 June 2022 (UTC)

=== Oppose (Administrative action review) ===
*'''Oppose and malformed RFC'''   The RFC is non-neutral.  The "background" isn't background, it is arguments for a certain outcome.   There is a good place for the process in Wikpedia.   It needs to be tweaked.  Less focused on "use of tools", more focused on actions (including/especially non-severe course corrections, and including mere mis-use of the imprimatur) of admins where fellow admins consider it impolite to intervene.  <b style="color: #0000cc;">''North8000''</b> ([[User talk:North8000#top|talk]]) 12:00, 11 June 2022 (UTC)
*:If you think there is a good place for a process like that on Wikipedia, then I suggest your time would be much better spent getting consensus for a new venue with that explicit purpose, rather than trying to mould this one into a vision that is completely at odds with what some others want to see the place become. [[User:Thryduulf|Thryduulf]] ([[User talk:Thryduulf|talk]]) 12:13, 11 June 2022 (UTC)
*'''Oppose''': My position is that AAR is a good idea and we should use it.—[[User:S Marshall|<b style="font-family: Verdana; color: Maroon;">S&nbsp;Marshall</b>]]&nbsp;<small>[[User talk:S Marshall|T]]/[[Special:Contributions/S Marshall|C]]</small> 12:14, 12 June 2022 (UTC)
*'''Procedural close''', RFC consists entirely of argument.--'''[[User:WaltCip|WaltCip]]'''-''<small>([[User talk:WaltCip|talk]])</small>'' 14:43, 12 June 2022 (UTC)
*'''Oppose''': it is too soon to mark it as historical. — [[User:Bilorv|Bilorv]] ('''[[User talk:Bilorv|<span style="color:purple">talk</span>]]''') 14:53, 12 June 2022 (UTC)
*'''Procedural close''' send this proposal through idea lab so that people can jointly work on it, then bring it back. Major issues with the proposal atm. [[User:Curbon7|Curbon7]] ([[User talk:Curbon7|talk]]) 15:33, 12 June 2022 (UTC)
*:@[[User:Curbon7|Curbon7]] I'm curious what issues you see with this proposal that could be workshopped? Either the proposal is successful and Administrative action review is deprecated and marked as historical or the proposal is unsuccessful and it isn't. [[User:Thryduulf|Thryduulf]] ([[User talk:Thryduulf|talk]]) 16:21, 12 June 2022 (UTC)
*'''Procedural close''' per the others and my (now reverted) closing statement. [[User:Levivich|Levivich]] 16:13, 12 June 2022 (UTC)

=== Neutral (Administrative action review) ===
*(see also my extended comment in the discussion section) It's currently harmless in it's nominally experimental but practically completely inactive state. My preference is just to leave it like that until it completely fades into obscurity such that placing a historical tag is completely uncontroversial, but equally actively marking it deprecated now is not going to harm anyone or anything so I've got no reason to oppose that. [[User:Thryduulf|Thryduulf]] ([[User talk:Thryduulf|talk]]) 12:06, 11 June 2022 (UTC)

*(see my  comment in the discussion section) For once I find myself concurring 100% with {{u|Thryduulf}}. [[User:Kudpung|Kudpung กุดผึ้ง]] ([[User talk:Kudpung|talk]]) 12:26, 11 June 2022 (UTC)

* I see no useful purpose in doing anything about it at this point, so find myself in agreement with Thryduulf and Kudpung for now. However I am open to logical reasoning and rational persuasion based on evidence. Cheers, &middot; &middot; &middot; [[User:Pbsouthwood|Peter Southwood]] [[User talk:Pbsouthwood|<sup>(talk)</sup>]]: 07:30, 12 June 2022 (UTC)

=== Discussion (Administrative action review) ===
* The "background" here is misleading and inaccurate and would be more appropriate as a comment. Yes, some people didn't think that XRV wasn't sufficiently related to RFA or too similar to AN. They're reasonable points, even if I disagree with them, but ultimately they had their say, along with those with other objections, and the RfC still found a comfortable consensus with something like 70 participants. After it was closed, we implemented the basic process proposed in the RfC and quickly started building momentum with some [[Wikipedia:Administrative_action_review/Archive_1|initial threads]] and a [[Wikipedia_talk:Administrative_action_review/Archive_1#XRV_structure/implementation|healthy set of discussions]] on how to refine the process. What happened then was that a small group of power users, unaccustomed to not getting their way, swooped down to try and [[Wikipedia:Miscellany_for_deletion/Wikipedia:Administrative_action_review|delete the page]], then when that failed, obstruct it by [[Wikipedia_talk:Administrative_action_review/Archive_2#What_is_the_problem?|insisting we needed a second RfC confirming the first]] before it could be used, put [https://en.wikipedia.org/w/index.php?title=Wikipedia:Administrative_action_review/header&diff=1069191036&oldid=1068179121 tags on the page telling people not to use it], and most damagingly of all, [[Wikipedia_talk:Administrative_action_review/Archive_2#Temporary_removal_of_links_to_this_page_from_directions_at_AN/ANI,_WP:ADMIN,_etc.|remove all incoming links to it]] from other project pages. With that concerted attempt to smother the process before it got started, ''coming from the very people XRV was supposed to make more accountability to the community'', it's not surprising that it became inactive shortly thereafter. So mark it as historical as a description of the current state of affairs if you like, but that doesn't change the fact that a) XRV had a strong consensus behind it which is now unrealised because of the objections of a small cohort and b) there remains a need for it, as seen by regular confusion about [[Wikipedia_talk:New_pages_patrol/Reviewers#Autopatrolled_editors_creating_unsourced_pages|where the used of PERMs can be reviewed]], and the continuing stream of ANI threads and ArbCom case requests about administrator misconduct that could have been resolved with early intervention at a less fraught venue. &ndash;&#8239;[[User:Joe Roe|Joe]]&nbsp;<small>([[User talk:Joe Roe|talk]])</small> 10:47, 11 June 2022 (UTC)
*:If you are going to give diffs of supposed obstructionism, it is only fair to those users that you ping them. Courtesy pings to users mentioned above {{Ping|Spartaz|Jehochman|Bbb23|Floquenbeam|Beeblebrox|Thryduulf|Kudpung|Isaacl}} [[Special:Contributions/2409:4071:4D0B:373:FC64:EA32:3697:9D16|2409:4071:4D0B:373:FC64:EA32:3697:9D16]] ([[User talk:2409:4071:4D0B:373:FC64:EA32:3697:9D16|talk]]) 11:32, 11 June 2022 (UTC)
*::...I linked to talk page sections which dozens of users participated in. Why have you [[WP:CANVAS|only notified]] the most vocal opponents of XRV? Not exactly a wonderful start if you're genuinely after a balanced discussion. Of course, even if there's a consensus to mark it as historical, we'll have to have a second on ''how'' to mark it as historical. &ndash;&#8239;[[User:Joe Roe|Joe]]&nbsp;<small>([[User talk:Joe Roe|talk]])</small> 11:34, 11 June 2022 (UTC)
*(responding to ping) It was clear from the RfC that developing something called XRV to do something related to reviewing (some subset of) actions by administrators and/or administrative actions (most but not all administrative actions are taken by administrators, most actions by administrators are not administrative actions) had consensus from those participating, which is not the same thing as implementing a less-than-half-formed venue with no clear agreement, even among proponents, regarding its purpose, scope or processes. When it became clear to me that it wasn't going to be easy to get agreement on any of the prerequisites for a functioning venue I decided I had better things to do with my life and the lack of activity suggests most others feel similarly. I don't really see the need to do anything with it other than let it naturally fade even further into obscurity. [[User:Thryduulf|Thryduulf]] ([[User talk:Thryduulf|talk]]) 12:10, 11 June 2022 (UTC)
*{{u| Joe Roe}}: Me? A power user? OMG! All I did was to state a few accurate facts [https://en.wikipedia.org/w/index.php?title=Wikipedia:Miscellany_for_deletion/Wikipedia:Administrative_action_review&diff=1064128456&oldid=1064128429 here] and [https://en.wikipedia.org/w/index.php?title=Wikipedia:Miscellany_for_deletion/Wikipedia:Administrative_action_review&diff=1064136885&oldid=1064135720 here]  - simple  generalisations about RfC proposals and noticeboard behaviour. That said, well, {{tq|''"coming from the very people XRV was supposed to make more accountability to the community"''}}, I'm not even an admin, so it wouldn't affect me. XRV is dead, and '''you''', dear IP hopping user, would probably have done better by letting sleeping dogs lie. [[User:Kudpung|Kudpung กุดผึ้ง]] ([[User talk:Kudpung|talk]]) 12:24, 11 June 2022 (UTC)
*:Well I didn't actually mean you {{u|Kudpung}}. I thought your points were fair and fairly expressed. That's 2409:4071:* leaping to conclusions. &ndash;&#8239;[[User:Joe Roe|Joe]]&nbsp;<small>([[User talk:Joe Roe|talk]])</small> 12:29, 11 June 2022 (UTC)
* I have reverted an [https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&diff=1092629553&oldid=1092619655 inappropriate closure] by {{U|Levivich}}, who had cast a [https://en.wikipedia.org/w/index.php?title=Wikipedia:Miscellany_for_deletion/Wikipedia:Administrative_action_review&diff=1064126804&oldid=1064126500 "Profanity-laced keep"] for XRV. Clearly they are [[WP:INVOLVED]] here. To address comments about canvassing, the reason I pinged 7-8 users was because {{U|Joe Roe}} was specifically talking about them in the examples they gave (which included one direct diff). The RFC question of "Should [[Wikipedia:Administrative action review]] be depracted and marked as historical?" ''is'' neutral. In the background section I explained why I opened this RFC, obviously I wouldn't have opened it if I was opposed to shutting it down myself. I don't see what RFCBEFORE is required here, XRV is a completely inactive process, I only sought to make it a formality. And no I am not a "logged out OP", I am a long term IP user who never saw a reason to create an account. My ISP assigns very dynamic IPs, so my contributions are spread out over a broad range of IP addresses. [[Special:Contributions/2409:4071:4D13:677B:E5E4:694E:766D:5EE0|2409:4071:4D13:677B:E5E4:694E:766D:5EE0]] ([[User talk:2409:4071:4D13:677B:E5E4:694E:766D:5EE0|talk]]) 06:20, 12 June 2022 (UTC)
* The basic problem with AAR is that after the community reached consensus to create it, it got back-door deprecated by way of quibbles about process and scope.  We clearly should have more structure around this than currently exists, because when an administrative action is disputed on AN, the thread can be closed after a random interval by a self-selected person, and ''that'' means that the actions are reviewed by whoever gets there first.  This creates an incentive to rush to comment if you want to be heard, which in my view is clearly suboptimal.  We ''should'' have fixed-duration discussions and holding them in a separate venue will help to archive them.  DRV reaches better decisions with less drama than the AN does, and having a well thought out process is the reason why.—[[User:S Marshall|<b style="font-family: Verdana; color: Maroon;">S&nbsp;Marshall</b>]]&nbsp;<small>[[User talk:S Marshall|T]]/[[Special:Contributions/S Marshall|C]]</small> 12:12, 12 June 2022 (UTC)
*:{{tpq|back-door deprecated by way of quibbles about process and scope.}} is an, interesting, way of framing the discussions that were attempting to determine whether there was consensus for the sort of process you desire or the sort of processes favoured by others. There was very clearly consensus for ''something'', but given that all these months later there is still no consensus about what exactly that something was is rather telling. [[User:Thryduulf|Thryduulf]] ([[User talk:Thryduulf|talk]]) 14:28, 12 June 2022 (UTC)
*::The consensus was: ''A new process, Administrative Action Review (XRV) designed to review if an editor's specific use of an advanced permission, including the admin tools, is consistent with policy in a process similar to that of deletion review and move review. Thanks to all the editors who contributed (and are continuing to contribute) to the discussion of how to implement this proposal.''  Wording taken directly from the RfC close.—[[User:S Marshall|<b style="font-family: Verdana; color: Maroon;">S&nbsp;Marshall</b>]]&nbsp;<small>[[User talk:S Marshall|T]]/[[Special:Contributions/S Marshall|C]]</small> 15:41, 12 June 2022 (UTC)
*:::IIRC there was a collapsed box in the proposal that had further details. The consensus was quite specific. [[User:Levivich|Levivich]] 16:12, 12 June 2022 (UTC)
*::::Yet, after months of discussion among editors acting in good faith, there is still no agreement on multiple open questions. This is rapidly heading towards rehashing those discussions, so I'll leave it here as you can read as well as I can and, unless anybody has anything new to bring to the table, there is no point in another few thousand words of no consensus. [[User:Thryduulf|Thryduulf]] ([[User talk:Thryduulf|talk]]) 16:17, 12 June 2022 (UTC)
*:::::There were no "months of discussion". XRV was smothered in a matter of days and none of the discussion was constructive, only nonspecific objections to the process being "a mess" or "an embarrassment" or "not what the RfC said". We asked you and others repeatedly what those "multiple open questions" about the process were supposed to be, and never got an answer. It died because you (plural) insisted that the RfC consensus could not be implemented before some supposedly critical flaws were resolved, but you wouldn't tell us what those flaws were. &ndash;&#8239;[[User:Joe Roe|Joe]]&nbsp;<small>([[User talk:Joe Roe|talk]])</small> 16:27, 12 June 2022 (UTC)
*::::::I would put it less strongly than Joe Roe, but I do think the community consensus was clearer than most of our policies, Thryduulf.  There was some real disagreement by people who wanted it to be something it wasn't, but the main problem was tactical failure to understand plain English.—[[User:S Marshall|<b style="font-family: Verdana; color: Maroon;">S&nbsp;Marshall</b>]]&nbsp;<small>[[User talk:S Marshall|T]]/[[Special:Contributions/S Marshall|C]]</small> 16:33, 12 June 2022 (UTC)
*:::::::I agree that what it was supposed to do seemed quite clear, but think that it has a failure to launch. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 16:39, 12 June 2022 (UTC)
*::::::::I wouldn't say failure to launch so much as it was shot down shortly after launch by people who opposed its launching. Joe summarized the details well above. [[User:Levivich|Levivich]] 18:33, 12 June 2022 (UTC)
*:::::::It didn't help that {{noping|Alalch Emis|label1=one editor}}, who had very firm ideas how XRV should develop, made 25% of the talk page edits as well as 25% of the edits at XRV itself. They're now blocked for disruptive editing and checkuser-blocked, but many may have been too exhausted or frustrated by then. [[User:NebY|NebY]] ([[User talk:NebY|talk]]) 19:20, 12 June 2022 (UTC)
*:::::::::That's a good point. It wasn't just those opposed to the idea who killed it; overenthusiastic supporters were equally to blame. It may be that, with the initial fervor dying down, cooler heads can now prevail and we can get it re-launched. [[User:Levivich|Levivich]] 19:32, 12 June 2022 (UTC)
* As I said before, mark it as an optional process and see if it helps solve problems (or if it tends to intensify them). Based on experiments we can then decide whether to make it permanent. [[User:Jehochman|Jehochman]] <sup>[[User talk:Jehochman|Talk]]</sup> 19:34, 12 June 2022 (UTC)
{{abottom}}

== Update for the fully professional league to notable leagues ==
{{closed rfc top
| status = Closed
| result = Discussion is also occurring at [[Wikipedia talk:Notability (sports)#Proposal for association football (soccer)|WP:Notability (sports)]] page. Discussion should be centralised to one forum, and therefore more appropriate for the linked page which has more specific interest in this topic, and also more commenters on the discussion. Note that a comment on this linked page is suggesting moving the discussion onward again to an alternative forum - this is beyond the scope of this page and this RfC closure. - [[User:Master Of Ninja|Master Of Ninja]] ([[User talk:Master Of Ninja|talk]]) 08:33, 14 June 2022 (UTC).<small>([[Wikipedia:Non-admin closure|non-admin closure]])</small>
}}

Hi. To clarify the sakes that can help enhance SIGCOV and GNG, I have proposed to update the following from the the title "fully professional leagues" to "notable leagues" in the area that the SIGCOV and GNG are to be respected, and to make the concerns addressed as to the list would be to inclusive in terms of notability.

{{ctop|Proposal}}

''Adapted from [[WP:FPL]].''

'''Proposed notable leagues'''

=== Men's leagues ===

* {{Fba|Albania}} - [[Kategoria Superiore]] (since 2016-17 season)
* {{Fba|Algeria}} - [[Algerian Ligue Professionnelle 1]]
* {{fba|Argentina}} – [[Argentine Primera División]] (since 1931)
* {{fba|Australia}} – [[A-League]]
* {{fba|Austria}} – [[Austrian Football Bundesliga]]
* {{fba|Belgium}} – [[Belgian First Division A]] (also know as [[Belgian Pro League]]) (from ~1960), [[Belgian First Division B]] (since 2018)
* {{fba|Brazil}} – [[Campeonato Brasileiro Série A]], [[Campeonato Brasileiro Série B]]
* {{fba|Canada}} – [[Canadian Premier League]], [[Major League Soccer]], [[USL Championship]] (formerly United Soccer League, USL Pro)
* {{fba|Chile}} – [[Chilean Primera División]]
* {{fba|China PR}} – [[Chinese Super League]]
* {{fba|Colombia}} – [[Categoría Primera A]]
* {{Fba|Costa Rica}} - [[Liga FPD]] (since 2004-05 season)
* {{fba|Croatia}} – [[Croatian First Football League]]
* {{fba|Czech Republic}} – [[Czech First League]]
* {{fba|Denmark}} – [[Danish Superliga]]
* {{Fba|Ecuador}} - [[Ecuadorian Serie A]], [[Ecuadorian Serie B]] (since 2021)
* {{Fba|Egypt}} - [[Egyptian Premier League]] (since 1990)
* {{fba|England}} – [[Premier League]], [[English Football League]]
* {{fba|Finland}} – [[Veikkausliiga]]
* {{fba|France}} – [[Ligue 1]], [[Ligue 2]] (from 1993–94 season)
* {{fba|Germany}} – [[Bundesliga]], [[2. Bundesliga]], [[3. Liga]]
* {{fba|Greece}} – [[Super League Greece]], [[Super League Greece 2]] (since 2021-22 season)
* {{fba|Hungary}} – [[Nemzeti Bajnokság I]]
* {{fba|India}} – [[Indian Super League]], [[I-League]]
* {{fba|Israel}} – [[Israeli Premier League]]
* {{fba|Italy}} – [[Serie A]], [[Serie B]], [[Serie C]]
* {{fba|Japan}} – [[J1 League]], [[J2 League]], [[J3 League]] (since 2022)
* {{fba|Mexico}} – [[Liga MX]]
* {{fba|Morocco}} – [[Botola]] (since 2011–12 season)
* {{fba|Netherlands}} – [[Eredivisie]], [[Eerste Divisie]]
* {{fba|New Zealand}} – [[A-League]]
* {{fba|Norway}} – [[Eliteserien]] (formerly Tippeligaen)
* {{fba|Poland}} – [[Ekstraklasa]]
* {{fba|Portugal}} – [[Primeira Liga]]
* {{Fba|Qatar}} - [[Qatar Stars League]]
* {{fba|Romania}} – [[Liga I]]
* {{fba|Republic of Ireland}} – [[League of Ireland Premier Division]] (since 2022 season)
* {{fba|Russia}} – [[Russian Premier League]]
* {{Fba|Saudi Arabia}} - [[Saudi Professional League]] (since 2008)
* {{fba|Scotland}} – [[Scottish Premiership]]
* {{fba|Serbia}} – [[Serbian SuperLiga]]
** Former countries include {{fba|Serbia and Montenegro}} – [[First League of Serbia and Montenegro]] and {{fba|Yugoslavia}} – [[Yugoslav First League]]
* {{fba|Singapore}} – [[Singapore Premier League]]
* {{fba|Slovakia}} – [[Slovak Super Liga]] (since 2009)
* {{fba|Slovenia}} – [[Slovenian PrvaLiga]]
* {{fba|South Africa}} – [[South African Premier Division]] (also known as Premier Soccer League, since 1996–97)
* {{fba|South Korea}} – [[K League 1]], [[K League 2]]
* {{fba|Spain}} – [[La Liga]], [[Segunda División]]
* {{fba|Sweden}} – [[Allsvenskan]]
* {{fba|Switzerland}} – [[Swiss Super League]]
* {{Fba|Tunisia}} - [[Tunisian Ligue Professionnelle 1]], [[Tunisian Ligue Professionnelle 2]], (since 2013 season), [[Tunisian Ligue Professionnelle 3]] (until 2016-17 season)
* {{fba|Turkey}} – [[Süper Lig]]
* {{fba|Ukraine}} – [[Ukrainian Premier League]]
* {{fba|United States}} – [[Major League Soccer]], [[USL Championship]] (formerly United Soccer League, USL Pro)
** Defunct leagues in the United States – [[North American Soccer League (1968–84)]], [[North American Soccer League (2011–2017)]], [[National Professional Soccer League (1967)]], [[A-League (1995–2004)]]

* {{Fba|Uruguay}} - [[Uruguayan Primera División]]

=== Women's notable leagues ===

* {{fba|Brazil}} – [[Campeonato Brasileiro de Futebol Feminino Série A1]] (from the 2019 season)
* {{fba|England}} – [[FA Women's Super League]] (from the 2018–19 season)
* {{fba|Italy}} – [[Serie A (women's football)|Serie A]] (from the 2022–23 season)
* {{fba|Japan}} – [[WE League]]
* {{fba|Netherlands}} – [[Eredivisie (women)|Eredivisie]]
* {{fba|Spain}} – [[Primera División (women)|Primera División]] (from the 2021–22 season)
* {{fba|Sweden}} – [[Damallsvenskan]] (from 2022 season)
* {{fba|United States}} – [[National Women's Soccer League]]
** Defunct leagues in the United States – [[Women's Professional Soccer]], [[Women's United Soccer Association]]
{{cbot|}}

I will look forward to hear your opinions, and have a peaceful day. Cheers. [[User:Ivan Milenin|Ivan Milenin]] ([[User talk:Ivan Milenin|talk]]) 03:08, 13 June 2022 (UTC)

===Responses (football leagues)===
* I've made a new section so the responses are readable. A few questions: (1) Can I ask why the proposal was not put to [[WP:FOOTBALL]] first, as this seems to be within that board's area of interest? (2) I note that [[WP:FPL]] is an archived/"historical" page that you have derived this from. Is this something that has been deprecated by the Football WP sub-group? (3) There seem to WP:FOOTBALL notability criteria already. What does this new proposal add? I.e. is this really needed? (4) What are the notability criteria used here? Do you have a list? (5) Why add defunct leagues? (6) Why mention since x year?
:(Continued) I do hate excessive guidelines as they prevent casual editors adding to knowledge. However if you wish to make a "notability list" then you need to ensure that you have criteria for it, as otherwise (eventually) either notability seems to get "captured" by a small group of editors, or alternatively descends into everyone thinking their hobby issue is notable enough to put on the list as there's no strict criteria. I hope these thoughts help in refining what you want to do. - [[User:Master Of Ninja|Master Of Ninja]] ([[User talk:Master Of Ninja|talk]]) 07:33, 13 June 2022 (UTC)
::@[[User:Master Of Ninja|Master Of Ninja]] I would note that they have zero need to put the proposal to a wikiproject first - in fact, I would generally say that would be a negative for a content project as doing so would inherently prohibit any notability policy that those interested in football disagree with. I make no comment on the other questions. [[User:Nosebagbear|Nosebagbear]] ([[User talk:Nosebagbear|talk]]) 09:09, 13 June 2022 (UTC)
:::*@[[User:Nosebagbear]] - thanks for reply. It's interesting as I feel this cuts both ways. That slightly odd sub-project guidelines or conventions shouldn't necessarily overrider WP policies. - [[User:Master Of Ninja|Master Of Ninja]] ([[User talk:Master Of Ninja|talk]]) 13:08, 13 June 2022 (UTC)
*Why is this here? you already started a discussion in the appropriate place, [[Wikipedia talk:Notability (sports)]]. Please do not split the discussion by having it in several places at once. —[[User:Kusma|Kusma]] ([[User talk:Kusma|talk]]) 11:42, 13 June 2022 (UTC)
:*Good catch, although it seems the proposal is somewhat different but related. The noted discussion is here: [[Wikipedia talk:Notability (sports)#Proposal for association football (soccer)]]. A user there already pointed to a previous discussion at {{section link|Wikipedia:Village pump (policy)/Archive 173|Notability guideline for association football on Wikipedia:Notablity (sports)}}. As well as another related discussion at [[Wikipedia_talk:Notability_(sports)/Association_football]]. These seem quite related discussions to me so should be consolidated on one forum. Any similar discussions on other parts of WP should be consolidated to this. @[[User:Ivan Milenin]] - what's your thoughts on this? - [[User:Master Of Ninja|Master Of Ninja]] ([[User talk:Master Of Ninja|talk]]) 13:18, 13 June 2022 (UTC)
::* {{re|Master Of Ninja}} I have read those comments. They appear to have been related, so, no problem with that. Proceed. [[User:Ivan Milenin|Ivan Milenin]] ([[User talk:Ivan Milenin|talk]]) 15:11, 13 June 2022 (UTC)
:::*Thanks [[User:Ivan Milenin]]. I see [[User:GiantSnowman]] and [[User:SMcCandlish]] have also made the same point in the section below. You should probably actually consolidate it on the other page ([[Wikipedia talk:Notability (sports)#Proposal for association football (soccer)]]) as that has more interest and discussion. I will (try and) close this discussion. If you have any other related discussions you should move to close them and point them to the main discussion page.
::::Although note in future having a central discussion does not stop you from posting to other boards to tell others that a relevant discussion is occurring elsewhere - it just is better to have one page for discussion.
::::I would also suggest in your proposal on [[Wikipedia talk:Notability (sports)]] that you update it and write some more background including links to the previous related discussion, and a summary of the outcomes, as linked on my previous reply above. This allows users dropping by to work out what has been discussed before, and to catch up more easily on progress so far. Otherwise it relied on [[User:Kusma]] pointing out to this page that there had been previous discussions. - [[User:Master Of Ninja|Master Of Ninja]] ([[User talk:Master Of Ninja|talk]]) 08:19, 14 June 2022 (UTC)

===Keep discussion central===
*This needs to be discussed at [[Wikipedia talk:Notability (sports)/Association football]] please. Having it in 3 separate locations is pointless. [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 15:39, 13 June 2022 (UTC)
*: Agreed. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 23:16, 13 June 2022 (UTC)

{{closed rfc bottom}}

== Proposal to prohibit WikiProjects from ranking further articles as A-class ==

I would like to notify the Village Pump of [[Wikipedia:Miscellany for deletion/Wikipedia:Content assessment/A-Class criteria|a proposal to prohibit WikiProjects from ranking articles as A-class]] that was filed at MfD yesterday. — ''Ceso femmuin mbolgaig mbung'', ''[[User:Mellohi!|mello]]'''''[[User talk:Mellohi!|hi!]]''' ([[Special:Contributions/Mellohi!|投稿]]) 18:55, 18 June 2022 (UTC)

== Allow admins to grant PCR right? ==
{{atop
| status = Nothing to do here
| result = This is a proposal for what is (and always has been) the status quo for PCR grants. --[[User:Blablubbs|Blablubbs]] ([[User talk:Blablubbs|talk]]) 13:22, 19 June 2022 (UTC)
}}



Currently, only bureaucrats may create new pending changes reviewers. I propose that this power be transferred to administrators, since the right is relatively less important (unlike, say, the power to grant new admins). Thanks. [[User:NotReallySoroka|NotReallySoroka]] ([[User talk:NotReallySoroka|talk]]) 06:42, 19 June 2022 (UTC)
:{{replyto|NotReallySoroka}} Er, I'm an admin with no superpowers - just the basic admin bundle plus autopatrolled. If I go to "User rights management" for any user (from a newly-registered account with zero edits, all the way up to Jimbo), I get the same two columns. The first, titled "Groups you cannot change" is greyed out - it has the following entries:
{{collapse top|List of items}}
:* bot
:* administrator
:* interface administrator
:* bureaucrat
:* oversight
:* steward
:* importer
:* transwiki importer
:* founder
:* researcher
:* checkuser
:* copyright violation bot
:* push subscription manager
:* blocked from IPInfo
:The second, titled "Groups you can change" allows me to toggle all of its checkboxes - it has the following entries:
:* account creator
:* IP block exempt
:* rollbacker
:* edit filter helper
:* autopatrolled
:* event coordinator
:* file mover
:* template editor
:* mass message sender
:* extended confirmed user
:* page mover
:* new page reviewer
:* edit filter manager
:* confirmed user
:* pending changes reviewer
{{collapse bottom}}
:I could therefore remove the pending changes reviewer right from you, and restore it again. But I won't, because that is against [[WP:ADMIN#Expectations of adminship]]. I could also grant it to Jimbo, who apparently doesn't have it... --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 09:28, 19 June 2022 (UTC)
::{{u|Redrose64}}, [[WP:JIMBOISNOTAHATSTAND]] /j. — [[User:Ixtal|Ixtal]] <sup>( [[User talk:Ixtal|T]] / [[Special:Contributions/Ixtal|C]] ) </sup> &#8258; <small> Join [[WP:FINANCE|WP:FINANCE]]! </small> 11:34, 19 June 2022 (UTC)
:::Jimbo doesn't need the pending changes reviewer permission to be explicitly set, as it's one of the many rights that come automatically with adminship... &nbsp;&mdash;&nbsp;[[User:Amakuru|Amakuru]] ([[User talk:Amakuru|talk]]) 12:11, 19 June 2022 (UTC)
*{{ping|NotReallySoroka}} see [[Special:ListGroupRights]] this is already in place. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 10:35, 19 June 2022 (UTC)
{{abot}}

== Add Armenian and Georgian languages to the other languages list on the bottom of English Wikipedia ==

Hi Wikipedia users and Admins!

I have a request which is to add Armenian and Georgian languages to the other languages list on the bottom of English Wikipedia since these two Wikipedia languages have more than 100K+ articles and should be finded quicker on the bottom of English Wikipedia in the other languages section.

Please note that is my desire to see these languages, the choice is of admins.

Thanks <!-- Template:Unsigned --><span class="autosigned" style="font-size:85%;">—&nbsp;Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:SSHTALBI|SSHTALBI]] ([[User talk:SSHTALBI#top|talk]] • [[Special:Contributions/SSHTALBI|contribs]]) 12:55, 25 June 2022 (UTC)</span>

:@[[User:SSHTALBI|SSHTALBI]] This should probably be requested at [[Talk:Main Page]] or [[Template talk:Wikipedia languages]]. --[[User:Ahecht|Ahecht]] ([[User talk:Ahecht|<span style="color:#FFF;background:#04A;display:inline-block;padding:1px;vertical-align:-.3em;font:bold 50%/1 sans-serif;text-align:center">TALK<br />PAGE</span>]]) 16:07, 25 June 2022 (UTC)

== [[:Wikipedia:Naming conventions Indian constituencies]] has an [[WP:RFC|RFC]]==

<div class="floatleft" style="margin-bottom:0">[[File:Ambox warning orange.svg|48px|alt=|link=]]</div>'''[[:Wikipedia:Naming conventions Indian constituencies]]''' has an RFC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the '''[[Wikipedia talk:WikiProject Indian politics/Archive 4#Proposal : Wikipedia:Naming conventions Indian constituencies|discussion page]]'''.<!-- Template:Rfc notice--> Thank you. [[User:BilledMammal|BilledMammal]] ([[User talk:BilledMammal|talk]]) 10:53, 26 June 2022 (UTC)

== Temporarily lock an article ==

[[NBA 75th Anniversary Team]] clearly states: Statistics are correct through the end of the 2020–21 season, the season last completed before the list was announced. And also: <!---Please do not update this list past the 2020-2021 season in order to provide the context in which the selections were made---> which doesn't keep folks from adding Steph's and Steve Kerr's recent NBA title. 

And since having an account on the wiki doens't induce reading skills, I suggest a hard lock for everyone until hte hype has died down.

No clue where this proposal should rightfully go, so please move it to the appropriate place, thanks. [[Special:Contributions/2A02:810D:933F:E250:D8E0:E9C0:15CE:893D|2A02:810D:933F:E250:D8E0:E9C0:15CE:893D]] ([[User talk:2A02:810D:933F:E250:D8E0:E9C0:15CE:893D|talk]]) 09:50, 18 June 2022 (UTC)

:The right place is [[WP:RFPP]], but you'd have to make the argument there that this problem disrupts the article so much atm that protection is needed. I see someone commented on this at [[Talk:NBA 75th Anniversary Team]], that may have some effect. [[User:Gråbergs Gråa Sång|Gråbergs Gråa Sång]] ([[User talk:Gråbergs Gråa Sång|talk]]) 11:06, 18 June 2022 (UTC)

::Tack så mycket. Will do when I’m on my PC again. [[Special:Contributions/2A02:810D:933F:E250:D942:55FA:23A0:689B|2A02:810D:933F:E250:D942:55FA:23A0:689B]] ([[User talk:2A02:810D:933F:E250:D942:55FA:23A0:689B|talk]]) 11:30, 18 June 2022 (UTC)
:::Ingen orsak! [[User:Gråbergs Gråa Sång|Gråbergs Gråa Sång]] ([[User talk:Gråbergs Gråa Sång|talk]]) 13:45, 18 June 2022 (UTC)
Section can be archived. [[Special:Contributions/2A02:810D:933F:E250:D02C:6B31:DA76:6D4B|2A02:810D:933F:E250:D02C:6B31:DA76:6D4B]] ([[User talk:2A02:810D:933F:E250:D02C:6B31:DA76:6D4B|talk]]) 15:56, 18 June 2022 (UTC)
:Sections are archived automatically by a bot, just wait a couple of days without editing the thread. [[User:Sungodtemple|Sungodtemple]] ([[User talk:Sungodtemple|talk]]) 16:28, 18 June 2022 (UTC)
::For this particular page, it's nine days after the most recent post. So if nobody else posts in this section, this will be eligible for archiving at 21:00, 27 June 2022 (UTC). --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 21:00, 18 June 2022 (UTC)

== Fix the Wikidata links of [[List of fifth intervals]] ==

Well, there are articles talking about fifth intervals of music theory.

Throughout WP articles of different languages, almost all of them share the similarities: they talk about
*perfect fifth
*diminished fifth
*augmented fifth
and the main Wikidata of Fifth intervals is [[wikidata:Q224169]].

The English pages [[List of fifth intervals]] also talks about different fifth intervals. But the article has been moved, so that one can not link to other wikidata from [[List of fifth intervals]].

'''I strongly suggest linking [[List of fifth intervals]] to [[wikidata:Q224169]]''' simply because all pages on WP of different languages talks about the same thing.

There are also some [[wikidata:Talk:Q224169|issues]] about whether to call it "list".

Well there are other "list"s of music theory.

#[[Unison]], which is not a list
#[[Second_(disambiguation)#Music]], redirected from [[Second (music)]]
#[[Third#Music theory]], redirected from [[Third (music)]]
#[[Fourth (music)]]
#[[List of fifth intervals]], see also [[Fifth#Music]]
#[[Sixth]], redirected from [[Sixth (music)]]
#[[Seventh#Music]], redirected from [[Seventh (music)]]
#[[Octave]], which is not a list

Those mentioned above are a series of intervals. Some articles talks about exactly one interval, some others talk about several kind of intervals, other languages alike. It is for sure that different intervals are of different importance. I also suggest to look through all above to check consistency and the interlingual links if we can find a better solution.

--[[User:吳傲雪|吳傲雪]] ([[User talk:吳傲雪|talk]]) 16:05, 24 June 2022 (UTC)
*I am confused as to what we are considering here… is the question about what to name the article? This isn’t the right venue for that. Raise it at [[WP:RM]].  [[User:Blueboar|Blueboar]] ([[User talk:Blueboar|talk]]) 21:59, 28 June 2022 (UTC)
Fix the wikidata. [[List of fifth intervals]] does not link to any articles of other languages now. '''I strongly suggest linking [[List of fifth intervals]] to [[wikidata:Q224169]]'''. Whether to rename it or move it, doesn't bother me. As mentioned above, it talks about the same thing, and should be linked to other wikis. --[[User:吳傲雪|吳傲雪]] ([[User talk:吳傲雪|talk]]) 03:56, 29 June 2022 (UTC)

== New page search engine NOINDEX duration ==

In 2012, an  [[Wikipedia:Requests for comment/NOINDEX|RFC]] decided that unpatrolled articles should be NOINDEXED until reviewed and accepted. In 2016, it was implemented differently as discussed [[Wikipedia:Page Curation/Suggested improvements/Archive 1#8.%20No%20Index%20until%20patrolled|here]]. At that time, it was assumed that new articles would be patrolled within 90 days and it would be sufficient to only honor NOINDEX on mainspace articles for 90 days. The New Page Reviewer user group is at present unable to review articles within 90 days (there is a backlog of 14,000) and proposes that the original RFC be fully implemented (that that the no-indexing of unreviewed articles be extended indefinitely).

There was some consideration of changing the NOINDEX period to 180 or 365 days to cope with the immediate backlog, but the NPP consensus is to follow the RFC which said '''Noindex unpatrolled new articles'''. There was also concern that since the RFC was 10 years ago, it would be good to get wider re-affirmation.

A quick summary of pros (may not be exhaustive)
* preventing the dissemination of potentially harmful information (copyvio, attack pages)
* preventing commissioned works by UPEs from slipping through
* motivating authors to write better articles (properly sourced articles are usually patrolled quickly)
A quick summary of cons (may not be exhaustive)
* an important news article may not be immediately visible in search engines (although obviously notable topics are usually patrolled quickly)
* an increase in the number of [[WP:HELPDESK]] questions like "why doesn't my article show up in Google?"

The discussion is at [[Wikipedia talk:New pages patrol/Reviewers#Picking a specific # of days for NOINDEX proposal at Village Pump|the NPP discussion page]] if you would like to comment. [[User:MB|<b style="color:#034503">MB</b>]] 20:29, 23 June 2022 (UTC)

:As I noted at [[phab:T310974]] - this doesn't yet seem to have been very well advertised; especially as it impacts all article writers.  Suggest adding to CENT and tagging as an RFC. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 21:07, 28 June 2022 (UTC)
::I think it would be best to do as suggested by {{u|xaosflux}}, if only to ensure each of our behinds are adequately covered {{p|;)}} — does that sound okay {{u|MB}}? — [[User:TheresNoTime|TNT]] ([[User talk:TheresNoTime|talk]] • she/her) 19:50, 29 June 2022 (UTC)
*{{re|Xaosflux|TheresNoTime|MB}} This is only one of the immediate solutions required by NPP. Others are also being implemented in an attempt to keep the encyclopedia free of spam and other totally inappropriate mainspace content. This software modification request is essential and urgent and concerns uniquely the huge workload of the New Page Reviewers, and hence the need to avoid unpatrolled pages entering the encyclopedia corpus as verified suitable for indexing by search engines.
:It is a request local to the New Page Review system and its authorised users and does not need a broadly publicised RfC. It does not impact all users in any way - having your article referenced is an advantage but not a right; nowadays most of the new articles that are submitted are unlikely to benefit greatly from being listed by Google. Like most websites, Wikipedia ''does'' have its own built-in search engine.
:The vast majority of new pages that exceed the previous 90-day limit are borderline notability or suitability cases that have either been left for reviewing by more experienced patrollers or simply could not be reviewed in time - the backlog is immense; backlog drives have had some minor effect but it would still take a year or more to clear  it. Each time the backlog has been successfully cleared by an all-out campaign, the reviewers have relaxed their participation and the backlog has very quickly grown again to an untenable extent.  
:Of the 700+ New Page Reviewers, less than 10% are active and very few are sufficiently experienced to patrol the pages quickly but accurately, and others are leaving due to burnout. New Page Patrollers, like all the other maintenance workers, are not paid for what has become a boring, mind-numbing, and thankless task and it is therefore irresponsible to continue submit them to stress. and make those who actually do it feel guilty for not doing enough.  Enough is enough. [[User:Kudpung|Kudpung กุดผึ้ง]] ([[User talk:Kudpung|talk]]) 20:11, 29 June 2022 (UTC)
::I replied at '''[[Wikipedia talk:New pages patrol/Reviewers#Picking a specific # of days for NOINDEX proposal at Village Pump]]''' to prevent forking this. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 22:57, 29 June 2022 (UTC)
:::Agree with not forking and keeping discussion at NPP. This was intended to be a notification of that discussion. [[User:MB|<b style="color:#034503">MB</b>]] 00:14, 30 June 2022 (UTC)

== Enabling the New Topic Tool by default ==

<!-- [[User:DoNotArchiveUntil]] 22:01, 1 July 2022 (UTC) -->{{User:ClueBot III/DoNotArchiveUntil|1656712873}}
{{closed rfc top|result=There is clear consensus to enable the new topic tool by default. Concerns regarding the reply tool and timestamps does not conflict with the rfc. Opened [[phab:T311023]]. <span style="font-family:Iosevka,monospace">0x[[User talk:0xDeadbeef#top|<span style="text-transform:uppercase;color:black">'''Deadbeef'''</span>]]</span> 01:35, 21 June 2022 (UTC)}}
[[File:DiscussionTools_New_Discussion_blank_2021.png|thumb|Screenshot of the new topic tool]]
Should the [[mw:Talk pages project/New discussion|new topic tool]] be enabled by default on English Wikipedia? <span style="color:#AAA"><small>&#123;{u&#124;</small><span style="border-radius:9em;padding:0 5px;background:#088">[[User:Sdkb|<span style="color:#FFF">'''Sdkb'''</span>]]</span><small>}&#125;</small></span> <sup>[[User talk:Sdkb|'''talk''']]</sup> 21:33, 27 May 2022 (UTC)

=== Background ===
The [[mw:Editing team|WMF's editing team]] has been developing tools that aim to improve the functionality of talk pages for both newcomers and experienced editors under the umbrella of the [[Wikipedia:Talk pages project|talk pages project]]. A few months ago, we [[Wikipedia:Village pump (proposals)/Archive 187#Offering the Reply Tool as an opt-out feature|enabled their reply tool]] by default. The [[mw:Talk pages project/New discussion|new topic tool]] is a similar tool for starting new sections on talk pages; you can preview it [https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)?dtenable=1 by clicking here] and choosing "Add topic" at upper right, next to the history tab.

The editing team [[Wikipedia talk:Talk pages project#New Topic Tool for everyone|has informed us]] {{tq|In light of the recent [[mw:Talk_pages_project/New_discussion#6_May_2022|A/B test results showing the positive impact]] of the [[mw:Talk_pages_project/New_discussion|New Topic Tool]], the [[mw:Editing_Team|Editing Team]] is in support of enabling it by default at all projects}}, and has done so on 20 other projects, with it available here as a beta feature that can be turned on in [[Special:Preferences#mw-prefsection-betafeatures|your preferences]]. This RfC asks whether it should be enabled as a default-on feature, but with an opt-out option available to all logged-in editors in their preferences.

=== Survey (New Topic Tool) ===

* '''Yes'''. This tool is the logical complement to the reply tool, which we have been using very successfully for several months. It makes starting discussions easier for both newcomers (vital for our future) and experienced editors (essential for our present). The ease of opting out (both fully in your preferences, and on a case-by-case basis by just editing in source if you need to) limits the potential for harm. We've [[Wikipedia talk:Teahouse#Should we enable the new discussion tool for everyone?|already been using it successfully at the Teahouse]] since March. It's not at 100% perfect functionality quite yet, but it's close, and it's certainly much better than the status quo. Enabling it now rather than once development is fully complete will provide us with a more meaningful window to give the developers feedback that they'll be able to address before they wrap up their initial development work. <span style="color:#AAA"><small>&#123;{u&#124;</small><span style="border-radius:9em;padding:0 5px;background:#088">[[User:Sdkb|<span style="color:#FFF">'''Sdkb'''</span>]]</span><small>}&#125;</small></span> <sup>[[User talk:Sdkb|'''talk''']]</sup> 21:33, 27 May 2022 (UTC)
* '''Sure, why not'''. If it helps less-experienced users participate more (as the A/B results suggest), then that's probably worthwhile. Judging from [[Wikipedia:Talk pages project#Starting a new discussion]], the big differences are the live preview (useful!) and the automatic signature (useful if "hyphen-hypen-space-tilde-tilde-tilde-tilde" hasn't already been permanently burned into your brain). Beyond that, the UX doesn't seem wildly different from the existing "+" setup, so there doesn't seem to be much to object to. -- [[User:Visviva|Visviva]] ([[User talk:Visviva|talk]]) 23:36, 27 May 2022 (UTC)
*'''Yes'''. A/B tests show positive benefit, it's fairly easy to enable, and helps new contributors. [[User:EpicPupper|🐶&nbsp;EpicPupper]] <sup>(he/him &#124; [[User talk:EpicPupper|talk]])</sup> 01:56, 28 May 2022 (UTC)
*[[File:OOjs UI icon add-constructive.svg|18px|link=]]&nbsp;'''Support'''<!-- [[User:Tol/Template/Quick reply]] -->, makes sense after the reply tool.&nbsp;&#8213;&nbsp;<span id="Qwerfjkl:1653722302569:WikipediaFTTCLNVillage_pump_(proposals)" class="FTTCmt">[[User:Qwerfjkl|<span style="background:#1d9ffc; color:white; padding:5px; box-shadow:darkgray 2px 2px 2px;">Qwerfjkl</span>]][[User talk:Qwerfjkl|<span style="background:#79c0f2;color:white; padding:2px; box-shadow:darkgray 2px 2px 2px;">talk</span>]] 07:18, 28 May 2022 (UTC)</span>
*'''Strong support''' I think it's a great and simple-to-learn tool. — [[User:Ixtal|Ixtal]] <sup>( [[User talk:Ixtal|T]] / [[Special:Contributions/Ixtal|C]] ) </sup> &#8258; <small> Join [[WP:FINANCE|WP:FINANCE]]! </small> 11:27, 28 May 2022 (UTC)
*'''Support''' There are bunch of userscripts that help to do the same though. <span style="font-weight: bold" >[[User:Alexander_Davronov|<span style="color:#a8a8a8;">AXO</span><span style="color:#000">NOV</span>]] [[User talk:Alexander_Davronov|(talk)]] [[Special:Contributions/Alexander_Davronov|⚑]]</span> 13:28, 28 May 2022 (UTC)
*'''Support''' An improvement over the raw wikitext form. – [[User:SD0001|<span style="font-weight: bold; color: #C30">SD0001</span>]] ([[User talk:SD0001|talk]]) 16:41, 28 May 2022 (UTC)
*'''Support''' I've found it to be an excellent counterpart to the reply tool. [[User:Sideswipe9th|Sideswipe9th]] ([[User talk:Sideswipe9th|talk]]) 15:25, 29 May 2022 (UTC)
*'''Support''' Nice improvement. [[User:MichaelMaggs|MichaelMaggs]] ([[User talk:MichaelMaggs|talk]]) 17:15, 30 May 2022 (UTC)
*'''Sure, why not?''' Go for it.  --[[User:Jayron32|<span style="color:#009">Jayron</span>]][[User talk:Jayron32|<b style="color:#090">''32''</b>]] 18:13, 31 May 2022 (UTC)
*'''Support''': Useful tool. <span class="nowrap">&#8212;'''[[User:CX Zoom|CX Zoom]]'''[he/him]</span> <sup class="nowrap">([[User talk:CX Zoom|let's talk]] • {[[Special:Contributions/CX Zoom|C]]•[[User:CX Zoom/X|X]]})</sup> 18:53, 31 May 2022 (UTC)
*'''Support''' I've been using the tool and it's a great improvement. - LCU '''[[User:ActivelyDisinterested|ActivelyDisinterested]]''' ''∆[[User talk:ActivelyDisinterested|transmissions]]∆'' °[[Special:Contributions/ActivelyDisinterested|co-ords]]° 00:30, 1 June 2022 (UTC)
* '''Strong support''' Best discussion tool ever been made available to Mediawiki. Of course it should be available by-default. [[User:Lectrician1|Lectrician1]] ([[User talk:Lectrician1|talk]]) 01:56, 2 June 2022 (UTC)
*'''Support'''. I have used it for some time, and I find it very convenient even as an experienced editor. [[User:MarioGom|MarioGom]] ([[User talk:MarioGom|talk]]) 11:04, 4 June 2022 (UTC)
:<s>'''Support''' It sign comments. [[User:TSOPar|TSOPar]] ([[User talk:TSOPar|talk]]) 13:53, 5 June 2022 (UTC)</s> {{sockvote}} <span class="nowrap">&#8212;'''[[User:CX Zoom|CX Zoom]]'''[he/him]</span> <sup class="nowrap">([[User talk:CX Zoom|let's talk]] • {[[Special:Contributions/CX Zoom|C]]•[[User:CX Zoom/X|X]]})</sup> 07:15, 8 June 2022 (UTC)
*'''Support'''. It signs comments, it's nice for both new users and for me! [[User:SWinxy|SWinxy]] ([[User talk:SWinxy|talk]]) 16:19, 5 June 2022 (UTC)
*'''Support''' Works well for me. [[User:Galobtter|Galobtter]] ([[User talk:Galobtter|pingó mió]]) 06:34, 6 June 2022 (UTC)
*'''Support''' Will make adding a new topic consistent with the reply tool, no point having two different interfaces when you can have just one for a user to get used to for talk page comments. [[User:Terasail|<span style="color:#088; font-weight:800;">Terasail</span>]][[User talk:Terasail|<sup><span style="color:#000;">'''[✉️]'''</span></sup>]] 14:15, 7 June 2022 (UTC)
*'''Support''' - nice job to the Editing Team working on this, thanks for the improvement! [[User:Retswerb|Retswerb]] ([[User talk:Retswerb|talk]]) 03:35, 11 June 2022 (UTC)

=== Discussion (New Topic Tool) ===
<small>Courtesy pings: {{u|PPelberg (WMF)}}, {{u|Whatamidoing (WMF)}}. Notified: [[WT:Usability]], [[WT:Talk pages project]]. <span style="color:#AAA"><small>&#123;{u&#124;</small><span style="border-radius:9em;padding:0 5px;background:#088">[[User:Sdkb|<span style="color:#FFF">'''Sdkb'''</span>]]</span><small>}&#125;</small></span> <sup>[[User talk:Sdkb|'''talk''']]</sup> 21:33, 27 May 2022 (UTC)</small>

:hi y'all – on the topic of, "How will people who prefer the existing <code>section = new</code> workflow be able to '''turn off the New Topic Tool'''?"...
:In addition to what @[[User:Sdkb|Sdkb]] mentioned above about you being able to '''disable the New Topic Tool''' within [[Special:Preferences#mw-prefsection-editing|Special:Preferences]],  the tool offers peoples the ability to switch back to the existing <code>section = new</code> experience from '''directly within the tool''' as pictured here: [[File:New Discussion Tool Hint.png|200px|right]] [[User:PPelberg (WMF)|PPelberg (WMF)]] ([[User talk:PPelberg (WMF)|talk]]) 02:04, 28 May 2022 (UTC)

Please see this.[https://en.wikipedia.org/wiki/Special:Diff/1090155763/1090157257] "What's going on with the times here? Bakkster Man posts at 12:29 am, Today (UTC+1) with many diffs. Next, in line, (visually) a post by Gimiv 8:40 pm, Yesterday (UTC+1) complaining about a report with no diffs. Last, a post by RandomCanadian at 11:50 pm, Yesterday (UTC+1).[reply]
Why are times skipping around...23:29, 27 May 2022 (UTC), next 8:40 pm, Yesterday (UTC+1), next 11:50 pm, Yesterday (UTC+1). I have no connection with any of these editors, but it's very confusing, shouldn't our "software" organize this chronologically? Seems to make editors look as if they haven't read, or are mis-replying to posts."
<!-- Template:Unsigned --><span class="autosigned" style="font-size:85%;">—&nbsp;Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Doug Weller|Doug Weller]] ([[User talk:Doug Weller#top|talk]] • [[Special:Contributions/Doug Weller|contribs]]) 12:17, 28 May 2022 (UTC)</span>

:I don't understand what you mean. That is not what I am seeing in that link; there isn't even a comment by Bakkster Man, and that is not how the timestamps look like for me. Can you include a screenshot of what you're seeing, and clarify what the problems are? (You can upload it to https://phabricator.wikimedia.org/file/upload/ if you don't want to clutter up Wikipedia.) Here's what the page looks like for me, and I don't see anything wrong: https://phabricator.wikimedia.org/F35185664. [[User:Matma Rex|Matma Rex]] <small>[[User talk:Matma Rex|talk]]</small> 21:43, 28 May 2022 (UTC)
::@[[User:Matma Rex|Matma Rex]] please take a look at the whole thread.[https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/Incidents#CutePeach_disrupting_COVID-19_discussions]. You've pointed to an earlier version. I can't fit it into a screen shot. [[User:Doug Weller|<span style="color:#070">Doug Weller</span>]] [[User talk:Doug Weller|talk]] 15:14, 29 May 2022 (UTC)
:::Oh, actually you linked to an earlier version, that's why I also looked at the earlier version. I thought that was intentional.
:::I am also still confused by the weird timestamps, I guess you're using some gadget to display them in your timezone and in different format? If it's showing some of them as "(UTC)" and others as "(UTC+1)", then that must be a bug in that tool. I have no idea what tool it is (it'd be slightly easier to guess if you shared a screnshot). You might find pages easier to read if you disable it, if that happens often.
:::The non-chronological order is expected for me. As far as I know, only replies at the same indentation level are supposed to be in chronological order. When you reply with deeper indentation to a comment earlier in the discussion, by necessity the result can't be chronological (unless you put your reply at the bottom of the thread, instead of making it a directly reply). I found a good example of this in the documentation pages: [[Wikipedia:Indentation#Indentation examples]] (admittedly it took me a while to find it). [[User:Matma Rex|Matma Rex]] <small>[[User talk:Matma Rex|talk]]</small> 18:56, 30 May 2022 (UTC)
*Does this still have the "feature" of hijacking the "create a page" process for brand new talk pages? — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 14:33, 31 May 2022 (UTC)
*:Yes, although I'm hoping that we'll add a way to disable that while keeping the tool enabled otherwise. I proposed that in [[phab:T297990|T297990]]. [[User:Matma Rex|Matma Rex]] <small>[[User talk:Matma Rex|talk]]</small> 17:41, 31 May 2022 (UTC)
*::'''[Update]''' The [[mw:Editing|Editing Team]] is going to prioritize implementing what @[[User:Matma Rex|Matma Rex]] mentioned above: a new setting that will enable people to decide for themselves whether they will immediately land in the source editor upon navigating to a talk page that has not yet been created or whether they will see the new [[:File:Talk page empty state.gif|empty state experience]].
*::We expect this new setting to be available in the next few weeks. [[User:PPelberg (WMF)|PPelberg (WMF)]] ([[User talk:PPelberg (WMF)|talk]]) 16:04, 2 June 2022 (UTC)
*::@[[User:Xaosflux|Xaosflux]] As of a few minutes ago, you can disable the "hijacking" of new talk pages in preferences at [[Special:Preferences#mw-prefsection-editing-discussion]] ("When I visit a discussion page that hasn't been created yet…"). [[User:Matma Rex|Matma Rex]] <small>[[User talk:Matma Rex|talk]]</small> 21:13, 7 June 2022 (UTC)
*:::Thanks for the update @[[User:Matma Rex|Matma Rex]]! — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 22:50, 7 June 2022 (UTC)

{{closed rfc bottom}}

=== Doing this ===
{{Tracked|T311023}}
Hey, all:  I'll have to ask the devs about the schedule, but I think this could be done next week – maybe Wednesday, if the deployment calendar has a free spot?  I'm not going to suggest [[WP:THURSDAY]] itself to them.  '''If this coming week is too soon, please let me know.'''  It can be postponed easily.

Many thanks to [[User:Sdkb|Sdkb]] for making this discussion happen.  I would particularly appreciate it if someone would spread the word.  I can tell VPT when the devs have settled on a day, but please let the non-technical editors know what to expect.  It's super easy to opt-out if you don't like the new thing.

If you want to see all the current options, then please click on https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&dtenable=1  It'll give you the ==New section== tool, but it'll also give you the awesome [subscribe] button.  DiscussionTools is in [[Special:Preferences#mw-prefsection-betafeatures]] if you want to keep it turned on.  Be on the lookout for some more changes, mostly about the appearance.  [[Wikipedia talk:Talk pages project]] has a link to a demo.  [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk:Whatamidoing (WMF)|talk]]) 17:01, 23 June 2022 (UTC)

:@[[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] how does reply deal with edit notices? Eg a lot of editors have them on their talk page, and if my chemotherapy really knocks me out I was going to add one making it clear I could not respond to help requests. [[User:Doug Weller|<span style="color:#070">Doug Weller</span>]] [[User talk:Doug Weller|talk]] 17:42, 23 June 2022 (UTC)
::@[[User:Doug Weller|Doug Weller]] reply-tool doesn't load edit notices for the page. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 18:26, 23 June 2022 (UTC)
:::@[[User:Xaosflux|Xaosflux]] this looks like a major flaw. And I presume one that can’t be fixed. I wish I’d thought of this earlier. [[User:Doug Weller|<span style="color:#070">Doug Weller</span>]] [[User talk:Doug Weller|talk]] 18:28, 23 June 2022 (UTC)
::::@[[User:Doug Weller|Doug Weller]] the "Add topic" component has the edit notices,the "reply" one doesn't.  So in your use case above, people newly starting a discussion on your user talk, while it had a page notice, would see it.  People replying to a discussion would not. (c.f. [[phab:T269033]]) — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 18:35, 23 June 2022 (UTC)
:::::@[[User:Xaosflux|Xaosflux]] Ah, that makes a big difference. In most cases that would suffice. Thanks. [[User:Doug Weller|<span style="color:#070">Doug Weller</span>]] [[User talk:Doug Weller|talk]] 18:42, 23 June 2022 (UTC)
::::::Also, this is ''only'' about the "Add topic" component.   [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk:Whatamidoing (WMF)|talk]]) 17:21, 24 June 2022 (UTC)
:::::::@[[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] yes, that’s what I understood. Thanks. [[User:Doug Weller|<span style="color:#070">Doug Weller</span>]] [[User talk:Doug Weller|talk]] 17:25, 24 June 2022 (UTC)
:The devs say that they can do Wednesday, subject to all the usual disclaimers and caveats.  Check https://wikitech.wikimedia.org/wiki/Deployments#Wednesday,_June_29 later if you want to know the exact time.  Please ping me if anyone has questions (here or any other page).  
:Remember:  There's a built-in button for switching to the old mode, and if you don't see that, then you can turn it off in [[Special:Preferences#mw-prefsection-editing-discussion]] at any time. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk:Whatamidoing (WMF)|talk]]) 20:18, 27 June 2022 (UTC)
:These config changes have been deployed now. [[User:Matma Rex|Matma Rex]] <small>[[User talk:Matma Rex|talk]]</small> 13:38, 29 June 2022 (UTC)
::@[[User:Matma Rex|Matma Rex]] - are they working?  I used a logged out session, went to a random article, went to talk tab, clicked "new section" - got the classic wikitext editor ([https://en.wikipedia.org/w/index.php?title=Talk:Curt_Brackenbury&action=edit&section=new link]) as opposed to ([https://en.wikipedia.org/w/index.php?title=Talk:Curt_Brackenbury&action=edit&section=new&dtenable=1 dtenable forced]) the new section discussion tool. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 14:02, 29 June 2022 (UTC)
:::They do not appear deployed yet to me, either. <span style="color:#AAA"><small>&#123;{u&#124;</small><span style="border-radius:9em;padding:0 5px;background:#088">[[User:Sdkb|<span style="color:#FFF">'''Sdkb'''</span>]]</span><small>}&#125;</small></span> <sup>[[User talk:Sdkb|'''talk''']]</sup> 14:03, 29 June 2022 (UTC)
:::[[phab:T311023]] appears to still be open too?  Ping to {{ping|Whatamidoing (WMF)}} as requested above. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 14:14, 29 June 2022 (UTC)
::::We've investigating now, it seems like the changes haven't been deployed to all servers. [[User:Matma Rex|Matma Rex]] <small>[[User talk:Matma Rex|talk]]</small> 14:44, 29 June 2022 (UTC)
::::@[[User:Xaosflux|Xaosflux]] @[[User:Sdkb|Sdkb]] Sorry about that – they should be deployed for real now. Apparently on some servers there was a caching problem and the new config wasn't being used, and I must have gotten one of the lucky ones when testing that the config change worked. SRE were able to fix it by just restarting stuff. I'll comment here when we know what exactly happened and how to prevent it in the future. [[User:Matma Rex|Matma Rex]] <small>[[User talk:Matma Rex|talk]]</small> 14:59, 29 June 2022 (UTC)
:::::@[[User:Matma Rex|Matma Rex]] - thank you, my last 3 tests seem to be working now. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 15:25, 29 June 2022 (UTC)

== Cite physical work ==

Why there is no one template for cite physical work like there is one cite web? There are three different Cite magazine, Cite encyclopedia and Cite book and probably more but maybe there is something universal? What if PDF file isn't a book, magazine or encyclopedia? [[User:Eurohunter|Eurohunter]] ([[User talk:Eurohunter|talk]]) 17:04, 16 June 2022 (UTC)
:Define what a "physical work" is here. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">[[User:Headbomb|Headbomb]] {[[User talk:Headbomb|t]] · [[Special:Contributions/Headbomb|c]] · [[WP:PHYS|p]] · [[WP:WBOOKS|b]]}</span> 18:52, 16 June 2022 (UTC)
::I assume a [[Roman graffiti|wall covered in latin insults]] would be a physical work. [[User:ScottishFinnishRadish|ScottishFinnishRadish]] ([[User talk:ScottishFinnishRadish|talk]]) 18:55, 16 June 2022 (UTC)
:::{{tlx|citation|mode{{=}}cs1|...}} should do the trick here. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">[[User:Headbomb|Headbomb]] {[[User talk:Headbomb|t]] · [[Special:Contributions/Headbomb|c]] · [[WP:PHYS|p]] · [[WP:WBOOKS|b]]}</span> 18:59, 16 June 2022 (UTC)
:Are you thinking of citing something like the [[Orkhon inscriptions]]? [[User:Gråbergs Gråa Sång|Gråbergs Gråa Sång]] ([[User talk:Gråbergs Gråa Sång|talk]]) 19:00, 16 June 2022 (UTC)
:: {{re|Gråbergs Gråa Sång}}, {{re|Headbomb}},{{re|ScottishFinnishRadish}} Wrong translation. I mean every [[:Category:Publications by format|printed work]] such as magazine, encyclopedia, book etc. [[User:Eurohunter|Eurohunter]] ([[User talk:Eurohunter|talk]]) 19:22, 16 June 2022 (UTC)
:::@[[User:Eurohunter|Eurohunter]] If you cite a book you are holding in your hand, you use the same template, just don't add a weblink/url. Those are not mandatory, just practical when available. [[User:Gråbergs Gråa Sång|Gråbergs Gråa Sång]] ([[User talk:Gråbergs Gråa Sång|talk]]) 19:26, 16 June 2022 (UTC)
::::{{re|Gråbergs Gråa Sång}} I mean if it not book or magazine. What then? [[User:Eurohunter|Eurohunter]] ([[User talk:Eurohunter|talk]]) 19:28, 16 June 2022 (UTC)
:::::Example? [[User:Gråbergs Gråa Sång|Gråbergs Gråa Sång]] ([[User talk:Gråbergs Gråa Sång|talk]]) 19:29, 16 June 2022 (UTC)
{{csdoc|cs1}} 
:::::There are plenty available - see box at right. Whilst all of them accept a {{para|url}} parameter, they are primarily for hardcopy sources, with the exception of {{tlx|cite AV media}}, {{tlx|cite episode}}, {{tlx|cite web}} and one or two others. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 19:49, 16 June 2022 (UTC)
::::::{{re|Gråbergs Gråa Sång}} {{re|Redrose64}} I mean their PDF versions so sometimes it's document which is not book or magazine - no one know what it exactly is so it need wider term than book or magazine. [[User:Eurohunter|Eurohunter]] ([[User talk:Eurohunter|talk]]) 19:50, 16 June 2022 (UTC)
:::::::If the pdf is a scan of a book, just cite to the book. If it's an original pdf, I would think that you would cite the website it came from.--[[User:Khajidha]] ([[User talk:Khajidha|talk]]) ([[Special:Contributions/Khajidha|contributions]]) 21:02, 16 June 2022 (UTC)
:::::::If there actually is a proposal in this section, it is hard to figure. The heading mentions "physical work" (presumably as opposed to a virtual work), but the OP mixes it up by mentioning pdf, a (virtual) file format. I was under the impression that the OP was asking for a catch-all {{tlf|cite xxx}} template for physical (real) works with no specific classification, similar to the way {{tlf|cite web}} may be used for some (virtual) online works, when such works cannot be otherwise classified. But the continuing references to pdf make me wonder. [[Special:Contributions/50.75.226.250|50.75.226.250]] ([[User talk:50.75.226.250|talk]]) 14:48, 17 June 2022 (UTC)
::::::::You can use {{tl|cite document}}.
::::::::The point isn't to classify the source.  The point is to get a properly formatted citation for the kind of thing that you're citing.  In this case, magazine articles and generic documents use the same citation formatting, so it's the same template.  You can use the redirect name if you want. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 00:50, 23 June 2022 (UTC)
:::::::The whole point of citing anything is so the reader can go check the source and verify the claim. If you don't know what medium what you're citing even is, better not cite it. [[User:Nardog|Nardog]] ([[User talk:Nardog|talk]]) 01:27, 23 June 2022 (UTC)
::::::::I dunno about that.  The difference between "an article" and "a report", or between "a long report" and "a short book" can be difficult to discern.  That doesn't make the source unusable. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 01:50, 23 June 2022 (UTC)
:::::::The UI tools have book, journal, news, and web. So in practice a lot of people will use the closest one of those. I imagine most other-language Wikipedias don't have the plethora of citation templates that we we do on w:en. ⁓&nbsp;[[User:Pelagic|Pelagic]] (&nbsp;[[User talk:Pelagic|messages]]&nbsp;) 21:37, 2 July 2022 (UTC)

== Reverting the old version of the Philippine name template  ==

Good day!
I want to change something to [[Template: Philippine name|Template: Philippine name]], what I want to happen is to return that term Philippine customs instead of Philippine name because for me, it's almost the same as [[Template: Portuguese name|Template: Portuguese name]] and sometimes there is a letter "Ñ" in the last name which is I thought I would return that old template that states the details about the presence of "Ñ" in the last name. 
Please give me permission to change the details a bit. 
I ask for your patience and understanding if you think I am interfering with you. 
Thank you 
[[User:RenRen070193|RenRen070193]] ([[User talk:RenRen070193|talk]]) 07:11, 6 July 2022 (UTC)
:The place for this discussion is at [[Template talk:Philippine name]]. I can't follow your argument there. Perhaps you could give some examples for your proposal and an explanation why you think your version is superior? —[[User:Kusma|Kusma]] ([[User talk:Kusma|talk]]) 08:24, 6 July 2022 (UTC)
::Kindly check this: 
::In this name that follows [[Filipino name|Philippine naming customs]], the middle name, Cruz, is a patronymic, not the maternal family name, and the surname is Santos. [[User:RenRen070193|RenRen070193]] ([[User talk:RenRen070193|talk]]) 12:03, 6 July 2022 (UTC)

==The situation at colors==
Gulp, well I started something that I hope gains acceptance but at least others can look, advise, complain, etc.  The situation:

[[Blue]] gets about 1400 views/day.  Prior to yesterday, the article was 123,000 bytes long.  It consisted of two main themes: technical content (optics, dyes, natural occurrence) and cultural material (artwork, symbolism). The cultural material included about 20-30% bulleted lists of where blue is somehow significant (politics, gender, sports, religion...).

So I split the article into [[blue]], which retains and expands the technical content (34,000 bytes and growing) AND [[colour blue in culture]] (86,000 bytes).  I have been actively cleaning up [[blue]].  I had asked the color project about my idea but concluded that that project was moribund.  So I proceeded.  [[Talk:Blue#Colour blue in culture|Here]], [[User:Mathglot]] comments on my edits and urges me to reach out more broadly, hence this message.

The implications of my actions are nontrivial because articles on colors are heavily consulted, and my action on [[blue]] vs [[colour blue in culture]] could be a model for future actions on primary and maybe secondary colors. These color articles tend to accrete a lot of imagery and factoids, by the way.

Another component of this message is that I could use some help. I will stop my editing of these articles if concerns outweigh support for this venture. --[[User:Smokefoot|Smokefoot]] ([[User talk:Smokefoot|talk]]) 18:15, 24 June 2022 (UTC)

: {{courtesy link|Talk:Blue#Colour blue in culture|Previous discussion:}} 
: Smokefoot is a good faith editor who initiated an undiscussed split of [[Blue]], and has been doing a good job of tidying up. While the split was a [[WP:BOLD]] move, I see no reason to undo it at this point. However, as this may lead to similar splits at a number of other color articles ([[Orange (colour)]], [[Green]], [[Red]], etc.) I suggested at the Talk page that {{they|Smokefoot}} seek consensus for future color-article splits at a forum with better traffic than an inactive project, and here we are. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 18:29, 24 June 2022 (UTC)
::Why do we need consensus to split articles? Is there disagreement? This seems inline with [[WP:BRD]] — [[User:PerfectSoundWhatever|<span style="letter-spacing:0.1em;">PerfectSoundWhatever</span>]] ([[User talk:PerfectSoundWhatever|t]]; [[Special:Contributions/PerfectSoundWhatever|c]]) 01:58, 25 June 2022 (UTC)
::: I don't think you ''need'' consensus, but it's a good idea for a large and high-profile article like this, per [[WP:CAUTIOUS]] (which is policy, though a rather gently-phrased one). It's also good for the person making the changes, so that they don't end up doing a lot of work for nothing. But most of our articles and Wikiprojects bear rather obvious evidence to the fact that nobody's around to hear any proposals anymore, which I guess is why this would end up on the Village Pump. -- [[User:Visviva|Visviva]] ([[User talk:Visviva|talk]]) 05:00, 25 June 2022 (UTC)
:The split seems logical to me. As for the other colours question, it should logically be dealt with on a case to case basis, when a section of an article becomes too long per [[WP:SPLIT]]. I'll try to help out to improve [[Blue]] where I think it could need it. But {{ping|Smokefoot}}, shouldn't the title of the article be [[Blue in culture]]? What else would "blue" refer to? — [[User:PerfectSoundWhatever|<span style="letter-spacing:0.1em;">PerfectSoundWhatever</span>]] ([[User talk:PerfectSoundWhatever|t]]; [[Special:Contributions/PerfectSoundWhatever|c]]) 01:35, 25 June 2022 (UTC)
::Perhaps [[Blues]] may be confused with this? <span style="font-family:Iosevka,monospace">0x[[User talk:0xDeadbeef#top|<span style="text-transform:uppercase;color:black">'''Deadbeef'''</span>]]</span> 02:11, 25 June 2022 (UTC)
:::I've never heard the non-plural "blue" used to refer to the genre. A hatnote to pointing [[Blues#In_popular_culture]] would probably solve any unlikely confusion. — [[User:PerfectSoundWhatever|<span style="letter-spacing:0.1em;">PerfectSoundWhatever</span>]] ([[User talk:PerfectSoundWhatever|t]]; [[Special:Contributions/PerfectSoundWhatever|c]]) 02:13, 25 June 2022 (UTC)
::::{{replyto|PerfectSoundWhatever}} [[Blue note]]. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 17:12, 25 June 2022 (UTC)
:Honestly, I'm not seeing an intrinsically difference, topic-wise, between the color and the culture around the color, the essence of blueness is the core of each. Having said that, that is more of a preference and certainly not something to war over, or even vote to re-combine if it ever came to that. It is what it is. I do think [[Blue in culture]] would stylistically be a better title, per above, too. [[User:Zaathras|Zaathras]] ([[User talk:Zaathras|talk]]) 02:10, 25 June 2022 (UTC)
:The split seems reasonable to me, and I applaud the use of a summary section in the main [[Blue]] article. But then again I have no idea what people are looking for when they search for a topic like "Blue", which would be a helpful thing to know in terms of how our coverage of topics like this should be configured. I wonder if there is any quantitative data on this. Are they looking for a definition? Technical information? Pretty pictures of blue stuff? -- [[User:Visviva|Visviva]] ([[User talk:Visviva|talk]]) 05:05, 25 June 2022 (UTC)
:I Think that splitting blue in culture away from blue in optics is a very bad idea, It greatly reduces the utility and quality of both articles. Now you have to search two different articles to find basic information that should be in one. the German, Spanish and French Wikipedias do not split up color articles. the  reduced lead montage on blue is also very unsatisfactory. Please return to a single article on each color, and use the format used in the other color articles. SiefkinDR (talk) 15:54, 25 June 2022 (UTC)
* Wikipedia has a chronic bias toward the technical aspects of a topic over the cultural aspects. That's both because of the interests/background of the majority of editors, and because the technical aspects are easier to write about than the cultural aspects, especially for broad topics. When something has both technical and cultural aspects, like a color, there's substantial risk of poor weighting. So while I'll leave it to your discretion whether to split out the culture section, {{u|Smokefoot}}, the main article [[blue]] will almost surely have far more pageviews, so I'd definitely urge you to consider starting from a broad level how to make sure there's enough [[WP:DUEWEIGHT]] for the cultural aspects in that article. <span style="color:#AAA"><small>&#123;{u&#124;</small><span style="border-radius:9em;padding:0 5px;background:#088">[[User:Sdkb|<span style="color:#FFF">'''Sdkb'''</span>]]</span><small>}&#125;</small></span> <sup>[[User talk:Sdkb|'''talk''']]</sup> 19:38, 25 June 2022 (UTC)
*:Spitballing here, this is probably a really bad idea but, what if we had one article [[Blue in science]] (or whatever title), and then [[Blue in culture]], where [[Blue]] is a [[WP:SUMMARYSTYLE]] of both? — [[User:PerfectSoundWhatever|<span style="letter-spacing:0.1em;">PerfectSoundWhatever</span>]] ([[User talk:PerfectSoundWhatever|t]]; [[Special:Contributions/PerfectSoundWhatever|c]]) 20:08, 25 June 2022 (UTC)
*:: {{re|PerfectSoundWhatever}} It's not such a bad idea, because having [[Blue]] as the [[WP:G#Parent article|parent article]] of two [[WP:G#Child article|child articles]] would solve the [[WP:DUEWEIGHT]] issue at [[Blue]], and also allow the child articles to be independently developed to different sizes without regard to due weight, which only applies within articles and not across them. <small>(That is, [[Shape of the Earth]] is 23 kb and barely says anything about "Flat Earth" theories, because it would be highly [[WP:UNDUE]] in that article for such a FRINGE theory, but the article [[Flat Earth]] itself is triple the size (77 kb), which is perfectly fine, because it is restricted to its own space and UNDUE does not apply. Same thing for articles like [[Fringe theories about the Shroud of Turin]]: once split off, they have their own DUEWEIGHT considerations that do not apply outside the article.)</small> In this same way, [[Blue]] is 43kb (up from 30kb at the split), and [[Blue in culture]] is over twice that, which isn't a problem now, but might be a problem in a unified article, depending what one considers the appropriate WEIGHT between cultural and other aspects. As far as overall size is concerned, studies show that most readers don't even read past the LEAD of an article, so the idea of making [[Blue]] into a relatively brief article in [[WP:SUMMARY STYLE]] with a couple of smallish body sections summarizing optics or science on the one hand, and culture on the other, is not such a bad one, and would solve several of the problems mentioned above, while still serving our readers well without an overly long article that they won't read anyway; readers may even be *more* likely to read about both the science *and* the cultural aspects if the article is considerably shorter. (Wouldn't call it 'Blue in science' though; maybe 'Optics of blue' or something; t.b.d.) [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 19:44, 27 June 2022 (UTC)
*:::{{re|Mathglot|Smokefoot}} I created a mockup of the above in my sandbox: [[User:PerfectSoundWhatever/sandbox]] <small>([https://en.wikipedia.org/w/index.php?title=User:PerfectSoundWhatever/sandbox&oldid=1096774359 revision for when I change my sandbox])</small>, with the accompanying new article "Blue in science" here: [[User:PerfectSoundWhatever/sandbox/2]]. Obviously, I left some summaries blank, and some summaries would certainly need to be expanded, but it gets the structure across.
*:::Honestly, this had made me realize that just having [[Blue]] in one article might be the best option. The current implementation of the split just doesn't really work, although a variation of my mockup ''might''. — [[User:PerfectSoundWhatever|<span style="letter-spacing:0.1em;">PerfectSoundWhatever</span>]] ([[User talk:PerfectSoundWhatever|t]]; [[Special:Contributions/PerfectSoundWhatever|c]]) 15:20, 6 July 2022 (UTC)
*I agree with the above. "Blue" is not exclusively an article about optics; blue in culture is equally important, and should have equal space in the article. It does not make sense to have the article on "Blue" that completely ignore history, art and culture.[[User:SiefkinDR|SiefkinDR]] ([[User talk:SiefkinDR|talk]]) 20:12, 25 June 2022 (UTC)
*I agree with the split, but per [[WP:CORRECTSPLIT]] #6, the parent article [[Blue]] should still contain a brief summary of [[blue in culture]]. [[User:Levivich|Levivich]]<sup class="sysop-show">[''[[Special:Block/Levivich|block]]'']</sup> 19:54, 27 June 2022 (UTC)
*: Not clear if you're talking about how it was, or how it is now. With 8 kb in the culture section at [[Blue]], that section is half-again larger than the science section.  I'd say that's probably too long for one  [[WP:Summary style|summary style]]-section in a [[WP:G#Parent article|parent article]] for which a stand-alone [[WP:G#Child article|child article]] exists. Or perhaps that's what you meant? [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 23:39, 27 June 2022 (UTC)
*::I posted my comment one minute before Smokeyfoot added a 6k summary. What a fast typist! :-) [[User:Levivich|Levivich]]<sup class="sysop-show">[''[[Special:Block/Levivich|block]]'']</sup> 00:16, 28 June 2022 (UTC)
* '''Oppose''' This split seems quite arbitrary as the original article still contains sections about clothing, religion and other cultural aspects.  Denigrating some cultural aspects in this way is unwise because it tends to generate a repeating cycle.  See [[WP:CARGO]] for details.
: When a reader goes to a [[WP:BROAD|broad]] topic such as [[blue]], they may have something specific in mind or they may wish to browse.  To assist their navigation, we should address the topic at quite a high level as there are likely to be many sub-articles such as [[shades of blue]], [[Blue (university sport)]] and so on.  Just about every aspect has some cultural implications and so that's not a useful sub-division.
: Note also that the concept of blue is not universal as some languages such as [https://www.newscientist.com/article/dn11759-russian-speakers-get-the-blues/ Russian] do not have a single corresponding word.  So, the very concept is a cultural artifact.  
: See also ''[[The Two Cultures]]''. [[user:Andrew Davidson|Andrew]]🐉([[user talk:Andrew Davidson|talk]]) 21:42, 28 June 2022 (UTC)
::We have data on the advisability of the split:
*[[Red in culture]]: 456 Page views in the past 30 days.
*[[Red ]]: 34,354 Page views in the past 30 days.
::Now, we could remerge *[[Red in culture]] and [[Red ]] because we know what is good for readers.  Or we can recognize that [[Red]] is providing the information sought, by and large.--[[User:Smokefoot|Smokefoot]] ([[User talk:Smokefoot|talk]]) 23:35, 28 June 2022 (UTC)
::: [[Red in culture]] is another arbitrary and unhelpful split.  Note that it has a section [[Red_in_culture#In_religion|In religion]] which seems identical to the same section in the main article.  It's just a [[WP:REDUNDANTFORK]] and so "''the more recent article should be merged back into the main article''". [[user:Andrew Davidson|Andrew]]🐉([[user talk:Andrew Davidson|talk]]) 12:52, 29 June 2022 (UTC)
::::It appears that the current situation is stable, i.e., [[Blue]], containing a hefty survey of cultural aspects, and [[Blue in culture]] with a more in depth description of blue in culture.  The readership statistics appear poised to mirror those for lightly consulted [[Red in culture]] vs highly consulted [[Red]].  Editors express a variety of opinions above, ranging from the split was ill-conceived/inept to the idea that we should force readers to read more about culture.  One thing we can all agree on: gratitude to [[user:SiefkinDR]], who over the previous week or two has dedicated much effort and insight into making [[Blue]] an article that should appeal to our readership. --[[User:Smokefoot|Smokefoot]] ([[User talk:Smokefoot|talk]]) 15:43, 6 July 2022 (UTC)

== A single letter with a period should always be disambiguated ==

Most instances of a letter of the English alphabet followed by a period point to a disambiguation page for that letter (see [[A.]], [[B.]], [[C.]], [[D.]], [[E.]], [[F.]], [[G.]], [[H.]], [[I.]], [[K.]], [[N.]], [[O.]], [[P.]], [[Q.]], [[S.]], [[T.]], [[U.]], [[W.]], [[X.]], [[Z.]]).

There are, however, precisely '''six''' letters for which the letter-with-period is either a redirect to another article on a specific topic (i.e., a magazine, book, album, or person), or the title of an actual article, and would ask that editors ''try to guess'' what the article in question will be ''before'' hovering/clicking the link. I would imagine that in most cases [[WP:ASTONISH|it will be a surprise]]. These letters are: [[J.]], [[L.]], [[M.]], [[R.]], [[V.]], [[Y.]]

Because of the ubiquitous use of letters as abbreviations, I assert that there can never be a true primary topic for any instance of a single letter of the alphabet followed by a period. Although this could be addressed through a series of [[WP:RM]] and [[WP:RFD]] discussions, I think that it would be cleaner to have a single discussion of the broader principle. I therefore propose:

'''All instances of a single letter with a period should be redirected to the disambiguation pages for the respective letters, with the two at article titles being moved to appropriate disambiguators, and with the rule being established that a letter of the alphabet followed by a period should not have a specific subject as its primary topic.'''

Cheers! [[User:BD2412|<span style="background:gold">'''''BD2412'''''</span>]] [[User talk:BD2412|'''T''']] 16:04, 25 June 2022 (UTC)
*'''Oppose''', if there is a primary topic, we should not use unnecessary disambiguation, consistent with the rest of the encyclopaedia. Readers are unlikely to care for consistency between the pages presented here. —[[User:Kusma|Kusma]] ([[User talk:Kusma|talk]]) 16:21, 25 June 2022 (UTC)
*:And '''strong oppose''' for [[L.]], the most famous abbreviation in biology. —[[User:Kusma|Kusma]] ([[User talk:Kusma|talk]]) 16:23, 25 June 2022 (UTC)
*::I'm not sure about the "in biology" there. Maybe in the taxonomy of biological organisms, which is only a small part of biology. [[User:Phil Bridger|Phil Bridger]] ([[User talk:Phil Bridger|talk]]) 17:08, 25 June 2022 (UTC)
*:::I'd also expect the most well-known taxonomic abbreviation to be the clear primary topic, but the data makes that seem shaky. In January, the redirect [[L.]] got 144 views, while the traffic from [[Carl Linnaeus]] to [[L (disambiguation)]] amounted to 67 link referrals. – Uanfala ([[User talk:Uanfala|talk]]) 18:31, 25 June 2022 (UTC)
*::::Some of these will be clicks out of random curiosity though, and it is unclear how many of these are by people searching for something else and redirected through [[L.]] (many people seem to click the top couple of links no matter what they are). I don't know if there is any better data that would help us figure this out, or ways to interpret this better. Pinging @[[User:WhatamIdoing|WhatamIdoing]] as I first heard about the clickstream tool from her whether she has further insight. —[[User:Kusma|Kusma]] ([[User talk:Kusma|talk]]) 18:42, 25 June 2022 (UTC)
*:::::Anyone can try it out.  For example, [https://wikinav.toolforge.org/?language=en&title=V. https://wikinav.toolforge.org/?language=en&title=V.] shows that most traffic from [[V.]] comes from the author's article and the most popular destination is to the article (presumably, this is mostly people who didn't start at that article).  Only about 3% have gone to the dab page.
*:::::By contrast, the lower-traffic https://wikinav.toolforge.org/?language=en&title=V_(disambiguation) mostly sees people going to several television series.  It would not seem unreasonable to me to move the book to [[V. (novel)]] (an existing redirect), with the idea that people might be looking for those television programs, but I'm not sure that it's an urgent task.   [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 21:20, 25 June 2022 (UTC)
*::::::As King of Hearts points out below, when the dab isn't at the base title, it's difficult to draw watertight conclusions. Still, the data for V. can be informative. There were 53 clicks from [[V.]] to the dab page: that's 3% of the total outgoing traffic recorded in the dataset, but that excludes targets with fewer than 10 hits for the month, and it obviously doesn't account for readers who don't click onwards. A more meaningful ratio can be arrived at by comparing with the 7.5 thousand total views of the article for the same period. This means that only about 0.7% of visitors of the article followed the link to the dab. If the ratio were about ten times higher, I'd get suspicious of the primary topic status. But 0.7% is a good signal that things probably are fine where they are. I don't think the outgoing  traffic from [[V (disambiguation)]] has much bearing here: we're not interested in readers searching for "V", we're interested in the ones who search for "V" + full stop. – Uanfala ([[User talk:Uanfala|talk]]) 21:40, 25 June 2022 (UTC)
*:Having said that, I do find Y. and J. rather questionable, but would suggest to do these case by case. —[[User:Kusma|Kusma]] ([[User talk:Kusma|talk]]) 18:21, 25 June 2022 (UTC)
:I went ahead and converted [[R.]] into a formal disambiguation page because, as it was, the page was already a disambiguation page written as prose (it just described a bunch of different definitions of "R."). It was either that or nominate it for deletion per [[WP:NOTDICTIONARY]]. --[[User:Ahecht|Ahecht]] ([[User talk:Ahecht|<span style="color:#FFF;background:#04A;display:inline-block;padding:1px;vertical-align:-.3em;font:bold 50%/1 sans-serif;text-align:center">TALK<br />PAGE</span>]]) 16:36, 25 June 2022 (UTC)
:Are readers entering "J.", "V." or "Y." really most likely to be looking for the content that we redirect them to now? [[User:Phil Bridger|Phil Bridger]] ([[User talk:Phil Bridger|talk]]) 17:08, 25 June 2022 (UTC)
::I would never have guessed the target of any of those titles.  In particular [[v.]] case-folds to V., and most readers might expect something on [[case citation]] or sporting rivalries. [[User:Certes|Certes]] ([[User talk:Certes|talk]]) 17:53, 25 June 2022 (UTC)
:::Fortunately we have some data about what readers do! [https://wikinav.toolforge.org/?language=en&title=V.] Some readers seem to click on the disambig page, but many seem to be happy. For L., the disambiguation page is not in the top destinations. —[[User:Kusma|Kusma]] ([[User talk:Kusma|talk]]) 18:18, 25 June 2022 (UTC)
::::That says nothing at all about whether readers "seem to be happy". My guess, and it's only a guess because I'm not taken in by such spurious data, is that many readers simply go to other sites when they don't see what they are looking for here. [[User:Phil Bridger|Phil Bridger]] ([[User talk:Phil Bridger|talk]]) 18:25, 25 June 2022 (UTC)
:::::If they find a better encyclopaedia somewhere else, I would be curious to know where. —[[User:Kusma|Kusma]] ([[User talk:Kusma|talk]]) 18:34, 25 June 2022 (UTC)
::::::Who said anything about a better encyclopaedia? People do web searches for what they are lokking for, and if a semi-reliable site such as Wikipedia doesn't give it they go to a completely unreliable site. [[User:Phil Bridger|Phil Bridger]] ([[User talk:Phil Bridger|talk]]) 18:41, 25 June 2022 (UTC)
:::::::If I Google (also Google Books!) for "V.", I don't get [[V.]] on the first page of results. Instead, I get a bunch of random crap called "V", not "V.". Wikipedia seems more precise here. —[[User:Kusma|Kusma]] ([[User talk:Kusma|talk]]) 18:46, 25 June 2022 (UTC)
:::::Yeah, why should we bother with the data when ''guesses'' are so much better! – Uanfala ([[User talk:Uanfala|talk]]) 18:36, 25 June 2022 (UTC)
::::::Reliable data is good for what it covers. This data says nothing about the happiness of readers. [[User:Phil Bridger|Phil Bridger]] ([[User talk:Phil Bridger|talk]]) 18:41, 25 June 2022 (UTC)
:::::::I admit that I over-interpreted the data. But I think there were some people who did serious analysis of such data, and we should listen to them if they can teach us what it means (that's why I pinged WAID above). Perhaps "wrong target frustration" can be measured. —[[User:Kusma|Kusma]] ([[User talk:Kusma|talk]]) 18:48, 25 June 2022 (UTC)
::::::::If you want people who do serious analysis, you want to be talking to [[User:MGerlach (WMF)]] or other folks on his team. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 21:22, 25 June 2022 (UTC)
:::::In general, pageview and/or clickstream data is of little value when used in support of keeping a primary topic in place. When a disambiguation page currently occupies the main title, then statistics are helpful for determining which of the disambiguated topics are most prominent. And when there is an existing primary topic in place, being beat out by another topic is a good sign that the former is not actually the primary topic. But by virtue of occupying the main title, the data will be inherently biased in favor of the current primary topic, so we are limited in what we can interpret from it. -- [[User:King of Hearts|<b style="color:red">King of ♥</b>]][[User talk:King of Hearts|<b style="color:red"> ♦</b>]][[Special:Contributions/King of Hearts|<b style="color:black"> ♣</b>]][[Special:EmailUser/King of Hearts|<b style="color:black"> ♠</b>]] 19:32, 25 June 2022 (UTC)
::::::There is also the question of what readers are looking for.  Sometimes, the thing I want to know is on the dab page.  I don't need to click after that; therefore, there is no clickstream data to indicate that I found the name/word/thing that I was searching for. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 21:23, 25 June 2022 (UTC)
:We should assess each case on its merits rather than making an arbitrary rule.  [[J.]], [[R.]], [[V.]] and [[Y.]] seem clear-cut with very strong cases for change.  [[L.]] and [[M.]] probably need an RM/RfD. [[User:Certes|Certes]] ([[User talk:Certes|talk]]) 19:24, 25 June 2022 (UTC)
*This seems like a good proposal to me, because a letter followed by a period is never going to have a ''primary'' topic (although I can see the case for [[L.]] and [[M.]]). Bearing in mind that we are here to build an encyclopedia and not a website, that seems like a sufficient reason for avoiding these, even if the existing arrangement doesn't disserve website users. OTOH, internal links provide another kind of information, and when I clicked on some backlinks for [[V.]] that I thought were questionable, I was surprised to find that all of them did in fact relate to the Pynchon novel. So unless there's been some recent cleanup, some of these may be more primary than they appear. (But I haven't clicked on all 115 incoming links.) As a side note, is there a tool that would give a concordance-style view of the wikitext generating the incoming links to a particular page? I've just been clicking through [[Special:Whatlinkshere]] and ctrl-F'ing the wikitext, but that seems kind of inefficient. -- [[User:Visviva|Visviva]] ([[User talk:Visviva|talk]]) 19:43, 25 June 2022 (UTC)
*:I usually go for an "insource:" search ([https://en.wikipedia.org/w/index.php?search=linksto%3A%22V.%22+insource%3A%2F%5C%5BV%5C.%2Fi&title=Special:Search&profile=advanced&fulltext=1&ns0=1 example]), though I suspect someone here may come up with a more elegant solution. – Uanfala ([[User talk:Uanfala|talk]]) 19:49, 25 June 2022 (UTC)
*::A search for <code>linksto:"V." -Pynchon</code> yields just one result: a false positive.  I don't know how many links were once wrong; there are [[WP:BPAT|people]] who fix such things. [[User:Certes|Certes]] ([[User talk:Certes|talk]]) 21:47, 25 June 2022 (UTC)
*::Ooh, thank you very much! MW internal search seems to have improved a great deal since whenever I last tried to use it for anything. -- [[User:Visviva|Visviva]] ([[User talk:Visviva|talk]]) 04:53, 26 June 2022 (UTC)
* <b> Oppose</b>, while [[WP:ASTONISH]] is a very integral part of the manual of style, I have a hard time finding sympathy for readers who look things up in the search bar just to see what comes up, and then get surprised at the result. If [[L.]] is a common abbreviation for Carl Linnaeus in reliable sources, and there's no better target, then I don't see why the link shouldn't stay as is. The other letter-with-period links will require their own "investigations", and a page-move may be necessary in some cases, but I oppose uniformly moving all of them into dab pages. --<b>[[User:VersaceSpace|<span style="color: black">VersaceSpace</span>]]</b> [[User talk:VersaceSpace|🌃]] 23:18, 25 June 2022 (UTC)
*'''Strong support''' per nom. The letters-followed-by-a-period's primary topic will probably be the letter, which is why the letter article is at the top of every letter disambiguation page. I do not believe that most readers typing in "L." in the search bar are looking for [[Carl Linnaeus]]. Some, sure, but not most. ''Even if'' Carl Linnaeus is the primary topic for L. in biology, that's still ''in biology'', which is just one subject. That doesn't make it the primary topic for all subjects, for ''everything''. I think it will surprise most readers if "L." redirects to pretty much anything other than a dab page or [[L]], and let's be honest, we don't really know what someone is looking for when they put a period after a letter in the search bar. Is it a typo? The dab pages make the most sense as a target. [[User:Levivich|Levivich]]<sup class="sysop-show">[''[[Special:Block/Levivich|block]]'']</sup> 04:42, 26 June 2022 (UTC)
*'''Oppose''' a rule. If anyone thinks a title takes them to the wrong place they can nominate it at [[WP:RfD]] and/or for [[WP:RM]] as appropriate, and that includes single letters followed by a full stop, so there is no need for this policy. In addition to not being needed now, it could easily cause problems in future if something named in this pattern becomes a clear primary topic (e.g. an American president or global superstar band called "M." could easily become primary topic). [[User:Thryduulf|Thryduulf]] ([[User talk:Thryduulf|talk]]) 09:09, 26 June 2022 (UTC)
*[[File:OOjs UI icon subtract-destructive.svg|18px|link=]]&nbsp;'''Oppose'''<!-- [[User:Tol/Template/Quick reply]] --> per [[WP:INSTRUCTIONCREEP]]. This is overly specific.&nbsp;&#8213;&nbsp;<span id="Qwerfjkl:1656254686648:WikipediaFTTCLNVillage_pump_(proposals)" class="FTTCmt">[[User:Qwerfjkl|<span style="background:#1d9ffc; color:white; padding:5px; box-shadow:darkgray 2px 2px 2px;">Qwerfjkl</span>]][[User talk:Qwerfjkl|<span style="background:#79c0f2;color:white; padding:2px; box-shadow:darkgray 2px 2px 2px;">talk</span>]] 14:44, 26 June 2022 (UTC)</span>
*'''Oppose as worded''' / '''Support in general''' Never say never. All could redirect to a DAB be default, but may redirect elsewhere only per consensus (at a RM discussion, etc.).  Rgrds. --[[User:Bison X|Bison X]] ([[User talk:Bison X|talk]]) 22:34, 26 June 2022 (UTC)
*'''Oppose.''' Per [[WP:SMALLDETAILS]], {{tq|V.}} is not the same as {{tq|V}}, and so on. Relatedly, it doesn't strike me as especially likely that someone searching for a letter will append a period when they could just as easily input the character alone. I think it makes sense to raise the disambiguation question on a case-by-case basis, but in my opinion a one-size-fits-all rule would do more harm than good. [[User:ModernDayTrilobite|ModernDayTrilobite]] ([[User talk:ModernDayTrilobite|talk]] • [[Special:Contributions/ModernDayTrilobite|contribs]]) 21:01, 28 June 2022 (UTC)
** I don't think [[WP:SMALLDETAILS]] is suitable for single letters, because there are countless instances where they will be used interchangeably with or without a period. For example, both [[UV]] and [[U.V.]] redirect to [[Ultraviolet]], both [[NJ]] and [[N.J.]] redirect to [[New Jersey]], and the punctuated "J" in [[J.League]] refers to Japan. [[User:BD2412|<span style="background:gold">'''''BD2412'''''</span>]] [[User talk:BD2412|'''T''']] 00:30, 30 June 2022 (UTC)
* Who will go through and pipe all the existing <code><nowiki>[[L.]]</nowiki> </code> links? Or do we consistently use {{tlx|L.}} already? Oh, I tried Certes' suggestion and was surprised to get only 85 hits for <code>linksto:"L."</code> Support Dab for J. V. Y., unsure for M. → Monsieur. Also support it as a general principle for the search use-case, if linking isn't a factor. If I type "V." in the search box, I would expect to find other things with a standalone V, with or without the dot, such as "V (TV series)", or "V for Vendetta". Why is some novel from the '60s a better result because it has the dot? The dab page gives me  options; the search suggestions drop-down gives me others, like "V.C. Andrews". (I view the proposal as "let's have one discussion instead of six separate ones", rather than "let's write this into policy".) ⁓&nbsp;[[User:Pelagic|Pelagic]] (&nbsp;[[User talk:Pelagic|messages]]&nbsp;) 11:59, 4 July 2022 (UTC)
** I will gladly undertake the piping task, as routine disambiguation fixing. [[User:BD2412|<span style="background:gold">'''''BD2412'''''</span>]] [[User talk:BD2412|'''T''']] 00:22, 7 July 2022 (UTC)

== TemplateScripts = Templates + JavaScript ==

Hi! I'd like to propose enabling [[Commons:Help:TemplateScripts|TemplateScripts]] on the English Wikipedia. It's not a MediaWiki extension, but a few lines of JavaScript added to [[MediaWiki:Common.js]] that basically allow to run JavaScript from templates, '''as long as the code is on the MediaWiki namespace and with the "TemplateScript-" prefix''', which requires an authorized user and community consensus to get there.

The system is enabled on the Spanish Wikipedia where it's used for easy signing of polls and projects (see blue button [[:es:Wikiproyecto:Veganismo/participantes|here]]), for navigating [[Template:Excerpt#Excerpt trees|excerpt trees]] (see box with tree icon [[:es:Discusión:Ciencia|here]]) for injecting interactive widgets on some articles ([[:es:Hormiga de Langton|here]] and [[:es:Juego de la vida|here]]) and more recently for creating interactive forms that inject content into other pages (see template [[:es:Plantilla:Formulario|here]], soon to be used on admin boards).

However these are only teasers. It doesn't require much effort to imagine countless other useful applications. So what do you think? [[User:Sophivorus|Sophivorus]] ([[User talk:Sophivorus|talk]]) 21:12, 29 June 2022 (UTC)

:Wait wait, is this another one of those "Check every single page load to see if it has text on it, then go load a script" requests? We've shot those down a LOT. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 23:00, 29 June 2022 (UTC)
::...and yep it appears to be.  This should be fixed in core or with an extension, not with this sort of hack.  Even an extension was refused by developers (c.f. [[phab:T8883]]). It looks like the next possible incarnation is [[phab:T241524]]. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 23:06, 29 June 2022 (UTC)
:::This is not a "hack", it's a pretty reasonable implementation. It's also similar to withJS -- with the difference that withJS looks at URL params while this looks at html attributes on the page. The server-side implementation from [[phab:T241524]] has its own limitations – as it requires the script to be a gadget, and EVERY gadget adds javascript to EVERY page load since all gadgets are RL modules that need to be registered by the startup module. That doesn't scale once you have too many gadgets. TL;DR is that putting something in core or an extension isn't a magic solution to performance problems. – [[User:SD0001|<span style="font-weight: bold; color: #C30">SD0001</span>]] ([[User talk:SD0001|talk]]) 08:46, 3 July 2022 (UTC)
:I would prefer something more focused on improving the encyclopedia. JavaScript is a potential security nightmare and there would need to be a good reason to add more. This tool would appear to give enthusiasts an ability to add animations and games which may or may not be desirable. However, spending time arguing about such animations and games would definitely be undesirable. [[User:Johnuniq|Johnuniq]] ([[User talk:Johnuniq|talk]]) 23:19, 29 June 2022 (UTC)
::Well, talking of games, I did wish if there were a quiz thing on Wikipedia. 5 or 10 questions everyday. At the end of quiz you get your score, with short descriptions about all questions asked, nudging them to read the article. If we can run DYK daily, this one shouldn't be hard either, except that I presumed it'll probably require a sitewide javascript to run. I firmly believe that it'll help increase engagement and attract more users. <span class="nowrap">&#8212;'''[[User:CX Zoom|CX Zoom]]'''[he/him]</span> <sup class="nowrap">([[User talk:CX Zoom|let's talk]] • {[[Special:Contributions/CX Zoom|C]]•[[User:CX Zoom/X|X]]})</sup> 23:48, 29 June 2022 (UTC)
:::@[[User:CX Zoom|CX Zoom]] We currently can have most anything where someone "clicks a button" kick off a javascript (either via the old ?withJS handler, or with the new gadget argument) - that's how pages like [[WP:TWA]] work. Of course, building and curating constant new quiz data requires volunteers. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 10:16, 30 June 2022 (UTC)
::::@[[User:Xaosflux|Xaosflux]]: I did some TWA on [[Special:Contribs/CX Zoom Alt|my alt account]], and its very interesting, except that the blue button at homepage of [[WP:TWA]] seems to not be working. Can you please check that? <span class="nowrap">&#8212;'''[[User:CX Zoom|CX Zoom]]'''[he/him]</span> <sup class="nowrap">([[User talk:CX Zoom|let's talk]] • {[[Special:Contributions/CX Zoom|C]]•[[User:CX Zoom/X|X]]})</sup> 14:47, 30 June 2022 (UTC)
:::::It [[Wikipedia:Village_pump_(technical)/Archive_198#Fix_Wikipedia_Adventure_by_adding_buttons_to_progress_in_"click_on_edit_button"_steps|seems to be broken]] with certain browsers, but no one has volunteered to work on it (one of the systemic problems that would be even worse if we put script-based workflows in front of readers!). — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 14:54, 30 June 2022 (UTC)
::::How about 1 question everyday based off [[WP:DYK]]. [[User:Sungodtemple|Sungodtemple]] ([[User talk:Sungodtemple|talk]]) 14:07, 30 June 2022 (UTC)
::::: Isn't 1 a bit too low? I think of starting with 5 per day. <span class="nowrap">&#8212;'''[[User:CX Zoom|CX Zoom]]'''[he/him]</span> <sup class="nowrap">([[User talk:CX Zoom|let's talk]] • {[[Special:Contributions/CX Zoom|C]]•[[User:CX Zoom/X|X]]})</sup> 14:52, 30 June 2022 (UTC)
::::::As I discussed at {{section link|Wikipedia:Village pump (idea lab)/Archive 40|Proposal 3: Add quizzes throughout the Main page}}, anyone should feel free to start a quiz (with as many questions as you want a day) to establish a track record of being able to produce them regularly, and to figure out what audience exists for this feature. Whatamidoing helpfully pointed out that [[mw:Extension:Quiz]] exists, though of course that is no guarantee that it would be installed on English Wikipedia. [[User:Isaacl|isaacl]] ([[User talk:Isaacl|talk]]) 01:07, 1 July 2022 (UTC)
:::::::Thanks, [[User:Isaacl|Isaacl]]. FTR, I requested at [[:testwiki:Talk:Main Page]] to install the extension so that I can work on it to present a working model. Thanks! <span class="nowrap">&#8212;'''[[User:CX Zoom|CX Zoom]]'''[he/him]</span> <sup class="nowrap">([[User talk:CX Zoom|let's talk]] • {[[Special:Contributions/CX Zoom|C]]•[[User:CX Zoom/X|X]]})</sup> 07:52, 1 July 2022 (UTC)
::::::::As I suggested in that conversation, you can start now with a non-interactive version to establish your daily track record of quiz generation. Good luck! [[User:Isaacl|isaacl]] ([[User talk:Isaacl|talk]]) 15:25, 1 July 2022 (UTC)

Hi guys! @[[User:Johnuniq|Johnuniq]] Regarding the security risk, isn't it essentially the same as with [[Special:GadgetUsage|default gadgets]] or MediaWiki:Common.js itself? TemplateScripts will just have to go through a similar review process. @[[User:Xaosflux|Xaosflux]] Regarding the overhead, it's a single non-blocking JavaScript line run after the page loads (like all code on MediaWiki:Common.js). If the check doesn't pass, nothing else happens. Isn't it a small price to pay for the potential benefits? Of course an extension or core solution would be even better, but it's been 16+ years since that first request and 3+ since the second. We all know WMF times, priorities and capacity. Here we have a chance to open up the JavaScript field on the spot with minimal overhead and security risks that we already know and handle successfully. If it catches on and demand rises, a core solution will surely follow! [[User:Sophivorus|Sophivorus]] ([[User talk:Sophivorus|talk]]) 15:25, 30 June 2022 (UTC)
:Sounds like it's worth trying to me. Amongst other things, it would enable the kind of interactive graphics that are used all the time in journalism now, and are slowly breaking into academic publishing (e.g. [https://distill.pub/2020/growing-ca/]). Wikipedia is incredibly text-heavy compared to other modern educational resources. This could help us catch up and therefore would definitely be improving the encyclopaedia. &ndash;&#8239;[[User:Joe Roe|Joe]]&nbsp;<small>([[User talk:Joe Roe|talk]])</small> 15:53, 30 June 2022 (UTC)
::I'm not against this. But its' honestly not something that can't just as well be done right now with a default Gadget, loading other gadgets/pages. And I think that shows this isn't the real problem. TemplateScripts isn't going to increase our high quality JS contributions, because if you were not able to write a gadget to fix your problem before, you won't be able to do so any more with this. The Javascript space is already wide open for anyone who can write high quality code with long term compatibility. But that turns out to be a lot harder than most ppl assume it to be. Specifically, I've seen a big lack of understanding of late loading JS, HTML layouting and styling by most JS authors, which is a hold up for lots of the scripts / gadget proposals that I have seen proposed over the years. —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 09:22, 3 July 2022 (UTC)
:::I can't recall the last time a script was held up from being a default gadget due to poor code quality. Rather, the concern has always been "this gadget will cause one line of extra code to run on every page load" which is what this proposal seems to address. – [[User:SD0001|<span style="font-weight: bold; color: #C30">SD0001</span>]] ([[User talk:SD0001|talk]]) 13:32, 3 July 2022 (UTC)
::::Then ppl reviewing the gadgets are not thinking it trough. One liners never matter in the grand scope of things and having 10 of them or 1 of them also doesn't really influence page weight. Page layout stability, printing/text-only compatibility and accessibility however do matter a great deal. —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 08:10, 5 July 2022 (UTC)
:::::I completely agree, but that's something to bring up with the people who give that rationale. Though I still think a couple of generic lines that can be used by many gadgets is better than 1 line per gadget. – [[User:SD0001|<span style="font-weight: bold; color: #C30">SD0001</span>]] ([[User talk:SD0001|talk]]) 16:02, 5 July 2022 (UTC)

Well, with good design, it's possible to create JavaScript-enhanced templates that don't compromise page-layout stability and have reasonable fallbacks for accessibility and printing/text-only mode. However, it's also true that most existing template scripts are meant for namespaces other than the mainspace (all except [[:es:Plantilla:Vivarium|Vivarium]] and [[:es:Plantilla:Formicarium|Formicarium]]). For example, check out [[:es:Wikipedia:Encuestas/2022/Fichas_biográficas|this poll]] where the script for signing I mentioned earlier is being used intensively and constructively for something that will improve the encyclopedia. All that is to say that I could tweak the TemplateScripts initialization code so that they run only on non-mainspace. If their use and demand grows, we may later re-evaluate if and how to enable them on mainspace (perhaps with adequate design guidelines). Thoughts? Support? Objections? Cheers! [[User:Sophivorus|Sophivorus]] ([[User talk:Sophivorus|talk]]) 13:21, 8 July 2022 (UTC)

== Require [[Wikipedia:Requests for page protection]] to protect pages ==

{{archive top|There's clear '''consensus against''' this proposal. [[User:Tol|<span style="color:#f542d7">Tol</span>]] ([[User talk:Tol|talk]] &#124; [[Special:Contribs/Tol|contribs]]) @ 19:13, 12 July 2022 (UTC)}}

I suggest that [[Wikipedia:Protection policy|page protection]] be used only as a response to a valid request from [[Wikipedia:Requests for page protection]]. I believe this will prevent unnecessary protection of pages that are not being [[Wikipedia:Disruptive editing|edited disruptively]]. Protection is not intended to be used as [[WP:PREEMPTIVE|a preemptive measure]]. [[User:FAdesdae378|FAdesdae378]] ([[User talk:FAdesdae378|talk]] <b>·</b> [[Special:Contribs/FAdesdae378|contribs]]) 20:16, 28 June 2022 (UTC)

*Is there a specific issue this is meant to address? I can see plenty of reasons to protect without a specific request at RFPP. [[User:ScottishFinnishRadish|ScottishFinnishRadish]] ([[User talk:ScottishFinnishRadish|talk]]) 20:19, 28 June 2022 (UTC)
*:There are only 1,034 administrators on the English Wikipedia. If there is a valid reason to protect a page, an average Wikipedian would request protection of it before an administrator would. [[User:FAdesdae378|FAdesdae378]] ([[User talk:FAdesdae378|talk]] <b>·</b> [[Special:Contribs/FAdesdae378|contribs]]) 20:38, 28 June 2022 (UTC)
*::Seems a bit arrogant to say that admins only act on requests from us mortals. The ones I see working around the project are pretty damm sharp. I note you didn't answer SFR's "specific issue" point?? - [[User:Roxy the dog|'''Roxy''' <small> the bad tempered</small>]] [[User talk:Roxy the dog|'''dog''']] 20:59, 28 June 2022 (UTC)
* '''Oppose''' This would delay protection in cases where it is needed. I've made several requests at [[WP:RPP/I]] that have taken a while to be reviewed, if an admin noticed a page with a need for protection during that time they would need to request the protection and presumably wouldn't be allowed to act on it themselves, this would significantly delay the time it takes to protect the page. People who unnecessarily protect pages often should be dealt with individually. [[User:PhantomTech|<b>P</b><small>HANTOM<big><b>T</b></big>ECH</small>]] ([[User talk:PhantomTech|talk]]) 20:29, 28 June 2022 (UTC)
*:Administrators should protect pages only in '''uncontroversial''' cases, where any well-intentioned user would agree [[WP:PP|constitutes protection]]. [[User:FAdesdae378|FAdesdae378]] ([[User talk:FAdesdae378|talk]] <b>·</b> [[Special:Contribs/FAdesdae378|contribs]]) 20:49, 28 June 2022 (UTC)
*::If you want to be taken seriously then present evidence that this does not happen already. I note that you seem to be backtracking a bit from your initial proposal. [[User:Phil Bridger|Phil Bridger]] ([[User talk:Phil Bridger|talk]]) 21:20, 28 June 2022 (UTC)
*'''Nope''' if there is an admin routinely making bad protections, bring them to [[WP:AN]]. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 21:00, 28 June 2022 (UTC)
*:Or [[WP:XRV]], depending how that discussion goes. [[User:Curbon7|Curbon7]] ([[User talk:Curbon7|talk]]) 21:23, 28 June 2022 (UTC)
*No. This is [[WP:not a bureaucracy|not a bureaucracy]]. Admins have (unless they have had that status since the early years of Wikipedia) been through a demanding selection process that demonstrates that they are trusted by the community to make such decisions. If one of them betrays that trust then we need to deal with that one admin, not create rules that get in the way of all thousand of them doing their job. [[User:Phil Bridger|Phil Bridger]] ([[User talk:Phil Bridger|talk]]) 21:20, 28 June 2022 (UTC)
*'''No''' &mdash; it's fine if an admin notices a problem and steps in to solve it without a notice being posted on some acronym board first, or if a non-admin sees a problem and makes a direct request of an admin who is [https://apersonbot.toolforge.org/recently-active/?admins currently active]. Mandating that every request be funneled through the same page would just mean a bigger backlog and a worse editing experience all around. [[User:XOR&#39;easter|XOR&#39;easter]] ([[User talk:XOR&#39;easter|talk]]) 00:31, 30 June 2022 (UTC)
*'''No''' I have watchlisted a lot of articles that are targets of vandalism. When they're hit, I just protect them. Why would I need to wait for an RFPP request rather than take the action myself? &ndash;&nbsp;[[User:Muboshgu|Muboshgu]]&nbsp;([[User talk:Muboshgu#top|talk]]) 00:38, 30 June 2022 (UTC)
*'''No''' per Muboshgu. We have policy like [[WP:INVOLVED]] in place. [[User:Gråbergs Gråa Sång|Gråbergs Gråa Sång]] ([[User talk:Gråbergs Gråa Sång|talk]]) 09:50, 30 June 2022 (UTC)
*I agree with the others that this won't be workable. However, unwarranted protections do happen quite often. It's not a case of someone blatantly misusing the tools, so it's not a matter for the noticeboards, and, at least in my experience, it can't normally be resolved by a one-on-one discussion with the admin. I think we need to begin with updating the protection policy (a lot of it reflects the practices from before ECP existed), then make sure a neat summary is publicised though the admin newsletter so that all admins are aware of the newly codified community expectations. After that, we could start sampling the newly applied protections and let those admins know who fall short of those expectations (it's more difficult to ignore that sort of feedback when there's a clear policy passage to point to). Oh, and there's also the huge legacy of indefinite protections from the early days, many of which will need revising. – Uanfala ([[User talk:Uanfala|talk]]) 10:19, 30 June 2022 (UTC)
*: Again, any specific cases that you think certain page protections made were unwarranted? Was there conversation with the admin involved? [[User:Robertsky|– robertsky]] ([[User talk:Robertsky|talk]]) 11:13, 30 June 2022 (UTC)
*::I'm not making broad proposals to address an individual incident. Probably worth pointing out that even though potentially unwarranted protections may represent a relatively tiny fraction of all protections applied, their absolute number is still quite big. – Uanfala ([[User talk:Uanfala|talk]]) 14:15, 30 June 2022 (UTC)
*:::Of course unwarranted protections happen. Everybody makes mistakes. I'm not concerned about that part of your statement, but about the bit where you say, "it can't normally be resolved by a one-on-one discussion with the admin." Without any evidence that looks very much like [[WP:casting aspersions|casting aspersions]] against our whole admin corps. If pages that shouldn't are being protected and this isn't being discussed properly then it's very much a matter for the noticeboards. [[User:Phil Bridger|Phil Bridger]] ([[User talk:Phil Bridger|talk]]) 14:48, 30 June 2022 (UTC)
*:::{{tq|even though potentially unwarranted protections may represent a relatively tiny fraction of all protections applied, their absolute number is still quite big}} any statistics or analysis on this? if yes, were the majority of unwarranted protections done by a few admins, or just a few by each admin but summed up to be a lot, or a lot by each admin? Depending on the stats and analysis, the solution you proposed may end up being a sledgehammer hammer on a nail.
*:::I have seen unwarranted protections discussions coming up at ANI, but those are mostly either done by relatively inactive admins who chose to suddenly used their rights, or admins who were pointed out or engaged later by other editors to be perceived as unwarranted and later either backed by other editors/admins or had the protections reverted. For inactive admins, the criteria to strip their rights had been tightened recently ([[Wikipedia:Inactive administrators]]), and we should see lesser of such issues from them (though it is already rare). [[User:Robertsky|– robertsky]] ([[User talk:Robertsky|talk]]) 17:17, 30 June 2022 (UTC)
*:::{{re|Uanfala}} And all you  have to do is request unprotection. [[User:Doug Weller|<span style="color:#070">Doug Weller</span>]] [[User talk:Doug Weller|talk]] 13:11, 3 July 2022 (UTC)
*'''No'''  I hear you.....I've seen many bad or questionable page protections, but your idea would be unworkable. Getting a process in place to review questionable ones (such as [[Wikipedia:Administrative action review]]) in place would be a better move. <b style="color: #0000cc;">''North8000''</b> ([[User talk:North8000#top|talk]]) 13:19, 3 July 2022 (UTC)
* '''Oppose''' If an admin is making poor decisions, a knee-jerk layer of beuracracy that affects all admins is not an appriate means of correcting the problem. Take it up with the admin in question, use existing processes if that doesn't yield a good result. --[[User:Beeblebrox|Beeblebrox]] ([[User talk:Beeblebrox|talk]]) 17:31, 7 July 2022 (UTC)

{{archive bottom}}

== metadata template ==

Would it make sense to use a "metadata" template to consolidate all the little templates we place at the top/bottom of an article? For example: {{tl|short description}}, {{tl|Use dmy dates}}, {{tl|pp-semi-protected}}, {{tl|hatnote}}, {{tl|Use British English}}, {{tl|Pp-move-indef}}, {{tl|Featured article}}, and so forth. I suppose the advantages would be consistency, simplified maintenance, lower confusion for new editors, and easier management via bots. [[User:Praemonitus|Praemonitus]] ([[User talk:Praemonitus|talk]]) 21:40, 10 July 2022 (UTC)
:Not a good idea, imo. This looks like a sink where all kinds of mismatched items are thrown together. I fail to see how this is consistent, easier to maintain, or simpler for new editors. [[Special:Contributions/204.19.162.34|204.19.162.34]] ([[User talk:204.19.162.34|talk]]) 22:44, 10 July 2022 (UTC)
:: (1) It's consistent because the available options are laid out in the template documentation, rather than relying on tribal knowledge of what templates to add; (2) It's easier to maintain since it is collected together under consistent management; (3) It's simpler for new editors since they don't have to understand a bunch of meta-templates requiring investigating a series of documentation; just the one page. The options can be laid out in a consistent and logical manner. For example, rather than having a slew of {{tl|Use Oxford spelling}}, {{tl|Use American English}}, ... {{tl|Use Sri Lankan English}} templates, you can have a single parameter such as 'spelling_variant='. [[User:Praemonitus|Praemonitus]] ([[User talk:Praemonitus|talk]]) 00:11, 11 July 2022 (UTC)
:::If you did this, I would leave out the page protection templates -- those are usually placed by admins or bots, and most editors shouldn't be touching them. For the others that seems fine. --[[User:Ahecht|Ahecht]] ([[User talk:Ahecht|<span style="color:#FFF;background:#04A;display:inline-block;padding:1px;vertical-align:-.3em;font:bold 50%/1 sans-serif;text-align:center">TALK<br />PAGE</span>]]) 14:08, 11 July 2022 (UTC)
:::You can try and create a sandbox version to see if it is viable. I have a feeling you'll get pulled too much into a sink-hole. On the other hand, merging the "Use x language" templates into one template with a parameter name might be something that can work. [[User:Gonnym|Gonnym]] ([[User talk:Gonnym|talk]]) 14:27, 11 July 2022 (UTC)
:I would support integrating all protection templates into one, but not {{tl|use dmy dates}}, etc. Keeping them at the top of page informs new editors of the correct style to be used. <span class="nowrap">&#8212;'''[[User:CX Zoom|CX Zoom]]'''[he/him]</span> <sup class="nowrap">([[User talk:CX Zoom|let's talk]] • {[[Special:Contributions/CX Zoom|C]]•[[User:CX Zoom/X|X]]})</sup> 18:22, 11 July 2022 (UTC)
::Protection templates already ''are'' integrated into one. Nowadays, they are all wrappers for [[Module:Protection banner]]. This works out what the current prot level is for creating, editing, moving, uploading (as appropriate), determines the prot duration, and either displays an applicable icon or puts the page into {{cl|Wikipedia pages with incorrect protection templates}}. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 20:10, 12 July 2022 (UTC)

== Creating new articles for bus routes. ==

I would like to propose that new articles be created to encapsulate lots of different bus routes.

===Background (bus route articles)===
On this very wiki, there are a series of articles concerning the various bus routes in London. These articles contain many details about the history of the routes and the vehicles that are used on it. I notice that there is not a lot of this for other Cities and Local Authority areas. This, I want to change, but it require a lot of work and dedication.

===My Proposal (bus route articles)===
I would therefore like to propose that an assemblage of articles be crated to discuss the bus routes of other major metropolises such as Glasgow and Dublin. I also do hereby request and require that such due process be observed in order to establish a network of pages covering the routes of more rural provinces, such as Ayrshire and the Lake District. I trust that such can be achieve in a timely and competent manner, and so I must propose such action to be conducted henceforth in order to improve the very fabric of this dear wiki.

===Considerations (bus route articles)===
Before I close, I will lay down a few important points to consider:
#I notice that there would some issues with establishing notability with some rather more obscure bus routes, but I trust that we can set criteria for that, and I believe that any bus route operating on a 30min frequency or more frequent than that should be fine.
#Yes, this is a massive project. If we want to cover the routes of all 200 odd countries, then we will be here for a long while. Perhaps we will build out from London first, and work on English routes. Scottish and Welsh would follow, then Northern Ireland and Ireland, and then onto the rest of Europe. If things are going well after this, then work on other continents should proceed in this order: North America, Asia, Africa, South America, Oceania. If at any point, notability is in doubt, then dial back a bit and focus mostly on large cities for a while.
#Remember, we are trying to eliminate London favouritism here, but we must not go to far and blatantly insult the capital of England. Care must be taken to look after those articles as well, and said articles should be used as a template for new pages.

===Conclusion (bus route articles)===
I hope this proposal is not too long, both literally and metaphorically. I hope these writings aren’t too long either. I expect good points from both those who support and those who oppose this idea. If there is too much opposition, then it would be good to talk about scaled down versions of this project. Should the need arise, I will create such a thing and post it on this page. Ideas to improve this project are encouraged and will be most useful here.
[[User:Pablothepenguin|Pablothepenguin]] ([[User talk:Pablothepenguin|talk]]) 19:02, 11 July 2022 (UTC) [[User:Pablothepenguin|Pablothepenguin]] ([[User talk:Pablothepenguin|talk]]) 19:02, 11 July 2022 (UTC)

:@[[User:Pablothepenguin|Pablothepenguin]] Editors in recent times have been highly resistant to creating new [[WP:SNG|subject-specific notability guidelines]], so we're left with the [[WP:GNG|general notability guideline]]. If a bus route meets that standard, it can have an article; you don't have to ask for it here. If it doesn't (as I suspect is the case for most bus routes), it can't. Some of those routes might warrant mention as part of broader-scoped articles on bus routes in an entire city. Check with [[WP:TRANSPORT|WikiProject Transport]] for more info. <span style="color:#AAA"><small>&#123;{u&#124;</small><span style="border-radius:9em;padding:0 5px;background:#088">[[User:Sdkb|<span style="color:#FFF">'''Sdkb'''</span>]]</span><small>}&#125;</small></span> <sup>[[User talk:Sdkb|'''talk''']]</sup> 21:05, 11 July 2022 (UTC)
:I would imagine that most bus routes are not notable as encyclopedia articles.  My town has a bus route that covers a {{convert|5|mi}} stretch with 4 stops on it - I can't see how the ''CityName Bus Purple Route'' is the least bit notable or of interest to anyone not near it.  Lists of these may be of some use at wikivoyage, simliar to pages such as [[:voy:en:Ferry_routes_to_Great_Britain]]. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 23:04, 11 July 2022 (UTC)
::I could argue the same thing about some of the London routes that are recorded on this very Wiki. Do you see the irony here? [[User:Pablothepenguin|Pablothepenguin]] ([[User talk:Pablothepenguin|talk]]) 23:48, 11 July 2022 (UTC)
:::[[WP:AFD]] is right around the corner, — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 00:33, 12 July 2022 (UTC)
::::[[Special:PrefixIndex/Wikipedia:Articles_for_deletion/London_Buses_route]] has some interesting reading! — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 00:37, 12 July 2022 (UTC)
:::::Looks like they get deleted and redirected to lists a lot --- then after some time someone just recreates them again! — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 00:40, 12 July 2022 (UTC)
::::::That being said, pages such as [[Night buses in London]] or [[List_of_bus_routes_in_London]] themselves don't seem t as useless. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 00:43, 12 July 2022 (UTC)
:::::::I am prepared to create more AFDs for these pages if my proposal doesn’t work out. I may have to “ruin” them to get them deleted as well. If you don’t know what I mean, I’m talking about messing with them to make them severely shoddy, then immediately submitting the deletion requests. [[User:Pablothepenguin|Pablothepenguin]] ([[User talk:Pablothepenguin|talk]]) 00:51, 12 July 2022 (UTC)
::::::::I would advise you to read [[:Wikipedia:Do not disrupt Wikipedia to illustrate a point]] before attempting anything like that. - [[User talk:Donald Albury|Donald Albury]] 01:23, 12 July 2022 (UTC)
::::::::Perhaps don't do that... [[User:Anarchyte|<span style="color:#202122;font-family:Trebuchet MS">Anarchyte</span>]] ([[User talk:Anarchyte|<span style="color:#202122">talk</span>]]) 11:34, 12 July 2022 (UTC)
:I think a general problem with bus routes is that they can easily be changed by the bus authority since they don't rely on any fixed infrastructure short of terminals. A route that has run for a long time may be notable per GNG but I can't expect every route in a metro area to be that way, even London. --[[User:Masem|M<span style="font-variant: small-caps">asem</span>]] ([[User Talk:Masem|t]]) 11:42, 12 July 2022 (UTC)
*I would think that the more ''useful'' approach would be to have an article on the town’s bus system (as a whole)… that article would contain an '''external link''' to the website of that system (which, presumably, would cover the individual routes).  That way Wikipedia can point readers to the information they desire, without having to worry about updating our article every time a specific route changes. [[User:Blueboar|Blueboar]] ([[User talk:Blueboar|talk]]) 13:12, 12 July 2022 (UTC)
*A few bus routes are individually notable, but they are rare. Most bus routes are better covered in articles about the area(s) they operate in, bus routes of [place] and/or transportation in [place]. For public transport articles generally, it is almost always going to be significantly preferable to write articles in a top down order, starting with articles about transport in <country/state/region>, then transport in <city>, then list of bus routes in <city>, and only writing the <City> bus route ''n'' article once all the higher level ones are at the very least start class (with C or better being preferable). Even then I recommend not publishing an article about an individual bus route unless it it is fully sourced and very clearly meets the GNG otherwise someone ''will'' nominate it for deletion. [[User:Thryduulf|Thryduulf]] ([[User talk:Thryduulf|talk]]) 13:35, 12 July 2022 (UTC)

*There's both the main implicit question and a different question if taken literally.  The main implicit question is avoiding separate articles on bus routes, usually by folding them into a higher level article.   I'd say follow the rules, and GNG will almost always exclude these.  They are usually ethereal / abstract  short-lived entities that exist only in the schedules of the organization that runs the buses.  The exceptions to this will pass GNG.   The ostensible/ literal question (creation of higher level articles) sounds like a good idea but is probably not the actual question.<b style="color: #0000cc;">''North8000''</b> ([[User talk:North8000#top|talk]]) 13:57, 12 July 2022 (UTC)
*:{{tpq|They are usually ethereal / abstract  short-lived entities that exist only in the schedules of the organization that runs the buses}} while there are unquestionably many bus routes this accurately describes, there are very long lasting routes (e.g. route 126 between Wells and Weston-super-Mare has been operating the same route with only minor alterations since at least 1967) that are not ephemeral and have some an existence outside timetable pamphlets (e.g. they appear in tourist guides, nostalgia discussions, etc.) but which do not meet the GNG (most of the info about the 126 route is on pages whose primary subject is the vehicles that have been used on it). These shouldn't have standalone articles, but they do merit mention somewhere. [[User:Thryduulf|Thryduulf]] ([[User talk:Thryduulf|talk]]) 15:54, 12 July 2022 (UTC)
:::I am thinking through the possibility of setting up RFDs for the London bus routes. I am aware of the need to combat London favouritism at this point in time. I have noticed that things that happen in London or things that are commonly associated with London, such as London buses, are automatically several hundred times more famous and noteworthy than things that happen in my neck of the woods. My two nearest cities, Glasgow and Edinburgh contain quite wonder things. But said things will never received the attention and interest that London things get. I am outraged at this decadence, and do anything to try and remove it. It is difficult work, as I do not want to offend Londoners, and I also do not wish to cause mass confusion.
:::Over the years, I have read many detailed histories of UK buses, each of which has contained very detailed information about the UK bus network. The one thing that has always annoys me in this case is the fact that said histories devote up to half of their time talking about just London. An example of this is that they will typically discuss how the first London buses, which were pulled by horses, plied their trade in the Victorian era. They will then go on to say that London made the decision to upgrade to motor buses in the early 1900s. The entire histories are full of stuff like this. Have they forgotten that every city in the UK made the same transitions? Are they not aware of beautiful companies such as Lothian of Edinburgh, and the main provider of buses in Birmingham? In addition to this, London vehicles, such as Routemasters, get a lot more attention that other buses, such as the Alexander and Albion vehicles that operated in the central belt of Scotland.
:::London buses have always confused me. Their refusal to accept the factual truth that LED destination displays are just plain better, and their insistence on obliterating First Bus purple, and Stagecoach White in favour of a boring Red livery (I prefer Stagecoach-type liveries with swirls and stripes to solid colours), confuse me to this day. Do remember, this is a company so backward, that their last conductors went in 2005 (Most places stopped this in the 1980s), and they still use roller blinds to display route info, even though my local buses stopped doing this in the 1990s.
:::But those London folks reel me right back in, with their more detailed route information, and their stop announcement systems. They also had a massive electric and hybrid bus fleet before anyone up in Scotland got there. Plus they also have separate doors for entering and exiting the bus. That’s why I strongly dislike them, because they confuse me by being backward and forward thinking simultaneously. I do not understand them at all, and I think you would need an IQ of at least 300 to truly figure them out.
:::Anyway, I should wrap up now. I believe London should switch to LED and throw out the roller blinds. Also, they should allow multi-coloured liveries with swirls and custom logos. Red is the colour of anger, evil, greed, and the Devil; London should move away from this. I recommend Green, the colour of environmentalism and nature, or blue, the colour of calmness and the Sea. There is also White, which represents peace and sterility, and Gold, which stands for wealth and prosperity. For the sake of tradition, heritage buses should continue to be in red, along with one or two independent London bus companies. My bus companies, as well as other Scottish firms should take notes from London’s positive strategies, such as stop announcements and bigger Electric fleets. Scottish buses should also be fitted with more detailed route information, as in London, where many via points are displayed as well as the destination. [[User:Pablothepenguin|Pablothepenguin]] ([[User talk:Pablothepenguin|talk]]) 17:30, 12 July 2022 (UTC)
::::In addition to the links you were given to read earlier, please also read [[Wikipedia:Right great wrongs]] before taking ''any'' action at all like you've just proposed. [[User:Thryduulf|Thryduulf]] ([[User talk:Thryduulf|talk]]) 19:16, 12 July 2022 (UTC)
:::::I will be careful. [[User:Pablothepenguin|Pablothepenguin]] ([[User talk:Pablothepenguin|talk]]) 19:21, 12 July 2022 (UTC)
::::::If you, or someone (unlikely) could write a raft of articles  [[Worcestershire bus route 144|like this historical one]], a journey from one end to the other that I had to make over 100  times as a child and in the 1950s from [[Malvern, Worcestershire|my home town]], then parts of your proposal might have potential. But although it was a stable route for decades from 1913 to 1976, it now changes its route every time I use it on my free bus pass. However, the 144 is one of only 42 routes to have made its way to [[:Category:Bus routes in England]], and nowadays bus routes are so volatile that such articles would need a permanent team to keep them updated. That said,  I fear much of your longer post above appears to be somewhat off-topic. [[User:Kudpung|Kudpung กุดผึ้ง]] ([[User talk:Kudpung|talk]]) 22:35, 12 July 2022 (UTC)

== Concerns about Making Vector (2022) the Default Skin in light of jawiki's Precedent ==

The Foundation has '''changed jawiki's default skin to Vector (2022)'''.<br>
Discussions on jawiki about this matter have been confusing.<br>
In addition, '''since the change was made suddenly and without notice to the general public''', there is widespread confusion in the Japanese social networking community about the change.<br>
'''The Foundation will try to make changes to enwiki next.'''(https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements)<br>
Would the English-speaking community agree with this?<br>
If you English speakers think this is OK, then forget about this topic, because the Japanese and English speaking communities have different ideas about site design.<br>
If not, once changes are made, it will be very difficult to revert.<br>
'''Please ask the communities you know''', such as Facebook, Twitter, WhatsApp, and Discord, whether they agree or disagree with the Vector (2022) specification.<br>
Then, invite everyone on each social network to '''participate in the discussion'''.<br>
Whatever the outcome, we believe it will lead enwiki in a better direction.<br>
<br>
(Original text)<br>
jawikiの前例から考えるVector (2022)のデフォルトスキン化の懸念について<br>
財団は'''jawikiのデフォルトスキンをVector (2022)を変更しました'''。<br>
この件についてjawikiでは議論が紛糾しています。<br>
また、'''一般ユーザーへの告知がなく'''、突然行われたため、日本のSNSコミュニティでも変更への混乱が広がっています。<br>
'''財団は次にenwikiに変更を加えようとするでしょう'''。(https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/ja)<br>
このことについて英語圏の皆様は賛成でしょうか？<br>
日本語圏と英語圏ではサイトデザインへの考え方が異なるので、英語圏の皆様が問題ないと考えるのであれば、このトピックは忘れて下さい。<br>
そうでないのであれば、一度変更が加えられたら戻すのは大変です。<br>
Facebook、Twitter、WhatsApp、及びDiscord等'''あなたの知る限りのコミュニティでVector (2022)の仕様について賛否を問うて下さい'''。<br>
そして、各SNSの皆様に'''議論への参加を呼び掛けて下さい'''。<br>
結果がどうであれ、そのことがenwikiをより良い方向へ導くと信じます。 [[User:HarukaFujihira|HarukaFujihira]] ([[User talk:HarukaFujihira|talk]]) 21:01, 12 July 2022 (UTC)

*Why would we ask social media? [[User:Schierbecker|Schierbecker]] ([[User talk:Schierbecker|talk]]) 01:21, 13 July 2022 (UTC)
*:Many Wikipedia users are IP users who do not have a registered Wikipedia account and use Wikipedia by searching from the Wikipedia main page, searching from Google, or accessing via hyperlinks from social networking sites. IP users are not informed that the default skin will be Vector (2022).<br>
*:If many users including IP users agree to Vector (2022) after the default skin is changed to Vector (2022), there will be no problem. However, as we can see from the examples of Japan and France, a lot of protests and confusion are expected.<br>
*:I have proposed a method to inform IP users in advance through social networking services as a way to prevent confusion in advance.<br>
*:If the consensus of enwiki users is that there is a better solution than SNS, or that there is no need to prevent confusion, then please ignore this topic. I am not forcing people to use SNS to spread the word. [[User:HarukaFujihira|HarukaFujihira]] ([[User talk:HarukaFujihira|talk]]) 02:44, 13 July 2022 (UTC)

== Discussion on renaming Citation Style 1 template parameter url-status ==

I've posted an RFC over at [[Help talk:Citation Style 1/Archive 84#RFC: Rename url-status parameter]], proposing to deprecate {{para|url-status}} in favor of {{para|archive-display}}, a name that better communicates its function and intent. Any community input would be welcome. [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 18:25, 14 July 2022 (UTC)

== RfC: Showing Editnotices to mobile editors ==
{{atop|Clear and overwhelming consensus to implement this. No need to wait the full time period to get it implemented. Any comments on technical questions, etc. can be discussed at [[User talk:Alexis Jazz/EditNoticesOnMobile]]. [[User:TonyBallioni|TonyBallioni]] ([[User talk:TonyBallioni|talk]]) 18:37, 15 July 2022 (UTC)}}
Should [[User:Alexis Jazz/EditNoticesOnMobile.js|a JavaScript gadget]] be installed to [[MediaWiki:Minerva.js]] to show [[WP:EDN|Editnotices]] to mobile editors? <span class="nowrap">&#8212;'''[[User:CX Zoom|CX Zoom]]'''[he/him]</span> <sup class="nowrap">([[User talk:CX Zoom|let's talk]] • {[[Special:Contributions/CX Zoom|C]]•[[User:CX Zoom/X|X]]})</sup> 09:54, 4 July 2022 (UTC)
=== Background (showing editnotices on mobile) ===
Mobile editors cannot see [[WP:EDN|editnotices]], which is a part of the [[WP:Mobile communication bugs]], which means that mobile editors aren't able to see the [[WP:ARBCOM/DS|Arbitration committee's discretionary sanction notices]], [[WP:MEDRS]], [[WP:BLP]] notices and any general instructions about editing a particular article. This prompted a phab ticket ([[phab:T201595]]) to be filed in 2018. During the COVID-19 pandemic, the inability to communicate properly with mobile editors was felt and the community requested in [[:meta:Community Wishlist Survey 2021/Mobile and apps/Mobile editnotices|2021]], and [[:meta:Community Wishlist Survey 2022/Mobile and apps/Show editnotices on mobile|again in 2022]] to introduce editnotices to mobile editors. But, the phab ticket has remained in dormant state, which, even after 4 years of filing, remains tagged as "Need triage". This RfC attempts to resolve the communication problem by installing [[User:Alexis Jazz/EditNoticesOnMobile.js]] to [[MediaWiki:Minerva.js]], until [[phab:T201595]] is fixed. <span class="nowrap">&#8212;'''[[User:CX Zoom|CX Zoom]]'''[he/him]</span> <sup class="nowrap">([[User talk:CX Zoom|let's talk]] • {[[Special:Contributions/CX Zoom|C]]•[[User:CX Zoom/X|X]]})</sup> 09:54, 4 July 2022 (UTC)

:To clarify, not ''all'' mobile editors cannot see edit notices. Android users on the Wikipedia app see editnotices; this script is for mobile users on the mobile site (''en.m.wikipedia.org''). iOS app users do not see editnotices, and the script will not change this. WMF says the feature "is on the roadmap". — [[User:PerfectSoundWhatever|<span style="letter-spacing:0.1em;">PerfectSoundWhatever</span>]] ([[User talk:PerfectSoundWhatever|t]]; [[Special:Contributions/PerfectSoundWhatever|c]]) 18:36, 10 July 2022 (UTC)

=== Survey (showing editnotices on mobile) ===
* '''Support''' as proposer. Having used it on several mobile devices, I've realised that it might be a good solution to the above mentioned problem. <span class="nowrap">&#8212;'''[[User:CX Zoom|CX Zoom]]'''[he/him]</span> <sup class="nowrap">([[User talk:CX Zoom|let's talk]] • {[[Special:Contributions/CX Zoom|C]]•[[User:CX Zoom/X|X]]})</sup> 09:54, 4 July 2022 (UTC)
* '''Support''' [[User:Pppery|* Pppery *]] [[User talk:Pppery|<sub style="color:#800000">it has begun...</sub>]] 14:05, 4 July 2022 (UTC)
* '''Support''' as proposed; there are no negatives to this and it helps address the [[WP:THEYCANTHEARYOU]] issue. [[User:BilledMammal|BilledMammal]] ([[User talk:BilledMammal|talk]]) 14:10, 4 July 2022 (UTC)
* '''Support''' as script author. On a technical note, registering the script as a default Minerva-only gadget is a little more efficient than using Minerva.js. I've written instructions on how to register the script as a gadget. But that's just details. — <span style="color:#e08020">Alexis Jazz</span> ([[User talk:Alexis Jazz|talk]] or ping me) 18:37, 4 July 2022 (UTC)
* '''Support.''' Of course, but I will note this is conditioned on the script be extensively tested before the edit installing it goes live. &#8211;<span style="font-family:CG Times, times">[[User:MJL|<span style="color:black">MJL</span>]]&thinsp;[[User talk:MJL|‐'''Talk'''‐]]<sup>[[User:MJL/P|☖]]</sup></span> 05:48, 5 July 2022 (UTC)
* '''Support if''' we limit to extendedconfirmed and higher user rights for 6 months. That might motivate people to improve the quality of these notices before dumping them on other ppl. —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 08:27, 5 July 2022 (UTC)
* '''Comment''' Hi - I’m the Product Manager for the [[:mw:Moderator Tools|Moderator Tools team]] at the Wikimedia Foundation and I wanted to leave a quick note that we’ve got Editnotices on our list as a potential priority to work on this year as part of our improvements to mobile web (we're working on [[:mw:Moderator Tools/Content moderation on mobile web/Overflow menu|accessing admin features]], [[:mw:Moderator Tools/Content moderation on mobile web/Preferences|preferences]], and probably Diff/Undo first). When we come to this I'd like to investigate how impactful editnotices are for newer users, since I don't think we've got much prior research on the topic (do they impact edit completion rates? do they have the intended effect of preventing or encouraging certain types of edits?). Anyway, don't let our plans stop you from moving ahead with this in the meantime. [[User:Samwalton9 (WMF)|Samwalton9 (WMF)]] ([[User talk:Samwalton9 (WMF)|talk]]) 11:19, 5 July 2022 (UTC)
*:{{ping|Samwalton9 (WMF)}} Could you clarify, does your team intend to make implementing editnotices ''conditional'' on the findings of that research? &ndash;&#8239;[[User:Joe Roe|Joe]]&nbsp;<small>([[User talk:Joe Roe|talk]])</small> 16:43, 5 July 2022 (UTC)
*::It seems that the WMF is working at a glacial pace here. In the Wikipedia of 2001, which had ''far'' fewer resources, would such decisions have had to be made regarding the prioritisation of implementation of required desktop features? Of course not - it would just have been done. The aim should be that by the end of this year everything that is available on the desktop should be available on mobile (unless any particular feature is shown to be impossible to implement), and even that is far too late. Commercial organisations reached that stage many years ago. [[User:Phil Bridger|Phil Bridger]] ([[User talk:Phil Bridger|talk]]) 18:18, 5 July 2022 (UTC)
*::: FWIW a big contributory factor of the seemingly slow pace Wikimedia works at is because of the technical complexity site specific gadgets like this add (this in addition to the fact most top ten sites with a tiny amount of staff compared to other top ten sites). The mobile and desktop site is maintained by 6 people fulltime which is ridiculous but an understandable constraint. [[User:Jdlrobson|Jdlrobson]] ([[User talk:Jdlrobson|talk]]) 20:28, 6 July 2022 (UTC)
*::::I wouldn't say that it's understandable that an organisation that raises so many millions of dollars each year should have so few technical staff. Get rid of the armies of unskilled "outreach" workers and employ a few useful highly-skilled highly-paid technical staff to fix these problems that plague us and make Wikipedia a laughing stock. [[User:Phil Bridger|Phil Bridger]] ([[User talk:Phil Bridger|talk]]) 21:15, 6 July 2022 (UTC)
*::::The problem is not that the WMF has a tiny amount of staff, but that the vast majority are sent off on tangents pursuing other agendas, leaving a tiny amount of overworked technical staff. [[User:Certes|Certes]] ([[User talk:Certes|talk]]) 21:36, 6 July 2022 (UTC)
*::::[[User:Jdlrobson|Jdlrobson]], SIX? I never looked up the whole technical team, frankly because I don't know where I should look for the full picture, but I've been curious about the size of the actual technical team. (so not counting managers, PR, etc) I'm terrified to ask, but how many managers etc. do you have?<br style="margin-bottom:0.5em"/>This actually explains why I rarely see any technical staff replying to anything.. I guessed you were understaffed, but six? Didn't you mean 66 maybe? It must have been a typo. Can't be six.<br style="margin-bottom:0.5em"/>And I agree with the above: the WMF raises millions in donations. You are not, NOT telling me they can't afford a dozen fulltime people to maintain this site and/or a few dozen IT students or the like for some grunt work. And just imagine: when three people get the flu, this site would be kept running by <i>three</i> people. Maybe you get a temp in that case, but that person would probably not be as productive. That is simply insane and irresponsible. <span id="Alexis_Jazz:1657156754204:WikipediaFTTCLNVillage_pump_(proposals)" class="FTTCmt">— <span style="color:#e08020">Alexis Jazz</span> ([[User talk:Alexis Jazz|talk]] or ping me) 01:19, 7 July 2022 (UTC)</span>
*:::::Just for some figures ... The WMF had a [https://upload.wikimedia.org/wikipedia/foundation/1/1e/Wikimedia_Foundation_FY2020-2021_Audit_Report.pdf#page=5 surplus of over $50 million] last financial year, and was heading [https://commons.wikimedia.org/w/index.php?title=File:F%26A_Tuning_Session_FY21-22_Q3.pdf&page=5 for another healthy surplus] in the year just ended. In addition to those surpluses, it accumulates around $20 million a year in its endowment. It [https://wikimediafoundation.org/about/annualreport/2020-2021-annual-report/financials/ claims] that 42% of its money is spent on "Direct support to websites" and 31% on "Direct support to communities" ... given [[Wikimedia_Foundation#Financial_development|total expenses of $112 million]], that is an $80-million dollar budget for those two rubrics. Total expenses are now over ten times what the Foundation spent in 2010. The Foundation spent half a billion dollars over the past five years ... more than it spent in the fourteen years prior, from 2003 to 2017. [[User:Jayen466|Andreas]] <small>[[User_Talk:Jayen466|<span style="color: #FFBF00;">JN</span>]][[Special:Contributions/Jayen466|466]]</small> 16:39, 7 July 2022 (UTC)
*::::Apparently Wikipedia gets some 5 billion views a month. A team of 6 doing all that technical maintenance work is simply understaffed. Every month I find that mobile site has gotten a few more features. I appreciate the progress. But we're currently so far behind on mobile site functionality that it would take us several more years if we continue at this pace. If the WMF needs more developers, they should hire them. It does receive a good amount of donation which it should use judiciously. <span class="nowrap">&#8212;'''[[User:CX Zoom|CX Zoom]]'''[he/him]</span> <sup class="nowrap">([[User talk:CX Zoom|let's talk]] • {[[Special:Contributions/CX Zoom|C]]•[[User:CX Zoom/X|X]]})</sup> 06:49, 7 July 2022 (UTC)
*:::::I suspect that Jon meant "the mobile site", which is what you would call "the Minerva skin", aka the [[mw:Reading/Web]] team. 
*:::::If your idea of "the site" means "keeping Wikipedia on the internet", then that's the [[mw:Wikimedia Technology|Technology department]] (e.g., the [[mw:Ops]] team), and they have more than 150 regular staff, not counting various contractors and vendors.  The Product department (of which both Jon and I are a part) also has more than 150 staff (plus probably more temporary contractors but fewer vendors). [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk:Whatamidoing (WMF)|talk]]) 17:28, 7 July 2022 (UTC)
*::::::@[[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] - while similar for sure, I think most of the problems in this thread aren't really about "Minerva" directly - but about "Mobile Front End", and its limitations. Everything MFE certainly has a huge impact on readers, who are increasingly visiting from mobile devices to read content. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 13:34, 14 July 2022 (UTC)
*:@[[User:Samwalton9 (WMF)|Samwalton9 (WMF)]] I'm wondering how admin tools and looking at diffs (things that affect 1000 people and editors respectively) take priority over showing notices to <s>IPs (you know, the supermajority of users?).</s> Nope this is why I don't comment when I'm tired let me modify: over showing content to ''mobile users'' (the ever growing sector of people that outnumber both admins and editors (as well as including <s>some</s> many?)) Happy Editing--'''[[User:IAmChaos|<span style="color:#000000">IAm</span>]][[User talk:IAmChaos|<span style="color:#0645AD">Chaos</span>]]''' 02:16, 6 July 2022 (UTC) modified 02:19, 6 July 2022 (UTC)
*::{{re|IAmChaos}} Great question, I agree it doesn't seem intuitive! First I want to invite you to share your thoughts on our team's priorities at [[:mw:Moderator Tools/Content moderation on mobile web|Moderator Tools/Content moderation on mobile web]] - our work is directly guided by what folks are telling us is important. In terms of how we got to the current priorities, admin tools (the Overflow menu) actually came up first for us specifically ''because'' it impacted a smaller number of users. Our team was previously working on [[WP:TWL|The Wikipedia Library]], so we didn't have much experience working in MediaWiki. As such, we started with a smaller scope project, which impacted fewer users, as our first foray into mobile web partly so that we wouldn't impact too many users if we, for example, introduced bugs. We then decided to prioritise Preferences because at the moment mobile users have no obvious way whatsoever to access critical user account features like changing their password, updating their email address, and adjusting notifications. We think this is a huge oversight for all mobile editors and we made the judgement call to fix it before other priorities. We are now prioritising Special:Diff and adding an Undo button there because it's what we were hearing about most from the editors we spoke to - outside of English Wikipedia editnotices honestly just didn't come up as often, if at all, but lots of mobile-first editors were frustrated they couldn't undo edits from diffs. In my view there's a lot to improve in the mobile web editing experience, especially in terms of features for active editors, patrollers, and admins, so please do head over to our project page and let us know what you think the priorities are. [[User:Samwalton9 (WMF)|Samwalton9 (WMF)]] ([[User talk:Samwalton9 (WMF)|talk]]) 08:55, 8 July 2022 (UTC)
*:I think more research on how edit notices or other alternatives can be made more effective across users of all types of devices would be great. I hope, though, this would happen in parallel with some interim solution that would allow today's version of edit notices to be visible across all devices. (If this means the community needs to go on a drive to slim down edit notices, possibly selectively for different browser sizes, with guidance from the constraints of the interim solution, so be it.) [[User:Isaacl|isaacl]] ([[User talk:Isaacl|talk]]) 02:34, 6 July 2022 (UTC)
*:[removed comment, I don't see the insult but whatever, not interested in dealing with replies that can't be bothered to use punctuation] <span id="Alexis_Jazz:1657099695360:WikipediaFTTCLNVillage_pump_(proposals)" class="FTTCmt">— <span style="color:#e08020">Alexis Jazz</span> ([[User talk:Alexis Jazz|talk]] or ping me) 09:28, 6 July 2022 (UTC)</span>
*::stop insulting people —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 09:40, 6 July 2022 (UTC)
*'''Support''' - No one should be editing if they are unable to receive notices about their edits. To User:Samwalton9 (WMF) - This should be the FIRST thing to be straightened out. --[[User:Khajidha]] ([[User talk:Khajidha|talk]]) ([[Special:Contributions/Khajidha|contributions]]) 12:16, 5 July 2022 (UTC)
*'''Support''', or as a stopgap measure, people editing from mobile should be blocked from editing any page with an active editnotice. —[[User:Kusma|Kusma]] ([[User talk:Kusma|talk]]) 18:44, 5 July 2022 (UTC)
*'''Support''' Some kind of fix for this problem is long overdue, and even a stopgap measure is better than the status quo. [[User:XOR&#39;easter|XOR&#39;easter]] ([[User talk:XOR&#39;easter|talk]]) 20:29, 5 July 2022 (UTC)
* '''Support''' - subject to you the whole security thing of not hosting it in Alexis Jazz's userspace and making sure it's tested or whatever the techy people need to be certain its safe to run on all accounts. Happy Editing--'''[[User:IAmChaos|<span style="color:#000000">IAm</span>]][[User talk:IAmChaos|<span style="color:#0645AD">Chaos</span>]]''' 02:21, 6 July 2022 (UTC)
* '''Qualified support''', subject to whatever testing etc. is appropriate, as per IamChaos above. -- [[User:Visviva|Visviva]] ([[User talk:Visviva|talk]]) 03:16, 6 July 2022 (UTC)
* '''Just do it''' No brainer. '''[[User:Lugnuts|<span style="color:#002bb8;">Lugnuts</span>]]''' <sup>[[User talk:Lugnuts|Fire Walk with Me]]</sup> 16:30, 6 July 2022 (UTC)
*'''Comment''' Is there a way I can test the script on the Wikipedia app? — [[User:PerfectSoundWhatever|<span style="letter-spacing:0.1em;">PerfectSoundWhatever</span>]] ([[User talk:PerfectSoundWhatever|t]]; [[Special:Contributions/PerfectSoundWhatever|c]]) 16:49, 6 July 2022 (UTC)
**[[User:PerfectSoundWhatever|PerfectSoundWhatever]], the script was made for the [https://en.m.wikipedia.org/ mobile site]. I've never tried the Wikipedia app, but I doubt it supports gadgets or userscripts at all. <span id="Alexis_Jazz:1657127696171:WikipediaFTTCLNVillage_pump_(proposals)" class="FTTCmt">— <span style="color:#e08020">Alexis Jazz</span> ([[User talk:Alexis Jazz|talk]] or ping me) 17:14, 6 July 2022 (UTC)</span>
**:That's a shame, wish the app had more customizability. Just tested on ''en.m.wikipedia'', works as intended, so will '''Support''' this proposal. — [[User:PerfectSoundWhatever|<span style="letter-spacing:0.1em;">PerfectSoundWhatever</span>]] ([[User talk:PerfectSoundWhatever|t]]; [[Special:Contributions/PerfectSoundWhatever|c]]) 17:38, 6 July 2022 (UTC)
*:@[[User:PerfectSoundWhatever|PerfectSoundWhatever]] I'm afraid apps do not currently support gadgets and userscripts. However, we do in fact show editnotices in the Android app, in our native wikitext editor. In the iOS app this is not yet available, but is on the [[phab:T201596|roadmap]]. There's also a page where you can follow our overall progress on improving [[mw:On-wiki_communication|on-wiki communication]]. [[User:DBrant (WMF)|DBrant (WMF)]] ([[User talk:DBrant (WMF)|talk]]) 17:27, 8 July 2022 (UTC)
*::That's pretty cool, thanks for letting me know! Don't edit on android enough to have seen that yet, but I tested it and it definitely works. A shame it strips the images down from the editnotice to just text, but it's definitely better than nothing. — [[User:PerfectSoundWhatever|<span style="letter-spacing:0.1em;">PerfectSoundWhatever</span>]] ([[User talk:PerfectSoundWhatever|t]]; [[Special:Contributions/PerfectSoundWhatever|c]]) 18:30, 10 July 2022 (UTC)
*'''Conditional strong support'''. Mobile editors need to see editnotices. Anything about engagement comes second to them missing ArbCom/BLP/etc. warnings, which are essential to the function of the encyclopedia, e.g., we should not block people for [[WP:1RR]] without a warning that the page is under 1RR. As IAmChaos said above, this should only go ahead if [[WP:IAN|smart people]] <u>(including the [[phab:T312299|editing team]])</u> are sure this script is ready for general deployment and that the script is moved out of Alexis Jazz's userspace. Otherwise, this needs to be implemented yesterday. [[User:HouseBlaster|House]][[Special:Contributions/HouseBlaster|Blaster]]<sup>[[User talk:HouseBlaster|talk]]</sup> 17:17, 6 July 2022 (UTC) <u>edited 18:41, 10 July 2022 (UTC)</u>
*'''Support'''. Absolutely need to fix this now that we have a workable solution. The extremely non-committal language from the WMF technodude ({{tq|on our list as a potential priority to work on this year}}) admits that this is not yet a WMF priority. The open-source fix-it attitude among Wikipedians is what makes Wikipedia work; applying it to technical challenges that the community has faced is something that should be supported and applauded. — [[User:Mhawk10|Ⓜ️hawk10]] ([[User talk:Mhawk10|talk]]) 21:01, 6 July 2022 (UTC)
*'''Support''': long overdue, essential feature, and there's little point in editnotices without it (most newbies/readers use mobile). This RfC is like asking if readers on mobile should also be able to see images and text. Of course they should. Our rules and procedures around editnotices presume that they are readable by editors, not desktop editors only. Thanks to {{U|Alexis Jazz}} for the hard work in patching over this large, sustained WMF failure. — [[User:Bilorv|Bilorv]] ('''[[User talk:Bilorv|<span style="color:purple">talk</span>]]''') 14:18, 7 July 2022 (UTC)
*'''Support'''. --[[User:Jayen466|Andreas]] <small>[[User_Talk:Jayen466|<span style="color: #FFBF00;">JN</span>]][[Special:Contributions/Jayen466|466]]</small> 16:40, 7 July 2022 (UTC)
*'''Support''' WMF should feel ashamed that we have to resort to a solution like this to fix bugs. [[User:ThePlatypusofDoom|ThePlatypusofDoom]]  [[User talk:ThePlatypusofDoom|(talk)]]
*''' Support'''. Sadly, the WMF is far from the only tech company that tends to be in far too much of a rush to get apps out quickly, rather than getting out apps that actually work. This has gone on far too long, if they are unwilling or unable to fix it, the community will have to do what it can instead. --[[User:Beeblebrox|Beeblebrox]] ([[User talk:Beeblebrox|talk]]) 17:28, 7 July 2022 (UTC)
*:@[[User:Beeblebrox|Beeblebrox]]: Actually, this hack works solely on mobile site, the en.m.wikipedia site. Mobile app doesn't support *any* javascript, so it can't work there. Though mobile app editor numbers are apparently very small compared to mobile web and desktop editors. I don't have hard data, but app download numbers and lack of "Android app edit" & "iOS app edit" tags in RecentChanges indicates so. The idea is to provide standard editing experience to as many people as possible, although some would still be left out, unless we find another hack or the WMF decides to act. <span class="nowrap">&#8212;'''[[User:CX Zoom|CX Zoom]]'''[he/him]</span> <sup class="nowrap">([[User talk:CX Zoom|let's talk]] • {[[Special:Contributions/CX Zoom|C]]•[[User:CX Zoom/X|X]]})</sup> 17:45, 7 July 2022 (UTC)
*::You are correct, I'm afraid apps do not currently support gadgets and userscripts. However, we do in fact show editnotices in the Android app, in our native wikitext editor. In the iOS app this is not yet available, but is on the [[phab:T201596|roadmap]]. There's also a page where you can follow our overall progress on improving [[mw:On-wiki_communication|on-wiki communication]]. [[User:DBrant (WMF)|DBrant (WMF)]] ([[User talk:DBrant (WMF)|talk]]) 17:34, 8 July 2022 (UTC)
*'''Support''': It is essential that equivalent information regarding crucial issues such as Editnotices should be presented to editors using whatever approved front-end. As others have said, deployment requires prior testing. [[User:AllyD|AllyD]] ([[User talk:AllyD|talk]]) 07:05, 8 July 2022 (UTC)
*:Should the process of deeming any new topic as sanctionable involve explicit consideration of which editing communities will or won't be made aware of the issue? This would be akin to various jurisdictions' requirements to document equality considerations in any new regulation. While it would be largely replicating a row from [[:Wikipedia:Mobile communication bugs]], it could concentrate minds, especially when, for example, it is identifiable that most editors in the area of interest use a front-end which lacks Editnotices. [[User:AllyD|AllyD]] ([[User talk:AllyD|talk]]) 07:13, 8 July 2022 (UTC)
*'''Support''' It's really disappointing that this critical bug still hasn't been fixed. In the meantime, this is worth doing even though it still won't deal with all the mobile issues. [[User:MichaelMaggs|MichaelMaggs]] ([[User talk:MichaelMaggs|talk]]) 09:30, 8 July 2022 (UTC)
*<s>No way, let's not do it, makes too much sense.</s> '''Support'''<s>, particularly in light of {{noping|Jdlrobso}}'s revelation above that there are only six people on WMF's tech team, which drives home the fact that if we want anything done around here technically, we'll have to do it ourselves</s>. WMF staffs 300 people on their Tech and Product departments, as stated below by Samwalton9. That said, there clearly seems to be a backlog that is preventing critical issues like this from being addressed, and so I think this is a good next step to take in resolving this in the interim. --'''[[User:WaltCip|🌈<span style="color: white; font-weight: bold; background: linear-gradient(red, orange, green, blue, indigo, violet)">WaltCip</span>]]'''-''<small>([[User talk:WaltCip|talk]])</small>'' 12:32, 8 July 2022 (UTC)
**{{re|WaltCip}} I just want to clarify that, per [[User:Whatamidoing (WMF)|Whatamidoing]] above, there are substantially more than six people who work in tech and product at WMF. Jdlrobson was referring to the Web team specifically. In total there's something like [https://wikimediafoundation.org/role/staff-contractors/ 300 staff] between the Tech and Product departments at WMF. [[User:Samwalton9 (WMF)|Samwalton9 (WMF)]] ([[User talk:Samwalton9 (WMF)|talk]]) 12:46, 8 July 2022 (UTC)
**:My mistake. I'll correct my !vote accordingly. '''[[User:WaltCip|🌈<span style="color: white; font-weight: bold; background: linear-gradient(red, orange, green, blue, indigo, violet)">WaltCip</span>]]'''-''<small>([[User talk:WaltCip|talk]])</small>'' 12:47, 8 July 2022 (UTC)
* '''Comment''' Hi y'all – as the Product Manager for [[mw:Editing | the team that is responsible]] for the editing interfaces any implementation of mobile edit notices would appear within, it felt important to me that you all know/consider:
*# The Editing Team, in collaboration with [[User:Samwalton9 (WMF)|@Samwalton9 (WMF)]] and the [[mw:Moderator_Tools|Moderator Tools team]], is actively working on a proposal for what we think could be the fastest, safest, and most effective path for making edit notices available to people editing on mobile.<sup>[[phab:T312587|T312587]]</sup> ''Note: we're thinking of something we could implement on the order of weeks NOT months.''
*# The Editing Team is [[phab:T312299|actively reviewing]] the [[User:Alexis_Jazz/EditNoticesOnMobile]] gadget.<sup>[[phab:T312299|T312299]]</sup> ''Note: [[User:Alexis Jazz|@Alexis Jazz]] I've [[phab:T312299#8065846|added a link]] to [[Wikipedia:Village_pump_(proposals)#c-Alexis_Jazz-2022-07-07T00:59:00.000Z-Xaosflux-2022-07-06T19:10:00.000Z|the comment you made above]] to ensure that the investigation we are doing considers the analysis you've already done.''
*# '''Before Wednesday, 13 July is over''', you can expect for me to share the findings from [[phab:T312299|the investigation we've done]] into [[User:Alexis_Jazz/EditNoticesOnMobile]]. 
*# '''Before Wednesday, 27 July is over''', you can expect for me to share a proposal for what the Editing Team can do to make edit notices available to people editing on mobile that we think would be safe/reliable, quick to implement (on the order of weeks), and effective. ''Note: you can see the potential approaches we've started exploring in [[phab:T312587|T312587]].''

: Please let me know if anything about the above prompts new thoughts/questions/concerns/etc. [[User:PPelberg (WMF)|PPelberg (WMF)]] ([[User talk:PPelberg (WMF)|talk]]) 16:58, 8 July 2022 (UTC)
::Hi y'all – a quick update from the [[mw:Editing|Editing Team]]:
::We've [[phab:T312299#8075990 |completed a technical and user experience review]] of the [[User:Alexis_Jazz/EditNoticesOnMobile |User:Alexis_Jazz/EditNoticesOnMobile gadget]]. Now, @[[User:Alexis Jazz|Alexis Jazz]], myself, and other members of the team are working together in Phabricator to decide how and if we might make improvements to the gadget in response to some of the concerns we raised.
::Before this Friday is over in California (UTC-7), I ''think'' you will have two things from us:
::1. A summary of the technical and user experience investigation, and resulting discussion, [[phab:T312299|that's happening in Phabricator]] ''and'' 
::2. A link to a prototype for a potential longer-term solution for implementing edit notice on mobile that the Editing Engineering team has built, with inspiration from the gadget AlexisJazz has written. [[User:PPelberg (WMF)|PPelberg (WMF)]] ([[User talk:PPelberg (WMF)|talk]]) 04:19, 14 July 2022 (UTC)
*'''Support'''. Not too keen on waiting three weeks just for a ''proposal''. It seems like volunteers can get this up and running much faster. If paid WMF staff can later replace it with a non-hack solution, great. Until then, this works. [[User:Levivich|Levivich]]<sup class="sysop-show">[''[[Special:Block/Levivich|block]]'']</sup> 17:53, 8 July 2022 (UTC)
*'''Support''' Think this will clear a lot of confusion, especially new users/editors on mobile.--[[User:Takipoint123|Takipoint123]] ([[User talk:Takipoint123|talk]]) 16:35, 9 July 2022 (UTC)
*'''Support'''. I haven't tested this or reviewed it for security, but enough people with a clue have done the job for us.  If we expected an "official" solution in three weeks then this would be hasty, but as what we expect is a proposal then let's fix it ourselves. [[User:Certes|Certes]] ([[User talk:Certes|talk]]) 22:40, 9 July 2022 (UTC)
*'''Support''', per [[WP:SNOW|snowball clause]] and [[WP:IAR|ignore all rules]] – "If a rule prevents you from improving or maintaining Wikipedia, ignore it." [[User:CactiStaccingCrane|CactiStaccingCrane]] ([[User talk:CactiStaccingCrane|talk]]) 07:48, 10 July 2022 (UTC)
*:Can you clarify what rule do you think should be ignored? [[User:Isaacl|isaacl]] ([[User talk:Isaacl|talk]]) 20:09, 10 July 2022 (UTC)
*::The fact that you need to gather consensus and go through all of the bureaucracy for this is dumb (including those from PPelberg). It is an obvious improvement compared to the current situation, so why not give it a try? [[User:CactiStaccingCrane|CactiStaccingCrane]] ([[User talk:CactiStaccingCrane|talk]]) 08:37, 13 July 2022 (UTC)
*:::It's the general approach the community takes: it allows for everyone to provide their perspectives and possibly consider improvements and alternatives (and improvements have been made to the implementation as a result of this discussion). I don't believe there is sufficient urgency to skip the discussion process, particularly since it seems to be coming to a clear conclusion. [[User:Isaacl|isaacl]] ([[User talk:Isaacl|talk]]) 15:55, 13 July 2022 (UTC)
*'''Support'''. Editnotices are an important feature for editors on all devices and if the WMF is moving too slowly then let's take matters into our own hands. —[[User:pythoncoder#Miscellaneous|<span style="color:#004080">python</span><span style="color:olive">coder</span>]]&nbsp;([[User talk:pythoncoder|talk]]&nbsp;&#124;&nbsp;[[Special:Contribs/pythoncoder|contribs]]) 03:36, 11 July 2022 (UTC)
*'''Support'''. Why not? <span style="font-family:Iosevka,monospace">0x[[User talk:0xDeadbeef#top|<span style="text-transform:uppercase;color:black">'''Deadbeef'''</span>]]</span> 14:04, 12 July 2022 (UTC)
*'''Support'''. Editnotices help to inform editors of those articles about what restrictions or special considerations apply, and should be visible to every editor on that page. The cunctating from the WMF is just going to do more harm than good here; this is a long-standing issue that needs an answer a week ago.  —[[User:Jéské Couriano|<i style="color: #1E90FF;">Jéské Couriano</i>]] [[User talk:Jéské Couriano|<span style="color: #228B22">v^&lowbar;^v</span>]] <sup><small>[[Special:Contributions/Jéské Couriano|a little blue Bori]]</small></sup> 19:18, 12 July 2022 (UTC)

=== Discussion (showing editnotices on mobile) ===
{{tracked|T201595}}
Following up on some comments above.  Fixing in core is a significantly better solution than some sort of client-side script. We certainly would never load this as a user-script from User:* namespace if we do go this way, it would indeed need to be moved. That script also seems to incorporate other functions, that we would need to consider if they should be kept or need further rewrites for security (i.e. not importing lua functions from template space in to something that is otherwise protected to interface admins). Actual '''gadgetization''' would also be preferable.  But let's leave out more technical details from VPR right now and make this clearer for general community members that are commenting.  A better summary may be:<br /><br /><big><strong>Should the English Wikipedia put in a hack to show edit notices to mobile editors until this function is available in the software?</strong></big><br /><br /> One important factor to consider is: it this really needed for ''all'' editors on mobile, or just logged in users?  Do we really think that the average mobile IP editor is going to care what some "arbcom" says or what a "1RR" is (keeping in mind that this is really only for unprotected pages as well)? Potential negatives of this should also be considered: such as is making every single page load a bit slower, use more bandwidth, and have increased client-CPU utilization -- is that worth it here (again especially for IP readers who would have to execute this on every page load). — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 19:10, 6 July 2022 (UTC)
:Would like to hear from {{ping|Jon (WMF)|}} on this as well. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 19:12, 6 July 2022 (UTC)
*Could there be other fixes for this?  For example, this proposal is a hack to the minerva skin - well the edit page already has the edit notices available, see an example page [https://en.wikipedia.org/w/index.php?title=6th_United_States_Congress&action=edit&section=0&useskin=minerva here] - they are just behind the "Page issues" link at the top of the page.  Would being able to improve that label be a better fix?  Like instead of it says "Page issues" - what if it said "This page has special rules and notes that you should review before editing" or something like that? Ping to the proposer for thought on that: {{ping|CX_Zoom}}. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 19:32, 6 July 2022 (UTC)
*:<small>Related messages: [[MediaWiki:Mobile-frontend-meta-data-issues]] and [[MediaWiki:Mobile-frontend-meta-data-issues-header]] (we can easily mock that up on testwiki too). — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 19:35, 6 July 2022 (UTC)</small>
*::Note: looks like "mobile front end" pages are '''not''' getting this, so there may still need to be multiple technical implementations depending on how the "mobile user" is trying to access the page. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 19:40, 6 July 2022 (UTC)
*:::What if we could '''at least''' get that same label to show in mobilefrontend? — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 19:45, 6 July 2022 (UTC)
*:The edit interface found by appending <code>useskin=minerva</code> to the URL is markedly different from the mobile editing interface, which doesn't show "page issues" at all. I don't know much about technical complexity this script will add, all I know is that it works just as anyone would expect it to. It is a huge problem that it can't support mobile app. The idea is to provide standard experience to as many editors as possible. Also, I don't have concrete data but I think "mobile app" editors make a very small portion of our editors, based on app download numbers. Mobile app edit gets its own edit tag, so number of hits that tag has should give us a proper idea. If the phab ticket is fixed, that's great, but at the moment it still doesn't seem to be at WMF priority list just yet, per Mhawk's interpretation of Samwalton9 (WMF)'s comment. Samwalton9 has also stated {{tq|don't let our plans stop you from moving ahead with this in the meantime}}. In fact, I'd say if a certain issue can be solved by the community, the (understaffed) developers would be able to devote time and effort to objectives the community cannot solve by itself. <span class="nowrap">&#8212;'''[[User:CX Zoom|CX Zoom]]'''[he/him]</span> <sup class="nowrap">([[User talk:CX Zoom|let's talk]] • {[[Special:Contributions/CX Zoom|C]]•[[User:CX Zoom/X|X]]})</sup> 08:23, 7 July 2022 (UTC)
*[[User:Xaosflux|Xaosflux]], to answer some of your questions:<ul><li>I agree 100% that the script, if deployed, should be registered as a default gadget, it should definitely NOT be loaded from my userspace. There is currently a gadget (not mine) that does that ([[WP:LOCO]]) and I agree that's not advisable. [[:User:Alexis Jazz/EditNoticesOnMobile#As a gadget|Instructions are now available here]]. It's ResourceLoader compatible.</li><li>Using ResourceLoader to load it minimizes the script and clients can cache it. When it's not yet cached, the script is a [https://commons.m.wikimedia.beta.wmflabs.org/w/load.php?lang=en&modules=ext.gadget.EditNoticesOnMobile&skin=minerva <3K gzipped] download. For comparison, loading '''this very discussion page''' causes DiscussionTools to download [https://en.wikipedia.org/w/api.php?action=discussiontoolspageinfo&format=json&formatversion=2&uselang=en&page=Wikipedia%3AVillage_pump_(proposals)&oldid=1096824592 a >6K (when gzipped) JSON] that is 100% unnecessary and not cacheable in any meaningful way. In addition to that there is what is typically more than twice that (still counting gzipped) in HTML crap, which is also 100% unnecessary and guaranteed to be uncacheable. I investigated these things because [[User:Alexis Jazz/Bawl|I wrote my own script to reply]] which requires neither. And if you actually write a reply with DiscussionTools, it forces a live preview that'll generate many requests. My script doesn't force a live preview upon the user, and when it is enabled anyway it does the job using a fraction of the requests while being more responsive. But I won't hold that last bit against the WMF: the way my script handles live preview I can't recall having ever seen anywhere else, so I won't blame the WMF for not having invented that. But force-enabling live preview in DiscussionTools <i>was</i> a conscious decision, and one that sends a clear message: nobody cares about bandwidth and nobody cares about the servers using what must be considerable CPU power to parse those live previews, or the energy used by client network adapters for this stream of data. The WMF and users are okay with DiscussionTools as the former has awarded themselves a series of barn stars and the latter generally lauds DT. So no, they won't even notice a <3K gzipped cacheable script.</li><li>{{tq|i.e. not importing lua functions from template space in to something that is otherwise protected to interface admins}} <s>EditNoticesOnMobile uses [[Module:String]] which is fully protected. I am not doing that for fun. The parser completely removes elements we need on the mobile site. This was the only way (or at least, the most efficient way) I could think of to get in <i>before</i> the parser sinks its claws into the wikitext.</s> EditNoticesOnMobile no longer uses Module:String. See [[phab:T308401]].</li><li>You are correct, on desktop Minerva edit notices exist in the HTML. Hardly anybody uses desktop Minerva. [[phab:T306737|Notifications don't even work on desktop Minerva]] and nobody cares. EditNoticesOnMobile deals with both desktop and mobile Minerva though. On desktop Minerva it simply unhides the notice. On the mobile domain this isn't available so a request for the edit notice is made, but only when the "edit" button is pressed. Not on page load.</li><li>Client CPU usage when loading a notice isn't that much. It has to render the HTML, but it would have to do that anyway regardless of implementation. Sure, an implementation in MediaWiki core could be somewhat more efficient, but I say it again: <i>DiscussionTools</i>. Nobody cares about efficiency. On page load (before loading a notice), EditNoticesOnMobile does hardly anything.</li></ul>Update: Module:String no longer needed. <span id="Alexis_Jazz:1657155573499:WikipediaFTTCLNVillage_pump_(proposals)" class="FTTCmt">— <span style="color:#e08020">Alexis Jazz</span> ([[User talk:Alexis Jazz|talk]] or ping me) 00:59, 7 July 2022 (UTC)</span>
*:@[[User:Alexis Jazz|Alexis Jazz]] Thank you for the updates! I think some of us care about efficiency at least a little bit. I think the comparisons to DisucssionTools is a bit of a red herring, DT isn't loading on every page view of every article, (and the script would be loading on every load - it just wouldn't ''also'' be doing even more loading until after clicking edit) the most common pages for logged out mobile users to come across and maybe, if we are lucky, to click edit and add something nice to. I do agree that we have an overall problem - we make edit notices for the benefit of editors, and editors aren't getting them - that is quite undesirable. So part of my hesitation is that because this is important, relying on client-side script processing feels wrong. Would like to get some feedback from some more of the mobile-dev's though, a "don't worry about it" would be nice from them. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 01:35, 7 July 2022 (UTC)
*::[[User:Xaosflux|Xaosflux]], it's true that DT isn't loaded on every page, but even so, it's a story about efficiency. EditNoticesOnMobile could be made smaller than it already is: uncouple the addEventListener into its own file and only load the rest of the script when the edit button is pressed. The notice can take slightly longer (pretty much your ping time to Wikimedia if the script has to be requested) to appear in this case. But the savings might be smaller than you think. It depends on how ResourceLoader will handle this exactly on enwiki, which will also vary from user to user. A request for a 100 byte JS (if no other scripts are downloaded in the same request) ends up producing >1K traffic due to overhead anyway. And since the script is cacheable I doubt uncoupling is really worth it. The script could be minified somewhat more, I tried putting it through my own [[User:Alexis Jazz/AJSJSMangler|AJSJSMangler]] resulting in [[:User:Alexis Jazz/EditNoticesOnMobile.min.js]] which is a little shorter but the gzipped difference is next to nothing. Some classnames etc could be shortened, but is it really worth it?<br style="margin-bottom:0.5em"/>And if you think DT is a red herring, you might be interested in ULS instead. [[phab:T308557]] was resolved by adding ext.uls.common as a dependency, which (I'd think) means that it'll be loaded on page load, but nobody got back to me on that so I don't know for sure. Btw, Matma Rex informed me of a special API feature on [[:phab:T308401]] so EditNoticesOnMobile no longer needs Module:String. <span id="Alexis_Jazz:1657166378547:WikipediaFTTCLNVillage_pump_(proposals)" class="FTTCmt">— <span style="color:#e08020">Alexis Jazz</span> ([[User talk:Alexis Jazz|talk]] or ping me) 03:59, 7 July 2022 (UTC)</span>
*:::@[[User:Alexis Jazz|Alexis Jazz]] good news on getting rid of a template call! Are you at a point where we can do some more testing of this on testwiki? — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 09:56, 7 July 2022 (UTC)
*::::[[User:Xaosflux|Xaosflux]], okay.. now. I just added [[localStorage]] caching: notices are cached for 12 hours. (the actual duration could be adjusted if deemed necessary) If a particular notice is dismissed, it won't show for 12 hours. When I checked, for just a moment, I thought the gzipped size had grown to 5K, but I was wrong. I was looking at the wrong entry: [https://commons.m.wikimedia.beta.wmflabs.org/favicon.ico Commons' favicon.ico] is 5K gzipped, including network overhead. I often test on betacommons, EditNoticesOnMobile is available as a gadget there. EditNoticesOnMobile however is just a hair over 3K gzipped now. For reference, enwiki's [[Favicon]] [https://en.wikipedia.org/favicon.ico] is about half the size of Commons' favicon.<br style="margin-bottom:0.5em"/>The size increase is negligible, but it prevents making multiple parse requests for the same page when editing a page more than once. I think it's a good tradeoff. Testing on testwiki works for me, but we should consider that template behavior could differ on another wiki. In particular {{tl|tmbox}} and {{tl|fmbox}}. An alternative could be to register EditNoticesOnMobile as a gadget here, just not enabled by default for anyone. Could even be hidden. (testers would have to append withgadget=EditNoticesOnMobile to a URL in that case)<br style="margin-bottom:0.5em"/>If deployed, I think it would be wise to do a gradual rollout, enabling it for some subset of users first. Just in case some browser or device wouldn't handle it as expected. <span id="Alexis_Jazz:1657223727150:WikipediaFTTCLNVillage_pump_(proposals)" class="FTTCmt">— <span style="color:#e08020">Alexis Jazz</span> ([[User talk:Alexis Jazz|talk]] or ping me) 19:55, 7 July 2022 (UTC)</span>
*:::::Let's follow up tech testing talk at [[User talk:Alexis Jazz/EditNoticesOnMobile]]. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 20:39, 7 July 2022 (UTC)
{{abottom}}