This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
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)
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. GiantSnowman07: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). GiantSnowman14:21, 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)
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)
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?) GiantSnowman18:30, 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. GiantSnowman18: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. GiantSnowman20:53, 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. GiantSnowman20:50, 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. MB21: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... GiantSnowman08: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. MB19: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)
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? -- Vaulter01:44, 2 May 2022 (UTC)
exactly. I have been editing for 16 years, at no point has any reader expressed confusion in this regard. GiantSnowman08:31, 2 May 2022 (UTC)
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." -- Vaulter15:49, 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)
@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)
According to the OED, "pres." is an abbreviation for "president" not present. The suggested usage is therefore not standard English.
The present is imprecise or indeterminate because it is constantly changing. It would be better to specify the time of writing, which is not the same as our articles are not updated in real-time.
The discussion above indicates that it lacks consensus
WP: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. Levivich19:25, 2 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)
@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. GiantSnowman13: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. Levivich14: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. GiantSnowman15: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. GiantSnowman15: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)
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)
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'. GiantSnowman11: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. GiantSnowman11: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?
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. GiantSnowman07:50, 7 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. GiantSnowman21: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)
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)
"Fix" Wikipedia Adventure by adding buttons to progress in "click on edit button" steps
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.
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)? — xaosfluxTalk14: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. — xaosfluxTalk18:33, 31 May 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.
Many websites are adding rainbow colors to their website. I think Wikipedia should as well. Not sure what a logo would look like, but worth discussing. Interstellarity (talk) 00:40, 8 June 2022 (UTC)
Yes, they don't ban the practice of celebratory logos, they strongly recommend against the practice of celebratory logos for holidays. 🐶 EpicPupper(he/him | talk)01:59, 8 June 2022 (UTC)
Oppose this well-intentioned idea, because every month is Think Of Us Month for some cause or other, many of them equally worthy. To be fair, we'd give each of them equal prominence – impossible in the year with only 12 months – and would never show our "normal" logo. It is better to feature related articles, pictures, etc. via the main page selections. Certes (talk) 11:32, 8 June 2022 (UTC)
Oppose I'm not in support of this as it isn't "about Wikipedia", and doesn't apply to all of our readers. While WMF is headquartered in the US, our readers are world-wide and this is a US-specific awareness event. — xaosfluxTalk12:47, 8 June 2022 (UTC)
Possible option - if there is a special editing drive for the locality (like a "Edit-a-thon for improving articles on United States LGBT Scientists") a geo-notice might do. — xaosfluxTalk12:51, 8 June 2022 (UTC)
I remember seeing a similar proposal recently for "official" recognition of another awareness/pride week/month, and think the same of this one. Interested people are welcome to have a drive to improve articles related to the subject at this time or any other time of year, but it should not come with any official imprimatur. Phil Bridger (talk) 18:55, 8 June 2022 (UTC)
Oppose. The only time it is appropriate for Wikipedia to collectively endorse any cause is when that cause pertains to our ability to build an encyclopedia (e.g. things about copyright or freedom of speech). As wonderful a cause as Pride is, it does not pass that bar. Editors can of course still show their individual support for Pride on their userpages and in their signatures. -- Tamzin[cetacean needed] (she/they)20:48, 8 June 2022 (UTC)
Yes, they can obviously show their support there, but such support is pretty empty unless they also work on improving related Wikipedia articles. Phil Bridger (talk) 21:40, 8 June 2022 (UTC)
Oppose As pointed out, a promotion of a US-centric cause that is unrelated to Wikipedia and would open us to endless promotion of various deserving causes. Meters (talk) 21:47, 8 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.
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)
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)
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)
Doesn't seem like this an issue, and is actually marginally helpful for readers with their interface languages set to anything other than English? — xaosfluxTalk10: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)
RfC: Bot to blank old IP talkpages
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.
Should a bot be used to blank old IP talkpages which:
Have not received any messages in the last 5 years
The IP is not under active blocks (including range blocks)
There have been no edits from the IP in the last 5 years
Pages that meet this criteria will be blanked and replaced with {{Blanked IP talk}}, which reads
Unregistered editors using this IP address received messages on this talk page years ago. Since users of the IP address have likely changed, these messages have been removed. They can be viewed in the page history.
There are millions of IP talkpages with vandalism warnings received since the earliest days of Wikipedia. Recent vandal warnings serve a useful purpose, but warnings from very long ago are detrimental as there is a high chance that the IP address would have shifted to different users. Stale warnings and other messages will confuse legitimate new editors editing from that IP seeing it apparently directed at them. Blanking the page and replacing it with {{Blanked IP talk}} template will avoid confusing legitimate editors, while still allowing access to potentially useful edit history.
Other benefits of this task will include uncluttering the Special:WhatLinksHere data for pages across all namespaces. Stale IP talkpages contains millions of links to articles, policy pages and their associated redirects, User pages, User talk pages, templates etc,. They will be cleaned up with this task.
This will involve the bot editing at least 1.5 million pages. If consensus is found for this proposal, I (or anyone else) can use a bot to implement it, subject to the normal WP:BAG approval from the Bot request for approval process.
Support, as proposer. I believe the criteria is a safe base for a bot to work from. We can discuss the bot's techincal implementation details, its handling of edge cases and see if any minor changes are necessary during the WP:BRFA process. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 08:37, 11 May 2022 (UTC)
Support. I understand some concerns raised in the discussion, and think that we can proceed cautiously by having such a bot begin by focusing on very old IP talk pages (e.g., the IP has neither edited nor been blocked for over 12 years, and the page has not been touched in that time), and once those are done, evaluate any surprises and move the limit up a year, and proceed that way until we get to the five year range. BD2412T05:54, 12 May 2022 (UTC)
Weak support I still have reservations over the matter, as I noted in the WP:VPIL discussion, but at least I have a sense that those reservations are also in the minds of the BotDevs and will be taken into account. --Jayron3218:08, 13 May 2022 (UTC)
One does not simply get to roll out IP masking. Major changes like that take a long time to happen. Many things about it is still not clear and WMF has yet to give a timeframe for implementation. Even after IP masking is rolled out at some point, stale IP talkpages will continue to pose a maintenance burden. A substantial portion of the existing millions of Lint errors is because of IP talkpages. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 19:19, 13 May 2022 (UTC)
Support. I see no reason as to why decade old IP talk pages shouldn't be templated out automatically, saving much time and manual effort, I sometimes find in RecentChanges. —CX Zoom[he/him](let's talk • {C•X})18:08, 14 May 2022 (UTC)
Support. There is indeed too much of a maintenance burden with these old IP talk pages. Blanking them / Blanking with template will reduce this while also making the what links here a bit more useful again. --Gonnym (talk) 20:18, 14 May 2022 (UTC)
Neutral I guess. Is this an actual problem, or a solution in search of a problem? I personally haven't experienced this as a problem for me. Maybe it's OK to see that there've been vandal warnings going back ten years, as this could indicate that it's like a static IP for a school, if being aware of that even matters... which probably not. I suppose it's more just clutter, and cleaning up clutter is OK too. Not important IMO, but perfectly OK to do if desired. Herostratus (talk) 22:29, 23 May 2022 (UTC)
Discussion (iptalk blanker bot)
I think I still prefer a subst'd type version of that simple template, so as to not add over a million instances of a template out there (which drags along another template, which drags along a module, etc). — xaosfluxTalk10:40, 10 May 2022 (UTC)
My preference for using a transcluded template is that if we have to change something due to future software changes (say the {{FULLPAGENAMEE}} magic word or some table markup), we can just update one page instead of having a bot go around changing substed uses. If the associated templates and modules are a concern, a compromise will be to hardcode {{Blanked IP talk}} to not use any other templates and modules. However note that every template and module used by {{Blanked IP talk}} is already used heavily enough to be under full protection. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 11:06, 10 May 2022 (UTC)
I have gone ahead and hardcoded most of the template, with no change in text. Previously it used 7 other templates and modules, now it uses only one. When reading this page from mobile, I realised the old template did not render in mobile due to it using tmboxtmbox-notice classes. Now it renders in mobile too. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 16:39, 15 May 2022 (UTC)
Question, what if the IP talk page hasn't received any actual warnings in 5 years, but their talk page got vandalized by another IP or a user before that 5 years happened, and no one noticed? Maybe the bot should look to see if there were any new warnings placed on the talk page in 5 years? ― Blaze WolfTalkBlaze Wolf#654514:13, 10 May 2022 (UTC)
The idea is to remove all stale messages from inactive IP talkpages, not just warnings. This is why {{Blanked IP talk}} uses the word "messages" instead of "warnings". If the page has received any edits within the last 5 years, the bot will ignore it. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 14:48, 10 May 2022 (UTC)
I use those templates regularly when I see lots of old warnings, and I think that it is a better solution han just blanking them out, but I also wonder if this whole idea will be moot if/when the WMF rolls out IP masking. Beeblebrox (talk) 21:10, 10 May 2022 (UTC)
Might it make more sense to wait for IP masking, give it a year or so, then delete every IP talk page? They're not going to be used any more. And even for users with the "unmask IP" right, the old unused IP talk pages will be less and less useful as months go on, given the dynamic nature of most IPs. Suffusion of Yellow (talk) 21:23, 10 May 2022 (UTC)
Deletion of things other than routine warnings risks deleting important information. Also, IP addresses aren't going away completely for a long while. Also, an old proposal thing maybe of interest: WP:OLDIP. -- zzuuzz(talk)21:35, 10 May 2022 (UTC)
Once masked identities are introduced, unregistered editors won't be looking at IP talk pages anymore but instead looking at their own talk pages. Thus the old IP talk pages won't have to be deleted to avoid confusion, and I think should be kept to preserve any discussions. isaacl (talk) 22:30, 10 May 2022 (UTC)
That goes to the second reason for templating these pages. The discussions contain links—millions of links. Links to articles, links to disambiguation pages, links to user pages and user talk pages, links to Wikipedia policy pages. Cleaning up incoming links across multiple namespaces for pages that tend to accumulate bad links is burdened by the clutter of links to decade-old messages from long-abandoned IP talk pages. BD2412T23:26, 10 May 2022 (UTC)
@BD2412 that sounds like an argument for clearing those pages - not really for why adding a million instances of a template is the best solution. — xaosfluxTalk23:32, 10 May 2022 (UTC)
An intentionally templated page is immediately distinct from a page blanked for reasons unknown. IP editors sometimes blank the warnings they receive; in my experience, they never template them. I do agree, by the way, that these can not be deleted, as the edit history may contain useful information. BD2412T23:35, 10 May 2022 (UTC)
I'm pretty sure we won't need to keep most of those messages. When it comes to schools, there's actually a high chance that the IP address will remain assigned to the same organisation. We frequently block schools for five years because they've shown that they can be that static. They can even get re-blocked without any new talk page messages. I can see a situation where a school comes fresh off one of these blocks to a freshly blanked talk page. I don't think that's necessarily a problem, but I also don't think it's fully recognised by this proposal. In an ideal world, we'd probably want to check when a block was made or expired. -- zzuuzz(talk)21:17, 10 May 2022 (UTC)
The proposal would exclude blocked pages from templating, but could be expanded to exclude pages that have come off a block within, say, the past three or four years. Ultimately, the vast bulk of pages we are dealing with are IPs that have actually never been blocked, but received a warning or a caution once or twice many years ago, and were never used again. That is pure clutter. I would certainly not be opposed to developing a protocol which starts with the most decrepit pages, and works up from there in a relatively slow and methodical fashion. BD2412T23:30, 10 May 2022 (UTC)
As BD2412 says (who have been doing this semi-automated for some time), the proposed criteria is enough for vast majority of IPs. I can set the bot to ignore pages having {{Schoolblock}} even when the IP is currently not blocked or check for block expiry date for pages having school block template. We can discuss these kind of cases and other technical implementation details when the BRFA is filed. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 02:53, 11 May 2022 (UTC)
It will not be going away shortly. Beta testing for IP masking has only just begun since last week. Other large scale WMF initiavites like Reply links took 1 year to go from beta testing to full roll out. IP masking is a much more drastic change and will surely take much longer for full implementation. As discussed above, there are other benefits from this task, namely uncluttering WhatLinksHere and reducing Lint errors backlog, that will relevant post IP masking. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 11:37, 2 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.
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?
Yes.
No, but the templates should not support them at all.
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)
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 there14: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. 0xDeadbeef07: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 there08: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. 0xDeadbeef08: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 there12: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 there02: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. — xaosfluxTalk15:42, 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 Pageuses 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.
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. 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. — xaosfluxTalk22: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. Levivich03:47, 6 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. — xaosfluxTalk01: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 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)
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)
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.
Lots and lots and lots of hidden text
Wikipedia has countless articles for which some text was added at some point, and then contested in some way not by being deleted, but by being hidden, often with a note (also hidden) explaining the reasoning for which the text was hidden (e.g., 'I don't think the source supports this' or 'this is off topic'). I find this to be a very bad practice, since this hidden text seems to be quickly forgotten about, and just stays on the page indefinitely. We also have metric tons of hidden links to deleted images, equally useless. I propose that we document all the pages that have blocks of text that were initially visible but were made hidden, and make a project of moving those from the articles to their talk pages for discussion. I think some of this can probably be done by a bot, but unfortunately only a small proportion, due to the potential for incorrectly moving appropriate uses of hidden text. However, it needs to be done, one way or another. BD2412T01: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 ~ LindsayHello08: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. BD2412T19: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)
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. BD2412T23: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. BD2412T01: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. BD2412T06:03, 6 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. BD2412T18: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. Levivich18: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. BD2412T19: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)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Should we make the homepage Wikipedia:Main Page rather than mainspace? It will be nice as minspace is for encyclopedic content only and the English Wiktionnary has already done so. Lynvir (talk) 09:47, 21 June 2022 (UTC)
Survey
Discussion
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
IAR Involved Close - no one wants this RfC. Those of us who think it was a bad idea are content to see if it actually takes off or if it dies. Those who thought it was a good idea don't want it marked historical yet and have an issue with the format of this RfC. The only thing everyone seems to agree on about this is that having an RfC about whether or not to mark it historical is something we don't need now. When all the interested parties agree this isn't a formal discussion worth having at this point; thats when you stop the discussion. I've already voted, so if anyone other than the IP who started this wants to revert me, go ahead, but my reading of the consensus is that there is nothing controversial about closing this now. TonyBallioni (talk) 19:52, 12 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.
Background (Administrative action review)
Wikipedia:Administrative action review (XRV) was created following Wikipedia:Requests for adminship/2021 review/Proposals#Passed: 6C Administrative action review. To start with, this board has nothing do with improving RFA, so many people who were not interested in RFA did not see the original proposal, as mentioned by User:Risker and User:TonyBallioni in the discussion section of the proposal. 6 months after creation and long discussions on the talk page later, the scope of this page is still unclear. It has hardly ever been used and still has "This is a newly created process and norms are still being established." on top. Many users have opined that XRV is a duplicate to WP:AN and its inactivity supports this notion. XRV has not received edits for the last 3 months except for test edits. There is nothing that XRV can do that cannot already be done at WP:AN with input from a wider audience. XRV is clearly a failed experiment and I propose that it be formally deprecated and marked as historical. There is already too much bureaucracy in wikipedia, pointing users to an unused and redundant process is unhelpful. 2409:4071:D9A:88D6:11AA:2ACF:EA4C:C433 (talk) 09:18, 11 June 2022 (UTC)
Support (Administrative action review)
Support I don't think XRV has done anything to support its founding as a solution to improve RFA's; it's birth from this RfC predicted that if it turns out to be useless it will naturally die, and it so it has. — xaosfluxTalk11:49, 11 June 2022 (UTC)
Put me here if this RfC continues — it failed because it is duplicative and the only reason to use it is to prove a point that it is needed. That being said, I agree with Kudpung below that the better outcome would just be to let it wither away in obscurity, so I don't really oppose a procedural closure of this RfC. Actually think a procedural closure might do more to speed up the death of it since there will be less fighting over whether to save it or not. TonyBallioni (talk) 19:04, 12 June 2022 (UTC)
Oppose (Administrative action review)
Oppose and malformed RFC The RFC is non-neutral. The "background" isn't background, it is arguments for a certain outcome. There is a good place for the process in Wikpedia. It needs to be tweaked. Less focused on "use of tools", more focused on actions (including/especially non-severe course corrections, and including mere mis-use of the imprimatur) of admins where fellow admins consider it impolite to intervene. North8000 (talk) 12:00, 11 June 2022 (UTC)
If you think there is a good place for a process like that on Wikipedia, then I suggest your time would be much better spent getting consensus for a new venue with that explicit purpose, rather than trying to mould this one into a vision that is completely at odds with what some others want to see the place become. Thryduulf (talk) 12:13, 11 June 2022 (UTC)
Procedural close send this proposal through idea lab so that people can jointly work on it, then bring it back. Major issues with the proposal atm. Curbon7 (talk) 15:33, 12 June 2022 (UTC)
@Curbon7 I'm curious what issues you see with this proposal that could be workshopped? Either the proposal is successful and Administrative action review is deprecated and marked as historical or the proposal is unsuccessful and it isn't. Thryduulf (talk) 16:21, 12 June 2022 (UTC)
(see also my extended comment in the discussion section) It's currently harmless in it's nominally experimental but practically completely inactive state. My preference is just to leave it like that until it completely fades into obscurity such that placing a historical tag is completely uncontroversial, but equally actively marking it deprecated now is not going to harm anyone or anything so I've got no reason to oppose that. Thryduulf (talk) 12:06, 11 June 2022 (UTC)
I see no useful purpose in doing anything about it at this point, so find myself in agreement with Thryduulf and Kudpung for now. However I am open to logical reasoning and rational persuasion based on evidence. Cheers, · · · Peter Southwood(talk): 07:30, 12 June 2022 (UTC)
Discussion (Administrative action review)
The "background" here is misleading and inaccurate and would be more appropriate as a comment. Yes, some people didn't think that XRV wasn't sufficiently related to RFA or too similar to AN. They're reasonable points, even if I disagree with them, but ultimately they had their say, along with those with other objections, and the RfC still found a comfortable consensus with something like 70 participants. After it was closed, we implemented the basic process proposed in the RfC and quickly started building momentum with some initial threads and a healthy set of discussions on how to refine the process. What happened then was that a small group of power users, unaccustomed to not getting their way, swooped down to try and delete the page, then when that failed, obstruct it by insisting we needed a second RfC confirming the first before it could be used, put tags on the page telling people not to use it, and most damagingly of all, remove all incoming links to it from other project pages. With that concerted attempt to smother the process before it got started, coming from the very people XRV was supposed to make more accountability to the community, it's not surprising that it became inactive shortly thereafter. So mark it as historical as a description of the current state of affairs if you like, but that doesn't change the fact that a) XRV had a strong consensus behind it which is now unrealised because of the objections of a small cohort and b) there remains a need for it, as seen by regular confusion about where the used of PERMs can be reviewed, and the continuing stream of ANI threads and ArbCom case requests about administrator misconduct that could have been resolved with early intervention at a less fraught venue. – Joe (talk) 10:47, 11 June 2022 (UTC)
...I linked to talk page sections which dozens of users participated in. Why have you only notified the most vocal opponents of XRV? Not exactly a wonderful start if you're genuinely after a balanced discussion. Of course, even if there's a consensus to mark it as historical, we'll have to have a second on how to mark it as historical. – Joe (talk) 11:34, 11 June 2022 (UTC)
(responding to ping) It was clear from the RfC that developing something called XRV to do something related to reviewing (some subset of) actions by administrators and/or administrative actions (most but not all administrative actions are taken by administrators, most actions by administrators are not administrative actions) had consensus from those participating, which is not the same thing as implementing a less-than-half-formed venue with no clear agreement, even among proponents, regarding its purpose, scope or processes. When it became clear to me that it wasn't going to be easy to get agreement on any of the prerequisites for a functioning venue I decided I had better things to do with my life and the lack of activity suggests most others feel similarly. I don't really see the need to do anything with it other than let it naturally fade even further into obscurity. Thryduulf (talk) 12:10, 11 June 2022 (UTC)
Joe Roe: Me? A power user? OMG! All I did was to state a few accurate facts here and here - simple generalisations about RfC proposals and noticeboard behaviour. That said, well, "coming from the very people XRV was supposed to make more accountability to the community", I'm not even an admin, so it wouldn't affect me. XRV is dead, and you, dear IP hopping user, would probably have done better by letting sleeping dogs lie. Kudpung กุดผึ้ง (talk) 12:24, 11 June 2022 (UTC)
Well I didn't actually mean you Kudpung. I thought your points were fair and fairly expressed. That's 2409:4071:* leaping to conclusions. – Joe (talk) 12:29, 11 June 2022 (UTC)
I have reverted an inappropriate closure by Levivich, who had cast a "Profanity-laced keep" for XRV. Clearly they are WP:INVOLVED here. To address comments about canvassing, the reason I pinged 7-8 users was because Joe Roe was specifically talking about them in the examples they gave (which included one direct diff). The RFC question of "Should Wikipedia:Administrative action review be depracted and marked as historical?" is neutral. In the background section I explained why I opened this RFC, obviously I wouldn't have opened it if I was opposed to shutting it down myself. I don't see what RFCBEFORE is required here, XRV is a completely inactive process, I only sought to make it a formality. And no I am not a "logged out OP", I am a long term IP user who never saw a reason to create an account. My ISP assigns very dynamic IPs, so my contributions are spread out over a broad range of IP addresses. 2409:4071:4D13:677B:E5E4:694E:766D:5EE0 (talk) 06:20, 12 June 2022 (UTC)
The basic problem with AAR is that after the community reached consensus to create it, it got back-door deprecated by way of quibbles about process and scope. We clearly should have more structure around this than currently exists, because when an administrative action is disputed on AN, the thread can be closed after a random interval by a self-selected person, and that means that the actions are reviewed by whoever gets there first. This creates an incentive to rush to comment if you want to be heard, which in my view is clearly suboptimal. We should have fixed-duration discussions and holding them in a separate venue will help to archive them. DRV reaches better decisions with less drama than the AN does, and having a well thought out process is the reason why.—S MarshallT/C12:12, 12 June 2022 (UTC)
back-door deprecated by way of quibbles about process and scope. is an, interesting, way of framing the discussions that were attempting to determine whether there was consensus for the sort of process you desire or the sort of processes favoured by others. There was very clearly consensus for something, but given that all these months later there is still no consensus about what exactly that something was is rather telling. Thryduulf (talk) 14:28, 12 June 2022 (UTC)
The consensus was: A new process, Administrative Action Review (XRV) designed to review if an editor's specific use of an advanced permission, including the admin tools, is consistent with policy in a process similar to that of deletion review and move review. Thanks to all the editors who contributed (and are continuing to contribute) to the discussion of how to implement this proposal. Wording taken directly from the RfC close.—S MarshallT/C15:41, 12 June 2022 (UTC)
IIRC there was a collapsed box in the proposal that had further details. The consensus was quite specific. Levivich16:12, 12 June 2022 (UTC)
Yet, after months of discussion among editors acting in good faith, there is still no agreement on multiple open questions. This is rapidly heading towards rehashing those discussions, so I'll leave it here as you can read as well as I can and, unless anybody has anything new to bring to the table, there is no point in another few thousand words of no consensus. Thryduulf (talk) 16:17, 12 June 2022 (UTC)
There were no "months of discussion". XRV was smothered in a matter of days and none of the discussion was constructive, only nonspecific objections to the process being "a mess" or "an embarrassment" or "not what the RfC said". We asked you and others repeatedly what those "multiple open questions" about the process were supposed to be, and never got an answer. It died because you (plural) insisted that the RfC consensus could not be implemented before some supposedly critical flaws were resolved, but you wouldn't tell us what those flaws were. – Joe (talk) 16:27, 12 June 2022 (UTC)
I would put it less strongly than Joe Roe, but I do think the community consensus was clearer than most of our policies, Thryduulf. There was some real disagreement by people who wanted it to be something it wasn't, but the main problem was tactical failure to understand plain English.—S MarshallT/C16:33, 12 June 2022 (UTC)
I wouldn't say failure to launch so much as it was shot down shortly after launch by people who opposed its launching. Joe summarized the details well above. Levivich18:33, 12 June 2022 (UTC)
It didn't help that one editor, who had very firm ideas how XRV should develop, made 25% of the talk page edits as well as 25% of the edits at XRV itself. They're now blocked for disruptive editing and checkuser-blocked, but many may have been too exhausted or frustrated by then. NebY (talk) 19:20, 12 June 2022 (UTC)
That's a good point. It wasn't just those opposed to the idea who killed it; overenthusiastic supporters were equally to blame. It may be that, with the initial fervor dying down, cooler heads can now prevail and we can get it re-launched. Levivich19:32, 12 June 2022 (UTC)
As I said before, mark it as an optional process and see if it helps solve problems (or if it tends to intensify them). Based on experiments we can then decide whether to make it permanent. JehochmanTalk19:34, 12 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.
Update for the fully professional league to notable leagues
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.
Discussion is also occurring at WP:Notability (sports) page. Discussion should be centralised to one forum, and therefore more appropriate for the linked page which has more specific interest in this topic, and also more commenters on the discussion. Note that a comment on this linked page is suggesting moving the discussion onward again to an alternative forum - this is beyond the scope of this page and this RfC closure. - Master Of Ninja (talk) 08:33, 14 June 2022 (UTC).(non-admin closure)
Hi. To clarify the sakes that can help enhance SIGCOV and GNG, I have proposed to update the following from the the title "fully professional leagues" to "notable leagues" in the area that the SIGCOV and GNG are to be respected, and to make the concerns addressed as to the list would be to inclusive in terms of notability.
I've made a new section so the responses are readable. A few questions: (1) Can I ask why the proposal was not put to WP:FOOTBALL first, as this seems to be within that board's area of interest? (2) I note that WP:FPL is an archived/"historical" page that you have derived this from. Is this something that has been deprecated by the Football WP sub-group? (3) There seem to WP:FOOTBALL notability criteria already. What does this new proposal add? I.e. is this really needed? (4) What are the notability criteria used here? Do you have a list? (5) Why add defunct leagues? (6) Why mention since x year?
(Continued) I do hate excessive guidelines as they prevent casual editors adding to knowledge. However if you wish to make a "notability list" then you need to ensure that you have criteria for it, as otherwise (eventually) either notability seems to get "captured" by a small group of editors, or alternatively descends into everyone thinking their hobby issue is notable enough to put on the list as there's no strict criteria. I hope these thoughts help in refining what you want to do. - Master Of Ninja (talk) 07:33, 13 June 2022 (UTC)
@Master Of Ninja I would note that they have zero need to put the proposal to a wikiproject first - in fact, I would generally say that would be a negative for a content project as doing so would inherently prohibit any notability policy that those interested in football disagree with. I make no comment on the other questions. Nosebagbear (talk) 09:09, 13 June 2022 (UTC)
Although note in future having a central discussion does not stop you from posting to other boards to tell others that a relevant discussion is occurring elsewhere - it just is better to have one page for discussion.
I would also suggest in your proposal on Wikipedia talk:Notability (sports) that you update it and write some more background including links to the previous related discussion, and a summary of the outcomes, as linked on my previous reply above. This allows users dropping by to work out what has been discussed before, and to catch up more easily on progress so far. Otherwise it relied on User:Kusma pointing out to this page that there had been previous discussions. - Master Of Ninja (talk) 08:19, 14 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.
Proposal to prohibit WikiProjects from ranking further articles as A-class
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.
Currently, only bureaucrats may create new pending changes reviewers. I propose that this power be transferred to administrators, since the right is relatively less important (unlike, say, the power to grant new admins). Thanks. NotReallySoroka (talk) 06:42, 19 June 2022 (UTC)
@NotReallySoroka: Er, I'm an admin with no superpowers - just the basic admin bundle plus autopatrolled. If I go to "User rights management" for any user (from a newly-registered account with zero edits, all the way up to Jimbo), I get the same two columns. The first, titled "Groups you cannot change" is greyed out - it has the following entries:
List of items
bot
administrator
interface administrator
bureaucrat
oversight
steward
importer
transwiki importer
founder
researcher
checkuser
copyright violation bot
push subscription manager
blocked from IPInfo
The second, titled "Groups you can change" allows me to toggle all of its checkboxes - it has the following entries:
Jimbo doesn't need the pending changes reviewer permission to be explicitly set, as it's one of the many rights that come automatically with adminship... — Amakuru (talk) 12:11, 19 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.
Add Armenian and Georgian languages to the other languages list on the bottom of English Wikipedia
Hi Wikipedia users and Admins!
I have a request which is to add Armenian and Georgian languages to the other languages list on the bottom of English Wikipedia since these two Wikipedia languages have more than 100K articles and should be finded quicker on the bottom of English Wikipedia in the other languages section.
Please note that is my desire to see these languages, the choice is of admins.
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.
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)
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.
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.
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)
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?"
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. — xaosfluxTalk21: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)
Agree with not forking and keeping discussion at NPP. This was intended to be a notification of that discussion. MB00:14, 30 June 2022 (UTC)
Enabling the New Topic Tool by default
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. 0xDeadbeef01:35, 21 June 2022 (UTC)
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 usIn 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}}talk21: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)
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 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)
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 Rextalk21:43, 28 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 Rextalk18:56, 30 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.
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.
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.
@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 Wellertalk17:42, 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) — xaosfluxTalk18:35, 23 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).
@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. — xaosfluxTalk14:02, 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 Rextalk14:59, 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)
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)
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)
Reverting the old version of the Philippine name template
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)
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)
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)
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)
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}}talk19:38, 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)
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)
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)
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.
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)
A single letter with a period should always be disambiguated
Most instances of a letter of the English alphabet followed by a period point to a disambiguation page for that letter (see A., B., C., D., E., F., G., H., I., K., N., O., P., Q., S., T., U., W., X., Z.).
There are, however, precisely six letters for which the letter-with-period is either a redirect to another article on a specific topic (i.e., a magazine, book, album, or person), or the title of an actual article, and would ask that editors try to guess what the article in question will be before hovering/clicking the link. I would imagine that in most cases 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.
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)
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.
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)
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)
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)
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 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)
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)
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. — xaosfluxTalk23: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. — xaosfluxTalk23: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. — xaosfluxTalk10:16, 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!). — xaosfluxTalk14:54, 30 June 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)
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.
There are only 1,034 administrators on the English Wikipedia. If there is a valid reason to protect a page, an average Wikipedian would request protection of it before an administrator would. FAdesdae378 (talk·contribs) 20:38, 28 June 2022 (UTC)
Seems a bit arrogant to say that admins only act on requests from us mortals. The ones I see working around the project are pretty damm sharp. I note you didn't answer SFR's "specific issue" point?? - Roxy the bad tempereddog20:59, 28 June 2022 (UTC)
Oppose This would delay protection in cases where it is needed. I've made several requests at WP:RPP/I that have taken a while to be reviewed, if an admin noticed a page with a need for protection during that time they would need to request the protection and presumably wouldn't be allowed to act on it themselves, this would significantly delay the time it takes to protect the page. People who unnecessarily protect pages often should be dealt with individually. PHANTOMTECH (talk) 20:29, 28 June 2022 (UTC)
If you want to be taken seriously then present evidence that this does not happen already. I note that you seem to be backtracking a bit from your initial proposal. Phil Bridger (talk) 21:20, 28 June 2022 (UTC)
No. This is not a bureaucracy. Admins have (unless they have had that status since the early years of Wikipedia) been through a demanding selection process that demonstrates that they are trusted by the community to make such decisions. If one of them betrays that trust then we need to deal with that one admin, not create rules that get in the way of all thousand of them doing their job. Phil Bridger (talk) 21:20, 28 June 2022 (UTC)
No — it's fine if an admin notices a problem and steps in to solve it without a notice being posted on some acronym board first, or if a non-admin sees a problem and makes a direct request of an admin who is currently active. Mandating that every request be funneled through the same page would just mean a bigger backlog and a worse editing experience all around. XOR'easter (talk) 00:31, 30 June 2022 (UTC)
No I have watchlisted a lot of articles that are targets of vandalism. When they're hit, I just protect them. Why would I need to wait for an RFPP request rather than take the action myself? – Muboshgu (talk) 00:38, 30 June 2022 (UTC)
I agree with the others that this won't be workable. However, unwarranted protections do happen quite often. It's not a case of someone blatantly misusing the tools, so it's not a matter for the noticeboards, and, at least in my experience, it can't normally be resolved by a one-on-one discussion with the admin. I think we need to begin with updating the protection policy (a lot of it reflects the practices from before ECP existed), then make sure a neat summary is publicised though the admin newsletter so that all admins are aware of the newly codified community expectations. After that, we could start sampling the newly applied protections and let those admins know who fall short of those expectations (it's more difficult to ignore that sort of feedback when there's a clear policy passage to point to). Oh, and there's also the huge legacy of indefinite protections from the early days, many of which will need revising. – Uanfala (talk) 10:19, 30 June 2022 (UTC)
Again, any specific cases that you think certain page protections made were unwarranted? Was there conversation with the admin involved? – robertsky (talk) 11:13, 30 June 2022 (UTC)
I'm not making broad proposals to address an individual incident. Probably worth pointing out that even though potentially unwarranted protections may represent a relatively tiny fraction of all protections applied, their absolute number is still quite big. – Uanfala (talk) 14:15, 30 June 2022 (UTC)
Of course unwarranted protections happen. Everybody makes mistakes. I'm not concerned about that part of your statement, but about the bit where you say, "it can't normally be resolved by a one-on-one discussion with the admin." Without any evidence that looks very much like casting aspersions against our whole admin corps. If pages that shouldn't are being protected and this isn't being discussed properly then it's very much a matter for the noticeboards. Phil Bridger (talk) 14:48, 30 June 2022 (UTC)
even though potentially unwarranted protections may represent a relatively tiny fraction of all protections applied, their absolute number is still quite big any statistics or analysis on this? if yes, were the majority of unwarranted protections done by a few admins, or just a few by each admin but summed up to be a lot, or a lot by each admin? Depending on the stats and analysis, the solution you proposed may end up being a sledgehammer hammer on a nail.
I have seen unwarranted protections discussions coming up at ANI, but those are mostly either done by relatively inactive admins who chose to suddenly used their rights, or admins who were pointed out or engaged later by other editors to be perceived as unwarranted and later either backed by other editors/admins or had the protections reverted. For inactive admins, the criteria to strip their rights had been tightened recently (Wikipedia:Inactive administrators), and we should see lesser of such issues from them (though it is already rare). – robertsky (talk) 17:17, 30 June 2022 (UTC)
No I hear you.....I've seen many bad or questionable page protections, but your idea would be unworkable. Getting a process in place to review questionable ones (such as Wikipedia:Administrative action review) in place would be a better move. North8000 (talk) 13:19, 3 July 2022 (UTC)
Oppose If an admin is making poor decisions, a knee-jerk layer of beuracracy that affects all admins is not an appriate means of correcting the problem. Take it up with the admin in question, use existing processes if that doesn't yield a good result. --Beeblebrox (talk) 17:31, 7 July 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.
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)
I would like to propose that new articles be created to encapsulate lots of different bus routes.
Background (bus route articles)
On this very wiki, there are a series of articles concerning the various bus routes in London. These articles contain many details about the history of the routes and the vehicles that are used on it. I notice that there is not a lot of this for other Cities and Local Authority areas. This, I want to change, but it require a lot of work and dedication.
My Proposal (bus route articles)
I would therefore like to propose that an assemblage of articles be crated to discuss the bus routes of other major metropolises such as Glasgow and Dublin. I also do hereby request and require that such due process be observed in order to establish a network of pages covering the routes of more rural provinces, such as Ayrshire and the Lake District. I trust that such can be achieve in a timely and competent manner, and so I must propose such action to be conducted henceforth in order to improve the very fabric of this dear wiki.
Considerations (bus route articles)
Before I close, I will lay down a few important points to consider:
I notice that there would some issues with establishing notability with some rather more obscure bus routes, but I trust that we can set criteria for that, and I believe that any bus route operating on a 30min frequency or more frequent than that should be fine.
Yes, this is a massive project. If we want to cover the routes of all 200 odd countries, then we will be here for a long while. Perhaps we will build out from London first, and work on English routes. Scottish and Welsh would follow, then Northern Ireland and Ireland, and then onto the rest of Europe. If things are going well after this, then work on other continents should proceed in this order: North America, Asia, Africa, South America, Oceania. If at any point, notability is in doubt, then dial back a bit and focus mostly on large cities for a while.
Remember, we are trying to eliminate London favouritism here, but we must not go to far and blatantly insult the capital of England. Care must be taken to look after those articles as well, and said articles should be used as a template for new pages.
Conclusion (bus route articles)
I hope this proposal is not too long, both literally and metaphorically. I hope these writings aren’t too long either. I expect good points from both those who support and those who oppose this idea. If there is too much opposition, then it would be good to talk about scaled down versions of this project. Should the need arise, I will create such a thing and post it on this page. Ideas to improve this project are encouraged and will be most useful here.
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}}talk21: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. — xaosfluxTalk23:04, 11 July 2022 (UTC)
Looks like they get deleted and redirected to lists a lot --- then after some time someone just recreates them again! — xaosfluxTalk00:40, 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 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)
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)
Concerns about Making Vector (2022) the Default Skin in light of jawiki's Precedent
The Foundation has changed jawiki's default skin to Vector (2022).
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.
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)
Discussion on renaming Citation Style 1 template parameter url-status
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.
To clarify, not all mobile editors cannot see edit notices. Android users on the Wikipedia app see editnotices; this script is for mobile users on the mobile site (en.m.wikipedia.org). iOS app users do not see editnotices, and the script will not change this. WMF says the feature "is on the roadmap". — PerfectSoundWhatever (t; c) 18:36, 10 July 2022 (UTC)
Survey (showing editnotices on mobile)
Support as proposer. Having used it on several mobile devices, I've realised that it might be a good solution to the above mentioned problem. —CX Zoom[he/him](let's talk • {C•X})09:54, 4 July 2022 (UTC)
Support as script author. On a technical note, registering the script as a default Minerva-only gadget is a little more efficient than using Minerva.js. I've written instructions on how to register the script as a gadget. But that's just details. — Alexis Jazz (talk or ping me) 18:37, 4 July 2022 (UTC)
Support. Of course, but I will note this is conditioned on the script be extensively tested before the edit installing it goes live. –MJL‐Talk‐☖05:48, 5 July 2022 (UTC)
Support if we limit to extendedconfirmed and higher user rights for 6 months. That might motivate people to improve the quality of these notices before dumping them on other ppl. —TheDJ (talk • contribs) 08:27, 5 July 2022 (UTC)
Comment Hi - I’m the Product Manager for the Moderator Tools team at the Wikimedia Foundation and I wanted to leave a quick note that we’ve got Editnotices on our list as a potential priority to work on this year as part of our improvements to mobile web (we're working on accessing admin features, preferences, and probably Diff/Undo first). When we come to this I'd like to investigate how impactful editnotices are for newer users, since I don't think we've got much prior research on the topic (do they impact edit completion rates? do they have the intended effect of preventing or encouraging certain types of edits?). Anyway, don't let our plans stop you from moving ahead with this in the meantime. Samwalton9 (WMF) (talk) 11:19, 5 July 2022 (UTC)
It seems that the WMF is working at a glacial pace here. In the Wikipedia of 2001, which had far fewer resources, would such decisions have had to be made regarding the prioritisation of implementation of required desktop features? Of course not - it would just have been done. The aim should be that by the end of this year everything that is available on the desktop should be available on mobile (unless any particular feature is shown to be impossible to implement), and even that is far too late. Commercial organisations reached that stage many years ago. Phil Bridger (talk) 18:18, 5 July 2022 (UTC)
FWIW a big contributory factor of the seemingly slow pace Wikimedia works at is because of the technical complexity site specific gadgets like this add (this in addition to the fact most top ten sites with a tiny amount of staff compared to other top ten sites). The mobile and desktop site is maintained by 6 people fulltime which is ridiculous but an understandable constraint. Jdlrobson (talk) 20:28, 6 July 2022 (UTC)
I wouldn't say that it's understandable that an organisation that raises so many millions of dollars each year should have so few technical staff. Get rid of the armies of unskilled "outreach" workers and employ a few useful highly-skilled highly-paid technical staff to fix these problems that plague us and make Wikipedia a laughing stock. Phil Bridger (talk) 21:15, 6 July 2022 (UTC)
The problem is not that the WMF has a tiny amount of staff, but that the vast majority are sent off on tangents pursuing other agendas, leaving a tiny amount of overworked technical staff. Certes (talk) 21:36, 6 July 2022 (UTC)
Jdlrobson, SIX? I never looked up the whole technical team, frankly because I don't know where I should look for the full picture, but I've been curious about the size of the actual technical team. (so not counting managers, PR, etc) I'm terrified to ask, but how many managers etc. do you have? This actually explains why I rarely see any technical staff replying to anything.. I guessed you were understaffed, but six? Didn't you mean 66 maybe? It must have been a typo. Can't be six. And I agree with the above: the WMF raises millions in donations. You are not, NOT telling me they can't afford a dozen fulltime people to maintain this site and/or a few dozen IT students or the like for some grunt work. And just imagine: when three people get the flu, this site would be kept running by three people. Maybe you get a temp in that case, but that person would probably not be as productive. That is simply insane and irresponsible. — Alexis Jazz (talk or ping me) 01:19, 7 July 2022 (UTC)
Just for some figures ... The WMF had a surplus of over $50 million last financial year, and was heading for another healthy surplus in the year just ended. In addition to those surpluses, it accumulates around $20 million a year in its endowment. It claims that 42% of its money is spent on "Direct support to websites" and 31% on "Direct support to communities" ... given total expenses of $112 million, that is an $80-million dollar budget for those two rubrics. Total expenses are now over ten times what the Foundation spent in 2010. The Foundation spent half a billion dollars over the past five years ... more than it spent in the fourteen years prior, from 2003 to 2017. AndreasJN46616:39, 7 July 2022 (UTC)
Apparently Wikipedia gets some 5 billion views a month. A team of 6 doing all that technical maintenance work is simply understaffed. Every month I find that mobile site has gotten a few more features. I appreciate the progress. But we're currently so far behind on mobile site functionality that it would take us several more years if we continue at this pace. If the WMF needs more developers, they should hire them. It does receive a good amount of donation which it should use judiciously. —CX Zoom[he/him](let's talk • {C•X})06:49, 7 July 2022 (UTC)
I suspect that Jon meant "the mobile site", which is what you would call "the Minerva skin", aka the mw:Reading/Web team.
If your idea of "the site" means "keeping Wikipedia on the internet", then that's the Technology department (e.g., the mw:Ops team), and they have more than 150 regular staff, not counting various contractors and vendors. The Product department (of which both Jon and I are a part) also has more than 150 staff (plus probably more temporary contractors but fewer vendors). Whatamidoing (WMF) (talk) 17:28, 7 July 2022 (UTC)
@Whatamidoing (WMF) - while similar for sure, I think most of the problems in this thread aren't really about "Minerva" directly - but about "Mobile Front End", and its limitations. Everything MFE certainly has a huge impact on readers, who are increasingly visiting from mobile devices to read content. — xaosfluxTalk13:34, 14 July 2022 (UTC)
@Samwalton9 (WMF) I'm wondering how admin tools and looking at diffs (things that affect 1000 people and editors respectively) take priority over showing notices to IPs (you know, the supermajority of users?). Nope this is why I don't comment when I'm tired let me modify: over showing content to mobile users (the ever growing sector of people that outnumber both admins and editors (as well as including some many?)) Happy Editing--IAmChaos02:16, 6 July 2022 (UTC) modified 02:19, 6 July 2022 (UTC)
@IAmChaos: Great question, I agree it doesn't seem intuitive! First I want to invite you to share your thoughts on our team's priorities at Moderator Tools/Content moderation on mobile web - our work is directly guided by what folks are telling us is important. In terms of how we got to the current priorities, admin tools (the Overflow menu) actually came up first for us specifically because it impacted a smaller number of users. Our team was previously working on The Wikipedia Library, so we didn't have much experience working in MediaWiki. As such, we started with a smaller scope project, which impacted fewer users, as our first foray into mobile web partly so that we wouldn't impact too many users if we, for example, introduced bugs. We then decided to prioritise Preferences because at the moment mobile users have no obvious way whatsoever to access critical user account features like changing their password, updating their email address, and adjusting notifications. We think this is a huge oversight for all mobile editors and we made the judgement call to fix it before other priorities. We are now prioritising Special:Diff and adding an Undo button there because it's what we were hearing about most from the editors we spoke to - outside of English Wikipedia editnotices honestly just didn't come up as often, if at all, but lots of mobile-first editors were frustrated they couldn't undo edits from diffs. In my view there's a lot to improve in the mobile web editing experience, especially in terms of features for active editors, patrollers, and admins, so please do head over to our project page and let us know what you think the priorities are. Samwalton9 (WMF) (talk) 08:55, 8 July 2022 (UTC)
I think more research on how edit notices or other alternatives can be made more effective across users of all types of devices would be great. I hope, though, this would happen in parallel with some interim solution that would allow today's version of edit notices to be visible across all devices. (If this means the community needs to go on a drive to slim down edit notices, possibly selectively for different browser sizes, with guidance from the constraints of the interim solution, so be it.) isaacl (talk) 02:34, 6 July 2022 (UTC)
[removed comment, I don't see the insult but whatever, not interested in dealing with replies that can't be bothered to use punctuation] — Alexis Jazz (talk or ping me) 09:28, 6 July 2022 (UTC)
Support - No one should be editing if they are unable to receive notices about their edits. To User:Samwalton9 (WMF) - This should be the FIRST thing to be straightened out. --User:Khajidha (talk) (contributions) 12:16, 5 July 2022 (UTC)
Support, or as a stopgap measure, people editing from mobile should be blocked from editing any page with an active editnotice. —Kusma (talk) 18:44, 5 July 2022 (UTC)
Support Some kind of fix for this problem is long overdue, and even a stopgap measure is better than the status quo. XOR'easter (talk) 20:29, 5 July 2022 (UTC)
Support - subject to you the whole security thing of not hosting it in Alexis Jazz's userspace and making sure it's tested or whatever the techy people need to be certain its safe to run on all accounts. Happy Editing--IAmChaos02:21, 6 July 2022 (UTC)
That's a shame, wish the app had more customizability. Just tested on en.m.wikipedia, works as intended, so will Support this proposal. — PerfectSoundWhatever (t; c) 17:38, 6 July 2022 (UTC)
@PerfectSoundWhatever I'm afraid apps do not currently support gadgets and userscripts. However, we do in fact show editnotices in the Android app, in our native wikitext editor. In the iOS app this is not yet available, but is on the roadmap. There's also a page where you can follow our overall progress on improving on-wiki communication. DBrant (WMF) (talk) 17:27, 8 July 2022 (UTC)
That's pretty cool, thanks for letting me know! Don't edit on android enough to have seen that yet, but I tested it and it definitely works. A shame it strips the images down from the editnotice to just text, but it's definitely better than nothing. — PerfectSoundWhatever (t; c) 18:30, 10 July 2022 (UTC)
Conditional strong support. Mobile editors need to see editnotices. Anything about engagement comes second to them missing ArbCom/BLP/etc. warnings, which are essential to the function of the encyclopedia, e.g., we should not block people for WP:1RR without a warning that the page is under 1RR. As IAmChaos said above, this should only go ahead if smart people(including the editing team) are sure this script is ready for general deployment and that the script is moved out of Alexis Jazz's userspace. Otherwise, this needs to be implemented yesterday. HouseBlastertalk17:17, 6 July 2022 (UTC)edited 18:41, 10 July 2022 (UTC)
Support. Absolutely need to fix this now that we have a workable solution. The extremely non-committal language from the WMF technodude (on our list as a potential priority to work on this year) admits that this is not yet a WMF priority. The open-source fix-it attitude among Wikipedians is what makes Wikipedia work; applying it to technical challenges that the community has faced is something that should be supported and applauded. — Ⓜ️hawk10 (talk) 21:01, 6 July 2022 (UTC)
Support: long overdue, essential feature, and there's little point in editnotices without it (most newbies/readers use mobile). This RfC is like asking if readers on mobile should also be able to see images and text. Of course they should. Our rules and procedures around editnotices presume that they are readable by editors, not desktop editors only. Thanks to Alexis Jazz for the hard work in patching over this large, sustained WMF failure. — Bilorv (talk) 14:18, 7 July 2022 (UTC)
Support WMF should feel ashamed that we have to resort to a solution like this to fix bugs. ThePlatypusofDoom(talk)
Support. Sadly, the WMF is far from the only tech company that tends to be in far too much of a rush to get apps out quickly, rather than getting out apps that actually work. This has gone on far too long, if they are unwilling or unable to fix it, the community will have to do what it can instead. --Beeblebrox (talk) 17:28, 7 July 2022 (UTC)
@Beeblebrox: Actually, this hack works solely on mobile site, the en.m.wikipedia site. Mobile app doesn't support *any* javascript, so it can't work there. Though mobile app editor numbers are apparently very small compared to mobile web and desktop editors. I don't have hard data, but app download numbers and lack of "Android app edit" & "iOS app edit" tags in RecentChanges indicates so. The idea is to provide standard editing experience to as many people as possible, although some would still be left out, unless we find another hack or the WMF decides to act. —CX Zoom[he/him](let's talk • {C•X})17:45, 7 July 2022 (UTC)
You are correct, I'm afraid apps do not currently support gadgets and userscripts. However, we do in fact show editnotices in the Android app, in our native wikitext editor. In the iOS app this is not yet available, but is on the roadmap. There's also a page where you can follow our overall progress on improving on-wiki communication. DBrant (WMF) (talk) 17:34, 8 July 2022 (UTC)
Support: It is essential that equivalent information regarding crucial issues such as Editnotices should be presented to editors using whatever approved front-end. As others have said, deployment requires prior testing. AllyD (talk) 07:05, 8 July 2022 (UTC)
Should the process of deeming any new topic as sanctionable involve explicit consideration of which editing communities will or won't be made aware of the issue? This would be akin to various jurisdictions' requirements to document equality considerations in any new regulation. While it would be largely replicating a row from Wikipedia:Mobile communication bugs, it could concentrate minds, especially when, for example, it is identifiable that most editors in the area of interest use a front-end which lacks Editnotices. AllyD (talk) 07:13, 8 July 2022 (UTC)
Support It's really disappointing that this critical bug still hasn't been fixed. In the meantime, this is worth doing even though it still won't deal with all the mobile issues. MichaelMaggs (talk) 09:30, 8 July 2022 (UTC)
No way, let's not do it, makes too much sense.Support, particularly in light of Jdlrobso's revelation above that there are only six people on WMF's tech team, which drives home the fact that if we want anything done around here technically, we'll have to do it ourselves. WMF staffs 300 people on their Tech and Product departments, as stated below by Samwalton9. That said, there clearly seems to be a backlog that is preventing critical issues like this from being addressed, and so I think this is a good next step to take in resolving this in the interim. --🌈WaltCip-(talk)12:32, 8 July 2022 (UTC)
@WaltCip: I just want to clarify that, per Whatamidoing above, there are substantially more than six people who work in tech and product at WMF. Jdlrobson was referring to the Web team specifically. In total there's something like 300 staff between the Tech and Product departments at WMF. Samwalton9 (WMF) (talk) 12:46, 8 July 2022 (UTC)
Comment Hi y'all – as the Product Manager for the team that is responsible for the editing interfaces any implementation of mobile edit notices would appear within, it felt important to me that you all know/consider:
The Editing Team, in collaboration with @Samwalton9 (WMF) and the Moderator Tools team, is actively working on a proposal for what we think could be the fastest, safest, and most effective path for making edit notices available to people editing on mobile.T312587Note: we're thinking of something we could implement on the order of weeks NOT months.
Before Wednesday, 27 July is over, you can expect for me to share a proposal for what the Editing Team can do to make edit notices available to people editing on mobile that we think would be safe/reliable, quick to implement (on the order of weeks), and effective. Note: you can see the potential approaches we've started exploring in T312587.
Before this Friday is over in California (UTC-7), I think you will have two things from us:
1. A summary of the technical and user experience investigation, and resulting discussion, that's happening in Phabricatorand
2. A link to a prototype for a potential longer-term solution for implementing edit notice on mobile that the Editing Engineering team has built, with inspiration from the gadget AlexisJazz has written. PPelberg (WMF) (talk) 04:19, 14 July 2022 (UTC)
Support. Not too keen on waiting three weeks just for a proposal. It seems like volunteers can get this up and running much faster. If paid WMF staff can later replace it with a non-hack solution, great. Until then, this works. Levivich[block]17:53, 8 July 2022 (UTC)
Support. I haven't tested this or reviewed it for security, but enough people with a clue have done the job for us. If we expected an "official" solution in three weeks then this would be hasty, but as what we expect is a proposal then let's fix it ourselves. Certes (talk) 22:40, 9 July 2022 (UTC)
The fact that you need to gather consensus and go through all of the bureaucracy for this is dumb (including those from PPelberg). It is an obvious improvement compared to the current situation, so why not give it a try? CactiStaccingCrane (talk) 08:37, 13 July 2022 (UTC)
It's the general approach the community takes: it allows for everyone to provide their perspectives and possibly consider improvements and alternatives (and improvements have been made to the implementation as a result of this discussion). I don't believe there is sufficient urgency to skip the discussion process, particularly since it seems to be coming to a clear conclusion. isaacl (talk) 15:55, 13 July 2022 (UTC)
Support. Editnotices are an important feature for editors on all devices and if the WMF is moving too slowly then let's take matters into our own hands. —pythoncoder (talk | contribs) 03:36, 11 July 2022 (UTC)
Support. Editnotices help to inform editors of those articles about what restrictions or special considerations apply, and should be visible to every editor on that page. The cunctating from the WMF is just going to do more harm than good here; this is a long-standing issue that needs an answer a week ago. —Jéské Courianov^_^va little blue Bori19:18, 12 July 2022 (UTC)
Following up on some comments above. Fixing in core is a significantly better solution than some sort of client-side script. We certainly would never load this as a user-script from User:* namespace if we do go this way, it would indeed need to be moved. That script also seems to incorporate other functions, that we would need to consider if they should be kept or need further rewrites for security (i.e. not importing lua functions from template space in to something that is otherwise protected to interface admins). Actual gadgetization would also be preferable. But let's leave out more technical details from VPR right now and make this clearer for general community members that are commenting. A better summary may be:
Should the English Wikipedia put in a hack to show edit notices to mobile editors until this function is available in the software?
One important factor to consider is: it this really needed for all editors on mobile, or just logged in users? Do we really think that the average mobile IP editor is going to care what some "arbcom" says or what a "1RR" is (keeping in mind that this is really only for unprotected pages as well)? Potential negatives of this should also be considered: such as is making every single page load a bit slower, use more bandwidth, and have increased client-CPU utilization -- is that worth it here (again especially for IP readers who would have to execute this on every page load). — xaosfluxTalk19:10, 6 July 2022 (UTC)
Could there be other fixes for this? For example, this proposal is a hack to the minerva skin - well the edit page already has the edit notices available, see an example page here - they are just behind the "Page issues" link at the top of the page. Would being able to improve that label be a better fix? Like instead of it says "Page issues" - what if it said "This page has special rules and notes that you should review before editing" or something like that? Ping to the proposer for thought on that: @CX Zoom:. — xaosfluxTalk19:32, 6 July 2022 (UTC)
Note: looks like "mobile front end" pages are not getting this, so there may still need to be multiple technical implementations depending on how the "mobile user" is trying to access the page. — xaosfluxTalk19:40, 6 July 2022 (UTC)
The edit interface found by appending useskin=minerva to the URL is markedly different from the mobile editing interface, which doesn't show "page issues" at all. I don't know much about technical complexity this script will add, all I know is that it works just as anyone would expect it to. It is a huge problem that it can't support mobile app. The idea is to provide standard experience to as many editors as possible. Also, I don't have concrete data but I think "mobile app" editors make a very small portion of our editors, based on app download numbers. Mobile app edit gets its own edit tag, so number of hits that tag has should give us a proper idea. If the phab ticket is fixed, that's great, but at the moment it still doesn't seem to be at WMF priority list just yet, per Mhawk's interpretation of Samwalton9 (WMF)'s comment. Samwalton9 has also stated don't let our plans stop you from moving ahead with this in the meantime. In fact, I'd say if a certain issue can be solved by the community, the (understaffed) developers would be able to devote time and effort to objectives the community cannot solve by itself. —CX Zoom[he/him](let's talk • {C•X})08:23, 7 July 2022 (UTC)
I agree 100% that the script, if deployed, should be registered as a default gadget, it should definitely NOT be loaded from my userspace. There is currently a gadget (not mine) that does that (WP:LOCO) and I agree that's not advisable. Instructions are now available here. It's ResourceLoader compatible.
Using ResourceLoader to load it minimizes the script and clients can cache it. When it's not yet cached, the script is a <3K gzipped download. For comparison, loading this very discussion page causes DiscussionTools to download a >6K (when gzipped) JSON that is 100% unnecessary and not cacheable in any meaningful way. In addition to that there is what is typically more than twice that (still counting gzipped) in HTML crap, which is also 100% unnecessary and guaranteed to be uncacheable. I investigated these things because I wrote my own script to reply which requires neither. And if you actually write a reply with DiscussionTools, it forces a live preview that'll generate many requests. My script doesn't force a live preview upon the user, and when it is enabled anyway it does the job using a fraction of the requests while being more responsive. But I won't hold that last bit against the WMF: the way my script handles live preview I can't recall having ever seen anywhere else, so I won't blame the WMF for not having invented that. But force-enabling live preview in DiscussionTools was a conscious decision, and one that sends a clear message: nobody cares about bandwidth and nobody cares about the servers using what must be considerable CPU power to parse those live previews, or the energy used by client network adapters for this stream of data. The WMF and users are okay with DiscussionTools as the former has awarded themselves a series of barn stars and the latter generally lauds DT. So no, they won't even notice a <3K gzipped cacheable script.
i.e. not importing lua functions from template space in to something that is otherwise protected to interface adminsEditNoticesOnMobile uses Module:String which is fully protected. I am not doing that for fun. The parser completely removes elements we need on the mobile site. This was the only way (or at least, the most efficient way) I could think of to get in before the parser sinks its claws into the wikitext. EditNoticesOnMobile no longer uses Module:String. See phab:T308401.
You are correct, on desktop Minerva edit notices exist in the HTML. Hardly anybody uses desktop Minerva. Notifications don't even work on desktop Minerva and nobody cares. EditNoticesOnMobile deals with both desktop and mobile Minerva though. On desktop Minerva it simply unhides the notice. On the mobile domain this isn't available so a request for the edit notice is made, but only when the "edit" button is pressed. Not on page load.
Client CPU usage when loading a notice isn't that much. It has to render the HTML, but it would have to do that anyway regardless of implementation. Sure, an implementation in MediaWiki core could be somewhat more efficient, but I say it again: DiscussionTools. Nobody cares about efficiency. On page load (before loading a notice), EditNoticesOnMobile does hardly anything.
@Alexis Jazz Thank you for the updates! I think some of us care about efficiency at least a little bit. I think the comparisons to DisucssionTools is a bit of a red herring, DT isn't loading on every page view of every article, (and the script would be loading on every load - it just wouldn't also be doing even more loading until after clicking edit) the most common pages for logged out mobile users to come across and maybe, if we are lucky, to click edit and add something nice to. I do agree that we have an overall problem - we make edit notices for the benefit of editors, and editors aren't getting them - that is quite undesirable. So part of my hesitation is that because this is important, relying on client-side script processing feels wrong. Would like to get some feedback from some more of the mobile-dev's though, a "don't worry about it" would be nice from them. — xaosfluxTalk01:35, 7 July 2022 (UTC)
Xaosflux, it's true that DT isn't loaded on every page, but even so, it's a story about efficiency. EditNoticesOnMobile could be made smaller than it already is: uncouple the addEventListener into its own file and only load the rest of the script when the edit button is pressed. The notice can take slightly longer (pretty much your ping time to Wikimedia if the script has to be requested) to appear in this case. But the savings might be smaller than you think. It depends on how ResourceLoader will handle this exactly on enwiki, which will also vary from user to user. A request for a 100 byte JS (if no other scripts are downloaded in the same request) ends up producing >1K traffic due to overhead anyway. And since the script is cacheable I doubt uncoupling is really worth it. The script could be minified somewhat more, I tried putting it through my own AJSJSMangler resulting in User:Alexis Jazz/EditNoticesOnMobile.min.js which is a little shorter but the gzipped difference is next to nothing. Some classnames etc could be shortened, but is it really worth it? And if you think DT is a red herring, you might be interested in ULS instead. phab:T308557 was resolved by adding ext.uls.common as a dependency, which (I'd think) means that it'll be loaded on page load, but nobody got back to me on that so I don't know for sure. Btw, Matma Rex informed me of a special API feature on phab:T308401 so EditNoticesOnMobile no longer needs Module:String. — Alexis Jazz (talk or ping me) 03:59, 7 July 2022 (UTC)
Xaosflux, okay.. now. I just added localStorage caching: notices are cached for 12 hours. (the actual duration could be adjusted if deemed necessary) If a particular notice is dismissed, it won't show for 12 hours. When I checked, for just a moment, I thought the gzipped size had grown to 5K, but I was wrong. I was looking at the wrong entry: Commons' favicon.ico is 5K gzipped, including network overhead. I often test on betacommons, EditNoticesOnMobile is available as a gadget there. EditNoticesOnMobile however is just a hair over 3K gzipped now. For reference, enwiki's Favicon[8] is about half the size of Commons' favicon. The size increase is negligible, but it prevents making multiple parse requests for the same page when editing a page more than once. I think it's a good tradeoff. Testing on testwiki works for me, but we should consider that template behavior could differ on another wiki. In particular {{tmbox}} and {{fmbox}}. An alternative could be to register EditNoticesOnMobile as a gadget here, just not enabled by default for anyone. Could even be hidden. (testers would have to append withgadget=EditNoticesOnMobile to a URL in that case) If deployed, I think it would be wise to do a gradual rollout, enabling it for some subset of users first. Just in case some browser or device wouldn't handle it as expected. — Alexis Jazz (talk or ping me) 19:55, 7 July 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.
Moved from Wikipedia:Village pump (technical)
— does that sound okay MB? — TNT (talk • she/her) 19:50, 29 June 2022 (UTC)
Support, makes sense after the reply tool. ― Qwerfjkltalk 07:18, 28 May 2022 (UTC)
Blocked sockpuppet) —CX Zoom[he/him] (let's talk • {C•X}) 07:15, 8 June 2022 (UTC)
Previous discussion: Talk:Blue § Colour blue in culture
Oppose per WP:INSTRUCTIONCREEP. This is overly specific. ― Qwerfjkltalk 14:44, 26 June 2022 (UTC)