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 GiantSnowman (talk · contribs) 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? Walter Görlitz (talk) 05:47, 1 May 2022 (UTC)

Apparently the issue concerns edits 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. 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. GiantSnowman 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. 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). GiantSnowman 14:21, 1 May 2022 (UTC)

Very short and easy answer - no they can't. 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. —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. Hawkeye7 (discuss) 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? 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. 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. 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? 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? 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. —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 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. 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. North8000 (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?) GiantSnowman 18:30, 1 May 2022 (UTC)

Can anyone explain why this actually matters? 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. GiantSnowman 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". 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. 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. GiantSnowman 20:53, 1 May 2022 (UTC)

@Walter Görlitz: The question is, can a project just ignore the manual of style? WP:LOCALCONSENSUS says not. --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. 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. GiantSnowman 20:50, 1 May 2022 (UTC)

Can somebody please persuade Walter to stop single-handedly trying to force the MOS on articles when there is clear opposition to the same? GiantSnowman 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? 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 that editors should usually attempt to follow. While occasional exceptions may apply, that does not mean it should be ignored by whole projects. MB 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. 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... GiantSnowman 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. MB 19:06, 2 May 2022 (UTC)

Per WP:CONLEVEL, 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. BilledMammal (talk) 00:26, 2 May 2022 (UTC)

there is a discussion here...and many are saying 'the MOS' does not need to apply. GiantSnowman 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? -- Vaulter 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. GiantSnowman 08:31, 2 May 2022 (UTC)

  @Vaulter, @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. 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. 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." -- Vaulter 15:49, 5 May 2022 (UTC)

  this is a fair point about accessibility - but what about '2002–pres.'? GiantSnowman 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"? —Kusma (talk) 23:20, 5 May 2022 (UTC)

  An excellent idea. MichaelMaggs (talk) 10:54, 6 May 2022 (UTC)

  @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. WhatamIdoing (talk) 19:21, 6 May 2022 (UTC)

  @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. —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. 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. -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. Blueboar (talk) 13:56, 2 May 2022 (UTC)
• Repeal. MOS:DATETOPRES is improper because:
  1. According to the OED, "pres." is an abbreviation for "president" not present. The suggested usage is therefore not standard English.
  2. 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.
  3. The discussion above indicates that it lacks consensus
  4. WP:CREEP

Andrew🐉(talk) 19:22, 2 May 2022 (UTC)

Agree with it being removed or amended. GiantSnowman 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 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. Levivich 19:25, 2 May 2022 (UTC)

  FYI it's multiple WikiProjects that 'ignore' it, not just one... GiantSnowman 20:16, 2 May 2022 (UTC)

  It was boldly added with 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. Hawkeye7 (discuss) 20:37, 2 May 2022 (UTC)

  which post-dates the way that the WikiProjects in question have been editing by at least 10 years... GiantSnowman 10:57, 3 May 2022 (UTC)

  Unfortunately, there is no rationale provided for the change either. Hawkeye7 (discuss) 06:04, 5 May 2022 (UTC)

As Indy beetle says, the best way forward is to have a discussion to establish consensus. Unlike the 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. 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. -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. 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. 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. 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 the information page: 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! -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: 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. 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. -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. GiantSnowman 11:42, 3 May 2022 (UTC)

      @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 according to the information page lack any authority ("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. 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: It is not a mandatory policy that editors must assiduously follow. 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 (talk) (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. GiantSnowman 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, North8000 (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. 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. GiantSnowman 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. – Joe (talk) 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. GiantSnowman 15:36, 3 May 2022 (UTC)

  There are clear grumblings about this situation from many outside the various WikiProjects. Great! Let's go do something about it! -Indy beetle (talk) 16:03, 3 May 2022 (UTC)

  We kinda already are! GiantSnowman 16:16, 3 May 2022 (UTC)

  To put it in simple terms for you, what links the two is WP:OWNERSHIP. – Joe (talk) 07:27, 4 May 2022 (UTC)

  Useful contributions only please. GiantSnowman 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)? Hawkeye7 (discuss) 21:57, 5 May 2022 (UTC)

  An excellent suggestion. ((Screen reader-only)) may be useful here. I don't see its converse ((Except screen reader)) but, if the dash is visible and silent, we don't need one. Certes (talk) 23:52, 5 May 2022 (UTC)

  yes, this seems like a fantastic compromise. GiantSnowman 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.— Ixtal ^{( T / C )} ⁂ Join WP:FINANCE! 08:14, 6 May 2022 (UTC)
• 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. 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'. GiantSnowman 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. 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. GiantSnowman 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. 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.) WhatamIdoing (talk) 19:38, 6 May 2022 (UTC)

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 ((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??? 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 1,450 results. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (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. GiantSnowman 07:50, 7 May 2022 (UTC)

  Very few of them are "–pres"; almost all of them (98%?) are "–present". You can see the abbreviation in the last row of the table at Colorado Buffaloes men's basketball#Record by coach. WhatamIdoing (talk) 20:44, 16 May 2022 (UTC)

  Still shows that it is barely used. GiantSnowman 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. —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. 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. —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, Lee Vilenski ^{(talk • contribs)} 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. GiantSnowman 21:05, 10 May 2022 (UTC)

Further on the history discussed above: as noted, the 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 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. -- Visviva (talk) 02:35, 22 May 2022 (UTC)

Agreed. GiantSnowman 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. Herostratus (talk) 03:28, 3 June 2022 (UTC)

It should be removed, as numerous editors have said here. GiantSnowman 07:38, 3 June 2022 (UTC)

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

---

Moved to Wikipedia:Village pump (technical) § Fix Wikipedia Adventure by adding buttons to progress in "click on edit button" steps

After some updates, 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. Aaron Liu (talk) 06:27, 4 June 2022 (UTC)

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

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?--Rocknrollmancer (talk) 20:11, 29 May 2022 (UTC)

@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)? — xaosflux ^Talk 14:22, 31 May 2022 (UTC)

Yes, that's what I tried to imply 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. Rocknrollmancer (talk) 16:46, 31 May 2022 (UTC)

@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. — xaosflux ^Talk 18:33, 31 May 2022 (UTC)

@Rocknrollmancer: Enable a gadget in your preferences to show some common summaries. TSOPar (talk) 17:20, 5 June 2022 (UTC)

Moved from Wikipedia:Village pump (technical) § Substitute int: messages

The ((int:filedesc)) and ((int:license-header)) 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 @Novem Linguae: wanted consensus so I post it here to get it.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 about 4000 pages affected in the File namespace. If no objections I will file a BRFA shortly. Thanks. –Novem Linguae (talk) 18:38, 8 June 2022 (UTC)

• No way. The ((int:...)) 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, ((int:filedesc)) 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? --Redrose64 🌹 (talk) 19:41, 8 June 2022 (UTC)

  Moved. –Novem Linguae (talk) 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. 🐶 EpicPupper ^{(he/him | talk)} 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. 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. 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. isaacl (talk) 22:59, 8 June 2022 (UTC)

• On occasion, I post messages with an ((int))-based invitation to read it in another language (More languages), and an invitation to translate it into another language (Please help translate to other languages.). Ideally, these should show in the user's interface language (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? 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 ((int: )) 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. —CX Zoom[he/him] ^{(let's talk • {C•X})} 08:10, 10 June 2022 (UTC)

  @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.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. — xaosflux ^Talk 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? — xaosflux ^Talk 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). —Kusma (talk) 11:16, 10 June 2022 (UTC)

Moved from Wikipedia:Village pump (technical)

On May 14, I created a template protected edit request at 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. 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 ((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 ((Talk header)) 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?

Pinging users at the previous discussion: @Paine Ellsworth, FlightTime, Bsherr, Mathglot, Shibbolethink, and Sdkb 0xDeadbeef 10:32, 9 June 2022 (UTC)

1, it can be confusing. 🐶 EpicPupper ^{(he/him | talk)} 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 ((Archives)) since it seemed reasonable to me and it is a supported feature for ((Archive list)). Indexing from 0 is pretty standard for computing and it didn't really raise any concern for me. ((Archives)) and ((Talk header)) serve different purposes and while ((Talk header)) is less appropriate for user talk, ((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 ((Talk header)) Terasail^[✉️] 11:40, 9 June 2022 (UTC)

Is this not more for VPR/VPP than technical though? Terasail^[✉️] 11:49, 9 June 2022 (UTC)

I'm not sure. Feel free to move it. 0xDeadbeef 11:52, 9 June 2022 (UTC)

Did you mean ((Talk header))? 0xDeadbeef 11:53, 9 June 2022 (UTC)

Ah yes I did Terasail^[✉️] 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. —CX Zoom[he/him] ^{(let's talk • {C•X})} 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? —CX Zoom[he/him] ^{(let's talk • {C•X})} 13:42, 9 June 2022 (UTC)

  The use case of yearly archives such as yours would also be included here since they require a |start= parameter in order to be detected by the templates. Terasail^[✉️] 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 |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. P.I. Ellsworth , ed. ^put'r there 14:45, 9 June 2022 (UTC)

  @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. 0xDeadbeef 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? P.I. Ellsworth , ed. ^put'r there 08:15, 11 June 2022 (UTC)

  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. 0xDeadbeef 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. P.I. Ellsworth , ed. ^put'r there 12:45, 11 June 2022 (UTC)

• 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. —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. 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? 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? 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. P.I. Ellsworth , ed. ^put'r there 02:48, 10 June 2022 (UTC)
• 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. — xaosflux ^Talk 15:42, 11 June 2022 (UTC)

PASSED

There is clear consensus to adopt the proposal. (non-admin closure) ((u|Sdkb)) ^talk 16:10, 11 June 2022 (UTC)

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

---

The Main Page 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 here.

Ping to those who participated in the original discussion: @Ravenpuff @Stephen @Izno @Xaosflux 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. --Izno (talk) 21:54, 2 June 2022 (UTC)
• Support (Isn't this a web standard by now?) 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.) 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 (talk) (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. 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 (talk) (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. Seraphimblade ^{Talk to me} 02:07, 3 June 2022 (UTC)
• I support having a responsive design that can adapt to different screen display widths. isaacl (talk) 02:15, 3 June 2022 (UTC)
• Support 🐶 EpicPupper ^{(he/him | talk)} 02:32, 3 June 2022 (UTC)
• Support responsive main page is brilliant. This should have been done eons ago. – SD0001 (talk) 12:02, 3 June 2022 (UTC)
• Support obviously MichaelMaggs (talk) 12:35, 3 June 2022 (UTC)
• Support, clear improvement for those who don't log in or can't use superior skins like Monobook. —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. – Joe (talk) 16:55, 5 June 2022 (UTC)

  Regarding Vector particularly, this recent blog post by a WMF engineer may be of interest. Izno (talk) 00:40, 6 June 2022 (UTC)

• Support, long time coming. Good usability is good. -- 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. – Joe (talk) 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. 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. – Joe (talk) 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. 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. — xaosflux ^Talk 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. 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 192 and 198. 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, Lectrician1, for bringing this home. Levivich 03:47, 6 June 2022 (UTC)

• Support a responsive design. Gonnym (talk) 17:07, 5 June 2022 (UTC)
• Support an update is clearly required. – 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. —Jéské Couriano v^_^v ^{a little blue Bori} 21:49, 5 June 2022 (UTC)

• 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? -- RoySmith (talk) 01:06, 6 June 2022 (UTC)

  @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 with this link. — xaosflux ^Talk 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. -- 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). 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? -- 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. 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. -- RoySmith (talk) 13:34, 7 June 2022 (UTC)

  I've learned something. :D Safari < 15 is bugged when text zoomed, which is 4% of our views, but apparently Safari at some age is broken with px media queries also.

  I can take a look at this. 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. Izno (talk) 02:09, 8 June 2022 (UTC)

• Support. Uncontroversial modernization. MarioGom (talk) 07:38, 10 June 2022 (UTC)
• Support - baby steps for the front page but progress is progress. Retswerb (talk) 03:38, 11 June 2022 (UTC)

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

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. 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, BD2412? Is there some auto- or semi-automated way? If so, i'll happily take some of this on. Happy days ~ Lindsay^Hello 08:05, 14 May 2022 (UTC)

FYI 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. | closed_date = <!-- ((End date|YYYY|MM|DD|df=y)) -->). 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. – Muboshgu (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. 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. 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. <!-- Badly terminated comment > Smith is an [[actor]] who did some [[film]]s. <!-- Valid comment -->, which quietly hides the intervening wikitext. Certes (talk) 19:56, 14 May 2022 (UTC)

Yes, I think we need to go after all of these issues. 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. Herostratus (talk) 22:24, 23 May 2022 (UTC)

I just found 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. 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 (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. 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 (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. 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 (talk) 12:35, 31 May 2022 (UTC)

@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. 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. 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. —Kusma (talk) 12:47, 5 June 2022 (UTC)

User:Δ has 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. 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 cheatsheet for nearly a decade. I don't see a reason to remove these en masse, but a tracking category could be useful. - LCU ActivelyDisinterested ∆transmissions∆ °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. 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. 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. 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. 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. Thryduulf (talk) 19:29, 11 June 2022 (UTC)

I would like to notify the Village Pump of a proposal to prohibit WikiProjects from ranking articles as A-class that was filed at MfD yesterday. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 18:55, 18 June 2022 (UTC)

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 — Preceding unsigned comment added by SSHTALBI (talk • contribs) 12:55, 25 June 2022 (UTC)

@SSHTALBI This should probably be requested at Talk:Main Page or Template talk:Wikipedia languages. --Ahecht (TALK
PAGE) 16:07, 25 June 2022 (UTC)

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 discussion page. Thank you. BilledMammal (talk) 10:53, 26 June 2022 (UTC)

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: 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. 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. 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. 2A02:810D:933F:E250:D942:55FA:23A0:689B (talk) 11:30, 18 June 2022 (UTC)

Ingen orsak! Gråbergs Gråa Sång (talk) 13:45, 18 June 2022 (UTC)

Section can be archived. 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. 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). --Redrose64 🌹 (talk) 21:00, 18 June 2022 (UTC)

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 issues about whether to call it "list".

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

1. Unison, which is not a list
2. Second_(disambiguation)#Music, redirected from Second (music)
3. Third#Music theory, redirected from Third (music)
4. Fourth (music)
5. List of fifth intervals, see also Fifth#Music
6. Sixth, redirected from Sixth (music)
7. Seventh#Music, redirected from Seventh (music)
8. 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.

--吳傲雪 (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. 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. --吳傲雪 (talk) 03:56, 29 June 2022 (UTC)

In 2012, an RFC decided that unpatrolled articles should be NOINDEXED until reviewed and accepted. In 2016, it was implemented differently as discussed 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 the NPP discussion page if you would like to comment. MB 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. — xaosflux ^Talk 21:07, 28 June 2022 (UTC)

I think it would be best to do as suggested by xaosflux, if only to ensure each of our behinds are adequately covered — does that sound okay MB? — TNT (talk • she/her) 19:50, 29 June 2022 (UTC)

• @Xaosflux, TheresNoTime, and 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. 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. — xaosflux ^Talk 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. MB 00:14, 30 June 2022 (UTC)

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

There is 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. 0xDeadbeef 01:35, 21 June 2022 (UTC)

---

Should the new topic tool be enabled by default on English Wikipedia? ((u|Sdkb)) ^talk 21:33, 27 May 2022 (UTC)

Background

The 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 talk pages project. A few months ago, we enabled their reply tool by default. The new topic tool is a similar tool for starting new sections on talk pages; you can preview it by clicking here and choosing "Add topic" at upper right, next to the history tab.

The editing team has informed us In light of the recent A/B test results showing the positive impact of the New Topic Tool, the 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 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 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. ((u|Sdkb)) ^talk 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. -- 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. 🐶 EpicPupper ^{(he/him | talk)} 01:56, 28 May 2022 (UTC)
•  Support, makes sense after the reply tool. ― Qwerfjkltalk 07:18, 28 May 2022 (UTC)
• Strong support I think it's a great and simple-to-learn tool. — Ixtal ^{( T / C )} ⁂ Join WP:FINANCE! 11:27, 28 May 2022 (UTC)
• Support There are bunch of userscripts that help to do the same though. AXONOV (talk) ⚑ 13:28, 28 May 2022 (UTC)
• Support An improvement over the raw wikitext form. – SD0001 (talk) 16:41, 28 May 2022 (UTC)
• Support I've found it to be an excellent counterpart to the reply tool. Sideswipe9th (talk) 15:25, 29 May 2022 (UTC)
• Support Nice improvement. MichaelMaggs (talk) 17:15, 30 May 2022 (UTC)
• Sure, why not? Go for it. --Jayron32 18:13, 31 May 2022 (UTC)
• Support: Useful tool. —CX Zoom[he/him] ^{(let's talk • {C•X})} 18:53, 31 May 2022 (UTC)
• Support I've been using the tool and it's a great improvement. - LCU ActivelyDisinterested ∆transmissions∆ °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. 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. MarioGom (talk) 11:04, 4 June 2022 (UTC)

Support It sign comments. TSOPar (talk) 13:53, 5 June 2022 (UTC) ( Blocked sockpuppet) —CX Zoom[he/him] ^{(let's talk • {C•X})} 07:15, 8 June 2022 (UTC)

• Support. It signs comments, it's nice for both new users and for me! SWinxy (talk) 16:19, 5 June 2022 (UTC)
• Support Works well for me. 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. Terasail^[✉️] 14:15, 7 June 2022 (UTC)
• Support - nice job to the Editing Team working on this, thanks for the improvement! Retswerb (talk) 03:35, 11 June 2022 (UTC)

Discussion (New Topic Tool)

Courtesy pings: PPelberg (WMF), Whatamidoing (WMF). Notified: WT:Usability, WT:Talk pages project. ((u|Sdkb)) ^talk 21:33, 27 May 2022 (UTC)

hi y'all – on the topic of, "How will people who prefer the existing section = new workflow be able to turn off the New Topic Tool?"...

In addition to what @Sdkb mentioned above about you being able to disable the New Topic Tool within Special:Preferences, the tool offers peoples the ability to switch back to the existing section = new experience from directly within the tool as pictured here:

PPelberg (WMF) (talk) 02:04, 28 May 2022 (UTC)

Please see this.[4] "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." — Preceding unsigned comment added by Doug Weller (talk • contribs) 12:17, 28 May 2022 (UTC)

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. Matma Rex talk 21:43, 28 May 2022 (UTC)

@Matma Rex please take a look at the whole thread.[5]. You've pointed to an earlier version. I can't fit it into a screen shot. 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). Matma Rex talk 18:56, 30 May 2022 (UTC)

• Does this still have the "feature" of hijacking the "create a page" process for brand new talk pages? — xaosflux ^Talk 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 T297990. Matma Rex talk 17:41, 31 May 2022 (UTC)

  [Update] The Editing Team is going to prioritize implementing what @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 empty state experience.

  We expect this new setting to be available in the next few weeks. PPelberg (WMF) (talk) 16:04, 2 June 2022 (UTC)

  @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…"). Matma Rex talk 21:13, 7 June 2022 (UTC)

  Thanks for the update @Matma Rex! — xaosflux ^Talk 22:50, 7 June 2022 (UTC)

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

Doing this

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 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. Whatamidoing (WMF) (talk) 17:01, 23 June 2022 (UTC)

@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. Doug Weller talk 17:42, 23 June 2022 (UTC)

@Doug Weller reply-tool doesn't load edit notices for the page. — xaosflux ^Talk 18:26, 23 June 2022 (UTC)

@Xaosflux this looks like a major flaw. And I presume one that can’t be fixed. I wish I’d thought of this earlier. Doug Weller talk 18:28, 23 June 2022 (UTC)

@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) — xaosflux ^Talk 18:35, 23 June 2022 (UTC)

@Xaosflux Ah, that makes a big difference. In most cases that would suffice. Thanks. Doug Weller talk 18:42, 23 June 2022 (UTC)

Also, this is only about the "Add topic" component. Whatamidoing (WMF) (talk) 17:21, 24 June 2022 (UTC)

@Whatamidoing (WMF) yes, that’s what I understood. Thanks. 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. Whatamidoing (WMF) (talk) 20:18, 27 June 2022 (UTC)

These config changes have been deployed now. Matma Rex talk 13:38, 29 June 2022 (UTC)

@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 (link) as opposed to (dtenable forced) the new section discussion tool. — xaosflux ^Talk 14:02, 29 June 2022 (UTC)

They do not appear deployed yet to me, either. ((u|Sdkb)) ^talk 14:03, 29 June 2022 (UTC)

phab:T311023 appears to still be open too? Ping to @Whatamidoing (WMF): as requested above. — xaosflux ^Talk 14:14, 29 June 2022 (UTC)

We've investigating now, it seems like the changes haven't been deployed to all servers. Matma Rex talk 14:44, 29 June 2022 (UTC)

@Xaosflux @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. Matma Rex talk 14:59, 29 June 2022 (UTC)

@Matma Rex - thank you, my last 3 tests seem to be working now. — xaosflux ^Talk 15:25, 29 June 2022 (UTC)

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? Eurohunter (talk) 17:04, 16 June 2022 (UTC)

Define what a "physical work" is here. Headbomb {t · c · p · b} 18:52, 16 June 2022 (UTC)

I assume a wall covered in latin insults would be a physical work. ScottishFinnishRadish (talk) 18:55, 16 June 2022 (UTC)

((citation|mode=cs1|...)) should do the trick here. Headbomb {t · c · p · b} 18:59, 16 June 2022 (UTC)

Are you thinking of citing something like the Orkhon inscriptions? Gråbergs Gråa Sång (talk) 19:00, 16 June 2022 (UTC)

@Gråbergs Gråa Sång:, @Headbomb:,@ScottishFinnishRadish: Wrong translation. I mean every printed work such as magazine, encyclopedia, book etc. Eurohunter (talk) 19:22, 16 June 2022 (UTC)

@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. Gråbergs Gråa Sång (talk) 19:26, 16 June 2022 (UTC)

@Gråbergs Gråa Sång: I mean if it not book or magazine. What then? Eurohunter (talk) 19:28, 16 June 2022 (UTC)

Example? Gråbergs Gråa Sång (talk) 19:29, 16 June 2022 (UTC)

There are plenty available - see box at right. Whilst all of them accept a |url= parameter, they are primarily for hardcopy sources, with the exception of ((cite AV media)), ((cite episode)), ((cite web)) and one or two others. --Redrose64 🌹 (talk) 19:49, 16 June 2022 (UTC)

@Gråbergs Gråa Sång: @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. 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 (talk) (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 ((cite xxx)) template for physical (real) works with no specific classification, similar to the way ((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. 50.75.226.250 (talk) 14:48, 17 June 2022 (UTC)

You can use ((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. 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. 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. 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. ⁓ Pelagic ( messages ) 21:37, 2 July 2022 (UTC)

Good day! I want to change something to 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 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 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? —Kusma (talk) 08:24, 6 July 2022 (UTC)

Kindly check this:

In this name that follows Philippine naming customs, the middle name, Cruz, is a patronymic, not the maternal family name, and the surname is Santos. RenRen070193 (talk) 12:03, 6 July 2022 (UTC)

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. 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. --Smokefoot (talk) 18:15, 24 June 2022 (UTC)

 Previous discussion: Talk:Blue § Colour blue in culture

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 he seek consensus for future color-article splits at a forum with better traffic than an inactive project, and here we are. 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 — PerfectSoundWhatever (t; 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. -- 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 @Smokefoot:, shouldn't the title of the article be Blue in culture? What else would "blue" refer to? — PerfectSoundWhatever (t; c) 01:35, 25 June 2022 (UTC)

Perhaps Blues may be confused with this? 0xDeadbeef 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. — PerfectSoundWhatever (t; c) 02:13, 25 June 2022 (UTC)

@PerfectSoundWhatever: Blue note. --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. 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? -- 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, 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. ((u|Sdkb)) ^talk 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? — PerfectSoundWhatever (t; c) 20:08, 25 June 2022 (UTC)

  @PerfectSoundWhatever: It's not such a bad idea, because having Blue as the parent article of two 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. (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.) 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.) Mathglot (talk) 19:44, 27 June 2022 (UTC)

  @Mathglot and Smokefoot: I created a mockup of the above in my sandbox: User:PerfectSoundWhatever/sandbox (revision for when I change my sandbox), 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. — PerfectSoundWhatever (t; 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.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. Levivich^[block] 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 summary style-section in a parent article for which a stand-alone child article exists. Or perhaps that's what you meant? Mathglot (talk) 23:39, 27 June 2022 (UTC)

  I posted my comment one minute before Smokeyfoot added a 6k summary. What a fast typist! :-) Levivich^[block] 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 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 Russian do not have a single corresponding word. So, the very concept is a cultural artifact.

See also The Two Cultures. Andrew🐉(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.--Smokefoot (talk) 23:35, 28 June 2022 (UTC)

Red in culture is another arbitrary and unhelpful split. Note that it has a section 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". Andrew🐉(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. --Smokefoot (talk) 15:43, 6 July 2022 (UTC)

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 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! 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. —Kusma (talk) 16:21, 25 June 2022 (UTC)

  And strong oppose for L., the most famous abbreviation in biology. —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. 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 (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 @WhatamIdoing as I first heard about the clickstream tool from her whether she has further insight. —Kusma (talk) 18:42, 25 June 2022 (UTC)

  Anyone can try it out. For example, 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. 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 (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. —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. --Ahecht (TALK
PAGE) 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? 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. Certes (talk) 17:53, 25 June 2022 (UTC)

Fortunately we have some data about what readers do! [6] 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. —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. Phil Bridger (talk) 18:25, 25 June 2022 (UTC)

If they find a better encyclopaedia somewhere else, I would be curious to know where. —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. 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. —Kusma (talk) 18:46, 25 June 2022 (UTC)

Yeah, why should we bother with the data when guesses are so much better! – 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. 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. —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. 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. -- King of ♥ ♦ ♣ ♠ 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. 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. 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. -- Visviva (talk) 19:43, 25 June 2022 (UTC)

  I usually go for an "insource:" search (example), though I suspect someone here may come up with a more elegant solution. – Uanfala (talk) 19:49, 25 June 2022 (UTC)

  A search for linksto:"V." -Pynchon yields just one result: a false positive. I don't know how many links were once wrong; there are people who fix such things. 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. -- Visviva (talk) 04:53, 26 June 2022 (UTC)

• Oppose, 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. --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. Levivich^[block] 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). Thryduulf (talk) 09:09, 26 June 2022 (UTC)
•  Oppose per WP:INSTRUCTIONCREEP. This is overly specific. ― Qwerfjkltalk 14:44, 26 June 2022 (UTC)
• 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. --Bison X (talk) 22:34, 26 June 2022 (UTC)
• Oppose. Per WP:SMALLDETAILS, V. is not the same as 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. ModernDayTrilobite (talk • 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. BD2412 T 00:30, 30 June 2022 (UTC)
• Who will go through and pipe all the existing [[L.]] links? Or do we consistently use ((L.)) already? Oh, I tried Certes' suggestion and was surprised to get only 85 hits for linksto:"L." 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".) ⁓ Pelagic ( messages ) 11:59, 4 July 2022 (UTC)
  • I will gladly undertake the piping task, as routine disambiguation fixing. BD2412 T 00:22, 7 July 2022 (UTC)

Hi! I'd like to propose enabling 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 here), for navigating excerpt trees (see box with tree icon here) for injecting interactive widgets on some articles (here and here) and more recently for creating interactive forms that inject content into other pages (see template 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? 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. — xaosflux ^Talk 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. — xaosflux ^Talk 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. – 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. 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. —CX Zoom[he/him] ^{(let's talk • {C•X})} 23:48, 29 June 2022 (UTC)

@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. — xaosflux ^Talk 10:16, 30 June 2022 (UTC)

@Xaosflux: I did some TWA on 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? —CX Zoom[he/him] ^{(let's talk • {C•X})} 14:47, 30 June 2022 (UTC)

It 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!). — xaosflux ^Talk 14:54, 30 June 2022 (UTC)

How about 1 question everyday based off WP:DYK. Sungodtemple (talk) 14:07, 30 June 2022 (UTC)

Isn't 1 a bit too low? I think of starting with 5 per day. —CX Zoom[he/him] ^{(let's talk • {C•X})} 14:52, 30 June 2022 (UTC)

As I discussed at 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. isaacl (talk) 01:07, 1 July 2022 (UTC)

Thanks, 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! —CX Zoom[he/him] ^{(let's talk • {C•X})} 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! isaacl (talk) 15:25, 1 July 2022 (UTC)

Hi guys! @Johnuniq Regarding the security risk, isn't it essentially the same as with default gadgets or MediaWiki:Common.js itself? TemplateScripts will just have to go through a similar review process. @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! 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. [7]). 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. – Joe (talk) 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. —TheDJ (talk • 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. – 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. —TheDJ (talk • 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. – 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 Vivarium and Formicarium). For example, check out 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! Sophivorus (talk) 13:21, 8 July 2022 (UTC)

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: ((short description)), ((Use dmy dates)), ((pp-semi-protected)), ((hatnote)), ((Use British English)), ((Pp-move-indef)), ((Featured article)), and so forth. I suppose the advantages would be consistency, simplified maintenance, lower confusion for new editors, and easier management via bots. 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. 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 ((Use Oxford spelling)), ((Use American English)), ... ((Use Sri Lankan English)) templates, you can have a single parameter such as 'spelling_variant='. 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. --Ahecht (TALK
PAGE) 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. Gonnym (talk) 14:27, 11 July 2022 (UTC)

I would support integrating all protection templates into one, but not ((use dmy dates)), etc. Keeping them at the top of page informs new editors of the correct style to be used. —CX Zoom[he/him] ^{(let's talk • {C•X})} 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 Category:Wikipedia pages with incorrect protection templates. --Redrose64 🌹 (talk) 20:10, 12 July 2022 (UTC)

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:

1. 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.
2. 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.
3. 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. Pablothepenguin (talk) 19:02, 11 July 2022 (UTC) Pablothepenguin (talk) 19:02, 11 July 2022 (UTC)

@Pablothepenguin Editors in recent times have been highly resistant to creating new subject-specific notability guidelines, so we're left with the 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 WikiProject Transport for more info. ((u|Sdkb)) ^talk 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 5 miles (8.0 km) 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. — xaosflux ^Talk 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? Pablothepenguin (talk) 23:48, 11 July 2022 (UTC)

WP:AFD is right around the corner, — xaosflux ^Talk 00:33, 12 July 2022 (UTC)

Special:PrefixIndex/Wikipedia:Articles_for_deletion/London_Buses_route has some interesting reading! — xaosflux ^Talk 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! — xaosflux ^Talk 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. — xaosflux ^Talk 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. 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. - Donald Albury 01:23, 12 July 2022 (UTC)

Perhaps don't do that... Anarchyte (talk) 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. --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. 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. 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.North8000 (talk) 13:57, 12 July 2022 (UTC)

  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. 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. 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. Thryduulf (talk) 19:16, 12 July 2022 (UTC)

I will be careful. Pablothepenguin (talk) 19:21, 12 July 2022 (UTC)

If you, or someone (unlikely) could write a raft of articles 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 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. Kudpung กุดผึ้ง (talk) 22:35, 12 July 2022 (UTC)

The Foundation has changed jawiki's default skin to Vector (2022).
Discussions on jawiki about this matter have been confusing.
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.
The Foundation will try to make changes to enwiki next.(https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements)
Would the English-speaking community agree with this?
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.
If not, once changes are made, it will be very difficult to revert.
Please ask the communities you know, such as Facebook, Twitter, WhatsApp, and Discord, whether they agree or disagree with the Vector (2022) specification.
Then, invite everyone on each social network to participate in the discussion.
Whatever the outcome, we believe it will lead enwiki in a better direction.

(Original text)
jawikiの前例から考えるVector (2022)のデフォルトスキン化の懸念について
財団はjawikiのデフォルトスキンをVector (2022)を変更しました。
この件についてjawikiでは議論が紛糾しています。
また、一般ユーザーへの告知がなく、突然行われたため、日本のSNSコミュニティでも変更への混乱が広がっています。
財団は次にenwikiに変更を加えようとするでしょう。(https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/ja)
このことについて英語圏の皆様は賛成でしょうか？
日本語圏と英語圏ではサイトデザインへの考え方が異なるので、英語圏の皆様が問題ないと考えるのであれば、このトピックは忘れて下さい。
そうでないのであれば、一度変更が加えられたら戻すのは大変です。
Facebook、Twitter、WhatsApp、及びDiscord等あなたの知る限りのコミュニティでVector (2022)の仕様について賛否を問うて下さい。
そして、各SNSの皆様に議論への参加を呼び掛けて下さい。
結果がどうであれ、そのことがenwikiをより良い方向へ導くと信じます。 HarukaFujihira (talk) 21:01, 12 July 2022 (UTC)

• Why would we ask social media? 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).
  

  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.
  

  I have proposed a method to inform IP users in advance through social networking services as a way to prevent confusion in advance.
  

  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. HarukaFujihira (talk) 02:44, 13 July 2022 (UTC)

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