Wikipedia:Village pump (all)

This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.

Click here to purge the server cache of this page (to see recent changes on Village pump subpages)

Village pump sections

Policy

post, watch, search
Discuss existing and proposed policies

Technical

post, watch, search
Discuss technical issues about Wikipedia

Proposals

post, watch, search
Discuss new proposals that are not policy-related

Idea lab

post, watch, search
Incubate new ideas before formally proposing them

WMF

post, watch, search
Discuss issues involving the Wikimedia Foundation

Miscellaneous

post, watch, search
Post messages that do not fit into any other category

View all village pump sections at once

Other help and discussion locations

I want...	Where to go
...help using or editing Wikipedia	Teahouse (for newer users) or Help desk (for experienced users)
...to find my way around Wikipedia	Department directory
...specific facts (e.g. Who was the first pope?)	Reference desk
...constructive criticism from others for a specific article	Peer review
...help resolving a specific article edit dispute	Requests for comment
...to comment on a specific article	Article's talk page
...to view other Wikimedia projects	Wikimedia Meta-Wiki
...to learn about citing Wikipedia in a bibliography	Citing Wikipedia
...to report sites that copy Wikipedia content	Mirrors and forks
...to ask questions or make comments	Questions

Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).

Policy

Policies on lists of fictional characters

I recently nominated List of Warriors characters for deletion. After a discussion on policy, it became clear to me that my nomination was not supported by policy, so I withdrew it. But I wanted to discuss the underlying policies here more broadly.

The article in question, which describes characters from a kids series with dozens of books, had grown to a remarkable 440,000 bytes long in March before being cut down to its current 35,000 by some very diligent editing. Clearly, the March version had some issues with WP:FANCRUFT. But under our policies on WP:SIZE and WP:CSC, these kinds of articles are allowed to exist even if they cite zero independent, reliable sources. Why? Because they are considered extensions/splits of the main subject of the article. So if Warriors (novel series) is notable, then List of Warriors characters is acceptable. This follows from WP:CSC #2, which states that standalone lists can work if "Every entry in the list fails the notability criteria."

Of course, this issue affects many franchises. Look at List of The Sopranos characters, or List of Warrior Nun Areala characters, or take your pick from Category:Lists of fictional characters by medium.

These pages present a number of issues. They are magnets for bloat, tons of WP:OR and WP:SYNTH, un-encyclopedic writing, and general fancruft. Because of this, they regularly need attention from experienced editors, who must either spend hours trimming them down and re-instituting WP:SUMMARY style, or else nominate them for deletion (as I did), sparking pushback from page editors. These pages strike me as a basic loophole in our notability criteria, that allow huge lists to proliferate without ever coming close to meeting the WP:GNG. Some individual fictional characters are certainly notable - Tony Soprano, for instance, or Severus Snape - they should have standalone, linked articles. I would propose modifying the WP:CSC criteria to say explicitly that lists of fictional characters are not covered by the criteria. I'm interested to hear what others think about this issue. Ganesha811 (talk) 17:52, 6 August 2021 (UTC)

Just as a general observation - this isn't a problem exclusive to character lists, this slow accumulation of cruft is an issue that affects huge numbers of our articles on fiction. I've had an eye on Elder race for a while because it is really badly exhibiting the symptoms, but I'm not really sure what to do with it: the article consists of a rather self contradictory intro where it lists a load of thing that an elder race may or may not be, followed by an enormous list of 90 examples, all unsourced, most not notable enough for their own article. It's a difficult issue to address because these articles are always going to attract drive-by edits adding their favourite character/example/thing to an existing list. Perhaps we need some stronger sourcing requirements for inclusion in lists of fiction things or a clarification of criteria 2, e.g. each item must have been discussed in a manner that relates to the list in at least one source? "Does not warrant a standalone article" doesn't mean "has no coverage at all". 192.76.8.91 (talk) 19:06, 6 August 2021 (UTC)

Lists of characters should be still be striving for some type of sourcing, and if that sourcing simply doesn't exists from reliable sources, then there's very little reason to have a long detailed list of characters when they can be summarized in the main body of the article. We don't expect the list of characters to necessary meet the same level of notability as the work itself, but WP:V is still a required facet, and just using the primary work as the source doesn't cut it (articles should be based on third-party sources). Likely what has happened is that while we have significantly pared down on how much standalone fictional character articles, those meant for deletion end up merged into these lists, with all content left uncheck, and create the long lists. These pages do need to be within WP:NOT#PLOT aspects too.

But I know that trying to say that these lists need to show more notability goes against WP:NLIST and has been a long-standing issue. I don't think its necessarily the existence of stand-alone lists but the amount of cruft they accumulate that needs to be addressed first and foremost. --Masem (t) 13:32, 7 August 2021 (UTC)

I agree that WP:CSC allows for a somewhat loophole to subvert WP:GNG, which very passionate editors can cite to add information that does not meet WP standards. Although WP:SPLITLIST does set forth that articles need to be kept "as short as feasible for purpose and scope," and that "too much statistical data is against policy," I think these principles can get lost in areas like fictional characters where editors are very passionate about adding information they find important. I'm not sure about a singular WP:CSC carveout for fictional character lists, because I think the problem is broader and should apply to more than one specific category. I agree with Masem that the underlying cruft needs to be addressed first. Fancruft and over-reliance on WP:CSC should not allow for the subversion of the basic principles of WP:V and WP:RS, which are meant to protect the integrity of all information on WP. Kind regards, PinkElixir (talk) 13:47, 7 August 2021 (UTC)

Yes, I've been objecting to this for a while now. The reasoning seems to be that Captain Blamtastic being notable automatically entitles List of Captain Blamtastic characters to an article. As well as, no doubt, List of Captain Blamtastic locations, List of Captain Blamtastic villains, and List of fictional weapons in Captain Blamtastic. None of which require sourcing because the parent article allegedly contains the required sources (it doesn't) and dependent articles acquire sourced status through some vague notion of trickle-down referencing. The result is fans writing a lot of reprehensible TV Tropes garbage that can't be verified and is all original research. Reyk _YO! 14:33, 7 August 2021 (UTC)

The cruft around Harry Potter includes not only List of Harry Potter characters, which is so long it needs an alphabetized index and most of which are redirects to article sections, but also List of supporting Harry Potter characters, none of which have articles and which includes several character profiles that are longer than many blps and mention everything that character ever did. I do not understand why we would need a standalone list of non-notable fictional characters. I'd support requiring fictional characters to be notable enough for their own articles for inclusion in list articles. A list with no lengthy descriptions within the parent article should be plenty. —valereee (talk) 14:40, 8 August 2021 (UTC)

There are cases where in a list of characters, some of the characters may be sufficiently notable for a standalone, but other characters at the same level of importance to the work are not (case in point is Characters of Overwatch (but this is where I know we've tried to drop 3rd party sourcing all over the place) - in such cases, it makes no sense to omit the characters at that level just because they aren't notable. What is essential is two fold: that these lists need to be limited in how "deep" they go: major and maybe the next minor level of characters (eg if we're talking a TV show, the characters played by the starring and recurring roles and not limited use cameos or roles) to keep the cruft in check to start, and that their creation should be based on if a good chuck (but not necessarily all) can be sourced to third-party RSes. We shouldn't be trying to be complete character lists for a work if that's simply not supported by sources (which in 99% of the time, they aren't). --Masem (t) 16:54, 8 August 2021 (UTC)

I think that's a question of Wikipedia:Balancing aspects, rather than verifiability or notability. WhatamIdoing (talk) 19:58, 9 August 2021 (UTC)

• Comment: I was reading through this thread and noted the link to Elder race. I PRODed that article after doing some searching for any sources which discuss the trope as a literary phenomenon (or a phenomenon in fiction more generally). I actually meant to RfD it, but the caffeine still hasn't kicked in yet, so I'll do that if someone contests the prod (which I expect). ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 14:07, 9 August 2021 (UTC)
  • @MPants at work: I don't think you'd have much luck getting an article deleted at RfD either...
    Interestingly your thoughts are the exact opposite of what I'd do, I was tempted to remove the enormous unsourced list of examples and turn it back into a stub containing the information that was present when the article was written, which does seem to have been sourced to the encyclopaedia in the "literature" section. I did think of prodding it, but the encyclopaedia suggested that there might be some decent sourcing out there (I couldn't find it though). 192.76.8.91 (talk) 19:10, 9 August 2021 (UTC)

    That was my issue. I thought there would be sources which were easy to find covering this, but to my surprise, this trope (as common as it is) seems to have very little coverage in the sources.

    My suggestion about trimming it to the list is based on the fact that I know several of the entries are explicitly described as "elder races" in the works in which they appear; if that were the criteria, we could maintain such a list in an encyclopedic manner.

    But that's literally the only way I can see this article not running afoul of our policies. The lede as it currently stands is just 1/2 OR and 1/2 wordy-expansion of the sourced content from the encyclopedia. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 19:20, 9 August 2021 (UTC)

    Give me a break, I despair when deletionists say they can't find sources for things like this. Clearly not really trying. The Greenwood Encyclopedia of Science Fiction and Fantasy has a seven page entry for "Elder races". I'm going to deprod this, if indeed it's survived this long. SpinningSpark 08:02, 5 September 2021 (UTC)

I'm specifically looking at this bit from the original comment by @Ganesha811:

> these kinds of articles are allowed to exist even if they cite zero independent, reliable sources. [...] This follows from WP:CSC #2, which states that standalone lists can work if "Every entry in the list fails the notability criteria."

I don't think that's true. It's possible to fail notability even if independent reliable sources exist.

CSC #2 is meant to cover things like a "List of minor Pokemon characters", in which we know something about the subject, but editors don't agree that it's enough for standalone articles. One common reason for this is editorial judgment, but another is that the independent sources don't contain Wikipedia:Significant coverage. WhatamIdoing (talk) 20:08, 9 August 2021 (UTC)

I agree with WhatamIdoing here because it's also possible for a list article to be notable without citing any reliable sources, but I think policy pretty much requires at least one reliable source (maybe in the lede of the list) for the article to be included in the encyclopedia, while the entries themselves do not have to be notable for inclusion according to WP:NNC. However, entries still need verifiable sourcing if they are challenged or likely to be challenged regardless of whether they are permitted without notability or not. This is the current interpretation that I think many people get confused. I think the confusion around how to interpret it correctly is what needs to change rather than the policies themselves. Huggums537 (talk) 05:25, 30 August 2021 (UTC)

It is better to have a list article, than an article on every character. Also if secondary sourcing is flimsy, then please consider writing at Wikibooks instead of Wikipedia. Quite a few similar pages have already been transwikied there. (even after long past deletion). Graeme Bartlett (talk) 08:10, 14 September 2021 (UTC)

What specific policy changes could we propose?

Masem, PinkElixir, Reyk, Valereee, IP editor - thank you all for your thoughts. I'm glad to see that this is an issue that others have noticed as well. What specific policy changes would help fix this? IP 192.76.8.91, I agree it is part of a larger issue, but it may be too heavy a lift to re-think how we approach all fiction - if we go one step at a time, we will probably get further. Do you all think that a change to WP:CSC criteria #2, saying "This criteria does not apply to lists of fictional characters/elements" would be effective? Or perhaps a requirement that lists of fictional characters be sourced to *secondary* sources only, so that huge amounts of primary-sourced WP:OR are no longer allowed? What other changes might work? Ganesha811 (talk) 13:06, 9 August 2021 (UTC)

Starting with CSC#2, I think there needs to be emphasized that such lists when created still must meet WP:V with thorough sourcing to third-parties (and lists only sourced to primary works or poor RS are thus not appropriate), and when talking about fictional works, WP:NOT#PLOT still applies: these are not lists to get around the limitations on plot regurgitation that apply elsewhere. Thes are policy level set points that absolutely can be used there. Any further advice can then be included in WP:WAF (writing about fiction) to spell out what these lists should focus on, avoiding trivial level characters or details, etc but based on the principles of CSC#2. --Masem (t) 14:39, 9 August 2021 (UTC)

Complying with WP:V does not require third-party sources.

This is one of the fundamental problems with this type of discussion, which turns up once or twice a year:

• Fact: Any given sentence/list entry about a book/fictional universe can fully comply with WP:V (and all related sourcing rules) if the content can unambiguously be found in the book itself.
• Fact: Most editors want independent/third-party sources in articles. (NB: Wikipedia:Secondary does not mean independent. We're basically talking about sources that the subject didn't create or pay to have created.)

Problem: There is no rule that says absolutely every article must contain a citation to an independent source. There isn't technically even a rule that says it must be possible to add a citation to an independent source to absolutely every article.

We have recommendations, and encouragement, and even a few written rules that say articles about certain subjects (e.g., businesses) must be verifiable in independent sources, but there isn't an overarching, absolutely-no-exceptions-even-for-your-special-subjects-we-really-mean-it-this-time rule that says that at least one fact in every separate page must be verifiable in independent sources.

Because of this situation, IMO if you want this article to comply with that standard, then we need to first create a rule that requires it. Until we make such a rule, we'll continue to have these discussions, with the one side correctly saying that each sentence is fully verifiable in an appropriate (primary+non-independent) source, and the other side complaining that it does not meet the unwritten, exception-riddled rule that most articles, about most subjects, under most circumstances, "should" contain an independent source. WhatamIdoing (talk) 19:52, 9 August 2021 (UTC)

@WhatamIdoing: Are you not describing WP:N? 192.76.8.91 (talk) 20:10, 9 August 2021 (UTC)

No. WP:N (you probably mean the GNG subsection of it) is a guideline, which some editors believe means that following it is optional. Also, there are alternative notability rules that undercut it. For three typical examples, consider:

• Wikipedia:Notability (academics), which says you can write an article about any university employee whose "academic work has made a significant impact in the area of higher education, affecting a substantial number of academic institutions" – and the method of determining this is: a Wikipedia editor says so. Consider also "The person has had a substantial impact outside academia in their academic capacity", which has the same rule for figuring out whether the person is notable. As far as PROF is concerned, once you meet these allegedly "objective" requirements, the entire article can be sourced exclusively to the subject's CV.
• For Wikipedia:Notability (sports), which says nearly all professional athletes are notable. For most popular sports, an athlete is notable if he is paid to play a game even for one second. Under those rules, it's perfectly fine to determine notability from the team's website, and to use only the team's website to source the article. (In practice, that's not what experienced editors usually do, but it's "legal".)
• Wikipedia:Notability (people)#Entertainers says any actor who has had "significant roles in multiple" films/shows is notable. All you need to prove notability is the film credits (which are a primary+non-independent source). For American actors, "multiple" is generally interpreted as "two".

We don't actually have a general rule requiring an independent source. WhatamIdoing (talk) 21:02, 9 August 2021 (UTC)

WhatamIdoing, just a quick note that, per the first sentence and the FAQs at the top of the page of NSPORT, meeting sport-specific criteria only presumes GNG and GNG sourcing is ultimately required. The second sentence refers strictly to meeting WP:V and showing evidence the topic is likely to have SIGCOV. So the guideline isn't actually an alternative to GNG. I just wanted to clear that up since a lot of people have this confusion and it encourages creation and more importantly retention of indiscriminate database-like microstubs on athletes. JoelleJay (talk) 18:35, 13 September 2021 (UTC)

WhatamIdoing, I'm not sure you're correct in saying that "Complying with WP:V does not require [secondary] sources." WP:V, under 'Original research', says "Base articles largely on reliable secondary sources. While primary sources are appropriate in some cases, relying on them can be problematic." Meanwhile, WP:NOR states "Do not base an entire article on primary sources, and be cautious about basing large passages on them."

Taken together, this suggests to me that articles primarily based on primary sources are not allowed under current policy. I think these cruft-accumulating lists of fictional characters are exactly the sort of problematic issue the policies caution us about. In-depth descriptions of fictional characters may be "verifiable" in the most literal sense of the word, but they usually are not verifiable in reliable, secondary sources, which is a real problem. Wikipedia is not a plot sponge. Ganesha811 (talk) 20:52, 9 August 2021 (UTC)

@Ganesha811, I didn't say that, because I know that Wikipedia:Secondary does not mean independent. We will never make progress on this subject if editors can't keep those two separate concepts straight. WhatamIdoing (talk) 21:03, 9 August 2021 (UTC)

WhatamIdoing, fair enough, you're right - "third-party" sources are not necessarily the same as "secondary" sources. But I'm not sure what difference that makes to the rest of my reply - articles based primarily on primary sources are clearly discouraged by current policy. Ganesha811 (talk) 21:14, 9 August 2021 (UTC)

Third-party reliable sources are very frequently not secondary sources. Most of the content in your local newspaper is primary, for example.

It's also possible to have a secondary source that is not independent. A meta-analysis of your own prior research, or an analysis of all the reasons why your grandfather was the best _____ ever, would be secondary but non-independent sources. WhatamIdoing (talk) 00:44, 10 August 2021 (UTC)

Actually, WP:V does say "Base articles on reliable, independent, published sources with a reputation for fact-checking and accuracy." (under WP:SOURCE). "base" here wouldn't mean every source has to be independent (which by nature has to be third-party for fictional works), but that should imply a significant majority of content should be based on those independent sources. When coupled with WP:NOT#PLOT, that strongly implies that lists of characters that only stay to in-universe aspects and otherwise dont include external sources are violating two key policies. --Masem (t) 21:50, 9 August 2021 (UTC)

Yes, WP:V makes a recommendation to have articles WP:Based upon independent sources. However:

• you know that recommendation is routinely ignored, and sometimes vehemently rejected, in all of the cases I mention above, and
• that still doesn't mean that "any given sentence/list entry about a book/fictional universe" isn't fully compliant with WP:V.

If we want every article to contain a citation to an independent source, we will have to change a policy to say "Add one or we will eventually delete it, even if you have an SNG rule/WikiProject opinion/20-year-long tradition that says you don't have to bother". And to make it happen, editors will have to agree that this is the right approach, even though that approach has some obvious downsides (e.g., making it much harder to write articles about professors who don't hire publicists). WhatamIdoing (talk) 00:29, 10 August 2021 (UTC)

I don't think we need a change in V or NOT, if we are specifically codifying issues with fictional works. The fact that WP:V is ignored does not mean it is right. A lot of our issues on fiction are a combination that pre-WP:N days, these were some of the most popular and largest pages that were written (it was routinely joked that we had more on Pokemon than severe world topics) and we're still seeing these linger, and that there's the monkey-see, monkey-do aspect that newer editors see these lists and think that's appropriate (or they're coming from TV Tropes or Wikia and think the same ideas work). We want to try to tackles these, but in the least disruptive manner to those that have maintained those. That we can do by altering CSC and WAF - guidelines, not policy - to be explicit about the expectations for lists of characters or similar material.

Also to keep in mind, we are specifically targetting the plot-related elements of a work. I can expect that you can find any random list of TV episodes and outside of ratings, it will be mostly unsourced. In that list, ignoring the short summaries, all those items (episode title, air date, etc.) are all things that can be sourced to the primary work, but that's because that's not the "fiction" of concern here. What we are worried about is keeping the short summaries concise there, and that's the type of thing that has to propagation to all elements involving a work's plot, whether on the main page about the work, a list of episodes, or a list of characters. NOT#PLOT specifically warns about this, and WAF echoes that. Unless you can provide the secondary or independent or third-party sourcing (it really doesn't matter), we do not want long summaries of a plot as that's just not encyclopedic. That's why when WP:V and WP:NOT are combined here, it clearly asserts that we should not be going into extreme depth about characters if they aren't discussed by outside sources, even if we can absolutely source that all to the primary work. --Masem (t) 01:43, 10 August 2021 (UTC)

Again: WP:V is not being ignored for any individual sentence or list entry in that entire page. WP:V is the policy that says you can source a novel's plot to the novel itself, remember? Every single sentence in that entire page complies with WP:V. WP:V is about individual claims, not whole articles. WhatamIdoing (talk) 19:06, 12 August 2021 (UTC)

I don't think it's realistic to rethink our entire approach to fiction in this discussion (which would be a herculean task), my thoughts were that I don't see why we should restrict this reform exclusively to lists of characters, I think that whatever is decided here should apply generally to lists of fictional elements be it locations, items, powers, storylines or whatever. Masem's thoughts sound very reasonable, I think we need some kind of clarification to point two along the lines of "It should be noted that "not notable enough for a standalone article" does not mean that lists of unsourced or primarily sourced material are acceptable. Each entry should be supported by secondary sourcing that demonstrates why it belongs in the list." (The wording could really use some work). Whether this should just apply to fiction things or more generally I'm not sure. 192.76.8.91 (talk) 19:36, 9 August 2021 (UTC)

Sure, I see what you're saying - lists of fictional characters came to mind first, probably because they are more common than other lists of fictional things. The discussion could be renamed "Policies on lists of in-universe fictional things" or similar. Ganesha811 (talk) 20:55, 9 August 2021 (UTC)

192.76, could you make up an example of something a secondary would need to say to justify the inclusion of an item in a list? Imagine that you're writing a List of Harry Potter characters or one of the Lists of superheroes. What's the minimum that you want the source to say, to demonstrate that Harry Potter, or Superman, or whatever other obvious content belongs in the list? WhatamIdoing (talk) 00:38, 10 August 2021 (UTC)

Actually, inclusion in those two lists would be very different metrics. For the superhero list, since that's cross media, I would expect that inclusion must be based on either WP having a standalone article on the character specifically or multiple RSes that speak about the hero. Whereas for HP characters, that would be a level of discussion needed by consensus, but I would say it would have to start with all significant recurring characters in the books, major one-book figures, and the like. --Masem (t) 14:02, 10 August 2021 (UTC)

That's not answering my question about what a secondary source would need to say to justify its inclusion. The statement is "Each entry should be supported by secondary sourcing that demonstrates why it belongs in the list." Your proposal here about "significant recurring characters in the books, major one-book figures, and the like" means "use primary sources", and therefore does not answer my question. WhatamIdoing (talk) 19:08, 12 August 2021 (UTC)

I think there's an ambiguity with the request in the specific example of List of supporting Harry Potter characters. Would secondary sourcing that demonstrates why it belongs in the list be a source that calls the character in question a "supporting character"? Or is it simply enough secondary sources that prove the character is relevant enough to be considered "supporting"? —El Millo (talk) 19:12, 12 August 2021 (UTC)

@Facu-el Millo, a secondary source provides some level of analysis. I'm not convinced that a sentence that says "Alice is a supporting character" counts as analysis. A paragraph or two that blathers on about something that would please your literature prof would count, but merely labeling all the characters except the protagonist as not being the protagonist doesn't sound like an analysis to me. WhatamIdoing (talk) 01:11, 24 August 2021 (UTC)

I was asking in order for it to be unambiguous and clear that there was no need for a reliable source to explicitly refer to the character as a "supporting character", that being significantly covered by reliable sources was what was required to be considered supporting, not as opposed to protagonist, but as opposed to minor or non-notable. —El Millo (talk) 01:19, 24 August 2021 (UTC)

Facu-el Millo, I think this is true because if it is being argued that inclusion is allowed without any secondary sourcing, then it certainly would be no problem allowing an inclusion using a third party source that says, "X was a supporting character" without any secondary sourcing analysis. This is the difference between 3rd party and secondary sourcing that WhatamIdoing was talking about earlier. Huggums537 (talk) 05:58, 30 August 2021 (UTC)

Exactly so, @Huggums537. In terms of defining a character from a notable book as being "supporting" (vs main or minor), the sourcing categories we're looking at are:

• The book itself is sufficient sourcing (primary+non-independent)
• A passing mention in a book review is sufficient, e.g., "Supporting characters such as Alice..." (independent, but not secondary)
• We need an analysis that explains why this character should be considered "supporting" (secondary, although not independent if it's written by the book's author)
• We don't care about sourcing (unlikely, but I include it for completeness).

I think in many cases that the book itself is sufficient, and I'd be totally satisfied with a passing mention of the label in any independent source. I don't think we need a secondary source for this. But other people seem to think that we do (e.g., the IP who wrote "Each entry should be supported by secondary sourcing"). WhatamIdoing (talk) 16:57, 30 August 2021 (UTC)

The extent that WP:Ver handles any text IMO it can handle this as well. If not challenged, an item can go on the list with no cite. Once challenged, it needs sourcing to establish that it meets the criteria of the list (given that its presence is an implicit statement of that) And the same WP:ver sourcing rules apply. Which means that in limited circumstance, a primary source is enough. BTW the list criteria is the main mechanism for assuring that the list doesn't have zillions of trivia listings. North8000 (talk) 20:01, 30 August 2021 (UTC)

North8000, totally agree here, and think many editors, even experienced ones, kind of fall off track when they attempt to conflate notability with sourcing article content. Even worse, removing perfectly verifiably sourced content on the mistaken notion of said content not being "notable" when notability doesn't apply to content in articles. What they don't fully understand is that notability applies to whole articles not the content within them. Huggums537 (talk) 06:42, 2 September 2021 (UTC)

• I've got two points – firstly, these lists are very often not created by fanboys, but by regular editors. Why? Because they want to get the list out of the main article. Not everyone reading the main article will be interested in every minor character/thing, but readers going to a "list of <foo>" will quite likely expect it to be extensive. There is no reason in principle why we should not provide that service.

Secondly, it has long been the convention on Wikipedia that the source of plot summaries is considered to be the fictional work itself (MOS:PLOTSOURCE). To my mind, character descriptions fall under this convention. By all means demand citations for anything that sounds dodgy or SYNTH and cut down on fancruft. But we really should stop beating up people who get excited by fictional universes with threats of deletion and instead just quietly help them to write better articles. I also agree that lists associated with a main article don't really need to prove notability independently. However, a list that is not referred to a single, main article must show that "lists of <foo>" is discussed in sources. SpinningSpark 08:44, 5 September 2021 (UTC)

I edited Warriors (novel series) to add an external link to external fandom wiki that provides more extensive character lists for the novels. It seems to be well maintained - at least much better than the Wikipedia list which started this discussion. My link to the external wiki is consistent with a similar link on Severus Snape. This raises some questions that I am baffled by as a relatively new editor. (1) Is there a policy regarding fancruft when a solid fan wiki exists outside Wikipedia? (2) Is there a basis for applying different policy to FireStar and Snape? ((3) Is there a basis for applying different policy to List of Warriors characters and Category:Harry Potter characters? I assume that there already is a separate policy for cleaning up cruft like this: Category:Literary characters introduced in 1997 although I do not yet know what it is (I would appreciate an explanation elsewhere that does not sidetrack this policy discussion). What matters to me is that keeping a cruft list encourages squandering of volunteer resources that could be better used to update and maintain the external Wiki that does a much better job of covering the same subject. I hope that whatever decision we make will take that into consideration as well.Annette Maon (talk) 16:11, 26 September 2021 (UTC)

It seems that the external link I added (as mentioned above) was rolled back quoting WP:ELNO as the reason. Following the "see also" link there to WP:ELP I found the following quote: "Note that the standards for WP:External links and WP:Reliable sources are different, so that a web page might be acceptable as an external link, but not as a reliable source, or vice versa". My addition of the external link was a bold edit and I respect User:Nikkimaria experience in deciding to undo it. It only underscores the questions I raised above. Should the external link on Severus Snape be removed as well? Are there any Fandom sites that are legitimate for use in external links even if they are not reliable sources? I recall reading about someone mentioning Memory Alpha as a possible legitimate link but I have not seen a list of consensus opinions regarding fandom wikis similar to what is found at the end of WP:ELP Annette Maon (talk) 14:02, 5 October 2021 (UTC)

Random Wikia/Fandom sites are typically not good EL; we're looking for sites with a strong history, so we're talking things like Memory Alpha for Star Trek, and Wookieepedia for Star Wars. Sites don't have to be notable like these, but they should have recognition beyond our own editors' assessment as a well-documented fan site. --Masem (t) 14:22, 5 October 2021 (UTC)

I don't like it

I'm being sincere here. Please explain to me how any of the above is not merely 'I don't like it' or 'not in my encyclopedia'?

WP:PSTS/WP:PRIMARY and WP:CSC (among other things), would seem to apply here. So what, if anything, is that actual issue? - jc37 03:19, 30 August 2021 (UTC)

@Jc37, there may be some of that. We have expectations about the right outcomes, and we have expectations about what outcomes our rules will produce. When the rules lead us to an unexpected outcome, we feel like there's a problem with either our expectations for outcomes or our current rules. WhatamIdoing (talk) 18:34, 30 August 2021 (UTC)

Sourcing Policy

(non-admin closure) No intelligible policy proposal has been put forward. Mohmad Abdul sahib has received advice on how to address this content dispute. JBchrch talk 20:25, 17 September 2021 (UTC)

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

---

I moved the discussion here so that a policy issue can be judged.Mohmad Abdul sahib 12:55, 16 September 2021 (UTC) ⤵⤵⤵⤵

User:Mohmad Abdul sahib, you copied a discussion (apparently, about the Buzzer article) from User talk:Just plain Bill#Hi although the last of that exchange was User:Just plain Bill suggesting you go to Talk:Buzzer. I see you have never edited Talk:Buzzer and tried to resolve the specific issue there. You have also not explained here what "policy issue [you want] judged". Additionally, you have ignored the statement at the top of this page that the purpose of this forum is to discuss proposed policies and guidelines and changes to existing policies and guidelines.

I have therefore taken the liberty of deleting the confusing exchange between you and Just plain Bill. I advise you to discuss matters regarding the Buzzer article at Talk:Buzzer, personal matters about Just plain Bill at User talk:Just plain Bill, and new policy suggestions, if you ever have them, here. — JohnFromPinckney (talk / edits) 06:05, 17 September 2021 (UTC)

▶There are commercial sites already, but they display scientific and studied materials without placing any advertisements. Commercial This is unfair. There are many sites that allow others to place their ads such as YouTube. The link is not considered commercial because of the presence of advertisements within the site. So, as this is allowed, articles free of ads must be allowed and are not considered commercial links because the site is commercial. There is a difference between a commercial article and a site commercial.Mohmad Abdul sahib 10:32, 17 September 2021 (UTC) Bumping thread for 7 days. Mohmad Abdul sahib 15:39, 17 September 2021 (UTC)

@Mohmad Abdul sahib, the advice you received was to post your concern to Talk:Buzzer. This page is "Wikipedia:Village pump (policy)", not "Talk:Buzzer". Please post your concern about an article on the article's talk page. If you need help figuring out how to post your concern at Talk:Buzzer, then try this direct link to the article's talk page. WhatamIdoing (talk) 19:29, 17 September 2021 (UTC)

▶WhatamIdoing You are not understand, not me!. I want to change the policy and put a clause stating that non-commercial links are allowed and not considered commercial links because the site is commercial!. This is to prevent the problem from recurring.Mohmad Abdul sahib 19:53, 17 September 2021 (UTC)

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

The removing process of Techyan's links

In Chinese Wikipedia's related talk page, a wikipedian said:

(translated) The Foundation has said that any links to sites held by global blocked users should be removed. This issue is a snowball clause, actually.

— Wikipedian 1233 on Chinese Wikipedia

So, should I remove all related links? I have a bot program (with optional manual mode, which is perfered now in enwp) at [1], with the following config:

{
   "replaces":{},
   "replaces_regex":{
      "\\[https?(:\\\/\\\/)?[a-zA-z0-9_.]*?wmcug\\.org\\.cn.*? (.*?)\\]": "\\2",
      "\\[https?(:\\\/\\\/)?[a-zA-z0-9_.]*?wmcug\\.org\\.cn[^ ]*?\\]": "{{Redacted|Chinese Wikipedia OA2021}}",
      "(https?(:\\\/\\\/)?)?[a-zA-z0-9_.]*?wmcug\\.org\\.cn[^ ]*": "{{Redacted|Chinese Wikipedia OA2021}}"
   },
   "skipped_ns": [2600],
   "api_php": "https://en.wikipedia.org/w/api.php",
   "username": "Example@BotPasswordUsername",
   "botpassword": "LOL",
   "delay": 10,
   "summary": "Remove links since Techyan was GBBed, ask Emojiwiki for details",
   "find_method": "exturlusage",
   "m_exturlusage_defs": {
      "euprotocol": "https",
      "eulimit": 500,
      "euquery": "*.wmcug.org.cn"
   }
}

 Wiki Emoji | Emojiwiki _Talk~~ 11:21, 19 September 2021 (UTC)

@Emojiwiki: This question may be better off at WP:VPP ~TNT (she/they • talk) 11:30, 19 September 2021 (UTC)

@TheresNoTime:Since I don't know how to move a conversation, can you help me to move it? ty--Wiki Emoji | Emojiwiki _Talk~~ 11:34, 19 September 2021 (UTC)

@Emojiwiki: Done ~TNT (she/they • talk) 11:37, 19 September 2021 (UTC)

Has the WMF actually confirmed that this is policy? Jo-Jo Eumerus (talk) 11:45, 19 September 2021 (UTC)

@Jo-Jo Eumerus:Not policy right now but is answered by WMF staff in English in zhwp page.—1233 ( T / C） 12:25, 19 September 2021 (UTC)

@Jo-Jo Eumerus and 1233:Ask 1233, actually I dont know (I only use commons sences)--Wiki Emoji | Emojiwiki _Talk~~ 11:54, 19 September 2021 (UTC)

Are we talking about external links to wmcug.org.cn? There are only two and they are not important: link search. Johnuniq (talk) 23:23, 19 September 2021 (UTC)

@Johnuniq:Yes, BTW if this aproved, I will suggest this on all wikimedia sites--Wiki Emoji | Emojiwiki _Talk~~ 06:16, 20 September 2021 (UTC)

I do not see a need to run this here; indeed, there are only 3 instances of related text. IznoPublic (talk) 20:12, 29 September 2021 (UTC)

Transwiki to enwikt

Today I closed Wikipedia:Articles for deletion/Meal train as transwiki only to learn that Wiktionary considers the transwiki process obsolete and no longer accepts transwikis from Wikipedia (see this related TFD.) Is this true across all projects? If so it might be helpful to replace Wikipedia:Transwiki with some information to that effect rather than having the soft-redirect to Meta. – filelakeshoe (t / c) 🐱 18:02, 24 September 2021 (UTC)

Well, even if enwikt doesn't want to do transwiki's - it doesn't mean that it can't be done to the hundreds of other WMF projects as appropriate. I suppose enwikt wants copy/paste done and is expecting that the author manually provide attribution somehow? In any case, I don't see this changing any policies here on the English Wikipedia. — xaosflux ^Talk 18:39, 24 September 2021 (UTC)

@Filelakeshoe: as far as your AfD closure, can't see a enwiki policy problem either - the determination is that this is not an appropriate article here, and that we will provide a redirect to an enwikt page. If enwikt doesn't want the page, then it would be a broken redirect speedy deletion at that point. — xaosflux ^Talk 18:49, 24 September 2021 (UTC)

I'll drop a note at wikt:en:Wiktionary:Beer_parlour to see if they have any insight to add here. — xaosflux ^Talk 18:55, 24 September 2021 (UTC)

As an en.wiktionary admin, I can state that we simply do not want transwikis. We don't want copy/paste, either — we don't want to deal with another wiki's dustbin, as the entries that have been transwikied are rarely useful or appropriate. That's why I nominated Template:Copy to Wiktionary for deletion. —Μετάknowledge^{discuss/deeds} 19:08, 24 September 2021 (UTC)

@Metaknowledge: thank you for the note, would you prefer that our authors just create a new wikt entry from scratch, following your inclusion and style criteria? We could just refer them there and let them know that after they have an acceptable wikt entry they can make a cross-wiki redirect here. — xaosflux ^Talk 19:33, 24 September 2021 (UTC)

New entries are always welcome, provided they belong in the dictionary and at least a vague attempt at the correct formatting has been attempted. —Μετάknowledge^{discuss/deeds} 19:39, 24 September 2021 (UTC)

I'm just an ordinary Wiktionary editor, but I can confirm that every transwikied entry I've come across was worthless, usually for several reasons, just causing us unnecessary clean-up work. If the term seems worthy of inclusion in a dictionary, it can be listed at Wiktionary:Requested entries.  --Lambiam 13:35, 25 September 2021 (UTC)

Tag-teams

User:Shrodger created: Margaret Martonosi, and User:Mmartonosi created: Susan H. Rodger. Other Users are new page approving each other's work. FWIW. Also, should it be noted on their article that they have a wikipedia User account? .... 0mtwb9gd5wx (talk) 18:58, 24 September 2021 (UTC)

@0mtwb9gd5wx: what is the policy or guidelines proposal you are wanting to discuss? If you think this is an instance of inappropriate use of user rights, please move to WP:ANI. — xaosflux ^Talk 19:02, 24 September 2021 (UTC)

@Xaosflux: I am not proposing policy, I am looking for clarification of policy. Also, should it be noted on their articles that they have a wikipedia User account? 0mtwb9gd5wx (talk) 19:13, 24 September 2021 (UTC)

Both those articles were created back in 2013. Neither editor has the current Wikipedia:New pages patrol/Reviewers user right, so this appears to be entirely moot. MB 19:53, 24 September 2021 (UTC)

User Shrodger created the article Margaret Martonosi several months before user Mmartonosi created the article Susan H. Rodger. Both have been active creating and editing articles on notable women computer scientists. Susan Rodger even authored the commendable article "Writing Wikipedia Pages for Notable Women in Computing". The qualification "tag team" is, IMO, completely inappropriate. I can discern no conflict of interest.  --Lambiam 13:50, 25 September 2021 (UTC)

Really? Editor A creates an article about Editor B, and Editor B creates an article about Editor A, and you can discern no COI there? I can discern at least the appearance of quid-pro-quo: "I'll write an article about you, you write an article about me." Whether this is what actually happened or if it's just coincidence, I don't know. The most recent edit was in June, so it's not that long ago. Still, if this isn't a pattern (if it's the only instance) then it's probably just coincidence. Anyone with these kinds of specific concerns should raise them with the editor(s) on their user talk page(s) in the first instance, and then if necessary, at WP:COIN. It's definitely not allowed by policy for editors to write articles about each other (at least without disclosing COI), but it may just be coincidence. It's not hard to imagine computer scientists might write articles about other computer scientists and thus two of them might write about each other: they may not even know each other IRL or even on-wiki. WP:AGF is also a policy, after all. (And no, their Wikipedia usernames shouldn't be included in their articles unless it's reported by WP:RS.) Levivich 15:16, 25 September 2021 (UTC)

Them having had what is at least the appearance of COI, and perhaps an actual COI, 8 years ago is nothing to deal with now. Unless you.can provide evidence of recent COI, there's nothing we can do. 46.116.237.47 (talk) 04:37, 26 September 2021 (UTC)

The most recent edit was in June, so it's not that long ago. Levivich 16:41, 26 September 2021 (UTC)

It's definitely not allowed by policy for editors to write articles about each other. Do we have any policy or guideline that specifically disallows editors writing articles about each other, or is it that writing about someone establishes a COI relationship with them? Or perhaps more precisely, imposes a COI relationship on them? NebY (talk) 17:04, 26 September 2021 (UTC)

WP:COI is the guideline, specifically WP:COISELF: You should generally refrain from creating articles about yourself, or anyone you know. If Editor A creates an article about Editor B and Editor B creates an article about Editor A, that doesn't establish a COI relationship or impose a COI relationship. What it does is raise an WP:APPARENTCOI where there is reason to believe that an editor has a COI but by no means does it prove or establish a COI... it simply raises the question (especially if Editor A and Editor B are in the same field like both are computer science professors) whether the two editors have an WP:EXTERNALREL:

Any external relationship—personal, religious, political, academic, legal, or financial (including holding a cryptocurrency)—can trigger a COI. How close the relationship needs to be before it becomes a concern on Wikipedia is governed by common sense. For example, an article about a band should not be written by the band's manager, and a biography should not be an autobiography or written by the subject's spouse. There can be a COI when writing on behalf of a competitor or opponent of the page subject, just as there is when writing on behalf of the page subject.

In addition, a quid pro quo (you write an article about me and in exchange, I'll write an article about you) could be view as WP:PAID editing: payment through exchange of labor. Another way it might be a COI is if the two editors are in some way competitors of each other, i.e. "revenge editing".

Now, it's worth repeating again that just because two editors create an article about each other does not mean that it was intentional, or there was any quid pro quo, or any ill intent. It simply raises the question of WP:APPARENTCOI. Levivich 17:31, 26 September 2021 (UTC)

Yes, it raises the question, but the answer is pretty obviously that there is no COI involved here. Phil Bridger (talk) 19:25, 26 September 2021 (UTC)

RfC notice for establishing Wikipedia:Notability (television) as a guideline

This is a notice that an RfC has been started requesting comment on if the draft of Wikipedia:Notability (television) should be implemented as a guideline and a WP:SNG. Comments are welcome at the discussion, here. - Favre1fan93 (talk) 16:34, 27 September 2021 (UTC)

A elongation: The questions for the candidates into Drafting Committee Movement_Charter

Into 2021-09-29 11:59:59 UTC You can suggest the questions for the candidates into Drafting Committee Movement Charter. ✍️ Dušan Kreheľ (talk) 18:06, 27 September 2021 (UTC)

Help regarding notability

(non-admin closure) Wrong place, but solved anyway. JBchrch talk 02:02, 28 September 2021 (UTC)

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

---

Hello! Sorry if this is not the right place to ask. I was searching in the Wikipedia namespace to find some information in regard to movie production companies and their notability inclusions criteria but wasn't sure what to read specifically given that the only page I was able to find related to that was in regard to movies which dealt only with the movies per se. Can someone guide me what notability criteria should I be looking for? I do understand that that information might not be in one single page. - Klein Muçi (talk) 23:07, 27 September 2021 (UTC)

This belongs at the Wikipedia:Help desk. As to the answer, see WP:GNG, then WP:NCOMPANY which applies to all companies. Herostratus (talk) 23:19, 27 September 2021 (UTC)

@Herostratus, thank you! Would it be somehow possible to find an example of a reliable, independent secondary source for a movie company (whichever) which would suffice to the rules explained in WP:NCOMPANY? I just want to see an example to understand how to apply the said rules to this case. - Klein Muçi (talk) 00:24, 28 September 2021 (UTC)

Klein Muçi, again, this is not the proper place for this discussion, but you should take a look at the referencing in the various articles mentioned in Major film studios. Notable movie companies will have received significant coverage in major daily newspapers, trade publications like Variety and Billboard, respected business journals and books published by university presses and other respected publishers. This applies worldwide. Cullen³²⁸ Let's discuss it 00:35, 28 September 2021 (UTC)

@Cullen328, thanks! That's what I was hoping to see. As for the discussion being out of the correct place, I was made aware of that in the first reply, as you saw but I was waiting for an admin to move it in the needed place, not wanting to "break more stuff" along the way. Anyway, I got the needed answer now so you can consider it closed. :) - Klein Muçi (talk) 00:44, 28 September 2021 (UTC)

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

RfC: amending parts of WP:NCELECT

Wikipedia:Naming conventions (government and legislation)#Elections and referendums claims to contain guidelines as to how to title articles about such democratic exercises. However, it appears to be a guideline which is not in sync with practice and which sometimes even leads to results which are outright contrary to the WP:TITLE policy.

Thus, I propose that all relevant phrases of NCELECT be altered to reflect actual usage, i.e. elections should be at [Date] [location name or adjective] [election], with the preference being left to other considerations of the article title policy (notably WP:COMMONNAME). RandomCanadian (talk / contribs) 03:00, 28 September 2021 (UTC)

Survey (NCELECT)

• Support as proposer. This seems to be a typical case of a guideline not exactly following actual practice, but never having been updated to match, and this leading to problems when it is incorrectly applied in a spirit violating WP:NOTBURO; not to speak of the fact that this is incoherent with the basic article title policy: a particular issue is with the guideline's call to use exclusively adjectival forms for country/place names. This is not very uniformly enforced (the vast majority of articles for sub-national level contests are, without exception, at the [Date] [Location] [election] form, ex. 2018 California elections, not "2018 Californian elections"), mostly because it's utter nonsense (2019 United Kingdom general election is a very obvious example of where using the adjectival form - "British" - would be very thoroughly inappropriate, not only because "British", while technically correct, is not used in this fashion due to specific socio-historical issues, but also because nobody refers to these as such) and because it leads to titles which are not particularly natural to a reader looking for the topic (if you can figure out where the article about the 2019 San Marino election is actually located without searching, good job), thus violating WP:COMMANNAME rather unambiguously; all in the name "but it is a guideline" - apparently, an ill-defined guideline because the only major RfC I see about it on the talk page archives is this, which makes no mention of using an ajectival form - this was altered here by Number 57, having been put in basically unquestioned in 2005 and not altered or passed up to the community for actual formal approval at any point in time. RandomCanadian (talk / contribs) 03:00, 28 September 2021 (UTC)
• Support Yup, makes sense. * Pppery * _{it has begun...} 03:01, 28 September 2021 (UTC)
• Oppose This would lead to even more inconsistency in election article title names. And British election articles really should be called just that. Number 57 08:11, 28 September 2021 (UTC)
• Weak Support - Consistency is good, but needs to be balanced with recognizability per COMMONNAME. Blind, over-consistency, can lead to readers not being able to locate articles. Redirects can help with that. Blueboar (talk) 11:45, 28 September 2021 (UTC)
• Support allowing either adjectival or noun form. We quite reasonably prefer 2017 French presidential election to 2017 France presidential election, but 2020 United States presidential election to 2020 American presidential election and 2017 Greater Manchester mayoral election to 2017 Greater Mancunian mayoral election, while 2019 British general election would be at best informal and more likely highly contentious. NebY (talk) 12:18, 28 September 2021 (UTC)
• Support. Found it! Had to search, though. JBchrch talk 13:17, 28 September 2021 (UTC)
• Oppose proposal as-is. If I understand this correctly, the proposal calls for indiscriminately setting all titles regarding election articles to the "[date] [location] [election]" format, setting aside a very well-established consensus in place in Wikipedia for decades and affecting hundreds if not thousands of articles, under alleged "not in sync with practice" grounds (a claim which, otherwise, has been left unsupported by actual evidence) and because it "sometimes even leads to results which are outright contrary to the WP:TITLE policy" (so, rather than addressing the particular issue(s) at hand to make it/them conform with TITLE, let's dump the whole NCELECT altogether and disrupt the vast majority of cases where it works nicely, why not?). On the one side, adjectival forms are a natural way of referring to the election in question in the article's body (thus avoiding unneeded piped links): 2019 San Marino general election or 2019 United Kingdom general election may have sense, 2016 Spain general election, 2021 Germany federal election or 2017 France presidential election are awkward when used in-text and would like require piped-links or the creation of redirects. But then, it should be noted that the current convention has been expanded locally to allow for more WP:TITLE-abiding exceptions in specific situations, i.e. 2020 United States presidential election (not 2020 American presidential election) or 2019 United Kingdom general election (not 2019 British general election), because that's how sources commonly refer to those and that's how those would be naturally referred to in any given text body. If the problem at hand pertains to specific situations (and it clearly is, by the wording of the proposal and because it seems like it is deriving from this particular discussion), then I'd favour an amendment to NCELECT introducing an additional clause under which "location" can take precedence over the adjectival form in those situations where sources do prefer the former over the latter (this is what already happens de facto in many situations, in a similar way that there is a clause providing for situations such as 2021 Scottish Parliament election or 2017 Northern Ireland Assembly election). Let's don't turn this into a WP:BROKE issue by causing havoc where it is not warranted. Impru20^talk 14:24, 28 September 2021 (UTC)

  @Impru20: You appear to indeed have misunderstood. The proposal is to allow either form, depending on which makes most sense in a given context. RandomCanadian (talk / contribs) 14:45, 28 September 2021 (UTC)

• @RandomCanadian: If that's the case, then yes, since that's what has been done locally for years without much trouble. Still, the formal text of the proposal is "that all relevant phrases of NCELECT be altered to reflect actual usage, i.e. elections should be at [Date] [location name or adjective] [election], with the preference being left to other considerations of the article title policy". Since I do not agree with it for the reasons exposed above and because it would leave the door too open to ambiguity, I keep my "oppose proposal as-is" !vote, favouring instead the incorporation of an additional clause (in a similar fashion as done "for elections to particular bodies or offices") which could be written as follows: "For elections in countries for which reliable sources prefer such format, default to the form "Date [country name] type election", as in: 2020 United States presidential election, 2019 United Kingdom general election, or 2020 New Brunswick general election". Impru20^talk 14:55, 28 September 2021 (UTC)

• @Impru20: it sounds like you're missing the "or adjective" part of "[date] [location name or adjective] [election]" (as you did in your initial comment). There's no ambiguity. It allows both "2019 United Kingdom general election" and "2017 French presidential election" as written, in contrast to the existing guideline (which prohibits the former). It is more explicit in this than your proposed text. — Bilorv (talk) 16:09, 30 September 2021 (UTC)

• Article names like "2019 United Kingdom general election" and "2020 United State presidential election" exist because it can be argued that using the adjectival form is problematic and an exception is made to the more natural article title form, which is the adjectival one. My issue with the proposal is that it gives equal weight to location and adjectival forms, whereas the latter should be preferred based on their naturalness. The risk is that we end up with worse article titles or time-wasting RMs because someone thinks it's better to call an article '2021 Germany federal election' and the proposed new wording of the guideline says this is fine. Number 57 16:19, 30 September 2021 (UTC)

• @Bilorv: I have missed nothing, I am explicitly against the proposed change as formulated. I am in favour of having the current scheme of using the adjective first as the default naming convention, but allowing the use of the location in specific cases where appropiate (which is what has been done in Wikipedia for years already). This is in contrast to the or proposal, which would basically allow for an indiscriminate use of either the location or the adjectival form in any case, even in elections of the same country (i.e. the proposal would technically allow for both a 2016 United States presidential election article and a 2020 American presidential election article to co-exist, with both being technically equally valid. It is a drastic example, but the point is made). My proposal would basically turn this unwritten convention into written policy, which would achieve the same as RandomCanadian's current proposal while being much more harmless. Impru20^talk 17:09, 30 September 2021 (UTC)

@Impru20: I should have pinged you below; in any case see this for further explanation as to why I don't think your drastic example would happen under my proposal as well. RandomCanadian (talk / contribs) 23:46, 30 September 2021 (UTC)

@RandomCanadian: The problem is that your wording leaves it just too open to interpretation and deviates from customary Wikipedia practice for many years. Your assurances do not matter, since you can just simply control the way other people would implement such naming convention under your proposal. Considering past precedence through Wikipedia on other NCs and MOS, it will get messy. I would rather prefer a straightforward solution that does not mean any drastic change to current policy. Impru20^talk 06:47, 1 October 2021 (UTC)

Agree to disagree, then, as I think the policy should not explicitly favour one form or the other (even if in practice one can expect that one or the other might be more frequent in some contexts), and also think that simply suggesting to follow the other criteria to fix any ambiguity as to which should be used will ensure that articles are overall at better, clearer titles (otherwise, as I also know from experience, people are going to argue "but the guideline favours adjectives" even in contexts where there is no reason to favour adjectives). RandomCanadian (talk / contribs) 13:37, 1 October 2021 (UTC)

• Support. We've needed a general consistency here for a long time now, and the proposed pattern already agrees with most of our relevant articles. I detect some "United Kingdom" vs. "British" dispute in the background, and I don't think this RfC addresses it; it is better taken elsewhere. WP:COMMONNAME is already effectively our guide to whether in a particular case to use an adjective or noun form, though it would not hurt for the guideline to reiterate, something like "When choosing between a noun and adjective form, use the form most frequent in reliable, independent, English-language sources."  — SMcCandlish ☏ ¢ 😼  00:32, 29 September 2021 (UTC)
• Comment - Perhaps on this topic, we should go via local consensus. I think there'd be opposition to 2024 American presidential election, for example. GoodDay (talk) 23:53, 29 September 2021 (UTC)

  @GoodDay: What are you opposing? If we followed the guideline as written, it should be "American". Obviously, the guideline is not in sync with actual practice, hence why I am proposing it be amended so that both forms are allowable, with the decision of which one to use for a particular country or region being left to local consensus. i.e. my proposal is basically this, but copied to the other three similar sentences too. RandomCanadian (talk / contribs) 12:10, 30 September 2021 (UTC)

  Just pointing out, that if we attempt an across the board implementation (either option)? It might get messy. As for myself, I will abide but whatever this RFC's decision is. GoodDay (talk) 18:52, 30 September 2021 (UTC)

  @GoodDay: The proposal isn't to make it a free for all; I explicitly wrote what is implied by usual policy, i.e. "with the preference being left to other considerations of the article title policy" - i.e. it shouldn't merely be an arbitrary choice, it would still need to follow the usual guidelines (including naturalness [so no "Germany elections"] and recognisability/precision [so no "American elections"]). RandomCanadian (talk / contribs) 23:43, 30 September 2021 (UTC)

  Changing to neutral. I'll abide by whatever the RFC decision is. GoodDay (talk) 23:50, 30 September 2021 (UTC)

• Support: needs updating as it's out of line with current practice, and the proposal will cover essentially all current practice. Even the Sanmarinese example wouldn't actually need to be changed to match this new NCELECT, though it should be. — Bilorv (talk) 16:09, 30 September 2021 (UTC)
• Support per nom, particularly to accurately document current practice and with the preference being left to other considerations of the article title policy. Levivich 23:36, 1 October 2021 (UTC)
• Support. Nomination makes cogent argument to have policy follow generally accepted practice. Eggishorn (talk) (contrib) 15:55, 3 October 2021 (UTC)
• Oppose but allow redirects. At minimun, the proposal and guidance should prioritize country name over adjective, as not everyone may be familiar with the adjective or the adjective may either be over- or under- inclusive. --Enos733 (talk) 18:38, 3 October 2021 (UTC)
  • Comment. A fair point, but note that this proposal still moves in the right direction - at least it allows the country name, while the current guidance suggests adjective-only. SnowFire (talk) 19:31, 4 October 2021 (UTC)
• Support. On Wikipedia we tend to go by actual cases rather than follow some philosophical "this is how it should be everywhere" principle. It would be wrong to call any UK-wide elections "British" because that word is ambiguous - it can mean "pertaining to the United Kingdom" or "pertaining to the island that contains most of England, Scotland and Wales, but certainly not Northern Ireland". But carrying that case over to everywhere leads to such absurdities as calling the recent election in Germany by a name that is hardly ever used in English. Let's just use the normal rules for article titles. Phil Bridger (talk) 19:39, 3 October 2021 (UTC)
• Support. Guidelines should follow usage, not the other way around. As a note, the change doesn't even forbid the adjectival form, so really can't see the issue with such a change at all - although, per others, certain flagrant examples like San Marino should probably be moved sooner rather than later. SnowFire (talk) 19:30, 4 October 2021 (UTC)
• Support: I see this as leading to titles that are stronger on the "naturalness" criterion. Firefangledfeathers (talk) 19:36, 4 October 2021 (UTC)
• Support: The current guideline fails Criteria #1 and #2 - and even without relevant policy, the San Marino example was extremely convincing when I first read it, and remains extremely convincing now. I'm not entirely certain we need any guideline to define this - I would think that we can come to reasonable titles on the basis of Criteria, perhaps with an explanatory essay pointing users in the right direction - but as we have one, the one we have might as well make sense. BilledMammal (talk) 20:28, 4 October 2021 (UTC)
• Comment: Whatever the result may be, I think there must be redirects made to allow for both forms. Have one form be where the article actually resides, while have the redirect of the other form to allow people to search using either form and also for links to be made with either form used. --boldblazer 23:17, 5 October 2021 (UTC)

Discussion (NCELECT)

• Whatever the exact shady origins of NCELECT, or the outcome of this discussion, formalising this aspect via a proper process is likely to reduce potential for misinterpretation. RandomCanadian (talk / contribs) 03:02, 28 September 2021 (UTC)
• The title of this section is misleading – the proposal isn't to deprecate NCELECT, it's to amend it. Also, why wasn't this done on the guideline's talk page like usual attempts to amend guidelines? Number 57 08:11, 28 September 2021 (UTC)

  The proposal is not at NCELECT cause that page has limited traffic. Also because as far as I see there's been an editor who's been editing the guideline without obtaining previous consensus for it; specifically on this point (diff), and that same person has been enforcing the guideline they wrote themself as though it were force of law. RandomCanadian (talk / contribs) 11:47, 28 September 2021 (UTC)

  That edit was a simple correction, not a material change (as 'demonym' refers to the people of a country which wasn't appropriate for the guideline, although in practice, in most cases they are the same). And I am not the guideline's original author. Number 57 12:19, 28 September 2021 (UTC)

• We have Year Canadian federal elections & Year United States presidential elections. We also have Year United Kingdom general elections & Year Russian presidential elections. They're all Year location election form. GoodDay (talk) 09:15, 28 September 2021 (UTC)

  Acoording to the guideline as written, it's supposed to be Year [Adjectival form] election (so "2019 British general elections", because "British" is indeed the demonym for "United Kingdom"). The guideline making no exception for other overriding policy concerns (such as the well known WP:CRITERIA), so should be amended to cover at least that. In addition, the guideline as written does not reflect actual practice, as demonstrated by countless cases like the California elections RandomCanadian (talk / contribs) 11:47, 28 September 2021 (UTC)

• The amendment is required. PS - I'm trying to picture 2022 Oregonian gubernatorial election, 2022 Illinosian gubernatorial election, 2021 New Jerseyite gubernatorial election, 2023 Lousianian gubernatorial election, etc. GoodDay (talk) 20:51, 3 October 2021 (UTC)

Deletion of TimedText Pages

Why are requests to delete TimedText pages, which are audio, considered at MFD rather than at FFD? I think I know the answer, which is because that is what the rules say. Why do the rules send deletion requests for TimedText to MFD, which is not otherwise a forum that concerns itself with files containing analog, audio, video, image, or other such information? Why not direct those requests to FFD? That isn't really a "good fit", but it is sort of "less bad fit" than MFD. Robert McClenon (talk) 04:49, 30 September 2021 (UTC)

@Robert McClenon: probably because they are relatively rare, I expect most TT deletions are speedy (G8 when the file is deleted), and the others are rather uncontested so they just lumped in to the "everything else" that went to MfD. Venue-wise, most FFD's are about copyright issues, which could pertain to TT's - but again it is rarely a concern. Aside, if we really wanted to move something out of MfD - I've always argued that Draft's would be the best (as their deletion arguments are almost always about content or content inclusion criteria - not about miscellaneous things). — xaosflux ^Talk 10:59, 30 September 2021 (UTC)

For reference, I looked over the last 20000 page deletions. Of those, 27 were TimedText - all of which were G8. Additionally, Special:PrefixIndex/Wikipedia:Miscellany_for_deletion/TimedText shows that there have only ever been 32 TT MFD's. — xaosflux ^Talk 11:07, 30 September 2021 (UTC)

Also, TT is not audio - it is plain wikitext. — xaosflux ^Talk 11:08, 30 September 2021 (UTC)

I don't think that either of these locations are completely bad, but I agree with Robert that these requests would ideally be handled at FFD, even though that means taking a little effort to update the rules (and probably Twinkle, too). WhatamIdoing (talk) 14:56, 30 September 2021 (UTC)

I don't object to moving these from MFD to FFD, but think that the overhead of even worrying about any of the mechanics is time best spent elsewhere. — xaosflux ^Talk 15:00, 30 September 2021 (UTC)

I agree with xasoflux; it's just not worth worrying about. -- RoySmith (talk) 15:11, 30 September 2021 (UTC)

I agree that, if there have been only 32 deletion nominations for TimedText files since Day One, then it makes very very little difference where we delete them. Perhaps this is because everything having to do with TimedText files makes very little difference. Robert McClenon (talk) 17:50, 30 September 2021 (UTC)

I agree it's not worth spending much time on. I can only think of three reasons for deletion: there is no associated media file, the associated media file is being deleted, or the transcription is significantly wrong and no one is volunteering to fix it, which for most cases doesn't require much discussion: an admin can watch the media file with the timed text and decide if it should be deleted. isaacl (talk) 19:52, 30 September 2021 (UTC)

Agree, deletion of media files, sound like images, belongs at FfD, primarily because complex copyright concerns are interwoven, like with image files. —SmokeyJoe (talk) 22:40, 5 October 2021 (UTC)

It not being a big frequent issue is not a reason to not improve something. SmokeyJoe (talk) 23:17, 5 October 2021 (UTC)

Deletion of Drafts

On the other hand, the deletion of drafts is a substantive matter. User:Xaosflux writes:

Aside, if we really wanted to move something out of MfD - I've always argued that Draft's would be the best (as their deletion arguments are almost always about content or content inclusion criteria - not about miscellaneous things).

Where would we move deletion of drafts to? They should not be moved to AFD, because, although drafts are proposed articles, notability is the most common reason for deletion of articles, and notability is not a reason for the deletion of drafts. What forum is there to move deletion of drafts to? Should there be a WP:Drafts for Discussion forum to discuss deletion of drafts, that could also handle appeals of rejected drafts, or complicated issues about whether to accept drafts? If drafts are not miscellaneous, what are they? Robert McClenon (talk) 17:50, 30 September 2021 (UTC)

@Robert McClenon: in my general opinion, miscellany is more about things that are ancillary to the project (mechanics, presentations, and niche things that never got their own home from VFD such as TimedText above) - while drafts are more aligned with the core mission of gathering/curating of knowledge. DfD could be the answer - there hasn't been enough push to bother before - but they are certainly a larger category than TT if we are looking at splitting something out of MfD. — xaosflux ^Talk 18:08, 30 September 2021 (UTC)

I've been one of the regular participants at MFD for several years, and my unscientific estimate would be that most of the time it has slightly more "draft-like" stuff than anything else, and next to that is WikiProject-related stuff. An exception was that in 2019, it was mostly portals, until the portal deletions resulted in an ArbCom case that didn't settle anything. (ArbCom, reasonably, said that there should be a community discussion. Community discussion fizzled out because the community was too scattered even to have a focused discussion.) However, much of what goes to MFD is either drafts or draft-like stuff, such as draft articles in user space. So a lot of what gets discussed at MFD is proposed content. (And portals are also a device for presenting content.) Robert McClenon (talk) 19:33, 30 September 2021 (UTC)

Perhaps we can move it out, by getting rid of that process to delete drafts. After all, we already have broad allowance for what drafts are allowed to exist, even if they wouldn't have a hope of surviving an AfD (we just delete them after they've been inactive for six months), and we already handle the things that need to be deleted (copyright, BLP, illegal) through speedy deletion.

With that said, this is just brainstorming; I have minimal experience with MfD. BilledMammal (talk) 21:22, 4 October 2021 (UTC)

Drafts are frequently left to languish, which might be unfortunate but which is a fact of life, but when deletion is being discussed, I would prefer to see those discussions happen at Wikipedia:Articles for deletion. They should be deleted (or not, as the case might be) on the same grounds as any page that is already in the mainspace, and the most straightforward way to make sure that the same standards are being applied is to have the same process handling it. There has been a tendency among AFD and NPP regulars to sometimes reject drafts and new pages on notable subjects on grounds that Wikipedia:Arguments to avoid in deletion discussions rejects. I also wouldn't object if the preferred process looked like first moving the page to the mainspace and then immediately nominating it for deletion. Leaving that log entry in the mainspace might make it easier to trace histories later.

Also, once a page has survived AFD, it should not be in draftspace. WhatamIdoing (talk) 00:51, 5 October 2021 (UTC)

Also, once a page has survived AFD, it should not be in draftspace. Yes. This is something I strongly support making policy. Thryduulf (talk) 10:11, 5 October 2021 (UTC)

There are really only 3 reasons why a draft should ever be deleted:

1. The sole author requests it (G7)
2. It is actively harmful to the project (e.g. attack pages (G10), copyright violations (G12), and similar)
3. No human has touched them for 6 months (G13) - and I'm not fully convinced this isn't causing more harm than good in its present form.

For everything else, there needs to be a very good reason why it needs to be deleted before it is eligible for G13. Lack of notability and other reasons articles are commonly deleted at AfD are not examples of such reasons. Thryduulf (talk) 10:11, 5 October 2021 (UTC)

The question is whether a page in the draft namespace is indeed a draft that could ever become an article. We do want to delete WP:NOTWEBHOST violations in any namespace, and draft namespace shouldn't be protected from that. (Howtos, manuals, gaming, various data dumps etc. should not be kept around based on what namespace they are in, but based on whether they have any conceivable use for the project). —Kusma (talk) 12:30, 5 October 2021 (UTC)

True. Any draft that violates any line at WP:NOT is welcome at MfD and is usually deleted there. The problem with most DraftSpace MfD nominations is that the nominator cites no WP:NOT violation. SmokeyJoe (talk) 23:23, 5 October 2021 (UTC)

Agree with User:Thryduulf. Very few good draftspace nominations are made at MfD. Mostly, I think it is due to enthusiastic Wikipedians trying to contribute, who don’t consider that raising unimportant issues on a formal deletion page creates more work than the original problem was worth. I.e busywork. SmokeyJoe (talk) 23:21, 5 October 2021 (UTC)

Sending all draftspace deletion to another forum would be good for mfd in removing much busywork from mfd. However, I predict that the new forum will be unattended. Most draftspace mfd nominations would have been appropriate for WP:N/N. Consider reviving that page. SmokeyJoe (talk) 23:25, 5 October 2021 (UTC)

RfC started on track listing sections

An RfC has been started at MOS:MUSIC relating to song articles. All comments are welcome. --TheSandDoctor ^Talk 03:08, 4 October 2021 (UTC)

What even is a reliable source?

Wikipedia says that we should not judge things by whether they are true, but what "reliable sources" say about them. Why should we just trust "respected commentators" for no reason? How do we decide if someone is respected? Why should we believe everything reliable sources say? — Preceding unsigned comment added by Aalaa324 (talk • contribs) 08:34, 4 October 2021 (UTC)

• I assume you are referring to media commentators? If so, We DON’T believe what they say. We DO, however, report what they say (using in-text attribution to indicate that what we are reporting is an opinion, and not necessarily fact). We should ALSO report what other “trusted commentators” say (especially if they disagree with the first commentator). See WP:NPOV for more on this. Blueboar (talk) 12:02, 4 October 2021 (UTC)
• Two remarks:
  • There is no consensually accepted definition of what a reliable source is (pinging WhatamIdoing, with whom I have discussed this at WT:RS). The guideline WP:RS gives some pointers by instructing editors to refer to sources with a reputation for fact-checking and accuracy (WP:REPUTABLE). The rest simply follows from there. At WP:RSN, the practice is for sources to be considered unreliable if they have a history of publishing falsehoods or fabrications.
  • Wikipedia's policies postulates that such reliable sources exist and are a valid basis on which to base an encyclopedia. You are of course completely free to reject this notion. However, the practical (as opposed to theoretical) question is how would you build an encyclopedia, then? JBchrch talk 13:59, 4 October 2021 (UTC)
• In re Why should we just trust "respected commentators", the answer is: sometimes we don't. Sometimes the disreputable source is the reliable one. We've cited tens of thousands of social media posts. If someone is accused of a crime and claims to be innocent of crimes, we might cite their denial of guilt, even if we think they're lying. The accused person is the most reliable source for what the person says about their guilt. (NB: not for whether the person is guilty, but for what the person says.) WhatamIdoing (talk) 21:12, 4 October 2021 (UTC)

Adding several namespace shortcuts

Boldly moving this to WP:VPI as there is no policy creation or modification being discussed here. — xaosflux ^Talk 14:31, 5 October 2021 (UTC)

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

---

Moved to WP:VPI

While contributing to English Wikipedia, I found that some namespace shortcuts are missing. For example:

• H: pointing to Help:
  • HT: pointing to Help_talk:
• T: pointing to Template:
  • TT: pointing to Template_talk:

if we add these shortcuts to English Wikipedia, this will makes links shorter and easier to access, esp. with shortcut services. Wiki Emoji | Emojiwiki _Talk~~ 12:27, 5 October 2021 (UTC)

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

Stale User Pages of Inactive Users

This question is about user pages of inactive users (inactive by several years), and specifically about user pages that have the nature of drafts. There are at least four kinds of user pages of long-inactive users:

• 1. Article-like pages.
• 2. Essays.
• 3. Stuff that is eligible for speedy deletion.
• 4. Other stuff, whether in sandbox pages or elsewhere in user space.

At Miscellany for Deletion we get a fair number of nominations to delete stuff in the user space of other users, active, semi-active, or inactive, and I am not always sure why the nominator was looking at it in the first place. I have written an essay, Ragpicking, that discourages looking at such stuff in the first place. However, we still get a fair number of nominations of stuff from inactive users, and some of the stuff is article-like.

This question is about article-like pages. The guidelines on user pages and stale drafts say that they may be moved to article space if they are ready for article space. They should not be moved to article space simply in order to be nominated for deletion, which wastes volunteer time. The guideline also says that draft pages may be moved to draft space, but they don't specify when. My thinking is that such pages should be moved to draft space if they do not currently satisfy verifiability and notability but have a credible claim of significance and so might be improved to be articles.

If there already is an article on a subject, then a user page can be redirected to the article, or tagged to be merged with the article. My real question has to do with stuff that isn't ready to be an article, but the topic is one that might have potential. When should these pages be moved to draft space, where they will be somewhat more visible, but will expire in six months? Robert McClenon (talk) 18:51, 5 October 2021 (UTC)

• @Robert McClenon: I think different standard practices may be in place for (Base userpages, e.g. User:Username), (Primary user sandboxes, e.g. User:User/sandbox), (Other user sandboxes, e.g. User:User/sandbox2), (User article drafts, e.g. User:User/Articletitle), and things you mentioned above like User:User/ProjectThingy. As such, I don't think there is a one-size-fits-all answer here. For example, in most cases it wouldn't be appropriate to redirect a base userpage to an article - even if it had article-like content on it, nor to move a primary sandbox that had lots of sandboxing done in to a draft about only one topic. — xaosflux ^Talk 16:59, 6 October 2021 (UTC)
  • User:Xaosflux - I was asking about article-like pages. I didn't mention base user pages. Your breakdown is similar to but not the same as mine. It is the drafts that I was asking about. Robert McClenon (talk) 00:53, 7 October 2021 (UTC)
    • @Robert McClenon: sometimes new users make what looks like a draft article on their own base user page. There are certainly a few ways these can be dealt with (such as moving their base page to a subpage, a draft, or mainspace) but what I was calling out is that this wouldn't be a good example of a page to leave a redirect on. — xaosflux ^Talk 01:00, 7 October 2021 (UTC)

• They're not causing anybody any trouble, why do anything about them? If there's some reason to believe they need to be deleted (socking, copyright problems, BLP problems, etc), sure. But otherwise, I don't see any reason to waste any time even thinking about them. -- RoySmith (talk) 17:08, 6 October 2021 (UTC)

• I think the reason is that some people consider tidiness to be a virtue. Personally I would much rather someone displayed more obvious virtues such as honesty, but many people seem to value tidiness. Phil Bridger (talk) 17:14, 6 October 2021 (UTC)

• User:RoySmith - Well, the reason why I am asking about them is that other editors ask to have them deleted at MFD for various reasons.

• Don't people have better things to do? -- RoySmith (talk) 01:14, 7 October 2021 (UTC)

• I have never understood the desire to clean out inactive user pages. There is no need. My call… as long as the inactive user page does not contain something we would ask an active user to remove, don’t do anything with it. Just let it sit there gathering electronic dust. If it really bothers you, I suppose we could place some sort of note saying that the user is inactive… but even that is not necessary. Blueboar (talk) 01:36, 7 October 2021 (UTC)

Let's Go Brandon

Let's talk about how "consensus" is being used to squashed dissenting opinions on articles relating to society/politics/political philosophies, through everything listed on the "pitfalls and and errors" subsection.

Undue weight to "reliable sources" is so disproportionate at this point that articles/sections/subsections look more like hit pieces than fairly weighted articles. None of the "reliable" sources are giving fair coverage to Donald Trump's conduct during the January 6th incident[2]. The title of this section is another example of how unfair weight is being given to one side, but not the other.

To say that I am pushing fringe theories would not be a fair assessment of my intentions. Neither would it be good faith to use Fox News as a straw man argument.[3][4] Considering the fact that all of the "independent" news outlets are no longer independent, Wikipedia and it's editors seriously need to consider expanding on what is considered to be a "reliable source". CosmicJacuzzi (talk) 06:34, 6 October 2021 (UTC)

When it comes to politics and events, our definition of neutrality amounts to presenting whatever the mainstream media and any formal academic sources say about the subject as being the primary and most important view of the subject. Obviously, it takes a while for academics to write books and peer-reviewed journal articles, so for events within the last year or so, we rely mostly on mainstream media. Following the mainstream and academic views is the definition of neutral on Wikipedia. It is explicitly against policy to treat all sides as being equally valid. I realize that this can be frustrating when people disagree with the mainstream view, but this is how it works on Wikipedia. WhatamIdoing (talk) 16:02, 6 October 2021 (UTC)

The "peer-reviewed journal articles" are a part of the mainstream media. If that wasn't the case, the examples I pointed out would exist and my point would be non-existent. It's an safe space of obvious lies, where people who disagree are labelled, yelled down, and silenced. I've seen the reprehensible behavior right here on Wikipedia. You bring it up on an Administrator's noticeboard, and a biased administrator jumps on it and just completely excuses obvious cases of outing. Followed by either of the involved administrators abusing either the sockpuppet, beating the dead horse, or fringe theories policies in order to justify a block. Want a good example of the echo chamber of lies? Take for example the "Haitian illegal immgrants 'being whipped'" incident. How that's being echoed by the White House, which is in turn being by the mainstream media. Every source that says anything to the contrary to the mainstream media is "misinformation/debunked/disputed/fake news/conspiracy theories". Whether that by journal articles by Conservative journalists, or Conservative news outlets. "Journals present the most recent research, and journal articles are written by experts, for experts."[5] All of those "experts" are leftists. If you're going to tell me I have an axe to grind, please go back to my top statement, and re-read the line about Fox news. CosmicJacuzzi (talk) 02:30, 7 October 2021 (UTC)

I feel that your problem is not with our sourcing policies but with a degree of gullibility. Jorm (talk) 02:34, 7 October 2021 (UTC)

The notion that peer-reviewed academic journals are part of the mainstream media is as bizarre as the notion that summarizing the mainstream media is a bad thing. Would you propose that we use fringe extremist media instead? Are you comfortable with the Revolutionary Communist Party and The Daily Stormer as sources for neutral encyclopedia articles? That's the path to madness and collapse. Cullen³²⁸ Let's discuss it 02:44, 7 October 2021 (UTC)

Surname not found

This really has nothing at all to do with the policies of the project, referring poster to other forums. — xaosflux ^Talk 17:02, 6 October 2021 (UTC)

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

---

There is an article on Rainsford Mowlem, but if you look for Mowlem, you don't get him. Could this be fixed?John Wheater (talk) 10:43, 6 October 2021 (UTC)

• @JohnWheater: this is not the correct venue for this type of help. Also, from a quick review I don't see any technical issues occurring. (A google search is able to find that article for example). You may use one of these forums for some general questions/help using Wikipedia: Wikipedia:Help desk, Wikipedia:Teahouse. — xaosflux ^Talk 17:02, 6 October 2021 (UTC)

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

Technical

Hatnote modules

I have always been too scared to ask this, but I can't stop wondering. Why do {{main}} and {{further}} use two different modules? Are they really that different in implementation that we needed two different modules for them?

Follow-up question which I suspect I have answers to but don't really, why do hatnotes even have modules? You would think a bit of text and some special formatting wouldn't require much work that couldn't be accomplished through conventional wikicode, but maybe these templates do something more that I just don't fully understand? –MJL ‐Talk‐^☖ 03:31, 30 September 2021 (UTC)

There does need to be a module somewhere along the track, to support the fact that templates can take an arbitrary number of parameters. As for why each hatnote template uses its own module, there's no good reason for it, and I tried to TfD the specific-template ones in 2018 and 2019 as part of a broader crusade against overuse of Lua, but ran in to a lack of consensus. * Pppery * _{it has begun...} 03:35, 30 September 2021 (UTC)

@MJL: Hi, I'm a major author of a lot of hatnote module code. {{Main}} needs a bit of special code to handle the case where it's used on category pages, where it has different output. If we could establish consensus to force category pages to use {{cat main}} or similar, and thereby removed the special case, then I'd happily transition {{main}} to use Module:Labelled list hatnote, which I wrote to standardize the behaviour of many simple hatnote templates. {{Nihiltres |talk |edits}} 21:46, 1 October 2021 (UTC)

@Nihiltres: If I understand it right, currently {{Main}} needs to act like {{cat main}} in category-space (which makes me wonder why we even have {{cat main}}..). If we switch {{main}} to Module:Labelled list hatnote, that needs to get changed. That seems reasonable, so I guess the question is where should we do that RFC? This is assuming that Module:Labelled list hatnote can't be changed to efficiently make {{main}} output something different in category-space without effecting {{further}}. –MJL ‐Talk‐^☖ 22:25, 1 October 2021 (UTC)

It was previously attempted by TfD, which … wasn't quite the right venue, but appears to be Pppery's favourite. I would start with a discussion on the talk pages of both (probably primarily on Template talk:Main with a message pointing people there from Template talk:Cat main) and solicit primarily objections. My expectation is that we'll get some grumbling about the status quo or leaving functionality in place, but that most people would agree that they should be separate templates and the current overlap removed by simplifying {{main}}. From there, getting rid of the "main" module in favour of the generic "labelled list hatnote" one becomes practically a G6 speedy, because a result for narrowing the template scope is nearly as good as a TfD for the module in practice. {{Nihiltres |talk |edits}} 06:39, 2 October 2021 (UTC)

@MJL: I've started a discussion at Template talk:Main as suggested in my previous comment. {{Nihiltres |talk |edits}} 17:04, 3 October 2021 (UTC)

Mapframe bug with references

I'm trying to use {{Mapframe}} here. However, when I click on the map, the text along the bottom turns into Map of Pomona College's campus[130][131] .mw-parser-output .div-col{margin-top:0.3em;column-width:30em}.mw-parser-output...

Additionally, when I try to add a reference to the |description= field for any of the markers, it spits out things like '"`UNIQ--ref-000000C1-QINU`"' (click on one of the teal icons in the northwest corner to see the issue).

Is whatever is causing these bugs a known issue? Is there any way around it? I was able to find a workaround for {{abbr}} by using <abbr title="Information Technology">IT</abbr> instead of {{abbr|IT|Information Technology}}, but I'm not sure if anything like that can be done for references, especially when they're SFNs. Help?

(I also have an additional mapframe question here if anyone here knows it well.) {{u|Sdkb}} ^talk 04:33, 30 September 2021 (UTC)

I recall there being a bug for the first one but I can't find it. I would recommend filing a new one under the Maps and TemplateStyles projects on Phab. It's not TemplateStyles fault, it's whatever lightbox implementation Maps are using not dealing gracefully with <style> elements and their contents, but tagging it for other just makes it obvious.

I'm not really surprised the second exists. In general, when you see a UNIQQINU pattern, it's a strip marker. Sometimes there's a limitation in the MW software can handle some input and sometimes we didn't code things properly on our side. That should start with a talk page message for the template/module to see if local template editors can see why that would be.

I don't really understand what issue you thought you had with the third that you "worked around". Izno (talk) 22:43, 1 October 2021 (UTC)

(Now that I look, I see one directly pertinent to the strip marker issue and <ref> specifically.) Izno (talk) 22:44, 1 October 2021 (UTC)

Okay, I created phab:T292598 for the first one. For the second, ɱ appears to be active at the module talk; would you perhaps be able to help? {{u|Sdkb}} ^talk 00:31, 6 October 2021 (UTC)

@Sdkb: - it seems that mapframe doesn't support inline references (except in captions, but you have the minor display issue at the bottom, like you mentioned). If I were you, I would move the map to its own page, like {{Ohio Statehouse map}} or {{George Floyd protests map}}, and there you can list out what is sourced for what, without dealing with display issues. Like how an image's file description page has attribution, same deal. ɱ (talk) 16:05, 6 October 2021 (UTC)

Reference desk introduction on mobile devices

When viewing a section of the Wikipedia Reference desk using a mobile device with a narrow screen, such as the page https://en.m.wikipedia.org/wiki/Wikipedia:Reference_desk/Language, the introductory parts (How can I get my question answered? / Select a section:) do not fit and can only be viewed and accessed by awkward horizontal scrolling. Is there a way to make this less awkward? (I suppose there is a way to make the page display adapt to the viewing device, but this is not my cup of tea.)  --Lambiam 08:21, 30 September 2021 (UTC)

I've created a sandbox version to work on improving this. —TheDJ (talk • contribs) 09:40, 30 September 2021 (UTC)

How about this version ? Its not too pretty, but it's a start. —TheDJ (talk • contribs) 14:38, 30 September 2021 (UTC)

I'm not getting any horizontal scrolling on my phone with that version, but there is a bit of horizontal overflow when using Firefox's responsive design mode with the iPad preset, which isn't present in the live version. I don't have a real iPad or anything with a similar screen size to test this, though. – Rummskartoffel 21:15, 30 September 2021 (UTC)

found it, was the input fields trying to be wider than possible. Thx for the report. —TheDJ (talk • contribs) 09:06, 1 October 2021 (UTC)

@TheDJ: Thanks. I can't test it on an iPad but it is fine on my phone. Can you install it? I could try but fear I'll muck up things in the process.  --Lambiam 22:37, 3 October 2021 (UTC)

i'll install it somewhere next week. I'm gonna need a bit of assistance in deploying it, because some parts are protected pages but i'll find someone for that. In the mean time, I also worked on Wikipedia:Reference desk, Wikipedia:Questions, Wikipedia:Village pump and Wikipedia:Community portal (in progress). —TheDJ (talk • contribs) 22:42, 3 October 2021 (UTC)

 Done —TheDJ (talk • contribs) 20:08, 5 October 2021 (UTC)

Authority control not showing up

Does anyone know why authority control isn't showing up at the bottom of Godric of Finchale's article? Best – Aza24 (talk) 21:55, 30 September 2021 (UTC)

Because the article's Wikidata item doesn't have any IDs that {{authority control}} knows about. * Pppery * _{it has begun...} 22:04, 30 September 2021 (UTC)

I just added the VIAF and GND to the associated Wikidata item, so the template appears now. Vahurzpu (talk) 20:24, 2 October 2021 (UTC)

Can't fully see UTCLiveClock gadget

I'm using a 13-inch macBook with latest version of macOS Big Sur. While using the newer look of the site, I see the live clock gadget pushed out by a tiny margin in the upper-right collapsible menu. To put this another way, I can see the hour hand and barely the minute hand but not the seconds hand. I'll provide an image if necessary. --George Ho (talk) 02:56, 1 October 2021 (UTC)

@George Ho: The hour, minute and second hands are three revolving pointers on an analog clock face. I guess you don't mean hands but the numbers on a digital clock. I guess "the newer look of the site" means you have disabled "Use Legacy Vector" at Special:Preferences#mw-prefsection-rendering. I see the problem with numbers there. It's caused by width: 6em in MediaWiki:Gadget-UTCLiveClock.css which is copied from mw:MediaWiki:Gadget-UTCLiveClock.css. PrimeHunter (talk) 03:40, 1 October 2021 (UTC)

Pinging Mr. Stradivarius who made the CSS in 2017. PrimeHunter (talk) 03:46, 1 October 2021 (UTC)

The below in your CSS is a temporary fix. It looks bad if "Use Legacy Vector" is enabled. PrimeHunter (talk) 03:57, 1 October 2021 (UTC)

.skin-vector #utcdate {
	width: 10em !important;
	margin-left: 0em !important;
}

I'll await Mr. S's response. Meanwhile, I found out that the same issue occurs on an iPad mini while using Desktop view. George Ho (talk) 05:29, 1 October 2021 (UTC)

The problem is not so much the CSS that I wrote, but rather that the UTC clock gadget never supported the newer Vector skin in the first place. It needs to be updated to support the new Vector (and also Minerva and Timeless, for that matter). There are some suggestions for how this might be done on the talk page. Also, it might be worth looking into the CSS solution that they are using on the Russian Wikipedia, which looks like it will alleviate some of the problems with calculating widths. — Mr. Stradivarius ^{♪ talk ♪} 03:32, 2 October 2021 (UTC)

Draft notice for redirects and other existing pages

If I attempt to create an article at a title like Cotesworth P. Smith, I get a notice above the edit box indicating that "There is a draft for this article at Draft:Cotesworth P. Smith". However, if I go to a title like Paint mixing (currently a redirect to Primary color) or Climate change in Pennsylvania (currently a redirect to Renewable energy law in Pennsylvania), I get no such notice about the existence of Draft:Paint mixing or Draft:Climate change in Pennsylvania. Similarly, if I go to edit a disambiguation page like Dramatization or War zone, I get no notice that Draft:Dramatization or Draft:War zone exist as possible WP:DABCONCEPT pages.

I am concerned that an editor who has the idea to write an article at a title currently serving as a redirect or holding a disambiguation page or the like may miss the existence of a working draft for this purpose. Can notices be added to the edit windows for existing pages where a draft exists? BD2412 T 03:27, 1 October 2021 (UTC)

@BD2412: Edit request filed at Template talk:Editnotices/Namespace/Main#Protected edit request on 1 October 2021, for making the message appear when the article is a redirect or disambiguation page. – SD0001 (talk) 06:29, 1 October 2021 (UTC)

Excellent, thanks. BD2412 T 03:09, 3 October 2021 (UTC)

Removing "Publish changes" and the rest

Hi. Is there a way to remove all of those buttons by using js/css? Hộp cát (talk) 05:17, 1 October 2021 (UTC)

@Hộp cát: To hide the buttons only (not the adjacent text or links), use

#wpSaveWidget,
#wpPreviewWidget,
#wpDiffWidget {
  display: none;
}

in Special:MyPage/common.css. You can still activate the buttons by using Alt+⇧ Shift+S, Alt+⇧ Shift+P or Alt+⇧ Shift+V respectively. --Redrose64 🌹 (talk) 09:23, 1 October 2021 (UTC)

Nice, thanks. Hộp cát (talk) 10:37, 1 October 2021 (UTC)

@Hộp cát, why do you want to do that? Whatamidoing (WMF) (talk) 20:57, 5 October 2021 (UTC)

Template:skip to top and bottom

When I noticed a bug elsewhere, Xaosflux suggested I take notice if I see others and approach the developer directly; I can't see any such (one) developer for this Template. The problem is it doesn't go all the way to the top. As someone mentioned recently, it's used on The Teahouse and the Template wiki-page itself. It misses the top two lines of visible text (on 16:9 display at 100%). Thanks.--Rocknrollmancer (talk) 00:34, 2 October 2021 (UTC)

That seems impossible without making it skin/interface-dependent. I just compared all elements that are at the top and have IDs in Legacy Vector and mobile view, and there was no overlap. Nardog (talk) 02:07, 2 October 2021 (UTC)

I guess I gotta wonder why anyone would use that template. Each time I click to go to the other end of a page that uses that template it adds an entry into the browser's history so if I click the up or down several times and then use the browser's back button to get back to where I started, I get the entire sequence played in reverse. Doesn't seem like the best or most friendly user interface to me...

—Trappist the monk (talk) 14:32, 2 October 2021 (UTC)

Hiding the "Languages" sidebar section

Resolved

span.editHelp { display:none; } #editpage-copywarn { display:none; } div.mw-tos-summary { display:none; } #editpage-copywarn2 { display:none; } span#minoredit_helplink { display:none; } span.mw-newpages-length { display:none; } #pt-betafeatures, #p-navigation, #footer-info, #footer-places, #footer-icons {display: none;}

I have this set on my common.css page. What I would like to do is add the sidebar section "Languages" also. Thanx in advance :) - FlightTime Phone (open channel) 03:51, 2 October 2021 (UTC)

@FlightTime Phone: seems to be:

#p-lang {
    display: none;
}

— xaosflux ^Talk 09:32, 3 October 2021 (UTC)

@Xaosflux: Thank you, seems to work just fine. Again thank you, - FlightTime (open channel) 17:31, 3 October 2021 (UTC)

@FlightTime, why do you want to do that? Whatamidoing (WMF) (talk) 20:59, 5 October 2021 (UTC)

@Whatamidoing (WMF): There are a number of userscripts posted below that sidebar section, I would have to scroll past the "Language" section to get to the links of the scripts, I would collapse it (cause I'm using Vector), but the section would not stay collapsed, so I thought if I could hide it using .css, I wouldn't have to keep re-setting it. - FlightTime (open channel) 21:07, 5 October 2021 (UTC)

It sounds like you want the sidebar to contain links to some scripts, and for those to be convenient to reach. I believe there is a way to insert your links into a specific section. Then your links would be higher up, with no scrolling required. Gadgets such as Wikipedia:Prosesize do this. Whatamidoing (WMF) (talk) 15:24, 6 October 2021 (UTC)

Maintenance template mobile view

Maintenace templates are shown below infobox and they shouldn't why shouldn't user know more citation are needed bi (talk) 05:49, 2 October 2021 (UTC)

@Baratiiman: is this a technical issue? What makes you think the display order is technically incorrect? If this feedback on layout style you could follow up Wikipedia talk:Manual of Style/Layout. — xaosflux ^Talk 09:34, 3 October 2021 (UTC)

List of external URLs on a page

Does there exist a relatively easy way, such as a tool, to list all the external URLs on a page? ie. outbound http(s) links that are not Wikipedia. -- GreenC 06:38, 2 October 2021 (UTC)

You could use the API. A list of urls is obtained with this code which gets the eternal links on the lion page. It includes all the links in citations, so I'm not sure if this gets what you wanted. —  Jts1882 | talk  07:11, 2 October 2021 (UTC)

@Jts1882: thank you very much. -- GreenC 16:40, 2 October 2021 (UTC)

doi citation tool down

I've being using http://reftag.appspot.com/doiweb.py to generate {{cite journal}} citations from a doi for several years. The tool is down for the last couple of weeks and giving the following error message: "Error: Server Error. The server encountered an error and could not complete your request. Please try again in 30 seconds." Does anyone know if this tool has been replaced, moved or what to do to get it working again? —  Jts1882 | talk  06:54, 2 October 2021 (UTC)

No idea about the status of that specific tool, but see WP:REFTOOLBAR or WP:UCB/User:Headbomb/Tips and tricks for alternatives. Headbomb {t · c · p · b} 13:28, 2 October 2021 (UTC)

I have both Reftools and citation expander activated, but haven't used them much. Now I see how the two together do what I want, reftools to create a minimal citation with just the doi and citation expander to complete the job. —  Jts1882 | talk  14:41, 2 October 2021 (UTC)

DOI is also accepted as an input in citer.toolforge.org. Links to this tool should be changed to something else, this issue has been reported several times allready.--Snævar (talk) 09:22, 4 October 2021 (UTC)

You will need to contact the creator, who I believe is Apoc2400. Izno (talk) 14:18, 2 October 2021 (UTC)

Apoc2400 has only one edit in the last year so seems to be inactive now. It was a very useful tool that I've used a lot. —  Jts1882 | talk  14:41, 2 October 2021 (UTC)

As you can see from the talk page, this was reported some time ago. I do not think further discussion here will be useful. Izno (talk) 16:02, 2 October 2021 (UTC)

See also Wikipedia:User scripts/Requests § restore the Wikipedia Citation Tool for Google Books. – Rummskartoffel 21:15, 2 October 2021 (UTC)

I see that Wikipedia DOI and Google Books Citation Maker has just been added to Help:Citation Style 1 by Medgirl131. That does the doi bit like the old tool. —  Jts1882 | talk  08:17, 4 October 2021 (UTC)

That's a big help; can someone with javascript skills please create a bit of code that will add a link to citation-maker to the left sidebar, under section 'Tools', the way User:PrimeHunter/Source links.js does? Second choice, add a link just above the Edit summary field in Preview mode, the way User:Anomie/unsignedhelper.js does. If you can do this, I love you. Or, you get a barnstar; your choice . (please {{reply to}} on reply; thanks!) Mathglot (talk) 17:04, 4 October 2021 (UTC)

(Hopefully)  Done @Mathglot - see User:Qwerfjkl/scripts/generatedoi. ― Qwerfjkltalk 17:55, 4 October 2021 (UTC)

@Qwerfjkl: thanks! Further comments at User talk:Qwerfjkl/scripts/generatedoi#Install methods. Mathglot (talk) 18:20, 4 October 2021 (UTC)

Spellcheck issue

I have a new laptop running Windows 10. My issue, is the spellcheck doesn't recognize a pipe ( | ) or a colon ( : ) in Wikilinks, as seen in this screenshot. I have no idea why it's like that, I don't think I changed any of those settings and hope there's a way to fix it. - FlightTime (open channel) 23:37, 2 October 2021 (UTC)

Wikipedia has no spell checker. It's done by your browser. Do you use Microsoft Edge? I see it there and haven't found a way to tell it that pipe and colon should be treated as word separators. PrimeHunter (talk) 02:49, 3 October 2021 (UTC)

@PrimeHunter: I'm using Chrome. I just found a spellcheck, grammar check...ect app Microsoft Editor: Spelling & Grammar Checker I'll disable the browser check and use the app and see how that goes. Thank you very much for your time. — Preceding unsigned comment added by FlightTime (talk • contribs) 03:02, 3 October 2021 (UTC)

Watching if a bot is live with in-wp notifications?

TL;DR: I want to get a notification (ideally, a ping or talk page notice, but an email would be ok) whenever Special:Contributions/Muninnbot has no recent edits in the last day (or maybe the last 30h). Is there an easy way to make this happen?

I am the maintainer of Muninnbot. That bot is set up to check some unit tests before firing notifications, so that (hopefully) changes in the MediaWiki API or PyWikiBot stop the bot from sending any notifications rather than sending malformed notifications.

The bot broke back in March (due to a breaking change in PyWikiBot, but the stability of PyWikiBot is a topic for another place). I did not notice it until GoingBatty found out about it last week, so the bot has been broken for about half a year (hopefully it's back up now, I will check after the next cron run). This has been the second breakage in (slightly more) than three years of operation of the bot, so while it is not exactly frequent, I still would like a better mechanism to detect this than having a human check Special:Contributions/Muninnbot or the talk pages of newbies.

I can imagine two ways of doing this, but either of them requires some work:

1. make Muninnbot send me a notification (how?) when the tests fail (right now, when tests fail, a message goes into the logs, but I am not reading the logs on Toolforge unless I already know something is wrong)
2. have a second bot read the page Special:Contributions/Muninnbot and post me a talk page message whenever there has not been any new contributions in a while (I could code this, but it is a bit of work)

Has something similar already been done? I can easily imagine similar requests, for instance anti-vandal fighters could want to watchlist a user's contributions, so that an account that vandalizes, gets a level-4 warning, then sleeps for two months is detected as soon as it wakes up. Tigraan^{Click here for my talk page ("private" contact)} 14:54, 3 October 2021 (UTC)

@Tigraan Try Wikipedia:Bot activity monitor. – SD0001 (talk) 14:55, 3 October 2021 (UTC)

Resolved

I must say, of all the questions I have asked during my time on Wikipedia, none has been asked with as little hope, answered with as much haste, or resolved so fully. Tigraan^{Click here for my talk page ("private" contact)} 15:06, 3 October 2021 (UTC)

Failure of section collapse mechanism in mobile view provoked by excessive templates/images

On mobile view (using en.m.wikipedia.org) long pages typically have section collapse arrows (^ pointing up for an expanded section, v pointing down for collapsed). This appears to be broken on some pages, such as List of professional sports families. Narrowing down the issue, this version is broken while the next edit, just removing a {{JAP}} template, fixes it. The difference is in 1009 vs 1008 total templates.
For a more artificial test case, 1001 copies of {{BEL}} causes the issue, while 1000 (next revision) is fine. It looks like a template issue, though something must account for the difference of 8 templates between the page when it was full of things (1008 templates ok), vs my artificial test case (1000 templates ok).

Another, even simpler test case: 1001x {{aye}} is broken, while the next revision (1000x) is ok.

I think it's really just an images issue. 1001 of the green ticks (directly substituted from {{aye}}) is broken, while again, the next version, with 1000 of them, works. – Anon423 (talk) 15:44, 3 October 2021 (UTC)

mediawikiwiki:Recommendations for mobile friendly articles on Wikimedia wikis#Limit number of images in a page has some background for what's going on. It is indeed related to the number of images. I am surprised it is breaking at 1k rather than the specified 10k. Jon (WMF) might know/care more. Izno (talk) 16:01, 3 October 2021 (UTC)

Could then the page be fixed by altering/replacing the flag templates to use unicode emoji flags instead? Your mediawikiwiki link suggests so, and MOS:FLAGS does not explicitly proscribe unicode flag emoji as an alternative. – Anon423 (talk) 22:06, 3 October 2021 (UTC)

I think that is a question for those pages' talk pages. Izno (talk) 22:17, 3 October 2021 (UTC)

It's indeed limited to 1000 images by this in https://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php:

'wgMFMobileFormatterOptions' => [
	'default' => [
		'excludeNamespaces' => [ 10, -1 ],
		'maxImages' => 1000,
		'maxHeadings' => 4000,
		'headings' => [ 'h1', 'h2', 'h3', 'h4', 'h5', 'h6' ]
	],
	'wikivoyage' => [
		'excludeNamespaces' => [ 10, -1 ],
		'maxImages' => 1000,
		'maxHeadings' => 4000,
		'headings' => [ 'h2', 'h3', 'h4', 'h5', 'h6' ] //T110436, T110837
	],
],

It was done after phab:T232690. phab:T248796 requests feedback to editors about it. PrimeHunter (talk) 16:16, 3 October 2021 (UTC)

Is there an easy way to find out how many pages this affects? Izno's mediawikiwiki link suggests a JavaScript command that counts the images, but that's hardly a global view. – Anon423 (talk) 03:00, 4 October 2021 (UTC)

That would be the phab:T248796 link that PrimeHunter provided. Izno (talk) 04:02, 4 October 2021 (UTC)

The typical way would be an automatic tracking category at Special:TrackingCategories. I don't know whether the problem is discovered at a time and place where a tracking category could be added. PrimeHunter (talk) 04:35, 4 October 2021 (UTC)

In the meantime, I have listed pages in mainspace which have this issue in quarry:query/4320. The first field is the page title, the second is the number of image links.--Snævar (talk) 09:30, 4 October 2021 (UTC)

Maybe it's a real use for presently TFDd {{too many images}}. Izno (talk) 14:15, 4 October 2021 (UTC)

Thanks. However, is there a particular reason why the query doesn't find List of professional sports families, which is known to have the issue? It seems to be finding pages with 1000 or more distinct images. – Anon423 (talk) 14:43, 4 October 2021 (UTC)

Excuse my lack of comprehension, but I don't quite see a way to find affected pages mentioned in that Phabricator thread. It seems the currently-unpublished suggested patch by BrandonXLF would only embed an HTML comment (or with Jdlrobson's comment, a hidden HTML span). I don't think that would be searchable, or would it? – Anon423 (talk) 15:23, 4 October 2021 (UTC)

Perhaps you should give feedback on the discussion such that a tracking category is added in the vein of those already in Special:TrackingCategories, as mentioned above. ;) Izno (talk) 16:13, 4 October 2021 (UTC)

Geohack Google maps display

This is a small issue, but I don't find it in the archives. Why, when I look at Google maps from the coordinates given in an article, via the Geohack page, do I see a double location marker thingie as of (IIRC) a month or so ago? My most recent experience of this is Bodega Bay, California; I checked that there is only one coordinates template on the page. I don't see this behavior either when I type in a different small settlement directly in Google maps or when I select a different mapping service or three at Geohack. (I'm using Firefox, but it doesn't seem to matter; I get the same thing in Chrome.) Yngvadottir (talk) 23:05, 3 October 2021 (UTC)

File:Focus of Bedford Park Garden Suburb.svg

Resolved

 – The specific issue with this SVG file was made by adjusting the file, the root cause upstream will continue to be tracked in phab. — xaosflux ^Talk 20:59, 4 October 2021 (UTC)

Tracked in Phabricator
Task T292439

There seems to be an issue displaying this image in the media viewer. The error message said "Error: could not load image from https://commons.wikimedia.org/wiki/File:Focus_of_Bedford_Park_Garden_Suburb.svg". The image looks fine when reading the article, and it works fine both when editing in Inkscape and when viewing it locally using Firefox (i.e. not via Wikipedia), so it seems to be specific to the media viewer. I've tried adjusting the image without success. Could start again and redraw it but presumably there's something in the .SVG file that the viewer doesn't like? Chiswick Chap (talk) 10:34, 4 October 2021 (UTC)

• Note, this is not a media-viewer specific issue, having a problem viewing at all resolutions (e.g. 313px example). — xaosflux ^Talk 10:49, 4 October 2021 (UTC)
  • Possibly phab:T200866 - while not ideal, @Chiswick Chap: you may want to upload an additional non-SVG version of the image for now if this is holding you up from improving an article here. — xaosflux ^Talk 10:53, 4 October 2021 (UTC)
    • Many thanks. I'll see if I can rustle something up temporarily. Chiswick Chap (talk) 10:56, 4 October 2021 (UTC)
      • I've put a .PNG file there temporarily. Feel free to ping me if the issue is fixed. Chiswick Chap (talk) 13:26, 4 October 2021 (UTC)

@Chiswick Chap: You distorted the pattern too much: patternTransform="matrix(-.00444 6.6367 -2620.7 22.904 44653 549.3)".  — Johannes Kalliauer - contrib. 18:10, 4 October 2021 (UTC)

@Xaosflux: It occurs immediately, therefore it crashes, no time-out.  — Johannes Kalliauer - contrib. 18:10, 4 October 2021 (UTC)

@Chiswick Chap: the new version JoKalliauer uploaded seems to be working. — xaosflux ^Talk 19:06, 4 October 2021 (UTC)

Thanks guys, both quick and precise, great help! Chiswick Chap (talk) 19:48, 4 October 2021 (UTC)

AWB network error

For the last few days, every time I try to run WP:AWB it tells me:

Network access error
The operation has timed out

I'm running AWB v6.2.1.0 on Windows 7, and nothing has changed on my system, as far as I know. Checking my contributions I can see that the last time I used AWB successfully was 2021-09-30. Is there a problem at the Wikipedia end? Mitch Ames (talk) 12:32, 4 October 2021 (UTC)

Sounds like the lets encrypt problem. Your client cannot connect, because the root certificate has expired and it doesn't know about the new root certificate most likely. —TheDJ (talk • contribs) 12:52, 4 October 2021 (UTC)

That seems likely. I'll add the Windows certificate and try again. Mitch Ames (talk) 13:32, 4 October 2021 (UTC)

I wanted to test the process before changing anything on my real PC, so I started up a virtual machine with a clean installation of Windows 7 SP-2 (from the DVD) with no additional updates or software, to see if I could reproduce the problem. I installed .NET 4.5.2, copied ABW and ran it - and it works fine, allowing me to login. The certificate manager says that DST Root CA X3 (which expired 2021-09-30) is not present at all on the clean VM. It is present on my real PC (where AWB does not work). I presume that DST Root CA X3 was installed by some piece of software that I installed in the past. (I have fairly detailed notes on changes I've made to the system, including MicRooCerAut2011_2011_03_22, per [6], so I'm confident I'd know if I'd manually installed DST Root CA X3.) So I installed DST Root CA X3 onto the VM - and AWB still works.

I could just remove DST Root CA X3 from the real PC to see if that fixes the problem, but I'd rather understand what's going on first.

Does anybody have any other ideas, or shall I just raise a Phabricator ticket? Mitch Ames (talk) 13:14, 5 October 2021 (UTC)

Deleting %LOCALAPPDATA%\AutoWikiBrowser, %USERPROFILE%\Documents\AWB and HKEY_CURRENT_USER\Software\AutoWikiBrowser does not fix the problem. Mitch Ames (talk) 13:47, 5 October 2021 (UTC)

See also: Wikipedia_talk:AutoWikiBrowser#AWB_stopped_working_on_one_PC. Mitch Ames (talk) 12:48, 6 October 2021 (UTC)

Pseudo-telephone numbers

Hi techies. There's something out there that turns perfectly-valid number ranges - such as page numbers in references - into things that are apparently intended to be interpreted as telephone numbers. This is the search that I'm using, and here is an example which I've since fixed, but I know that CycoMa (talk · contribs) is not the only person who makes that error. The tags to that edit are "Mobile edit Mobile web edit Visual edit Advanced mobile edit", so is it a bug in one of these features, or a misbehaving browser add-on? If the latter, is it worth putting an edit filter together for that? --Redrose64 🌹 (talk) 14:04, 4 October 2021 (UTC)

You participated in the discussion we had about it. Izno (talk) 14:19, 4 October 2021 (UTC)

The ticket for the remaining problems of this is phab:T116525. Apparently in some conditions iOS still auto formats those links and we don't fully understand how (I suspect it's somewhere in a out of document context where we handle some VE actions or something vague like that). —TheDJ (talk • contribs) 14:25, 4 October 2021 (UTC)

I forgot about that. But it seems to concern numbers formatted like 999-9999 and in my example the format is different - the page range is "184/185 – 253/254". --Redrose64 🌹 (talk) 14:31, 4 October 2021 (UTC)

(edit conflict) @Redrose64: the flags recorded in Special:AbuseFilter/examine/1427973382 mobile app (user_app):false; mobile interface (user_mobile):true suggest this was made using the mobile web site, not the mobile app - so I suspect this was introduced client-side, somewhat related to phab:T116525. If CycoMa would like to share their browser version with us we may have a bit more to go on. — xaosflux ^Talk 14:23, 4 October 2021 (UTC)

This edit suggests that if it is local, it's VE, not Mobile. --Redrose64 🌹 (talk) 19:47, 4 October 2021 (UTC)

VE desktop can still be done from a mobile device though. I guess it could be that other systems also do this auto formatting, but so far, I only know about iOS and the Skype extension doing this like this. —TheDJ (talk • contribs) 12:58, 5 October 2021 (UTC)

Autofill for citations not working

Discussion about topic already talked about here: https://phabricator.wikimedia.org/T292267. Said to come here for it.

--Apollo468 (talk) 15:29, 4 October 2021 (UTC)

Since I can not reproduce, on win10, edge 94, could you open up the tree dots in the top right corner, then more tools - developer tools - network (opens to the right), then try to add an autofilled citation, write down what messages you get in the network and console tabs and post it here, thanks. It would tell what the tool is doing and whether the browser understands it.--Snævar (talk) 07:46, 5 October 2021 (UTC)

Tech News: 2021-40

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

• A more efficient way of sending changes from Wikidata to Wikimedia wikis that show them has been enabled for the following 10 wikis: mediawiki.org, the Italian, Catalan, Hebrew and Vietnamese Wikipedias, French Wikisource, and English Wikivoygage, Wikibooks, Wiktionary and Wikinews. If you notice anything strange about how changes from Wikidata appear in recent changes or your watchlist on those wikis you can let the developers know.

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 5 October. It will be on non-Wikipedia wikis and some Wikipedias from 6 October. It will be on all wikis from 7 October (calendar).
• Some gadgets and bots that use the API to read the AbuseFilter log might break. The hidden property will no longer say an entry is implicit for unsuppressed log entries about suppressed edits. If your bot needs to know this, do a separate revision query. Additionally, the property will have the value false for visible entries; previously, it wasn't included in the response. [7]
• A more efficient way of sending changes from Wikidata to Wikimedia wikis that show them will be enabled for all production wikis. If you notice anything strange about how changes from Wikidata appear in recent changes or your watchlist you can let the developers know.

Future changes

• You can soon get cross-wiki notifications in the iOS Wikipedia app. You can also get notifications as push notifications. More notification updates will follow in later versions. [8]
• The JavaScript variables wgExtraSignatureNamespaces, wgLegalTitleChars, and wgIllegalFileChars will soon be removed from mw.config. These are not part of the "stable" variables available for use in wiki JavaScript. [9]
• The JavaScript variables wgCookiePrefix, wgCookieDomain, wgCookiePath, and wgCookieExpiration will soon be removed from mw.config. Scripts should instead use mw.cookie from the "mediawiki.cookie" module. [10]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

16:28, 4 October 2021 (UTC)

Why is there a Lilypond error on this page?

Resolved

 – zhwiki fixed their module. — xaosflux ^Talk 17:00, 5 October 2021 (UTC)

Hi, just wondering why this page on Chinese Wikipedia has a Lilypond error when I can't see any Lilypond scores in the source. Is it being included from somewhere and where can I check it? (Error: "line 5 - column 1: bad grob property path (Staff.Clef stencil), line 6 - column 1: bad grob property path (Staff.TimeSignature stencil)") thanks. A1415 (talk) 16:15, 3 October 2021 (UTC)

• Haven't solved it yet, but comparing w:en:User:Xaosflux/sandbox112 and w:zh:User:Xaosflux/沙盒 suggests that it is something in w:zh:模組:Listen. — xaosflux ^Talk 10:55, 5 October 2021 (UTC)
  • Confirmed it is in the module and not some other project-local setting.... — xaosflux ^Talk 10:57, 5 October 2021 (UTC)
    • @A1415: Perhaps User:Great Brightstar who introduced a custom midi handler to the zhwiki version of the module can help on this. — xaosflux ^Talk 11:01, 5 October 2021 (UTC)
      • When I loaded the zhwiki module to our sandbox, I get the same problem- but only on midi files, see User:Xaosflux/sandbox112. — xaosflux ^Talk 11:05, 5 October 2021 (UTC)

The source code used in Chinese Wikipedia was ported by myself, just with minor changes for translation, when English Wikipedia used the same code base for rendering MIDI audio. As the server is now able to converting MIDI directly without any workarounds, I think it's resonable to update source code in there. --Great Brightstar (talk)

@Great Brightstar: thank you for the update, @A1415: seems like this is something you can fix at w:zh:模組:Listen, and you can use Module:Listen as a reference. zhwiki has applied protection such that only their administrators can update that module. — xaosflux ^Talk 15:39, 5 October 2021 (UTC)

It's fixed now. @A1415: Thanks for your digging up. --Great Brightstar (talk) 15:47, 5 October 2021 (UTC)

I also introduced a TemplateStyle in that module, which used to improve the display of this template for mobile phone screen, which affects the grey line. Anyone who have rights to edit the mudule could port it to here. --Great Brightstar (talk) 16:28, 5 October 2021 (UTC)

That should not be ported here. As you have been told before, making piece-part changes here and there is not the solution, and especially if it's tweaking CSS display. Izno (talk) 16:46, 5 October 2021 (UTC)

As a general debugging tip for the future, you can use Special:ExpandTemplates to find the underlying <score> tag and the markup that's being passed to it. Legoktm (talk) 17:48, 6 October 2021 (UTC)

Basic pywikibot question

Back in 2010-2011 I used to run pywikibot a lot on various projects (perhaps never en.wikipedia). After I stopped doing this, the source code moved from SVN to Git and things started to changes names in a way that I didn't care to catch up with. Now I'm trying again, and I find various instructions that conflict each other. The instruction I followed was to download the software with the "pip install pywikibot" command. This got me some source code and the files say they are from 2021, so this should be up to date. But it doesn't run, since the file logging.py says "from logging import CRITICAL, ..." and this is a circular reference. This appears seriously broken. Is that the state of pywikibot source code nowadays? Is anybody fixing it? On this page, I'm informed that there's a mailing list, but it has seen only one message in August and two in September, which is very little. Is the project dead? Where should I look? Which other bot software should I use instead? --LA2 (talk) 12:31, 5 October 2021 (UTC)

Ticket management and activity of pywikibot is tracked in Phabricator. See https://phabricator.wikimedia.org/project/profile/87/ —TheDJ (talk • contribs) 12:56, 5 October 2021 (UTC)

Yes, but the kind of error I experienced was beyond the level where a ticket can fix it, like beating a horse that is apparently already dead. Now I tried instead to download the tar archive. It works. What the "pip install pywikibot" did was download the pywikibot/ subdirectory of the whole project, which is called "core-stable". I have no idea why there is a command for downloading just that subdirectory. It's not useful. Maybe I should write a ticket that the instructions are wrong. If I knew what the right instructions were, I would just update that wiki page. --LA2 (talk) 13:22, 5 October 2021 (UTC)

Installing pywikibot requires more than python nowadays. See phab:diffusion/PWBC/browse/requirements.txt for an list of required software packages. Sure the docs could be better.--Snævar (talk) 15:07, 5 October 2021 (UTC)

Do not use SVN or Git. Installing Python 3 (not 2) and running 'pip install pywikibot' is all that is required. Try 'pip list --outdated' and fix any problems shown. To update a package called xxx use 'pip install --upgrade xxx' (for example, xxx = pywikibot). Johnuniq (talk) 22:16, 5 October 2021 (UTC)

Edit causing ref errors

Here, the edit by my bot has apparently caused empty ref errors. Any idea why? ― Qwerfjkltalk 15:25, 5 October 2021 (UTC)

@Qwerfjkl: can you provide a diff? — xaosflux ^Talk 15:39, 5 October 2021 (UTC)

Diff. I have posted a query at Template talk:efn. – Jonesey95 (talk) 16:00, 5 October 2021 (UTC)

The problem was caused by the = sign inside the span tag within the {{efn}} template. The workaround/fix is to put |1= in front of the unnamed parameter of {{efn}}. – Jonesey95 (talk) 17:34, 5 October 2021 (UTC)

ai making disambiguation pages

disambiguation pages are the main navigation tool so why are n't they automatically genereted by software bi (talk) 15:51, 5 October 2021 (UTC)

Talk Page/User Page

Hello,

It was brought up on my talk page that the format isn't very mobile user friendly. I'm trying to correct this as I really don't want it to be such a pain for a user to be able to view my pages. I'm not even sure if this is the right location for this but it was suggested to ring it up here. I don't want to lose as much of my formatting as possible but I don't mind sacrificing a little if it means a more user friendly page. Any assistance would be most grateful. I'm not great at formatting so I am sure I made a ton of mistakes but since I don't use a mobile device other than my tablet I cant see what they see. Tank you for not throwing me out right away. --ARoseWolf 17:35, 5 October 2021 (UTC)

@ARoseWolf: look at them like this: Your Mobile Userpage and Your Mobile Talkpage - and try making your window narrow to see what it will look like for others. Your talk page will also appear mostly blank to mobile users because of phab:T241402 - so you might want to design around that. — xaosflux ^Talk 18:40, 5 October 2021 (UTC)

(edit conflict)I fixed a bunch of syntax errors on the page, but I don't know enough about mobile view to know what it is supposed to look like. When I click "Read as wiki page", I can see the page just fine. I do notice that the normal mobile TOC (under "Active discussions") is not listed in mobile view, at least for me, possibly because it is placed in a custom location on the page. Maybe there's a phab task about this? I hear that a lot of people use mobile, but I don't see how it is really functional for active editors. – Jonesey95 (talk) 18:47, 5 October 2021 (UTC)

Thank you both. I sincerely want to get it right. No one should have to scroll around when looking at the page and I don't want that. --ARoseWolf 18:57, 5 October 2021 (UTC)

Just now, I made your talk page a bit more boring in order to make it work in mobile view. You are welcome to revert my change if you do not like it, but the mobile problems will persist. – Jonesey95 (talk) 19:14, 5 October 2021 (UTC)

File's old versions

Hello. DeltaQuadBot has stopped hiding old versions of my files. I reached out to its owner (User talk:AmandaNP#DeltaQuadBot) and she found out that the problem is not in the bot, but in the category. Category is empty. But my files (for example: File:Paseo (film).jpg, File:Prince's Tale.jpg, File:Souls of Totality.jpg) must be in this category. What could be the problem? — Vladlen Manilov ✉ / 04:19, 6 October 2021 (UTC)

I find it even more concerning that there might be almost 2,000 files sitting because it's not coming up in the category. I proposed here might be a better place to try and resolve this as it's not a bot issue. -- Amanda (aka DQ) 04:23, 6 October 2021 (UTC)

The problem seems to be that Category:Non-free files with orphaned versions more than 7 days old isn't added to the pages in an edit, but by {{Orphaned non-free revisions}} based on date, so if the template is placed before the revisions are a week old, the category isn't updated. Null-editing the file propagates the change, but manual null-edits aren't exactly the fix for an automatic task. Maybe DeltaQuadBot could instead operate on Category:Non-free files with orphaned versions and check the dates itself? – Rummskartoffel 10:40, 6 October 2021 (UTC)

That would require a large write in the code, which i'm not going to lie, is not what I want to do. I'm sure though that my bot wouldn't be the only one affected by this. So i'm not sure a small fix is really the optimal solution here. It used to work perfectly, so I'm assuming that this was a change, and if so, some back porting should have been done to allow them to change categories. -- Amanda (aka DQ) 18:39, 6 October 2021 (UTC)

There is an bug for this issue at phab:T51803, when it gets fixed it would populate the category based on the #time parser function in the template, so 7 days after the last edit. Currently the files will end up in the category 1 month after the last edit, so 3 weeks later than they should.--Snævar (talk) 23:28, 6 October 2021 (UTC)

Where did my "reply link" go?

A while ago I installed a script that adds a "reply" link to the end of signatures that very conveniently opens an edit window with the appropriate indent and a ping already set. It suddenly stopped working a few days ago. See line 30 of my common.js . If this script is no longer functional, is there an alternative that works similarly? I've become rather used to it. Roger (Dodger67) (talk) 06:29, 6 October 2021 (UTC)

@Dodger67: It's deprecated. The alternatives are DiscussionTools (enable from Special:Preferences#mw-prefsection-betafeatures) or Convenient Discussions. – SD0001 (talk) 06:35, 6 October 2021 (UTC)

Thanks Roger (Dodger67) (talk) 06:49, 6 October 2021 (UTC)

Updated Commons image displays strangely in en-wiki, correctly in most other Wikipedias

I'm seeing a strange problem with an image recently updated in Commons and showing up strangely at English Wikipedia, but fine in most others. It appears like this in the article Philippe_Pétain.

After a request at the Wikipedia:Graphics Lab/Photography workshop, a new version of File:Foch Pershing Petain and Haig.jpg was uploaded. It has better contrast and brightness, and an aspect ratio closer to landscape, where the original one was a darker version in portrait mode.

The new image is showing up correctly in articles in Norwegian, Italian, Basque, and Czech Wikipedias. And to my surprise, correctly above right.

But the old image is still showing up, but stretched out of shape to match the aspect ratio of the new image in the article Philippe_Pétain in en-wiki, and also in articles at Esperanto and Serbian Wikipedias, and in the top image in Commons. I tried purging pages, no help. What's going on here? Mathglot (talk) 08:43, 6 October 2021 (UTC)

I checked with another browser, and the en-wiki image shifted to the new one, but Serbia didn't, and then switched later. Could this be some strange browser cache issue? Tried a third browser, and everything displayed the new image. Switched back to the first browser, which originally had the problems, but now everything is working. Some combination of delayed updates, and cache issues? Anyway, whatever it was, it's gone now. Mathglot (talk) 08:50, 6 October 2021 (UTC)

Damn, it came back again! At Philippe_Pétain#End of war, and at the en-wiki file page, at File:Foch Pershing Petain and Haig.jpg. I give up. Mathglot (talk) 08:54, 6 October 2021 (UTC)

@Mathglot Try WP:BYPASS, it worked for me with a similar problem. Gråbergs Gråa Sång (talk) 08:55, 6 October 2021 (UTC)

Thanks, I'll try that. Mathglot (talk) 08:57, 6 October 2021 (UTC)

Article is both draft and start class

Hello! So I recently created the article Splatoon 3 which was copy and paste moved from Draft space by Panini and then properly moved by GeneralNotability. It's currently rated as start class, however XTool's page history of Splatoon 3 says it's Draft class. I looked at the article and I couldn't see any draft related category. Anyone know why XTools still doesn't say it's Start class? ― Blaze The Wolf^Talk_{Blaze Wolf#6545} 14:57, 6 October 2021 (UTC)

•  Works for me https://xtools.wmflabs.org/articleinfo/en.wikipedia.org/Splatoon_3 says "start class" when I look at it. Keep in mind, xtools works off of a replica, so may be delayed - and class ratings aren't actually part of the article at all - they are just notes on the talk page. — xaosflux ^Talk 15:27, 6 October 2021 (UTC)

• XTools gets assessment data from Special:PageAssessments, which indeed still had it listed as "Draft". I made a null edit and that fixed it [11]. I'm not entirely sure what happened here; it seems Draft talk:Splatoon 3 and Talk:Splatoon 3 both coexisted at the same time. Perhaps because the talk pages weren't moved, no update to the templates on those pages was triggered. At any rate, if you see this happen again, a null edit (or actual edit) should fix it. — MusikAnimal ^talk 15:28, 6 October 2021 (UTC)
  • So maybe ignore the part I said about the replicas, if this is live-loading, but it could still hit caching/job log backlogs. — xaosflux ^Talk 15:31, 6 October 2021 (UTC)
    • mw:Extension:PageAssessments just to note for future reading if this is found in the archives. — xaosflux ^Talk 15:32, 6 October 2021 (UTC)

      No, it's true XTools can suffer from replication lag (in addition to job queue lag), but you would see a warning at the top of the XTools page if that were the case. You can also check toolforge:replag. You just happened to check XTools after I made the null edit. At any rate, Special:PageAssessments is the authoritative source. If XTools says something different, it's lying. — MusikAnimal ^talk 15:35, 6 October 2021 (UTC)

      Ah ok. I'll see if I can move the Draft's talk page to the Article space talk page since a copy and paste move was performed and see if that fixes it, or if it's already fixed. ― Blaze The Wolf^Talk_{Blaze Wolf#6545} 17:12, 6 October 2021 (UTC)

expired SSL certificate

On linux, I'm getting an expired certificate error when accessing enwiki using multiple CLI tools (wget, w3m). It doesn't happen with firefox. It only occurs on one machine (IP?) on a different machine/IP no problem. Typically this points to system date being wrong, but the date is accurate. Other SSL sites work OK only *.wikipedia.org - Any ideas what it might be? Example: wget -q -O- 'https://en.wikipedia.org' returns empty response. Cert check can be bypassed with --no-check-certificate but is insecure and weird security errors are disconcerting. -- GreenC 17:37, 6 October 2021 (UTC)

@GreenC see HTTPS/2021 Let's Encrypt root expiry. Legoktm (talk) 17:45, 6 October 2021 (UTC)

@Legoktm: Thank you, that must be it as my OpenSSL is old. I've spent hours trying to get it work, upgrading SSL and adding the new root certificate and removing old, but nothing works.

/etc/ssl/certs/ISRG_Root_X1.pem -> /usr/share/ca-certificates/mozilla/ISRG_Root_X1.crt

Updated /etc/ssl/certs/ca-certificates.crt

For now, will disable certificate checking on each tool, I'm sure this will haunt me later. -- GreenC 21:26, 6 October 2021 (UTC)

Not sure what system you are using, but for old debian variants: In /etc/ca-certificates.conf, for the entry mozilla/DST_Root_CA_X3.crt prefix it with ! (so !mozilla/DST_Root_CA_X3.crt) to disable it and then run update-ca-certificates. This removes this expired root from the evaluation path. update everything that uses ssl. And then update the OS, because... it's clearly not up to date ;) —TheDJ (talk • contribs) 21:56, 6 October 2021 (UTC)

@TheDJ: .. OMG it worked. I had removed DST_Root_CA_X3.crt and rebuilt ca-certificates.conf using dpkg-reconfigure ca-certificates then updated with update-ca-certificates - but guess it still requires DST_Root_CA_X3.crt to be around and marked off with ! in the .conf .. whew not obvious. Thank you! -- GreenC 22:17, 6 October 2021 (UTC)

I personally found this explanation to be very readable. And that this worked basically means that you are using outdated openssl/gnutls/libressl etc... Maybe your OS version has a version-backports apt repo you can add that has a backport of the openssl version you need. But hard to say. —TheDJ (talk • contribs) 22:27, 6 October 2021 (UTC)

Proposals

"WP:PROPOSE" redirects here. For propose for deletion page, see Wikipedia:Proposed deletion and Wikipedia:Deletion requests.

Dispense with "In popular culture" because there is no such thing.

Should Wikipedia continue to have sections titled "In popular culture? 20:40, 12 August 2021 (UTC)

Executive summary: It's not 1887 anymore. "Popular culture" is just "culture". This is why we don't have commensurate "High culture" sections. It all runs together now, and "In popular culture" sections should be called something else -- "In other media" or "In general culture" or "Other uses and references" or whatever. I'm going to start doing that. You should too.

---

Extended exposition: The distinction between "high culture" and "popular culture" is so permeable to be no longer useful. In older times some people went only to the symphony and read Livy in the original Latin. And disdained or know nothing about folk songs and banjo music and boxing and Sherlock Holmes etc.

Nowadays, even rich people -- even old money rich -- and PhD's listen to, I don't know, Trent Reznor and Vivaldi's The Four Seasons and Leonard Cohen and read, I don't know, John Cheever or Bernard Cornwell as well as Livy and Schubert and Proust and so on. They just do.

Where does Horse Lords fit? Where does Aaron Copland fit? How about the Beatles, or John Updike? How about Picasso? Paul Robeson and Nobel laurate Bob Dylan? Yo Yo Ma and Eric Clapton? Ocean Vuong, Van Morrison, Walter Scott? Is Old Man River low culture, and Pachabel's Canon high?

Set me off was Do not go gentle into that good night. The "In popular culture" section references Doctor Who and Stravinsky and Rodney Dangerfield and Elliot del Borgo and John Cale and Matthew McConaughey and Ceri Richards and Iggy Pop and so on... if all that is "popular culture", what isn't?

I mean I could have maybe sorted all that into two sections, "In popular culture" and "In high culture" (or maybe "In obscure culture"), but that would be nonsensical. Instead I renamed the section. We don't have any guidance on that so I made up "Use and references in other works". Could have been something else.

(Also, FWIW, the term "In popular culture" makes some editors claw the draperies and call the maid for smelling salts. There's no point in triggering our bourgeois colleagues, so something less suggestive of the tenements is in order.)

"In popular culture" might belong in Snobopedia, but not here. I fully realize that making a rule changing stuff like is near impossible in this hidebound environment, so I'm not even suggesting a !vote, but I'll tell you what. I'm done with "In popular culture" and I'm not going to write that title for sections, and I aim to change them when I see them. That's my proposal: if you buy the argument, vote with your feet and do it too. If you don't, don't. Herostratus (talk) 22:08, 11 August 2021 (UTC)

Interesting thoughts, Herostratus. It bothers me when I see something like this and think, "well, yeah, why didn't I notice that myself (sooner, consciously)"? I believe I'll consider renaming such sections to something like "Notable cultural references" where it fits, when I see such things. Certainly something to think about. — JohnFromPinckney (talk / edits) 22:38, 11 August 2021 (UTC)

There are probably essays and maybe even guidelines about it. I label those sections "Influences", it's a form of notability. Something is "influential" when it has "influenced" significant works or people, making it notable, not a list of random trivia. -- GreenC 00:01, 12 August 2021 (UTC)

Influences or (cultural) legacy should be in order. And I agree that this should be reserved to those which made a very significant impact on society, e.g. the Thompson submachine gun or the RMS Titanic. Blake Gripling (talk) 01:41, 12 August 2021 (UTC)

I don't think there's a one-size solution here, but I do agree that most sections that are labeled "in popular culture" can likely renamed to something more broad. What that is depends; if there's only a handful, such a list might fall under a Legacy or Influence section and not be sectioned off on its own, while longer sections may need something of its own section like "References in other works" as suggested. But I would say that if we are making a distinction between pop culture (the masses) and high culture (the elite), then there are likely cases of older works (thinking Shakespeare-type classics) where we are more likely documenting what is a high piece of culture being reused by the popular culture. I don't know of any immediate examples but I would not be surprised nor balk at an article called "Romeo & Juliet in popular culture". But again, I can't propose a hard-set rule in this area when this would be appropriate, so I would be hesitant to simply say "scrub all 'popular culture' use". --Masem (t) 01:50, 12 August 2021 (UTC)

• I disagree, both in terms of the naming issue, and with the utility of content falling under such headings. The widespread use of the header indicates the intuitive understanding that people (including readers) have of the term, and is no more snobby than referring to popular music. Speaking of the readers, in terms of inclusion of such content, let's Give the People What They Want (to the extent that it can be cited to sources). BD2412 T 01:51, 12 August 2021 (UTC)
  • But there is a point that WP is not TV Tropes, and such sections often are kudzu for weak or unsourced assertions of pop culture, which we can read as being what people want. We are here to provide educational material for the readers, and to that end we focus often on content that the average reader doesn't want but what a slim minority will want. This is perhaps due to many users expecting WP to provide certain types of content, thinking it a one-stop shop, that are simply outside our bounds established in policy. Hence we really need to be careful if we try to craft policy or guideline around readers' preferences. --Masem (t) 02:17, 12 August 2021 (UTC)
    • Considering that our most viewed pages for the past week include The Suicide Squad and Jungle Cruise, and that our most viewed topics routinely include pop culture and entertainment topics, I suspect that it more than "a slim minority" who have an interest in this sort of content. BD2412 T 02:46, 12 August 2021 (UTC)
      • I mean that if you take the type of content we want editors to focus on based on what we are not per WP:NOT, that type of content tends to cater to a slim segment of the readers but that's because that's the key academic content of an encyclopedia. I'm sure those movies had huge page views but I also would suspect that the bulk of readers were only reading them for the plot summary, cast list, and reception, and little about development/filming/etc. (which is the more academic core of those articles). That type of popular content is basically one step removed from what IMDB or TV Tropes offers, and while can offer it, its there to augment the more academic facets which typically do not interest the majority of readers but are still good reference for some. --Masem (t) 02:54, 12 August 2021 (UTC)
• I think that we are ultimately just talking about the title of a subsection, and it really doesn't matter to me which title is used, but I will say the cookie cutter "in popular culture" gets old after awhile, and the titles that have been suggested as alternative options are refreshing, but in the end, I really don't mind which title is used as long as we continue to add the pertinent information. Huggums537 (talk) 02:07, 12 August 2021 (UTC)

  I also want to add that the logic of the comments suggesting disposal of "In popular culture" for no sound reason other than because it invites trivia, and list cruft etc. totally escapes me. This is the logical equivalent of saying, x could be used for something silly, stupid, bad, or evil; therefore we should dispose of x. Proponents of this type of logic usually like to insert some kind of exaggerated example of where this has occurred with x. The two problems facing this type of logic is that it completely ignores all of the places where it has not occurred with x, and x has worked out just fine. The second problem is that it overlooks the obvious fact that x can always be used for something silly, stupid, bad, or evil, so that in and of itself really isn't justification enough, otherwise we would be able to simply dispose of anything and everything we just don't like, and can replace with x. Huggums537 (talk) 20:24, 12 August 2021 (UTC)

  I also want to add an example: Let's say x is Wikipedia lists. Someone could argue that lists invite cruft and should be disposed of. They might provide an example of an exceptionally bad list to prove their point, while ignoring the hundreds of good ones. They might argue some lists could be used to damage Wikipedia, and we should eliminate lists all together, while glossing over the fact that we have a process in place to eliminate individual lists that might be damaging. Is the possibility of a thing being used for the wrong purpose sufficient grounds alone for the disposal of that thing as a solitary rationale? I hope not, and I hope this is a good illustration... Huggums537 (talk) 20:50, 12 August 2021 (UTC)

  Another fine example of this wrong thinking is that there are way more than enough documented cases of road rage where a vehicle has been intentionally used to harm people or property that proponents of this flawed logic might argue we should dispose of vehicles all together or put some kind of restrictions on them to prevent people from using them in such destructive ways. However, this overlooks the overwhelming majority of evidence that most vehicles are not used in destructive ways, and it also ignores that the minority of them that are used this way are currently being handled by other processes we already have in place, making a blanket ban and more restrictions not only redundant, but an un-necessary burden on the moral majority. Huggums537 (talk) 11:31, 20 August 2021 (UTC)

• WP:IPC does encourage editors to use a section name other than "In popular culture", though that is just an essay. Personally I don't especially care what the section is named; the content is of greater concern to me. I'm not sure what this proposal's goal is: to make calling a section "In popular culture" a warnable offense? To suggest an update to the MoS? If everyone agrees that IPC is poor section-naming, what's the practical result? As far as concerns about the content, I would say that WP:IPCV and the associated RfC were a godsend as they provided bright-line guidance that IPC items require independent sourcing as a means of establishing the items' significance for inclusion purposes. DonIago (talk) 02:22, 12 August 2021 (UTC)

Usually the term / section name just serves as an entre / coatrack for fandom or promotional items that don't belong in the article. I don't want yet another rule but it would be good to put a Scarlet Letter painted on that phase as being such, or discouraging it's use.North8000 (talk) 02:28, 12 August 2021 (UTC)

• In my experience a section heading mentioning "popular culture" generally proceeds incredibly useless and off topic information. I think Randall said it best in his xkcd comic. HighInBC ^{Need help? Just ask.} 02:32, 12 August 2021 (UTC)

Nice one!  :-) :-) North8000 (talk) 02:38, 12 August 2021 (UTC)

• • Drawing from the above comments by JohnFromPinckney and Blake Gripling, "Cultural influence" may be a better header. It implies the subject is the topic itself, rather than the subject being the "popular culture" influenced by it. This may help reduce the propensity for off-topic information. CMD (talk) 02:41, 12 August 2021 (UTC)

    If it fits (it often does) I sometimes use "In fiction". Gråbergs Gråa Sång (talk) 14:18, 12 August 2021 (UTC)

• Subcultures still exist, and they have various levels of prestige. I think it's funny that all the examples of how culture has blended together are stuff my middle-aged dad would talk about at a party but don't include any band I listen to or any author I've read (and I read Latin). This of course isn't a coincidence because "popular culture" is stuff middle aged dads talk about at parties, not the whole extent of cultural experience. Perhaps the popular culture section includes people you know because that's the point? You know them because they're in popular culture---because they're popular? If you didn't recognize someone on those lists, now that would be remarkable. Idk, this whole thing reads like you're projecting your cultural experience as if it's universal when it remarkably isn't. — Wug·a·po·des​ 03:11, 12 August 2021 (UTC)

• I'm inclined to agree with BD2412 - you're right that our current use doesn't match the old definition of "popular culture". However it does match the way the term is used by the majority of people (and sources) now, and thus is a reasonable term. Nosebagbear (talk) 06:37, 12 August 2021 (UTC)

• Drawing a distinction between "high culture" and "modern popular culture" or whatever you want to call them isn't really that important. The point is to stop endless lists of off-topic trivia. Reyk _YO! 08:01, 12 August 2021 (UTC)

• I agree with the idea....what are we proposing to put in practice though Cas Liber (talk · contribs) 11:18, 12 August 2021 (UTC)

• Reminds me of the now-deleted article about Miami Vice in popular culture. I mean sure, the series is indeed iconic for perpetuating popular 80s stereotypes, but imo such cultural impact is best described in a "Legacy" section. WP:MILPOP handled it better like in the Thompson submachine gun where its significance in pop culture is well-integrated into the history section rather than as a listcruft of all known instances of where the Tommy gun was used. A separate popular culture article wouldn't hurt if it is well-written in pose and there is exceptional proof that the subject gained notoriety e.g. Adolf Hitler. Blake Gripling (talk) 11:23, 12 August 2021 (UTC)
• "In popular culture" is now itself a phrase ingrained in (popular) culture, perhaps our most infamous section title. As such, I don't think much misunderstanding or literalism about the connotations of "popular culture" is in the minds of our readers. Such sections are almost always bad, and should either be removed as fancruft or adapted into a proper "Legacy" or "Impact" section (such as Black Mirror#Cultural impact) that doesn't aim just to enumerate random references but to convey the scope and significance of the work on future art or the public consciousness. — Bilorv (talk) 11:31, 12 August 2021 (UTC)

  I'd say "Controversies" is our most infamous section heading... –MJL ‐Talk‐^☖ 16:49, 18 August 2021 (UTC)

• The wording of the section heading can make quite a difference. Headings such as "In popular culture" or even worse "References in popular culture" attract editors who seem to think it's important to add a bare mention of the subject in episode 12 season 23 of their favourite show. Much less likely to attract that sort of thing is a section headed "Cultural impact" or "Notable cultural developments". I'd like to see us much more strongly discourage the old "In popular culture" wording. MichaelMaggs (talk) 12:22, 12 August 2021 (UTC)
• ”In popular culture” is just another way of saying: “Trivia”. Blueboar (talk) 13:14, 12 August 2021 (UTC)
• In popular culture is a useful honeytrap for crap that doesn't belong in the article. That's its main value. --jpgordon^{𝄢𝄆𝄐𝄇} 14:17, 12 August 2021 (UTC)
• What Jpgordon said. To the best of my knowledge, its origin on Wikipedia was Gunpowder Plot in popular culture, and (as the person who originally suggested it), I can confirm that the intent in that case was quite deliberately to restrict the edit-warring over every TV show that mentions Guy Fawkes to a single section where people could fight it out without disrupting the main body of the article. It sounds patronizing, but it does serve a valid purpose; IPC sections and subpages means people don't try in good faith to rewrite entire articles just because a movie on the topic comes out or it gets mentioned on Star Trek.

  I have no attachment to "in popular culture" as a name, if anyone can think of something better. It's literally the first name that occurred to me and was subsequently picked up on and copied by other articles; it has no particular significance. ‑ Iridescent 14:45, 12 August 2021 (UTC)

Wait.. you are the one who started IPC? This is notable Wikipedia history, given how influential it has been (for better or worse!). If you don't mind, this should be in a "history" section at WP:IPC -- GreenC 15:48, 12 August 2021 (UTC)

Wikipedia:"In_popular_culture"_content#History -- GreenC 15:55, 12 August 2021 (UTC)

I thought I'd coined the phrase, but on doing some digging there were already a few IPC pages existing prior to that—the oldest I can find on a very quick dig is Librarians in popular culture (a candidate for "Wikipedia's worst article"). I do believe the Gunpowder Plot one was the first one set up explicitly to keep the IPC froth off the main topic, though. (I am responsible for "civility police", "indefinite not infinite" and "ANI flu"; my footnote in Wikipedia's history is secure.) ‑ Iridescent 16:07, 12 August 2021 (UTC)

The oldest deleted page titled "...in popular culture" - where I can't find evidence that it was moved there later, like, say, Evocation in popular culture, created at Conjuration and moved there in 2010 - is Teaching in popular culture, created 17:50, 29 April 2004. The oldest existing article with such a title is Adolf Hitler in popular culture, originally created at Hitler in popular culture at 15:20, 2 October 2004‎. (There may be older pages that started with IPC titles and were later moved to non-IPC titles, but that's laborious to search for.) The phrase was likely used in section headers even earlier. —Cryptic 18:45, 12 August 2021 (UTC)

IIRC these started showing up as sections in articles in early 2004, but I wouldn’t be surprised if someone dug up a diff from late 2003, see for example 1 2 3; even Exploding whale had one 4. Eventually those sections grew so much they were spun off into separate articles to avoid overwhelming the page, indeed some comprised the majority of an articles content at the time of spin-off e.g. 5. The whole process took place more or less organically; then as now people often just copied what they saw others doing. In hindsight, in popular culture is probably not best, but a lot of the time the thought process was just to be bold and assume that it would be improved upon later.

In fact people have been trying alternatives for some time now 6, see also, Cultural influence of Plato's Republic, Venus in culture, Cultural references to Hamlet , Women warriors in literature and culture, Synesthesia in fiction etc. Doubtless someone with a bit more free time available will be able to find other formulations in current use. Regards, 81.177.3.8 (talk) 19:20, 13 August 2021 (UTC)

Might I suggest Wikipedia:"In_popular_culture"_In_popular_culture pending this RFC? @GreenC Shushugah (he/him • talk) 02:20, 15 August 2021 (UTC)

What I was thinking was using "Cultural influence" or "Cultural allusions" or maybe "Cultural influence and allusions". in WP:VG, we don't have "in pop culture" sections but just "Legacy" sections instead.Blue Pumpkin Pie (talk) 16:02, 12 August 2021 (UTC)

• Oh but now here's a thought regarding the content rather than the name of these sections. There's plusses and minuses, but to my mind, the purpose of these sections is to indicate how well known the entity is. So, let's take "Do not go gentle into that good night"... is this an obscure poem like say "The Legend of Novgorode" or thousands of others, or is it more well known? That's a very important point for the reader to know! But we can't just assert it. If we have a source saying "This poem is super well known!" fine, but first of all we usually don't, and second even if we do it's just one guy asserting it.

But... remember Writing 101: show, not tell. Well, Do not go gentle into that good night#Use and references in other works shows very well that the poem's reasonably famous. Important info. Even minor examples can help with that. If somebody says a line in passing on some HBO show, that that's another demonstration that it's floating around in the culturespace, unlike say Trilce.

But then: as we all know, these sections can grow out of control, too. So here's what I've tried, and I think it maybe works OK: Make the "References in other works" short but dump the excess examples down into either the Notes or the References sections, where they are they are still there but don't bother anybody. At Anyone for tennis? I gave some examples (basically the bluelinked ones), then added "And so forth" with the ref for that containing all the extra non-bluelinked examples. You can also use a Note instead. Reasonable approach? Herostratus (talk) 16:16, 12 August 2021 (UTC)

I don’t think that works particularly well— feels like hiding cruft that shouldn’t really be in the article. But I have no problem with ‘in popular culture’ sections at all, when put together properly. This whole discussion seems, to me, a waste of energy that would be more productively expended in other endeavors, such as writing content. Eddie891 ^Talk _Work 16:26, 12 August 2021 (UTC)

Yeah how about not telling other people how to spend their volunteer hobby time maybe. I've got 500 articles created and many thousands of article edits, how about you. Herostratus (talk) 16:43, 12 August 2021 (UTC)

…I’m just suggesting that I don’t think this is the most productive thread Eddie891 ^Talk _Work 18:18, 12 August 2021 (UTC)

since you asked, in the past five years since I began editing, I’ve created over 300 articles and made over 40,000 edits and written several featured content (incl one fa with an in popular culture section) and had almost 100 dyks. In that time, you’ve created 156 articles and made about 11,000 edits. Eddie891 ^Talk _Work 18:25, 12 August 2021 (UTC)

I'm going to nicely ask to stay on topic and remain civil. And if you feel its a waste of time, you can contribute to the articles you want. it's ok to not find a topic productive. Others don't feel the same way.Blue Pumpkin Pie (talk) 18:29, 12 August 2021 (UTC)

? I don’t see the problem with my conduct. I said what I thought, herostratus replied to say ‘yeah, no’— which I understand— and I answered his explicitly posed question. Eddie891 ^Talk _Work 18:55, 12 August 2021 (UTC)

Since it has come up, I have over 1,800,000 edits, with over a million being article edits. I have created over 6,000 articles. To reiterate my earlier position, I think "in popular culture" sections are fine. If you want to police them for proper citation to sources, go ahead. If you want to structure them into prose, have at it. Trying to remove them altogether is counter to the information-sharing function of the encyclopedia, and is indeed a waste of volunteer time. BD2412 T 20:09, 12 August 2021 (UTC)

• Whatever such sections should be called, they should not encourage every casual reader to think, "Hey, this list doesn't include the fact that in the third episode of the fifth season of Family Man, it is revealed that the neighbor's cat is named Crookshanks." Calling them "In popular culture" seems to do exactly that. —valereee (talk) 17:07, 12 August 2021 (UTC)
  • This also brings up that, it's also the list format that many of these take. Lists "look" easy to add onto so draw in every trivial mention. It is far better to try to encapsulate how a topic has entered popular culture by prose, if possible, as I've found new editors tend to be a bit more adverse to trying to alter that and making a mistake. --Masem (t) 17:21, 12 August 2021 (UTC)
    • It does draw in every trivial mention, but that also means it's drawing in first posts by readers, sometimes. That's key. We get them to add a reference to say something the saw on American Dad. That's the start. Then we sloooowly reel them into our dysfunctional little group here, and one day they wake up and they're writing articles about ninth-century Inner Mongolian minor poets. But by then it's too late for them to rejoin the world of normal people. BWAHAHAHAHA Herostratus (talk) 19:07, 12 August 2021 (UTC)

      OTOH, when that edit gets reverted five minutes later with an annoyed edit summary of "rem trivia"...the bait is doing its job, the reel not so much. :D —valereee (talk) 19:17, 12 August 2021 (UTC)

      While lists are a good way for first edits of new editors, 99 times out of 100, when added to a pop culture section, it is unsourced. Which if unchecked creates a self-replicating problem. --Masem (t) 20:54, 12 August 2021 (UTC)

      I think this gets well off-topic, but it's not specific to IPC: we have a huge problem because no-one's first 100 edits are good, but 100 bad edits in 2006 is alright because at least it creates something new, and 100 bad edits in 2021 is not fine because it makes existing alright content worse. So whatever you do is wrong and you'll get reverted and scared off the website. Or you don't get reverted initially, but someone finally notices you and tells you everything you've spent many hours on is wrong, and now you get scared off the website but you're also in tears. My best answer to this so far is "people should start off at Fandom and then come here when they're already used to the website design and some of the culture". — Bilorv (talk) 01:29, 13 August 2021 (UTC)

      Oh $deity no don't send people to Fandom for a good experience. It's as good as testwiki for learning Wikitext I suppose, but does absolutely nothing for learning to edit in a collaborative environment. AntiCompositeNumber (talk) 03:51, 15 August 2021 (UTC)

      With the levels of hostility expressed to both newcomers and old hands, there's not much collaborative environment in Wikipedia either. — Bilorv (talk) 12:15, 22 August 2021 (UTC)

    I think that is an excellent point. Lists absolutely beg people to add to them. Maybe such sections shouldn't usually be lists? —valereee (talk) 19:21, 12 August 2021 (UTC)

• I think that most of the posts are getting away from the main point, which is that the word "popular" shouldn't be used here. For example opera and ballet are not considered "popular", but mentions in such are just as valid or invalid as mentions in Hollywood films or pop music or computer games. Phil Bridger (talk) 19:37, 12 August 2021 (UTC)
• This is a fairly interesting point, and I would add my voice to those that more or less hate these sections as they almost inevitably become long lists of unsourced cruft. I'm not sure changing the name will solve that core problem, but I'm nt opposed to the idea of trying it. My personal approach is to just remove anything without a source since that's pretty basic, and also remove mentions based on one throwaway line from a tv show, and maybe add things like hidden comments or edit notices if they persist. (Not that it always works, it's been over a decade of trying get people to stop posting that Commander Riker is "from" Valdez, Alaska). Beeblebrox (talk) 20:29, 12 August 2021 (UTC)
• Where there are also things like opera & novels, I tend to use headings like "Cultural references", which might also cover a whole themed episode of say South Park, but not a passing reference. Johnbod (talk) 01:36, 13 August 2021 (UTC)
• I have no real opinion on the title discussion, "popular culture" is intuitive if not dictionary perfect. Like many above I too generally dislike these sections, principally because they are usually an unsourced dumping ground for passing mentions in an single episode of a sitcom or the like. I think a good start may be to make MOS:POPCULT more succinct and punchy, emphasising the 2015 RfC, possibly elevating the sourcing requirements from that RfC into a guideline itself. Cavalryman (talk) 04:00, 13 August 2021 (UTC).
• I suggest "Society and culture" as a title (used in WP:MEDMOS) which I think does a better job of reflecting this. What's popular culture now is usually not even in 10 or 20 time (which are now timespans relevant to Wikipedia!) In general I also find that sections "In popular culture" are almost always WP:TRIVIA and could be completely blanked.Tom (LT) (talk) 10:32, 13 August 2021 (UTC)
• Strong oppose to a change (although hopefully this isn't a decision that is being taken here). On individual pages I'd guess that 'In popular culture' sections are themselves quite popular, have likely been a Wikipedia mainstay since 2001, and have a name which is both extremely recognizable and a more-than-adequate descriptor. On stand-alone article pages the idea of changing this ramps the "Huh?" factor up a level or six. Important pages such as World War I in popular culture, World War II in popular culture, Apollo 11 in popular culture and dozens if not hundreds more have educated readers about cultural events which have themselves educated the public since their inception. A good discussion, but let's leave it at that. Randy Kryn (talk) 11:12, 13 August 2021 (UTC)
• I don't know. Who cares. This seems like something that should be handled on an article-by-article basis.--WaltCip-(talk) 17:08, 13 August 2021 (UTC)
• I think that the underlying issue is this. The normal practice is that In the normal inclusion / exclusion decisions are made based on a multitude of factors including degree of relevance and degree of importance to the topic. Headings should be for material that inherently belongs in the article. Certain headings distort that process towards bringing in material that would not have otherwise been included. Headings like "in popular culture" are of that type. Particularly promotional or fandom items. North8000 (talk) 17:28, 13 August 2021 (UTC)
• Oppose. I'm not going to talk about whether or not we should have these sections in the first place, because that doesn't seem to be the point of this RfC. But I don't think most people intend a negative implication when they're talking about popular culture. I also agree with Randy Kryn's reasoning. Clovermoss (talk) 22:03, 13 August 2021 (UTC)
• The existence of the article Mermaids in popular culture is presumably what allows the article Mermaid to pursue a purely zoological examination of these alluring beasts. The former article includes such pop culture phenomena as Zemlinsky's Die Seejungfrau; which seems only right as Die Seejungfrau has been put out on at least ten commercial recordings, AFAIK five times as many as there have been of Tubular Bells. -- Hoary (talk) 22:34, 13 August 2021 (UTC)
• Oppose any across-the-board deprecation of "in popular culture" sections, which to me is where you place mentions of snippets of musical pieces heard in video games, TV shows, etc., instead of discussing modalities, orchestration, and influences (which probably fairly applies to the Dylan poem referenced above), etc. The lack of sourcing in such sections is notorious, but that's for editors of individual articles to decide how much original reporting to let in. Dhtwiki (talk) 09:03, 14 August 2021 (UTC)
  • The lack of sourcing in such sections is notorious, but that's for editors of individual articles to decide how much original reporting to let in. We already decided that; the answer is "none," and we wrote that up on a core content policy page called WP:No original research, which is global consensus that editors of individual articles cannot change. Levivich 14:39, 16 August 2021 (UTC)
    • I tend to let plausible, innocuous statements stand, not to violate policy but in the hope that other editors will come along and find sources for them. Leaving unsourced a statement that a subway's door-closing chime is inspired by a piece by Handel isn't at the same level as, say, leaving an unsourced statement alleging criminal wrongdoing. If left unsourced, even the innocuous statements may eventually be swept away by more deletionist editors; and I won't object. Dhtwiki (talk) 01:32, 21 August 2021 (UTC)
• Oppose deprecating the term 'in popular culture'. It's merely one of several acceptable titles for such sections/articles, and I see no need for any new rules. LEPRICAVARK (talk) 23:14, 14 August 2021 (UTC)
• Deprecate such sections. Listing every time X appears in fiction (or popular culture, or whatever) is what TV Tropes does. As I said in Wikipedia:Articles for deletion/Space stations and habitats in fiction: If there is sufficient coverage in WP:Reliable sources to write a prose article about X in fiction/popular culture/whatever then such a separate article should exist (I don't think this is a terribly tall order – see e.g. eco-terrorism in fiction and space stations and habitats in fiction, which—full disclosure—were both rewritten as prose articles by me), and if there isn't sufficient coverage to do that then we shouldn't have a "in popular culture" section in the main article about X. We should never just enumerate examples of X in fiction/popular culture/whatever. In general, I quite agree with the essay WP:CARGO—fiction is not fact and collecting raw data does not produce analysis. TompaDompa (talk) 01:32, 15 August 2021 (UTC)
  • You are iVoting in the wrong discussion, TompaDompa. This is just about the changing of the section title, "In popular culture", not about whether the sections should exist or not. (That is for a whole different discussion.) GenQuest ^"scribble" 07:02, 15 August 2021 (UTC)
    • I'm not at the wrong discussion, I'm just proposing a more radical solution – one that would cut the Gordian Knot, so to speak. The text at T:CENT says Should articles continue to have sections titled "in popular culture"? My answer is no—not because the title is bad, but because having such sections is. TompaDompa (talk) 03:24, 16 August 2021 (UTC)
• Oppose deprecating the term 'in popular culture'. Like it or not, this content is going to continue to be added to the articles, and we have to put this junk somewhere, and the un-cited and trivia can then be easily deleted from these sections. Now, someone start a discussion about whether these sections should even continue to exist and things will get quite interesting. GenQuest ^"scribble" 07:02, 15 August 2021 (UTC)

• Comment I don't understand your reasoning for the opposition. You just commented that this discussion isn't about removal of these sections, but you used that very reason for that. What do you mean by "we have to put this junk somewhere". Would it hurt the article if we don't?Blue Pumpkin Pie (talk) 16:13, 15 August 2021 (UTC)

I am against the change of the title of these sections. If we are going to have them, they should be consistant. (That was what this discussion is about.)

With that said, however, I don't think the existence of these sections is particularly helpful or needed. Actual, non-trivial, referenced information regarding the article(s) subject(s) should be in the article body where their presence is explained in relation to the subjct, not tossed in at the end of an article with no clear indication of why it is important to an understanding of the subject that they must actually be there. But that is an issue that has not yet been advanced by anyone, not this proposal. And to answer your question, Blue Pumpkin Pie no, as far as I am concerned, it doesn't hurt the article if we don't put/leave the junk in, it improves it. But, junk will just continue to reappear without that alternate discussion taking place some day. GenQuest ^"scribble" 03:15, 13 September 2021 (UTC)

break

So I'm seeing kind of three questions:

1) There's the question of whether sections should even exist' at the end of articles that have things "In Joyce Carol Oates's 2000 novel Blonde, the character of The Ex-Athlete is based on DiMaggio" and "In Seinfeld, Season 3, episode 1 "The Note, Kramer spots DiMaggio in a Dinky Donuts" and "DiMaggio appears in Harvey Comics' Babe Ruth Sports Comics (August 1949)"

2) There's the question of, if they do continue to exist, (and they will) how should they be named (the original and basic question of this thread).

3) And then there's also always the eternal the question of, if they do exist, how to curate? Should stuff like the first item above (important character in a serious novel) be in them and stuff like the second (passing mention in a vulgar and witless, but very popular, TV program) or the third (cover appearance in a long forgotten and lost children's comic) not? (And other questions of details.) And what practical procedures might be used to curate them?

So, for the first question, there are a lot of decent arguments either way, but as a practical matter, come on. We're always going to have these sections. It's entirely legit to express your opinion for/against them, but it's not going to change anything. So moving on.

For the third, well the current procedure is for editors -- driveby anon readers often enough -- to keep adding stuff (some good, some marginal, a whole lot silly; some well ref'd, some poorly ref'd, some unref'd) and for other editors to come across them, mutter "oh my God" under their breath and trim them (or even delete them), and for people to occasionally argue about it, since ultimately it's a matter of opinion how to curate. That's kind of kludging along (like a lot of the Wikipedia!), but it's OK, and I honesty don't think there's a better way. It's alright. It works OK. The project is not going to collapse over this. I can't imagine any rules that could be put in place ("No more than ten items" or "No refs to non-bluelinked sources" or whatever).

For the second, that's the question.

• Should these sections continue to be named "In popular culture" as is usual (altho far from universal)?
• If not, should they mostly be named one other single name, or let 1000 flowers bloom?

I just don't think there's any way to make a rule. There is the general practice of naming them "In popular culture", and rules are to codify common practice, so there could be a formal guideline made to that effect, such that someone could come along and rename your "In art and literature" to "In popular culture" and have the high ground. But I mean that's not going to happen. You're not going to get even 60% of a large group to agree to that. So just forget it. Trying to make a rule to have the sections be named some other thing is forget it squared.

It would be preferable to have a (generally common) name. As we do for "Early life" and "Personal life" "Discography" and "See also" etc. That's a good point. And they only possible generally common name is "In popular culture", barring a long-term sea change. So it's fine for individual editors to keep doing that.

For my part, personally, in my personal opinion it just sticks in my craw. In my article, I don't want to put "Chaucer says this..." and "Juan Ruiz de Alarcón says that..." under popular culture. Yes they're in the vulgar tongue, and yes in their time they were for the common people, but I mean not anymore. Mostly people only read them in college classes. Few people say "Pick me up a guilty-pleasure novel, Jackie Collins or Cervantes or Melville or something like that; I'm just not in the mood for Boethius today". They just don't. Chaucer and Richard III (1699 play) are closer to Terance and Quintilian than to Nicholas Sparks or Tom Clancy, n'est-ce pas? It's just incorrect. It's misleading the reader. I don't want to do that, so for my part I'm not going to.

So... different names in different articles for sections that are pretty much the same content? Oh well. Least bad option IMO. Herostratus (talk) 18:48, 15 August 2021 (UTC)

• Oppose deprecating the Popular Culture sections. That is the name that Wikipedia has had for those sections, and usually they are useful additions to the encyclopedia. In cases where they are silly or useless, we can get into ugly edit-wars that go to WP:ANI and keep the tone of WP:ANI a little less heavy. That's only half humorous. But the sections are useful and the name is as good as anything else. Robert McClenon (talk) 19:45, 15 August 2021 (UTC)
• Deprecate the sections as WP:UNDUE/WP:OR. When writing about the topic "Foo," what we're supposed to be doing is summarizing WP:RS about Foo. If the RS state that Foo was mentioned on The Simpsons, then yes, that should be included in our article, probably in a section called "Impact" or "Legacy" or something like that. But if no RS mentions it, and an editor adds to the Wikipedia article that Foo was mentioned on The Simpsons (or in a song lyric, or as part of a plot of a book, or whatever), then that's WP:UNDUE and WP:OR because it's including something in the Wikipedia article Foo that isn't mentioned in any of the RSes about Foo. Anything not mentioned in the Foo RSes doesn't belong in the Foo Wikipedia article at all. Levivich 14:34, 16 August 2021 (UTC)
• I seriously doubt that changing the typical name for these sections would stop them from accumulating cruft. XOR'easter (talk) 22:24, 16 August 2021 (UTC)
• Meh. There are probably far more important things to be doing right now, this feels very navel-gazey. Stifle (talk) 09:54, 17 August 2021 (UTC)
• Oppose change This is a solution looking for a problem. There is nothing wrong with the phrase "in popular culture"; everyone knows what it means. I don't see any good reason to change it. Mlb96 (talk) 20:49, 17 August 2021 (UTC)
• Support change. I just had to wipe out the entire "In Popular Culture" section in When Johnny Comes Marching Home because of a mix of WP:UNDUE, WP:OR and WP:UNSOURCED issues. I suspect that renaming the sections will reduce the affinity for people adding random trivia. I would also lean towards User:Levivich's position of a general depreciation, but that goes beyond the scope of this discussion. BilledMammal (talk) 07:02, 26 August 2021 (UTC)
• Support change This is not, unlike what some claim, a "solution in search of a problem". The problem is very real; and you don't need a particularly acute sense of what is encyclopedic and what is not to figure that out - even xkcd gets it. There are some decent examples of sections which appropriately deal with the cultural impact of something; for ex. this (which is half decent) or this (probably one of the better examples). However, far too often, it looks just like unrelated notices of appearance, almost sillier than the xkcd comic I link as a parody earlier. RandomCanadian (talk / contribs) 23:09, 3 September 2021 (UTC)
• Oppose Popular culture is a thing. We have an article on it but it wasn't invented on Wikipedia as there is scholarship going back long before. As for the archetypal IPC section or article, that's a thing too. The main thing that's not clear to me is who updates such sections and why. Is it done by regular editors, specialist gnomes or the general public? Anyway, Wikipedia is the encyclopedia that anyone can edit and this seems to be one of the consequences. So it goes. Andrew🐉(talk) 23:55, 3 September 2021 (UTC)
• Comment I think that In Popular Culture sections can be appropriate if (1.) the thing is actually significant for its role in popular culture and (2.) the section is a succinct summary that gives a general overview and names only the most noteworthy works. The Empire State Building article does a really good job of the latter. In practice however, most In Popular Culture sections are just indiscriminate lists of times that really famous or significant things appeared in works of fiction; many of these listings either lack sources or are sourced solely to the fictional work that the article topic appears in. Honestly, I think any In Popular Culture section that consists solely of a bullet pointed list can be safely removed without negatively impacting the article. Spirit of Eagle (talk) 02:19, 5 September 2021 (UTC)
• Comment. I oppose depreciation, but I'd support considering a new name. "In culture", shorter, will do fine. What's popular is debatable anyway.--_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 12:31, 7 September 2021 (UTC)

Proposal by CaptainEek, ft. Baby Yoda

• Proposal: In general, our "In pop culture" sections are the worst parts of articles. Occasionally, they are actually useful. But usually they are an agglomeration of OR and are 9/10 times trivia. I think the substantive change that we could implement is in effect a meta-notability requirement. I suggest The content of "In popular culture" sections, or similar sections, must have been discussed in reliable secondary sources which specifically link the cultural item to the subject. These sources must be focused on the subject, NOT the cultural item. Take for example the subject of "Bone broth", and you wish to include mention of how Baby Yoda in The Mandalorian drank some. An appropriate source would be "The Illustrated Catalogue of Soup", which is a secondary source focusing on soups. Should the Catalogue of Soup mention how Baby Yoda famously drinks some, then it is fair game for a popular culture section. By contrast, an article in Polygon reviewing the latest episode of the Mandalorian is NOT an appropriate source for a popular culture section on the "Bone broth" page, because it is not focused on the subject, which is soup related. CaptainEek ^{Edits Ho Cap'n!}⚓ 01:19, 11 September 2021 (UTC)

  I used this as one of the criteria to delete parkour in popular culture (the other was just "have an RS"). Izno (talk) 02:14, 11 September 2021 (UTC)

  CaptainEek, but the Polygon article is also relevant to the subtopic of "popular culture", which is what the main subject of IPC is all about, and if it mentions how Baby Yoda drank the bone broth, then the main topic of the article now becomes relevant to the subtopic as it relates to popular culture as well. There are more topics to consider staying focused on besides just the main topic since many articles contain subtopics (some of which are far removed from the main topic, IPC sections being a good example of this) and so opening the door for a narrow view that says content within subtopics must ignore the relevance to that subtopic and focus on only the main topic is generally a bad idea. Huggums537 (talk) 14:29, 13 September 2021 (UTC)

• Support the hell out of this. GenQuest ^"scribble" 14:51, 11 September 2021 (UTC)
• Support - Donald Albury 15:05, 11 September 2021 (UTC)
• Support per nom. ― Qwerfjkltalk 20:23, 11 September 2021 (UTC)
• Support. Nikkimaria (talk) 00:05, 12 September 2021 (UTC)
• Oppose proposal that contradicts set guidelines that clearly dictate notability shall not apply to content within articles. See WP:NCC WP:NNC. Not only does this proposal attempt to apply notability to content within articles, it also attempts to apply it to the value of reliable sources as well, which is something I think we should have another guideline clearly dictating doesn't apply to sources either. The purpose of notability is for determining if a subject warrants having an article, not for nitpicking over trivial details of subject matter content or determining value of sources. It tells you that in the very first and second sentence of the notability guideline. Wikipedia has gone wildly out of control with "notability mania" for far too long, and it's time to stop the madness and think about what we are doing. Huggums537 (talk) 07:23, 12 September 2021 (UTC)

  NCC is a naming convention, not sure what you may have intended to link. As WP:N indicates, notability can be and is used as an inclusion criteria for lists, and we've already had an RfC establishing sourcing standards for IPC content. Nikkimaria (talk) 12:27, 12 September 2021 (UTC)

  Nikkimaria, I meant to link to WP:NNC. You can see how I might have got the links confused as they are rather similar. I will strike the other link and correct it now that you brought it to my attention. As for the list criteria, it is the exception that can be, but does not have to be, not the rule. Notability does not apply to the vast majority of article content as I have pointed out in both the main paragraph of WP:N, the now corrected link I provided earlier, and in the nutshell of WP:N as well as all throughout it. This exists as an actual rule, not an optional exception that may or may not be such as is the case with the list criteria... Huggums537 (talk) 18:23, 12 September 2021 (UTC)

  Although the proposer has framed this as a notability-related idea, the proposal itself is not rooted solely in that policy; the reference to sources on the subject can also be understood as related to due weight. If no reliable sources on the subject discuss a particular IPC mention, it follows that our article also would not. Nikkimaria (talk) 18:55, 12 September 2021 (UTC)

  Nikkimaria, of course I agree if there are no reliable sources to support an IPC mention, an article should not, but that is not the WP:DUE policy this proposal is asking us to follow. Rather, the proposal is asking us to take two sources that do in fact both discuss a particular IPC mention, and come to our own conclusions about how reliable they are based upon notability in relation to the subject. This actually has nothing to do with due weight at all since we are still talking about the very same IPC mention that would otherwise be allowed into the article no matter which source is used, because you can't say, "I'm removing this content per DUE because the source isn't "notable", but then turn around and put the EXACT same content in per DUE with a different source that you have concluded is "notable". That's not how DUE works. You don't get to play both sides of the field. DUE doesn't apply to sources any more than notability does, it applies to article content. Huggums537 (talk) 23:10, 12 September 2021 (UTC)

  The "notability" framing was part of the intro, but the proposal itself does not mention that concept; it discusses sourcing. DUE is entirely based on sourcing, because the idea of DUE is that we represent things proportionally to their representation in sources. In that context, it's absolutely appropriate that different sourcing would change whether and how we include something in an article. Nikkimaria (talk) 00:25, 13 September 2021 (UTC)

  Nikkimaria, but this proposal never was talking about representing things proportionally to their representation in sources as DUE was intended either. Therefore, it runs the risk of damaging the current notability guideline by weakening it through setting precedents which go against it. Huggums537 (talk) 01:05, 13 September 2021 (UTC)

  I'm not sure how it could accomplish that? We make decisions about including or not including content within articles all the time. Nikkimaria (talk) 01:18, 13 September 2021 (UTC)

  Nikkimaria, well because the proposal itself actually does mention the notability concept considering the fact it requires content must now be sourced with reliable secondary sources, and not just mere mentions, but focused on the topic. Sounds very much like same requirements for articles being applied to content against notability. Setting a standard against existing guideline is what opens that can of worms... Huggums537 (talk) 01:37, 13 September 2021 (UTC)

  But "secondary" is not a consideration only in discussions of notability; it's a pretty fundamental part of WP:NOR. And the need for secondary sourcing in this area specifically has already been established by RfC. Nikkimaria (talk) 01:41, 13 September 2021 (UTC)

  Nikkimaria, as explained before, this isn't the same thing as your previous discussion though you are desperately wanting it to be. The old idea of needing secondary sourcing to include IPC entries is now being superseded by this new idea that IPC entries not only require secondary sourcing, but they now also require notability standards to apply to both the sources and the content being added, which is against current guidelines. Further, we are being asked to believe that it is ok to remove an entry per DUE presumably because the "bad" source holds a minority view, only to have the exact same entry reinstated per DUE because the "better" source now holds a majority view? This specific discussion about "secondary" is for sure a consideration about notability not DUE or NOR unless you want want to talk about the original research editors might be using to determine which sources they have concluded warrant a minority vs. majority view for the exact same content? Huggums537 (talk) 05:21, 13 September 2021 (UTC)

  We will need to agree to disagree on the interpretation of the proposal. I see it as a reasonable conclusion drawn from existing policy and precedent. Nikkimaria (talk) 11:53, 13 September 2021 (UTC)

• Support Good idea. De728631 (talk) 21:10, 12 September 2021 (UTC)
• Support This is the "directional relevance test" that prevents the mention of, e.g., hundreds of Pokemon on taxon pages, but doesn't argue against the mention of taxa on Pokemon pages. The connection is relevant one way but not the other, and that is normally reflected in the available sources. It's actually a rather common sense rule, and as such in wide practical application even if not codified. Let's codify it. --Elmidae (talk · contribs) 22:47, 12 September 2021 (UTC)

An illustration, just this minute reverted from Roe deer#Culture: In Hiawatha Longfellow depicts his hero killing a "roebuck" on the shores of Lake Superior, quite a feat since the roebuck only lives in Eurasia. Leaving aside the smart-ass tone and and the lack of sourcing - I think any rule precluding this kind of thing is quite obviously useful. --Elmidae (talk · contribs) 23:00, 12 September 2021 (UTC)

Elmidae, sure that's a good example, and I would support a proposal for lack of sourcing in IPC, but we don't really need one since you have just proved it can be done without it, and that is also not what this proposal is about at all... Huggums537 (talk) 23:34, 12 September 2021 (UTC)

That's why I said "leaving aside" these issues. The point is that the poem is irrelevant to the species, whereas the species may well be relevant to the poem (if you want to discuss how much natural history knowledge Longfellow put into his work or whatever). The requirement should be to demonstrate that relevance. --Elmidae (talk · contribs) 23:42, 12 September 2021 (UTC)

Elmidae, the species might very well be relevant to the poem, and the poem might not be directly relevant to the species itself, but it might be relevant to the species as it is related to the world "in popular culture", which is why it is in that particular section to begin with. I agree the smart ass tone and lack of sourcing are problematic, but again, existing policy provides that sourcing could have been applied, and the smart ass tone part removed, or the entire thing removed as you proved. This proposal has good intentions, but is ultimately more harm than good. Huggums537 (talk) 06:00, 13 September 2021 (UTC)

Also, the above mentioned about directly and indirectly relevant is another reason the proposal doesn't make much sense, since the proposal is asking that all content in IPC sections be directly related to the subject of the article, rather than the subtopic of the IPC section, which kinda defeats the whole purpose of the section in the first place. This isn't "directional" at all, and is actually impossible to be since we are not just talking about comparing the relevance of some random content to the topic (or vice versa), but rather the relevance of that content to the IPC section as well, which is another topic within the main topic. This proposal is essentially saying that article content is no longer allowed to have any relevance to the subtopic of the very IPC section it might be included in, but it must have direct relevance to the main topic exclusive of the relevance to the subtopic it sits in. Does that really sound like a sensible solution? Huggums537 (talk) 12:21, 13 September 2021 (UTC)

• Strong Support for this or something like it. Paul August ☎ 23:58, 12 September 2021 (UTC)
• Support, Elmidae has articulated my thoughts exactly. Cavalryman (talk) 05:39, 13 September 2021 (UTC).
• Two suggestions - I want to support this, but have two suggestions.
  1. These sources must be focused on the subject, NOT the cultural item - might modify this to be similar to the way we talk about notability, which is to say it doesn't have to be the subject of the source, but the source must provide some in-depth coverage of the subject, not just the cultural item. So, for example, if e.g. Polygon writes about the Mandalorian and goes off on a long tangent about the history of bone broth, that seems like at least a gray area worth considering.
  2. Regarding fair game for a popular culture section - It would be worth framing this as a minimum requirement rather than what absolutely determines inclusion. This might be assumed, but given the nature of "in popular culture debates" it may be worth articulating. — Rhododendrites ^talk \\ 19:48, 13 September 2021 (UTC)

     Rhododendrites, good ideas! I think I can craft some wording for point 2 (after ...fair game for a popular culture section add (this is not the only factor for inclusion, merely the minimum; other relevant policies apply)., but am a little more at a loss for point 1. Do you have a suggested wording? CaptainEek ^{Edits Ho Cap'n!}⚓ 01:26, 14 September 2021 (UTC)

• I'm frankly appalled that a long time experienced editor like Rhododendrites and even an admin like CaptainEek who are both very well respected members of the community are still attempting to apply notability guidelines to article content even after it has been pointed out this is against the guidelines. I did notice the masterful tactic to go around it by saying the intention was to frame it as something "similar to the way we talk about notability". I have a suggested wording. You could call it note-ability. That way you're technically not violating any notability guidelines while you apply something "similar" to them. Yeah, sounds good to me. I just might be good enough to get into the master tactic club one day... Huggums537 (talk) 20:08, 14 September 2021 (UTC)

  Guidance can change. No rule is written in stone on Wikipedia. Also, I argue that this is not an actual notability requirement. Notability requires that at least three sources exist for an article to exist. This is only requiring one source (like basically every other peice of content), it's just that that source needs to be related to the subject. CaptainEek ^{Edits Ho Cap'n!}⚓ 20:29, 14 September 2021 (UTC)

  CaptainEek, sure guidance can change, but it hasn't. Not yet. So, why do we even have it if nobody is going to bother following it? Also, I argue that if your proposal is in a situation where you find the need to argue your point in a debate about whether it is violating the guidelines or not, then that makes the proposal questionable. Lastly, my final suggestion for wording is not-ability, like a hyphenation of not notability. Lol. Oh my gosh! I crack myself up sometimes! Huggums537 (talk) 20:48, 14 September 2021 (UTC)

  What better time to change it then now? Sungodtemple (talk) 21:29, 14 September 2021 (UTC)

  Notability requires that at least three sources exist, @CaptainEek? I've always heard that it was at least two. WhatamIdoing (talk) 18:30, 15 September 2021 (UTC)

  @Huggums537: Rhododendrites ... attempting to apply notability guidelines to article content. No, saying that we could explain X in a manner similar to how we explain something Y doesn't mean X=Y. If we wanted to write a new policy about something and wanted to convey "it's not explicitly against the rules but it's usually a bad idea" I might say we should explain it like we explain COI. That doesn't mean we should apply the COI policy to whatever the new policy is. But ultimately, yes, using the word "notability" in Eek's original proposal is a mistake. That word is loaded, leads to confusion, and leads to lots of unnecessary subthreads over the use of that term. This isn't actually about notability it's about inclusion criteria for a particular kind of material. Some people throw the word "notability" around about this stuff, some people say "noteworthy"... whatever word people are using, we can tell from the context that we aren't talking about WP:N because that's not about content, and we're talking about content. — Rhododendrites ^talk \\ 20:46, 14 September 2021 (UTC)

  Rhododendrites puts it better than I do: I did not intend this to be a notability requirement, I was simply at a loss for better words. CaptainEek ^{Edits Ho Cap'n!}⚓ 20:54, 14 September 2021 (UTC)

  Rhododendrites, as I just explained to your our colleague, if you find yourself in a situation where you feel the need to defend the proposal about it violating guidelines or not with a bunch of technical jargon or other debate only proves the proposal is questionable. Huggums537 (talk) 21:00, 14 September 2021 (UTC)

  ... Eek shouldn't have said "notability". Nobody's trying to apply the criteria for an article on Wikipedia to whether we include a cultural reference. If you think the proposal is bad or would prefer to oppose until "notability" is nowhere to be seen, I completely get that, but can we move on from the semantic line of argumentation to what's actually being argued? I would add that if you find yourself in a situation where you feel the need to stand by an objection even after it's pointed out that nobody actually supports the thing you're objecting to, it may prove the objection is questionable. — Rhododendrites ^talk \\ 21:15, 14 September 2021 (UTC)

  Rhododendrites, you are right. Eek shouldn't have said "notability". Likewise, you shouldn't have said "similar to the way we talk about notability". I see a lot of "shouldn't haves" here. Also, I would add that if you find yourself in a situation where you feel the need to stand by an objection even after it's pointed out that nobody actually supports the thing you're objecting to, it may prove the objection is questionable. Or, it could just mean nobody knows me and everybody knows the nominator so the natural tendency is to support who you know and trust because they have proven themselves, and be watchful of the newcomer because you don't already trust them yet. Or, it could be that the nominator has been around way longer so they have way more followers. It could also be that newer editors who might feel the same way I do are simply not aware processes like this exist or they may not be skilled enough to participate. There could be any number of actually reasonable explanations for not having any support other than my objection being questionable. OTH, the only really reasonable explanation my colleagues would be having to try to prove that this proposal is not violating any guidelines is because it is questionable to begin with. Now, as much as I would love to argue the finer points of what's actually being argued, I think you made all of your points clear. I also think my "semantic line of argumentation" is pretty clear as well, and it sounds like you don't wanna hear any more "semantics", and I sure as heck don't wanna hear no more technical or policy jargon, so I guess that's a wrap. Huggums537 (talk) 22:15, 14 September 2021 (UTC)

  Rhododendrites, I guess I just could not resist to argue the finer points with you. This isn't actually about notability it's about inclusion criteria for a particular kind of material. Well, inclusion criteria is just different words for notability. Almost everything we have about inclusion, or inclusion criteria links right back directly to notability. See: WP:Inclusion, WP:Inclusion (essay), and the most damning of all, WP:Inclusion criteria which is just a redirect to WP:N. Huggums537 (talk) 00:25, 15 September 2021 (UTC)

• Just for the record, I am also against any proposal to apply a rule to any one subtopic that I would not find reasonable to apply across all other subtopics. The reason for this being that it opens the door for more and more subtopics to be restricted to the rule until some idiot thinks it is a good idea for all of them. Huggums537 (talk) 20:08, 14 September 2021 (UTC)

  Watch out for the slippery slope! Sungodtemple (talk) 21:29, 14 September 2021 (UTC)

  Yes, please do. Watch your step. Be careful. Take care. Don't take any wooden nickels either. Also, please note the above referenced article acknowledges the slippery slope as a logical argument in critical thinking (as opposed to a fallacy). Huggums537 (talk) 23:45, 14 September 2021 (UTC)

• Oppose on the common sense ground that if something is noteworthy but not independently notable, imposing such a requirement will merely force editors to put it in other parts of the article rather than in a "popular culture" section. BD2412 T 20:12, 14 September 2021 (UTC)
• Support: Basically WP:TRIVIA except it applies to sentences instead of sections. And some sections are just one sentence. Sungodtemple (talk) 21:29, 14 September 2021 (UTC)
• I support the intent of this proposal, but do worry about the potential confusion over notability, whether intended or not. I've developed the proposal a little, as noted in the section below, and suggest tightening up the existing concept of 'noteworthiness' instead. Comments would be very welcome there. MichaelMaggs (talk) 02:32, 15 September 2021 (UTC)

Proposal by MichaelMaggs

Our biggest practical problem is that we don't have a consolidated set of guidelines on cultural material that can be easily linked to. The rules are spread across various guideline pages, with the most important substantive rule actually being on an MOS page, where many editors will never find it. MOS:CULTURALREFS notes that the 2015 RfC was closed with "The consensus is very clear that a secondary source is required in almost all cases. A tertiary source is even better, if available. In the rare case that a primary source is judged to be sufficient, it should be properly cited. The source(s) cited should not only establish the verifiability of the pop culture reference, but also its significance."

This is a proposal to bring the rules together into a single new guideline. It's based on CaptainEek's proposal and editor feedback, but with a few modifications. Specifically I've added more explanatory material, have made use of the existing concept of noteworthiness rather than inventing a new meaning for notability, and have based it on what the secondary source establishes not what it 'focuses on'. I doubt in practice that this would represent a radical change, but it should make it easier for editors to curate Cultural reference sections and to explain to new editors how they work.

Noteworthiness of cultural references

Some articles include a section devoted to the subject's cultural significance, often called "In popular culture", "In the media", "Cultural references" or the like. Especially where they are presented as lists, such sections can if not effectively curated degenerate into mere collections of trivial or otherwise non-encylopedic references. This guideline applies to all Cultural reference sections, regardless of the specific title used.

As explained at WP:NNC, the general notability guidelines define how notable a subject has to be before it can have its own Wikipedia article. Those guidelines do not, in themselves, apply directly to article content, which means mean that (with the exception of certain lists that explicitly restrict inclusion to notable entries) an individual item of content such as a cultural reference is not normally required to demonstrate standalone notability. However, the fact that a reference may be verifiable does not automatically make it suitable for inclusion (WP:VNOT and WP:INDISCRIMINATE). For example, evidence that the article's subject verifiably appears in a particular cultural context such as an episode of a TV series is not in itself enough.

As with all content, a cultural reference must be sufficiently noteworthy to be mentioned within the context of the article. 'Noteworthy' in this context means capable of being supported by at least one secondary source that establishes not only the verifiability of the cultural reference, but also its significance to a discussion of the article's subject. Note that this is a one-sided test: it is not enough for the article's subject to be of significance within the cultural context of the reference.

Example

An imaginary example may be useful. Assume that in a Cultural references section of the Bone broth article, an editor has added a reference to the fact that some soup of that type was drunk by Baby Yoda in an episode of The Mandalorian. Is that a noteworthy addition to the article? That will depend on the availability and content of the sources:

Unsourced, or supported solely by the primary source of the episode itself

• If challenged, no, since no secondary source has been supplied.

Sourced to a national newspaper article that discusses how important the broth-drinking incident was to the development of the overarching storyline of the entire Mandalorian TV series

• No, since the source does not establish the significance of the specific drinking episode to the article's general discussion of its subject, namely bone broth. No matter how prominent the incident may be within its own cultural context, it cannot be considered noteworthy unless it is significant within the context of the article's subject. In this example, the incident would best be added not to Bone broth but to The Mandalorian.

Sourced to a cookery book in which a recipe for bone broth mentions that Baby Yoda famously drank some

• Possibly yes, as this is a secondary source that establishes the significance of the incident within the context of a discussion of bone broth. Of course, editors may still hold the cultural reference to be insufficiently important even in that context, per WP:INDISCRIMINATE, but in principle the source should be usable.

The Manual of Style has further information on the preferred layout of cultural reference material: see MOS:CULTURALREFS

Feedback would be welcome. MichaelMaggs (talk) 18:40, 14 September 2021 (UTC)

MichaelMaggs, I think this proposal has the heart in the right place, but I have some concerns. One can be easily fixed, but the other is so disturbing it might affect the whole proposal. First, I think this: Those guidelines do not, in themselves, apply directly to article content, which means that (with the exception of certain lists that explicitly restrict inclusion to notable entries) an individual item of content such as a cultural reference is not normally required to demonstrate standalone notability. needs to be changed to: Those guidelines mean that (with the exception of certain lists that explicitly restrict inclusion to notable entries) an individual item of content such as a cultural reference is not normally required to demonstrate standalone notability. because the previous sentence refers to both WP:NNC and WP:N, but the way it is currently written it's not crystal clear to the reader exactly what "apply" means or which one of these guidelines is being referenced when it says "those guidelines don't apply directly to article content". Better to just leave that part out if it's going to confuse things. Now for the doozy. I went through the MOS you linked to and found no references at all to "Noteworthy", and the only three references I found regarding notability were all three related to the main topic of a subject and had nothing to do with the treatment of the cultural references. Your proposal mentions "noteworthy" something like 4 times (not counting the subtitle). That alone makes this proposal even more problematic than the one Eek tried to come up with and I would promptly oppose it once voting started. I'm sure you are probably more than well aware of this by now, but I refer you to: WP:NOTEWORTHY because I think it is rather ironic that this is where that link leads to... Huggums537 (talk) 23:04, 14 September 2021 (UTC)

On your first point, I've made the clarifying change you suggested. On the second, I'm sorry to hear that you intend to vote against this proposal as you have against CaptainEek's, but there's nothing remotely "disturbing" about it. As I mentioned, 'noteworthiness' is a concept already used in WP:NNC (or WP:NOTEWORTHY if you prefer) but it's currently undefined. I'm proposing that 'noteworthy' is clarified so that in the specific context of cultural references it is defined as "capable of being supported by at least one secondary source that establishes not only the verifiability of the cultural reference, but also its significance to a discussion of the article's subject", a slightly rephrased version of the 2015 RfC closure. MichaelMaggs (talk) 02:20, 15 September 2021 (UTC)

MichaelMaggs, thank you for making the suggested change. However, noteworthy can't be a concept being used in NNC because it isn't even defined just as you said. Also, the way it's being used there isn't so much a concept as it is an interchangeable term with "content coverage". You could remove the entire "noteworthy" parenthetical statement from that statement leaving you with: Content coverage within a given article or list is governed by the principle of due weight and other content policies. or you could just as easily interchange it with: (i.e. whether something is noteworthy enough to be mentioned within the article or list) is governed by the principle of due weight and other content policies. and you would still be saying the same thing, but the significance of all this interchanging is that the guideline is clearly telling us that both "content coverage" and "noteworthy" are already governed by DUE and other policies. I've gone into some detail about how none of these proposals have much support in DUE. The only policies you have provided to support this proposal are WP:VNOT and WP:INDISCRIMINATE. Both of these are great policies for removal of bad stuff, and even prevention, but we already do that anyway, and neither of those policies in any way support requiring significant coverage similar to notability for content, and we actually have guidelines against it. You would have to show me policy that supports such a proposal, especially in DUE since the guideline said DUE is the principal governor of noteworthy, but if you can find anything in WP:V, WP:NOR, or WP:NPOV that supports regulating content in this manner, then I will accept that too. Huggums537 (talk) 06:05, 15 September 2021 (UTC)

MichaelMaggs, P.S. I got a little carried away with the whole "disturbing" thing. Pay no attention to my occasional melodrama... Huggums537 (talk) 06:35, 15 September 2021 (UTC)

Huggums537, I'm really sorry. I've read every word of the many postings you've made in response to this and the above proposal but I'm truly unable to discern your underlying rationale. I think you are arguing that things can't be done because they aren't compatible with the wording of existing guidelines. But the whole point is to change and improve those guidelines. MichaelMaggs (talk) 10:04, 15 September 2021 (UTC)

MichaelMaggs, ok so if I am understanding you correctly, what you are saying is that you do in fact see my argument about these proposals being against the guidelines, but your counter argument is that the whole point is to intentionally go against them in order effect a change in them for the purpose of improvement? To that I would say that if you intend to go against the current guidelines and/or effect any changes in them, then the discussion should be brought before an even larger community with proper discussion notices posted at both WP:N, the central discussion area of village pump, and anywhere else a controversial guideline change might be made known to the public... Huggums537 (talk) 14:14, 15 September 2021 (UTC)

Huggums537, Oh dear, I fear you've expended a lot of time and effort arguing on the basis of a false premise. Of course the proposals aren't in line with existing guidelines. They suggest improvements and changes: that's the whole point. I thought that was quite clear, in that CaptainEek referred to the "substantive change that we could implement", and I explicitly suggested "a single new guideline". This is a preliminary discussion about possible changes, and everyone understands that any consensus to change a guideline that emerges here will naturally have to be presented to the wider community in a formal way before anything actually gets implemented. MichaelMaggs (talk)

MichaelMaggs, ok then. You might be right about argument over a false premise, but I feel my time has been well spent making some valid points. Huggums537 (talk) 17:10, 15 September 2021 (UTC)

Also, I'd like to point out that unless the intention is to modify or replace current existing guidelines, then "a single new guideline" that is along the same lines of the ones being proposed here would be in direct conflict with the currently existing guidelines. That is the whole basis of my underlying rationale. For example, if you made this "single new guideline", in order to make all guidelines compliant with the others, there would then also have to be discussion about removing all the instances in WP:N where it talks about how notability applies only to articles. (There are many.) Then, there would have to be talk about removing the whole section dedicated to the understanding that notability doesn't apply to content. All this in order for the new guideline to be compliant. If you are going to start talking about simply writing guidelines that conflict with each other and just letting it ride, then we might as well stop calling it guidelines and start calling it Wikipedia:Optional choice - Choose your own adventure! Huggums537 (talk) 18:04, 15 September 2021 (UTC)

Yet another proposal (sorry)

Based on the work above, but I feel a little clearer, and including the suggestions I listed above. If unhelpful, let me know, and I won't put up much of a fuss about collapsing it. :) It's much in line with the original proposal b CaptainEek above, so I also don't mind if we just swap it in up there (if participants feel like it's an improvement, of course). — Rhododendrites ^talk \\ 04:03, 15 September 2021 (UTC)

Articles often include material about cultural references to the subject of the article. Sometimes this content is in its own section ("in popular culture" is the most common, but also "in the media", "cultural references", etc.), and sometimes it is included with other prose. When not effectively curated, such material can expand in ways not compatible with Wikipedia policies like what Wikipedia is not and neutral point of view.

Cultural references about a subject should not be included simply because they exist. Before including a reference in an article, that reference should be discussed in reliable secondary sources which specifically link the cultural item to the subject. These sources should cover the subject of the article in some depth, and not simply mention it in a source about the movie, song, television show, etc. which referenced it.

Take for example the subject of bone broth. You may wish to include mention of how Baby Yoda in The Mandalorian drank bone broth. An appropriate source might be Bon Appetit magazine, which is a reliable source for articles about soup. If Bon Appetit mentions how Baby Yoda drank bone broth, it may be suitable for inclusion in the bone broth article. By contrast, an article in Polygon reviewing the latest episode of The Mandalorian which does not go into any detail about bone broth but simply mentions that Baby Yoda drank some in that episode is not sufficient to include in the article because it does not provide any significant coverage of the subject of the article.

Note that this sourcing requirement is a minimum threshold for inclusion of cultural references. Consensus at the article level can determine whether particular references which meet this criteria should be included.

• I support this version, as it accomplishes what I intended, as well as dealing with some matters I hadn't considered. More than happy to have this be swapped in for my version. CaptainEek ^{Edits Ho Cap'n!}⚓ 05:01, 15 September 2021 (UTC)
• Rhododendrites, this seems more reasonable. Where would you intend to implement said proposal? I meant to ask this of CaptainEek on the original proposal, but forgot. This seems like important information to me, but nobody else seems to be worried that much about it... Huggums537 (talk) 05:22, 15 September 2021 (UTC)

  Good question. I wasn't sure, either, and don't have a strong opinion. — Rhododendrites ^talk \\ 15:53, 15 September 2021 (UTC)

  Actually, now that I'm looking at it, this just seems like the same proposal rewritten. There is nothing whatsoever in WP:DUE that supports the idea of making it a content requirement that you must have a secondary source, and the only policy or guideline that supports the idea that a reliable secondary source must have more than a mere mention of the subject, or that secondary sources must cover the subject in depth, or have "significant coverage" is WP:N (which does not apply to content WP:NNC), and all these WP:Inclusion criteria, are supposed to apply only to articles, not content. Huggums537 (talk) 17:31, 15 September 2021 (UTC)

  Words have meaning outside of what someone chose to assign as a redirect target. We make decisions about what to include or not include within articles all the time; we also regularly codify these sorts of decisions in our policies and guidelines (some quick examples: WP:LPNAME, WP:GAMECRUFT). "Inclusion" as a concept is not tied solely to notability. Nikkimaria (talk) 00:22, 18 September 2021 (UTC)

  Nikkimaria, Words might have meanings outside of redirect targets, and policies or guidelines, but that would indicate those meanings only exist in the minds of the Wikipedified. You may very well have been making decisions about what to include or what not to include within articles for a very long time. but you have been doing so against current policy and guideline. WP:LPNAME is more about privacy issues than it is about "inclusion", therefore a poor example, and I actually do see a clear violation there in the last sentence, but just because WP:Other stuff exists doesn't mean it should be repeated. WP:GAMECRUFT is a MOS, not a policy or guideline. Nevertheless, I think you should read it again since everything there actually is tied to very well to notability in that the directive applies to the notability of gaming articles not content just as it should when it comes to notability and all the "inclusion criteria" is focused on the noted exception; lists. Although, I do see a violation of the notability guideline with #13 and #15, but again, just because violations exist don't mean we should repeat them, we should fix them. Huggums537 (talk) 23:22, 18 September 2021 (UTC)

  MOS is a guideline, and much of the material in that guideline (aside from #1 and #2) has nothing to do with notability and everything to do with what to include within gaming articles. What specific policy or guideline do you think is being "violated" in making decisions about content within articles, when you have argued repeatedly WP:N does not apply to content? What "clear violation" do you feel exists in the WP:BLP policy, and why would you believe N would take precedence over other policies? Nikkimaria (talk) 23:31, 18 September 2021 (UTC)

  Nikkimaria, WP:NOT also has plenty about what not to include in articles as well. You could just link to that too, but everything there will offer just as little support for this proposal as what you have linked to. The only guideline that offers the most support for this proposal also just happens to be the same one that says it isn't supposed to apply to something like this. The problem you have identified with what you linked to is that policies, guidelines, and editors are conflicting with each other in the first place. So, I think identifying this conflict is the first step in solving the problem. Therefore, your question about what violation I think exists is a valid one. The conflict (i.e. "violation") arises when we have a policy : However, names of family members who are not also notable public figures must be removed from an article if they are not properly sourced. and it is worded so ambiguously that it could mean several things, including one interpretation which is against our guidelines about applying notability to content. So, the problem isn't about "precedence", it's about "conflict", and why we have clear directives telling us that notability is not supposed to apply to article content, but yet you just gave us examples of where people have introduced this so called "concept" into the MOS at WP:GAMECRUFT #13, #15 and I see #8 also now. Huggums537 (talk) 00:32, 19 September 2021 (UTC)

  We've gotten well off the track of what the actual proposal is now, so I'll suggest you take any perceived conflicts between our policies and guidelines to a different venue. Nikkimaria (talk) 01:00, 19 September 2021 (UTC)

• Notice - this discussion has slowed down considerably. Considering there seems to be broad agreement about the basic principles, I've boldly updated MOS:POPCULT. I only see a couple people dissenting throughout these threads (not counting the original thread about the term "popular culture," but also including past discussions about sourcing/inclusion/what's usually preferable). So let's see if we can shift the conversation to discussion over specific wording at that talk page rather than here? — Rhododendrites ^talk \\ 14:52, 24 September 2021 (UTC)

  Thanks for your efforts here. Regarding, "Rather, all such references should be discussed in at least one reliable secondary source..."...I wonder whether this language should be strengthened, perhaps in accordance with the RfC referenced at WP:IPCV, which uses the language, "a secondary source is required in almost all cases." To me, that's a bit stronger than "should". DonIago (talk) 20:35, 24 September 2021 (UTC)

  @Doniago, do you want a "true" secondary source, or just not a PLOT-level self-source? Imagine that the content in question is whether to mention the film Mr. Holland's Opus in the articles about Minuets in G major and G minor and A Lover's Concerto. Is it:

  • enough to source this claim to the film itself? (primary, non-independent)
  • enough to source it to an interview with the film's director that mentions the names? (primary, non-independent)
  • enough to source it to a magazine article that mentions the names? (primary, independent)

  Or do you need a "true" secondary source, which is one explains why these particular songs were chosen and what effect was produced as a result? (If that true secondary is by the film's makers, it's a non-independent secondary source; if it's by someone unconnected, it's an independent secondary source.) WhatamIdoing (talk) 20:17, 28 September 2021 (UTC)

  I think it depends on the claim. If it's "the music is played in the film" (say, as part of a short list), then the film's credits may be sufficient. If information about the music being played in the film is being added to an IPC section though, essentially claiming that the occurrence of the music in the film has some level of significance, then it should be a source that gives some context to the use of the music within the film beyond the mere fact of it. If it's an interview with the film's director that mentions why the music was chosen, for instance, that could work. In my experience 75% of IPC items are problematic because no source is provided, with an additional 15% being problematic because the source doesn't discuss the item in any significant detail. Is this helpful? DonIago (talk) 20:53, 28 September 2021 (UTC)

  Super helpful. Also, I tend to agree with you. ;-)

  I think it might be helpful to say that there needs to be "a source that gives some context or explains why it is significant, beyond the mere fact of it". That would prevent editors from incorrecting each other about whether the cited source is "really" a secondary one. It would presumably include a wide range of sources, but all of the usable sources would be able to support a sentence longer and more significant than "This music was in this film" (or "This disease was mentioned in one of the 17 years that Grey's Anatomy was on television"). WhatamIdoing (talk) 23:53, 28 September 2021 (UTC)

  The analogy I like to use is that the source should establish not just that the tree fell in the woods, but that it made a sound when it fell. :p But yes, since we're talking specifically about IPC sections, I agree with everything you just said. The language at WP:IPCV may be useful in terms of formulating the specific verbiage. Cheers! DonIago (talk) 02:36, 29 September 2021 (UTC)

  @Doniago, and @WhatamIdoing, could either of you explain to me how this little mini-discussion you just had about requiring "significant coverage" in sources "beyond the mere fact of it" for simply adding minor content to any article or section isn't just this notability guideline being applied to content instead of being applied to the creation of articles as the notability guideline was intended? Is the guideline not clear that notability was not intended for content, but for the creation of articles? 05:04, 4 October 2021 (UTC) Huggums537 (talk) 05:04, 4 October 2021 (UTC)

  As I mentioned in my first comment in this thread, there was an RfC that established that when adding IPC content secondary sources are required "in almost all cases". I don't believe anyone involved in that RfC raised the question that you're raising now. If that consensus bothers you, the RfC was long enough ago that you're welcome to raise the question again. Otherwise, you seem to have an objection here, and I'm not sure what it is. DonIago (talk) 05:16, 4 October 2021 (UTC)

  My objection is to the onslaught of various proposals about some "mysterious concept of basic principals" that is supposed to solve article content issues by requiring things such as "significant coverage", and "more than existence in sources" from a community who is seemingly oblivious to the fact that this concept already has a name entitled "notability". Except, our existing guidance tells us this concept is strictly for the creation of articles, not parsing out article content. If it isn't obvious to you by now that my objection is with the direct conflict to the existing guidance, then I'm not sure it really matters what my objection is. Huggums537 (talk) 07:49, 4 October 2021 (UTC)

  @Huggums537, it's not about the notability guidelines. It's about WP:PSTS: "Wikipedia articles should be based on reliable, published secondary sources". In this case, we're talking about what it would mean for this specific section's contents to be Wikipedia:Based upon secondary sources.

  All articles should be primarily citing secondary sources. Why not this section, too? WhatamIdoing (talk) 20:46, 4 October 2021 (UTC)

  it's not about the notability guidelines. So, that's what they keep telling me, except we haven't just simply been talking about making sure content has reliable sources that are secondary. We have been making additional inclusion criteria not covered in the slightest little bit by WP:PSTS which includes "significant coverage" among other things that have way more to do with WP:NRV than any other policy or guideline you could possibly link to. You can easily see that it only stands to reason if this were simply about adding sources as you claim, then the existing guidance that you have linked to would be sufficient when combined with other policies we have about verifiability and there would be no need for any of these abusive and WP:Creepy proposals. So, why not this section too? Because content within articles (including sections) aren't supposed to be having that much to do with WP:NRV or any part of WP:N according to the existing guidance at WP:NNC. Huggums537 (talk) 23:33, 4 October 2021 (UTC)

  @Huggums537, you are the only person to use the words "significant coverage" in this mini-discussion. Naturally, nobody can tell you why you think they were using words that they didn't use.

  I wonder, though, whether the answer to your real question is in Wikipedia:Balancing aspects. A mere passing mention in a source suggests that we are talking about "minor aspects of its subject", whereas "a source that gives some context or explains why it is significant, beyond the mere fact of it" suggests that the detail is not merely a minor aspect, and that it should be included in the article "with a weight proportional to its treatment in the body of reliable, published material on the subject". WhatamIdoing (talk) 01:05, 5 October 2021 (UTC)

  It seems we are just mincing words here. Sure, I've been the only one to use the exact phrase, "significant coverage", but that is only because using that terminology was easier than repeating how others in the "mini-discussion" have talked about 1) levels of significance in relation to claims made in IPC sections, 2) levels of significance in relation to the details of sources, and 3) the significance of content beyond the mere fact of it. All of which are notability concepts that could be summed up as "significant coverage". I think anyone, including myself, would agree with you that, "a source that gives some context or explains why it is significant, beyond the mere fact of it" suggests that the detail is not merely a minor aspect, and that it should be included in the article "with a weight proportional to its treatment in the body of reliable, published material on the subject". However, this statement also implicitly suggests that material should not be included at all (different from being included proportionally and also an WP:Inclusion criteria) if the source isn't giving "significance". Again, making it go back to a point about notability above and beyond simply being about sourcing or proportion. What I hear the bulk of the community saying is that we have a problem with trivia laden IPC sections that are usually poorly/unsourced, and even though we have sourcing policies already in place to remedy this, we propose some new instruction creep that will conflict with existing guidance, which will by extension, conflict among editors as well. Problem solved. Huggums537 (talk) 04:34, 5 October 2021 (UTC)

  • SIGCOV is a piece of jargon whose meaning has almost nothing to do with the plain English terms. We can talk about a source giving significant attention to a fact without caring about SIGCOV.
  • If no source (including sources other than the one I'm looking at) suggests that a given piece of information has any significance/importance/salience to the article's subject, then why would you want to include that piece of information in that article? I mean, it might be both true and verifiable that Joe Film ate an apple on the morning of his wedding, but why would editors include that fact in the Wikipedia article about Apples, if there are no reliable sources that indicate his wedding breakfast menu is a relatively important thing for people to know about apples?

  WhatamIdoing (talk) 20:39, 5 October 2021 (UTC)

  I want to add that you, Nikkimaria, and others who keep trying to prove how these proposals are backed up by all these policies and guidelines other than WP:N will never be able to escape the fact that whatever any one of these proposals might claim to be based upon, they will all still contain those parts which makes them based on notability as well. I think a good analogy would be to think of the proposals as a mixture of sweet tea. The community is saying, "we have brewed some really good sweet tea here that is based on 99% pure organic cane sugar!", and I'm over here pleading, "yeah, but that sugar has got 1% Ricin above and beyond the 99%. I'd really think twice about having any of that if I were you." Huggums537 (talk) 05:19, 5 October 2021 (UTC)

  I don't think so. Once we've decided that an article about Apples should exist, then we're finished with our advice pages on how to decide whether the article should exist, and we move on to the core content policies.

  It's true that our advice on whether the article should exist coordinates with the core content policies. That is intentional, and I suspect that you would think us all rather stupid if we wrote the notability rules to include subjects that can't be verified. WhatamIdoing (talk) 20:46, 5 October 2021 (UTC)

Worthy?

Just an aside and probably out of sequence, but we need to tread carefully around the word noteworthy. In general, notability talks about a subject having been noted rather than a subject somehow being worthy. (Just wander through the archives of Wikipedia talk:Notability to see plenty of previous discussions.) So, inclusion in WP is about a subject already having been included in other sources, not whether we have a view about how worthy a subject might be for inclusion. The distinction is probably core to much of the IPC discussion – we should not add items to IPC just because we think they should be there (however interesting or entertaining they can be), but because other sources have already noted the connection. — GhostInTheMachine ^{talk to me} 08:23, 15 September 2021 (UTC)

GhostInTheMachine, if you were wandering through talk pages on the WP:N pages, then these distinctions that you have been explaining to us between "noted" or "worthy" is how inclusion applies to articles, not the content within them. To say it a better way, we would rephrase your own statement to say: So, inclusion in WP is about a [subject's article] already having been included in other sources, not whether we have a view about how worthy a subject might be for [article] inclusion. That means everything you just explained about these distinctions is not core to the IPC discussion, it is in fact irrelevant to it. That is what the bulk of the community is failing to grasp. They are confusing main topics (articles) with subtopics (sections) and subjects (which could refer to content or an article title) so it's very easy to see how everyone gets confused so easily. Wikipedia needs to come up with less confusing naming conventions or editors just need to get better at deciphering the madness... Huggums537 (talk) 14:30, 15 September 2021 (UTC)

The reason I keep driving these point home is because people seem to be blissfully unaware that they are wanting the notability policy to support their very well intentioned notions that they should be able to make inclusion requirements for content that talks about such things as distinctions between "noted" and "worthy", or "significant coverage in secondary sources", and "inclusion criteria". However, when it is pointed out to them that the notability policy actually does not support this well intentioned notion, but clearly says it is intended to be used for articles, not content, and even has a section specifically dedicated to talking about how it doesn't apply to content, they start to seek support for it elsewhere, such as DUE, but eventually they will find that support for it only exists in the mind of the Wikipedified... Huggums537 (talk) 15:27, 15 September 2021 (UTC)

Section break for new comments to support/oppose

• totally oppose. The phrase "popular culture" emerged organically based upon common popular <ahem> usage. on that basis, it should be retained. I see no basis for discarding or proscribing it in any way. and by the way, there is a clear and highly significant distinction between forms of popular culture such as comic books and rock music, and the more classic, long-standing, and higher elements of our culture, such as classic literature, music and art from past centuries. that is the whole point of this phrase. ---Sm8900 (talk) 🌍 14:05, 15 September 2021 (UTC)
  • Putting this at the bottom may be confusing, as only the top part of this thread is about the phrase itself. The rest of this discussion is about the content that goes in such sections (under any name). Perhaps it makes sense for us to start a new section at the bottom of this page for the content-focused (rather than terminology-focused) proposal(s), so as to avoid confusion. — Rhododendrites ^talk \\ 16:47, 15 September 2021 (UTC)
    • @Rhododendrites:, those are excellent points and suggestions. whatever method you think best is totally fine and acceptable to me. thanks for providng your valuable input and corrections. ---Sm8900 (talk) 🌍 16:53, 15 September 2021 (UTC)
      • I agree, unsure what exactly this section is voting on. CaptainEek ^{Edits Ho Cap'n!}⚓ 19:28, 15 September 2021 (UTC)
        • Me three. I thought maybe this was a response to the OP way up top, but wasn't sure... Huggums537 (talk) 17:27, 16 September 2021 (UTC)
• There are two things that Wikipedia has from the beginning done notably well: Computer technology, and popular culture. Back in 2001, thee weevery few geneally accessible sources reliable forthe sort of computer articles, especially on open software, anywhere near as comprehnsive or good as WP. In 2001 there were very few serious academic sources or reliable non0fan sources of any kind, bout many aspcts of popular culture. Most of the many journals now in existnece weren't yet started; the major humanities journals and indexes ignored it. Again, things are better now, but I think most people in the world think its the one best source for this domain, a domain which is appaently he major concern of hundreds of millions of people. How else would people like me even know about this part of the world? These sections, even when they are inherently trivial, are often interesting--who among us here really always skips over for them? DGG ( talk ) 06:47, 20 September 2021 (UTC)
• Oppose. Pop culture is extremely turbulent, normal culture lasts. In order to show what span something has been culturally significant for, seeing what timespan it has been used in popular culture makes sense. We can see that Picasso was culturally relevant longer than OJ Simpson because one is featured in works for a longer time and the other isn't. It also doesn't make sense to just rename it to to "Culture" because the fluid changes in pop culture clash with the lasting traditions of normal culture and it's important to keep them distinct. Plutonical (talk) 14:07, 29 September 2021 (UTC)

My proposal

I actually worked on banging together some guidelines for this a while back.

1. if a section is "X in popular culture", X should be a proper noun, otherwise it doesn't really have a unique identity to be displayed in popular culture. "Clothes in popular culture: characters on Star Trek wear clothes."
2. if X has appeared in Y, but Y is not itself the topic of a Wikipedia article, it doesn't get mentioned.
3. if X appears in Y, but is not both indispensable and central to Y, then it doesn't get mentioned. DS (talk) 04:45, 23 September 2021 (UTC)

   DragonflySixtyseven, this reverts directly back to my same old arguments of all the previous proposals, in that these very outdated and "Wikipedified" ideas about what the guidelines should be (2009) are in direct conflict with the directives of the current notability guideline which clearly says in the nutshell; The notability guideline does not determine the content of articles, but only whether the topic should have its own article. and in the lead; These guidelines only outline how suitable a topic is for its own article or list. They do not limit the content of an article or list... plus a whole section of the notability guideline dedicated to the very subject: WP:NNC. So, to say that a topic "must have a Wikipedia article" {i.e. must be notable) just to be included as some minor content within an article is a clear violation of, and direct conflict with the current guideline.

   Besides, the proposal makes littles sense anyway.

   First, it is essentially saying that only articles with titles that are proper nouns may have "IPC" sections because articles with other kinds of titles somehow don't have a "unique identity" (whatever that's supposed to mean). Then, confuses things much further by saying only articles with proper noun titles have IPC sections that must contain topics that have Wikipedia articles, and only these proper noun articles must have IPC topics that somehow connect back to the original proper noun article. There are so many logical content restriction flaws in it, that it makes me grateful the current guidance advises against applying notability to content. Huggums537 (talk) 18:50, 23 September 2021 (UTC)

Enable Article / Talk tab bar for mobile anon users

If you visit https://en.m.wikipedia.org/wiki/Mona_Lisa while logged in, you'll see the "Article Talk" tab bar. ("minerva__tab-container" element) But if you're logged out, this tab bar goes missing and there's no way to access the talk page unless you manually alter the URL. This turns out to be by design and now consensus is required for a configuration change to ensure that anyone who can edit can also reach talk pages. — Alexis Jazz (talk or ping me) 11:29, 22 August 2021 (UTC)

• Support as proposer. — Alexis Jazz (talk or ping me) 11:29, 22 August 2021 (UTC)
• Support, Obviously. Sometimes I really do question if the WMF understands the site that they run, this is supposed to be a collaborative encyclopaedia building site - how on earth is collaboration supposed to occur when you hide the main methods of communicating from the vast majority of users? The requirement for consensus seems to be backward here - removing the ability for anonns to communicate on mobile should have required community engagement, restoring longstanding functionality should be the default. The rationale for removing talk page access for all mobile annons seems to be a combination of "mobile IP users are obviously too stupid to understand the concept of a talk page and would just fill them up with nonsense and spam" (I'd like to see the data that supports this, according to the phabricator task this is based on them putting a talk page link in a rarely visited settings page and being surprised that people didn't understand what it did???) and that the mobile talk pages are too buggy to be publicly available (In which case they need fixing, not hiding.). I just can't see the sense in having a huge body of users who are allowed to edit the site but are barred from discussing their editing - it just seems dumb. 192.76.8.74 (talk) 12:42, 22 August 2021 (UTC)

  For background, talk pages were never removed, rather they were added. The mobile site was built from the ground up. In fact, we didn't have editing for a long time as it was communicated to WMF by editors that notifications were mandatory before we could do that. We added notifications, then editing. Talk page access was only added in current form circa 2019 because communities spoke up and helped drive that priority.

  Building the mobile site has always been based on priorities, so nobody in WMF has ever removed this functionality as you are alleging here. Please assume good faith. Our software is extremely complex with very few maintainers. Jdlrobson (talk) 19:16, 23 August 2021 (UTC)

• ? @Jdlrobson: - any reason someone is going to try to block setting $wgMinervaTalkAtTop = [ "base" => true ]; if the enwiki community asks for it? — xaosflux ^Talk 15:49, 22 August 2021 (UTC)

  Replied with suggestions: https://phabricator.wikimedia.org/T54165#7301936 Jdlrobson (talk) 19:17, 23 August 2021 (UTC)

• I'm a bit torn here, in that I only partially agree that this is supposed to be a collaborative encyclopaedia building site. The primary purpose of this site is to be an encyclopedia serving our readers. Obviously, to have an encyclopedia, you need to write an encyclopedia, but the writing is not the primary purpose. It's just a means to the end. Screen real estate on a mobile device is precious, and wasting pixels on a feature that's mainly of benefit to writers degrades the experience of our readers. -- RoySmith (talk) 16:41, 22 August 2021 (UTC)

  RoySmith, that's a valid argument, but you can't have it both ways. Either mobile anon users can edit (which they currently can) and they need to be able to reach talk pages. Or you remove their edit button (that saves even more pixels) so they won't have a pressing need for talk pages anymore, but that's a difficult topic. — Alexis Jazz (talk or ping me) 17:09, 22 August 2021 (UTC)

  I'd be happy to see all anonymous editing go away. Want to edit? Make an account and the editing buttons and links become visible. IMHO, the amount of effort we put into making anonymous editing work isn't justified by the value it adds. For example, the whole "IP Masking" effort that's currently underway. -- RoySmith (talk) 17:41, 22 August 2021 (UTC)

  RoySmith, I don't oppose, but unless/until we manage to establish a consensus to end IP-editing (this recent effort went nowhere) we have to deal with it. So that's what I'm trying to do. As long as they have an edit button, they should have a talk page link. — Alexis Jazz (talk or ping me) 18:04, 22 August 2021 (UTC)

  @RoySmith and Alexis Jazz: I don't think we should make the fork for showing editing features logged in vs. not. We want users to log in even if they never plan to edit so that if they do decide later on to fix a typo it'll be a smoother journey from there down the editing rabbit hole. But if their first reaction when they create an account is "ack, this just introduced all these ugly buttons I don't want", they'll never stay logged in. {{u|Sdkb}} ^talk 07:23, 24 August 2021 (UTC)

• We should block all edits from all platforms that do not have full access. —Kusma (talk) 16:50, 22 August 2021 (UTC)
• Support per nom with my thanks for stewarding this issue. Not giving mobile IP editors access to talk pages is just stupid, I have no other words for it. WP:Communication is required. Levivich 06:13, 23 August 2021 (UTC)
• Support Paid employees have missed the boat here. An IP user edits, is constantly reverted, but doesn't see explanations on their talk page. Effectively a campaign to frustrate and drive away IP editors, while further stigmatizing IP users to the community.—Bagumba (talk) 11:13, 23 August 2021 (UTC)
• This is now a forked discussion, can I suggest redirecting this back to the WP:VPP section, as that is also diverging into something separate from what the section author originally wrote. ProcrastinatingReader (talk) 12:34, 23 August 2021 (UTC)

  This is a specific request for the mobile platform software, the other is a high-level policy proposal.—Bagumba (talk) 14:23, 23 August 2021 (UTC)

  I agree with Bagumba: this is a specific proposal for a skin and should be allowed to reach its own conclusion. The other discussion is a broader one covering all clients. Regardless of its outcome, the skin can be changed as per community consensus. isaacl (talk) 15:20, 23 August 2021 (UTC)

  @RoySmith: oppose early closure. This is a specific proposal to do a specific actionable thing. The thing is boolean as well so it is very easy to determine the result. That VPP discussion is extremely broad and vague. — xaosflux ^Talk 15:49, 23 August 2021 (UTC)

  No problem, I've backed out my close. -- RoySmith (talk) 16:54, 23 August 2021 (UTC)

• Support If a given setup supports editing, it should support talk pages. WP:ENGAGE. MarioGom (talk) 16:59, 23 August 2021 (UTC)
• 
  Question I agree that giving everyone (including logged-out folks) access to the talk page is a good idea. However screen space is indeed limited on mobile, as RoySmith mentioned, and we know from our data that most logged-out people are not visiting Wikipedia with the intention of editing. They want to read articles, and the Article Talk tabs push the article down the page a bit, so does that design align with what they want? Additionally I wonder if the "Talk" tab, as it is currently presented to logged-in folks, might be confusing logged-out folks and newcomers in general (i.e. what does "Talk" mean? what will happen if I tap on it?)? Which brings me to these mockups made a few years ago by User:Npangarkar_(WMF), of an expanded article footer that has additional tools and information (including a link to the talk page). I feel like the inclusion of an icon, and the more descriptive title ("Discuss" vs. "Talk") make it easier for newcomers to understand what they might find if they tap on it. It could be even more helpful if the button/link included the number of discussions (something like "2 active discussions"), which was an idea explored in Winter. AHollender (WMF) (talk) 18:40, 23 August 2021 (UTC)

  @AHollender (WMF): The note about screen real estate makes sense, but nobody really scrolls to the bottom either. There is a pencil icon on each section to edit it. Editing and discussion workflows should ideally go hand in hand, so if it's prominent and easy to edit there needs to be a complimentary method of discussion. Perhaps a button on the warning message that shows up when you click "Edit" is one way forward. For logged in users, the 'advanced mobile' mode (which shows the talk button) should perhaps be default, since most logged-in people do probably edit (?) ProcrastinatingReader (talk) 19:31, 23 August 2021 (UTC)

  That's a good point about wanting the workflows to go hand in hand, ProcReader. Maybe we want some more mockups of what that could look like.

  AHollender, regarding "discuss" vs. "talk", I believe the desktop tab used to say "discuss" instead. I'm not sure why it was changed, but that's probably a discussion to seek out. The biggest issue I tend to see is WP:NOTFORUM—it's not always intuitive that the discussion page is for discussing improvements to the article, not a general comment thread for discussion about the topic. We designed {{Talk header}} to help explain this, but the mobile developers got fed up with the banner bloat on talk pages and just shoved them into an "about this page" submenu no newcomer will ever click on, so ¯\_(ツ)_/¯. {{u|Sdkb}} ^talk 20:22, 23 August 2021 (UTC)

  A common trap is for people to do mobile mockups in English, then be surprised when the German version is a mess because "Diskussion", "Quelltext bearbeiten" and "Versionsgeschichte" don't fit into the space allotted for "Talk", Edit", and "History". -- RoySmith (talk) 21:20, 23 August 2021 (UTC)

  It traditionally was Talk, then globally it was changed to "discussion" and then en.wp freaked out because "discussion" was too long (taking up more space in their monobook skin) and different from "talk" and they feared that "discussion" would invite discussions on the topic instead of the article, so en.wp changed it back to talk. —TheDJ (talk • contribs) 10:17, 24 August 2021 (UTC)

  People still use Monobook? ProcrastinatingReader (talk) 10:24, 24 August 2021 (UTC)

  Back then definitely. And the bar is all filled up with additional portlet actions for administrative actions as well, because dropdown menus are BAD :D —TheDJ (talk • contribs) 10:26, 24 August 2021 (UTC)

  I do. I try Vector once per year, but never enjoy it. Too much whitespace and all my buttons are hidden somewhere. —Kusma (talk) 10:36, 24 August 2021 (UTC)

  I absolutely do. Tried Vector for a while, but never could get used to it. Too much clutter. Monobook is clean and simple, and that's exactly what I want in an interface. Seraphimblade ^{Talk to me} 05:56, 25 August 2021 (UTC)

• Qualified support. This is a classic example of systemic bias toward editor desires over WP:READER desires. I agree with everyone that it's essential to have some way to access talk pages from every editable page, but I agree with RoySmith and AHollender (WMF) that we don't want to give it inappropriate emphasis. The mockup of what it could look like from the bottom of the page looks quite nice, although I'd want to see some more discussion around what we'd want to go in the edit overview section or whether we should just keep the current "last edited by JimboWales" bar. {{u|Sdkb}} ^talk 20:14, 23 August 2021 (UTC)
  • Readers also use the talk page. An IP's angry post at Talk:F-777 prompted me to fix a redirect we didn't know was broken. — Wug·a·po·des​ 22:15, 27 August 2021 (UTC)
• Support, and (probably deserves its own section) switch from text labels on tabs, to icons with tooltips (ha-ha, the mobile folks won't see the tips). RoySmith's comment about the length of terms like Quelltext bearbeiten raises a good point, but the solution is to follow the example of European road signs and come up with good icons for 'Read', 'Edit', 'History', and so on, and relegate text equivalents to second place. I can visualize one for 'Talk' involving two little talking heads facing each other. It's well established that people process images faster than text, and it would also be a god-send for those of us who occasionally wander off to other language Wikipedias in languages we can't read, and just want to check history, or find a related discussion or compose a diff or something. Mathglot (talk) 22:16, 23 August 2021 (UTC)

  Icons works well in addition to text, but on their own are known to sometimes increase confusion, esp the more there are and the more esoteric they become to try to convey the many meanings that have to be conveyed. Especially on mobile, where you have no hover labels etc this actually reduces discovery. Anyways, mobile already uses a lot more icons than desktop does. The Advanced mode for editors on mobile, currently has language, a watch star, a clock winding back, a pencil and a dropdown menu.... and I think most people on first glance have no idea what any of them do...... —TheDJ (talk • contribs) 10:25, 24 August 2021 (UTC)

• Support. However, as other editors have suggested, it might be better to find an alternative to the [Article | Talk] tabs to save some screen real estate. There's a lot of blank space between the language icon and the edit icon. Maybe slip in a Talk page icon in that row? Alternatively, the proposed Tools section at the end of the page looks great. - Wikmoz (talk) 04:56, 24 August 2021 (UTC)

Actually, it looks like the problem was already solved in the Wikipedia app. At the bottom of each article, there is an ABOUT THIS ARTICLE section with links to View talk page and View edit history. - Wikmoz (talk) 05:16, 25 August 2021 (UTC)

• Support as at least a start. Mobile or not, we should always make the channels of communication clear and easy to find, and treat every reader as a potential editor. Seraphimblade ^{Talk to me} 06:56, 24 August 2021 (UTC)
• Support. It doesn't make sense that a group that is allowed to edit cannot even view talkpages and edit-histories. Why not make pressing the existing "edit" button on the mobile site open up a sub-menu with the options "Edit article", "Go to talk page", and "View history"? I think it's unlikely that anyone technically inclined enough to edit a page would be confused by this additional step. Rabbitflyer (talk) 22:19, 31 August 2021 (UTC)
• Strong support - Talk pages are the backbone of Wikipedia. It would help me tremendously with my work on Wikipedia in mobile. If we did it in the userspace, we should do it to others as well. Interstellarity (talk) 16:34, 1 September 2021 (UTC)
• Somewhat support to turn on now using whatever method is easiest (e.g. $wgMinervaTalkAtTop = [ "base" => true ];), then afterward engage in design discussions, such as whether it should be in the top bar or at the bottom. ⁓ Pelagic ( messages ) 08:58, 11 September 2021 (UTC)
  • Concern: encouraging more people to publish their IP address. (But honestly if this is a blocker then we should also disable IP editing until the masking question is resolved. This might be a topic for the VPP fork instead of here.)
  • Question: is there a similar switch to show it at the bottom, how it was in pre-AMC, logged-in Minerva? ⁓ Pelagic ( messages ) 08:58, 11 September 2021 (UTC)
• Comment: An article Talk page is of value to readers, even if they never post. It allows them to see that there have been discussions or arguments about contentious issues. Sometimes the discussion counts towards an article's credibility or otherwise. Like History, it sends the message that Wikimedia is crowdsourced, and not created by paid writers. Many readers on mobile mayn't care about references either, but we make sure they can access them. ⁓ Pelagic ( messages ) 09:19, 11 September 2021 (UTC)
• Support per nom. Huggums537 (talk) 19:08, 23 September 2021 (UTC)
• Very Strong Support I don't understand why this is by design. Does the WMF not want anonymous users to engage in discussions on the talk page if they use mobile? That just seems like they are purposely making it easier for mobile IP editors to get banned because they have no way to try and gain consensus for an edit they made. ― Blaze The Wolf^Talk_{Blaze Wolf#0001} 19:14, 23 September 2021 (UTC)
• Support. I use Mobile Wikipedia and it would be really convenient fo others to see talk page discussions when not at home. It might also help them learn something, which is a pretty big deal. Plutonical (talk) 14:41, 29 September 2021 (UTC)

Request from Editing Team

Comment: Hi y'all – I work as the product manager for the Editing Team. We're actively working on a series of improvements to talk pages on desktop, and within the next few months, we'll be shifting our focus to improving talk pages on mobile.

With this in mind, can you please review – what I currently understand to be – the issues you all have raised here and let us know what issues you think are missing from this list and/or what about this list needs to be edited?

For added context: I'm asking the above because it's important to me that our team accurately and exhaustively understand the issues y'all are raising here, so that we can make sure the issues we prioritize working on in the next few months are the issues that will be the most impactful to address.

Issues

1. Meta
   1. Talking is a core part of editing and there is a large segment of people who can edit and not talk. As 192.76.8.74^[1], @Alexis Jazz^[2], @RoySmith^[3], @MarioGom^[4], @ProcrastinatingReader^[5] , and others in previous conversations have articulated^{[6] [7] [8] [9] [10]}: collaborating is an important part of writing an encyclopedia. In order to collaborate, you need to be able to talk to people. Currently, there is a large segment of people (anons editing on mobile), who are: A) able to edit and B) not able to collaborate, by way of them not having access to talk pages.
      1. The above, "...wastes time and energy for editors to post explanations/guidance/warnings for contributors who cannot respond" @Johnuniq^[11]
      2. It also helps contextualize why anons editing on mobile not having access to talk pages is problematic.
   2. It's disconcerting to learn that we – volunteers and WMF staff – do not seem to share a core assumption/understanding that people who can edit, must also need to be able to talk.
2. Talk page design
   1. People do not intuitively recognize discussion pages as places to talk about improvements to articles.^[12]
   2. People accessing talk pages on mobile lack access to important context about the conventions that guide how these pages can be used constructively. E.g. Talk page banners/templates are difficult to discover and edit notices are absent.^[13].

Additional context

Considering there are three teams within the Foundation working on improvements to talk pages, I thought it would be worth making sure you all were aware of the work that is being planned and done to improve volunteers' ability to communicate with one another.

• Editing Team | Talk pages project
  • *Reply Tool: a way to reply to talk page comments in one click
  • *New Discussion Tool: an inline form for adding new topics with keyboard shortcuts for pinging and inserting links
  • **Notifications: subscribe to receive notifications about comments posted in specific topics/sections
  • Usability Improvements: a series of improvements to help people instinctively recognize and use talk pages as spaces to communicate with other people
  • Mobile: we'll be introducing all of the above on mobile as well.
• Android Team | Communication Improvements
  • Implementing talk pages and the Watchlist natively within the Android app
  • Improving notifications so people can be aware when others are contacting them
• iOS | Notification improvements
  • A series of improvements intended to help iOS participants to know when they have a new notification without them having to check Wikipedia’s website or check pages in the app, so that they can take timely action on their notifications.

*You can experiment with the Reply and New Discussion Tools right on desktop, by enabling the DiscussionTools beta feature in Special:Preferences.

**You can experiment with Topic Subscriptions on desktop by appending ?dtenable=1 to any talk page URL like this. PPelberg (WMF) (talk) 00:03, 28 August 2021 (UTC)

I inserted a subheading to make this more easy to respond to. A quick additional point is that there needs to be a way of alerting users of mobile devices that is different from the normal semi-spam that occurs with nearly all apps competing for user attention. I have seen phones where a dozen apps have badges showing notifications—the owner ignores them as background noise. For Wikipedia use, when a user opens their browser or app, and if there are outstanding talk-page messages, there must be something like the orange-bar-of-death that more or less compels the user to respond. The suggestion that real-estate on a phone is important completely misses the point that the first thing the user should do is at least view their talk. That raises another tricky point. By convention, we bottom-post, but on a phone that might require a bunch of scrolling. I'm not sure what to do about that but ideally the current sections would be shown. Johnuniq (talk) 00:18, 28 August 2021 (UTC)

I inserted a subheading to make this more easy to respond to.

Oh, wonderful! Thank you for doing that @Johnuniq.

As for the additional issue you are raising, I'm glad you drew out this nuance. You can expect a response from me about this point next week. PPelberg (WMF) (talk) 01:01, 28 August 2021 (UTC)

there needs to be a way of alerting users of mobile devices that is different from the normal semi-spam that occurs with nearly all apps competing for user attention.

@Johnuniq: would it be accurate for me to understand the issue that's prompted you to share the above as: "Anonymous editors do not respond to the messages others leave for them on their talk pages."

Note: I appreciate the language I proposed above does not include the solution/requirement you proposed. I've done this intentionally so as to ensure I'm accurately understanding the underlying issue any solution(s) would need to address.

By convention, we bottom-post, but on a phone that might require a bunch of scrolling.

This is a great callout and something we will need to consider as part of the work we have planned to help people identify new talk page activity. I've documented – what I understand to be – the question inside of what you are saying on Phabricator: "How might bottom-posting impact the likelihood that people accessing talk pages, particularly on mobile, will see the new messages others have left for them?". PPelberg (WMF) (talk) 01:47, 2 September 2021 (UTC)

@PPelberg (WMF): It's not quite right to sum up the issue that's prompted me in the terms above. First, some IP editors are experienced and do respond to talk page messages (so "do not respond" is over generalized). Second, that wording makes it sound as if the anonymous editor might have made a choice to not respond whereas my original concern was for the many edits made by mobile IPs and accounts where the UI does not show them that they have a talk message, and/or does not rub it in their face that the message might be something they "must" see as opposed to the normal spam from many social media platforms, and/or does not provide a simple way to respond. Finally, I am one of many editors who occasionally write detailed explanations for new users and it is destructive for editors like me to later learn that the recipient probably never even knew about my explanation. My point is that the UI is damaging the collaborative community because people like me now think that all IPs/accounts using inoperative software should be banned. Regarding "simple way to respond": I think there should be an orange bar with suitable wording that is hard to avoid. Clicking that bar would take them to the first section on their talk with the most recent date. I understand enough about code to know that would be difficult, but something much better is needed. Perhaps force all new contributors (with a cookie?) to follow a quick tutorial. That might be mandatory if any of their edits have been reverted. Thanks for taking the time to engage here. Johnuniq (talk) 05:11, 2 September 2021 (UTC)

@Johnuniq, I appreciate you teasing out the nuance that had been missing from describing the issue(s) as, "Anonymous editors do not respond to the messages others leave for them on their talk pages."

Combining the above, with the language @TheDJ offered , I've taken another pass at articulating the issues you referred to in the comment you posted on 00:18, 28 August 2021 (UTC).

@Johnuniq+ @TheDJ: are y'all able to review the language below and let me know if you think there are ways it could be changed to more accurately/exhaustively capture the collection of communication issues that impact people editing anonymously on mobile?

Revised problem statements

"People editing anonymously on mobile devices do not realize when other volunteers are trying to communicate with them. If by chance these anonymous volunteers do realize that others are trying to communicate with them, they have a hard time responding." PPelberg (WMF) (talk) 00:26, 16 September 2021 (UTC)

@PPelberg (WMF): My suggestion is "Editors using mobile devices may not realize that important messages have been left for them. If they do see the messages, they may not know how they can respond." Of course some messages may not be important, but if there is a problem, the messages might be vital. I think problems can also occur for registered accounts so I omitted "anonymous". I don't use devices to edit so I'm not sure, but I have heard that it can be hard to see what they would have to do to respond ("where do I tap?"). Johnuniq (talk) 02:24, 16 September 2021 (UTC)

I've never been convinced that most IPs read the messages on their talk pages, even on desktop. I've filed phab:T291297 to request that someone figure out whether there's much point to posting those messages in the first place (in terms of whether the IP reads the message; other experienced editors/admins might benefit from seeing that concerns are recurrent). Whatamidoing (WMF) (talk) 20:15, 17 September 2021 (UTC)

"Anonymous editors do not respond to the messages others leave for them on their talk pages." I'd say "Anonymous users do not realize that there are messages/that others are trying to tell them something, and if by chance they do realize, they have a hard time responding to those messages/notifications" —TheDJ (talk • contribs) 20:43, 3 September 2021 (UTC)

I assume we're talking about talk pages only here? If so, I think this question is broken down into two parts. The first is deficiencies compared to the desktop editing experience. However, deficiencies compared to desktop is not the full list of problems with mobile talk pages or things that should be done differently on mobile, but I would have to think harder on that part to produce a list. One example: if you see a protected page and want to edit it, the workflow on enwiki is via a talk page edit request. It's a pretty poor UI esp on mobile (you can explore it by going to Donald Trump in incognito on your phone and trying to edit). Some of this falls on the community but there's not really a much better workflow possible without software changes. IIRC(?) not too long ago the "View source" button wasn't shown at all so it wasn't clear how to request a change, so I guess the situation is improving...

Although I suspect 'solutions' is separate to 'issues' I would like to take the opportunity to note, in regards to 2.2 (talk page banners), that I have some feelings on the usefulness of the banners on many talk pages. They're a mess, like look at this. It wouldn't be reasonable to show it all to mobile users, and very often there is nothing useful in them IMO (but I suspect I may be a minority view there). Conversely, see here for a useful non-generic banner and toggle "read as wiki page" on and off to see it. It's a hack used to make the message visible on mobile but apparently still only displays when you "read as wiki page"; I don't know why that feature even exists? If a solution to the talk banner issue can't be figured out, showing editnotices (somehow) would be a feasible solution. A talk page editnotice should only be placed when there's something substantive to say about that particular article. ProcrastinatingReader (talk) 01:02, 28 August 2021 (UTC)

The problem with not showing banners to mobile users is that we expect all users who use the talk page to have read them. It is not reasonable to expect Desktop users to be aware which banners are visible to other editors and which are not. —Kusma (talk) 19:09, 28 August 2021 (UTC)

But I agree that we have far too many banners (and many of them are useless). The whole Wikiproject and assessment stuff really should be in a "meta" area, not taking up space on a discussion page. —Kusma (talk) 19:16, 28 August 2021 (UTC)

@ProcrastinatingReader – I appreciate you sharing these thoughts. Comments and questions in response to the points you raised are below...

I assume we're talking about talk pages only here?

Yep, exactly.

if you see a protected page and want to edit it, the workflow on enwiki is via a talk page edit request. It's a pretty poor UI esp on mobile...

To confirm: are you referring to how people wanting to edit a protected page on mobile need to submit an edit request by way of starting a conversation on said page's talk page and that workflow not being straightforward? [i]

...the usefulness of the banners on many talk pages. They're a mess, like look at this. It wouldn't be reasonable to show it all to mobile users, and very often there is nothing useful in them IMO...Conversely, see here for a useful non-generic banner and toggle "read as wiki page" on and off to see it.

I've tried to put what you described into my "own words" to ensure I'm understanding this as you intended it. Can you please let me know if there is anything you would change in order for it to better reflect what you are communicating?

Peter's "own words": "Volunteers need to be able to display information to people, across devices, in ways that will enhance their understanding of: A) The subject page they are likely reading about and/or B) What to consider before participating on the talk page."

Also, these examples are great. Particularly the Talk:COVID-19 lab leak theory example. Thank you for sharing them; it's clarifying to be able to see what you are imagining in your mind.

---

i.The workflow for submitting an edit request as an anon volunteer on mobile, by my count, requires ~7 less-than-intuitive steps: 1) Click edit pencil, 2) Click the View source link that temporarily appears at the bottom of the page, 3) Scroll the page, 4) Locate and click the Submit an edit request button, 5) Scroll to the bottom of the talk page's source, 6) Draft a message, and 7) Post said message. PPelberg (WMF) (talk) 02:20, 2 September 2021 (UTC)

• @PPelberg (WMF): I find the "new section" interface is pretty intuitive for new users. If that link could be more easily accessible, not just the talk page link, I think it would be more useful. I tend to use the &preloadtitle=Foo so that the subject line is filled with some default text, and I've found this useful for action links like leaving me messages about user scripts or questions about things from other projects. — Wug·a·po·des​ 17:53, 28 August 2021 (UTC)

  @Wugapodes: you sharing the experience you've had with, what we've been calling, the New Discussion Tool is helpful to know, especially as we approach offering as an on-by-default feature at the first set of Wikipedias in the coming weeks (see: phab:T271964).

  If that link could be more easily accessible, not just the talk page link, I think it would be more useful.

  Agreed...can you say a bit more here? What about its current location, how it appears, etc. do you think detracts from it's usefulness? Also: have you seen gadgets here, or on other wikis, that you think are effective at addressing the issue(s) that prompted you to share this feedback? For context: you sharing this is timely as well because we will soon be thinking about ways to make the affordance for starting new discussions easier for people to identify and access, regardless of where they are on a given page.

  I tend to use the &preloadtitle=Foo so that the subject line is filled with some default text, and I've found this useful for action links like leaving me messages about user scripts or questions about things from other projects.

  Interesting! Are you able to share a link to a diff and/or page where I can see what you're describing "in action"? PPelberg (WMF) (talk) 03:40, 2 September 2021 (UTC)

  @PPelberg (WMF): You can see an example at User:Wugapodes/Capricorn#Feedback and bugs. The feedback link is created using the fullurl parser function which also allows you to specify the url query. So for that link, I have it add action=edit&section=new to the url which opens the new section interface as well as preloadtitle=... which fills the subject line with the currentuser parser function so that the title is unique and I know who sent it regardless of whether they remember to sign. The full code for that link is {{fullurl:User_talk:Wugapodes|action=edit&section=new&preloadtitle=Message%20regarding%20Capricorn%20from%20%7B%7Bsubst%3Acurrentuser%7D%7D}} At Wikipedia:20th anniversary we did something very similar for the "Say happy birthday" button. I set that button up so that it opened a specific section on the talk page that we made for the purpose, and it used &summary=Wishing Wikipedia a happy birthday to prefill the edit summary for readers.

  W/r/t the link placement, full disclosure, I use responsive monobook on my mobile so take my feedback with a grain of salt. At least as I've seen, the links on articles tend to just be to the talk page which for lots of readers doesn't mean much. Getting from article to talk post is a couple extra clicks in my experience. If the link were "ask a question" or "suggest an improvement" instead of (or in addition to) a talk page link, I think it would encourage more use of talk and depending on the phrasing make the posts more useful. — Wug·a·po·des​ 07:08, 3 September 2021 (UTC)

  I have it add action=edit&section=new to the url which opens the new section interface as well as preloadtitle=... which fills the subject line with the currentuser parser function so that the title is unique and I know who sent it regardless of whether they remember to sign.

  @Wugapodes the above is the precisely the kind of detail I was seeking...thank you for sharing it. I think the workflow you are describing will be compatible with the approach we are taking for offering preload support within the New Discussion Tool. Although, would you be open to reading the "Requirements" section of this ticket and letting us know whether you think there is anything problematic about and/or missing from what's currently written? cc @Matma Rex

  If the link were "ask a question" or "suggest an improvement" instead of (or in addition to) a talk page link, I think it would encourage more use of talk and depending on the phrasing make the posts more useful.

  Making the links themselves more action-oriented could be a successful approach. I've added this idea to the task in Phabricator we are using to track ideas for how we might make talk pages easier for people to discover. PPelberg (WMF) (talk) 00:45, 16 September 2021 (UTC)

• Thanks for that info, PPelberg. At a glance, the issues summary you put together looks good and seems to capture the main points. {{u|Sdkb}} ^talk 03:29, 2 September 2021 (UTC)

  At a glance, the issues summary you put together looks good and seems to capture the main points.

  Oh good. This is helpful to know...I appreciate you stopping back by to say as much, @Sdkb. PPelberg (WMF) (talk) 03:43, 2 September 2021 (UTC)

RFC: New PDF icon

Should we replace the current PDF icon? –MJL ‐Talk‐^☖ 05:33, 8 September 2021 (UTC)

Background

Our current PDF icon is File:Icons-mini-file acrobat.gif . To put it simply, it isn't particularly good. It's a .gif made over 16 years ago. Berrely mentioned this in WP:Discord, so I set about coming up with a modern SVG version of the file. The result was File:Icons-mini-file pdf old.svg  File:Icons-mini-file pdf.svg .

Options

There are three options that should be considered here:

• Option 1 to support using File:Icons-mini-file pdf old.svg  File:Icons-mini-file pdf.svg 
• Option 2 where you agree that we should change File:Icons-mini-file acrobat.gif  but don't like File:Icons-mini-file pdf.svg 
• Option 3 to oppose any changes to File:Icons-mini-file acrobat.gif 
• Option 4 for removing the icon entirely.

Consensus for Option 2 should be followed up in a separate discussion. [Updated 15:35, 9 September 2021 (UTC)]

Discussion (new PDF icon)

• Option 1. As proposer. –MJL ‐Talk‐^☖ 05:33, 8 September 2021 (UTC)

  Comment. I have uploaded a new file that does not have the GPL copyright concerns attached to it. Please see File:Icons-mini-file pdf.svg  for the old file. Currently, the old one is at File:Icons-mini-file pdf old.svg  and the new one is at File:Icons-mini-file pdf.svg , but they should be swapped in like 30 minutes or so. –MJL ‐Talk‐^☖ 21:38, 8 September 2021 (UTC)

  @Xaosflux, Anomie, WOSlinker, and Wugapodes: Sorry to ping you both again about this I have now replaced the SVG with a CC0 one per your concerns. –MJL ‐Talk‐^☖ 05:00, 9 September 2021 (UTC)

  The link in the summary above doesn't seem to point to that? Perhaps strike and insert to the proposal above? — xaosflux ^Talk 10:46, 9 September 2021 (UTC)

  Fixed. –MJL ‐Talk‐^☖ 15:35, 9 September 2021 (UTC)

• Option 1. Clean look and close enough to the original. I would also be open to moving away from the Adobe Acrobat logo if someone comes up with a different icon, since the company no longer holds a monopoly over the format. Yeeno (talk) 🍁 06:01, 8 September 2021 (UTC)
• Option 2. I would prefer something that isn't tied to Adobe, like File:Icon pdf file.svg: . There are many more options in commons:Category:PDF icons. – Joe (talk) 06:15, 8 September 2021 (UTC)

  Since this option is proving popular, but some have correctly pointed out that the "PDF" text is hard to read, I've created a version which is better optimised for small sizes: File:PDF icon.svg. Please feel free to tweak it further. – Joe (talk) 12:37, 8 September 2021 (UTC)

  I tweaked it further, but I think there's a limit to how well tiny SVGs can render text: . --Ahecht (TALK
  PAGE) 20:13, 8 September 2021 (UTC)

  It's easy to read, in SVG format, and is clear of copyright concerns. Ultimately, it's probably the best bet for symbol replacement. Plutonical (talk) 14:58, 29 September 2021 (UTC)

• Option 2, and concur with Joe that the Adobe logo is mega fail. The icon he posted in the comment above this one seems good, and it's an SVG, which is better than the tiny GIF being used currently as it can be rendered at any size without looking terrible. jp×g 06:34, 8 September 2021 (UTC)

  Man, there's some pretty great icons in that category. jp×g 06:37, 8 September 2021 (UTC)

  Do I look like I know what a JPEG is? ~~~~
  User:1234qwer1234qwer4 (talk) 09:41, 8 September 2021 (UTC)

• Option 2 The icon must change. The old thing is a relic of the dark ages. Initially I thought ooh the adobe svg looks great. But Adobe are no longer the pdf overlords, and I don't rather like Adobe, evil empire of tech that it is. Joe's suggestion of the generic PDF SVG is the perfect solution. CaptainEek ^{Edits Ho Cap'n!}⚓ 06:42, 8 September 2021 (UTC)
• Option 3 as a reasonable specific replacement. Robert McClenon (talk) 07:03, 8 September 2021 (UTC)

   Eeeehhhhhhh, @Robert McClenon, are you sure you typed in the right number for your preferred option? ~~~~
  User:1234qwer1234qwer4 (talk) 09:45, 8 September 2021 (UTC)

• Option 1 as a reasonable specific replacement. Robert McClenon (talk) 14:58, 8 September 2021 (UTC)
• Comment is licensed as copyright free but is licensed as GPL which could make a diffence as to how it can be used without any linking back to the file. -- WOSlinker (talk) 07:36, 8 September 2021 (UTC)
• Option 2 I agree with Joe.--Vulp❯❯❯here! 07:55, 8 September 2021 (UTC)
• Option 2; the new SVG looks wrong to me without a gradient, and I think we should move away from Adobe promotion. ~~~~
  User:1234qwer1234qwer4 (talk) 09:39, 8 September 2021 (UTC)

  Option 4 below does not seem too far fetched either. We don't seem to have this for other file formats, why display an image specifically for PDFs? ~~~~
  User:1234qwer1234qwer4 (talk) 20:42, 8 September 2021 (UTC)

• Option 2: PDF is no longer specific to Adobe, so let's remove their logo. Option 1 (File:Icon pdf file.svg) looks ideal when enlarged, but the letters are hard to distinguish at icon size. I suggest a new copyright-free SVG with even larger letters (They won't occupy many pixels.) Certes (talk) 11:40, 8 September 2021 (UTC)

  @Certes, note that there are no "letters" in option 1. ~~~~
  User:1234qwer1234qwer4 (talk) 15:15, 8 September 2021 (UTC)

  Oops, I was referring to Icon pdf file.svg. Certes (talk) 17:08, 8 September 2021 (UTC)

  The only candidate I can read at 16px is (File:Icon pdf file.png). Text on other versions, including the SVG auto-converted to a 16px PNG, is illegible. Certes (talk) 18:29, 9 September 2021 (UTC)

• 1 or 2 is fine for me. --Izno (talk) 12:01, 8 September 2021 (UTC)

  Given that someone added the "ditch it entirely" option 4, put me in that camp as first preference with a fallback to 1, 2, or any other reasonable icon that isn't the old one. I am not strongly persuaded, as below in re to Ivanvector, that we must make these icons more accessible. What I would prefer to see is the block of CSS in Common.css removed and for everyone to enjoy a marginally faster page load. --Izno (talk) 19:07, 9 September 2021 (UTC)

• Still Option 2 (even after addition of an Option 4, edited 20:28, 9 September 2021): Although "oppose any changes" seems pretty strong, I was leaning toward Option 3 since the proposal seemed to be based on the argument It's a .gif made over 16 years ago, with no explanation of why that's bad. Personally, I'd rather use a 291-byte file than one 6 KB in size, ceteris paribus. But then, despite the weird threading, I noticed the replacement suggested by Joe Roe. It doesn't have the Adobe logo or (*gag*) name on it, it's clearly for PDFs, and it's only 2 KB in size. So if we're going to change, let's change to something like that. This one (, 707 bytes) works for me, too. — JohnFromPinckney (talk / edits) 12:04, 8 September 2021 (UTC)

  I don't think the file size matters here, because what is actually downloaded by your browser is a server-rendered bitmap of the appropriate size, not the original SVG. That's approximately the same for all the files,[12][13] and less than 1 KB. Also, "weird threading"? – Joe (talk) 12:18, 8 September 2021 (UTC)

  Did not know about the different download file, thanks. And it wasn't actually so much weird threading as it was confusion on my part from JPxG's contributions. My too-quick reading saw the big file image at the upper right, which wasn't either the current icon nor the proposed replacement. When they wrote concur with Joe that the Adobe logo is mega fail I thought they were agreeing with the proposer (which you're not) that the icon was mega fail (although that wasn't clear why). Then JPxG also said there's some pretty great icons in that category [sic], which would have been more appropriate, IMO, as a reply to your 06:15 post, not as a reply to themself. I got a bit lost. Confusion on my part from scanning too quickly, and thinking too slowly. — JohnFromPinckney (talk / edits) 14:52, 8 September 2021 (UTC)

  This is untrue in the context of CSS-loaded images (I am not sure whether you meant to distinguish). SVG images are sent as SVGs to the end user when loaded by CSS. In the context of this proposal, we would be making modifications to the CSS, so the end user would receive an SVG at the size of interest.

  In the context of any old generic file wikilink, yes, SVGs are rendered to bitmap and served as PNG automatically. Changing that behavior – to use SVGs more directly – is ancient phab:T5593. Izno (talk) 19:11, 9 September 2021 (UTC)

  I suppose the problem isn't directly that "[i]t's a .gif" but rather that it has a fixed resolution looking pixelated on modern screens, while a vector version would be rendered in an appropriate resolution on any device, as Joe pointed out. ~~~~
  User:1234qwer1234qwer4 (talk) 15:22, 8 September 2021 (UTC)

  Striking my !vote until I have time to study the revised options. — JohnFromPinckney (talk / edits) 18:09, 9 September 2021 (UTC)

  Unstriking my !vote above, as I find I still prefer Option 2. The target proposal in Option 1 is now even less appealing, as the new target File:Icons-mini-file pdf.svg looks even worse at 16px on my device than the old target File:Icons-mini-file pdf old.svg. The newly added Option 4 is okay, I guess, after Option 2, but I personally appreciate having an indication of PDF-ness. I sometimes use a different reader than the one my browser tries to use by default, or I can choose to save the PDF file somewhere for later perusal. — JohnFromPinckney (talk / edits) 20:28, 9 September 2021 (UTC)

  JohnFromPinckney, in citations there's already "(PDF)" as an indicator, seemingly added by {{Citation}}. Exactly how this is stylized is up for debate (Ahecht made a suggestion below), but the indication is already there without any icon. — Alexis Jazz (talk or ping me) 20:50, 9 September 2021 (UTC)

  Yes, thanks, Alexis Jazz. That means we get icon and "(PDF)" with a CS1|2 template (<ref>{{cite web |title=With cite template |url=https://example.com/Adobe.pdf}}</ref>), and just the icon without one (<ref>[https://example.com/Adobe.pdf Without cite template]</ref>). What would be good for me is to drop the icon but replace it with the textual "PDF" indicator, which I guess would be an Option 5. — JohnFromPinckney (talk / edits) 19:19, 11 September 2021 (UTC)

References

• Option 1. That logo is still the most widely associated with the PDF format, and anything else is just making things less clear for our readers. There doesn't seem to be a clear alternative being posited (the letters in the version proposed by Joe are illegible at this resolution), and most of the reasons above seem to hinge on people's person feelings about Adobe, which shouldn't enter into this debate. Either leave well alone, or adopt the new clearer version proposed by the OP.  — Amakuru (talk) 12:14, 8 September 2021 (UTC)

  "Personal feelings" is a bit dismissive. We're an free knowledge project and have a long history of supporting free software, free licenses, and free formats wherever possible. I highly doubt that the generic 90s software-looking acrobat squiggle is more widely recognised than the letters "PDF", but I agree the legibility of my first suggestion could be improved. – Joe (talk) 12:22, 8 September 2021 (UTC)

  If someone comes up with an alternative that actually works, then I might support it. But I'm not going to give a blank cheque to swap an easily recognisable logo for one which might not immediately convey its meaning to our readers. "Option 2" involves dispensing with the current logo without any consensus as to what we're swapping it for, and I can't support that.  — Amakuru (talk) 12:31, 8 September 2021 (UTC)

• Option 2 - some generic PDF logo (i.e. not the Adobe 'squiggly triangle') to be determined later. SVG > GIF, of course, but I think we should take this opportunity to swap it for a more generic logo. firefly ( t · c ) 12:25, 8 September 2021 (UTC)
• Option 2 or 3 Option 1 is a non-starter due to license. We need something that's public domain or CC0 to avoid a requirement to link back to the file description page for attribution and/or notice of license. I wouldn't oppose an identical image with a proper license; while it's annoying to have the Adobe software's logo in there, it's also recognizable. As for that several people above seem to like, all I see at that size is a document icon with a red bar over it. The text "PDF" is not visible. Again, I wouldn't oppose an alternative that's more legible. Anomie⚔ 12:26, 8 September 2021 (UTC)
  • Striking as the concerns I raised seem to have been addressed, the new image for option 1 has a usable license and people have suggested as a better choice for option 2. I don't have enough of an opinion on the current options to !vote. Anomie⚔ 16:57, 9 September 2021 (UTC)
• Option 2 Let’s move away from Adobe. --Malcolmxl5 (talk) 12:32, 8 September 2021 (UTC)
• Option 3 This is change for the sake of change and doesn't actually accomplish anything. * Pppery * _{it has begun...} 13:21, 8 September 2021 (UTC)

  @Pppery, the current file is 512 pixels, which is too small to be rendered properly on modern screens and appears conspicuously pixelated. ~~~~
  User:1234qwer1234qwer4 (talk) 15:29, 8 September 2021 (UTC)

• Option 3 or 2: the current icon is serviceable as is, but if we were to change, I'd rather something without the Adobe logo. Isabelle ^🔔 14:35, 8 September 2021 (UTC)
• Option 2 per Firefly and others. There is nothing wrong with using a 16-year-old icon per se, and the proposed replacement's only advantage is in file format and that's not enough reason imo to justify a change. However what does justify a change is using a generic icon that doesn't require someone knowing what the logo of a private company represents. Whatever icon we end up choosing, we should probably consider including it as an example in the PDF article. Thryduulf (talk) 15:07, 8 September 2021 (UTC)
• Option 2, PDF files are no longer the sole domain of Adobe and we shouldn't be using their logo, but none of the suggested icons have been readable. I modified one of the existing PDF SVG icons on commons to make it more readable (), but if the intent is to use this at 16px, pixel art is always going to render better than an SVG, e.g. . --Ahecht (TALK
  PAGE) 15:37, 8 September 2021 (UTC)

  I have to admit that the 16px PNG rendering does look like a usable option and also looks way less pixelated than the current icon (where even the border displays very blurry), at least on my end. ~~~~
  User:1234qwer1234qwer4 (talk) 15:48, 8 September 2021 (UTC)

• Ehhhhhhh ---- GPL are we opening a can of worms by changing from a free image to one that has to drag GPL around with it everywhere? — xaosflux ^Talk 16:58, 8 September 2021 (UTC)

  Leaning more towards Option 2 and using File:Icon pdf file.png or something similar, provided it is CC0 or other very-free license. — xaosflux ^Talk 18:50, 8 September 2021 (UTC)

  @Xaosflux and Anomie: Wouldn't a comment in the CSS be sufficient for linking to the license and authorship? –MJL ‐Talk‐^☖ 20:56, 8 September 2021 (UTC)

  Nope. The GPL seems particularly weird when it comes to images, and even more weird when it comes to SVG images. The bottom line is that we need to clearly distribute the image along with the author's copyright notice and the notice that it's under the GPL, which we satisfy by linking the image to the file description page that has all that information. Hiding a comment in a CSS file, where it'll be hard to find and may be minified out, won't cut it. Anomie⚔ 21:55, 8 September 2021 (UTC)

  Okay, I have managed to remake the SVG using stuff that was in the Public Domain. –MJL ‐Talk‐^☖ 05:06, 9 September 2021 (UTC)

• Option 2 I find the PDF text version quite promising. The one I think is the most legible is (show) (File:Icon_pdf_file.png) which is easily readable on both mobile (both vector and mobile version). There are of course scenarios where it wouldn't be legible, but I feel the current icon would be non-distinctive under the same circumstances and I could see many readers not knowing what the acrobat icon means now a days. --Trialpears (talk) 17:03, 8 September 2021 (UTC)
• Option 2 Go for File:Icon_pdf_file.png . It's more readable than the similar svg versions. -- WOSlinker (talk) 18:23, 8 September 2021 (UTC)
• Option generic PDF SVG Headbomb {t · c · p · b} 18:34, 8 September 2021 (UTC)
• Option 4 get rid of it altogether. No GPL license, no trademark (US #3652386 and #3652388, I have no idea how to link these from https://tmsearch.uspto.gov/ so search yourself, it's the squiggly triangle), no BS. The document icon with "PDF", even Joe Roe's improved version, is hard to read and ultimately provides no additional information over just the text "(PDF)". This is currently defined in MediaWiki:Common.css#L-510 btw, it's not template specific or MediaWiki default. — Alexis Jazz (talk or ping me) 19:55, 8 September 2021 (UTC)
• Opposed to any GPL-licensed image or image restricted by trademark. Would prefer CC-0 license. No strong opinions on the design itself, I'm open to a new one but don't see a serious problem with the existing image. — Wug·a·po·des​ 20:29, 8 September 2021 (UTC)

  @Wugapodes: Wouldn't the trademark issue be a problem with File:Icons-mini-file acrobat.gif  as well? I'm a little confused there. –MJL ‐Talk‐^☖ 21:00, 8 September 2021 (UTC)

  I'm not an expert on trademark, but I presume so. My understanding is that having a trademark isn't a problem per se as long as we aren't using it to mislead readers about brand identity or disparage the trademark holder. The issue isn't a legal one, but a philosophical one: I'd prefer we use free equivalents that do not have copyright or trademark restrictions whenever possible. But unless we have consensus for an option that is free of copyright and trademark, I'd rather we have some graphical representation of the PDF over nothing. So by no "serious problem" I mean that it's not enough for me to say get rid of it immediately, but I do think there is room to improve. If we are going to improve, I want us to also move in the direction of copyright- and trademark-free images, but if the option is do nothing or remove the icon without replacement, I'd rather do nothing. (NB I do like Ahect's idea of just using stylized text instead of an icon.) — Wug·a·po·des​ 21:40, 8 September 2021 (UTC)

   Question: Why is specifying the file format necessary for PDF files? ~~~~
  User:1234qwer1234qwer4 (talk) 22:13, 8 September 2021 (UTC)

  Wugapodes, I'm fine with stylized text too. The text "(PDF)" already gets added, seemingly by {{Citation}}. I just think the icon should go away. Trademark is possibly a theoretical legal issue. The squiggly triangle in the infobox of PDF is fine because there is clearly no connection between Adobe and Wikipedia. When used as system icon of sorts, like we have it in MediaWiki:Common.css#L-510, it could cause people to believe there is a connection between Adobe and Wikipedia or MediaWiki, like us relying on Adobe software or being endorsed by Adobe. It's a theoretical issue though, this may or may not actually be a trademark violation and Adobe is unlikely to try and crack down on this kind of unauthorized usage. My main issue is also philosophical: try to avoid trademarks if possible, particularly when they're not being used for commentary. 1234qwer1234qwer4, I think traditionally this kind of indication (not just on Wikipedia) was provided to warn users to get a cup of joe while their computer chugs along for 15 minutes to load Adobe Acrobat Reader. — Alexis Jazz (talk or ping me) 22:33, 8 September 2021 (UTC)

  @1234qwer1234qwer4: PDFs are a bit of a weird file format. Sometimes when you click a link it will automatically download a file on your device, but other times it can just open up in a new tab. The biggest concern, however, is that not all mobile devices support PDFs across the board. My phone can just barely do it (and requires a download everytime I view one.. which can be a problem for larger files), so I have always found these icons helpful. –MJL ‐Talk‐^☖ 05:06, 9 September 2021 (UTC)

• Option Alexis Jazz - WP:ACCIM recommends that information should not be conveyed using only images, and while the revised icon with plain text is a slight accessibility improvement over the corporate logo version, it's still a long way off from meeting that standard. Alt text would help, but a simple (PDF) alongside the link is frankly much better and more useful than a small icon with tiny, barely-legible text. Ivanvector's squirrel (^trees/_nuts) 20:40, 8 September 2021 (UTC)

  Or something like PDF, which is reminiscent of what Google uses. --Ahecht (TALK
  PAGE) 21:14, 8 September 2021 (UTC)

  I see this as a case of progressive enhancement given broadband speeds and the compression of PDFs (which has gotten better since PDFs stopped being all-image files), as the size was predominantly the rationale for ever indicating that a URL pointed to a PDF. Separately, CS1/2 already auto-indicates whether something is a PDF. I don't really see much cause for anyone to generally indicate something is a PDF. (This is not an opinion on this RFC per se, just making a comment about whether we should need to indicate something is a PDF.) Izno (talk) 19:02, 9 September 2021 (UTC)

  There is an old-school web best practice to indicate if a link doesn't take you to a web page, since that's the general expectation (and, yes, size was part of the concern). I'm not sure of the current consensus on this matter in the web design community. isaacl (talk) 19:46, 9 September 2021 (UTC)

  I haven't designed web pages since the mid-90s so I can't really comment on standards, but I'd prefer if there were some kind of indicator, text or otherwise. Compression has improved for sure but PDFs are still multimedia, even a single-page plain-text PDF can be several megabytes. Not everyone who reads Wikipedia benefits from the expansion of broadband in wealthy countries, and third-party software is still generally required to open a PDF or use their full functionality, and this can be severely prohibitive for someone on say a 14.4kbps dialup connection, or using a 2G mobile device. We still warn when a link goes to an external website, and we should do the same with multimedia. Ivanvector's squirrel (^trees/_nuts) 20:52, 9 September 2021 (UTC)

  "We still warn"? We don't (I assume by "we" you mean MediaWiki software, please be precise if otherwise), at least not "accessibly", in the same way we don't as the would-be "replace with 'PDF' in text". Izno (talk) 21:22, 9 September 2021 (UTC)

  If you look at the web, I'd say that mostly doesn't happen any longer. I mostly don't think it should, especially with the advent of "the browser does everything (video, audio, PDFs of late in e.g. Firefox, yadda yadda)". Browsers are monsters not far off from being their own operating systems (oh wait :). Izno (talk) 21:24, 9 September 2021 (UTC)

  Although links to PDF files often lack indicators (with the ubiquity of the format, probably due to both happenstance and successful Adobe marketing), links to video and audio generally still provide some kind of indication. Users generally want to know in advance if they're going to see some kind of audiovisual presentation. Their current browsing environment (such as alone in a room or within a crowd) and personal desires at the moment influence what type of interaction they want to have. isaacl (talk) 00:56, 10 September 2021 (UTC)

  Yes, by "we" I did mean the MediaWiki software, with the little "arrow escaping the box" icon beside all external links (like this, which is, indeed, not accessible). Remember that while progress marches on, it marches past many people who read Wikipedia but don't have access to cutting-edge tech that we do in developed countries, and something as minor to us as loading a couple-megabyte multimedia file could be an outright ordeal for them. On a trip to Cuba a few years ago I turned my phone on when our plane landed, and didn't even get out of the airport before I had a text from my carrier saying I was up to $100 in roaming charges and they had disabled my data. I remember the not-too-distant past trying to edit through Opera on a flip phone, and recently made one edit from my Wii's embedded browser just to see if it would work - it did but it was frustrating. I still see more Windows XP than ChromeOS in checkuser results, and rarely even older OSes. Ivanvector's squirrel (^trees/_nuts) 16:43, 15 September 2021 (UTC)

• With apologies to those who already knew, the choice of icon is implemented in MediaWiki:Common.css line 510. Help:External link icons#Custom link icons informs us that The image must be 16 pixels wide and cannot be SVG format. (That's in an example about adding a custom icon for .xls, but I assume it applies to .pdf too). From my rather basic knowledge of graphics, .png may be the best format for this use case. Certes (talk) 22:52, 8 September 2021 (UTC)

  Certes, I had already mentioned Common.css above, but you inspired me to add an anchor to the line number. — Alexis Jazz (talk or ping me) 23:02, 8 September 2021 (UTC)

  @Certes: Really, SVG is the best format because it is the most scalable (imo). –MJL ‐Talk‐^☖ 05:06, 9 September 2021 (UTC)

  Normally, yes, but the software doesn't seem to accept SVGs here. Also, if it's shown at a fixed 16px, we should probably optimise for that, e.g. align the paper edges and the orthogonal lines of the letters mid-pixel. If the day comes when MediaWiki renders an SVG at 128px on our 16k holodisplays, we can replace the icon again. Certes (talk) 10:19, 9 September 2021 (UTC)

  When it says "cannot be SVG format", I suspect that refers to the URL used. So https://upload.wikimedia.org/wikipedia/commons/c/cb/Icons-mini-file_pdf.svg would fail, but https://upload.wikimedia.org/wikipedia/commons/thumb/c/cb/Icons-mini-file_pdf.svg/16px-Icons-mini-file_pdf.svg.png would be ok. For that matter, the restriction on SVG may be outdated (it was written in 2011), or may have been because someone's browser in 2011 didn't support SVGs there, or may be to avoid explaining that the SVG's intrinsic size needs to be 16px; at any rate, I tested it and it seemed to work fine. But I do agree that optimizing the icon for the size would be a good idea. Anomie⚔ 11:51, 9 September 2021 (UTC)

  The "restriction" is outdated. We have been serving SVGs via TemplateStyles for CS1 for a year or two now. My guess is that it is related to IE8 and lower, which MediaWiki no longer supports. The page pointed to by Certes should be updated. Izno (talk) 18:58, 9 September 2021 (UTC)

  But if you're using the png rendering of an SVG file, you get all the downsides of an SVG (e.g. blurry lines and fonts) with none of the advantages of it being scalable. --Ahecht (TALK
  PAGE) 13:14, 24 September 2021 (UTC)

• Option 2 I think File:Icon_pdf_file.png is a much better replacement, is very readable, and is simple. This is the obvious choice for me. DiamondIIIXX (talk) 03:47, 9 September 2021 (UTC)
• Comment This may seem like an odd question but, why is the file in a .gif format anyways? Aren't .gif format files used for animated images? But I support Option 2, per the above discussion. The current file makes it seem like the file is in Adobe Acrobat (which, a few years ago, that was probably the only way to view PDFs) when really it can be viewed in many places besides Adobe Acrobat. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) (Stupidity by me) 19:06, 9 September 2021 (UTC)

  GIF format was long used for images on computer networks, pre-Internet, pre-Web, and up to now. Due to patent issues (which are no longer applicable as the patent in question has expired), there was a push to move to PNG format, and JPEG became popular for photos due to better compression and appearance (both due to higher resolution colour not being limited to only showing 256 colours and its compression algorithm being a better fit). GIFs remained in use for animated images as the original PNG specification did not support this capability. The current image being a GIF is reflective of how long ago it was put into place. isaacl (talk) 19:27, 9 September 2021 (UTC)

  Ah ok, thanks for informing me! I've always know .gif format files as being animated images so I was confused when I saw that the current image we're using was in the .gif format but wasn't animated. @Isaacl: Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) (Stupidity by me) 19:31, 9 September 2021 (UTC)

• Option 1 as an improvement, until someone thinks of something which is equally clear and less like its own logo. DGG ( talk ) 06:33, 10 September 2021 (UTC)

  I'm confused as to what you mean. Many people have already thought of something equally clear and less like a logo. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) (Stupidity by me) 13:07, 10 September 2021 (UTC)

• I'm not going to pick an "option" because at this point there are too many icons going around, but I support using some sort of SVG icon (preferably without the Adobe logo) that's CC0 (or similarly) licensed. I don't prefer any particular icon. Tol (talk | contribs) @ 21:14, 10 September 2021 (UTC)\]

  @Tol: Option 2 does not require a commitment to any particular proposed icon. All it means is that you are against File:Icons-mini-file pdf.svg  and are also against File:Icons-mini-file acrobat.gif . That sounds like where you are basically at right now. –MJL ‐Talk‐^☖ 06:34, 12 September 2021 (UTC)

  @MJL: Ack, my mistake. Option 2 sounds good. Tol (talk | contribs) @ 17:39, 12 September 2021 (UTC)

• Question Have we asked Adobe what they will allow? I quickly skimmed https://www.adobe.com/legal/permissions/icons-web-logos.html and thought I need to ask someone with expertise in copyright law. Vexations (talk) 22:24, 10 September 2021 (UTC)

  Does it matter? If we don't want to use one vendor's logo for an industry-wide standard, whether they want us to use it is irrelevant. Certes (talk) 22:32, 10 September 2021 (UTC)

• Option 2 (use MediaWiki? fallback). I used inspect element to disable the current icon pulled from Common.css, and discovered that the fallback pdf icon is evidently [14]. This is the visual counterpart to the external link icon [15]. I suppose this is a !vote to remove the text in Common.css, and let this fallback icon take its place, since it establishes a nice visual consistency, and doesn't stick out as much as the ones that have been proposed so far, which I don't like. — Goszei (talk) 04:46, 11 September 2021 (UTC)

For the sake of illustration in this discussion, I have uploaded the icon I am proposing to Commons; it looks like this: (for comparison, here is the external link icon that appears all over Wikipedia, part of the same MediaWiki set: ). — Goszei (talk) 03:43, 20 September 2021 (UTC)

• Option 2 - Personally I like Icon pdf file.png Seddon ^talk 18:47, 13 September 2021 (UTC)
• I support Option 2 () because it seems the best visual indicator of a PDF. I oppose just using text; the image makes it stand out that it's a PDF. ― Qwerfjkltalk 19:04, 13 September 2021 (UTC)
• Option 2 per everyone else, and in terms of replacements, first choice: PDF, second choice: File:PDF icon bold.svg , third choice: File:PDF icon.svg . Levivich 05:25, 14 September 2021 (UTC)
• Option 2. Concur about change from corporate logo; but there's a problem, because we don't seem to be moving towards any consensus whatsoever about what is the substitution. I believe the PDF Google PDF icon is the most legible and does not cram white letters into a red background, which the colour-blind may not see, and that against a white sheet of paper with abnormally thick black margins. Keep it simple, really; there is no obligation for us to keep that red stripe. Szmenderowiecki (talk) 09:46, 14 September 2021 (UTC)

  we don't seem to be moving towards any consensus whatsoever about what is the substitution that's not a problem because this discussion is explicitly not intended to determine that. If (as seems likely) option 2 gains consensus there will be a second discussion to determine what the replacement should be. Thryduulf (talk) 12:23, 14 September 2021 (UTC)

• Option 2 as tie to Adobe is no longer appropriate. Use . I'm seeing that around anyway, so more and more becoming the default I guess. Herostratus (talk) 02:48, 15 September 2021 (UTC)
• Option 2 Any icon containing the letters PDF. The best so far seems to be PDF icon.svg , followed by PDF icon bold.svg , but perhaps a version with black/dark blue lettering could be better? — GhostInTheMachine ^{talk to me} 08:35, 15 September 2021 (UTC)

  Maybe not ... PDF icon blue.svg and PDF icon black.svg — GhostInTheMachine ^{talk to me} 09:19, 15 September 2021 (UTC)

• Option 2 although I am not fond of the red letters, as it seems redundant For example MyProposal.pdf DGerman (talk) 19:55, 20 September 2021 (UTC)
• Related proposal: I've opened a related proposal; !voters here are invited to comment at Help talk:Citation Style 1#Proposal: Use the document icon instead of the external link icon for documents. {{u|Sdkb}} ^talk 04:42, 23 September 2021 (UTC)
• Option 2. Perhaps the new symbol, to be determined, could be a piece of paper with a folded corner (As is seen in most file format icons) with the letters "PDF" on it? Clear of copyright concerns and adobe attachment. (EDIT: Just learned that the comments below indeed have this idea covered) Plutonical (talk) 14:55, 29 September 2021 (UTC)

Discourage en-xx UI variants

In follow up to Wikipedia:Village_pump_(technical)#Paalika_Keka and some edit summaries at MediaWiki:Preferences-summary/en-gb, I'm proposing that we specifically add verbiage that we "discourage" our users from selecting en-ca and en-gb interface variants. These variants cause users to miss any localization to our interface messages, and put them at the mercy of either falling back to the default message - or accepting whatever the editors of translatewiki have put in place. I'd much prefer we forcibly made these fallback, but that is not currently a software option. — xaosflux ^Talk 20:42, 24 September 2021 (UTC)

Pings to some recently involved editors: @PrimeHunter, Mike Peel, Redrose64, and Jdforrester:. — xaosflux ^Talk 20:42, 24 September 2021 (UTC)

• Yep, scrap the lot. I suspect that people who choose these options do so in the belief that it will configure the text of articles - which is the one thing that it doesn't alter. Most of us know that petrol and gasoline are the same substance, but how often do words with UK/US variants come up in the interface messages? --Redrose64 🌹 (talk) 20:50, 24 September 2021 (UTC)
• Fully support deprecating the lot for all the reasons above. They only cause problems that we then have to unravel at VPT(!). firefly ( t · c ) 20:55, 24 September 2021 (UTC)
• Support. I once examined the full en-gb file and it only made around ten minor spelling and punctuation differences like color/colour, not different words like petrol/gasoline. For that you lose a lot of messages customized for the English Wikipedia, e.g. with links to our policies, processes and help pages. For example, compare the edit page for a fully protected page in en and en-gb (admins must log out to see it). en-gb users sometimes cause confusion when discussing the interface with others, and some help pages don't match what they see. en-ca (Canadian English) has the same problems but few users so it rarely comes up. PrimeHunter (talk) 21:18, 24 September 2021 (UTC)
• Support; they are nothing but trouble. Customize some of the messages within the variants to point people to how to choose the right setting. – Jonesey95 (talk) 00:33, 25 September 2021 (UTC)
• Support per Primefac. – SD0001 (talk) 02:21, 25 September 2021 (UTC)
• Yep, support. Tol (talk | contribs) @ 02:41, 25 September 2021 (UTC)
• Comment since I was pinged. We already have a warning in the preferences: "Language (warning:selecting a language other than 'en - English' may prevent you from seeing custom parts of the interface on the English Wikipedia and you may see inaccurate external translations.):" (where the 'external translations' bit is weird/wrong - it's translations built into MediaWiki). Presumably that could be extended to warn against en-GB and en-CA. I'm generally in favour of giving people the choice, though. Also, it shouldn't be completely disabled, as it's useful to browse the interface in other languages when you're not a native language speaker (I quite regularly do this on other language wikis). Thanks. Mike Peel (talk) 10:11, 25 September 2021 (UTC)

The quoted warning was added to MediaWiki:Yourlanguage this year. It is only displayed if the language is still the default en. PrimeHunter (talk) 13:35, 25 September 2021 (UTC)

The bit about external translations is correct because it is done at Translatewiki.net, which is not a WMF wiki. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 05:15, 26 September 2021 (UTC)

• @Mike Peel: I don't think we have the capability to remove these entirely locally, this is just about "discouraging" this right now - and may include adding warnings if your language is in those English variants. — xaosflux ^Talk 10:20, 25 September 2021 (UTC)
• Just to be clear, this proposal is only about the interface - and will have no impact in any way at all on the content of articles or the manual of style for engvar's in articles. — xaosflux ^Talk 10:20, 25 September 2021 (UTC)
• Support per nom. ― Qwerfjkltalk 14:21, 25 September 2021 (UTC)
• Support. Checking the last 30 days stats at translatewiki, en-gb has 44 translations and en-ca has only 4 translations. This shows that there are very few maintainers for these variants, which is what causes test edits and vandalism to go undetected until en.wp users notice it. Due to lack of active maintainers at both translatewiki and locally at en.wp, users who opt English variant interfaces get a suboptimal experience. So English variant interfaces should be discouraged in favour of base en. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 05:15, 26 September 2021 (UTC)
• Can we not just get en-GB and en-CA removed? What purpose do they serve? – Joe (talk) 07:55, 26 September 2021 (UTC)

  @Joe Roe: in some cases yes - part of this proposal is to actually discourage editors from "selecting" that language - not just cleaning up the messages; some prior messaging had push back about discouraging someone from using those settings. Nothing intrusive - just labels on things like preferences warning that this option is discouraged if someone actually does set it. — xaosflux ^Talk 09:42, 26 September 2021 (UTC)

  I mean removed as option, so we don't have to have to have these messages. – Joe (talk) 09:46, 26 September 2021 (UTC)

  Probably non-zero development work from the languages team, especially since a user's interface preference can be global and not solely local. IznoPublic (talk) 15:15, 26 September 2021 (UTC)

  If development work is being done, then the right solution is to fix phab:T57473, rendering the whole issue moot. * Pppery * _{it has begun...} 22:57, 26 September 2021 (UTC)

  @Pppery: the general tech problem is that when a localized message exists in a base language, but the user is set to use a base-variant language, when the base-variant language is not localized the user's language fallback chain doesn't bring them to the base language. — xaosflux ^Talk 23:32, 26 September 2021 (UTC)

  Does phab:T57473 refer to something else? * Pppery * _{it has begun...} 23:34, 26 September 2021 (UTC)

  That one seems to be about the fallback chain for base languages only, I think there is another could of phab tickets about base-variant fallbacks that I'm not remembering right now.— xaosflux ^Talk 11:01, 27 September 2021 (UTC)

  Oh. I actually meant fix the general problem, not one specific manifestation I may have linked to by mistake. * Pppery * _{it has begun...} 14:14, 27 September 2021 (UTC)

• Yes, please, discourage away. I'm tired of getting confused questions at VPT. :^) --IznoPublic (talk) 15:16, 26 September 2021 (UTC)
• Forcibly deprecate if we can get the developers to allow us to do it, and Support as second choice if not. No reasonable user who understands the situation would choose en-XX, and keeping the options around only confuses people and makes them waste their time figuring out the correct choice. We also ought to be doing all we can to discourage editors from wasting their energy maintaining the en-XX UI sets—having those forked makes precisely as much sense as forking English Wikipedia into American English Wikipedia and British English Wikipedia, i.e. zero sense. {{u|Sdkb}} ^talk 18:03, 1 October 2021 (UTC)
• Support. I've had a problem caused by selecting GB- User_talk:SilkTork#What's_broken?, which has now been fixed by reverting to standard en. What it offers (a simple spell check) can be problematic in itself as I am aware that I have automatically "corrected" spellings in articles which shouldn't have been corrected because that option is offered even when the article is supposed to be in American spelling. So it's a fairly useless gadget. SilkTork (talk) 16:45, 5 October 2021 (UTC)

RfC notice for establishing Wikipedia:Notability (television) as a guideline

This is a notice that an RfC has been started requesting comment on if the draft of Wikipedia:Notability (television) should be implemented as a guideline and a WP:SNG. Comments are welcome at the discussion, here. - Favre1fan93 (talk) 16:34, 27 September 2021 (UTC)

Migrate archive URLs from WebCite to the Wayback Machine

It seems to me that WebCite is obsolete now. I suggest to perform a script run/bot run to migrate all archive links that use WebCite to archive links using the Wayback Machine. According to our article, WebCite has not been accepting new archive requests since February and the site seems to be down since August. It seems unclear if WebCite will come back or not, so I think switching to a more stable archive service seems desirable. In particular, I think in cases were the original link is dead and a WebCite archive link is used, that link should be replaced by a Wayback Machine link if possible. I do not know how many replacements this task would entail, but I expect it would be impractical doing it manually. Toshio Yamaguchi (talk) 09:16, 30 September 2021 (UTC)

Recent changes for spammy/vandal IPs

A common theme when seeking admin intervention against a troublesome IP is that too many productive users will be caught in large range blocks.

Would there be value in having a page that logs IP ranges with vandalism/spam issues and then produces a recent changes queue limited to these ranges? Slywriter (talk) 12:43, 1 October 2021 (UTC)

Discussion at MediaWiki talk:Editpage-head-copy-warn § Can we remove the content reuse disclaimer?

 You are invited to join the discussion at MediaWiki talk:Editpage-head-copy-warn § Can we remove the content reuse disclaimer?. {{u|Sdkb}} ^talk 03:03, 2 October 2021 (UTC)

Ability for Extended Confirmed users to Protect their own talk page

This is a quite big and good feature to have as of right now, i have been getting quite a bit of ip's vandalising my page and doing the request to protect my talk page is time consuming, a feature i would request is for all Extended users to be able to protect their talk page from ips. MoonlightVector^{Talk page} 14:50, 4 October 2021 (UTC)

MoonlightVector This is a form of a perennial proposal, see Wikipedia:Perennial proposals#Grant non-admins admin functions within their user space. 331dot (talk) 14:52, 4 October 2021 (UTC)

I don't think it's possible to gives users permission to protect specific pages without admin rights as if you're able to add protection to 1 page, you're able to add protection to all pages. However if this is possible then I think it should be a separate permission from Extended Confirmed similar to rollback to prove that the user will be able to use it correctly and not use it to just prevent people from warning them or something on their talk page. 331dot makes a good point above. ― Blaze The Wolf^Talk_{Blaze Wolf#6545} 14:53, 4 October 2021 (UTC)

• If you have a habitual problem with IPs vandalizing your talk page, you may request indefinite protection. 331dot (talk) 14:55, 4 October 2021 (UTC)
• Another option is to treat your user talk page the way you might treat voicemail on a phone… simply clearing/deleting any messages you don’t want to keep.

I regularly clear my user talk page after I have read new messages (not just vandalism). And I have found that Vandals tend to go away if you don’t respond to them. Blueboar (talk) 15:16, 4 October 2021 (UTC)

Your 2nd part is the entire reason WP:DENY exists. The trolls want attention. You deny them that, they get bored and leave. ― Blaze The Wolf^Talk_{Blaze Wolf#6545} 23:39, 4 October 2021 (UTC)

Semiprotecting pages of UFC Events

It is well know that the results of UFC events are often subject to vandalism. Wouldn't it be better to semi-protect the articles (as the event nears) to allow only registered users to edit. Most of these fake edits come from IP accounts. Registered users would get banned if they do anything spooky. I posted this suggestion in WT:WikiProject Mixed martial arts. but was doubtful for a response as it is quite inactive. I am not a highly experienced editor. Just thought of sharing my suggestion to the editors here.--Atlantis77177 (talk) 10:09, 6 October 2021 (UTC)

As it is policy to encourage people to try editing Wikipedia without requiring that they first register an account, we in general do not pre-emptively protect pages. If repeated vandalism or disruption over a short period becomes a problem on a page, we can temporarily protect the page or block IP addresses or ranges from which abusive edits are being made. - Donald Albury 13:50, 6 October 2021 (UTC)

Idea lab

Ability to mark notifications from other wikis as read

Hello! So I'm not sure if this is at all possible but when I go to another Wiki I haven't been on before, I always get a notification when I come back to English Wikipedia saying I have notifications from other wikis, while being forced to go to that wiki (or at least click on the notification which takes me to the other Wiki) in order to mark the notification as read. I propose that we give users the ability to mark notifications from other Wikis as read from English Wikipedia (or whatever Wikipedia they mainly use) just like notifications from the Wiki they are currently on. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) (Stupidity by me) 20:15, 7 September 2021 (UTC)

• Support, it is so annoying when that happens. Sometimes I get notices from Wikis I have never edited because a change I made like a file rename in Commons was ported there. BD2412 T 20:28, 7 September 2021 (UTC)

It took me awhile to figure out, but there is a way to mark notifications from other wikis as read without going there. In the notification dropdown, there's a blue dot to the right of the notification. Click it to clear it and that will do it. Schazjmd (talk) 20:29, 7 September 2021 (UTC)

• I think that's a "problem solved", then. BD2412 T 20:34, 7 September 2021 (UTC)

I kinda wish it were a bit more obvious than that. Also @BD2412: you're not supposed to vote here. This is just for formulating ideas before you vote on them. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) (Stupidity by me) 18:54, 8 September 2021 (UTC)

• I'm aware of that, but I did it anyway, per WP:IAR. BD2412 T 19:29, 8 September 2021 (UTC)

  Fair enough. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) (Stupidity by me) 19:10, 9 September 2021 (UTC)

You can also do this at Special:Notifications, which is easily reached by choosing "All notifications" at the bottom of the dropdown menu. Whatamidoing (WMF) (talk) 16:35, 9 September 2021 (UTC)

I mean, that's functionally as awkward as having to go to that project to resolve it, but I was not aware of that blue dot method noted above, so will try that out next time. And I've just tested with 10 editors, and only a few knew about that working. Nosebagbear (talk) 15:41, 11 September 2021 (UTC)

Can confirm blue dot method works (though it looks like it wipes the notification rather than marking it was read) Nosebagbear (talk) 21:40, 13 September 2021 (UTC)

Hitting the blue dot does not wipe the notification on my Chromebook using MonoBook. - Donald Albury 23:00, 13 September 2021 (UTC)

Clicking the blue dot moves the notification between "Read" and "Unread". If you have a lot of notifications (I have 62 waiting for me this morning), then that will move it out of the visible list. Whatamidoing (WMF) (talk) 16:15, 14 September 2021 (UTC)

It removes the notification only while you are browsing a wiki other than the one where it originated. If you go to the originating wiki, you will see the notification of interest. IznoPublic (talk) 16:19, 22 September 2021 (UTC)

I'd like the ability to figure out what other wiki a notification is from when I am on my phone. In the responsive monobook skin, crosswiki notifications show the red/blue numbers, but the actual text notifications are hidden, and there is no obvious way to find out they even exist. I've previously used

.mw-echo-ui-notificationsInboxWidget-sidebar {display:block;}

in my monobook.css to turn the wiki selector on, but that messes up the formatting. Currently I'm just hoping I don't get crosswiki pings while on my phone. Any ideas? @Whatamidoing (WMF)? —Kusma (talk) 20:10, 14 September 2021 (UTC)

@Kusma, my advice is that you post that question at Wikipedia:Village pump (technical). Whatamidoing (WMF) (talk) 18:46, 15 September 2021 (UTC)

Been there, done that: Wikipedia:Village_pump_(technical)/Archive_190#Crosswiki_notifications_and_the_responsive_monobook_skin. —Kusma (talk) 21:23, 15 September 2021 (UTC)

Real-time reporting of election results

• Should live election results be reported on Wikipedia articles?

Live election results may contradict one another. The references to support the results soon become unverifiable because updated results erase any prior results. There is no protocol for determining which how often the live results should be updated, or if the reference needs to be static (like a webpage archived with the Wayback Machine).

See 2020 United States presidential election on November 5, 2020, for example. The references for the election results are live election results from ABC News and The New York Times, whose previous versions have been lost.

I have no objections to declaring winners based on election calls of reputable media organizations, or the reporting of final but unofficial results provided that our sources concur. wikinights _talk 20:07, 14 September 2021 (UTC)

• Yes, as long as it's made clear what the sources are and what the reporting figure is (e.g. as used in this infobox). This is pretty standard practice and is usually done quite reasonably. Number 57 20:17, 14 September 2021 (UTC)
• This is the idea lab, so what is your idea for dealing with this problem? Yes, on election nights in Western Anglophone countries we get a lot of such edits, but they seem to be fixed quickly enough for nobody who realises that this is an encyclopedia, not a breaking news service, to be inconvenienced. Phil Bridger (talk) 20:32, 14 September 2021 (UTC)
• Experience says it's basically impossible to stop people from adding such information in near real time. I don't think any "protocol" or special rules are likely to work. What would you do if people update "too quickly"? Fortunately counts usually finish at some point, and then we can use the final results and find stable references for those. Hyperlink references on old revisions are very often broken. That's just a fact of life. As long as current versions are working, I'm not bothered. —Kusma (talk) 21:11, 14 September 2021 (UTC)
• On election day & for a month after ward, an article should be semi-protected, due to oncoming mostly well-meaning but scarcely informed editing. GoodDay (talk) 23:50, 14 September 2021 (UTC)
• We basically already report election results in near-real-time. Overly excited editors tend to forget to add/update the refs, but that's why we have {{Current election}} enabled on election pages. I would be in favor of discouraging such reporting altogether (in the spirit of WP:RSBREAKING) but that's probably something that won't happen anytime soon. Dr. Swag Lord (talk) 06:56, 15 September 2021 (UTC)
• Yes. 🐔 Chicdat  ^{Bawk to me!} 10:25, 15 September 2021 (UTC)
• This is an encyclopedia, not a breaking news service. No. SQL^{Query Me!} 10:55, 15 September 2021 (UTC)
  • We update the stats for the players, are we not? Those are live. Elections should be treated the same. My only worry is that it might generate edit warring like crazy.--MollyPollyRolly (talk) 03:02, 23 September 2021 (UTC)
    • @MollyPollyRolly: "We" don't. A certain cadre of editors do — to the overall encyclopedia's detriment, IMHO. Enough of their frequent-flyer articles have ended up under Pending Changes protection that I'd love to ban the lot of them. WP:NOTSTATSBOOK anyway, but not one of their stats edits ever includes a single citation. How is any of that even supposed to be reviewed? (It doesn't help that the side-by-side diff view removes enough context that edits to table content are rendered near-indecipherable most of the time, and the visual diff more likely than not craps out because of the article length / coding complexity.) Thank you for the opportunity to rant about one of my pet peeves! 😁 -- FeRDNYC (talk) 15:55, 27 September 2021 (UTC)
• I see no issue with the status quo I see with most ongoing elections. Broad stroke reporting (number of seats, which may be subject to change but will largely remain static) should be added, but not full reports such as developing vote totals. JackWilfred (talk) 13:02, 15 September 2021 (UTC)
• This came up at WT:CANADA just a few days ago, Mathew5000 observed that while editors had rushed to update preliminary results in the template series for the 2015 and 2019 Canadian federal elections, the vast majority of those templates were never subsequently updated with official results nor verified, and have been hosting incorrect data for several years now. Wikipedia shouldn't do anything in real time, but if we're not going to actively prevent this behaviour then we need a concerted effort to go around and clean it up once official results are available. Some editors have also suggested adding a disclaimer to results templates indicating that results are preliminary, and maybe that banner could populate a maintenance category? Category:2021 Canadian federal election results by riding with unofficial results, as a subcat of Category:2021 Canadian federal election results by riding? That would be a big help. Ivanvector's squirrel (^trees/_nuts) 15:54, 15 September 2021 (UTC)

Undo Editor update

So whenever I undo an edit and add something to the edit I undid, I'm forced to use what I'm going to call the undo editor. It appears to be a version of the source editor, however I find it a bit hard to use, mainly when adding a reference or adding more than a few things, as there are some tools in the top bar of the source editor that I like to use when normally using the source editor that either appear to be missing from the undo editor or aren't as good in the undo editor. For example, on the page for Sonic Colors, I undid an edit and added a reference in that same edit, however the ref tool in the undo editor simply just adds <ref> </ref> instead of adding {{Citeweb}} as well as ref tags. So I have to publish the editor and remove the reference and then click the reference tool in the top toolbar of the source editor which allows me to simply put in the link of the reference and it will add the correct information (Such as the Citeweb template and ref tags) for me. I propose that we update the undo editor to be on par with the current source editor (maybe something similar to the reply tool that's being added). Blaze The Wolf | Proud Furry | Discord: Blaze Wolf#0001 (talk) 14:49, 16 September 2021 (UTC)

 Works for me @Blaze The Wolf: are you using mobile or the visual editor? Can you tell which editor you are using from this list: mw:Editor? When I'm on the undo screen, I get the same tools as if I'm in the normal source editor. Is perhaps your citation tool bar just collapsed? — xaosflux ^Talk 13:07, 17 September 2021 (UTC)

@Xaosflux: It appears it's because I"m using WikiEd which I didn't realize did that until just now. ― Blaze The Wolf^Talk_{Blaze Wolf#0001} 13:14, 17 September 2021 (UTC)

@Blaze The Wolf: thanks for the update, for bug reports on that personal user script, please follow up at: User_talk:Cacycle/wikEd. — xaosflux ^Talk 13:21, 17 September 2021 (UTC)

@Xaosflux: Nah I don't really think it's a bug. It's just a bit to complex for me to understand. ― Blaze The Wolf^Talk_{Blaze Wolf#0001} 13:23, 17 September 2021 (UTC)

mw:Editor has screenshots of all the editing environments I'm aware of. The "Undo" button always uses your default editor, which is always an old wikitext editor (either 2010 or 2003 versions). Whatamidoing (WMF) (talk) 19:17, 17 September 2021 (UTC)

@Whatamidoing (WMF): Why using an old version? Isn't there a new one? The updates should come out every week, if I am not mistaken.--MollyPollyRolly (talk) 02:59, 23 September 2021 (UTC)

If you haven't change your prefs, then you are the 2010 wikitext editor. It is rarely updated, because there usually isn't any need to change it. The date is the year that it was widely released. Whatamidoing (WMF) (talk) 16:46, 24 September 2021 (UTC)

Replacement for Interlanguage link template

This is a proposal to deprecate {{interlanguage link}} and define a new type of disambiguation/redirect page that includes one or more links to the appropriate page on one or more other wikis.

The primary issue that I raise with the existing solution is that multiple articles may have links for the same article which exists on other wikis but not on enwiki. Whenever there is any change to the set of wikis that should be linked to (perhaps the article has become available in another language, or perhaps an English-language version has become available), then all the pages referencing that article need to be modified ... we even have a bot which automatically replaces the {{Ill}} with a direct link when an English-language version becomes available.

The proposed solution is a form of disambiguation or "manual redirect" page that has whatever name that would presumably be used on enwiki. The pre-existing discussion is at Template talk:Interlanguage link § Proposed alternative to Template:Ill. Fabrickator (talk) 18:47, 19 September 2021 (UTC)

Note that this can be used in a citation, a meaningful advantage over {{Ill}}. Fabrickator (talk) 19:13, 19 September 2021 (UTC)

I think you misunderstand how {{ill}} works when that red-linked article gets created here – no manual change is required, the red link will turn blue and interlanguage links should appear in the left side bar. A bot may come along and remove the template. As for citations: several components of a citation can already be linked via {{ill}}. Author links are of course possible in free-text citations, and can be hacked into citation templates as well. -- Michael Bednarek (talk) 02:49, 20 September 2021 (UTC)

Sorry, I "mis-spoke" about how the template handles the case when an enwiki version of the page becomes available.... as that's the single situation which is handled okay, more or less. Every other case is handled poorly, in that it's necessary to edit each page which references the affected article when there's any other change to availability of interlanguage versions of the article. Fabrickator (talk) 06:44, 20 September 2021 (UTC)

I would be happy to see the templates and their redlinks being replaced with links to articles that provide at least a basic stub level of content, and with sufficient referencing to show the subject is notable. However, this proposal would see approximately 110,000 redlinks being replaced with links of a different color, and the creation of many new pages to which these recolored links would go. They would be each contain a list of external links to other wikis, but be lacking the level of content or citations required in standard articles. The idea that redlinks are ugly as they are highly visible and a clear indication of something being wrong (i.e. missing content) is not a major concern to me compared to the actual lack of content, something which I feel the proposal does not fix, but attempts to mask by using placeholder pages. There are numerous issues with the usage of this template, from inconsistency in the naming of the redlink to the order, number and selection of language links used with it. It may be possible to make adjustments to the template or create tools that can help to sort some of this, however, these issues are mainly the result of editing rather than the template itself. Changes to the documentation could help inform editors of some potential issues and how to avoid or work around them. EdwardUK (talk) 04:53, 20 September 2021 (UTC)

EdwardUK wrote:

I would be happy to see the templates and their redlinks being replaced with links to articles that provide at least a basic stub level of content, and with sufficient referencing to show the subject is notable

It seems like you are trying to apply some sort of technical rule that would have the effect of complicating or otherwise deterring the implementation of a presumably useful feature. I'm a little perplexed at this approach, given what seems to be a general consensus that these interwiki redlinks are expected to encourage the creation of new articles. Anyway, notability applies to articles, and I think we can distnguish between a redirect page and an article. Fabrickator (talk) 09:45, 20 September 2021 (UTC)

The technical rule is simply meeting the standard expectations of any standard article without which the article is liable to be deleted or draftified. Here it seems the intention is to circumvent these requirements by classing these as a different type of main space page for topics where there is another language version and I would be very surprised if these pages were not challenged either as a concept or on an individual level. I would expect the issue of notability to apply on the basis that wikipedia is not an indiscriminate collection of information, so inclusion here should not be based solely on the content existing on other wikis.

I understand these pages could be seen as starting points which could be expanded into full articles, but it is not clear at what point they would make the transition and the standard rules would apply. This would be a particular problem where content creeps in and it goes from "this article is not available" to "there is no article about topic X…" followed by a brief description for the benefit of the disambiguation and then to further details being added. With the redlinks there is a clear dividing line over there being an article or not, the proposed pages would make this line unclear. EdwardUK (talk) 16:40, 20 September 2021 (UTC)

I am not sure what the source is of your contention that these redirect pages could be expanded into full articles, but of course there's nothing preventing existing disambiguation pages from being expanded in this manner, and there are certainly some cases where a disambiguation page actually describes a term when there is no appropriate article to link to. Just take a look at the red herring disambiguation page. Fabrickator (talk) 18:43, 20 September 2021 (UTC)

There are certainly examples of disambiguation pages that deviate from the guidelines and have content that should not be there, but these pages are never intended to become articles, only to list topics for which there are already related articles on the English language wiki. What the language link pages would need is something more like a disambiguation/hatnote so that users could know exactly which topic there is no article for without having to open any of the links (or translate the contents).

It may be possible to use templates or bots to assist in creating both the redirect and language link pages if the text was kept simple and generic. (If I am correct in thinking that the proposal would create two pages for each topic, a redirect/article page and a links page, one being a page where the article will eventually be but is initially blank except for a redirect to the second page, which has the language links) However, adding the language links may be more difficult, and based on the size of the task I do not know how complicated or time consuming it would be to add the individual disambiguation for each page, and as it has been noted, the template has numerous cases of name and language variations for a single topic, which could result in many errors and page duplications which would have to be corrected too.

Once an article has been created (replacing the redirect) it would orphan the language links page. If these link pages were kept there could be a build-up of these redundant pages, and if deleted there is the same issue as happens with the template, that if the article is deleted or removed the links to it would turn red but the redirect and language links would not be restored. (This is one of the reasons I would prefer to have citations from the start, so that the articles are more likely to be retained.) When it comes to the creation of the articles I can see two ways in which this is likely to happen, either overwriting the redirect page with a full article, or as a result of additions of text on the links page until an editor decides at some point that it should be moved to the article page. EdwardUK (talk) 07:38, 21 September 2021 (UTC)

We've got to start off with some common ground about our attitude towards interlanguage links. On the one hand, the fact that we can use interlanguage links greatly increases the number of distinct topics that are potentially available to enwiki users, notwithstanding the fact that these articles are not in English. On the other hand, some of these articles might not meet the standards of what would be considered acceptable as an article on enwiki, notwithstanding the fact that these articles aren't in English.

So supporting this notion that we might be concerned about this is that some of these other wikis might not have similar attitudes about reliable sources, NPOV, or certain other policies we consider to be fundamental, and thus, such links could be harmful to the reputation of enwiki. If this is a substantial concern, we might restrict links to certain wikis which we consider to have a "like-minded" attitude compared to enwiki.

Now let's take a more positive stance. Given that there are at least some non-English wikis that do have similar standards, we will still have disagreements, certainly as to notability, for instance. And I'll raise the question that has been brought up in a sideways sort of manner: Are we inviting some kind of trouble if we allow a link to an article that would not be considered notable on enwiki, but which is considered notable on one of these "like-minded" wikis? Phrasing the question another way, if the folks running the Russian-language wiki allow there to be an article for some obscure Russian philosopher (yet this article does not exist on enwiki because the philosopher is not notable in the English-speaking world), and enwiki has an article mentioning that obscure Russian philosopher, should it be okay to have an interlanguage link to the article on the Russian wiki? Answer me that, and I think that would help us to move forward. Fabrickator (talk) 09:40, 22 September 2021 (UTC)

Yes. -- Michael Bednarek (talk) 10:52, 22 September 2021 (UTC)

See H:FOREIGNLINK. - Donald Albury 16:26, 22 September 2021 (UTC)

@Donald Albury: The whole point of this discussion is actually the deficiencies of the existing solutions such as {{interlanguage link}}. Some of the discussion has been to the effect that a proposed solution would create "disambiguation" pages (using the appropriate English name of the article) which would offer one or more interlanguage links to choose from, but one of the objections has been that those might not meet the "notability" requirement on enwiki. We now have one person agreeing that this should not be considered to raise a notability issue. Fabrickator (talk) 21:55, 22 September 2021 (UTC)

One solution to all this, will be to wait until a good translator will arrive and will translate this "obscure philosopher" article with attributed reliable sources.--Filmomusico (talk) 22:01, 22 September 2021 (UTC)

Unless the content of a page is terrible (in which case I would not bother) then linking to it would be fine, but that is not the same as creating an English language page for it. On the English wiki the quality expectations are higher than they once were, so there are plenty of older sub-standard and non-notable articles, (some which could be deleted or draftified but have not, either because they have not been noticed, they have been ignored, or the issues have been tagged but not resolved), and the situation is the same in other languages including "like-minded" wikis. The German article de:Arthur Kaan for example, (this being found on Achilles, the first article listed on the "What links here" page for the template) is of a quality which would be okay to have or to link to, but not necessarily to create. If the article already existed in English I think it would be kept, it seems notable and has sources but it would be tagged for lacking inline citations, however, as a new article it may be seen as inadequate until these citations are added, which would be difficult to do as of the three sources on the German wiki, one is not online and a version of another (Thieme-Becker) is behind a registration/pay wall.

If the proposed pages were implemented, then when information on the links page is added, (specifically the introductory disambiguation), it would be necessary if this is drawn from the other language versions to ensure that it has the correct copyright attribution, and that it is accurate, which may be unclear if the other version lacks citations. If it was on the English wiki the editor would be taking on responsibility for the accuracy of the information/content, whereas using the template they only have to ensure the accuracy of the link(s). It would also be necessary when attempting to fully create this article in English to not just use a direct translation but also make additional improvements, without which it could be draftified or deleted, with the redirect and link pages being lost. Unless there is a better alternative, then for this proposal to succeed, there would need to be a way to counter any pages being removed, this would require the creation of another type of template added to the redirect page, which would be retained when it becomes the article page (unlike the removable template used for changing the color of incoming links). These would inform admin editors of the option to restore the redirect page, not just move or delete the article, and could link to any tools that may have to be created to provide a method for un-deleting the links page and adding to it any messages regarding removed versions or drafts of the article. After the first set of proposed pages have been created to replace the existing templates I do not think any more pages of this type would be made because the combination of pages and templates needed would be very off-putting to editors trying to add it, instead they would opt for ordinary redlinks and argue for the restoration of the template which is much easier to use. EdwardUK (talk) 23:39, 22 September 2021 (UTC)

Not to make too fine a point of it, but I do not propose having separate redirect and link pages. I don't know if it helps any, perhaps we should drop the term "redirect", it's just a disambiguation page that may have links to one or more pages, pages which happen to be on other wikis. If it's decided to replace this disambiguation page with an article, some consideration could be given to how we "transition" it back to the way it was if it's decided to delete the article. This is worthy of giving some thought to, but building up some complex set of conventions may be overkill. I see this as a way of increasing the use of wikilinks to non-English wikis, so that there's only one place where the interwiki links (for a given article) need to be recorded, instead of repeating them on each page containing the term to be wikilinked. Fabrickator (talk) 00:09, 23 September 2021 (UTC)

The reason why interwikis exist is so that one can translate an article from one language to another. On the other hand, the articles that we write are translated more (because we have more) then in other languages.--Filmomusico (talk) 02:55, 23 September 2021 (UTC)

The only place the language links need to be recorded is on wikidata, the problem is that this is easily accessible from an article, where it is displayed on the left sidebar, but not from a redlink, and although the template allows a link to wikidata to be added, many of the editors that use the template probably think that it may be more helpful to link directly to another language instead of having to go through wikidata. If there was just a link to a single page, tagged with a "this is not an article" type template, then it would not need to have a list of language links as users could access the wikidata item and find the list of language links there.

Suppose though, instead of this disambiguation page, we were to have a modified "Creating…" page. This would require an addition to be made to the standard blank "Creating…" page (reached from clicking a redlink) of a feature (maybe a sidebar tool option) allowing the editor to pre-associate that name with an existing wikidata item before the article has been created. This could be used to generate a modified "Creating…" page for which all the matching redlinks could display in another color, for example orange. Then when another editor sees it they would be aware that when they clicked on this orange link it would take them to the modified "Creating…" page (something like https://en.wikipedia.org/w/index.php?title=____&action=edit&orangelink=1) from which they could either access the wikidata item, or create the article. This would remove the need for the template (and the language links it displays), without the need for the creation of disambiguation pages or having to create the list of language links that goes on it. Some editors with technical knowledge may have to assess the practicalities/possibilities of this concept, and there may still be some uses of the template that are tricky to convert, but it would very be simple for editors to add new links. EdwardUK (talk) 03:16, 23 September 2021 (UTC)

In principle, this might be an optimum approach, i.e. a single source mapping "equivalent" articles across all different language wikis. As a practical solution, I would be really skeptical. This means that existing editors (and perhaps non-editors) need to somehow be interacting with Wikidata. I looked at the Wikidata docs, trying to access info using the QID, couldn't make out heads or tails. I guess there's great stuff in there that I'm missing out on. (I tried finding the stuff mentioned in the left sidebar, I couldn't find that either.) So I am a totally clueless editor it seems. This would seem to be a huge barrier, maybe I'm the only one with such a blind spot, but I doubt it. My prediction would be that if we go this route, then only a small group of particularly technical editors will participate, it will become a feature regular editors can't effectively contribute to, they'll see that interlanguage articles exist but have no way to contribute. The ability to contribute is obviously a big part of the appeal of being an editor, adding interlanguage links look like a meaningful way to contribute (just as many editors feel they are encouraged to improve articles by adding wikilinks), but this will be beyond them. I am highly skeptical that the barriers this seems to create would be overcome. Fabrickator (talk) 15:37, 23 September 2021 (UTC)

The level of interaction would be little different than it currently is with the existing template, or would be with the proposed disambiguation page. Here the requirement is also for the initial editor adding the links to visit the external pages in order to verify their links are accurate. On most articles the link to wikidata is found in the left sidebar near the bottom of the tools section. (unless using the mobile website, or there is no item, or other display settings have moved/removed it) Adding links to wikidata would be much like when adding other languages, after opening a page on the relevant language site/wikidata an editor could use the search bar at the top right to look for the name and confirm if there is already a page for their topic, with wikidata the QID would appear next to the page title, which the editor could copy without having to take any editing action within wikidata. Then on the standard/redlink "Creating…" page, using a feature (which is not currently there and would need to be created) the editor could type/paste in the QID just as they currently do when adding it to the template. Note that until the article has been created this link would only be one-way, so that it would link to wikidata, but wikidata would not link back to the non-existent English article. When subsequent editors click on the orangelink, the sidebar of this "Creating…" page would not only have a wikidata item, but also the other features generated as a result of this, notable the language list, and also the commons link. These could be accessed directly from that page without having to go via the wikidata site. It could also see more consistency in the naming of links if, when an editor tries to turn a redlink orange by adding the wikidata ID, a message appeared if that QID had already been linked to a different name, so that they could then go back and adjust their redlink as needed. EdwardUK (talk) 19:12, 23 September 2021 (UTC)

@EdwardUK: WP:Wikidata § New articles seems to claim that the capability to create links based on Wikidata is already present. I tried following their instructions with Evgenia Zabolotskaya, adding ru:Институт общей физики имени А. М. Прохорова РАН via Wikidata. But that only updates the Wikidata. There are instructions shown for semi-automated migration and manual migration, but they do not seem clear enough to follow. Can you tell whether these instructions should actually work if I were able to figure out how to follow them? Fabrickator (talk) 21:30, 23 September 2021 (UTC)

Arbitrary section break

Fabrickator: Your merge of Evgenia Zabolotskaya (D:Q67166568) and ru:Институт общей физики имени А. М. Прохорова РАН [A.M. Prokhorov General Physics Institute of RAS] (D:Q16655721) at Wikidata was ill advised. Those articles do not cover the same subject and the merge ought to be reverted. -- Michael Bednarek (talk) 02:15, 24 September 2021 (UTC)

The wikidata instructions seem hard to follow, I get lost near the start as soon as it says to locate "Item by title", rather than just using the "Search Wikidata" box at the top right, but after that it looks like it should work. I have only tried some of more basic things on wikidata, (correcting info and adding links rather than merging and migrating) though I think some of this might be suited to editors more experienced than me. Also these instructions are designed for working with links and pages that already exist. Because, initially there would be no article in English for them to create a link for, editors would not need to know how to do this or any other editing within wikidata. If editors are aware of other language articles that are missing from wikidata they can add them, but it is not required as all they would be doing at this stage is looking for the QID. Entering this into the English wikipedia using a tool/option on the article creation page would extract and display the information from wikidata, without the page itself being added to wikidata. Effectively it is a tool that can be used to show a preview of the links that would normally only appear after the article has been created. Only when the English article had been created would there be the need to add it as an entry on wikidata, and the fact that an editor has already identified its matching QID should make this more manageable. EdwardUK (talk) 02:31, 24 September 2021 (UTC)

@Michael Bednarek: @EdwardUK: I'm not sure I see eye-to-eye with regard to the need for the English-language article to already exist. I think of the QID as a concept, in this case I was trying to apply this to the concept of a specific institute of the Russian Academy of Sciences. The concept exists independent of the existence of an English-language article providing information about that concept. Wikidata is proffered as a specific mechanism that substitutes for {{Interlanguage link}}, it doesn't make sense that the English-language article must first exist. I'm guessing that somebody knows how to do this, or else knows that there's some piece that's missing and it can't really do this, but that person is neither you (EdwardUK) nor me. Michael, is there any chance you can set us straight on this? Fabrickator (talk) 03:10, 24 September 2021 (UTC)

I think of Q-numbers at Wikidata as ISBN numbers or barcodes (note the stylized barcode used as Wikidata's logo) which identify a well defined entity; see Help:Wikidata. The Wikipedia entries at Wikidata then provide links to exactly that subject in various language editions of Wikipedia. -- Michael Bednarek (talk) 03:27, 24 September 2021 (UTC)

If the article did not exist, then in theory it would be possible to create what would be a redlink for it on wikidata, yet trying to do so would result in an error because the list of languages on wikidata is intended to aid navigation, for this reason it would not be desirable to have redlinks here as is the case with them being discouraged in our internal navboxes. I think consensus would probably also be against adding a redlink outside of the English wiki as I have seen a past discussion opposing the linking of our draft versions to wikidata in case this was to suggest to other wikis that something here was sub-standard or deficient, and I think adding redlinks would be viewed in the same manner.

With regards to the language template I have just spotted something interesting on the Chinese language version. An example can be found here: zh: 巴克斯特公園 (Baxter Park), linking to Sir David Baxter. This link appears to be their version of the language template, but the redlink and language links have been replaced with a green link. When the link is hovered over it changes to red and displays a navigation popup which roughly translates as: "Entry X has not yet been created, and can be found on the corresponding page of English Wikipedia:X". EdwardUK (talk) 06:51, 24 September 2021 (UTC)

I came across some other Wikipedia (can't figure out which it was) that provides a solution. See the link labeled "General Physics Institute" on User:Fabrickator/Evgenia_Zabolotskaya. Fabrickator (talk) 19:53, 24 September 2021 (UTC)

Aha! This is already supported {{Interlanguage link}} using the WD (QID) parameter... but of something like 50,000 instances of {{Ill}}, only about 2,000 use this feature, quite rare. I would suggest that using {{Ill}} without QID ought to have been deprecated (or at least discouraged), but Wikipedia editors are no different from other people, they repeat what they see and what they are familiar with. So we continue to propagate a use of {{tlc|Ill}] that doesn't really do the job very well. Fabrickator (talk) 04:00, 25 September 2021 (UTC)

The option to use the template to provide a separate link to wikidata next to a redlink avoids the problem of WP:SURPRISE caused by using a piped link. With the template I think that linking to wikidata should be encouraged in certain situations, mainly as an alternative to adding too many language links. But even with a wikidata link I think editors would continue in wanting to select the best ones and have direct links to these languages too, as they think readers would find this more helpful than just the link to the list of languages, and when there are only one or two languages then linking directly to them and leaving out the wikidata link could be seen as reducing unwanted clutter.

The maximum number of language links was increased from 5 to 12 in 2017, when one editor requested it to enable linking to all the language pages for a particular topic even though at the time only about 3 of these were anything more than a stub. I cannot see a significant benefit in this, the links to stubs did not add anything helpful, one or two links to the good pages were all that was needed, and even if they had all been good that would still have been sufficient. If the issue were to be raised again on the talk page again the number may be reduced. There is a certain amount of reluctance/hostility among some editors towards wikidata, but if asked to consider whether with this template it is more helpful to have a) numerous links to stubs, b) a link to one (or two) good article(s) and wikidata, or c) just to wikidata, my thought is that many would opt for b). When those options are presented with arguments towards greater consistency and neater appearance, I think that it would be possible to gain consensus to adjust the template, or at least to establish clearer guidance on how to use the template to best effect. EdwardUK (talk) 18:31, 25 September 2021 (UTC)

@EdwardUK: You wrote:

linking to wikidata should be encouraged in certain situations, mainly as an alternative to adding too many language links.

I consider it objectionable that, when you link using the QID, the Wikidata link doesn't appear if the enwiki article has come into existence (which is particularly problematic if the enwiki article is a stub). But the original concern I had, being the need to update the {{Ill}} template when the article becomes available in a new language, that's only resolved if the QID is specified. As for users being annoyed by being presented with a bunch of irrelevant choices, this problem is solvable by providing some sort of user-customizable language preferences... but WP editors can't be making the call about which interlanguage version is best (for how many reasons? ... even if the editor feels one language is preferable to another when linking from a specific article, that may change over time, it requires the ability to read the mind of the user, and it goes against the principle of having a single set of interlanguage article equivalences per source article).

Should I try to make this clear? We now have a way to record all the instances in which articles on "Prokhorov General Physics Institute" may be available in various languages. Assuming this article existed in several languages, and you would let the editor who's inserting the link in an article specify which language is best, based on the context in which it is linked? So now, the preferred link depends on the where it's linked from? Never mind that those articles change over time, and the best language to link to would also be subject to change, you're doing completely the opposite of what the QIDs do for us. The QID is suitably close to the right solution, and the only logical reason to avoid using it is a belief that nothing pertinent to the choice of link is ever going to change. Fabrickator (talk) 22:21, 25 September 2021 (UTC)

Here's an article where I resolved several links by QID. The one issue I had was where there was an existing article on enwiki for a different topic.... because that makes the Wikidata link disappear ... adding a qualifier solves the problem, also a couple of items had disambiguation pages in other languages, including a qualifier can reduce the risk of future collisions. All in all, this is a much better solution than using {{ill}} without a QID, IMO. Fabrickator (talk) 03:56, 26 September 2021 (UTC).

Something that would assist in creating versions of the template containing a wikidata link could be useful. There is a user script here: User:Cobaltcigs/IllWill, the description for which says it can be used with redlinks to search wikidata for the matching topic and then add the template with language links. (I have not installed it so am not entirely sure of how it works) It may already have an option for, or could be modified for, adding a wikidata link rather than languages. If not then it may be possible to create a similar user script that could be used for this. EdwardUK (talk) 03:47, 27 September 2021 (UTC)

My attention has been directed to WP:Wikidata § Appropriate usage in articles. I am not sure I fully grasp the rationale. The objection seems to focus on the reliability of Wikidata content, but (given my narrow view of WD as nothing more than a table of "equivalent" non-English language articles) this just strikes me as bizarre. This is how decisions are made here in WP-land, one more piece of evidence (IMO) giving credence to the hypothesis that WP is dysfunctional. Fabrickator (talk) 10:05, 27 September 2021 (UTC)

I was aware that opinion was generally against the use of wikidata and in particular the use of it to automatically add content to wikpedia articles (in case this content may be inaccurate), but the summary for the New RFC (June 2018) suggests no consensus over its use in the language template. Had the RFC banned this then the ability to use this parameter of the template should surely have been disabled and deprecated at that time, which did not happen, and since then another feature, the short= parameter has been added for use with the wikidata link. This would seem an illogical thing to add if the link itself had been prohibited. EdwardUK (talk) 15:44, 27 September 2021 (UTC)

One of the main objections to Wikidata was the fact that the Wikidata "reliable source" requirement might not be up to the standards of the enwiki reliable source requirements. In this instance, the QID is used to obtain a set of interlanguage links on other Wikipedia sites. The query as currently set up by {{interlanguage link}} uses an anchor to go to the Wipkipedia links section of the Wikidata page for that QID. It would be helpful if this could be chaned to display only the Wikipedia links, I presume that this is not too difficult to do. It might be desirable to have certain constraints on these links (e.g. disallow revision ids), but that concern is not a good reason to reject the concept... and to reject on this basis would result in a case of catch-22, nobody is going to fix this problem as long as such Wikilinks are disallowed.

With regard to the closure New RFC on linking to Wikidata (WP:Manual of Style), the statement :

As to the other proposed exception of linking to WD, by inline inter-language link, given that there is roughly a numerical tie and there's no clear-cut refutable argument(s) from either side, I am unable to see any consensus.

. But I think I am properly perplexed when this becomes:

Wikidata should not be linked to within the body of the article except in the manner of hidden comment(s) as to mentioning the Q-number.

It seems to me that you get to this depending on how the proposition is structured. For instance, if this had been interpreted as the following independent propositions:

* prohibit Wikidata links in hidden comments

* prohibit Wikidata links in interlanguage links

* prohibit Wikidata links in ordinary text

Then we'd have no consensus on the use of Wikidata links in interlanguage links, and given that the current state had been to allow them, these links would continue to be allowed. Fabrickator (talk) 01:17, 30 September 2021 (UTC)

@Fram: At User talk:Winged Blades of Godric § June 2018 RfC on Wikidata links, User:Fram responded to this, stating

No: there is consensus that Wikidata links are not allowed in text, and there is no consensus to make an exception for interlanguage links. Which means that the first rule also applies to the second case

.My response to Fram is "Thanks for providing the opportunity to elaborate on my point."

Of 31 votes cast, I interpreted 25 as having a statement that I could assign to one of 3 categories:

* 12 support the proposal (prohibit WD links in interlanguage links and ordinary text)

* 9 oppose the proposal (allow WD links in interlanguage links and ordinary text)

* 4 support the proposal with exception (allow WD links in interlanguage links, prohibit them in ordinary text)

So is this 16 to 9 in support of the proposal, while 13 to 12 (no consensus) to exempt the rule for interlanguage links? Or is it 16 to 9 to prohibit links in ordinary text, and 13 to 12 (no consensus) to allow them in interlanguage links (thus they would continue to be allowed). So with the identical facts, being presented two different ways yet reaching contradictory results, this demonstrates that the determination made in the closure of this RfC was arbitrary." Fabrickator (talk) 02:07, 3 October 2021 (UTC)

Why do we customize appearance of stub tags by topic?

I was recently questioning the utility for readers of having stubs display their category. For instance, at Lukas Lämmel (to choose the first Special:Random hit), why does it help readers to say This biographical article related to association football in Germany, about a midfielder born in the 1990s, is a stub. rather than just the standard This article is a stub.? Lämmel's page already establishes the basic information about him, so it doesn't help to repeat it at the bottom. It'd be better to be concise (or, if we're allowing ourselves some wordiness, to use it to provide better instruction on how to de-stubify an article). The icon is purely decorative. For editors, the stub category (Category:German football midfielder, 1990s birth stubs) already appears in the visible category list, and most stub sorting happens via sorters clearing out the maintenance category rather than stumbling on an unsorted stub anyways.

Given all this, I'm inclined to suggest (in a more formal proposal in a highly visible setting) that we stop using custom displays for stub tags and have them all adopt the standard {{Stub}} appearance. To be clear, I'm not considering proposing that we stop using sorted stub tags, which would be very different. Are there considerations I should have in mind for making such a proposal?

Note: I'm posting here rather than WT:WikiProject Stub sorting since I'm interested in feeling out what the likely response will be among a broad group of editors, not stub specialists. I'm putting an invite there, though, as I do want to hear from those more heavily involved with stubs. I'd appreciate if those coming here from that invite could note so in their comments. {{u|Sdkb}} ^talk 00:16, 21 September 2021 (UTC)

I don't claim to understand all of this metadata stuff that gets incorporated into WP, but it seems to me that having these somewhat vague characteristics be called out in a specific place (i.e. at the bottom of the page) serves multiple purposes:

1. This is content that should be populated at the initiation of the article.

2. This should avoid random editing later on..

3. It saves us from having to dig this out from the article as it develops over time.

Maybe I'm missing something, but it seems like this may be quite useful. Fabrickator (talk) 07:13, 21 September 2021 (UTC)

The text "related to association football in Germany, about a midfielder born in the 1990s," explains how the article gets into Category:German football midfielder, 1990s birth stubs. The rest of the text is boilerplate, it is generated by {{asbox}}. --Redrose64 🌹 (talk) 08:59, 21 September 2021 (UTC)

I have never been convinced by the theoretical basis for stub sorting, but I am happy it exists in practice. Let's talk about the history here: stub tags and stub sorting are old and predate both talk page assessment tags and the category namespace's transformation from a chaotic mess of tags into something resembling a system. Stub tags were always centrally controlled and provided a parallel and working system both for basic assessment and for categorisation. Sometimes this results in oddly fine categories like the one you mention above, a bit different from those used a long time ago on Ambrosius Stub, the best stub we've ever had. While we might not strictly still need this (if we assume that talk page assessments work perfectly, which isn't true either), it isn't terrible to have a redundant system in place. However, the really good thing about stub sorting in my view is not that it is all that useful by itself, but that most stub sorters perform a lot of cleanup tagging, page triage and categorisation while stub sorting. I'd be sad to lose that.

As for having different stub tags display differently: I kind of agree that it is more important that the article is a stub and that it should be expanded than what type of stub it is. For better visuals, all stubs should have a "stub" icon, not a distracting German football for the football related ones. (Similarly, Portals should use a "Portal" icon, not a decorative picture related to the portal topic). —Kusma (talk) 09:21, 21 September 2021 (UTC)

@Kusma: Thanks for that history! The broader thought about stub sorting being redundant to talk page banners and categorization did occur to me. It's hard to know whether getting rid of it would push stub sorters to add talk page banners instead or just make them give up. That would be an even huger change than what I'm considering here, though, and Wikipedians aren't exactly known for embracing bold changes to the way we operate, so I doubt it would pass. {{u|Sdkb}} ^talk 13:14, 21 September 2021 (UTC)

I like the idea, although Redrose does make a good point so maybe instead it could include what the subject is related to as part of the stub template since some stubs are literally 1 sentence, not really establishing what they are known for. ― Blaze The Wolf^Talk_{Blaze Wolf#0001} 15:07, 21 September 2021 (UTC)

I'm sure that somewhere there's an article that has a stub template that includes information that the article itself does not, but my sense is that it's very rare. If an article is so bad it doesn't establish the basic thing it's about, that's a problem beyond anything a stub tag can fix. {{u|Sdkb}} ^talk 15:16, 21 September 2021 (UTC)

Stub sorting and WikiProject banners serve separate purposes and are not interchangeable. Stub sorting is an article categorization task. The meaning is "This is a short article about Subject _____." WikiProject banners are associating the article with a semi-formal group of editors. It happens that most (but not all!) WikiProjects care about articles mostly (but not entirely!) within a given subject area, but others don't follow subject areas at all, and many articles are interesting to a wide variety of WikiProjects. Talk:Leonardo da Vinci includes 17 WikiProjects. WhatamIdoing (talk) 16:40, 21 September 2021 (UTC)

They're definitely not interchangeable, but if I were constructing Wikipedia's systems from scratch, I would make one system for categorizing things, not multiple partially redundant ones (categories, talk page banners, structured data at Wikidata, stub tags, even lists and navboxes). Anyways, this is all a tangent; if editors want to consider changing stub categorization more fundamentally, we should open a separate thread for that. {{u|Sdkb}} ^talk 17:22, 21 September 2021 (UTC)

If I were constructing Wikipedia's systems from scratch, I wouldn't put metadata in a free-form text file. WhatamIdoing (talk) 02:14, 22 September 2021 (UTC)

The images attached to stub templates draw attention to the stub tag; I hope that doing so might suggest an editor/reader edit the article, and images are more compelling than text. Also, I'm not fussy about what the text of the stub tag says, as long as it deposits the article in an appropriate stub category, for the use of editors who browse the categories rather than noticing the individual tag. (Also also, WhatamIdoing's point is spot on and not germane to this discussion, though I understand why folks think "Stub-Class article" and "stub" are related.) Her Pegship (?) 16:50, 21 September 2021 (UTC)

• One reason for thematic stub tags is that a stub article, by its nature, is incomplete and so lacks information. The thematic stub tags therefore help both readers and editors understand the topic and take it forward. The graphical icon is also useful in drawing the reader's attention and encouraging them to develop the article. They are also reasonably attractive and inoffensive. They thus compare very favourably with the obnoxious banner tags at the head of articles which are far more unpleasant and unhelpful. It is those which should be done away with. Andrew🐉(talk) 18:48, 21 September 2021 (UTC)

  Per my reply to Blaze the Wolf, I don't think stub tags actually tend to bolster understanding of a topic in the vast majority of cases. But even for the cases where we do, a stub tag isn't where we want to be doing it for a multitude of reasons: it doesn't fit with their essential message (designating an article as a stub), they're at the bottom of a page (whereas we want essential info at the top), and they're going to be removed once the article is improved. {{u|Sdkb}} ^talk 19:00, 21 September 2021 (UTC)

  they're going to be removed once the article is improved - that's kinda the point, we want people to expand the article and when they do so, that will justify the removal of the stub tag. --Redrose64 🌹 (talk) 23:40, 21 September 2021 (UTC)

I'm sure this sounds/is stupid, but I find that the stub tag categorization line encourages improvement of the article because, by indicating in the voice of the tag itself that the tag knows what the article is about, it makes it feel like someone has thought about how this article fits into the broader encyclopedia. If I read "This food-related article is a stub" I feel that Wikipedia's coverage of food in general is lacking because of this article's stubbiness, not just that this particular niche article is too short. This increases the urgency in a way that I find maybe helpful or at least charming. CapitalSasha ~ talk 19:40, 21 September 2021 (UTC)

I agree that the icons should be removed. They serve at best a decorative purpose. Some people here are arguing they should be kept because they "draw attention to the stub tag", but I think this is precisely the reason they should be removed. If drawing the reader's attention away from the content of the article and toward the invitation to improve it is a valid goal, then why not make them flashing animated gifs to achieve that goal even more effectively? Colin M (talk) 23:46, 21 September 2021 (UTC)

As the stub tag and its image are located at the bottom of the page, I don't see the (very small) icons as drawing attention away from the article itself; they're discreet enough to catch the eye but not so intrusive as to demand the reader's attention. In a related aspect of the appearance of tags, if the icon is a problem I would at least propose that a generic stub icon such as be applied to all stub tags (though it would be too bad to waste the effort we've put into creating appropriate icons!). Her Pegship (?) 00:09, 22 September 2021 (UTC)

I have a pretty significant case of Banner blindness where stub tags (and much of the English Wikipedia's other infrastructure) is concerned. Could any of the editors here comment on whether they personally have expanded an article because the image in the stub tag caught their attention? WhatamIdoing (talk) 02:18, 22 September 2021 (UTC)

I chronically forget to remove the stub tags AFTER I'm done improving the articles. It's a curse. I've probably annoyed other editors over it. I've never paid it much mind otherwise, as a reader or editor. Estheim (talk) 06:37, 23 September 2021 (UTC)

I doubt that anyone is annoyed by that. They're probably just grateful that you expanded the article. WhatamIdoing (talk) 18:27, 23 September 2021 (UTC)

Lol, hope so! Trying to psychoanalyze how I feel about decorated vs non-decorated tags, the ones that are decorated make me think the article is a part of a highly active and enthusiastic Wikiproject. Like, I wouldn't be surprised if Hurricanes and Military articles had more decorative stub tags, but it can create that impression even if the actual Project is actually moribund. This is speaking as an editor, not as a reader. Estheim (talk) 19:45, 23 September 2021 (UTC)

@WhatamIdoing: I think the Wikiproject assessment is more likely to lead to improvements. At least in the Wikiprojects to which I belong, the tables of importance by quality are used to try to ensure that if possible Top or High importance articles aren't stubs. I can't recall having responded to a stub template or the categories created by stub templates. Peter coxhead (talk) 08:02, 23 September 2021 (UTC)

Using TV/radio call letters/signs instead of station branding for News articles citations (US and Canada)

I am aware that any station in the US and Canada would use a generic brand of a newscast with the name of the network and it can happen to most stations. Others use different names. Here's an example of what I mean:

• If you refer to ABC 7 (Or in other cases, ABC 7 [Eyewitness/Action] News) for source, it's either KGO-TV, KABC-TV, WLS-TV, WABC-TV, or any other TV station that is in that channel affiliated to the network.
• If you refer to Fox 5 (or Fox 5 News) for a source of the article, you refer to KTTV, WTTG, WNYW, or other stations with the name Fox [Channel number] News.

Replacing the station's name for their newscasts and using just the station's call letters (for an example: ABC 7 in New York as WABC-TV]]) is in my view the best solution so it can not only become clarified, but it makes it easier for people to know which station it is directly coming from. I must mention, this should apply to local newscasts in the US and Canada. I really feel that its much better this way so people don't have to figure out which station this source it goes to and eases up the need to search which source it is coming from. 20chances (talk) 00:33, 21 September 2021 (UTC)

Why does it matter which station it's coming from, if they're all showing the same newscast? WhatamIdoing (talk) 16:42, 21 September 2021 (UTC)

The proposal is for local newscasts, which rarely get picked up by the national networks. - Donald Albury 18:14, 21 September 2021 (UTC)

Are the USA and Canada the only ones where two different stations far enough to each have the same place in the over the air spectrum that would be designated the same way? Could this also apply to the different broadcasters that are part of ABC (Australia)?Naraht (talk) 18:45, 21 September 2021 (UTC)

All TV stations in the US and Canada broadcast regionally. However, they're affiliated to the network that they broadcast. For an example. WABC-TV only broadcasts in the NYC Area and airs ABC Programming. CBLT-DT in Toronto only airs in the Greater Toronto Area, and is part of the CBC Network. Australia has regional stations just like in the U.S. but it is different. 20chances (talk) 23:47, 21 September 2021 (UTC)

We normally refer to works by their titles, in this case that is part of the title of the source - the government license number could be useful, but in general is less informative. — xaosflux ^Talk 18:59, 21 September 2021 (UTC)

I will agree that using the station call letters (Like using KABC-TV (which uses abc7.com) for the use of any articles for its newscasts if using the article from the station.) My problem is that not mentioning the call letters and just using the name of the website from the station (ex: abc7.com for KABC-TV) or using ABC 10 to refer to a station in Sacramento or San Diego in California or other similar ones can not only be vague, but also confusing if not directed to the right source. 20chances (talk) 23:47, 21 September 2021 (UTC)

You certainly can do both. Here is an example citation:

{{Cite episode
|series=NBC 6 South Florida News at 12pm
|author=NBC 6 South Florida
|network=NBC
|station=WTVJ
|minutes=14|quote=This experiment concludes that water is wet
|date=2021-09-22}}

Which produces:NBC 6 South Florida (2021-09-22). NBC 6 South Florida News at 12pm. 14 minutes in. NBC. WTVJ. This experiment concludes that water is wet

— xaosflux ^Talk 13:53, 23 September 2021 (UTC)

My only if is what if there's a link to that segment that is posted online? 20chances (talk) 16:54, 23 September 2021 (UTC)

@20chances: we have lots of citation templates, that one is in Template:cite episode. — xaosflux ^Talk 16:57, 23 September 2021 (UTC)

@Xaosflux:I agree on the use of citations, but the problem is that some stations don't mention where the article and/or the news segment is uploaded. Sometimes, many articles do link a segment from a newscast (some don't mention the times on which it was actually aired) 20chances (talk) 01:39, 24 September 2021 (UTC)

@20chances: If you're citing a web upload of a video, probably best to use {{Cite web}} even if the video was aired on TV at some point. If you're looking to add a link to an existing {{Cite episode}} citation, it does accept the standard |url= parameter, though interestingly that parameter is documented as (emphasis mine) URL of an online location where the text of the publication can be found. (But then there's also a separate |transcript-url=, which makes me think |url= doesn't have to link exclusively to text.) -- FeRDNYC (talk) 18:00, 29 September 2021 (UTC)

{{Re|FeRDNYC]] Right. The only problem is that people will use the name of the website instead of the station's call letters as the source for the website parameter like the examples I mentioned above. So instead of using the URL abc7ny.com for the website parameter for the ABC station in New York, since there's 2 TV Stations on channel 7 that are affiliated to the ABC Network, it would be WABC-TV instead. Hopefully I'm trying to get it right.

Notified of Manual Reverts

Hello! So I discovered that you get a notification when someone reverts your edit in any way BESIDES a manual revert which I find rather interesting. So I propose that people are also notified when their edit is reverted manually. ― Blaze The Wolf^Talk_{Blaze Wolf#0001} 19:41, 22 September 2021 (UTC)

Just add the page to your watch list… then you can track all edits not just reverts. Blueboar (talk) 19:50, 22 September 2021 (UTC)

Won't this just create talkpage bombardment?--MollyPollyRolly (talk) 22:05, 22 September 2021 (UTC)

@MollyPollyRolly: The notifications never go to your talkpage though. ― Blaze The Wolf^Talk_{Blaze Wolf#0001} 22:21, 22 September 2021 (UTC)

@Blaze The Wolf: Where does it go then? I thought that notifications are linked to talkpages, like we see with ClueBot.--MollyPollyRolly (talk) 01:20, 23 September 2021 (UTC)

@MollyPollyRolly: ClueBot uses warnings which go to talk pages. Notifications go to the bell icon. ― Blaze The Wolf^Talk_{Blaze Wolf#0001} 01:21, 23 September 2021 (UTC)

@Blaze The Wolf: Still, even it does go to a bell icon, it will still be a bombardment of some kind. For example, a new editor edits an article which you revert by using manual revert. First, majority of new editors don't even pay attention to what is on top. Second, if the editor edits multiple articles at the same time, it might be considered as notification spamming.--MollyPollyRolly (talk) 02:31, 23 September 2021 (UTC)

@MollyPollyRolly: That is true. And the reason ClueBot's warnings go to the bell icon is because you are automatically notified about things on your talk page. ― Blaze The Wolf^Talk_{Blaze Wolf#0001} 12:16, 23 September 2021 (UTC)

They still require attention. I think it's a bad idea. Doug Weller talk 15:42, 23 September 2021 (UTC)

@Doug Weller: The idea itself is not bad, the outcome of it might spill a disaster to an already fragile project. :(--MollyPollyRolly (talk) 20:12, 23 September 2021 (UTC)

Ya, I realized that if someone makes an edit that is a manual revert of an older edit, if you got notified about manual reverts then it could spam multiple people's notifs. ― Blaze The Wolf^Talk_{Blaze Wolf#6545} 16:41, 24 September 2021 (UTC)

If memory serves, brand-new accounts aren't notified about being reverted. Whatamidoing (WMF) (talk) 16:59, 24 September 2021 (UTC)

That seems rather interesting. It can technically do both harm and good, depending on what the person behind the account is wanting to do. ― Blaze The Wolf^Talk_{Blaze Wolf#6545} 18:32, 24 September 2021 (UTC)

@Blaze The Wolf: I suspect the thinking there is that new users being reverted would be helped more by a talk page message (even if it comes in the form of a warning) giving some guidance about why they were reverted, vs. just a notification with no explanation behind it. And we are all encouraged to template the n00bs when we revert them, so they know what they did wrong.

Regarding the idea in general, I feel like it would have to be opt-in, if it were implemented. But would that be an all-or-nothing, sitewide opt-in, so you get notified every time there's a revert of some edit you made months and months ago and have already forgotten about? Or would it be on a per-page basis, in which case... yeah that really just sounds like the watchlist, huh? -- FeRDNYC (talk) 16:06, 27 September 2021 (UTC)

@Blaze The Wolf: The removal of request templates after fulfilling the request (like a file move or non-free reduce) is also a manual revert. Archiving of discussions can also result in manual reverts. — Alexis Jazz (talk or ping me) 21:12, 3 October 2021 (UTC)

What to do about infoboxes for soundtracks in film articles?

Wikipedia:WikiProject Albums/Backlog elimination drive: Album covers is an effort to reduce the Category:Album infoboxes lacking a cover backlog, which has approximately 24,000 entries. Over at WikiProject Film, editors are discussing how there are many film articles with infoboxes for soundtracks lacking cover art. The lack of images in these infoboxes is a major source of the backlog, but we're not sure how this can be resolved. Sometimes, soundtracks have unique covers, other times they are similar to film posters (fair use images).

If you have ideas, please contribute to the discussion at WikiProject Film. And, of course, editors are invited to join the campaign to reduce the missing album covers backlog. Thanks and happy editing! ---Another Believer _(Talk) 16:00, 23 September 2021 (UTC)

My only solution to this would be to add a cover (if available).--Filmomusico (talk) 20:15, 23 September 2021 (UTC)

Some option to make articles easier to read

Hello! So I had an idea of an option in the settings that would make articles a bit easier to read. My reasoning behind this is people like me (I'm autistic) have a hard time reading some longer sections of articles. This is mainly due to having sort of a short attention span, making it hard to read long sections of articles in one sitting. I propose some way to break up article sections in a way that makes it easier to read. I'm not exactly sure how we would do this which is why I put this in idea lab. Some of the ideas I have are making the text slightly larger, making different parts of the article highlighted in different colors, or making the space between different parts of the article/section larger. Let me know what you guys think and if you guys have any other ideas as to how we would make larger articles easier to read. ― Blaze The Wolf^Talk_{Blaze Wolf#6545} 16:40, 24 September 2021 (UTC)

I should probably specify that not everyone who has this issue is autistic. Dyslexia can also make reading articles an issue. ― Blaze The Wolf^Talk_{Blaze Wolf#6545} 16:44, 24 September 2021 (UTC)

@Blaze The Wolf, have you tried "new" Vector? @AHollender (WMF) designed it to have a narrower width (on most people's font/screen-size combinations) because shorter lines are easier for many people to read. If you want to try it out, then go to Special:Preferences#mw-prefsection-rendering-skin and un-check the "Legacy vector" item.

Remember: It often takes people two weeks of regular use to get used to a change in the appearance of a website. A few things (e.g., the search bar and links to non-English Wikipedias) are in different places, and you'll have to re-train your habits. But if you stick with it through that adjustment period, you might find it easier to read articles. Whatamidoing (WMF) (talk) 17:06, 24 September 2021 (UTC)

At the same time, many of our articles do have over-long sections, which I'm sure puts a high % of readers off. Editors should get in the habit of breaking them up. It might be an idea if MOS:PARA actually specified a figure for a length that is likely to be too long - at the moment it just says cryptically "paragraphs that exceed a certain length become hard to read" - yes, but what length? Johnbod (talk) 17:15, 24 September 2021 (UTC)

I wonder how it would work to have some kind cursor which highlights one paragraph at a time (or perhaps one line, or a contiguous span of N lines). As you finish reading each paragraph, you could use the up or down arrow keys to move to the next paragraph. A nice side-effect of this could be that the software keeps track of the last paragraph you read and when you revisit the page, gets you back to the same place. That might make it easier to read a bit, go away, and come back to read some more. -- RoySmith (talk) 18:04, 24 September 2021 (UTC)

I highlight (select) text as I read all the time. I suspect many people do. It drives me nuts when a website overrides the selection behavior (Medium, Feedly, etc.). Nardog (talk) 05:28, 25 September 2021 (UTC)

@Nardog: That is a close second, in my list of egregious web-design offenses that should be capital crimes, behind setting the visited link color the same as the normal link color. That I absolutely loathe, and (to all site designers guilty of this crime:) if I visit your site a lot, I will add a userstyle to undo your bullshit, you bunch of heathen, poo-flinging webmonkeys! -- FeRDNYC (talk) 16:11, 27 September 2021 (UTC)

Infinite scroll isn't the first, FeRDNYC? For shame. IznoPublic (talk) 20:17, 29 September 2021 (UTC)

@Izno: Heh. I have nothing against infinite scroll per se — like too many things, it's neither inherently good nor bad, but its power can be difficult to wield correctly, and it's all too easily abused. Infinite scroll as a replacement for pagination is fine as long as (a) there's still a well-defined structure and ordering to the contents; (b) you can reach individual items directly, and (c) you can skip to a point within the infinite scroll, so you don't have to work down from all the way back at the start. (Granted, almost nobody does all of that correctly.)

Tumblr's archive pages for blogs are an example of "pretty good". They scroll "infinitely" into the past (until you hit the first post), and posts are grouped by month. You can start from the "top" (end/latest post) of any given month by selecting it from a dropdown menu, and the infinite scroll will work backwards from that point instead of from "now". You can also filter the contents of the list by things like post type or tag matches. It's mostly OK, really.

The sadly-more-typical "infinitely accumulating progression of barely-related content with no rhyme, reason, or (most importantly) navigation/control", though... well, I guess I figure that's more than a "bad web design" issue. Those sites are fundamentally engineered to convert users' wasted time into site revenue. -- FeRDNYC (talk) 22:52, 29 September 2021 (UTC)

@Nardog Yup, I do that too (selecting text to make it easier to read). Not as a regular thing, but it's an option I have in my toolkit when I'm faced with a website that's made just plain bad design decisions. There's lots of good human-factors research on how to make text easier to read. Font selection, line length and spacing, paragraph formatting, contrast, kerning, etc, etc. And then there's the legions of web designers who do things "because it looks good". -- RoySmith (talk) 20:42, 29 September 2021 (UTC)

@Whatamidoing (WMF): I've tried new Vector and I haven't really liked it. It seems really weird to all of the sudden have the article and sidebar be on the same "level". Overall it just feels weird to me and I haven't liked it so I've switched back to legacy Vector. Also, the narrower width isn't noticeable at all and to me it would just make sections seem longer. I do honestly wonder if it's because when I'm staring at black text on a computer screen, it all sort of starts to blur and black highlights form around the words and in between lines (which aren't really there, it's an illusion). I would honestly love for WIkipedia to have a dark mode but at the moment, Wikipedia's dark mode just feels like "high contrast" mode where the colors are reversed, therefore making a pseudo-dark mode. ― Blaze The Wolf^Talk_{Blaze Wolf#6545} 18:31, 24 September 2021 (UTC)

For RoySmith's idea, what we need is an accessibility expert who is also a JavaScript expert. Like RexxS (talk · contribs). --Redrose64 🌹 (talk) 19:22, 24 September 2021 (UTC)

• The Encyclopaedia Brittanica, in those far-off days when it was a paper encyclopaedia, used to be in two sections - the Micropeaida (Index and Ready Reference) and the Macropaedia (knowledge in depth). For example, when articles of famous people were in the Macropaedia, the Micropaedia would have a corresponding article for that person saying "Abstract of text biography." Would it help if all articles in Wikipedia were headed by an "Abstract" section, similar to the Micropedia articles in the Encyclopaedia Brttanica? YTKJ (talk) 21:38, 24 September 2021 (UTC)

That's what MOS:LEAD is supposed to be. Unfortunately, few articles are written that way RoySmith-Mobile (talk) 09:31, 25 September 2021 (UTC)

• There was an article a bunch of years ago, I think it was posted at Engadget but even knowing that I can't seem to find it anymore, it's been around 10 years so hardly surprising. But in the context of some speculation about the future of human-computer interfaces, one of the advances suggested was that eye-tracking software could observe your progress through an article as you read it, and effectively "mark your place" on the page as you go. Get halfway through a long-form Sunday NY Times thinkpiece and have to run out the door to catch a train? Pull the article up on your mobile device once you're on board, and the browser scrolls right to the last word you read so you can pick up exactly where you left off.

I mean, we all know the most likely use of such technology is to force people to actually watch ads in their content, or other evil manipulations of that sort. But, still, there are some potentially beneficial aspects to that kind of thing, deep down there under all the obvious perversions of it. -- FeRDNYC (talk) 16:27, 27 September 2021 (UTC)

Alright so I haven't really seen many ideas about this. I understand that New Vector might help, however some users don't want to use New Vector, so any ideas that might work with both New and Legacy Vector? ― Blaze The Wolf^Talk_{Blaze Wolf#6545} 19:07, 5 October 2021 (UTC)

Mnemonic for evaulating potential vandalism

Last night, I thought of a mnemonic for evaluating potential vandalism, and I wrote it on a user subpage (User:Plutonical/MOUSE). I'm posting it here to see what you guys think.

M - Maliciousness – Is the edit seemingly malicious?

O – Overtness – Is the edit openly and blatantly disruptive?

U – User – Does the responsible user have a history of vandalizing Wikipedia?

S – Source – Is the edit based on a reliable source?

E – Experience – Is the responsible user new?

Is this in line with current wikipedia policies in your opinion? Plutonical (talk) 12:08, 30 September 2021 (UTC)

This is a good idea for a mnemonic, but there is a change that I think can improve it. The experience of the user does not greatly influence if the user is prone to vandalising, for example: A user that has been on Wikipedia for 3 months can still vandalise, regardless of the time she/he has been on the site. Perhaps change the E to something more constitutional? I don't know, but I think this can be a potential improvement, regardless it is a good, nice, and rememberable mnemonic that can be extremely useful. --Pink Saffron (talk) 14:33, 1 October 2021 (UTC)

Point E being true does not mean the edit is more likely to be vandalism. It's meant to help check if it's a new user who really doesn't know much about the site and is using an article as a sandbox or damaging them accidentally. That way we avoid biting as per Wikipedia:DONTBITE Plutonical (talk) 14:26, 2 October 2021 (UTC)

• Points 3 and 5 seems slightly redundant to me, they both seem to be variants on "does the user have any productive contributions". It's also not the case that a user with experience is immune from vandalising, there's been quite a few cases of experienced editors making sock puppets to vandalise. I also think the "source" point misses the mark - if a user adding sourced content then it's probably more a case of WP:NOCLUE than vandalism - they're probably trying to improve the encyclopaedia, they just don't know the details of WP:RS. It wouldn't be obvious to a lot of newcomers that the daily mail of facebook are not suitable for adding content to articles for example, that doesn't make their edits vandalism. 192.76.8.74 (talk) 05:50, 2 October 2021 (UTC)

point 5 (E) is there to check if the user might be using random articles as a sandbox or damaging them for other reasons.. It's a measure against putting harsh punishments on newcomers. Plutonical (talk) 14:24, 2 October 2021 (UTC)

Really not sure you need an acronym to evaluate anything. 99%+ of vandalism is obvious to everyone, with the other 1% obvious to everyone who's familiar with the subject. Headbomb {t · c · p · b} 13:31, 2 October 2021 (UTC)

Default Protection of Closed RFAs

I was thinking and wondering, given how some RFAs experience vandalism, and it's very unlikely they'll be edited after closure, why RFAs aren't automatically fully protected by the closer as a standard practice? Could this be a viable practice? Would it make sense? ~Gwennie🐈｟💬 📋｠ 21:09, 3 October 2021 (UTC)

Full protection is a bit much as that would impede template maintenance, fixing lint errors and other such legitimate edits. But extended-confirmed protection would probably be a good idea. – SD0001 (talk) 08:50, 4 October 2021 (UTC)

Could you show me some statistics on how much of a problem this is first? — xaosflux ^Talk 10:27, 4 October 2021 (UTC)

I wish I could come up with some, however that feels like OR. ;) (How would I gather the requisite data?) ~Gwennie🐈｟💬 📋｠ 01:06, 5 October 2021 (UTC)

@Gwennie-nyan: in general, we only protect things when necessary to prevent disruption to the project. Over time we have had to extend certain preemptive protections (such as to templates that are widely used) because as a class they have been disruptively edited previously. We generally don't see a lot of disruption at closed discussions such as RfA (or the immensely larger number of AFD pages) - so to consider preemptive protection on them we should have a showing of a pattern of disruption first. I agree it seems reasonable that those pages don't have a need to be edited - and from a "content" perspective - they shouldn't be. From a technical perspective, sometimes they need to be - and currently can be by anyone doing such technical updates. — xaosflux ^Talk 01:16, 5 October 2021 (UTC)

My impression is that this issue isn't serious enough to warrant preemptive protection. If a particular RfA page is being persistently targeted for vandalism or harassment, then we could protect them individually, but we shouldn't protect all RfA pages preemptively, especially if, as SD0001 mentions, there are legitimate reasons for editing them after closure. See also WP:PREEMPTIVE. Mz7 (talk) 06:18, 5 October 2021 (UTC)

Import from Commons

On occasion we lose Commons-hosted images that we could have hosted as fair use had there been a simpler way to import the file from Commons (similar to how we can export to Commons). On another talk page @Alexis Jazz said this is possible by creating an upload_by_url user right that a gadget would then use to preserve/import the file's edit history. This would require community consensus for a configuration change, so wanted to open for discussion. If you're wondering what we'd be looking to import, offhand: (1) Any file that would sufficiently meet WP:NFCC fair use criteria but happens to be uploaded to the wrong place, (2) Images that meet our free use criteria (US-based copyright) but not Commons' (US-based and country of origin's copyright), such as freedom of panorama violations. Related: T214280. czar 04:55, 4 October 2021 (UTC)

I think I'd want to know exactly how upload_by_url works. Jo-Jo Eumerus (talk) 07:35, 4 October 2021 (UTC)

@Czar: is the workflow for this, with examples, available somewhere? I did a very quick direct test (resulting in testwiki:File:Лежка_моржей_на_острове_Нортбрук-test.jpg) which did get the file over, but did not get the "file's edit history". — xaosflux ^Talk 10:36, 4 October 2021 (UTC)

@Xaosflux: What do you mean? — Alexis Jazz (talk or ping me) 11:11, 4 October 2021 (UTC)

@Alexis Jazz: testwiki:File:Лежка моржей на острове Нортбрук-test.jpg was an upload_by_url from commons:File:Лежка моржей на острове Нортбрук.jpg. The upload part, and not having to mess with downloading and reuploading the file, itself seemed to go fine - but it did not do anything about preserving the attributions such as the original uploader information from commonswiki, or even mention the upload_by_url source in a log or in the file description. — xaosflux ^Talk 12:01, 4 October 2021 (UTC)

I think I confused Czar. I said It would perhaps be feasible to create a gadget if we granted users the upload_by_url right and added upload.wikimedia.org to the whitelist for that. I'm not saying it would be impossible otherwise, but it would be a whole lot less messy. Either way page/upload history wouldn't be preserved this way, only mw:Extension:FileImporter can do that. The either way here means that a gadget, whether it uses upload_by_url or not, will not preserve page/upload history like fileimporter does when exporting to Commons and this way refers to gadgets in general. It's just that a gadget with upload_by_url would be easier to create and less prone to errors. Such a gadget would (oversimplified):

• Generate the link to the full image for use with upload_by_url
• Obtain wikitext of the filepage on Commons
• (optional) obtain username of the original uploader
• (optional) do some replacements for Commons-specific templates, remove DR templates, etc
• (optional) do some replacements based on user input (I'm thinking a little form where you select PD-USonly, non-free logo, non-free biog-pic, etc)
• (optional) check if the image is >0.1 megapixel and claimed as fair use, if so tag for non-free reduce
• Upload file here with the updated wikitext

Hope this clears things up. Without upload_by_url the image would have to be downloaded to the computer of the user and uploaded to enwiki. That would be more complicated and more likely to fail so I'm not particularly interested in trying to walk that path. — Alexis Jazz (talk or ping me) 11:11, 4 October 2021 (UTC)

• Without solving for the how to ensure proper licensing and attribution components, working on the how to change the download/upload workflow to link-for-upload doesn't seem extremely useful (nor is yet figuring out who should be allowed to do this, and how/if to manage such group). How prevalent is this situation, and is there someone that wants to work on building the mechanics for such a process? — xaosflux ^Talk 15:12, 4 October 2021 (UTC)

Adding several namespace shortcuts

Moved from WP:VPP

While contributing to English Wikipedia, I found that some namespace shortcuts are missing. For example:

• H: pointing to Help:
  • HT: pointing to Help_talk:
• T: pointing to Template:
  • TT: pointing to Template_talk:

if we add these shortcuts to English Wikipedia, this will makes links shorter and easier to access, esp. with shortcut services. Wiki Emoji | Emojiwiki _Talk~~ 12:27, 5 October 2021 (UTC)

HT: and TT: are interwiki prefixes, so they can't be used. WT: isn't a namespace shortcut either, but there are many redirects substituting for that. See Special:PrefixIndex/H: and Special:PrefixIndex/T: for existing shortcuts. Making more shortcuts just means we'll have more strange cross-namespace redirects such as Wikipedia:Kill (the page should properly be called Project:Kill). —Kusma (talk) 12:38, 5 October 2021 (UTC)

• Administrator note @Emojiwiki and Kusma: I moved this to VPI, it is certainly not a ready-to-go policy proposal (and I really don't think it ever will require a policy update even if it was to go forward). — xaosflux ^Talk 14:32, 5 October 2021 (UTC)
• Please see Wikipedia:Perennial_proposals#Create_shortcut_namespace_aliases_for_various_namespaces for some background on this topic. — xaosflux ^Talk 14:32, 5 October 2021 (UTC)
• @Emojiwiki: ht:Paj Prensipal, tt:Баш бит — Alexis Jazz (talk or ping me) 15:44, 5 October 2021 (UTC)
• Digression: Note enwp dot org is not owned by the Wikimedia Foundation. Reader beware if you make use of it. isaacl (talk) 22:32, 5 October 2021 (UTC)
  • Indeed. If you want to generate short URL's use Special:UrlShortener, there's no need for external services. 192.76.8.82 (talk) 01:11, 6 October 2021 (UTC)

WMF

What we've got here is failure to communicate (some mobile editors you just can't reach)

Summary of overall issues: User:Suffusion of Yellow/Mobile communication bugs ProcrastinatingReader (talk) 03:08, 21 March 2021 (UTC)

Over a year ago, I reported two problems to the WMF:

Tracked in Phabricator
Task T240976

(1) Logged-in mobile web editors are not given a very strong indication that they have new messages. There's just a little number in a red circle. It's similar to what many other sites use for "Exciting! New! Offers!" and other garbage. There's nothing to say "A human being wants to talk to you."

Tracked in Phabricator
Task T240889

(2) Mobile web IP editors are given no indication at all that they have new messages. Nothing. Every template warning, every carefully thought out personal message, and everything else just disappears into a black hole, unless the user stumbles across their talk page by accident, or switches to the desktop interface.

But I get it. Bugs happen. They can be fixed. Instead both problems were marked as a "low" priority.

This is baffling. Problem 1 is a serious issue. Problem 2 is utterly unacceptable.

We are yelling at users (or even dragging them to WP:ANI) for "ignoring" our messages that they have no idea exist. We are expecting them learn without any communication all sorts of rules from WP:V to WP:3RR to WP:MOS that don't even apply to most other sites on the web.

Until they get blocked, of course. What a terrible experience. How are we supposed to gain new users when their very first interaction with a human is being told to f--- off, for "ignoring" a message they didn't even know about?

WMF, please explain to this community why this is a "low" priority. One year is long enough. Suffusion of Yellow (talk) 22:55, 16 February 2021 (UTC)

I'll just note that a majority of our users are accessing us on mobile so this isn't a niche problem either. Best, Barkeep49 (talk) 23:26, 16 February 2021 (UTC)

Wow. Neglected high-priority phabricator tickets are nothing new, but this is another level. Jimbo Wales, this deserves your attention. {{u|Sdkb}} ^talk 08:11, 18 February 2021 (UTC)

I would like to point out that the majority of messages left to IPs will never reach the user in question anyways, ESPECIALLY on mobile connections. Due to shared ips, the chance of someone else viewing the message before the person you are trying to reach is probably about 50/50. I realise that sometimes leaving a message is effective, but there are serious questions about all the cases where it is simply leaving a very confusing and often aggressively toned message to a completely different user just randomly reading an article at the busstop a month later. What we really need is a completely new way to leave messages to anonymous users. Possibly with some sort of very short lived session or something. But as ip users are more or less stateless (the software concept) right now, that is probably hard to implement. —TheDJ (talk • contribs) 09:26, 18 February 2021 (UTC)

@TheDJ: I would have no objection to expiring the OBOD if the talk page isn't clicked in a few days. Many messages come only a few minutes after the user makes the edit; most mobile carriers aren't that dynamic. Suffusion of Yellow (talk) 17:14, 23 February 2021 (UTC)

Tracked in Phabricator
Task T263943

Equally baffling is that mobile app users do not see any notifications, including no talk page notifications, logged in or out. The link to talk is buried within the settings. Official mobile apps! They don't even see block messages! See T263943 and others. This block review and also this discussion where an editor also tested block messages. The editor was blocked multiple times for something that was not their fault but that of a poorly thought out app. They are not alone. Quote from phab task: Conclusion: Using the app is like being inside a bubble, without contacts with the exterior. It's no wonder there's so much people complaining here that using the app caused their Wikipedia account to be blocked, for reasons they don't understand. ProcrastinatingReader (talk) 09:33, 18 February 2021 (UTC)

Tracked in Phabricator
Task T275117

Tracked in Phabricator
Task T275118

I have filed T275117 and T275118. ProcrastinatingReader (talk) 10:22, 18 February 2021 (UTC)

I'm always surprised that anyone manages to edit with the mobile interface. As another example, if you're not logged in, there is no way to access the talk page of an article, or even any indication that it exists. If an unregistered user makes an edit and is reverted with a common summary like "see talk", I imagine many will have no idea what's going on. – Joe (talk) 09:39, 18 February 2021 (UTC)

@Joe Roe: Sorry if this is not the right place, but I'm trying to find out why you can't access an article talk page if you're not logged in (on mobile). This was the only mention I could find. Do you know if this issue is being addressed anywhere? Cheers, Fredlesaltique (talk) 07:50, 18 June 2021 (UTC)

@Fredlesaltique: AFAICT the talk page link is a feature of mw:Reading/Web/Advanced mobile contributions (see § January 14, 2019 - Getting started with Talk page links), which is currently only available to logged in editors (I don't know why, though). See also phab:T54165, though that doesn't seem very active. – Rummskartoffel 11:30, 18 June 2021 (UTC)

The mobile web, and mobile apps, appear to be designed for readers and not writers. Having used mobile web occasionally, I think it's usable for logged in editing, but I do have to switch to desktop every now and then. I've used the iOS app only for a test - it is not usable for editing imo. ProcrastinatingReader (talk) 09:55, 18 February 2021 (UTC)

The number of edits I have made with the mobile web or app interface is most likely less than 50 (out of 13,000). Even for reading, the mobile interface is borderline unusable. I do frequently edit from my 4-inch cell phone screen (in fact, I'm doing that right now)... but I use the desktop version. —pythoncoder (talk | contribs) 14:04, 18 February 2021 (UTC)

I agree with Joe and have always found Cullen328 to be a bit of a superhero for being who he is on a mobile device. Best, Barkeep49 (talk) 18:19, 18 February 2021 (UTC)

Thanks for the kind words, Barkeep49, but I simply use the fully functional desktop site on my Android smartphone. It's easy. If I was the king of the Wikimedia Foundation, I would shut down the mobile site and apps, because they are an ongoing impediment to serious editing. RoySmith, there is no need to invest more effort (money) on a good editing interface for mobile, because that interface already exists - the desktop site. Just change its name from desktop to universal or something, and the problem will be solved.Cullen³²⁸ Let's discuss it 18:34, 18 February 2021 (UTC)

• In some parts of the world, laptops and desktops are common, and people's phones are their second screen. In an environment like that, yes, it makes sense for mobile devices to be thought of as a read-mostly interface. On the other hand, in other parts of the world (particularly India in the context of English language users), mobile is how people access the internet.[16] There's no doubt that building a good editing interface for mobile is a hard thing, but we should be investing more effort there. Poor mobile editing tools disenfranchises a large segment of the world's population. -- RoySmith (talk) 14:41, 18 February 2021 (UTC)

• @Suffusion of Yellow: Thank you for basically expressing exactly the same problem I wanted to. I have blocked a few editors who seem to be editing in good faith but just don't communicate, which eventually end up at ANI and after much agonising, get hit with as friendly a WP:ICANTHEARYOU block as we can muster. In the last instance, Mdd97 (talk · contribs), I specifically made a custom block template that said "CLICK HERE TO READ YOUR MESSAGES" in a way that they surely couldn't miss .... but again, following the block they've not edited again. We have to get to the bottom of this; if it's got to the stage where I've got to block people and the root cause is a software fault, it needs to be fixed. Surely the WMF can't be happy that I've needed to issue blocks on good-faith editors in this manner. Ritchie333 ^{(talk) (cont)} 16:10, 18 February 2021 (UTC)
• To address a reaction some might have, yes, the vast majority of users on mobile are readers, not editors, and no, I wouldn't want the community totally in charge of redesigning the mobile interface, since we'd end up with the phenomenon we have at desktop where e.g. the tools section of the sidebar is visible to every user on every page despite it being of zero use to 99.9% of them. But this request is not just editor-centrism; it applies to users who have already edited and who badly need a notification to help them not get lost. {{u|Sdkb}} ^talk 18:55, 18 February 2021 (UTC)
• I think the mw:Talk pages project, especially now that they are beginning to work on subscribing to notifications for talk page sections, could be interested in this discussion. Pinging User:PPelberg (WMF) and User:Whatamidoing (WMF). It also touches on UCoC Enforcement, highlighting that there needs to be funding for software dev. in addition to other measures. Pinging User:SPoore (WMF) and User:BChoo (WMF) for want of knowing who to contact regarding Phase 2. Pelagic ( messages ) – (09:51 Sat 20, AEDT) 22:51, 19 February 2021 (UTC) ... Adding User:Xeno (WMF) after seeing section above. Pelagic ( messages ) – (09:55 Sat 20, AEDT) 22:55, 19 February 2021 (UTC)

  Pelagic: Thank you for the ping and highlighting how this is a related need for my current project. I've been following this thread and will be including the comments (and phabricator links - thank you for those!) in my work categorized under important requests for additional human or technical resources to assist with on-wiki workflows. Xeno (WMF) (talk) 15:02, 14 March 2021 (UTC)

Question - Is this something that could be cured by bringing back the "Orange Bar of Death"? Mjroots (talk) 16:31, 22 February 2021 (UTC)

@Mjroots: the orange bar of death never went away. Last I check, it's still there for non mobile IP editors. That's why they get an indication of new messages. AFAIK, it was never there for the mobile web editor, that's probably part of the problem. Nil Einne (talk) 03:06, 23 February 2021 (UTC)

What no one has ever told me is why it was left out in the first place. Was it a simple oversight? Did someone have such a little understanding of how the sites work that they thought communication was unnecessary? Some other reason, that I'm not thinking of? This is the most confusing part. Suffusion of Yellow (talk) 17:14, 23 February 2021 (UTC)

I wish it could be brought back for all editors. Looks like bringing it in for IPs on mobiles could be the cure here. Mjroots (talk) 18:40, 23 February 2021 (UTC)

This is alarming but not surprising. Since I do a lot of question answering at the Teahouse, I'll point out a random IP's post from yesterday, in the same vein as some of the sentiments noted above: "Also, why don’t they get rid of the mobile view? So terrible!".--Fuhghettaboutit (talk) 00:29, 24 February 2021 (UTC)

• Does anyone with a (WMF) account plan on commenting in this thread? Suffusion of Yellow (talk) 17:21, 8 March 2021 (UTC)

  Don't hold your breath. For most WMF employees, commenting on Wikipedia using a WMF account is a quick way to get yourself fired. You might, if you make enough noise, get a department head to respond by saying that mobile users are very important to us and we will do everything we can to address this, up to but not including doing anything differently that we are doing them now. --Guy Macon (talk) 17:39, 8 March 2021 (UTC)

  @Guy Macon: When they did the same thing with desktop IPs, it was fixed within hours of being pointed out. Serious, not rhetorical question: what's changed about WMF culture since 2013? Suffusion of Yellow (talk) 17:58, 8 March 2021 (UTC)

When you spend three times as much money without the actual job you were hired to do changing, you start to focus more on spending all of that money instead of on doing your job. When you hire a boatload of new employees when the current bunch are more that enough to do the job, those new employees find something to do, whether that something needs doing or not. I'm just saying. --Guy Macon (talk) 18:31, 8 March 2021 (UTC)

• User:Suffusion of Yellow broadly you have two factors. Firstly there is little incentive for WMF people engage people here were they will get a bunch of people shouting that them (which is not fun). Secondly there has been a longstanding unwritten understanding that mobile is the WMF's turf while the community has more ownership of the desktop.©Geni (talk) 11:21, 11 March 2021 (UTC)

  Well, imagine this. Someone is standing on your foot. You politely ask them to move off of it. They don't. You repeat your request more loudly. They continue to ignore you. It still hurts. At some point, does shouting and shoving come into play?

  If WMF doesn't like being shouted at, well—certainly, no one does. But people do not like being ignored either, and doing so is an excellent way to get them started shouting just to be heard at all. Seraphimblade ^{Talk to me} 21:42, 14 March 2021 (UTC)

• Action from the WMF! One two three new mobile bugs I discovered while investigating this have been triaged as "low" priority, and a fourth was lowered to "medium", after a volunteer developer had raised it to "high". All without a word of explanation. The first (unparsed spam blacklist messages) isn't a huge deal I'll agree. But why is not telling users why they're blocked or falsely telling registered users that they're blocked personally not a major concern? That's how we lose people. Suffusion of Yellow (talk) 22:55, 22 March 2021 (UTC)
  • Can we locally block these apps from editing English Wikipedia? That would force the WMF to fix them. Fences&Windows 00:02, 26 March 2021 (UTC)

    @Fences and windows: Yes, this can be done with the edit filter. It could even be limited to users with no confirmed email address. But there's a catch. The apps don't properly display custom edit filter warnings, either! The iOS app just displays the title of the page where the message is stored. And the Android app doesn't display custom messages at all. The mobile web editor does display messages properly, however. Suffusion of Yellow (talk) 00:10, 26 March 2021 (UTC)

    If this were a lower-priority issue, I would say we should come back in a month and see if the WMF fixed it. But this is such a glaring oversight that I feel this may be the only option if we want to fix this. Question: would this apply to just the app, or to the mobile site as well? —pythoncoder (talk | contribs) 15:06, 29 March 2021 (UTC)

    It's app only (the user_app variable in the edit filter). ProcrastinatingReader (talk) 15:12, 29 March 2021 (UTC)

  Thanks, ProcrastinatingReader. If we prepare an RfC, where would it be held? It would need advertising on cent. Fences&Windows 23:47, 29 March 2021 (UTC)

  @Fences and windows: Any RFC will need some very careful drafting first. If it fails (for any reason) the WMF could interpret the failure as "see the community doesn't really care about this issue". Suffusion of Yellow (talk) 23:51, 29 March 2021 (UTC)

  We might want to move this thread to WP:VPT; this noticeboard is not widely watched. –xeno^talk 23:54, 29 March 2021 (UTC)

  I really don't want to rush into an RFC, though. There are many questions. Should we also disallow mobile IP web editors? Should we disallow edits from users with a confirmed email address? Which bugs, exactly, do we want fixed? How long do we give the WMF to fix them? This is a nuclear option. It should not be taken lightly.

  But please don't move the whole thread to VPT. It's here so it doesn't get buried in the archives. Suffusion of Yellow (talk) 00:33, 30 March 2021 (UTC)

  (edit conflict) Two-question RfC maybe? Initial brainstorm - Question 1: consensus 'letter' to WMF requesting resources be allocated to promptly fix the issues. Question 2: if not done within 90 days, mobile apps blocked from editing enwiki by edit filter. Best to move this particular matter to VPI. ProcrastinatingReader (talk) 00:36, 30 March 2021 (UTC)

  It has to be noted though that disallowing edits, if it comes to it, is really not great and rather bitey, as the editors will hardly have any clue what's going on due to EF messages being iffy. Maybe bugging Jimbo and/or Doc James to contact someone in engineering is a viable option? ProcrastinatingReader (talk) 00:43, 30 March 2021 (UTC)

  As I said. Nuclear. Suffusion of Yellow (talk) 01:09, 30 March 2021 (UTC)

  Yes, IDEALAB is the best place (for a new thread). That will discourage any supporting and opposing until we figure just what we're asking for. Suffusion of Yellow (talk) 01:09, 30 March 2021 (UTC)

  This needs caution—an overly enthusiastic RfC or proposal at WP:VPI is bound to be voted down and that would cause a lot of people to automatically vote down any future proposals of a similar nature. I'm thinking of masked IPs—any proposal to impede or block such users could easily fail if it appeared to be similar to an earlier idea to block "good faith" users who were unaware that communication was even possible, let alone required. Johnuniq (talk) 08:34, 30 March 2021 (UTC)

• I wish I could say I was surprised by any of this but I've long assumed that something like this was the cause of numerous editors I've come across who display quite clearly that they have never seen their IP/user talk page, and simply have no idea why their edits "aren't going through" (because a human editor keeps undoing them). A thorough waste of thousands of hours of volunteer time, on both ends. There are some countries or regions in which accessing the internet is only financially possible for the everyday person via a mobile phone, so the WMF's inaction here is another built-in systemic bias which prevents some cultures from effectively contributing their knowledge and skills to Wikipedia. — Bilorv (talk) 06:51, 29 March 2021 (UTC)
• Tracked in Phabricator
  Task T278838
  
  
  User:Suffusion of Yellow/Mobile communication bugs seems to be an excellent overview but it would get more attention if it were on phab. I have tried to roughly copy it to https://phabricator.wikimedia.org/T278838 which can probably be used as a parent task for all these issues. – SD0001 (talk) 15:04, 30 March 2021 (UTC)

Hi everyone, thanks for raising these issues, and documenting the problems so thoroughly. We're going to get a group of people from the Product department together next week to talk about these problems, and see what we can do about it. I'll let you know what we figure out. I appreciate you all bringing it up. — DannyH (WMF) (talk) 22:17, 7 April 2021 (UTC)

Thank you, Danny! I look forward to seeing what you come up with. Suffusion of Yellow (talk) 19:55, 9 April 2021 (UTC)

26 April update

Hi everyone, we talked in the Product department about the issues that are being raised in this conversation.

We're currently showing notifications to logged-in editors on mobile web, which appear as a number in a red circle at the top of the page. It's the standard design on mobile that indicates that there are messages for you.

We've been reluctant to do that for IP editors on mobile web, because mobile IPs shift around so much. Desktop IPs can change as well, so there's some risk of not reaching the right person on desktop, but the risk is a lot greater for mobile. People walk around with their phones and move from one wifi or cell tower to another. We haven't wanted to show a message bar to a mobile reader who happens to be picking up the same cell tower or wifi access point as someone who made an edit a year ago.

On the apps, the Android team has released improvements to the talk page experience in February and March. Echo notifications currently exist in the Android app, and user talk pages are also discoverable through the watchlist. Users can access article talk using a dropdown menu at the top right; you can see how this works in this walkthrough gif. There are some further improvements planned, including enabling in-line replies, and building onboarding features to help people discover both the watchlist and talk pages. You can learn more, and ask the team questions, on their Android communication project page.

The iOS team is also looking at improving the talk experience on their app. They're currently in the initial design and technical planning phase for enabling Echo notifications on iOS. Later this year, they're planning to fill in some of the missing collaboration features on the app, including making editing tools and talk pages more prominent.

There are some different things to discuss here, and I'd like to know what you think. — DannyH (WMF) (talk) 18:47, 26 April 2021 (UTC)

What are we doing about the block notification messages and the other edit screen notices?? —TheDJ (talk • contribs) 19:02, 26 April 2021 (UTC)

@DannyH (WMF):

• About IP users: As myself and others have suggested, there's a solution to the "random unrelated reader" problem: Don't show the alert if the new message is over X days old. Or (if the privacy policy permits) set a cookie anytime they click "publish", and only show any new message alert to people who have edited in the past X days. Or even both. I think most people already understand that messages sent to IP users are not guaranteed to reach the user. But we do expect that when 1.2.3.4 edits Foo, we leave them a message, and then an hour later 1.2.3.4 edits Foo again, that they've seen our message. That's the disconnect between expectations and reality that's been bothering us. You're also making the assumption that users on mobile devices are also on mobile connections. What about the phone user on their home WiFi? That could be stable for months.
• About logged in users: No, the red circle is not (only) the standard "you have new messages" alert. It's also the standard "we have some spammy garbage we'd like to sell you" alert. Of course experienced users know Wikipedia doesn't do that, but inexperienced ones are the people we're trying to reach. As matter of habit, I ignore similar-looking notices on unfamiliar websites.
• About the Android app: Again, what about spam-weary users who have turned off push notifications. With no in-app alert, how are they supposed to know that there is an urgent message on their talk page?
• About the iOS app: If users are currently in a total bubble, why enable editing at all? Why not wait until basic communication features are implemented, and keep the app read-only in the meantime?

I'm really getting the impression that the WMF thinks that user communication is an afterthought. Y'all didn't just forget one communication-related feature, you forgot most communication-related features. How did this happen in the first place? Suffusion of Yellow (talk) 20:15, 26 April 2021 (UTC)

@DannyH (WMF): Thank you for your time working on and responding to this. I recognize the difficulties in developing a good software product for the diverse projects that rely on MediaWiki software. However, I am deeply frustrated that this has been allowed to occur. Ensuring that existing community mechanisms for communicating with other editors, especially new editors, continue to function is a bare-bones requirement for any Wikimedia minimum viable product. To paraphrase Risker's related thoughts on Wikimedia software development in a different area: the intention behind a lot of this has been good, but sometimes I think engineers have no idea how our projects actually function and how significant some of these problems are. Frankly, if logged-out mobile editors don't have an interface to see messages, then the logged-out mobile interface should not contain editing functionality. Otherwise, this software is wasting many many hours a day of volunteer time tracking down and reverting and warning (not that they'll see the warnings) and blocking good faith IP users who are oblivious to community norms and this software is wasting just as much time spent by new editors trying to help out but unable to access any feedback about their editing. Best, KevinL (aka L235 · t · c) 10:01, 28 April 2021 (UTC)

Let me make more explicit a position that I suspect a broad swath of the English Wikipedia community may support: If the Foundation feels that it is impractical to build a communication system to communicate with logged-out mobile editors, then logged-out mobile users should be required to log in to edit. Wikipedia is a collaborative project; we simply cannot allow users to edit without being able to communicate with them effectively. KevinL (aka L235 · t · c) 10:05, 28 April 2021 (UTC)

Absolutely, thank you for the clear description of the situation. I was thinking of going rogue and just blocking any uncommunicative user/IP after a single warning. That would avoid mega-frustration and wasted time and would focus minds on fixing the problem rather than ticking boxes for the number of new edits from new users. Johnuniq (talk) 10:23, 28 April 2021 (UTC)

@DannyH (WMF): If fixing all the issues is going to take some time, and you don't want to disable editing entirely, can you break the Android app a bit more? See this. Using that hack a message can be conveyed to iOS users but the same can't be done for Android. It shouldn't take long to make the tweak, which would at least allow a custom mechanism to communicate a message to Android editors. Perhaps directing them to login via their browser app, for example. ProcrastinatingReader (talk) 03:16, 30 April 2021 (UTC)

Hi everyone, thanks for posting more thoughts. As usual, there's lots to respond to here.

It's true that the apps are late to including talk page features. That's partly because we didn't have a clear strategy for how we could improve talk pages sitewide — we knew that we wanted to improve the usability of talk pages, but the Flow project was not successful, and we knew that we needed to find a new direction. We determined that new direction with the Talk Pages Consultation in mid-2019, and then the Editing team started their Talk pages project to build tools for replying, starting new discussions and being notified when people comment in specific talk page sections. (If you haven't yet, you can turn on the new tools for replying and starting new discussions in the Beta preferences tab.)

As part of that project, the Editing team has developed the ability to break down wikitext conversations into individual comments, and all of that work is now informing the work that both the Android and iOS teams are doing to improve the talk page experience on the apps as well.

Now, one of the things that we do when a product team is working on a feature is to look at both the usage numbers and the revert rate for edits that are made using the feature. If the revert rate is higher than average, then clearly there's a problem with the feature that we need to fix.

Comparing the revert rates across desktop, mobile and apps, we see a similar pattern with both logged-in and logged-out editors. Looking at the last 30 days on English Wikipedia, mobile web edits have a higher revert rate compared to desktop edits. That's true for both logged-in users (10.2% revert on mobile web to 3.7% revert on desktop) and IP editors (35% revert on mobile web to 22% revert on desktop). Edits made through the apps are closer to the desktop revert rate. For logged-in app users, about 6.5% of app edits are reverted, compared to 3.7% on desktop. For IP app users, it's around 24% app edits reverted vs 22% IP edits on desktop. So while every single revert is a waste of time for somebody, we don't see app editing causing significantly more problems than desktop editing, especially compared to mobile web.

As I said earlier, the Android team has recently released improvements for talk pages just last month, and has plans to continue work on it, and iOS will be working on communication features later this year. So while those teams had a late start on these features, they are currently getting attention.

Some more specific points: Suffusion of Yellow, your suggestion about offering a time-limited message is interesting, and started a conversation in a couple of teams, so thanks for bringing that up. For your question about the assumption that mobile devices are used on the go: yes, there are definitely people who use mobile devices on stable IPs. However, it's a lot more likely that any given mobile device will be on an inconsistent IP than a desktop device.

Regarding people who ignore red circles and turn off push notifications, it's true that banner blindness is very strong, and that's a problem for web designers in general. However, we've found that when someone takes a specific step like turning off push notifications, responding with larger and more insistent notifications is not likely to help.

I'm happy to keep talking, if folks have more questions or suggestions. DannyH (WMF) (talk) 18:47, 30 April 2021 (UTC)

Danny, I'm intrigued and puzzled by your statement here. You have people here (and in many previous conversations) expressing frustrations at an inability to communicate with users. Some prior discussions have been about specific editors who have a mixture of constructive and troubling edits which are the kind of editors who can frequently be helped to stop the troubling edits. Your response, if I'm understanding it correctly, is that because there is no difference in revert rates for these editors compared to those on other platforms that the lack of communication doesn't matter. This might be true but would be a radical shift in culture in terms of how we handle disruptive editing and would be at odds with other foundation sponsored initiatives, including obligations to help new users in the UCoC. Can you help me either understand where I am failing to get what you're saying or if I do understand what you're saying how we, as an enwiki community, can square this circle. Best, Barkeep49 (talk) 19:17, 30 April 2021 (UTC)

Hi Barkeep49: What I shared about the revert rate was in response to a couple of things. First, Johnuniq commented on the fact that I'd only talked about edits from app users, and didn't acknowledge the impact on the editor community who have to clean up a mess. (The part about "ticking boxes for the number of new edits from new users.") It was also a response to the suggestion made in a few places that the apps shouldn't allow editing if the communication features aren't up to desktop standard. My point is that we do try to take the impact on the community into account, by making sure that features that we build don't result in a mess that's noticeably bigger than the mess that already exists.

But yes, this conversation is mostly about reaching specific editors who might be helped to stop making troubling edits. I agree that the communication features are important, and both apps teams have been and will continue to work on communication features. Some of the problems that we're talking about have already been addressed on Android; I think that in the case mentioned in the thread on Jimbo's talk page, they would have received talk page notifications as of March 30th — but that was sadly too late to reach that user. These conversations have inspired us to talk more about the communication features as a product team, and I appreciate the folks who have brought it up here. — DannyH (WMF) (talk) 20:37, 3 May 2021 (UTC)

DannyH (WMF), the desktop site is fully functional on modern mobile devices. The solution to this problem to shut down all apps and sites that are not fully functional, and redirect all users to the desktop site, which should be renamed the "fully functional site". That would save enormous amounts of money and draw a gigantic worldwide pool of new editors into the WMF free knowledge websites. Right now, we are erecting barriers to collaboration with people editing with mobile devices, and that is terribly sad. I speak as an editor who has been editing and more recently administrating with Android smartphones for ten years. 99+% of my edits are on smartphones. The WMF is spending buckets of money on a problem that does not exist, and making matters worse in the process. Cullen³²⁸ Let's discuss it

While this may have been a hypothetical, I would personally oppose such a proposal, solely because while the desktop site is functional on mobile, the text is still really small. The probably-crazy solution that immediately comes to mind is to switch the site skin to the new Responsive MonoBook, because that would display the content at a reasonable size on mobile while presumably allowing IPs to see the Orange Bar of Doom. (I haven't tested this, but I assume it works because unlike Minerva, MonoBook is maintained by the editing community.) Also, there are some plans to make Vector responsive too, but I don't know anything about that. —pythoncoder (talk | contribs) 22:19, 5 May 2021 (UTC)

At least a couple of us have disagreed with your view a few times, Cullen. The desktop site is not at all well optimised, and the apps are better for reading already. The solution is not to delete everything, rather than fix the issues. It's such an overly simplistic view anyway; compare this to this in terms of page size. I mean, the suggestion just isn't considerate of all the language projects and global users, and is just so unlikely to happen that it distracts from real solutions, which really is to disable editing in the interim / provide a roadmap, or at least allow the community to do that if it wishes to by consensus. ProcrastinatingReader (talk) 01:36, 6 May 2021 (UTC)

hear hear. —TheDJ (talk • contribs) 08:35, 6 May 2021 (UTC)

I agree that just nuking mobile and forcing everyone to use desktop is the wrong solution. What many people don't quite grasp is that not everyone is like them. They assume that because they have a large screen smartphone and a fast connection, then of course everyone does, and if a desktop website works for them then of course it works fine for for everyone else.

In the real world some people access Wikipedia on old flip phones, satellite phones with huge packet delays, rugged industrial phones with tiny screens, and ancient computers using modems.

I recently finished a preliminary design for a major toy manufacturer that includes a very low performance web browser with a really cheap display. That one got cancelled (90% of toys that make it to prototype do) but sooner or later you are going to see something similar in the toy aisle at Wal-mart for $29.95 USD. --Guy Macon (talk) 11:02, 6 May 2021 (UTC)

@DannyH (WMF): is this a joke or am I misunderstanding? You're saying that it's a deliberate design choice that mobile app editors are not seeing the messages being left for them? How do you suggest that we contact CejeroC, or does it not matter that thousands of volunteers' time (both newbie and experienced) are being wasted? — Bilorv (talk) 23:33, 29 May 2021 (UTC)

Hi @Bilorv: I think that you're misunderstanding slightly. It's a deliberate design choice not to show notifications for IP editors on mobile web, because there's a higher chance that we'll show the notification to the wrong person. It's more likely that a mobile web edit was made by someone who's moving around, so the notification would appear for a random reader who happens to be picking up the same cell tower or wifi access. We are showing notifications for logged-in editors on mobile web, and both logged-in and logged-out editors on the Android and iOS apps.

CejeroC was an editor on the Android app, which added talk page notifications in some changes made in February-March 2021. This was too late for the people trying to contact CejeroC, unfortunately, but it should be easier to contact Android app editors from now on. — DannyH (WMF) (talk) 18:35, 4 June 2021 (UTC)

Thanks for the reply, DannyH (WMF). I'm glad that I was misunderstanding, as the other option was deeply undesirable. My new questions are as follows: you're saying that it's a deliberate design choice that unregistered mobile web editors are not seeing the messages being left for them? Where can I see the WMF's data on the percentage of IP talk page messages that would have been seen by someone who was not the intended target, versus the percentage that would have been seen by the intended target? And how should a volunteer attempt to get in contact with an IP editor tagged as making mobile web edits, particularly when the IP has clearly been static for a non-trivial amount of time (based on the length of the editor's contributions)? — Bilorv (talk) 18:57, 4 June 2021 (UTC)

@Bilorv: I wish we could get data on who sees which notifications; it would make life easier. Unfortunately, we don't know. (There are a lot of stats that are typically collected by other big websites that we don't collect out of respect for users' privacy.) The judgment call that we're making right now is based on our understanding that a large number of IPs move around and are unreachable even on desktop, and that problem is obviously magnified for mobile IPs. For the question of how a volunteer could get in contact with a stable mobile IP editor, one potential workaround would be to leave them a message on the IP's talk page, and then when you revert one of their edits, you put a link to their talk page in the edit summary. That's obviously a hack, but IP editors having a talk page at all is kind of a hack. — DannyH (WMF) (talk) 20:58, 8 June 2021 (UTC)

I don't believe that the users I'm thinking of are aware that there's a page history—in fact, I often see behaviour that makes me think they are going "my edit didn't go through, why is it not there when I look again a few hours later?" after a revert (and I don't think the layout makes the page history obvious). I need to send a big fuck-off banner saying "SOMEONE IS TRYING TO TALK TO YOU ABOUT THE EDIT YOU DID" in order to engage attention. Unfortunately, no such functionality exists. I do appreciate the privacy afforded to readers and editors, but you're making a judgement call based on not very much—certainly not what the community wants—and using a 2001 IP-based system is not the solid foundation for communication that I need. (I understand the WMF is planning to anonymise IPs but not change them as the method of tracking unregistered contributors.) I don't necessarily want us to start tracking people with cookies, so I know every solution comes with a disadvantage, but this situation is honestly ridiculous. So much of my time is wasted with sending out messages to people who will never see it, and the alternative is just undoing what they did without explanation (what message is that to send to a newcomer? How can we get new editors involved by doing that?). — Bilorv (talk) 21:25, 8 June 2021 (UTC)

@Bilorv: As you say, the 2001 IP-based communication system is very flawed. The big f'off banner doesn't even work for desktop IP editors all too often, because IPs shift around, or just because the person who's making the edits doesn't understand or doesn't respond to talk page messages. For mobile IP editors, you're even less likely to make a connection. I think that if the folks who created MediaWiki twenty years ago were creating it today, they probably wouldn't use IP addresses as the foundation for communication, but this is the legacy system that we have.

I do think that the work that the Anti-Harassment Tools team is doing on "IP masking" will help with this, especially if we use cookies on mobile devices to associate the device with an auto-generated user name. There's a lot of planning and discussion left to do on the IP masking project, and figuring out how to communicate with "masked" IP editors will be one of many things to figure out. — DannyH (WMF) (talk) 22:42, 9 June 2021 (UTC)

@DannyH (WMF): We are showing notifications for ... both logged-in and logged-out editors on the Android and iOS apps. Can you link me to the phab task where the the lack of iOS notifications was fixed? I don't have an iOS device handy and phab:T274404 and its subtasks suggest work is just getting started. Also, the Android app still isn't showing me any alerts for logged-out talk page messages. And least no one has responded to my simple question at phab:T95396. So what have I missed? Suffusion of Yellow (talk) 19:37, 6 June 2021 (UTC)

@Suffusion of Yellow: Sorry, you're correct about iOS. I just checked my own post at the top of the section and realized that I made a mistake when I replied to Bilorv. Android has already made the changes; iOS is getting started on that work. I looked at your question on that ticket, which I think was not the correct ticket for that bug report — it looks like that ticket was closed in May 2020, and may not have been the right ticket anyway. I just asked the PM to take a look at it, and tell me where that report should go; I'll let you know when I get an answer. — DannyH (WMF) (talk) 21:06, 8 June 2021 (UTC)

Ah, I see that you've already made that connection on phab:T276147. At least, I think so. Let me know if I'm not correct. — DannyH (WMF) (talk) 21:22, 8 June 2021 (UTC)

@DannyH (WMF): So I understand there is still a subset of logged-out mobile editors not getting talk page notifications, yet they are still editing? This is unacceptable.

As has been stated above, if an interface does not have basic communication capabilities, then the interface should not have editing capabilities. --DB1729 (talk) 02:17, 8 June 2021 (UTC)

@DB1729: I understand your dismay; I agree that communication is essential for productive wiki collaboration. I think that at the root, this is actually a flaw in the concept of allowing people to edit without an account on Wikipedia. Twenty years ago, it may have been roughly accurate to assume that IP addresses were mostly stable, because everybody had a desktop and mostly a dial-up connection, so if you posted a message for a particular IP address then you were likely to reach the same person. Today, the use of laptops at wifi hotspots and phones and tablets using cell service has basically broken that model. A few years ago, we reached the point when mobile pageviews hit 50% of our traffic, and by now the majority of Wikipedia readers are accessing our site with a mobile device.

I think that your suggestion of restricting IP editing on mobile is an interesting one, and it's possible to argue that that should apply to desktop as well as mobile. But that's a much bigger conversation, and I don't think we'd be able to settle it here. — DannyH (WMF) (talk) 21:19, 8 June 2021 (UTC)

I don't have the data, but edits I make using my phone usually come from the same IP (my home or work wifi) that my desktop edits come from. (I use responsive monobook, so my phone edits count as "desktop"). What's inhibiting communication with some mobile editors is not that their IP changes, it is that the software they use is not fit for purpose. Do you know any of the people who can fix the software? —Kusma (talk) 08:28, 10 June 2021 (UTC)

@DannyH (WMF): Speaking of notifications Danny, for some reason I never got that ping from your last reply.(ironic) Did you get a confirmation it was sent? Thank you for the reply and for sharing your thoughts. In the meantime, yes I understand the dynamic IP problem, but these users are notified (I hope) when their IP addresses are blocked, are they not? Presumably when they open an edit window? Similarly, a talk page notification could be displayed only when there is an attempt to edit. It could then time-out or become invisible after a set duration, much like I assume a block notice will disappear once the block expires. DB1729 (talk) 15:48, 12 June 2021 (UTC)

#suggestededit-add 1.0

Tracked in Phabricator
Task T227623

I think it would be a good idea to also bring up what I think is the related issue of the #suggestededit-add 1.0 process, as this seems to a mobile idea. See for example Jomart Allaguliyev (talk · contribs), a new mobile user who has made over 1000 edits exclusively through this process. Most are fine, but some are wrong, and some are almost nonsensical. Sometimes they re-do and worsen their own better work! [17] [18]. They've also a few times made the same edit twice after being reverted [19][20], which feels like something popped up and they simply repeated the action? The only documentation seems to be on Wikidata, so it is unclear how exactly these are happening or where they're happening from. There is an old Phab task (T227623) closed suggesting the process is working as intended. CMD (talk) 02:42, 22 April 2021 (UTC)

I'm confused about how this is a suggestedit issue. That editor was given exactly one warning, as far as I can tell. If an editor is editing disruptively, the first step is to notify them on their talk page, isn't it? (Also, I have fixed your broken link above.) – Jonesey95 (talk) 04:26, 22 April 2021 (UTC)

Thanks for the fix. The user is not editing disruptively, on the whole. The point is, this user's edits are being solely guided by some program out there providing editing suggestions to new users, provided by WMF, of which there seems to be little documentation. How is it not a suggested edit issue, when any potential disruptiveness would presumably be due to this feature? It would be nice to have documentation. If the edit summaries are automatically generated, why don't they include a wikilink to such documentation? The Mediawiki FAQ states only that it is to "Add short descriptions to articles that are missing descriptions", which is clearly not the case given these are edits to existing short descriptions. CMD (talk) 09:14, 22 April 2021 (UTC)

As an update here, the page Wikipedia:Suggestededit-add 1.0 has been created by Guy Macon, but I'm still seeing edits like these ones which add the short description "Overview of the topic", and am no less enlightened as to whether these somewhat meaningless descriptions are being suggested by Wikimedia software. CMD (talk) 05:21, 13 September 2021 (UTC)

Another block. Any progress?

[21] Didn't seem like there was any other option. Any progress on resolving these issues? As I requested somewhere, any chance we can break the Android app some more so we can use a hack like Filter 1139 (for iOS) for Android users as well? That hack works due to the fact that iOS edit filter disallows do not parse the page but just display the page title instead. Android unfortunately uses a hardcoded vandalism warning, so this does not work there. It should be trivial for WMF engineers to make Android behave the same as iOS while they do proper fixes. @DannyH (WMF)? ProcrastinatingReader (talk) 14:19, 15 July 2021 (UTC)

@ProcrastinatingReader: It looks like the fix for edit filter messages on Android has made it to the official (app store) release. So it should be possible to "communicate" with Android users through the filter now. However, links in the edit filter message will open in the browser. And if they're viewing a wiki that isn't their default language, the links will go the wrong language wiki. e.g., if we (on enwiki) send them to Special:MyTalk or WP:EF/FP/R, they might end up at fr:Special:MyTalk or de:WP:EF/FP/R. I don't know if that bug is being actively worked on, but we're getting somewhere. Suffusion of Yellow (talk) 23:34, 17 July 2021 (UTC)

Suffusion of Yellow I don't know a lot about edit filter, but I (maybe) have an idea for a work around. Can we redefine all edit filter links as fully defined [external links] and explicitly point them to https://en.wikipedia.org/_whatever_ ? Alsee (talk) 12:34, 18 July 2021 (UTC)

@Alsee: Tested here. That seems to work. The first link (Foo) opens at frwiki (because that's the first language in my settings), but both testwiki:Foo and https://test.wikipedia.org/wiki/Foo open at testwiki. That should work for a filter like 1139 (hist · log) but I don't think we should "fix" the dozens of other messages to work around this bug. Suffusion of Yellow (talk) 20:06, 18 July 2021 (UTC)

Some progress - see the latest update at mw:Wikimedia Apps/Team/Android/Communication. Nthep (talk) 21:00, 2 August 2021 (UTC)

Seeking design help for minor edit pop-up box

The RfC at Wikipedia:Village pump (proposals)/Archive 179#RfC on limiting minor edits, asking whether minor edits should be restricted to autoconfirmed or extended-confirmed editors, was recently closed. The closer noted that there was "slightly more support" for limiting the box to autoconfirmed editors than continuing the status quo (requiring only registration), and although it wasn't quite enough for implementation, there is clear community dissatisfaction with the present functionality of minor edits. A sidebar I started about the possibility of a pop-up box received general support.

Mostly copying my explanation comment: Part of the issue we have with minor edits is that our definition of minor is not intuitive, and this means that we have to assume that people misusing the box are doing so out of ignorance, which makes it very difficult to do enforcement. One way to address this would be if, the first time an editor checks the minor edit box, a notice pops up with a brief definition of what we mean by "minor" (perhaps similar to the wording at {{uw-minor}}) that the editor would have to okay. This would ensure that everyone making a minor edit can be expected to understand what it means.

Would any of the design folks at the WMF be willing to help put together a prototype of what that notice could look like? That could then be presented to the community seeking consensus for implementation. {{u|Sdkb}} ^talk 23:05, 9 August 2021 (UTC)

@Sdkb: I wonder if a low-key way to do this change is to introduce a little info/question icon next to the "Minor" that includes an explanation of what it is? Something like in this image ->

TemplateWizard_extension_03

. -- NKohli (WMF) (talk) 00:37, 28 August 2021 (UTC)

@NKohli (WMF), that would be one option, but I'm not sure it'd be aggressive enough. The minor edit box already includes a link to Help:Minor edit, but I suspect very few people actually click on that (it's averaging 220 views/day), and I'm not sure many more would click on an icon. The problem is bad enough that the community is on the verge of disabling minor edits for new users entirely, so I think a more in-your-face form of education is likely needed. We could certainly experiment with different options and see what data we get. {{u|Sdkb}} ^talk 19:21, 28 August 2021 (UTC)

Implementing a popup could be useful, but as you say it's probably not actually going to get looked at if it's optional. Maybe we could do some sort of diff-analysis to have this suggested popup trigger itself if e.g. you've checked "minor edit" and you're changing more than 100 characters -- an "are you sure?" focus.

(I feel like in the long-term the "right" way to handle this would be for "minor edit" to be an attribute that's applied to an edit automatically via a system like ORES. The problem, of course, is that distinguishing between minor typographical corrections and incredibly-significant meaning-changes strikes me as a very tricky one.) DLynch (WMF) (talk) 23:45, 7 September 2021 (UTC)

@DLynch (WMF): Definitely. The current minor edit feature is like the evil bit. Automatic detection is likely difficult & a lot of effort for a low benefit really, but is probably how such a feature should work. ProcrastinatingReader (talk) 01:55, 8 September 2021 (UTC)

Automatic detection of minor edits would require strong AI-levels of intelligence. Even single letter changes can be major if they're, say, changing a subject's gender or taking a stance on a controversial MOS issue like she vs. it for ships. I don't see any way that could reasonably be automated. {{u|Sdkb}} ^talk 23:21, 8 September 2021 (UTC)

I agree, especially when you consider that I've made some minor edits that tallied at over a thousand characters difference when adding archives to deadlinks in a long list article. Thryduulf (talk) 02:05, 9 September 2021 (UTC)

A minor edit is one that the editor believes requires no review and could never be the subject of a dispute. Sadly, no automated process can reliably determine whether an edit requires review, let alone whether its author believes it to require review. Certes (talk) 10:40, 9 September 2021 (UTC)

Board of Trustees election has started

Voting has begun in the Wikimedia Foundation Board of Trustees elections! Voting ends at 23:59, 31 August 2021 (UTC). Verify your eligibility and vote now: https://meta.wikimedia.org/wiki/Special:SecurePoll/vote/Wikimedia_Foundation_Board_Elections_2021

-EpicPupper, your friendly local English Wikipedia election volunteer

🐶 EpicPupper ^{(he/him | talk, FAQ, contribs)} 18:32, 19 August 2021 (UTC)

Question: Are there any voter guides or other resources for first-time voters? —pythoncoder (talk | contribs) 21:16, 19 August 2021 (UTC)

I found this Q&A posed to the candidates helpful. (Though, incidentally, I found it a bit surprising that there were no links in the banner or the voting page to this sort of information, and that I had to do a google search to find information about the candidates.) Colin M (talk) 23:36, 19 August 2021 (UTC)

Hi @Pythoncoder, nice to meet you. I'm actually a first-time voter as well :) I find all the links at [22] helpful, especially the candidate table, Q&A, candidate profiles, general voting information and history, and information on Single Transferrable Vote (the voting format this election uses).

If it helps, personally, what I did in advance of the election was start a LibreOffice doc, look at the candidate question answers and statements, rank the top 10 of who I like, bottom 6 of who I don't like, and leave the rest in the middle. When voting, I then entered those in and picked randomly for the middle ones. 🐶 EpicPupper ^{(he/him | talk, FAQ, contribs)} 00:29, 20 August 2021 (UTC)

Thank you both so much for these helpful resources! —pythoncoder (talk | contribs) 01:13, 20 August 2021 (UTC)

rank the top 10 of who I like, bottom 6 of who I don't like, and leave the rest in the middle. When voting, I then entered those in and picked randomly for the middle ones – I see this was posted before the advice meta:Special:Diff/21908644/21913330. Would your approach change in light of that advice? —2d37 (talk) 19:40, 31 August 2021 (UTC)

I'm surprised they don't have a single page that presents basic info on all the candidates. I had to click open 20 or so tabs to see their info. What candidates do you guys like? I am just going to vote for folks that have the most edits on the English Wikipedia unless convinced otherwise. I feel it is important to make sure that our wiki is well represented. Those candidates appear to be Rosiestep, Mike Peel, AshLin, and Discott. –Novem Linguae (talk) 06:45, 20 August 2021 (UTC)

I've taken editing history into account but also looked at the candidates' statements. (Yes, it's a shame that takes so many clicks.) I'm not here to tell anyone which policies to like, but I do suggest you vote for whomever will try to lead the WMF in your preferred direction. I also attached some importance to answers to Community Questions from those candidates who provided them. Certes (talk) 12:12, 20 August 2021 (UTC)

Results are now available here. Certes (talk) 18:14, 9 September 2021 (UTC)

Community questions

Hello fellow editors,

I would like to draw your attention to the complete list of 61 questions which were asked by the Community here. The Election Committee of the WMF selected eleven of these questions which were mandatorily needed to be answered by the candidates in the link given above by Colin M. Some candidates answered the complete list of 61 questions and you can read their views in their questions, however please note there was severe time pressure on the candidates in this election and all candidates were genuinely not able to answer all the questions due to commitments in real life.

Please do go through candidate statements and their answers to the mandatory 11 questions and complete set of community questions before voting. Vote wisely, and Happy Editting. :) AshLin (talk) 06:56, 20 August 2021 (UTC)

Disclaimer: I am a candidate for the Board of Trustees Election and this post is only for information of editors on my home wiki. AshLin (talk) 06:56, 20 August 2021 (UTC)

Hours of analysis yielded these candidate options

Hi everyone. I read and analyzed carefully for hours the candidates' statements, background, goals, positions. My main priorities in a candidate are support for transparency, democracy and decentralization of the board, digital and free education rights, inclusiveness of the Wikimedia projects' community at large in decision making. As a result of my analysis, the top 5 candidates I recommend are

1. Farah Jack Mustaklem
2. Lorenzo Losa
3. Lionel Scheepmans
4. Vinicius Siqueira
5. Adam Wight

— Preceding unsigned comment added by Thinker78 (talk • contribs) 00:29, 26 August 2021 (UTC)

After rating the candidates' statements, Q&A answers, user pages, and other stuff on seventy-eight variously-weighted metrics (for a total of around 2400 individual ratings), with my top priorities aligning with a majority of those named above, I can say my top five candidates are mostly the same up to ordering as the above, but with AshLin and Discott rather than Mr Mustaklem and Dr Siqueira. —2d37 (talk) 13:45, 31 August 2021 (UTC)

2d37 That's very interesting! I guess we did a rather objective job and it proves by reaching about the same conclusions without ever communicating with each other. Question: I didn't find AshLin nor Discott, did you mean Ashwin and Scott? Thinker78 (talk) 15:38, 31 August 2021 (UTC)

I would be less inclined to think it shows objectivity than subjectivities that were slanted in similar directions. AshLin and Discott are indeed Ashwin Baindur and Douglas Ian Scott, according to the candidate pages. I suppose it was confusing of me to use their usernames while also using the offline names that you had already. —2d37 (talk) 19:33, 31 August 2021 (UTC)

<sigh> And only Lorenzo Losa was elected from among those five. Perhaps darker days ahead for the WMF. As if it's not bad enough. :/ --Hammersoft (talk) 19:28, 9 September 2021 (UTC)

I gave a big sigh too. At least we have elected one member who believes that The community is not just a bunch of people providing free work. I'm concerned that, for many of us, this may have been Wikipedia's last chance to return to a model we can continue to support. Certes (talk) 19:55, 9 September 2021 (UTC)

Sigh. Did anyone really give any weight to some random candidate preference list like the one presented in the original post here? MarioGom (talk) 22:45, 10 September 2021 (UTC)

Announcement regarding IP editing

Cross-posting from this month's Tech News:

• Last year, the Portuguese Wikipedia community embarked on an experiment to make log-in compulsory for editing.  The impact report of this trial is ready. Moving forward, the Anti-Harassment Tools team is looking for projects that are willing to experiment with restricting IP editing on their wiki for a short-term experiment. Learn more.

Should we sign up? – SD0001 (talk) 16:10, 6 September 2021 (UTC)

I'm torn here. The editor/admin in me says, "Yes, please, now, if not sooner". The software engineer in me says, "This is a big change; we should roll out big changes slowly and carefully". List of Wikipedias says enwiki has 10^5 active users while ptwiki has 10^3. Making the next scale-up a factor of 100x seems aggressive. I have no idea how these other projects feel, but if one of {ru, ja, es, de, fr} went next, that would seem more prudent, as a 10x scale-up. -- RoySmith (talk) 16:46, 6 September 2021 (UTC)

I agree with Roy. Running an experiment in mid-sized projects first sounds more sensible. That being said, once we know the structure of the experiment, we should discuss doing it on enwiki at some point. MarioGom (talk) 16:52, 6 September 2021 (UTC)

I also reluctantly agree. We should try definitely try it on en.wiki in the future, but seems sensible to try it on some other smaller wikis first. Joseph2302 (talk) 17:16, 6 September 2021 (UTC)

I'd say No. Preventing anonymous edits, even temporarily, is far too important a change to be done experimentally. It would be one of the biggest decisions the community has ever taken, and would certainly require consensus at a major RfC advertised with banners, etc. Certes (talk) 17:29, 6 September 2021 (UTC)

Well, at least WMF is seriously talking about this - this is a very significant step. But I agree that we are probably not a good test case, if "temporary" is all that is being offered right now. --Rschen7754 18:04, 6 September 2021 (UTC)

• My opinion is that this is long overdue. Obviously the advantage of IP editing is its role in getting new editors in, in that people see without any hassle how easy it is to edit the encyclopedia. That's how I got roped in, certainly. But the project is very mature now, and it's much more accepted on the web generally that you have to sign up for things in order to contribute. People are used to that. And there are major problems with the IP model, including: (1) it's slightly deceptive, because as a new editor (and again, this happened to me) you imagines that you're editing Wikipedia anonymously when logged out; or at the very least that only high-powered users can see your details. But in fact, your IP address gets logged publicly and irrevocably against that edit. And yes, there is a warning box, but it could easily be missed. (2) I'm no legal expert, and no doubt the WMF have done their due diligence, but the concept of attributing a piece of text to an IP address from a copyleft point of view seems distinctly odd. IP addresses are shared and transient, and in most cases it would be near impossible to use it to identify the individual making the edits; and (3) along the same lines, IP editors are basically legal sockmasters; they can edit from any and all IP addresses in the world, and nobody is any the wiser. I apologise to any long-term IP editors who may take this as an affront to their way of life, but I think all things being equal it will be better for them to just sign up and contribute that way. All IMHO anyway. Interested to see which way this goes.  — Amakuru (talk) 19:37, 6 September 2021 (UTC)

  Privacy isn't an issue because masked IPs are coming. Preventing IP edits might spare WMF the considerable work of implementing masked IPs, and spare us from whatever drawbacks their chosen design might have, but privacy is happening anyway. Certes (talk) 00:18, 7 September 2021 (UTC)

  @Certes: I agree, and to add to this, I really haven't seen much evidence from the WMF that masked IPs will be implemented in a way that won't significantly impact anti-vandalism efforts. Given that, I think that as long as there's first a major RfC confirming there's consensus for it, disabling anonymous editing is the best way forward here, since the WMF has stated repeatedly that IP masking is a non-optional mandate from Legal and thus keeping the status quo is simply not an option. Nathan2055^{talk - contribs} 21:51, 11 September 2021 (UTC)

• I'm a strong supporter of allowing IP editing, but sticking our head in the sand is not an option. The arguments from vandalism-prevention and privacy-promotion will eventually win the day if there is no data showing benefits to IP editing. I support a short, fixed-time experiment where IP editing is disabled world-wide. Certainly no more than a week; even 31 hours may be enough to get sufficient data. User:力 (power~enwiki, π, ν) 19:40, 6 September 2021 (UTC)

  力, During that time, what will you measure and how are you going to do that? Vexations (talk) 19:44, 6 September 2021 (UTC)

  Presumably the WMF will write that up in detail before the (absolutely necessary) high-profile RFC. At a high level I would want to see data regarding: change in edits reverted as vandalism, change in account signups, change in good edits from non-ECP users, change in complaints on Twitter, and change in edit rate on certain pages that generally see high IP activity (I don't have specific pages in mind but my first guess is current sports events). User:力 (power~enwiki, π, ν) 19:52, 6 September 2021 (UTC)

  

  

  There is a writeup of the pt trial on meta. It's not always easy to determine what constitutes "success", but these two graphs are rather convincing: reverts dropped by about 50% and protected pages dropped by about 80%. -- RoySmith (talk) 23:31, 6 September 2021 (UTC)

  The report on the ptwiki trial cites m:Research:Value of IP Editing as a counterpoint. Both are interesting reading. – Joe (talk) 06:35, 7 September 2021 (UTC)

• I agree with Roy above that enwiki should not be a test; I do, however, support forcing account creation, especially to stop masked IP editing. ― Qwerfjkltalk 19:44, 6 September 2021 (UTC)
• If there is to be an experiment then the success criteria should be decided in advance. All too often I have seen experiments on Wikipedia being adjudged to be successful because of the sunken costs fallacy. Phil Bridger (talk) 20:13, 6 September 2021 (UTC)
• Once again, the WMF appears to assume that the communities require their permission to a) ban IP editing, b) run a trial. This harks back to WP:ACTRIAL which they blocked for SIX years under a fake premise. ACTRIAL had been carefully prepared and approved by the en.Wiki community by overwhelming consensus at series of major RfC. The success of these debates was due to careful planning and wordsmithing of neutral RfC statements prepared by a small taskforce, backed up by available stats. When it was realised that the trial could be done ourselves anyway by applying a simple local filter, and threatened to go ahead, the WMF relented and even agreed to provide further stats for the experiment, proving yet again that the English Wikipedia has far more qualified people among its ranks than the WMF and is big enough and ugly enough to make its own decisions. The rest is history. Kudpung กุดผึ้ง (talk) 22:45, 6 September 2021 (UTC)
• Some of the high-handed language in the WMF report is unfortunate (they will allow Portuguese Wikipedia to continue disallowing IP editing apparently), but on the whole I think it's great they are now willing to support trials of radical changes like this. We won't be able to decide whether enwiki is better or worse with anonymous editing by chewing over the same old talking points; we need hard data. – Joe (talk) 06:42, 7 September 2021 (UTC)

Like I said, because you obviously missed it Joe Roe, the WMF is too big for its boots. They do not give the communities 'permission ' to do anything. The communities are the bosses, not the WMF, and the communities should assert themselves. Kudpung กุดผึ้ง (talk) 09:45, 7 September 2021 (UTC)

• I'm sorry but the graphs posted here are just dumb, and an example of confirmation bias at best. What we need in contrast to this are graphs that show the percentage of good edits by IPs and editors before and after the trial, absolute numbers corresponding to the same and then compare them with the revert/page protection figures. What we need to know is where it hurts, not the obvious implications that reverts and page protects dropped (since IP-related edits construe the most of both of these actions). To clarify, I'm not implying fault on the poster but presenting these graphs without context as to what the relevant information is would mislead the general community. --qedk (t 愛 c) 15:25, 7 September 2021 (UTC)

  Aye, counting page protections and reverts is easy but without a comparison to good edits by IPs it's nothing more than cherry-picking. Jo-Jo Eumerus (talk) 16:33, 7 September 2021 (UTC)

  100% agree with qedk here —TheDJ (talk • contribs) 21:49, 7 September 2021 (UTC)

  (Partial response in my comment below.) Sunrise (talk) 22:51, 8 September 2021 (UTC)

• Any further discussions about IP editing must also take into account that WMF planned to mask IP editing. I have done a mini-research last month about IP editing, and in my opinion, we still need IP editing.
  
  And even if we decided to disallow IP editing, what kind of registration do we like? Do we want confirmation of email address? Or we just allow sign up without email address? How about temporary email? Do we allow usage of them? How hard/simple the registration will be? The discussion about IP editing is a long-winded one, and we shouldn't concern only about the edits themselves, but also the registration, if we choose to mandate it.

SunDawntalk 18:05, 8 September 2021 (UTC)

• My question would be the desired benefit from this. I'm going to guess it's related to vandals and sockpuppetry. I got sucked into watching for socks in India/Pakistan film and television related articles a few years ago where there are several highly active socks who frankly don't care one way or the other. They create accounts when needed, use IP's when they feel like it. This change would make them create more accounts, which means SPI will get even more reports and more of a backlog. Unless this change would also require an email address and the account confirmed from that email address, I don't see how this will do much to stop or significantly slow down the more dedicated socks and vandals. Drive-by vandalism would slow a lot, but anything else I question. Ravensfire (talk) 18:09, 8 September 2021 (UTC)

  It is true that socks create accounts willy-nilly. But, at least that gives us some clues about which edits were done by the same person, and a useful target to block. I don't get the logic behind This change would make them create more accounts, which means SPI will get even more reports and more of a backlog. That's like saying stores shouldn't install security cameras because it would catch more shoplifters and make more work for the courts. -- RoySmith (talk) 18:58, 8 September 2021 (UTC)

  My thought there (and from dealing with another Bttowadch range) is that I generally don't bring IP's to SPI without a named account also existing. If I do, it's either a very static IP or a range that recent activity (3-4 months minimum) is substantially all from the sock. With IP masking, my ability as a normal editor to identify those ranges is gone. If you now eliminate the IP editing, that means a lot of sock accounts created. There are times that an SPI report sits for 7+ days because there isn't enough of you all already (please don't take that as anything bad about the folks working SPI, ya'll frankly rock on a task that can be disheartening at times). I worry that's going to get worse. Ravensfire (talk) 13:56, 9 September 2021 (UTC)

• I agree that enwiki should eventually sign on, but as RoySmith says we should not be the next in line to "try it out". Work out the kinks on projects that aren't the largest in the portfolio first. As for protecting "anonymous editing" that's becoming more and more of a red herring: the only way to edit truly anonymously is by creating an account. If you have an account we will bend over backwards to safeguard your connection info from becoming public, but if you don't create an account and edit "anonymously" we will paste your IP address right next to each and every edit you make. Ivanvector's squirrel (^trees/_nuts) 18:48, 8 September 2021 (UTC)
• Remember that we are the free encyclopaedia that anyone can edit - not the encyclopaedia that only registered editors can edit. Bear in mind that registering an account takes time (you have to stop editing the page, go to the registration form, complete and submit it, and then go back to the page) - that will for sure stop casual vandals, but it also stops good-faith editors who just want to fix something. There's definite confirmation bias going on here. Sure, making editor IP addresses public is problematic - but that's already being fixed separately within MediaWiki, so it's a separate problem from whether IPs should be allowed to edit. Thanks. Mike Peel (talk) 19:08, 8 September 2021 (UTC)

  So the developers streamline the registration process so it can be completed without navigating away from the page. Plenty of web sites with much smaller budgets than the WMF have figured that one out. - MrOllie (talk) 19:11, 8 September 2021 (UTC)

  What will a potential recruit do when their attempt to publish their first edit pops up a registration form? My reaction would probably have been to abandon any attempt to contribute, mumbling "fix your own bloody encyclopaedia then". Certes (talk) 19:21, 8 September 2021 (UTC)

  Simplifying the registration form per the suggestion by @MrOllie: makes sense ('Do you want to continue editing and expose your IP address, or quickly register a pseudonym') - but the response by @Certes: about then abandoning the edit given the complication also makes sense. It's a trade-off, but in general I think we should err on the side of enabling more editors. Thanks. Mike Peel (talk) 19:35, 8 September 2021 (UTC)

  'Do you want to continue editing and expose your IP address, or quickly register a pseudonym?' seems a very reasonable question (until IPs get masked). However, 'Do you want to register or go away?', even if more delicately phrased, sounds less encouraging. Certes (talk) 23:46, 8 September 2021 (UTC)

  First and foremost (i.e. WP:5P1), we are an encyclopedia. Anything which detracts from achieving that must be subordinated to the primary goal. And there's nothing in "anyone can edit" which implies "anyone can edit without registering". We have lots of requirements. We require that everybody use https. We require that editors not share their passwords. We require that editors not use their user page to sell illegal drugs. And a bunch of other things. All of these in some way place restrictions on "everyone may edit". Requiring that you register wouldn't be any different. -- RoySmith (talk) 00:13, 9 September 2021 (UTC)

• Just saying, if we're all in a running trials kind of mood, we could... actually try IP masking and see if the parade of horribles actually turns up, before we try pulling up the drawbridge entirely. Opabinia regalis (talk) 19:32, 8 September 2021 (UTC)

  @Opabinia regalis: The problem with that is that implementing IP masking, even on a trial basis, would still require a series amount of development work from the WMF, which could be instead put toward fixing more critical issues like WP:THEYCANTHEARYOU, while disabling IP editing completely is a single configuration switch on the backend. I also have pretty significant concerns about the WMF testing code and/or plugins on production wikis, since they don't exactly have a great track record with their previous testing programs. Notably, Flow, a talk page plugin that has been all but abandoned by the WMF in favor of the newer talk page initiative, is still installed on Commons despite an RfC to remove it following the conclusion of its trial, since the WMF was unwilling to have old Flow-based talk pages linked in logs go to 404 messages, and was also unwilling to spend any developer time making a clean uninstall script or some other workaround to fix that issue; IIRC there's even still an open Fabricator ticket to fix it that of course hasn't been touched in like five years.

  The point is; if there's a simple solution that doesn't have that many drawbacks, is shown to be supported by the majority of editors, and only requires a single setting change and no custom code from the WMF, and on top of all of that is likely to seriously reduce the load on the anti-vandalism teams, it seems like that's the option we should be working towards as opposed to the "half-measure" of implementing masked IPs that is, at least as of now, believed to come with a serious set of drawbacks and new problems that we'll need to work around. Nathan2055^{talk - contribs} 22:09, 11 September 2021 (UTC)

  @Nathan2055: As far as I understand, the WMF is going to put in that work to implement IP masking either way, so we might as well try it for a bit once it's finished. If it's fine, great. If it isn't, we can still flip that single configuration switch. – Rummskartoffel 11:44, 13 September 2021 (UTC)

• I agree with one of the comments above that a decrease in reverts and page protects is merely an expected result, although they’re still useful as a measure of the change in moderation workload. We also already have a measurement for "good" edits (the number or fraction of non-reverted edits), which is probably one of the better approximations we are likely to get. The relevant question is the comparison between the two.

One way to frame this to ask about how much we care about the total number of good edits, compared to the average quality of edits, and (since it is virtually guaranteed that these will point in different directions) to what degree we are willing to sacrifice one in favor of the other. This is probably where setting a threshold of action ahead of time would be the most valuable. If I were doing the analysis, I think I would create a summary measurement "reverts per good edit" - i.e. a value of 10 would mean we have 10 reverted edits for every good edit, and a value of 0.1 would mean we have 1 reverted edit for every 10 good edits – which would be a direct measurement of the cost-benefit ratio (at least for these specific costs and benefits). The information for this should already be in the data, so it could to be calculated for the existing dataset as well.

Another relevant point is that any comparison between IPs and registered users based on number of edits assumes that those edits have the same average quality, which may or may not be the case. One option would be to weight by the absolute number of characters added or removed (in other words, the measurement of "quality" would be the amount of content changed by the edit), which would be an imperfect measurement although I don’t have any better alternative coming to mind right now. Sunrise (talk) 22:51, 8 September 2021 (UTC)

I agree that the drop in reverts and page protects, by themselves, are not enough to prove this is what we want. As an extreme example, we could reduce reverts and protects to zero by disabling all editing. I put those results into the category of "That's encouraging; this definitely deserves a closer look".

Some of the costs of IP editing are harder to quantify. There's a huge amount of effort by editors and admins that goes into fighting spam, vandalism, and other non-productive editing. I'd certainly rather be writing DYKs and GAs, but SPI keeps dragging me back in.

Not to mention WMF developer time that goes into developing code to manage IPs. Sadly, it appears that IP masking is already a sunk cost (or at least committed to be), but consider what other improvements could be made if the effort that's going into to could be put to improving the system in other ways. What's your favorite feature request that's not getting done because there's nobody to work on it? -- RoySmith (talk) 13:31, 9 September 2021 (UTC)

My favourite request is WP:THEYCANTHEARYOU. IP editors might behave better if we could ask them to. Certes (talk) 15:49, 9 September 2021 (UTC)

We are now to a point on the internet that if you want to participate anywhere, you create an account to do so. I don't see why this is such a hurdle. RickinBaltimore (talk) 11:27, 9 September 2021 (UTC)

Just because it is how it is =/= how it should be. The ideal internet is where there is no identity or trust involved, the primary reason why registration has been required is because of a) data collection, primarily, b) lock-in, secondarily and in a very side effect kind of way, c) control malicious actors. Think of how many fake accounts a social media platform typically has, there is nothing stopping bad actors from running rampant after creating accounts, in fact, the things that prevent those are hardblocks, autoblocks and account creation blocks, all of which rely on the fact that we know their IP addresses. --qedk (t 愛 c) 14:10, 12 September 2021 (UTC)

Sure, but one of the fundamental features of Wikipedia is that it has full attribution on its edits. As such, identity is a key facet of editing and it simply isn't good enough to rely on a transient IP for that, any more than it is good enough to allow open proxies to edit. Trust is also a factor, because bad actors do exist, and nobody's proposing the hiding of IP addresses from the software and advanced users, only that you won't be able to perform an edit under that handle.  — Amakuru (talk) 14:36, 12 September 2021 (UTC)

QEDK, concepts of "trust" and "identity" are essential parts of what makes Wikipedia work. (I don't know how or why Wikipedia works, but I know that much. I also know that I'm not disagreeing with you ... you're making a technical point I think, and I'm making a point about our cultural values.) - Dank (push to talk) 14:56, 12 September 2021 (UTC)

I doubt the purpose of registration is for data collection or lock-in, one would think it's clearly for the sake of better attribution. Also, hardblocks and account creation blocks can both work with IP editing disabled. – SD0001 (talk) 06:59, 13 September 2021 (UTC)

To clarify, I was referring to registration in general, on the internet, as RB had mentioned. --qedk (t 愛 c) 09:46, 13 September 2021 (UTC)

• I have long defended IP editing, partly because it is probably how I started, and partly becaues Pre Covid I would make IP edits while on unsafe WiFi such as in airports. However I have read meta:IP Editing: Privacy Enhancement and Abuse Mitigation/Impact report for Login Required Experiment on Portuguese Wikipedia and been converted. We should trial this on EN wikipedia and see if we get the same benefits including fewer admin actions needed. If we can't persuade more people to run for RFA we need to reduce the admin workload, and stopping IP editing seems to do that. I agree that with spam and similar problems now would also be a time to require email for account creation, but not for people who's IP's geolocate to countries whose governments have tried to restrict Wikipedia. ϢereSpielChequers 12:42, 13 September 2021 (UTC)
  • @WereSpielChequers: I seriously respect your opinion, given your long-term involvement with the Wikimedia projects, and also your endorsement of IP editing and simplified RFA procedures that I've seen for a long time now (and I was thoroughly convinced that you were thinking in the right way when I heard you talk about both these issues at past wikimeets). So your statement here seriously makes me stop and rethink this issue. In part, it seems like an 'if we can't do A, then let's stop B' kind of position - wouldn't it be better if we could get people through RfA more easily, rather than blocking IP editing? But you've worked on simplifying RfA for so long, perhaps if even you are giving way here, perhaps we should consider the alternative? But then, what do we gain here - half the reverts, and half the blocking workload - but no clear statistics for the number of positive edits? Maybe 'non-reverted' is a good metric, but the fluctuations are an order of magnitude more than the 'reverted' stastics? What impact does this have on the ethics of the community, rather than its workload? Thanks for thinking about this. Mike Peel (talk) 21:53, 13 September 2021 (UTC)
    • Thanks Mike, yes there is an element of pragmatism, fixing RFA is very hard, and reducing the admin workload may be a better approach. But there is also the issue of being willing to change your mind if the facts change. I did not expect the Portuguese language IP ban to have as good a set of results as it has done, and while I would like to see longer term results, short term has been good. As for ethics, we have an obligation to protect those members of the community who get targeted for harassment, and an IP ban is one way to do that. The other ethical issue is that we have huge skews as to where in the world we have editors. An IP ban that switched off IP editing in the parts of the world where we already have significant numbers of editors, but allowed IP editing in countries where we most need new editors would be an interesting exercise to preferentially recruit where we most lack editors. ϢereSpielChequers 10:33, 16 September 2021 (UTC)
      • This is an interesting idea but I can imagine it backfiring and making IP editors even more maligned than they already are. This isn't always the case, but I tend to associate IP editors from these countries with spam and seemingly good-faith but very misguided efforts to improve Wikipedia. I don't think IP editing is a good recruitment tool because of the communication problems involved. There's also the problem that IP's outside of North America/Europe tend to be very dynamic in my experience (more so than those in countries with high editing rates), making it harder to track miscreants down and effectively deal with them. Graham87 13:15, 17 September 2021 (UTC)

        It also raises a couple of other questions. Firstly, is it fair to introduce positive discrimination by this back door rather than on its own merits after proper discussion? Secondly, how will mobile IP editors react, especially those using the app, given the difficulty of notifying them what's happening? Certes (talk) 13:30, 17 September 2021 (UTC)

        • To answer Graham87's point, by leaving IP editing as a possibility in parts of the world which we underrepresent, we aren't likely to increase our problems in those areas, rather reduce the amount of dodgy editing by IPs in UK, and US anda few other countries. To answer Certes point, perhaps it is positive discrimination, is that a problem? Happy to discuss that if others think the idea might fly. However I have a suspicion that the trolling and really nasty stuff is predominately from privileged kids in parental basements, if it turns out that the worst we get from Nigeria and India is spam then maybe we should not think of this as positive discrimination, and instead think of it as an extension of range blocking. Country wide range blocking in countries where IPs harass editors. ϢereSpielChequers 18:47, 24 September 2021 (UTC)

  • I commented five years ago now about planning for a post-admin era on Wikipedia. Bit by bit, that reality is coming true. Whatever reforms have been attempted on RfA, WSC's very helpful (if depressing) table at WP:RBM shows they've not been able to increase the numbers of successful RfAs over the last ten years. In fact, it's the opposite. If the current trend continues for another ten years, the number of successful RfAs in a given year may drop to zero. This is part of the product lifecycle. Either we plan for it, or we're doomed. One way to help soften the blow is to reduce current admin workload. There are a variety of ways to do this. To name a few; reduce the amount of continued vandalism by IPs and bad faith accounts is one. Imagine a world where ClueBot can block, and not just based on edits but also on filter logs. That needs to happen in some form. Another method is to analyze processes admins have to follow to conduct admin functions and streamline those processes that are the biggest time sinks. Another is automatic page protections for articles where there is a high rate of vandalism or reversions as determined by ClueBot. I could go on for a while here. What has to happen, whether we like it or not, is for the project to become increasingly protectionist of its existing content. Honestly, this more abstract discussion likely needs to be done elsewhere. --Hammersoft (talk) 14:21, 17 September 2021 (UTC)

    The bar for RfA has risen steadily, predictably increasing quality but decreasing quantity. I can't deny that having too few good admins is better than having too many bad ones. I wonder if there are more ways to delegate carefully selected admin-type work to experienced editors who wouldn't pass RfA because they are competent in some but not all areas. Certes (talk) 23:23, 18 September 2021 (UTC)

    We already have non-admins doing lots of admin-type work. WP:NAC for example. At WP:SPI, we've got non-admin clerks who do outstanding work. WP:RESPONDER-RFC describes another idea, which doesn't seem to be going anywhere. -- RoySmith (talk) 23:56, 18 September 2021 (UTC)

• Based on a comment in T289795, it looks like farsi wikipedia is going no-ip. -- RoySmith (talk) 20:56, 22 September 2021 (UTC)

  The main task for the Farsi Wikipedia request is at T291018, with a fair amount of discussion. the wub "?!" 22:00, 23 September 2021 (UTC)

• I think I may be a little unique in that I first registered an account because for some reason (very likely my computer illiteracy) I was unable to edit unregistered. I don't think asking people to spend 15 seconds registering completely anonymously is going to see droves of potential editors be turned away. I await further analysis of other wiki's trials, but I think this is something we here should trial soon. Cavalryman (talk) 01:08, 23 September 2021 (UTC).
• Can we throttle, but not block? If WereSpielChequers' comment above is correct that it's mostly an admin resources issue, then some sort of throttling of IP contributions would reduce admin resources required, while still allowing IP editing in some form. Time-based throttling might restrict when (think alternate side parking rules) and ID-based throttling might restrict who (even IPs on M,W,F, odds on Tu-Th-Sa). Measurements taken after some elapsed interval would allow fine-tuning of the throttling needed to achieve a desired end. Mathglot (talk) 18:28, 24 September 2021 (UTC)

m:Office actions/September 2021 statement

See also:

• m:Talk:Access to nonpublic personal data policy#Policy adjustment on behalf of Legal.
• zh:WP:OA2021

I'm quite surprised this hasn't been posted yet. It looks like we have a problem with the CCP. I have three big questions:

1. Why did it take the CCP so long?
2. Why are they not here as well?
3. If the CCP is on the English Wikipedia, why can't we detect them?

I already know the answer to the third, it's more rhetorical. MER-C 18:54, 16 September 2021 (UTC)

What is CCP?--Ymblanter (talk) 18:56, 16 September 2021 (UTC)

Chinese Communist Party. MER-C 18:58, 16 September 2021 (UTC)

They are probably here as well but not yet in numbers that can influence any processes. However, we have seen that a single person (possibly not affiliate with a state) managed to grow such a big sockfarm that he was able to influence recent ArbCom elections in the Russian Wikipedia. So I am sure we will feel CCP here as well, though this is probably not their main priority for the moment as Wikipedia is only available in China via VPN.--Ymblanter (talk) 19:02, 16 September 2021 (UTC)

This is something I don't understand - they're the biggest source of disinformation and malign foreign influence in the West and their apparent presence is smaller than most of WP:PAIDLIST. The same questions can be asked about Putin as well. MER-C 19:13, 16 September 2021 (UTC)

Putin is most certainly present, I have encountered users clearly paid by Russia to spread disinformation.--Ymblanter (talk) 19:15, 16 September 2021 (UTC)

It would be naive to believe that China and Russia are the only governments engaging in this kind of activity. -- RoySmith (talk) 20:44, 16 September 2021 (UTC)

The announcement has a lot of PR speak and is hard to understand. What's the summary? WP:OFFICE de-sysop'd 4 Chinese Wikipedia bureaucrats, and also some admins and interface admins, and banned some people, because they are suspected of working for the Chinese Government? And also removed all Chinese Wikipedia checkusers? Is it known what abuses these guys got away with? I see that zhwiki is in traditional Chinese... does this mean that its main users are Taiwanese folks? Does mainland China even have a Wiki, and has it been able to escape censorship? –Novem Linguae (talk) 23:10, 16 September 2021 (UTC)

Chinese Wikipedia lost its CheckUsers in an unrelated incident in 2018. Also, zhwiki uses LanguageConverter to convert between traditional and simplified Chinese on the fly, so it's not specific to Taiwan. * Pppery * _{it has begun...} 23:29, 16 September 2021 (UTC)

Some of these people posted at external fora threatening to find out the personal data of Hong Kong editors who opposed the CCP mainstream ideology and give the data to the Chinese government, if I understand the things correctly. This is also in the cited Signpost articles.--Ymblanter (talk) 05:45, 17 September 2021 (UTC)

Mostly correct but more.

Recent years' sysop elections have traces of large scale voting manipulations. Refer to the third RfA of 和平奮鬥救地球 (Peacearth) early this year, which failed due to large amount of oppose votes from WMC, including many of the aforementioned office action'd users.

Also earlier this year, a sysop (now global banned) 蟲蟲飛 was accused of socking by multiple stewards. This finally lead to a Request for Desysop vote, which also failed (with over 80% of users chose to support her). Some people suspect that her ban is linked to this. By the way, she got away with that by pledging that she was "using a common iPad" and was "framed" and also (possibly) appealing to the stewards' nationality.

Walter Grassroot is known to frequently use discrimating words towards Hong Kong and Taiwan people in discussions. He is also responsible for mass-uploading Chinese state media news video clips to Commons, then mass-inserting them in articles, violating WP:UNDUE. Literally nobody could stop him, because whenever a sysop blocks him, another certain sysop (now desysoped in action) would certainly come and unblock him.

尤里的1994 identifies him as a Nazi. He puts Nazi flags on his user page. He also advocates that China should use nuclear weapons to initate "destructive military actions" towards Taiwan - All written on his user page. His user page was sent to Request for Deletion for promoting Nazism and violating WP:NOT, but the request eventually failed, for "anything written on user page is his freedom of speech".

The community in Chinese Wikipedia is gradually going out of control, and I doubt whether this office action could help it become normal. To my knowledge, this incident is reported in mainland China with tons of people criticizing WMF. I am not sure whether they will seek revenge. I could sense things are going insane. Milky·Defer >Please ping me while replying to me... 08:30, 17 September 2021 (UTC)

@MilkyDefer I assume WMC above means m:Wikimedians of Mainland China? -- RoySmith (talk) 13:09, 17 September 2021 (UTC)

@RoySmith: Exactly. In zhwiki, "WMC" or seldomly, "WMCUG", refers to Wikimedians of Mainland China. Sorry for my mistake. No offence to Wikimedia Canada. Milky·Defer >Please ping me while replying to me... 14:38, 17 September 2021 (UTC)

The "this user is a Nazist" (and a "national Bolshevism"), support for fascism and the nuclear bombing of Taiwan present on the user page of 尤里的1994 pre-blanking is mind boggling.--Eostrix  (^{🦉 hoot} _hoot🦉) 08:25, 18 September 2021 (UTC)

Equally disturbing is that he denounces (one of the primary culture-heros of China), while supporting Legalism, the totalitarian philosophy that underlay the oppressive Qin dynasty. (In other words, he clearly understands what Naziism is all about.) I know we want a diversity of viewpoints on Wikipedia, but IMHO allowing his is one group more than I am comfortable with. -- llywrch (talk) 19:22, 18 September 2021 (UTC)

• To MER-C original questions: While WMCUG action here seems to be pro-PRC, I don't think there's enough information to state that this is a direct Communist Party of China (CPC) operation? That being said, there seems to be both pro-PRC and anti-PRC operations on English Wikipedia. The exact actors behind each of them is not necessarily clear in all cases. For example, their focus area can also be consistent with private businesses in China, and their competitors. This is not a problem exclusive to China by the way. Political UPE/influence ops on English Wikipedia can also be found for pro-US, pro-Qatar, pro-UAE sockfarms, just to name a few. Unfortunately, I think we have a quite limited understanding of this type of activity. MarioGom (talk) 10:05, 18 September 2021 (UTC)

The WMF seems to be quite clear in not attributing blame on the CPC or the Chinese Government. (Note that followers of the QAnon conspiracy theory were mostly not in the pay of, or under the direction of the Trump administration, even if many of their acts may have been pro-Trump) While the WMCUG seems to be pro- the current policies of the Bejing government, as ordinary editors we have no way of knowing whether this group has state backing, so we as individuals can only judge the edits on there own - if edits are reverted it should be because the edits are disruptive or against policy, not because we think the editors are part of some conspiracy.Nigel Ish (talk) 21:02, 18 September 2021 (UTC)

Right. I agree with that characterization. I also agree with the Office Actions. My comment was about the framing in this particular thread. There are state-linked UPE operations on Wikipedia (which, by the way, I wouldn't call conspiracies). But that does not seem to be the case here. MarioGom (talk) 22:55, 18 September 2021 (UTC)

• Some points:
  • Quotes: "some users have been physically harmed" (from the original statement), "all individuals who were banned were banned for the kinds of behavior that communities (including English) widely regard as within the Foundation’s remit" (from the mini faq, in response to my question about whether the bans were for '"conventional" reasons (eg, threats of violence or other serious actions of types that the community has accepted as belonging to T&S)').
  • The desysoppings seem to be because of issues with the votes (Manipulation? Socks? Threatening or blackmailing users to vote a particular way? The original statement mentions the need "to make sure that the community can hold fair elections, without canvassing or fraud", but the details are unclear.), and the WMF has said that the local community can hold new votes to re-sysop them.
• The bans seem clearly reasonable. The desysoppings I'm more skeptical of; it seems to me that it should have been dealt with either locally, or with the assistance of either the stewards or global community, unless there were, here too, serious threats involved (such that all would agree it was beyond the abilities of volunteers to deal with). But information is limited, so it's hard to tell. --Yair rand (talk) 06:26, 20 September 2021 (UTC)

Miscellaneous

Movement Charter Drafting Committee - Community Elections to take place October 11 - 24

Hello all; I'm including the short version of this full announcement below. Please let me know if you have any questions. Xeno (WMF) (talk) 02:47, 21 September 2021 (UTC)

---

This is a short message with an update from the Movement Charter process. The call for candidates for the Drafting Committee closed September 14, and we got a diverse range of candidates. The committee will consist of 15 members, and those will be (s)elected via a 3-step process:

• Election process for project communities to elect 7 members of the committee.
• Selection process for affiliates to select 6 members of the committee.
• Wikimedia Foundation process to appoint 2 members of the committee.

The community elections will take place between October 11 and October 24. The other process will take place in parallel, so that all processes will be concluded by November 1.

For the full context of the Movement Charter, its role, as well the process for its creation, please have a look at Meta. You can also contact us at any time on Telegram or via email (wikimedia2030wikimedia.org). — Preceding unsigned comment added by Xeno (WMF) (talk • contribs) 02:47, 21 September 2021 (UTC)

• I would also like to invite editors to submit m:Movement Charter/Drafting Committee/Election Compass Statements to help in the design of toolforge:mcdc-election-compass, a voting advice application. Xeno (WMF) (talk) 02:23, 23 September 2021 (UTC)

Thanks to everyone who provided statements. Users may endorse those statements they feel are important at m:Special:MyLanguage/Movement Charter/Drafting Committee/Election Compass Statements until October 3rd.

Feel free to let me know if you have questions about this process. Xeno (WMF) (talk) 15:34, 29 September 2021 (UTC)

Low-traffic fundraising campaign banner test - October 2021

Dear all,

This is just to briefly inform you that we will be running a low-traffic test during the first week of October.

What does this mean? This means that banners will be visible to some non-logged-in users throughout the whole 7 days. We will only be running them at a traffic level of 7%, which means readers have a small chance of seeing a banner on each pageview, and no readers will see continuous banners.

We're exploring this type of test format, as it allows us to take a better sample of the readership population. If you have any questions or comments please go to the Fundraising talk page JBrungs (WMF) (talk) 06:38, 29 September 2021 (UTC)

This seems to be the (huge) banner involved. How the money for the rich WMF helps to maintain Wikipedia's independence is not really clear, and why you need to insult the readers who don't give is equally unclear ("they simply look the other way"? Or they are your proverbial "poor child" who you wanted to give the sum of all knowledge, your actual target group, or perhaps they don't donate a few dollars, but countless hours of their time improving Wikipedia and help pay for the WMF employees and the third-party commercial spammers that get paid by the WMF (more than $400,000 for Trilogy Interactive LLC?), i.e. by us. It is debatable whether you even need the money, but at least do it in a less obtrusive and less offensive way. Fram (talk) 07:34, 29 September 2021 (UTC)

Dalelkhan_Sugirbayev#Descendants

Nusipkhan Konbay is a male. How can Dalelkhan Sugirbayev's son marry to Nusipkhan Konbay?--Kaiyr (talk) 09:00, 1 October 2021 (UTC)

Standardization of article titles involving Azerbaijani proper names

The Azerbaijani language has switched from Cyrillic to Latin script in 1992, and the new Latin-based Azerbaijani alphabet is being used locally. However, mainly because of accustomedness from the Cyrillic era, in English usage Azerbaijani personal or geographic proper names are routinely Anglicized, either directly from Azerbaijani or through the transliteration of the Russian spelling of the Azerbaijani noun, which often leads to those names becoming much more common in English-language sources. As a result, often an article about an Azerbaijani person/place which was started with the local spelling is moved to the Anglicized form once it becomes more known in English-speaking world.

Currently both forms can be seen in Wikipedia. While the Anglicized forms are more common, the local forms for lesser-known people and places aren't an uncommon sight either. I believe either the use of the local spelling or the method of Anglicization should be standardized. There are about five possible ways this could be dealt with as I see it:

1. Don't enforce a standardized spelling policy:
   • The articles Ilham Aliyev, Vagif Mustafazadeh, Kalbajar and Malxələf stay as is.
2. Use the local forms of the names only, including the uncommon Latin letter Ə:
   • This would mean Ilham Aliyev being renamed to İlham Əliyev, Vagif Mustafazadeh to Vaqif Mustafazadə ​and Kalbajar to Kəlbəcər, and Malxələf staying as Malxələf. With thousands of other Anglicized and more recognizable Azerbaijani names also being renamed, this is far from ideal.
3. Use the previous Latin alphabet proposal from 1991, which used the letter Ä for Ə:
   • Under this policy Ilham Aliyev would look like İlham Äliyev, Vagif Mustafazadeh like Vaqif Mustafazadä, Kalbajar like Kälbäcär, and Malxələf like Malxäläf, which are slightly more recognizable but still requiring many renames.
4. Anglicize the names using the following rules: c → j, ç → ch, ə → a, ğ → gh, x → kh, İ/ı → I/i , q → g, ö → o, ş → sh, ü → u:
   • This would result in Ilham Aliyev staying as Ilham Aliyev, Vagif Mustafazadeh being renamed to Vagif Mustafazada, Kalbajar staying as Kalbajar and Malxələf becoming Malkhalaf.
5. Anglicize using the rules above, but Anglicize the suffix -zadə as -zadeh:
   • This would keep Vagif Mustafazadeh as is, while being the same as the previous one otherwise, which might be desirable.

While I like the option four, I don't know how to make this an official policy, and I want it to be discussed first. – anlztrk (talk) 09:30, 1 October 2021 (UTC)

Wikipedia's approach for things like this is typically just "follow what the sources say", so for article titles, we should be determining them by figuring out what's most common in sources. If the issue is contentious, it probably makes sense to have a wider discussion to decide on an approach; maybe host it at one of the MOS talk pages, add an RfC tag, and send invites to relevant wikiprojects. Aside from article titles, we should also be including alternative forms in the lead, and that might be relevant for discussion too. {{u|Sdkb}} ^talk 22:10, 3 October 2021 (UTC)

Let's talk about the Desktop Improvements

Hello!

Have you noticed that some wikis have a different desktop interface? Are you curious about the next steps? Maybe you have questions or ideas regarding the design or technical matters?

Join an online meeting with the team working on the Desktop Improvements! It will take place on October 12th, 16:00 UTC on Zoom. It will last an hour. Click here to join.

Agenda

• Update on the recent developments
• Sticky header - presentation of the demo version
• Questions and answers, discussion

Format

The meeting will not be recorded or streamed. Notes will be taken in a Google Docs file. The presentation part (first two points in the agenda) will be given in English.

We can answer questions asked in English, French, Polish, and Spanish. If you would like to ask questions in advance, add them on the talk page or send them to [email protected].

Olga Vasileva (the team manager) will be hosting this meeting.

Invitation link

• Join online
• Meeting ID: 829 3670 1376
• Dial by your location

We hope to see you! SGrabarczuk (WMF) 15:09, 4 October 2021 (UTC)

WP:ELECTCOM2021 self-nominations are open

Hello, just a reminder that editors are invited to nominate themselves to serve on the 2021 Arbitration Committee Electoral Commission until 23:59 October 8, 2021 (UTC). Thank you, — xaosflux ^Talk 15:16, 4 October 2021 (UTC)

Social media outage

Did yesterday's (5 October 2021) outage of Facebook and other social media have any effect on our traffic? I'm imagining the possibility that people who could not access their usual cyber-haunts might have visited WP instead. Roger (Dodger67) (talk) 08:37, 6 October 2021 (UTC)

Or perhaps it had the opposite effect. People who couldn't access their usual haunts might have temporarily given up on the Internet altogether. Of course the two effects could both have been in play, in which case it would be very difficult to say whether it had any effect without the right questions being asked (and answered truthfully) in a rigorous survey. I think that is unlikely to happen. Phil Bridger (talk) 16:32, 6 October 2021 (UTC)

Looks like it was a pretty ordinary Tuesday in the traffic data. --Yair rand (talk) 18:27, 6 October 2021 (UTC)

Your connection is not private

Don't know if this is where this comment goes. However, accessing Wikipedia with Chrome browser has been a problem since September 30. The following is the reason given: NET::ERR_CERT_DATE_INVALID. Judging from the numerous comments at Google Chrome Help, it's affecting many Chrome users. This is the explanation given when I click on Advanced:

"en.wikipedia.org normally uses encryption to protect your information. When Chrome tried to connect to en.wikipedia.org this time, the website sent back unusual and incorrect credentials. This may happen when an attacker is trying to pretend to be en.wikipedia.org, or a Wi-Fi sign-in screen has interrupted the connection. Your information is still secure because Chrome stopped the connection before any data was exchanged.
You cannot visit en.wikipedia.org right now because the website uses HSTS. Network errors and attacks are usually temporary, so this page will probably work later."

I'm using Safari to access Wikipedia -- and I don't like using S for editing. I'm sure many Wikipedia readers and editors are encountering the Chrome browser problem. Pyxis Solitary (yak). L not Q. 13:24, 6 October 2021 (UTC)

@Pyxis Solitary: your browser and/or operating system may not be up to date. See https://letsencrypt.org/2021/10/01/cert-chaining-help.html for more information. — xaosflux ^Talk 13:28, 6 October 2021 (UTC)

Also see this cloud mailing list thread which discusses a different aspect of the same issue. -- RoySmith (talk) 13:46, 6 October 2021 (UTC)

[tangent] I've been thinking about web browsers recently. Apparently, over the next year, Apple is improving users' privacy by moving some Safari users to something similar a VPN (approximate geolocation will still work, but your IP will change occasionally, if I've understood the description correctly?), and I hear that Chrome has announced they'll stop telling websites that the browser is Chrome to improve privacy, too (it will interfere with device fingerprint abilities). This is going to make things more difficult for the CUs, but a movement with our values can hardly complain about internet-wide improvements to user privacy. Whatamidoing (WMF) (talk) 15:40, 6 October 2021 (UTC)

Universal Code of Conduct Enforcement Draft Guidelines review still needs your ideas and opinions

Hello, this is a reminder that the Universal Code of Conduct Draft Enforcement Guidelines are open for local review and comment (comments may also be left on Meta, and at other local venues). The Drafting Committee will start working on revisions and improvement after October 17, so it will be helpful to provide thoughts before then.

There is also a newly-published abstract that provides an overview of the draft guidelines..

We are also hosting another conversation hour on October 15, 2021 03:00 and 14:00 UTC, as well as another functionary consultation October 7 18:00 UTC (tomorrow).

On behalf of the Drafting Committee, many thanks to everyone who has given ideas so far. We hope to hear from more of you - the Guidelines will be much stronger if more opinions are included. Xeno (WMF) (talk) 16:40, 6 October 2021 (UTC)