Wikipedia:Village pump (idea lab)/Archive 77

How about we use colours to make WP:RS sources stand out? Something in lines with this?^[1]

The pop-up link could be in green as well.^[1]

A different colour will also raise intrigue among new editors, and will ultimately lead up to a good chunk of them getting aware of the different categories of sources, especially reliable sources, in Wikipedia. Cdr. Erwin Smith (talk) 07:23, 18 February 2026 (UTC)

I do not support this idea. No source is reliable 100% of the time. We do not cite the New York Times for medical claims, for example. Sources may be generally reliable but editorial judgment is still required. Cullen328 (talk) 08:20, 18 February 2026 (UTC)

Editorial judgement will continue to be required, even if this proposal gets accepted.

The colour will simply differentiate RS from Non-RS sources, so that they stand out among the rest, if they're inserted based on editorial judgement. Cdr. Erwin Smith (talk) 09:34, 18 February 2026 (UTC)

It's often more complicated than just "reliable" or "unreliable". For example the Anti-Defamation League is listed at WP:RSPADL as being generally reliable for material outside the context of the Israel-Palestine conflict, partially reliable on the topic of antisemitism when Israel and Zionism are not concerned, and unreliable for the Israeli–Palestinian conflict. Any colour coding would this have to show it as red, yellow and green at the same time as the highlighter would be unaware of the context. Thryduulf (talk) 15:16, 18 February 2026 (UTC)

If the goal is to have a general color-coded list of reliable sources to make it easier for newer editors to identify them, we already sort of have that at Wikipedia:Reliable sources/Perennial sources. Note that this list is not reader-facing, and I agree with Cullen328 that it would not be desirable to make it reader-facing. The list merely attempts to describe past editorial decisions related to frequently used sources; it is not meant to prescribe how those sources should be used in every context. Mz7 (talk) 08:55, 18 February 2026 (UTC)

Note: when I first wrote the above comment , this section did not at the time include a link to WP:RSP in the section header. Mz7 (talk) 05:06, 20 February 2026 (UTC)

There are scripts etc. that do this based on various lists of sources, e.g. m:Cite Unseen and CiteHighlighter. Cheers, SunloungerFrog (talk) 09:28, 18 February 2026 (UTC)

If a source isn't reliable, why are you using it? All sources used within Wikipedia should be reliable, though no doubt some are more reliable than others. Colour coding for any reason is also a bad idea, with significant numbers of people being colourblind. Chuntuk (talk) 15:07, 18 February 2026 (UTC)

A generally unreliable source might be perfectly fine to cite for banal statements like "The sky is blue". Katzrockso (talk) 15:45, 18 February 2026 (UTC)

Do you even need to cite for banal statements like that? Citations are for proving things which have to be verified, not banal and everyday knowledge statements like your example. woaharang (talk) 17:22, 18 February 2026 (UTC)

Almost never. More relevantly though most generally unreliable sources are reliable for WP:ABOUTSELF matters. Some are also reliable for small niches, e.g. Blogger is marked as generally unreliable but hosts some blogs that are usable per WP:EXPERTSPS. Thryduulf (talk) 19:14, 18 February 2026 (UTC)

Do you even need to cite for banal statements like that? Generally not, but sometimes you do. mdm.bla 16:11, 20 February 2026 (UTC)

Honestly, I don't think it's a good idea. For example, a small number of editors may be colorblind. I know that most of us aren't, but it's important to respect disabled people. In any case, using WP:RS makes it kind of obvious what the category is.

Most editors ARE competent enough to know what citation goes where. This is basically spoonfeeding. woaharang (talk) 17:21, 18 February 2026 (UTC)

Aside from all of the valid issues already raised, I would not expect most readers to understand that ^[1] was intended to indicate that the citation to which it pointed was reliable. Rather, I would expect them to be confused by seeing different footnotes in different colours. Caeciliusinhorto-public (talk) 15:08, 20 February 2026 (UTC)

To assist with verification and finding suitable archival snapshots of webpages, it may be a good idea to make it a requirement to provide a valid |date= or |accessdate= parameter whenever a |url= parameter is used by a citation template. What I'm suggesting is that a warning message be displayed like when citing without a |title= parameter. Ideally, only one of them would have to be present to remove the warning, since it's often preferable for verification to have |date= but many websites don't provide one; |accessdate= provides a fallback when the reference is undated. If doing it that way would be difficult to code we could instead leave |date= as optional and make only |accessdate= a requirement, though this would increase the backlog we would have to deal with, so I'd rather avoid it. If implemented as accepting either |date= or |accessdate=, the wording of the warning should make it clear that |date= is not an alias or abbreviation for |accessdate= so newer editors are not confused. The warning should probably only be visible to editors, not readers.

If the presence of a date in some form were required with a URL, it would be a starting point for searching through snapshots of a webpage; just start with the snapshot with the nearest date. At present it's never a requirement, even for {{cite web}} where there's no alternative to using |url=. It might also be helpful for bots, since a bot could then not only check if a snapshot merely exists on an archival site but also check which snapshot is likely to be the most helpful, based on the archival date.

I first suggested this at Wikipedia:Requests for comment/Archive.is RFC 5 in the context of migrating archive links away from Archive.today; finding suitable snapshots elsewhere would be more straightforward if URLs were always paired with dates. Regardless of whether a consensus to deprecate/replace Archive.today links emerges, requiring dates with URLs would help with link rot in general.

If implemented, it would have to be done by an editor who has both technical knowledge and relevant permissions, as it would require modifying protected templates and possibly Module:Cite and/or related modules. It would also require making an appropriate tracking category, so editors could monitor and begin dealing with the new backlog of citations that should have dates but don't.

(I'm posting it here as I'm unsure if it's sufficiently "concrete" for "Proposals". If it is, please let me know so I can move this over there.) – Scyrme (talk) 23:03, 15 February 2026 (UTC)

For one thing, some URLs are courtesy listings when the citation is to a book, journal, or other printed matter. The cited material is not going to be lost if the URL stops working, and the date for the citation has nothing to do with when the URL link went up. Donald Albury 00:08, 16 February 2026 (UTC)

Providing a date for offline materials even when it isn't the same as the date it was published online is also helpful, so I don't see why this would be a problem. To be clear, I'm not suggesting that |date= always pertain to the URL. Part of the point of using the existing date parameter is so that references to works which have offline editions are excluded from the check even if a courtesy URL is provided. Link rot is less of a concern where print publications exist, so finding suitable snapshots isn't a priority and no warning/notice is needed.

However, if it would cause unforeseen problems to add this requirement to all citations, then how about at least requiring a date for {{cite web}}? The point of that template is to reference online-only resources, so there should be no issue with "date" differing from the date of publication online. Doing it this way would be better than nothing, but it would leave out any references that use other templates, eg. {{cite news}}, which are often also used for online-only material.

Another approach might be to create a new parameter, eg. |onlinedate=, to distinguish when "date" differs from the date of publication online, but the disadvantage of this is it would not exclude things that already have "date" or "accessdate", so the would inflate the backlog of citations with URLs to add dates to. If it's important to distinguish |date= and |onlinedate= for references which have both printed and online editions, we could add that new parameter as an additional way to remove the warning, so references which already have a date in some form are still excluded but editors can make the distinction when adding new references or updating undated references. – Scyrme (talk) 00:48, 16 February 2026 (UTC)

A lot of auto-filled citations for newspapers use {{cite web}}. WhatamIdoing (talk) 03:23, 17 February 2026 (UTC)

Might be possible to add a Help:CS1 errors about this, but as Donald Albury notes it would have to be refined enough to exclude citations where we don't require access-dates. CMD (talk) 03:31, 16 February 2026 (UTC)

I don't think this is needed because it's quite possible to find out when a URL was added to an article using a tool like WikiBlame. I'm pretty sure InternetArchiveBot uses a similar procedure to automatically add access dates and figure out which archive link to use. Also I've had situations where the access date is irrelevant because I've first accessed the link in archived form, long after it was taken off the live Internet; examples are references 2 and 16 at the Caitlin Hulcup article (permalink); I found those references because the Australian Web Archive is keyword-searchable. On re-reading, I've realised that those references have dates though. This reference, which I used dozens of times, is a concrete example of an undated reference, but I added a nominal access date in those cases. This sort of thing can also happen with the Wayback Machine if someone uses an old version of a website to find information. An example where I did this without either a date or access-date parameter because both were irrelevant is reference 4 at Corrina Hewat (permalink). Graham87 (talk) 04:08, 16 February 2026 (UTC)

@Graham87: I didn't know there were automated ways to add access dates. I'm glad they exist. However, these methods seem like they require some technical knowledge to use (and also knowing they even exist to begin with). I think most editors would find it much more straightforward to just click a live link, see if it verifies the text, see if it has a date, and add today's date (the date they checked) if it doesn't.

There are many articles that have issues that a bot could definitely fix, but, as is often the case with human editors, no bot has gotten around to it yet. If someone is editing an article anyway, why not alert them to an issue which is generally easy to fix?

If you have situation where the original webpage is undated, it dies, and you find it on an archive and reference it after the fact, a solution to that might be to also include |archivedate= in the check. Since the point of providing a date is help with finding an archive that works, if an archive is already provided the check can be skipped. – Scyrme (talk) 04:40, 16 February 2026 (UTC)

I know InternetArchiveBot has done at least a couple of run-throughs of the entire encyclopedia and I believe (but could be wrong about this) that it aims to check every page eventually. I think it's also through that bot that every time a new link is added to Wikipedia, an automated attempt is made to archive it on the Wayback Machine. Having said that, outside of the edge cases listed above, I usually only encounter URL's without dates/access dates when they're bare URLs. I'm going to provide a pointer to this discussion at Help talk:Citation Style 1, where changes like this are normally discussed. Graham87 (talk) 05:18, 16 February 2026 (UTC)

I'm not aware of links automatically being archived when added to Wikipedia. Is that for all URLs or only ones in references? If it's the latter, that would leave out bare URLs or manually written references which wouldn't necessarily get picked up automatically after an editor converts them to use a template. If there's some system that checks if an editor has added a URL, would it notice if an editor finds an old URL that was already in the article and puts it inside a template?

Regardless, as noted in the RFC regarding Archive.today, the Internet Archive isn't always successful at archiving pages so it would likely still be helpful to include a date that would assist in finding suitable snapshots through other archival services.

If dateless citations which use |url= are rare, managing the backlog shouldn't be difficult. At present, there's no way to check. (Or if there is a way, it's technical and most editors wouldn't know how to do it. I'm sure there's probably some external tool somewhere that could be queried to do this.)

Thank-you for providing the pointer. I wasn't sure where the best place for this would be, but I assumed it was here since it would affect so many articles, and I assumed the main talk pages would be mostly for maintenance. – Scyrme (talk) 06:08, 16 February 2026 (UTC)

It's all URLs in the main namespace. See Wikipedia:Link rot § Automatic archiving. Graham87 (talk) 11:07, 16 February 2026 (UTC)

Good to know. Though as it notes, "in practice not every link is getting saved". I don't think we can rely entirely on automation. – Scyrme (talk) 21:36, 16 February 2026 (UTC)

If it's not working with automated systems, then adding human error to the process is not likely to give us better results. WhatamIdoing (talk) 03:24, 17 February 2026 (UTC)

Guess anything a bot can't do perfectly isn't even worth attempting. Why allow human editors to do anything? Some of them will inevitably mess it up, so why bother? It's just more opportunity for human error.

I really doubt that's what you really think. There are obviously cases where manual editing is necessary. In cases where the the bots aren't successful, human intervention may overcome their limitations. In these cases, why not make the task simpler and less error prone by making relevant information more easily available? (In this case a date included in the template as a starting point for identifying the most suitable snapshot of a webpage.) – Scyrme (talk) 15:58, 20 February 2026 (UTC)

This would be something that's only useful for webpages that change overtime, for anything that's doesn't change this would be completely pointless. That goes beyond courtesy links to books, magazines, etc. There are many web links that will not change either, so this will only ever be useful for a subset of citations that are to webpages. Secondly there is no way to force editors to include an access date, all that can be done is create a tracking category and error message. If the large red error message that a refname is undefined goes regularly unnoticed (it's the most visible of such error messages), this will be doubly so. The tracking category will also start off with hundreds of thousands of entries.
Encourage editors to add a access date for transient webpage maybe, but it would be a bad idea to enforce this for everything with a url. -- LCU ActivelyDisinterested «@» °∆t° 12:54, 16 February 2026 (UTC)

All web links are liable to change eventually. Providing a date or accessdate where it's not strictly necessary doesn't do any harm. If even some editors notice and respond to the notice, which I know I would and I'm sure there are others who likewise fix citations when they find them, I don't see what the harm is. – Scyrme (talk) 21:25, 16 February 2026 (UTC)

Such a message could discourage people from supplying any citations at all. Far better a citation without a date than no citation. Phil Bridger (talk) 15:51, 16 February 2026 (UTC)

I don't see why it would discourage people from adding any citations. People aren't discouraged from adding citations by other notices/warning that citations emit. As ActivelyDisinterested notes, editors are more likely to just ignore a message they don't know how to fix than to remove a whole citation after adding it. Given how easy it would be to remove this notice, I can't imagine it deterring editors. – Scyrme (talk) 21:20, 16 February 2026 (UTC)

The longer and more complicated the task, the more likely people are to give up. WhatamIdoing (talk) 03:29, 17 February 2026 (UTC)

Finding a date for a dead link is a longer and more complicated process than providing one when adding a live link as a reference. In the latter case, an editor adding a URL could just provide today's date as the access date while they're adding it. It's quick and simple. It's probably an easier task than finding a URL to cite was in the first place. – Scyrme (talk) 03:36, 17 February 2026 (UTC)

I mean, you can always dig through the page history to find when they first added it. That's what I do sometimes. PARAKANYAA (talk) 00:50, 17 February 2026 (UTC)

That's true, but if editors were encouraged to add a date, there would be less need to dig through history (or use WikiBlame). It's usually better to reduce how often problems are made in the first place than to cleanup afterwards. – Scyrme (talk) 02:01, 17 February 2026 (UTC)

We don't even do that for people adding bare URLs. PARAKANYAA (talk) 05:17, 20 February 2026 (UTC)

A bare URL has no template which could be made to emit a warning. However, we do often manually add notices for bare URLs to encourage editors to fix them. ({{bare URL inline}}. {{bare URLs}}) We also provide tools to help with formatting references in both editors, to help editors avoid making the problem in the first place. The visual editor even has a tool that will automatically generate a properly formatted reference from a URL alone using Zotero (included a retrieval date), to make it as easy as it possibly could be to add a proper citation rather than just a bare URL. – Scyrme (talk) 15:50, 20 February 2026 (UTC)

That is not what you are arguing. You were arguing for it to be required when you include it. First we would have to get consensus for access dates being mandatory. Also, citoid does not work with many websites, including the New York Times. PARAKANYAA (talk) 23:03, 20 February 2026 (UTC)

I am and have always been arguing for a warning or notice to be displayed in preview when editing when a citation template which uses |url= does not include any kind of date parameter (not just |accessdate=). That is what I meant by making it required. If you thought otherwise, then perhaps I've not been clear enough; perhaps I should have said "encourage", not "require", but regardless I have not changed what I've been suggesting or arguing for. I am aware that consensus would be required; that's why I started a discussion.

I don't see the relevance of citoid not being perfect. Feels like you're moving the goalposts. I said it's usually better to reduce how often problems are made in the first place, you said we don't even do that for people adding bare URLs, and I have just shown that in fact we do, both by visibly marking it as a problem when it happens, albeit manually, which discourages some editors who see the notices from doing it in the future because they're made aware it's a problem, and by providing tools that help editors avoid creating the problem, by automatically formatting references for them, so it's easier for editors to do it correctly.

Now you're saying citoid doesn't always work. So what? How is that relevant to it's usually better to reduce how often problems are made in the first place? Even if it does it imperfectly, the rationale is still to assist editors so fewer of them create problems in the first place. If your argument is that it actually creates more problems than it prevents, then I could see the relevance, but, 1. I doubt it, and 2. that would be a case for removing the tool not an argument against encouraging or helping editors in not making (in this case, very easily avoidable) problems. – Scyrme (talk) 00:25, 21 February 2026 (UTC)

I am saying it is ridiculous for a warning to pop up over date when we don't even do it for bare urls. We don't need templates to emit warnings the strings can be detected. Neither are mandatory so we shouldn't treat them like they are. PARAKANYAA (talk) 02:47, 21 February 2026 (UTC)

Why is it "ridiculous"? I have described the practical benefits of including dates and how a notice would encourage editors to include them. You have neither refuted these benefits nor raised any problems which may outweigh the benefits. That a notice for some other problem doesn't already exist doesn't mean one should never be added for either problem.

The argument resembles WP:OTHERSTUFFEXISTS, though in this case you're arguing other stuff does not exist. I also still don't see much difference in principal between manually added notices and automated notices, so bare URLs don't seem like they're a particularly good example for other stuff not existing. – Scyrme (talk) 16:12, 21 February 2026 (UTC)

I've been a huge fan of checking in on the featured article and especially the featured picture on the main page each day. I remember reading something about certain audio files being promoted on the main page as part of a Today's Featured Audio section, or something like that. Did this ever happen? And if so, could it be brought back? There is such a great variety of audio on the site, such as historical speeches, animal calls/sounds, and recordings of instruments and compositions. These audio tracks bring so much colour and depth to articles, and I think having a section on the main page for them is more than warranted. RedRampageRuckusRaider (talk) 04:29, 22 February 2026 (UTC)

We used to have Wikipedia:Featured sound candidates. Per this search, they've only appeared on the Main Page once for Wikipedia's tenth anniversary. Graham87 (talk) 05:30, 22 February 2026 (UTC)

I really like this idea! Amercer1 (talk) 02:34, 23 February 2026 (UTC)

What does exist is the 'Media of the Day' tile on the Commons frontpage. See audio files previously featured there here. Prototyperspective (talk) 17:08, 23 February 2026 (UTC)

This seems like something that would have been discussed in the past, but I haven't seen any discussions so here goes...

Quick caveat: I'm just recently getting back into Wikipedia editing, so there's a good chance I'm not up to date on how some of this stuff works - so take the below with a grain of salt.

Many (most?) categories on Wikipedia (and likely on other sites like Commons) look to me like they could be automatically generated by querying WikiData.

For example, take https://en.wikipedia.org/wiki/Category:Albums. This category could be easily represented with a WikiData query - "Give me all Wikipedia pages that correspond to 'instance of' 'album'".

For another example, take https://en.wikipedia.org/wiki/Category:Against_Me!_songs. Corresponding WikiData query: "Give me all Wikipedia pages that correspond to 'instance of'='album', where 'performer'='Against Me!'"

Another non-music example: https://en.wikipedia.org/wiki/Category:People. Corresponding query: "Give me all Wikipedia pages that correspond to 'instance of'='person'".

Over the long-term, I think it would be way more scalable and maintainable to generate Category lists automatically using WikiData, rather than requiring editors to manually keep these up to date.

Benefits:

• Saves time for editors with adding categories. As long as pages are tagged with the relevant properties in WikiData, editors don't need to go into the "Category" section and select appropriate Categories for pages.
• Categories should become vastly more accurate/comprehensive over time. As far as I understand, accuracy of Categories currently depends on editors putting manpower into manual categorization. Instead if we can rely on our data and generate the Categories based on the data, the Categories should start to maintain themselves.
• Nudges editors in a more productive direction.
• ---- Current state (to my knowledge): If a page is missing from a Wikipedia category, the editor is encouraged to manually add the page to that category on Wikipedia, on a specific language Wikipedia.
• ---- If automatic categories are implemented: Editors are encouraged to fix the underlying metadata in WikiData - which provides more flexibility/value overall.

• This should make it easier for different languages to benefit from WikiData/categories. Rather than each wiki maintaining its own set of Categories, if the data is all centralized in WikiData and Categories are automatically generated, then every language wiki could benefit from the same Categories I'd think.

Another option:

Another possibility would be allowing let users to associate a WikiData query with a manually-created Category. Then, let the user click "run query" to get back a list of pages from the query. This would let the user compare the manually-curated pages in the Category to the query-generated Category pages.

Another option:

Create an alternative type of Category (maybe call it "auto-generated Categories" or similar) to fulfill this need, rather than messing with/impacting the existing Category system. And allow users to look at Categories and Auto-generated Categories side-by-side. This could be a beta feature for awhile, invisible by default until the bugs are worked out. Ancient9983 (talk) 10:42, 9 February 2026 (UTC)

I like this idea, and suggest that it not really be "automatic categories", but more like "automatic suggestions". It might be more valuable to Commons. WhatamIdoing (talk) 23:31, 10 February 2026 (UTC)

Hello, this is exactly the subject of Wikidata discussion: How can Wikidata be useful IRL if it has less data than Wikipedia? and in some way also m:Contradictions within Wikimedia projects. I'm intending to create a page on Wikidata about this topic which aggregates all the info about this subject.

A problem there is that other than what you may expect, Wikipedia usually has more structured data in categories than Wikidata. This is because there's only few users only running few and usually very limited bulk data imports and because data in Wikipedia is not systematically imported to Wikidata. A tool to do so is the HarvestTemplates tool which can get data from temples into Wikidata but it has issues and nobody is developing it further and is only about templates anyway.

For the other direction of Wikidata->Wikipedia, a tool to do this is petscan & list-building tool & listeria (forgot which of these is best suited) as described in this video. However, it requires quite some time, manual reruns to update things, and most importantly doesn't scale and is limited to highly-motivated highly-active technicallyskilled users. On Commons, automatic addition based on Wikidata is done via the Wikidata infobox template. However, it only adds a small subset of categories which have been requested individually on the talk page which has lots of requested in need for volunteer developers to help out with. For example, I requested the addition of automatic categories for software categories for the data on which programming language it was written in and things like that which were recently added. And I requested the birth year and death year categories to be added by the template which are currently added by contributors manually (0 replies so far). Note that this only works for categories that have a Wikidata item and were linked to it.

Over the long-term, I think it would be way more scalable and maintainable to generate Category lists automatically using WikiData, rather than requiring editors to manually keep these up to date. What it needs imo are ways to keep both in sync. That will also surface contradictions and thereby enable seeing & fixing flaws (see link above). Categories are created by Wikipedians. Categories part of a series (such as a category for every year) could also be created automatically (e.g. the one for 2026). Also note that a surprisingly large fraction of Wikidata items, including many linked to popular broad articles that are well categorized, do not have their key or any instance of and/or subclass of properties set and not very rarely are the ones set false.

then every language wiki could benefit from the same Categories I'd think. Please see Wish375: A tool to copy Wikipedia categories to another language Wikipedia. Note that it's not useful but problematic if you create finely subcateegorizing categories when the respective Wikipedia doesn't have so many articles to make that useful. A wikipedia with articles on just 3 books published in a year may not want to subcategorize them by genre for example.

allowing let users to associate a WikiData query with a manually-created Category That would be great and I meant to propose sth related to this regarding incomplete Commons categories.

Create an alternative type of Category (maybe call it "auto-generated Categories" Maybe the wish 375 could be extended with this idea. I don't think English Wikipedia in specific would have a lot of reasonable/useful auto-generated categories that aren't yet categories so I don't think this would be useful here. Prototyperspective (talk) 15:04, 12 February 2026 (UTC)

I agree about not over-categorizing subjects. First, it's not practical to drill down through a dozen cats to find a nearly empty category like "Category:British detective books published in 1952" at the end. Very small wikis might benefit from not having too many categories beyond the very basic list in mw:ORES/Articletopic.

Second, people might actually prefer a Wikipedia:Category intersection approach (how most modern websites work, e.g., if you go to a real estate website and filter for houses of a particular size and price), and putting detailed individual cats on the page. In that case, you want Category:British publications, Category:Detective books, and Category:1952, and the rest can be sorted out from there. WhatamIdoing (talk) 01:26, 14 February 2026 (UTC)

The second point is an interesting subject where there's quite some potential for improvements/developments I think. Here one can theoretically already use the deepcategory search operator which is far too unknown, underused and not integrated anyhow (eg into the search page). Problems with it are:

• It fails or only shows results up to a certain limit for large categories like deepcategory:Science (where one would have to use petscan or similar) but it actually works for deepcategory:1952 which also is a quite large cat with 41,566 articles. Also worth noting is that still many articles miss key categories (or have only too broad categories instead of being in the category about exactly the article's topic).
• Often, there are some miscategorizations. A tool to see why an article is somewhere underneath a category would help improving or fixing the categorizations and I requested such here (voting open) albeit focused on use for Commons. But even if such a tool is built and it's widely used by people to improve categorization, there probably are still quite many flaws (it always depends on the category). The miscategorizations often limit the usefulness or accuracy of the cat intersection/filter.
• Relevant categories are difficult to know or find and not eg suggested on the category page to create dynamic filtering. Currently people would have to know about the deepcat search operator and then manually type what intersection they have in mind into the search bar.

Prototyperspective (talk) 14:31, 14 February 2026 (UTC)

Unfortunately one problem I see here is how bad the current user interface is for Wikidata. Realistically unless it was completely overhauled to be more user friendly I personally would not want to have to edit Wikidata just to update something on Wikipedia. -- LCU ActivelyDisinterested «@» °∆t° 18:06, 13 February 2026 (UTC)

Other than the missing button to add a statement at the same place at the top (phab:T142082), which issue(s) do you see with it? The input fields already have autocomplete and also show the possible/expected properties to enter first (or only). One problem maybe is navigating to instances that are subclasses or things like that – do you mean such navigational things? If any of what the user suggested was implemented I'd imagine sth to add things to a dynamic category could be shown directly on the category page on Wikipedia without having to go to Wikidata.

In any case, it seems more reasonable to let changes to Wikidata trickle down into Wikipedia(s) and changes here to trickle up to Wikidata. @Ancient9983 I suggest to sometimes create sparql queries for the things you have in mind like "Give me all Wikipedia pages that correspond to 'instance of' 'album'" with that you'll often see if you compare it to the Wikipedia category that oftentimes Wikipedia is more complete (even when Wikidata has some items that are missed in Wikipedia). You can somewhat easily create such queries with this. This should make it easier for different languages to benefit from WikiData/categories. Rather than each wiki maintaining its own set of Categories If the Wikipedias' changes via categories and infoboxes are synced to Wikidata then the same thing is achieved without substituting categories. The categories retrieved from Wikidata could also be 'WD suggested categories' that are only added as normal categories when users here review them by going through the backlog. Prototyperspective (talk) 18:42, 13 February 2026 (UTC)

I mean that the whole interface needs to be chucked out and redone, and that noone should have to edit Wikidata to edit Wikipedia. It's a shame that the bridge to backflush data from Wikipedia to Wikidata hasn't been created, as it would solve this issue. No amount of tinkering with the current Wikidata interface will solve the problem. -- LCU ActivelyDisinterested «@» °∆t° 20:31, 13 February 2026 (UTC)

I have to agree with ActivelyDisinterested on this. When I look at a Wikidata page, I find it completely incomprehensible to me. It might as well be in ancient Sumerian. If I wanted to edit it, I would not even know where to begin. I don’t even understand how it is structured.

So… I tend to be wary of any attempt to integrate the two projects. And I strongly oppose any proposal that suggests that we would have to go to a Wikidata page to make a change appear on a WP page. Less adamant going the other way… but still wary. Blueboar (talk) 02:10, 14 February 2026 (UTC)

Well I have to say such criticism isn't as is quite constructive. It's unclear. But if you can explain it more clearly maybe some things could be improved there. It's very unlikely the whole interface will be fully overhauled to sth entirely different. I always found it quite self-explanatory and don't know what you don't understand about it. It's as simple as this:

There are 'items' which can have Wikipedia article links. Other than such links they're composed of Property:Value statements. For example, Instance of: Building. It's as simple as that. To make it complete and you don't really need to know this early, there are also Qualifiers for Values. One example for that is Language: English (for example if the Value is a website URL). If you want to edit you need to as said click the "add a statement" button on an item or if you want to create a new item in the left main menu panel select "Create a new Item". I don't think arguments the UI is that incomprehensible hold water in the face of this simplicity. People say the same about Wikipedia; well you got to actually go ahead and use it and try – then the things you need to know will quickly become simple. Nevertheless, I don't support requiring users to go to Wikidata anyway. Prototyperspective (talk) 12:08, 14 February 2026 (UTC)

I know that MediaWiki uses SQL, so maybe we could query (with my very limited knowledge of SQL) SELECT * FROM data WHERE instanceof = 'album'. SeaDragon1 (talk, contributions) 16:24, 23 February 2026 (UTC)

This would be queried using SPARQL and as said WD has some items with that instanceof set that Wikipedia does not have and Wikipedia has some (sometimes many) that Wikidata does not have. Moreover, things are categorized sometimes differently on WP than what's possible on Wikidata (more so when considering not only whether it's technically possible but also whether it's actually set). Lastly, the SQL or SPARQL for querying isn't among the main subjects here.

Another non-music example: https://en.wikipedia.org/wiki/Category:People. Corresponding query: "Give me all Wikipedia pages that correspond to 'instance of'='person'". Wikipedia has them subcategorized; Wikidata, with the slow-loading tens of thousands of people items, hasn't. Prototyperspective (talk) 17:05, 23 February 2026 (UTC)

Well, if you want to fetch it from Wikipedia (either from the actual content of Category:People or via an API), go ahead. Just make sure you know about CORS. SeaDragon1 (talk, contributions) 17:22, 23 February 2026 (UTC)

When I do a search for a string using insource, it is *much* more likely to actually finish if I add a "normal" word to search for in the search. So if I do a search on (putting # around my searches in this text) # insource:/dia of Fraternities/i stevens #, it goes much faster than and is far more likely to finish than # insource:/dia of Fraternities/i # . The issue is that if the first search returns no records (say if I'd searched on # insource:/\<ref>[^\<]*dia of Fraternities/i stevens # ), it says "Showing results for sevens. No results found for insource:/\<ref>[^\<]*dia of Fraternities/i stevens." This assumes that the "problem" is there are no hits for stevens, not that the insource is limiting them. In the case where an insource: (or intitle: etc.) squeeze the results down to zero records, I propose that it show the results for the normal word actually in the search, in that case stevens rather than sevens. This is just an example, I've run into it doing other similar searches. I'm not sure this is ready for a proposal, or where this discussion should be done, but the help desk doesn't seem like the right place.Naraht (talk) 21:44, 20 February 2026 (UTC)

Phab: might be the right place. See mw:How to report a bug. Just tell them that you're having a problem with searches timing out (they know this is a problem) and that when it's a problem, you'd like to get ____ instead of nothing. WhatamIdoing (talk) 06:04, 23 February 2026 (UTC)

WhatamIdoing. Timing out isn't really the issue. I've written some fairly complex insource regexes (The fact that look-ahead/look-behind aren't allowed isn't that surprising) It's the how do we get from stevens to sevens. (In a similar situation it suggests fraternitys (yes, an improper plural) for a complex insource plus fraternity. And I'm not honestly sure it would count as a *bug*, but more of a discussion, which is why jumping to Phab doesn't seem right.Naraht (talk) 13:27, 23 February 2026 (UTC)

Phab takes feature requests, too. Anything that needs a code change is going to require a Phab ticket eventually. WhatamIdoing (talk) 19:36, 23 February 2026 (UTC)

Naraht, if I understand what you are saying, this is nothing new and is already described at mw:Help:CirrusSearch#Using the index first to filter results. You could try asking at mw:Help talk:CirrusSearch. Or, try a Phab enhancement request, but I'm not sure how far that would get as Cirrus is built on mw:Elasticsearch and what you are asking for isn't fixable by MediaWiki, I don't believe. Just follow the recommendations for responsible regex requests (which it seems you are already doing, and discovered by yourself) and you should be fine. Mathglot (talk) 03:08, 24 February 2026 (UTC)

Since the latest policy proposal on using LLMs is unlikely to pass, I thought that maybe a different approach could work. Most of these proposals suffer from the enforcement problem: that it's extremely difficult to definitively determine whether any given text was LLM-generated (see this report by WikiEdu for the discussion on what works and what doesn't). The community would not want to sanction editors based on uncertain evidence.

Alternative proposal: address the harms directly! Rather than trying to detect LLM use itself, what if we focused enforcement on the specific problems that LLM-generated content causes? Consider the major issues with LLMs

• Citation accuracy: LLMs are often unreliable at faithfully representing sources. We could impose stricter sanctions and strengthen enforcement of WP:V, especially for editors who repeatedly add claims that don't match their citations.
• Volume and review capacity: LLMs enable editors to add large amounts of content slop quickly, overwhelming our ability to review it adequately. We could implement rate-limiting measures, perhaps restrictions on the number or scope of edits that editors can make within a given timeframe, with newer editors subject to stricter limits.

These measures target the harm to encyclopedia quality directly. They can work alongside (and serve as an enforcement mechanism of) a more general ban if we end up adopting it. They can also work on their own if we don't adopt a general ban on LLM content.

What other specific harms from LLM use can you think of? Any side effects such measures might have? Alaexis_¿question? 11:28, 5 February 2026 (UTC)

Putting aside the way the above is written, the enforcement problem applies to a lot of our policies, we are reactive because of the open nature of the project. There isn't really an enforcement gap in terms of stricter sanctions for Citation accuracy, people get blocked a lot. The gap there is in detection in the first place, which we don't have the manpower to do. As for rate limiting, not sure how that would work. Even WP:MASSCREATE requires manual oversight, and creation is easier to track technically than edits in general. CMD (talk) 11:36, 5 February 2026 (UTC)

There isn't really an enforcement gap in terms of stricter sanctions for Citation accuracy, people get blocked a lot I didn't know this is the case. What is generally considered a block-worthy behaviour? But in any case detecting inaccurate citations is a much simpler task than detecting LLM-generated content.

As to the rate limiting, it's a problem that a lot of other organisations have solved in various contexts. Before discussing technical details let's first establish whether it's a good idea in principle. Alaexis_¿question? 12:36, 5 February 2026 (UTC)

Disruptive editing in the article space often results in blocks, I don't think most admins have a strict checklist. I don't think it is easier to detect inaccurate citations in any case, llm use can be blatant, whereas checking citations almost always requires investigative work. As for rate limiting, there isn't going to be support for a generic number of edits or amount of content filter because they mask a huge range of variation. If you are proposing something more specific, there'll need to be at least broad technical details. CMD (talk) 13:44, 5 February 2026 (UTC)

I see your point. Let's see what others say. Perhaps our existing processes already do a good job of preventing this kind of mass editing. Alaexis_¿question? 14:42, 5 February 2026 (UTC)

detecting inaccurate citations is a much simpler task than detecting LLM-generated content. Actually the opposite, overwhelmingly so. A great deal of LLM-generated content is pretty obvious linguistically. But verifying the citations and source-to-text integrity can take hours or even days depending on length of the article and availability of sources. (This is the same conclusion WikiEdu came to recently - verifying AI content takes longer than just researching/writing from scratch.) Gnomingstuff (talk) 15:55, 5 February 2026 (UTC)

The wikiedu report I linked mentions false positives and clearly the no tool would give you full certainty.

"A great deal of LLM-generated content is pretty obvious linguistically" is *maybe* true if the person creating it makes zero effort to hide it. Alaexis_¿question? 16:02, 5 February 2026 (UTC)

Obvious AI content is obvious, but not all AI content is obvious. It is also the case that some content that is, to some reviewers, obviously AI is not in fact AI. The rates of detection reported in studies vary greatly with 75-99% detection of AI content as AI, and 2-50% for false positives (human-written content detected as AI). I can't immediately find it, but @WhatamIdoing has previously cited a study that found the humans who are most reliable at detecting whether something is or is not AI are those who themselves make significant use of AI tools (which describes few of the Wikipedians who are most vocal about AI use). Thryduulf (talk) 17:21, 5 February 2026 (UTC)

It's linked in Wikipedia:Signs of AI writing#Caveats. WhatamIdoing (talk) 18:34, 5 February 2026 (UTC)

I would guess the people who work heavily on AI cleanup are probably much more knowledgeable about AI, at this point, than the control group in that study.

A lot of what we get as AI content is either completely unreviewed, or reviewed little enough that if they made an effort to hide it, they didn't do a very good job, because the biggest tells of AI use are not necessarily intuitive or obvious to laypeople. (Which is the case with most large language model-related tells. These are quirks of vector math, they're not going to fit a palatable spiritual narrative.) Gnomingstuff (talk) 21:56, 5 February 2026 (UTC)

If we end up getting Pangram (which doesn't have an article btw?) through the WMF, then this proposal may be moot for now Kowal2701 (talk) 17:30, 6 February 2026 (UTC)

Not sure it meets WP:NCORP currently but I wrote a draft Gnomingstuff (talk) 21:21, 6 February 2026 (UTC)

Why? It still works probabilistically and has false positives. How comfortable would you be with imposing sanctions based on a black box that told you that a given edit is LLM-generated with the probability of 83%? Alaexis_¿question? 23:05, 6 February 2026 (UTC)

Depends on context. If it's an editor who's been warned and shown no sign of changing, pretty comfortable. Would obv use ordinary analysis as well. But Pangram has false positives less than 1% of the time Kowal2701 (talk) 00:03, 7 February 2026 (UTC)

@Kowal2701, I saw this number in the draft that you've created but to be honest I doubt it. I tested it and reached 100% fully human written with a simple prompt and 3 minor copyediting tweaks in a passage of ~100 words. I don't want to describe it here per WP:BEANS but if you're interested I can share it privately. Alaexis_¿question? 12:16, 7 February 2026 (UTC)

<1% is for false positives, I'm sure it's much higher for false negatives. Whatever troubles we're having, education systems have it much worse, I'm amazed LLMs were released with no considerations for that, like making all output identifiable. Btw it was Gnomingstuff who created the draft Kowal2701 (talk) 12:27, 7 February 2026 (UTC)

Sorry @Gnomingstuff! Btw I think that the draft can be promoted to the mainspace.

The paper says that Commercial detectors outperform open-source, with Pangram achieving near-zero FNR and FPR rates that remain robust across models, threshold rules, ultra-short passages, "stubs" (≤ 50 words) and 'humanizer' tools. Note that it hasn't been published in a peer-reviewed journal. I'll go out on a limb and say that I don't believe these numbers. To check false positives I'd need more Pangram credits, that would be an interesting exercise. Alaexis_¿question? 19:58, 7 February 2026 (UTC)

Yeah one of the reasons it's in sandbox is because the efficacy section is scant and mainstream media coverage is just not really there at the moment Gnomingstuff (talk) 04:24, 8 February 2026 (UTC)

So, adding a lot of content to Wikipedia is harmful and should be stopped. Duly noted. Cambalachero (talk) 14:00, 5 February 2026 (UTC)

This is not at all what I said. As an example, a user with an LLM can create 1000 articles in one day overwhelming the capacity to review them and do even basic notability checks. The rate limit should be set high enough not to affect human contributors. Alaexis_¿question? 14:21, 5 February 2026 (UTC)

Adding a lot of unvetted AI slop to Wikipedia is harmful and should be stopped, yes. XtraJovial (talk • contribs) 21:38, 6 February 2026 (UTC)

Adding a lot of poor-quality content to Wikipedia is harmful and should be stopped, whether that content is human-generated, AI-generated or a mix.

Adding a lot of high-quality content to Wikipedia is beneficial and should be encouraged, whether that content is human-generated, AI-generated or a mix.

What matters is the quality of the output, not the tool. Thryduulf (talk) 21:53, 6 February 2026 (UTC)

• The flaw with using LLMs is one that many editors fall into even when NOT using LLMs: not doing proper research before you write.

A proper article is source based… the writer first reads LOTS of sources and then summarizes what they say (and then cites the best of those sources to provide verification for that summary).

A poor article is text based… the writer first decides what he wants the text to be, and then finds (and cites) a source to verify it. That is the wrong/backwards approach.

That said… You CAN use LLMs for research… to locate potential sources… but you need to actually read those sources in order to see if they fall in line with what other sources say. You can not properly summarize the sources based only on an LLM. You need to read lots of other sources as well. Blueboar (talk) 14:49, 5 February 2026 (UTC)

• Just make WP:LLMDISCLOSE a guideline, as I've been saying for over a year now. Experienced editors should be able to understand that presenting text or ideas that originated in an LLM as their own words goes against WP:PLAGIARISM and/or WP:FREECOPY and/or WP:NOSHARE. Those guidelines apply in both article and talk space. New editors who are non-transparent about their LLM use get blocked all the time. Some of those people were headed for blocks anyway, but some of the blocks could possibly have been averted by a clearer explanation of community expectations for transparency about the provenance of text. We can litigate the pros and cons of various AI use cases, but there's literally no constructive reason to be non-transparent about the source of the content you insert here and most of the LLM-related problems we face will go away if people start following WP:LLMDISCLOSE. -- LWG ^{talk (VOPOV)} 17:33, 5 February 2026 (UTC)

  The people who would do the most harm using LLMs would be least likely to disclose their LLM usage. If they add unreviewed LLM slop it means they don't know or don't care about our basic policies. Why would they obey LLMDISCLOSE? Alaexis_¿question? 22:08, 5 February 2026 (UTC)

  Not all LLM users are bad faith. -- LWG ^{talk (VOPOV)} 06:34, 6 February 2026 (UTC)

  I think most LLM-use is done in good faith, most just aren't aware of on-wiki guidance or the problems w LLM-use Kowal2701 (talk) 17:33, 6 February 2026 (UTC)

  It's a combination of people using LLMs in good faith and people editing in bad faith (mostly spammers) who use LLMs because that's how you spam nowadays. Gnomingstuff (talk) 20:38, 6 February 2026 (UTC)

  That's a great point. So we have two personas

  Alice: a well-intentioned user who wants to contribute to Wikipedia and is not aware of our policies and of the issues with LLMs. For these users, a well-placed warning is all we need to prevent them from copy-pasting LLM output. The warning can be added based on existing policies such as WP:V.

  Bob can be a troll, a paid editor or a true believer with an axe to grind. They can use LLMs to generate a higher volume of edits and make the violations harder to detect.

  I regularly talk to new users and I can confidently say that both types exist. The measures I proposed were mostly to deal with the second type of editors. It's possible that the existing mechanisms already handle them just fine but I'm not sure they do, considering that they require manual admin/editor work. Alaexis_¿question? 22:59, 6 February 2026 (UTC)

  While this is true, it's the same principle we use for WP:COIs and especially WP:PAID - it means that we can block the worst abusers on sight as soon as we determine they're using LLMs. In both cases I'd prefer a total ban, but a declaration requirement backed by instablocks for knowing violations (maybe one warning for people who might not realize) will at least let us remove many of the worst abusers as soon as we recognize that they're using LLMs. If you flip it around, the fact that the worst abusers wouldn't obey LLMDISCLOSE is the entire point - we're always going to have to catch them, sure, but LLMDISCLOSE means we can block them instantly once we catch them, with no further debate or discussion needed beyond maybe one second chance for people who go "oops I'm sorry, I didn't know" and follow the guideline going forwards. --Aquillion (talk) 15:25, 14 February 2026 (UTC)

  The lead paragraph of WP:LLMDISCLOSE, verbatim, should definitely be a guideline if not a policy. Honestly, I think it should be in the Terms of Use. Arguing that we shouldn't require users to do something because bad-faith users won't do it is like saying we should ditch verifiability because vandals don't care. lp0 on fire () 11:48, 6 February 2026 (UTC)

  The huge difference is that a source can be checked by anyone who has access to it (for many sources - literally by anyone with the internet connection).

  To steelman your argument, it's more like the disclosure of COI and paid editing. Here we also don't have the ability to check whether an editor is paid for his edits. I don't know if this disclosure policy can be considered successful. Alaexis_¿question? 12:00, 6 February 2026 (UTC)

  That's fair. I nonetheless see no reason for a good-faith editor to hide their LLM use. lp0 on fire () 12:19, 6 February 2026 (UTC)

  But would you argue we should repeal WP:PAID just because we can't catch everyone? That would be absurd. Having it is still extremely valuable, since it's what lets us instantly block the worst paid editors when we catch them. LLMDISCLOSE would work the same way - it's not a magic cure-all, but it would be a huge improvement over having nothing. --Aquillion (talk) 15:28, 14 February 2026 (UTC)

  Let's say I ask ChatGPT a question, and it gives me a piece of text as an answer. Can someone else find that specific piece of text in the internet on his own? And if the answer is no, can we say (from the point of view of copyright law) that the text was "published", and not merely privately shared? Cambalachero (talk) 14:43, 6 February 2026 (UTC)

  WP:PLAGIARISM doesn't care if the text you falsely present as your own was privately shared or published. If you didn't write it youself, you cannot insert it into Wikipedia unless you disclose the source and provide proper attribution. -- LWG ^{talk (VOPOV)} 15:47, 6 February 2026 (UTC)

  I do not agree. The combo of both a lack of author and a lack of publication (understanding both terms in the copyright sense) means that there is no plagiarism even if the text is copypasted elsewhere. And note that Wikipedia:Plagiarism does not say anything about this specific scenario. Cambalachero (talk) 16:12, 6 February 2026 (UTC)

  Respectfully, this is why I am urging the community to adopt WP:LLMDISCLOSE as a guideline, to make it clear to people like you that the lack of copyright on LLM text does not make it acceptable to claim it as your own, just as it is unacceptable to claim other forms of public domain or mechanistically generated text as your own. -- LWG ^{talk (VOPOV)} 16:18, 6 February 2026 (UTC)

  In other words, you can't justify your proposal if it is challenged by someone with actual arguments instead of mere acronyms, so you want a "guideline" to shut the door to any discussion and have things be your way... not by force of reason, but by reason of force. Cambalachero (talk) 16:36, 6 February 2026 (UTC)

  Not at all, my argument is simple: per the terms of use of Wikipedia, any editor who inserts text here is representing that they own the copyright on that material and are releasing it under a Wikipedia-compatible license. The only exceptions are limited quotes, which must be clearly marked and attributed, and public domain content, which must be clearly marked and attributed. LLM text is not copyrightable, as you have argued above, so it cannot be released under a Wiki-compatible license, so it must be clearly marked and attributed as one of the exceptions if it is inserted at all. That's not acronym bludgeoning, and I don't think it's difficult to understand. You are allowed to disagree with me: I'm not the king of Wikipedia, and this proposal (which I oppose) isn't about LLMDISCLOSE anyway. -- LWG ^{talk (VOPOV)} 16:50, 6 February 2026 (UTC)

  It isn't? Oh, you must have confused me with that "Just make WP:LLMDISCLOSE a guideline, as I've been saying for over a year now" bolded text that I replied earlier. Cambalachero (talk) 16:56, 6 February 2026 (UTC)

  @LWG, please see https://creativecommons.org/2023/08/18/understanding-cc-licenses-and-generative-ai/ under "CC Licenses and outputs of generative AI", especially the line that says If you create works using generative AI, you can still apply CC licenses to the work you create with the use of those tools. Creative Commons "encourages" (but does not and cannot require) people to label generative AI output as CC-0. This is for the convenience of re-users, not because of some fundamental incompatibility with the license. After all, a typo fix or a one-word reply is not copyrightable either, and Wikipedia editors have been "licensing" such uncopyrightable edits for 25 years now.

  We could set a higher standard, as we do for (e.g.,) WP:NFCC. However, we should not say that there are licensing or legal problems with posting uncopyrightable content on wiki. WhatamIdoing (talk) 19:43, 6 February 2026 (UTC)

  Thanks for the link. What I see on that page: The CC license you choose will apply to the creative work that you contribute to the final product, even if the portion produced by the generative AI system itself may be uncopyrightable. So I'm not sure I have the same understanding as you do there. The copyright status of LLM output is above my paygrade, but if it's public domain, as has been argued by others, I don't see how it doesn't fall under the same requirements as other public domain content. -- LWG ^{talk (VOPOV)} 20:31, 6 February 2026 (UTC)

  Yes, LLM output (according to what others say) at least usually does fall under "the same requirements as other public domain content".

  But: In terms of the CC license itself (NB: not including any additional rules that the English Wikipedia chooses to adopt – just the actual legally binding contract in which you "agree to irrevocably release your text under the CC BY-SA 4.0 License"), there are no requirements for public domain content.

  For example, you can "license" a typo correction, like you did in this edit, even though that is a non-copyrightable public domain edit. The typo correction doesn't become copyrighted or further restricted by the license, but you're not violating the license by posting something that is not eligible for copyright.

  The same logic applies (as far as anyone can tell, at least under US law at the moment) to LLM output. It's not eligible for copyright protection, but posting it on wiki doesn't violate the Creative Commons license.

  Posting some kinds of LLM output (e.g., a couple of sentences of new content) without disclosure would AIUI fall afoul of our local rules against Wikipedia:Plagiarism, but it isn't a copyright or license problem. WhatamIdoing (talk) 07:17, 22 February 2026 (UTC)

  Copying a string of text from an LLM is no more plagiarism than copying a random string of numbers from a random number generator Czarking0 (talk) 20:15, 10 February 2026 (UTC)

  Claiming that you wrote something when you definitely didn't write it is plagiarism. (Call it "lying about who wrote this" if that's easier to understand.) WhatamIdoing (talk) 07:19, 22 February 2026 (UTC)

  Whem you say "plagiarism", are we talking about actual copyright law, or just using buzzwords to mean that you don't like it? Cambalachero (talk) 15:42, 22 February 2026 (UTC)

  @Cambalachero: neither; WAID is talking about plagiarism, which, as that page will tell you, is not the same thing as copyright infringement. lp0 on fire () 15:47, 22 February 2026 (UTC)

  WhatamIdoing was pretty clear to me. XtraJovial (talk • contribs) 15:52, 22 February 2026 (UTC)

  I don't think it's black and white. If I consult a dictionary to find the right word I don't need to credit it. With the LLMs the question is how much human review and/or changes are needed for me to be considered the author. Alaexis_¿question? 15:57, 22 February 2026 (UTC)

  If you post something to Wikipedia, unless it is clearly marked as a quote, then you are representing it as your work. If you are copying the content from somewhere without attribution, that is plagiarism. And the argument about words you have looked up in a dictionary is a straw man. Donald Albury 18:16, 22 February 2026 (UTC)

  Copyright is a legal thing. Plagiarism is a moral thing. It is possible to violate the legal thing without violating the moral thing, and vice versa. WhatamIdoing (talk) 19:30, 22 February 2026 (UTC)

  If morality prevents you from improving or maintaining Wikipedia, ignore it. Cambalachero (talk) 18:13, 24 February 2026 (UTC)

• Could we get a very simple brightline rule of "editors may not use LLMs for paid editing"? This includes the edits themselves, the disclosures, and addressing concerns about the edits on talk pages. Hopefully that's a simple, brightline, "don't speed with a body in the trunk" type rule. Tazerdadog (talk) 22:15, 5 February 2026 (UTC)

  Um, have you seen the various uproars at Wikipedia:Administrators' noticeboard § OKA: problematic paid translation and lead rewrites via LLMs across thousands of articles.? I fear a simple brightline is unachievable where LLMs are concerned. ClaudineChionh (she/her · talk · email · global) 11:55, 6 February 2026 (UTC)

  I think that is a very good example of why such a bright-line rule is desirable. The imbalance of time between a paid editor using an LLM and volunteers reviewing manually is untenable. Tazerdadog (talk) 00:58, 7 February 2026 (UTC)

  To quote from there

• Looks like some kind of rate limiting would've helped. Alaexis_¿question? 12:19, 7 February 2026 (UTC)

  Maybe we can encourage them to go work on Crockipedia instead? ← Metallurgist (talk) 19:19, 10 February 2026 (UTC)

The rate limiting measures could possibly end up creating a Streisand effect to editors who were not planning to use an LLM to generate wiki content. ~2026-11404-95 (talk) 16:47, 24 February 2026 (UTC)

I created Template:New archival link needed as a potential solution to highlight links to archive.today or other deprecated archival repositories. Following the archive.today RFC being closed in favor of deprecation and removal, I am wondering if it is possible to have a bot append this template to references linking to archive.today as part of the removal process. mdm.bla 03:21, 20 February 2026 (UTC)

As an example: Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.^{[1][new archival link needed]} mdm.bla 03:29, 20 February 2026 (UTC) mdm.bla 03:29, 20 February 2026 (UTC)

In a technical sense, a bot can to do this, and it should be fairly easy for one to do so. The harder part is establishing consensus that a bot should do it. The outcome of Wikipedia:Requests for comment/Archive.is RFC 5 helps, but doesn't specifically establish that a bot should go around adding this tag to half a million articles. Anomie⚔ 13:21, 20 February 2026 (UTC)

Thanks for the input, Anomie. Do you think this is an idea that is worth exploring further/could gain consensus? I assume that would be a discussion for VPR if/when my idea gets to that point. mdm.bla 16:24, 20 February 2026 (UTC)

I'm more interested in if the bot can go one step further - a bot to simply tag all the citations, or a bot that simply yeets all the citations are straightforward enough - can we technically build a bot that replaces the citation with the original link if it's live, or with archive.org if both have captures? Tazerdadog (talk) 21:35, 20 February 2026 (UTC)

If we're swapping captures the bot would need to verify that they're equivalent. I found one a while back where one had archived an error page and the other the actual content, even though they were very similar dates (a few days apart iirc). Thryduulf (talk) 21:44, 20 February 2026 (UTC)

Currently GreenC_bot's WP:WAYBACKMEDIC tasks are probably the closest actions to what you're looking for, but per Thryduulf the replacement process would have to be more involved in order to satisfy WP:V. InternetArchiveBot is also working on a similar task for dead links. Relatedly, GreenC_bot should probably be stopped from adding archive.today links (courtesy ping @GreenC). mdm.bla 21:55, 20 February 2026 (UTC)

There is no way to do this that can tell if the captures are equivalent, many supposed captures are actually nonfunctional, 404s, or of the wrong content. It will have to all be checked manually. PARAKANYAA (talk) 23:04, 20 February 2026 (UTC)

Manually is ... not going to happen. The biggest manual cleanup I am aware of us completing was 70,000 redirects under CSD X1. I was one of the people who put the most hours into that cleanup. Most of those redirects were decided with single digit seconds of volunteer time. It took two and a half years to finish. This is an order of magnitude more references, and each reference likely takes longer to manually fix than a Neelix redirect took to process. We need at least some automation help here. We can accept a fair amount of errors as better than the alternative, and I'm definitely going to put in some hours personally to get through this. However, there mathematically must be a bot somewhere, even if all it can do is rescue the live links. Maybe a AWB plugin that asks if these are the same website? If we can't get any automation, then we have to mass delete these and eat the hit on verifiability. Tazerdadog (talk) 23:32, 20 February 2026 (UTC)

There is quite simply no automated way to replace the links with other archives and have any reliable rate of accuracy because the other archiving services work completely differently and there is no way for the bot to tell if the content is the same, or even if it exists and is not a 404.

A fair amount of errors for new content introduced is not acceptable. The most automated way that is possible is simply ripping out all of the archive.today links and marking them as dead. Infinitely preferable to linking things that are very likely to not contain the content at all; additionally in many cases the link cannot exist because the other archiving service does not capture the website at all. The archiving bot already only used archive.today as a source of last resort where other archives failed.

Its main use cases are 1) paywall jumping (which we shouldn't have even been linking them for in the first place) 2) javascript heavy or obscure websites that the Internet Archive cannot capture due to technical or request reasons (e.g. there are some fairly major Canadian websites that block the Internet Archive entirely). With 1 we can just remove the archive and deal with the paywall (which is what I have always done, I don't know why everyone is so determined to jump paywalls) but 2 is unfixable. Per WP:LINKROT we are not actually supposed to remove material cited to dead links, though. With news sources we could just remove the link to the original entirely if it is dead, to address that issue. PARAKANYAA (talk) 23:58, 20 February 2026 (UTC)

Yes, WP:VPR would be appropriate if it gets to that point. Anomie⚔ 23:42, 20 February 2026 (UTC)

If the link is alive still, a bot can simply remove the archive. If it is not, then you... cannot just make a new archive capture. So just remove it and tag it as a permadead link. I oppose the usage of the template as it doesn't actually solve any of this. PARAKANYAA (talk) 23:05, 20 February 2026 (UTC)

Having a bot go through and remove all of the instances of archive.today leaving the base link feels like the logical next step then. Tazerdadog (talk) 01:02, 21 February 2026 (UTC)

Well, we should add the dead link tag in the cases where the link is no longer live, but yes. PARAKANYAA (talk) 01:04, 21 February 2026 (UTC)

• In defense of just adding this or a similar tag (+ category) , it gives page watchers and readers, especially those not in the know, an alert to let them know that there's an issue with the source, and that they can help by changing it. How edits that will prompt is unknown to me - however, something I have also thought of is that this is a lot of manual effort, but it's not overly difficult, for probably the vast majority of archive.today uses - if the link is live, remove the archive.today link. If it's not, check archive.org, and replace if possible. If not, then move on to the next citation & circle back later to do the difficult one. Given that, it might be interesting to experiment using that task as one of the newbie onboarding tasks? It's certainly no more difficult than expanding an article section, finding citations for unsourced material, or copyediting -- probably far easier for some newbies, actually. (Just saying, I'm a wee bit shit at copyediting and typo hunting, which is what all of your newbie onboarding pages said to try when I first started) Can't promise it'll be a perfect solution, but it's something relatively easy, yet tedious, and hard to mess up that badly. GreenLipstickLesbian💌🧸 03:53, 21 February 2026 (UTC)

  Instead of having a bot add a tag so we can maybe solve the problem in 12 years, why would we not have a bot just remove all the links and immediately solve the problem? PARAKANYAA (talk) 04:36, 21 February 2026 (UTC)

  @PARAKANYAA Because there's two problems here, both of which are being talked about as though they're the same, but which are distinct:

  a)large amounts of links to website we now know to be an unreliable mirror / website running illicit code.

  b)large amount of material which we can only seemingly verify to an unreliable mirror that we know can, and will, tamper with archived webpages.

  Bot removing links only solves problem A. Having the bot break/hide/render unclicklable all links would also only solve problem A. That would be useful. Bot (your solution) can't solve problem B. Bot solution "remove all links" would rather only mask problem B/move it to the 12+ year backlog. Only humans can solve problem B. Also, only humans can figure out how large problem B is. B will possibly take 12+ years to solve, but, well, that's where we're at. No matter what we call it, the backlog created by problem B exists, and will exist for the foreseeable future. I'm trying to think of ways to solve problem B; like you said, solving problem A is trivial. GreenLipstickLesbian💌🧸 04:55, 21 February 2026 (UTC)

  No matter what we do there are going to be large swathes of material, especially pre-2013, that do not exist on any other archiving service. There is nothing we can do about that, and there is no way for it to be solved. Therefore it is not a consideration. Removing the links will solve "Problem A" and and it will not hinder finding sources for the ones that are still findable. It wouldn't mask it any more than tagging it like this would. PARAKANYAA (talk) 04:58, 21 February 2026 (UTC)

  @PARAKANYAA Tagging it identifies the issue, which is the first step to solve it. Making it appear as though the material is supported by an active, working citation does hide the issue because people see a footnote and go "oh, yes, well, this must be true and verified!" A footnote with a whacking great "better source needed" or "fails verification" alerts people to the fact that no, not everything is okay. And then they can fix it.

  And, yes, material cited only to a website only on archive is is an issue. The citation will be to be replaced or, if you truely can't find that material supported by any other source or sources, online or off, then the material will need to go (the same way you might remove material cited to Fandom a random SNS post) because a)we can't trust it atp and b)the material is likely undue. Not guaranteed, but likely. That is how we solve this problem, though I'm most certainly not operating under the delusion that it will be a quick and easy solve. Now, if you'll excuse me, I'm going to go put on a podcast and fix a few dozen archive today links. GreenLipstickLesbian💌🧸 05:39, 21 February 2026 (UTC)

  That is why I said add the dead link template when you remove it by bot!

  Fixing it manually is a complete non starter. Also, no, per WP:KDL you are not supposed to remove material even if only cited to a dead link: "Do not delete a citation just because it has been tagged with dead link for a long time". You can just remove the archive and tag the dead link, or remove the link entirely and keep the citation. For news outlets especially you should never delete the citation because that is going to exist in an archive somewhere in the world even if not online. PARAKANYAA (talk) 05:52, 21 February 2026 (UTC)

  Great, I'm glad we're still on the same page that a tag of some form is needed; I'm still looking for a solution that will actually migrate these links over to new archives or live, published, citations, however. A bot tagging everything as permanently dead will not do that, though, like I maintained in my first post, it could be useful at solving the other problem. Which is what my post was targeted at?

  And, Parakanyaa, everything will have to be fixed manually, one way or another. I know you think the amount of work makes this impractical; if we're getting that nihilistic, though, ultimately, we will die, our servers will go dark, the sun will consume the rock on which we reside and entropy will take all. For now, though, let's try and brainstorm ways to fix a bunch of dead citations with the least impact possible?

  ... and, um, yes ,the existence of other archives is why I specifically said "online or off", and said only if you truly couldn't find the material supported in other sources, and can't track down a copy of the original source through contacting the original publisher or author, and you've made a reasonably exhaustive search through other potential sources, including primary sources. Ultimately, however, if I scour the entire planet looking for a source to back up the statement "X railroad opened on October 16, 2019", and I can't find one, not even a record tucked away in the office of the government which commissioned said railroad, then I'm challenging either that material's authenticity or dueness. So, as per my last message, not technically "just because it has been tagged with a dead link for a long time", there's a few extra steps. If it's something like a fact about a living person, then those extra steps suddenly start including BLP privacy-related PAGs as well. GreenLipstickLesbian💌🧸 06:42, 21 February 2026 (UTC)

  Also, @PARAKANYAA, per WP:DEADREF (our actual content guideline on the matter, not the how to guide),

  Do not delete a citation merely because the URL is not working. Dead links should be repaired or replaced if possible. If you encounter a dead URL being used as a reliable source to support article content, follow these steps prior to deleting it:

  where step 7 is:

  Remove hopelessly-lost web-only sources

  So. Yep. GreenLipstickLesbian💌🧸 06:46, 21 February 2026 (UTC)

  Well, if we do what you are suggesting, there isn't much brainstorming to do, is there? We pick at this manually for the next decade. Sure. I still do not think the tag is helpful even from that perspective. We cannot make a "new archive link" of a source that is dead; it hides the more dire fact that, as you describe, we are going through the dead reference process and are treating it like a dead reference.

  TIL on that last one. PARAKANYAA (talk) 07:02, 21 February 2026 (UTC)

  Yeah, it's grunt work. Hence brainstorming "is this gruntwork enthusiastic newbies could do, especially given that there's such a high portion of sources still available on the web & an abnormally high amount of source metadata documented here and on archive.is when compared to the deadref category as a whole?"

  I'm not completely sold on the tag's being exactly worded as "new archive link needed" or whatever it is. The problem with having a bot apply the dead reference tag, as you pointed out, the bot can't (or, can't practically and reliably) tell if a an alternative archive was already created for the website, whether on archive.org or elsewhere. I think having a bot tag all articles, then having humans either fix the citation or manually remove the tag and replace it with a "dead link" tag once they confirm that an archive doesn't appear to exist, and only then funnel it through the dead references process, might be more efficient and less disruptive to mainspace content. Or it might not - unfortunately, this is the point where my thought experiment needs more data. GreenLipstickLesbian💌🧸 07:16, 21 February 2026 (UTC)

  Anecdotally -- and I hope this doesn't completely put everybody off the idea -- I got into serious Wikipedia editing with CCI, aka hunting down dead links, unreliable mirrors, and replacing those links and sources on older, untouched, articles. If my newbie homepage had a task like this, I'd have leaped at it, instead of just ignoring it. But I'm not quite narcissistic enough to map that experience onto others! GreenLipstickLesbian💌🧸 07:21, 21 February 2026 (UTC)

  @GreenLipstickLesbian: The tag name is open to wordsmithing, maybe something like [deprecated archive]? mdm.bla 20:32, 21 February 2026 (UTC)

  I'd like that. But, also, please bear in mind that not only am I awful at copyediting, I'm awful at figuring out concise ways to convey a nuanced information in a way that make sense to anybody whose name is not GreenLipstickLesbian! GreenLipstickLesbian💌🧸 20:35, 21 February 2026 (UTC)

  That looks fine to me and seems clear enough as to what the issue is. --Super Goku V (talk) 01:08, 22 February 2026 (UTC)

  Took me a bit, but here is an example: M. P. Castle. As you can see from the last edit before today, one of the sources needed to be fixed by InternetArchiveBot to use an archive.today link last year. If we remove all archive.today links automatically, then this link would be a dead one as http://www.abps.org.uk/Home/Who_Was_Who/index.xalter#C now takes readers to a page that says "The page you are looking for may have been moved or removed." It would leave parts of the article sourced with a dead link and drop this article down to two active sources, both of which are not good for biographies. --Super Goku V (talk) 05:41, 21 February 2026 (UTC)

  Yes, this is going to leave a lot of dead links, regardless of whether manually or done by bot. PARAKANYAA (talk) 05:50, 21 February 2026 (UTC)

  My concern is that automatically going in and removing the links increases the likelihood that articles will have content removed because the link is dead without being checked for a replacement or even lead to articles being deleted. Maybe I shouldn't be concerned this way, but currently I am. --Super Goku V (talk) 05:58, 21 February 2026 (UTC)

  I don't see what difference it would make here if it was done by the bot or a human. PARAKANYAA (talk) 06:04, 21 February 2026 (UTC)

  Scale. It's one thing to fix incorrect content removal when they're following a human and another entirely when they're following a bot. Thryduulf (talk) 01:20, 23 February 2026 (UTC)

I think we can go one step further than this. At the very least, we could remove archive.today links from templates which have |url-status=live. There has been talk of even using the Internet Archive API to automate beyond that; I don't have enough knowledge on the subject to know how feasible that is, but I think removing WP:EARLYARCHIVEs would be a good step. I spent a decent amount of time yesterday removing archival links for live URLs, which could have been saved by such a bot. {{GearsDatapack|talk|contribs}} 00:16, 26 February 2026 (UTC)

Is there a way to follow an article's talk page only? Or is there a way to be notified of new activity on an article's talk page?

Following an article's talk page can keep one up to date with any new discussions or disputes without following the entire article which could lead to excessive notifications. IOHANNVSVERVS (talk) 23:50, 26 February 2026 (UTC)

@IOHANNVSVERVS, see mw:Help:DiscussionTools#Topic subscriptions. You may need to enable it in Special:Preferences#mw-prefsection-editing-discussion. Then go to Tools > Subscribe. WhatamIdoing (talk) 00:06, 27 February 2026 (UTC)

This is only for subscribing to already existing talk page entries/topics though, right? IOHANNVSVERVS (talk) 01:14, 27 February 2026 (UTC)

Slightly lower down on that page is mw:Help:DiscussionTools#Page subscriptions, which I believe is what WhatamIdoing is referring to. It says that you will only be notified about new discussion topics. 45dogs (they/them) (talk page) (contributions) 01:25, 27 February 2026 (UTC)

Oh, brilliant! Thank you, IOHANNVSVERVS (talk) 01:31, 27 February 2026 (UTC)

Yes, thank you. WhatamIdoing (talk) 02:45, 27 February 2026 (UTC)

I know the very existence of temporary accounts is controversial, but let’s assume that allowing people to edit the encyclopedia while logged out or without a permanent account at all serves some useful purpose, such as minimizing barriers to people who can contribute meaningfully. I get all that, but I question whether that extends to user talk pages or other “back of the house” discussions.

So the idea is this: if you don’t want to edit with a permanent account for whatever reason—-great. But your contributions are limited to articles and article talk pages, where there is almost no reason to know what your contribution history is. Let your contributions stand on their own merits. But in other contexts, such as administrative discussions, where the user’s involvement in discussions may be relevant, or on user talk pages, where the user with a permanent account is left wondering whether they’ve ever interacted with this user before, you need a permanent account. Those discussions can seem (or get) pretty personal, and the cloak of complete anonymity lowers the quality of discussions when one user can see an editor’s entire contribution history, and the other’s rolls over every so often.

Thoughts? Dustinscottc (talk) 23:26, 25 February 2026 (UTC)

At absolute minimum temporary accounts need to be able to edit their own user talk pages, and to contribute to project-space discussions about their edits/behaviour. Thryduulf (talk) 00:42, 26 February 2026 (UTC)

In addition, having access to draft space and other user's talk pages is probably a very good idea. This lets them create articles and ask a question to another person. File namespace is probably also a good idea. Tazerdadog (talk) 00:49, 26 February 2026 (UTC)

I could possibly get on board with draft space, but not about other users’ talk pages. I think editors who get more involved with long-term discussions — especially discussions that are inherently targeted at other users — need to be transparent about the kinds of conversations they have had in the past. If you want to be a part of community discussions, I think it’s reasonable to be required to adopt a consistent identity as part of the community. Dustinscottc (talk) 15:51, 26 February 2026 (UTC)

I agree with that, which makes me wonder whether it would be too difficult from a technical perspective. Dustinscottc (talk) 15:47, 26 February 2026 (UTC)

No, it'd be easy: you'd give them access to the Wikipedia: and Wikipedia_talk: namespaces, plus User_talk: because someone could be talking about them in any of those spaces.

So now the list is Main, Talk:, User:, User_talk:, Wikipedia:, Wikipedia_talk:, Draft:, Draft_talk:, and that's probably 99% of edits, so why bother adding restrictions?

Maybe instead of proposing a solution (e.g., restricting edits to certain namespaces), you could tell us what problem you'd like to solve. For example, I see that a TA suggested that you be more civil on an article's talk page – probably referring to this comment aimed at a long-time admin – so now you don't want TAs to be able to leave notes on your talk page. And I'd have to ask: So, do you instead want them to address your behavior in the middle of the article's talk page, where everyone in that discussion will see it? Or at ANI? Or do you just not want anyone to tell you that you were not showing an optimal amount of civility, so you can be shocked when enforcement actions appear? Or maybe you just want someone with a registered account to say it, because it's more impressive if you hear this from someone who spent 15 seconds registering an account than from someone who didn't (or doesn't happen to be logged into their account from the computer they're using)? WhatamIdoing (talk) 19:49, 26 February 2026 (UTC)

No, I’d like to be able to identify disruptive editors. There was no civility problem. Meritless notices are disruptive. When a user is registered, it’s easier to tamp down the disruption by keeping the user accountable for past and future disruptive behavior. When it’s a TA, there’s no good way to identify

The incident that prompted this is not a big deal, but it’s easy to see how it could become a big deal. Minor concerns about single comments can and should be addressed in the discussion where they occur. If users of TAs become interested in policing discussions and trying to enforce Wikipedia norms, then they should sign in. Clearly, there is some value to being able to see a user’s past contributions. After all, you just did it.

And no, my revised thinking is not all the pages you listed. It’s Main, Talk, and their own User talk space. TAs should not even have access to their own page other than their talk space because it’s all temporary anyway. Dustinscottc (talk) 20:26, 26 February 2026 (UTC)

It sounds to me like you agree that if someone posts a thoughtful comment in a discussion, and some guy on the internet who disagreed with that POV responded by saying "Well, I think this comment illustrates that we’re past the serious debate portion of this RM", then this would not exactly make the poster feel like their participation was welcomed and valued by this person. Therefore, maybe there actually was a civility problem.

I agree with you that your comment wasn't a big deal relative to community practices, but there is widespread disagreement about whether minor problems should be addressed in the discussion where they occur. Some people feel like a note on your User_talk: is more private, or that side discussions about behavior shouldn't be placed in main discussions, where they could distract from the discussion or be seen as a way of discrediting your POV. Others are horrified that their less-than-perfect behavior is being highlighted to the people who watch their talk pages, whose respect they want to keep.

Everything's temporary. The median number of days for an active registered editor is 1. The median number of edits made (among those who make any edits at all, which is already a minority) is 2. That's not much opportunity for seeing a user's past contributions. WhatamIdoing (talk) 21:00, 26 February 2026 (UTC)

So first of all, the civility complaint was not about that comment, which I also don’t think violates the civility standards. It certainly is no more uncivil than your list of rhetorical questions above. The comment I was responding to was, intentionally or not, not a serious comment, and was in fact illustrative of the kinds of unhelpful comments that were little more than commentaries about what people think of Elon Musk’s acquisition of Twitter or how X is currently operated. Pointed comments do not present a civility problem. All of which is off-topic. If you want to discuss further, come on down to my talk page.

More to the point here, user talk pages are inherently personal. Access to them is not necessary to allow unregistered users to contribute meaningfully to the encyclopedia, and any benefit is outweighed by the risk of anonymous harassment. Dustinscottc (talk) 21:15, 26 February 2026 (UTC)

On your talk page, you claimed that you didn't know which comment the person was complaining about. But now you do? Which one do you now think they were complaining about?

That TA made 19 edits over the space of four days. Compare that against the Registered editors by edit count: If they'd registered an account for those edits, they'd be in the top 5% of Wikipedia editors of all time by edit count. And I'd bet that they'd still be telling you that they didn't appreciate your comments. (NB that I'm neither agreeing nor disagreeing with them about that; I'm just saying that registration doesn't magically change people's POV on what's polite.) WhatamIdoing (talk) 21:49, 26 February 2026 (UTC)

Editor that made Dustinscottc make this section here. I will do the right thing here owning up to an honest mistake and fully apologise for and admit the fact that that was not their error, it was mine because I accidentally linked the Twitter RM when the WP:NPA was actually on their user page. I explained everything here.

Your other points still stand though. ~2026-12020-63 (talk) 22:31, 26 February 2026 (UTC)

User who added the warning box here. There was a civility problem, please stop lying: . ~2026-12020-63 (talk) 22:19, 26 February 2026 (UTC)

No. SuperPianoMan9167 (talk) 00:59, 26 February 2026 (UTC)

I don’t think anyone believes that granting access to some tools and not others makes unregistered users not human. Unregistered users can’t do some things already. The idea I’m floating would not inhibit the vast majority of useful contributions that unregistered users make, which is to directly contribute to articles. Dustinscottc (talk) 15:55, 26 February 2026 (UTC)

Under your revised proposal, TAs would no longer be able to report vandalism, request page protection, discuss changes to policy, participate in Village Pump discussions, participate in XfD discussions, comment on noticeboards, update file descriptions, create drafts, fix template documentation, revert vandalism to a category page, discuss changes to a help page, etc.

This would absolutely inhibit useful unregistered contributions. SuperPianoMan9167 (talk) 20:32, 26 February 2026 (UTC)

The vast majority of TA edits are to articles and talk pages. What is so unreasonable about asking for a modicum of accountability for the rest? Dustinscottc (talk) 20:35, 26 February 2026 (UTC)

The vast majority of registered accounts have only made edits to articles and talk pages. WhatamIdoing (talk) 21:01, 26 February 2026 (UTC)

I’m not sure I follow your point. I’m not suggesting that registered users should be obligated to do anything other than the same things that TAs could do. Dustinscottc (talk) 21:18, 26 February 2026 (UTC)

The vast majority of TA edits are to articles and talk pages is your excuse for restricting them to those namespaces.

Well, I'm telling you that The vast majority of edits by registered accounts, especially newly registered accounts, are also to articles and talk pages. What's sauce for the goose is sauce for the gander.

More to the point, "accountability" isn't what you get with a free registered account. In fact, with a TA, senior editors can find their IP address, which sometimes means the actual human can be tracked down. That's why subpoenas ask for IP addresses instead of usernames. WhatamIdoing (talk) 21:53, 26 February 2026 (UTC)

No. The reason for restricting them to those spaces is that the risk of disruptive behavior due to a lack of accountability outweighs the potential benefit except in the spaces I’ve mentioned. Senior editors can track down IP information for registered users, so there is no advantage to a TA. Dustinscottc (talk) 23:21, 26 February 2026 (UTC)

IP information for temporary accounts is available to all administrators and to those with the Temporary account IP viewer right accounts (currently 822 and 377 accounts respectively, so nearly 1200 editors and there are also about 276 editors with the global temporary account IP viewer right, although some of them will be included in the first figures).

IP information for registered accounts is available only to checkusers (currently 49 editors) and only in accordance with very strict rules. Thryduulf (talk) 23:39, 26 February 2026 (UTC)

What "lack of accountability"? The TA showed up here and gave an account of what happened and how. That's literally accountability. WhatamIdoing (talk) 23:41, 26 February 2026 (UTC)

But when has the user of the TA done similar things in the past? Does this user have a history of posting frivolous warnings on users’ talk pages? Is there context from prior conversations that indicates the user has some kind of grudge? This is relevant information that is obscured by the use of a TA. And if you don’t think that information is relevant, why did you avail yourself of it with respect to my previous conversations? Dustinscottc (talk) 23:51, 26 February 2026 (UTC)

Being able to check someone's contributions to find out if they're just as "bad" as you isn't accountability. That's "two wrongs make a right" illogic.

If you register a Wikipedia:Clean start, then how would we know if you have done similar things in the past? For all we know, you could have an undisclosed prior account. How would we know if you have a history of posting frivolous (you mean mistaken, right?) warnings on users' talk pages? What's the context from the prior conversations that indicate that you might have a grudge that can only be detected if someone knows your (hypothetical, AFAIK) prior account name? WhatamIdoing (talk) 23:57, 26 February 2026 (UTC)

I’m not suggesting that the value is from making comparisons. It seems like you are injecting a lot of facts regarding a specific incident, which I’m not interested in discussing here. You’re welcome to post in my talk page if you want to talk about that. But speaking globally, yes, registered users may, on occasion, start over. But they do not do so automatically every 90 days or when they use a different device. For a user with hundreds of edits over several years, you can identify patterns and understand their intent by that wider context. While it could sometimes be true with registered users, it is always true with TAs. Dustinscottc (talk) 00:09, 27 February 2026 (UTC)

Sure, for the less than 1% of editors who have hundreds of edits over several years, you can sometimes identify patterns and use that information to guess what's going on.

But for the 99% who don't – a group that included you just a few months ago, BTW – you can't. And that's a lot of editors. For example, you suggest that we need "hundreds of edits" to figure out what's going on with an editor, and before then, they shouldn't be allowed to leave a note at someone else's talk page. Your 75th edit ever was to leave a note on someone else's talk page, complaining about behavior that you felt rejected your participation. Ignoring a dozen edits from many years before, you had effectively been editing for five (5) days when you posted that note. Do you think that someone with five days' experience is justified in communicating directly with an editor? And if yes for you, then why not someone with up to 90 days' experience?

The next day, just a few edits later, you were editing Wikipedia:Administrators' noticeboard/3RRArchive490#User:Dustinscottc reported by User:Newimpartial (Result: Both users and an IP blocked from page for a week). Again, if you have been editing for just a few days and are still well short of the "hundreds of edits" you mention here, but you're justified in responding there (I certainly think you were), then why shouldn't everyone else be allowed to? WhatamIdoing (talk) 00:36, 27 February 2026 (UTC)

I did not say or suggest that one must have hundreds of edits (or any other number of edits) prior to posting on other user talk pages. I am suggesting that users should engage in these discussions in a way that can be viewed over time. The mention of “hundreds of edits” was illustrative, not prescriptive.

But even in your enthusiastic thrashing of the straw man you’ve constructed, I think you’re illustrating my point. For whatever reason, you’ve decided to take the time to dig through my contribution history, going back more than a year. Clearly, that has some value to you. Dustinscottc (talk) 00:47, 27 February 2026 (UTC)

Yes, it has some value. For example, when people say "Oh, IPs/TAs are bad because one did this", it's usually pretty easy to find an example of me doing that myself when I was new, or the complainer doing that when they were new. It's a way of getting some perspective.

Here, you are complaining that someone who edited as a TA for five days left a complaint on your talk page. But functionally speaking, when your registered account was five days into its "real" editing (I do not count you making a single-digit number edits every couple of years beforehand), you did exactly the same thing: you went to the User_talk: page for another editor and told them that you didn't like them calling you a Wikipedia:Single-purpose account just because almost the only thing you had edited was Talk:COVID-19 lab leak theory, where almost the only thing you had to say was that you objected to any connection being made between the idea that COVID-19 leaked from a Chinese lab and rising anti-Chinese sentiment in other countries.

Why is it okay for you complain directly to an editor on Day 5 as a registered account, but not okay for a TA that edits for five days to do the same thing? Sure, you have kept editing since then, so we can have this conversation a year later. But you also could have quit when you got blocked for edit warring (it's a common response), and the rules have to work with the information we have at hand on the day of the complaint, and not with the information we might have a year later. WhatamIdoing (talk) 02:58, 27 February 2026 (UTC)

The warning was not frivolous ~2026-12020-63 (talk) 08:58, 27 February 2026 (UTC)

This would prevent unregistered editors from listing anything on one of the WP:CP subpages or the talk page, which is problematic when we do occasionally get a listing from them. Tenshi! (Talk page) 20:13, 26 February 2026 (UTC)

I had an idea for pages about languages to allow you to go to that language's main page on Wikipedia, it could appear above the article in both English and that language, it would be something like:

This is the English language article for {insert language here}. To browse Wikipedia in {this language}, click here.

Seo an t-artaigil Beurla airson {cuir a-steach cànan an seo}. Gus brobhsadh tro Wikipedia ann an {a’ chànan seo}, briog an seo. GlitchedCheeseSandwich (talk) 18:38, 28 February 2026 (UTC)

I like it, it's possible people search something like "german wikipedia" and arrive at German language Kowal2701 (talk, contribs) 18:59, 28 February 2026 (UTC)

Searching something like "german wikipedia" would actually send you to German Wikipedia, the English-language article about the German-language Wikipedia, not German language.

If something like this were implemented, I think it'd make much more sense to have it appear on articles like German Wikipedia, French Wikipedia, etc. than on articles for languages. Someone searching for a language probably just wants information about that language, not to browse Wikipedia in that language, whereas someone searching for another language version of Wikipedia might plausibly be looking to use that language's version of Wikipedia.

However, I'm fairly sure most (if not all) the articles about different language versions of Wikipedia already link to them in their infoboxes, so I'm not sure a notice like this would be needed on those articles. Arguably, having a bilingual notice could be helpful, but then again if a reader is on, say, the article German Wikipedia and wants to read it in German to help them find a link to the German-language Wikipedia they can just use the languages menu to go directly to the German-language Wikipedia, without having to look for a link to it in the English-language article. – Scyrme (talk) 19:14, 28 February 2026 (UTC)

Robert Carradine is a well-known actor whose death is attracting a lot of attention currently. I first noticed this at In the News where the nomination is already mired in the usual nitpicking – I raised an objection myself. Then, this morning, I see that his article was the top read yesterday with over a million views, along with many other members of the Carradine family. This pattern is fairly typical and Eric Dane got similar attention when he died recently.

As our ITN is not handling this expeditiously, I looked at how it was playing on other projects. Starting with other European languages that I can understand, I found that Carradine had already been posted on the main page of the Wikipedias for French, German and Spanish, along with his picture (right). I've noticed before that they usually get such deaths posted without delay but I'm not sure what their process is and the language barrier makes it difficult to find out. We have pages that likewise get this done quickly such as Portal:Current events and Deaths in 2026 which have already posted the death too. So our ITN is quite an outlier.

Looking further, I checked out Wikidata and found that its main page has a similar section called Related to current events and that this currently lists both Eric Dane and Robert Carradine. I'm more familiar with the internals of that project and so looked at how this was done. It turned out that there's a bot which populates that section of their main page automatically: MsynBot 11. This was created by MisterSynergy and the code is on Github. I'm not sure exactly what its logic is but it seems to work well enough – well done!

We could use something similar here to automatically list such trending topics on the main page. We already have the WP:TOP25 but that requires manual effort, runs on a weekly cycle rather than daily and isn't surfaced on the main page. So, the idea to discuss is that we might borrow this concept and tech to set up something similar here.

Andrew🐉(talk) 11:30, 25 February 2026 (UTC)

Automatically listing popular articles seems like it would quickly run into conflict with a fundamental principle of all of the current main page sections that articles must meet a certain quality standard (in the case of ITN, WP:ITNQUALITY). A bot could automatically avoid articles with major cleanup tags, but ITNQUALITY also advises Articles should be a minimally comprehensive overview of the subject, not omitting any major items. Stub articles are never appropriate for the main page. Articles should be well written with clear prose. Articles which consist solely or mostly of lists and tables, with little narrative prose, are usually not acceptable for the main page, and prose should be in narrative style, not proseline-type writing. – most if not all of these restrictions would be difficult or impossible to automatically enforce. Caeciliusinhorto-public (talk) 17:02, 25 February 2026 (UTC)

There's no such fundamental principle. Many articles linked on the main page have issues and this is especially common in some sections such as the Featured Picture. That's why WP:ERRORS exists. And why the main page has the usual disclaimers. The fact that Wikipedia makes no guarantee of validity is its actual fundamental principle.

Of course, some quality filters might be used by the bot logic, as suggested, and this is commonly done in such displays to exclude spurious articles which seem to be artifacts such as .xxx. For example, see the equivalent Top Read card in the app.

Andrew🐉(talk) 17:14, 25 February 2026 (UTC)

Editors like to have control over what readers see. Periodically someone points out that trending articles are shown in the Wikipedia app. This usually freaks someone out, but it also gives you an answer: If you want that, use the app. WhatamIdoing (talk) 19:32, 26 February 2026 (UTC)

But editors don't control what readers see. Such popular and trending articles are, by definition, the ones which are already being most read. Most readers choose articles themselves using search engines and editors have limited control over those. So, for example, Robert Carradine was the most read article on the English Wikipedia yesterday, even though it has yet to appear on the main page, being still hung up at ITN. It got about ten times the views of the featured article which was a worthy but rather dull topic.

So, the main page listings are mainly for the benefit of the Wikipedia community as they are more likely to read them than the general public. By highlighting what's getting the most traffic, the community is alerted to what's hot and can check that it has not got serious problems such as vandalism. If you're not tracking this then you're working in the dark.

Andrew🐉(talk) 20:57, 26 February 2026 (UTC)

If editors want to see what is currently getting the most traffic, there are backrooms ways to do that already – Topviews, the weekly Top 25 report, weekly most edited article report. The mainpage currently averages about seven million views per day; it's disingenuous to suggest that it's mainly read by members of the Wikipedia community rather than the general public. If you want better ways of tracking spikes in readership, then propose that; that's not what the main page is for. Caeciliusinhorto (talk) 19:57, 1 March 2026 (UTC)

Wikipedia's default warning system (for example, with Twinkle) to problematic editors is an escalating set of five stages. Basically: note, caution, warning, final warning, and then a report for potential blocking. Recent changes reviewers may decide to skip levels, issue single warnings, etc, but the default is five. I feel that's a ridiculously lax standard. Because the harshest sanction we can enforce is to not allow editing, we reserve it for only the most persistent vandals and problematic editors. The problem with that mindset is that the threat of being blocked from editing is not actually a deterrent at all - because what does the bored kid who wants to add "eats poop" to an article care about eventually being unable to continue doing that? I'd like us to default to a three-tier system: caution, warning, block, with a low threshold for reducing that to immediate blocks. For TA's, a 24 or 31 hour block for a few clearly non-constructive edits (or a single egregious edit, such as to BLP articles) should be no big deal and handed out generously. Curious to see what others' thoughts are, especially fellow recent-change patrollers. Matt Deres (talk) 20:38, 3 February 2026 (UTC)

In my view, the reason there are four warnings by default is to encourage assuming good faith. You don't have to issue all four warnings before reporting someone to AIV if the vandalism is particularly egregious. That's what {{uw-v4im}} is for.

Also, this concerns warning templates, so you can probably ask for more input at WikiProject User warnings. SuperPianoMan9167 (talk) 21:07, 3 February 2026 (UTC)

Sometimes, when I've given a {{uw-attempt1}} template to warn a user for triggering edit filters, the editor I just warned gets immediately blocked, probably because of the edit filter auto-reporting that DatBot does. SuperPianoMan9167 (talk) 21:13, 3 February 2026 (UTC)

You may not have to issue all four warnings, but it's also not uncommon to see responses at AIV that the editor has "not been sufficiently warned". That's why I want to address the expectation. And I also want to be clear that I'm not talking about editors that are genuinely struggling with WP's way of doing things. Fuck up a template or a table or something? Well, we've all been there, right? But edits like this and this and this and this and this (those are all items I cleaned up just yesterday) are not editors that are struggling. They know what they're doing and know that they're doing wrong. You don't have to assume anything. Matt Deres (talk) 14:29, 4 February 2026 (UTC)

Five is not the default, but often the maximum. But you are right about the most severe sanction we can impose being the extremely trivial one of not allowing editing of one web site. I've lost count of the number of times that I've pointed out that we can't deprive anyone of their liberty for a minute or fine anyone a cent/penny. Despite the fact that I dont care about being blocked (or maybe because of it) I never actually have been. A bit sad, really. Phil Bridger (talk) 22:02, 3 February 2026 (UTC)

• I don't see how taking these tools away from recent changes patrollers would be useful. When an administrator at AIV says a user was insufficiently warned it's not because the administrator is blindly counting the number of warnings. They're taking the user's behavior into account. It's very, very, very common to see users blocked at AIV based on far fewer (or sometimes zero) warnings. The bot removes blocked users from AIV quickly, so most of these are invisible unless you're looking at the page history. Similarly, recent changes patrollers are not blindly applying warning levels. We take the user's behavior into account, and regularly skip levels, start on a higher level, or report at a lower level, based on what's appropriate. A maximum of two warnings prior to a block is unnecessarily aggressive. Recent changes patrollers are competent enough to report users to AIV after an appropriate number of warnings (whatever that number may be), and administrators are competent enough to act solely based on a user's behavior (and not whether they've received exactly 4 warnings). There's no problem here to be solved. --tony 15:03, 4 February 2026 (UTC)

  +1 Took the words right out of my mouth, absolutely agree with everything here. – LuniZunie_(talk) 12:01, 6 February 2026 (UTC)

• I'm not sure what problem we'd be trying to solve by discouraging or preventing editors from issuing good faith notices that are at least as informational as they are actual warning. For instance, most new editors have no idea that WP:FILMPLOT exists, and as such there's Template:uw-plotsum1, and for repeat offenders, Template:uw-plotsum2. Are we going to say that editors are no longer allowed to issue that notice, which doesn't just tell an editor that they violated plot summary guidelines, but also provides some explanation and links to other relevant guidelines? DonIago (talk) 18:22, 4 February 2026 (UTC)

  Nobody is suggesting that we block people for adding too much verbiage to a film plot. Why bring that up at all? I'm talking about deliberately nonconstructive edits: deliberate factual errors, libel, vandalism, etc. Matt Deres (talk) 14:33, 5 February 2026 (UTC)

  Repeatedly violating WP:FILMPLOT is disruptive editing, so it is germane to the conversation. DonIago (talk) 21:00, 5 February 2026 (UTC)

  Not really. If you give someone four templated warnings for overly detailed film plots then report them to AIV, I'm not going to block them, and I wouldn't if the warning sequence was changed. HJ Mitchell | Penny for your thoughts? 21:04, 5 February 2026 (UTC)

  It's encouraging to me to have an admin acknowledge that they wouldn't block an editor who was repeatedly violating a guideline and presumably refusing to communicate about it. DonIago (talk) 21:26, 5 February 2026 (UTC)

  As a general rule, I only block from AIV if it's bad faith. For anything else, it needs to go to a venue where they have a chance to defend themselves. I might make an exception if they're really persistent and you've explained in plain English and without templates what the problem is. But templating someone for adding their favourite plot point to a film article is biting the newcomer, which is more harmful than the edit itself. HJ Mitchell | Penny for your thoughts? 21:32, 5 February 2026 (UTC)

  My apologies, it seems, unlike my usual pattern, I didn't read your prior message literally enough. I wouldn't take someone to AIV for plot summary issues because that's not vandalism. If it was on the same article repeatedly that would likely be a 3RN problem, and if it was multiple articles it would be ANI most likely. DonIago (talk) 21:39, 5 February 2026 (UTC)

  There's a warning template for basically every kind of disruptive editing, including MOS violations. I imagine {{uw-mos4}} doesn't get used very often. SuperPianoMan9167 (talk) 21:03, 5 February 2026 (UTC)

• Oppose Left unchecked, punishment generally drifts towards being more severe over time. People get accustom to a punishment, and think that someone deserves worse, implements such new punishment, and then the cycle begins again until it becomes so cruel and ridiculous reform becomes necessary. Organizations left to their own devices will grow their bureaucracy, policy, and rules until it becomes so unwieldy it crumbles, but in the mean time people are forced to follow those rules or face increasingly harsh punishment. I would like us to move away from total "block" being the default, we are to quick to resort to exile. Other sanctions that are less severe, with time limits, should be developed and implemented.

GeogSage ^{(⚔Chat?⚔)} 00:14, 5 February 2026 (UTC)

If you think temporarily disallowing someone from editing a webpage in bad faith is in any way on some slippery slope to cruelty, I can only suggest you touch grass. Not getting to add "Did you know my ess has many many nooks and cranny" to an article is not a punishment at all and blocking that person has had zero negative repercussions for anyone. Matt Deres (talk) 14:46, 5 February 2026 (UTC)

• I've long thought (as one of the most active admins at AIV) that we give too many chances, especially for spammers (who are not bored kids and really should be blocked on sight). It's worth having the flexibility that the current warnings offer, but there's absolutely no need to go through all four in order. I'll happily block after level 3, or if you skip from 1 to 4; feel free to start at 3 and report on the next edit if there's no way it's good faith (like most of Matt's examples). But for borderline cases, it's nice to have level 1 for "that might have been a mistake" or "I'm not sure what you're trying to do". Level 2 is more "maybe you don't know it but what you're doing is disruptive", and level 3 is "no seriously, you need to knock it off now". I'd happily get rid of level 4, which is essentially level 3 but more so. HJ Mitchell | Penny for your thoughts? 19:06, 5 February 2026 (UTC)

  The question is, why do people habitually give out all four warnings for obviously bad-faith edits? Do they image it's policy? Or are they just on autopilot, and following the Twinkle/Huggle defaults? Suffusion of Yellow (talk) 20:21, 5 February 2026 (UTC)

  I think Huggle and similar are programmed to just escalate until they get through all four. There's basically no human intervention other than pressing the "vandalism" button. I think Twinkle will suggest a warning level but the user can override it with an extra click or two. A lot of inexperienced users feel they have to go through all four warnings before they can report; I thought that when I was new. HJ Mitchell | Penny for your thoughts? 20:34, 5 February 2026 (UTC)

  Does the number indicate A) the level of severity of the combined edits, or B) the amount of times someone did something naughty.

  If its A, and I think it is and should be, we don't communicate that clearly. Polygnotus (talk) 21:03, 5 February 2026 (UTC)

  Definitely A. At least that's the way it should be and I suspect the way it was always intended to be. HJ Mitchell | Penny for your thoughts? 21:07, 5 February 2026 (UTC)

  @WhatamIdoing What do you think? Polygnotus (talk) 21:19, 5 February 2026 (UTC)

  That's certainly how it's defined at WP:UWLEVELS. DonIago (talk) 21:21, 5 February 2026 (UTC)

  The first question is, do people habitually give out all four warnings for obviously bad-faith edits? Certainly some people do, especially if they are doing simple Wikipedia:Recent changes patrol work, but others probably don't.

  With counter-vandalism tools, escalating levels are automatic. You don't see the vandal/spammer/whatever's talk page, so you don't know if there were prior problems. In that sense, it's definitely (B) in practice, even if it "should" be (A).

  One difficulty with decreasing the levels is that notifications aren't always seen or read immediately. Consider this sequence:

  • Van Vandal vandalizes article A.
  • Van Vandal opens article B to vandalize it.
  • Dave Defender sees the vandalism to article A, reverts it and leaves a warning.
  • Van Vandal posts the vandalism to article B.
  • It's only now – with two articles vandalized – that Val Vandal has any chance of seeing Dave's warning. But someone may well see the vandalism in article B, and notice that the warning's timestamp precedes the timestamp for the article B edit, and be angry that Van Vandal was vandalizing after (and in spite of) being "previously" warned.

  And that's assuming that all warnings are correctly delivered. Sometimes a warning for "vandalism" is actually someone correctly removing poorly sourced or erroneous information. WhatamIdoing (talk) 21:58, 5 February 2026 (UTC)

  @WhatamIdoing See WP:VPT#Stats on vandalism template usage for a quick first exploration (more research required). Polygnotus (talk) 22:11, 5 February 2026 (UTC)

  With counter-vandalism tools, escalating levels are automatic. You don't see the vandal/spammer/whatever's talk page, so you don't know if there were prior problems. Only with some countervandalism tools. One thing I like about Twinkle is that when you revert an edit with it, it redirects you to their user talk page (so you can see previously issued warnings). Granted, doing this on mobile is tedious, as I have to repeatedly close the auto-opened edit window to access the warning templates from the TwinkleMobile menu, but I do get to see if there have been any prior issues with the editor. SuperPianoMan9167 (talk) 22:12, 5 February 2026 (UTC)

  Offering a choice instead of simply incrementing may be a good feature request. Polygnotus (talk) 22:14, 5 February 2026 (UTC)

  Already implemented in Twinkle: I can choose "auto-select warning level" or a specific level. SuperPianoMan9167 (talk) 22:16, 5 February 2026 (UTC)

  Programmes like Huggle just show the user a diff and they select one of several options. If they select vandalism, the programme reverts the edit and drops the next warning in the sequence without any human involvement. The human could be two or three diffs further on by the time the programme has left the warning. HJ Mitchell | Penny for your thoughts? 22:18, 5 February 2026 (UTC)

  I'll note that (at least some) counter-vandalism tools are continuously evolving; WP:WikiShield, a "descendant" of WP:Huggle, does have a setting to allow the user to choose the warning level or have it selected automatically. I haven’t used Huggle or WP:AntiVandal recently and can't remember if they have similar settings. ClaudineChionh (she/her · talk · email · global) 03:38, 6 February 2026 (UTC)

  Yeah this is the exact reason I have the settings. I sometimes find myself skipping straight to level 2 or level 3, as it all depends on the context of the edit.

  AV has the same, but I don't think HG does. – LuniZunie_(talk) 12:04, 6 February 2026 (UTC)

  Notified: Wikipedia talk:WikiShield, Wikipedia talk:AntiVandal and Wikipedia talk:Huggle/Feedback. ClaudineChionh (she/her · talk · email · global) 03:47, 6 February 2026 (UTC)

  Interceptor is another that allows users to see prior warnings. I oppose the changes proposed because having 4 warnings can be helpful, especially when an edit looks like vandalism but was actually good faith. As an aside, yesterday I dealt with a vandal on Wikiversity, who made 19 edits before being blocked, all vandalism, and they included adding "I am a vandal" in Ukrainian. They were blocked for 5 days, and after they trolled their talk page so much that their talk page was deleted, they had TPA revoked and their block extended to 2 weeks. I'm not sure if there's a lesson to be learned ("someone will always AGF more than you"?), or if I just wanted to rant. Anyway, I support assuming good faith and oppose unnecessary blocks for vandals who might well just stop anyway. lp0 on fire () 11:29, 6 February 2026 (UTC)

There is also some degree of minimizing sysop workload. Many vandals get bored quickly so will stop on their own after a few edits. A higher threshold limits reporting to cases that most likely need a block. And of course, gross-vandalism, obvious socks, LTAs, etc. can be reported with no warning at all. ~2025-41540-19 (talk) 04:53, 12 February 2026 (UTC)

I generally ignore levels of warnings, and go directly to an appropriate one (currently I use Twinkle), regardless of what has gone before with a particular case. Admins who have dealt with vandalising users after my warnings have never made any comment on this behaviour, and I've been doing it for years. Hand wringing on this issue seems a little pointless as a vandal is a vandal. I've got here from ClaudineChionh's notification notified above. - Walter not in the Epstein files Ego 16:44, 16 February 2026 (UTC)

Same. If someone's engaging in unambiguous vandalism or throwing personal attacks around, I see no reason to give them the 'good faith' notifications. They know what they're doing. DonIago (talk) 03:08, 17 February 2026 (UTC)

I think we should keep it because there are situations where a new editor (who doesn't know or fully understand the rules) and/or an editor with good/misguided intentions should be shown leniency; only a persistently problematic and/or knowingly malicious user deserves harsh and/or immediate sanctions. QuisEstJoe (talk) 20:51, 27 February 2026 (UTC)

I'm a new editor on here, so I may not have as much skin in the game as all the other editors here.

That being said, I think it's better to assume good faith and stick to the 5 strike system, because from what I understand, there's 4 tiers of warning before a report, and then one special tier for particularly egregious cases that may warrant more immediate action, which seems like a good solution. Speaking as a newbie editor: I'd (personally, at least) appreciate a little leniency and decency from the more experienced editors, like whenever I'm editing something and they catch something I did wrong, they can point to a policy I've neglected or violated; learning and reading all the policies is at times quite daunting and a little overwhelming, to be completely honest here. Ediot (talk) 03:16, 2 March 2026 (UTC)

Wikipedia is not a bureaucracy and Our social policies are not a suicide pact. The problem of biting newcomers will not be solved by requiring adherence to the five strike system. How much leniency we should show to editors who have made problem edits is conditional on how damaging such edits are to the encyclopedia and what evidence is available as to the intentions of the editor. Some edits are very obviously intended to harm the encyclopedia or attack other users, and the assumption of good faith can be very short-lived. We have to trust the judgement of our fellow Wikipedians in dealing with problem edits and allow leeway in imposition of warnings and, for administrators, blocks, unless and until an editor or admin demonstrates that their judgment on warnings and blocks is out of step with the community. Donald Albury 13:47, 2 March 2026 (UTC)

Hi! I saw in Village Pump (proposals) that User:SunDawn said Today's Google Doodle is about Winter Olympics, a Google logo but the Os are replaced with a puck and a hockey stick, a funny thing. It still appears as that when I searched about "holocaust" and about "Putin invasion". Both are very serious issue and Google is not changing their look for such matter. and I wondered... could we add a mechanic where on a genocide-heavy page, the baby globe would appear, but then be scared away by the topic? Thanks!

P.S. If this is the wrong place to discuss this, please tell me. SeaDragon1 (talk, contributions) 14:29, 24 February 2026 (UTC)

This seems yet more frivolous than the example that SunDawn was complaining about, and thus yet more offensive. Add to that that it would require a fair amount of effort to implement and this idea seems fundamentally unworkable. _signed, Rosguill ^talk 14:33, 24 February 2026 (UTC)

Oh, okay. Just thought it would be kind of cool. SeaDragon1 (talk, contributions) 14:36, 24 February 2026 (UTC)

This implies that the baby globe manages to keep absolute perfect composure at genocide, war crimes, dictatorships, and other horrors of man. I wouldn't want to have to face him in a match of poker. ~2026-11404-95 (talk) 15:04, 24 February 2026 (UTC)

What I meant was:

The Baby Globe (if it appeared on ALL pages) would be scared by the title and flee off to... wherever.

Or cry. That works too. SeaDragon1 (talk, contributions) 16:17, 24 February 2026 (UTC)

The VPP discussion got long and difficult to navigate, but don't worry, baby globe will be OK. The baby globe will only appear on a pre-determined set of articles, not every article. (The exact list of articles can be found on Meta-Wiki if you know where to look, but I haven't been sharing this list so as not to spoil the surprise.) ClaudineChionh (she/her · talk · email · global) 22:29, 24 February 2026 (UTC)

I think your idea is kind and foundamentally right in theory but i see this as hard to implement in practice Madotea (talk) 16:56, 1 March 2026 (UTC)

I am in agreement with @Madotea for this, implementing this feature would take a lot of unnecessary templates and code complexity, and would almost guarantee that every single page relating to any form of atrocity would end up with a Wikipedia:TURQUOISELOCK. ~2026-11404-95 (talk) 14:01, 4 March 2026 (UTC)

Also, the "Baby Globe Fear" module would be a big pain to fix, not only because of how complex it would be, but because of the fact that it would get a Wikipedia:PINKLOCK before you can say damn you Red Baron! ~2026-11404-95 (talk) 14:04, 4 March 2026 (UTC)

I meant like how the baby globe appears on pages, right? Well, maybe if the globe appears on a... let's call them no-no pages for now. Anyways, if the globe appears on a no-no page, then it plays a video (which is literally just what the baby globe is) of it getting scared and running away, then delete the <video> element.

Pseudocode:

if (fearPages.includes(pageName))
{
    let video = document.createElement("video");
    video.setAttribute("loop", "");
    video.setAttribute("src", `/w/extensions/WP25EasterEggs/resources/media/video/scared-${mode}.webm`);
    video.setAttribute("style", "width: 100%;height: 100%;object-fit: contain;");
    easterEggContainer.appendChild(video);
}

SeaDragon1 (talk, contributions) 22:21, 4 March 2026 (UTC)

What about a template made for each page, just as a guide for beginners? We could also try to strengthen existing security measures for account saferty. An auto-deletion bot checking articles for AI usage, or deleting innacurate information may also be in order. ~2026-13727-27 (talk) 07:22, 7 March 2026 (UTC)

Who would decide what is inaccurate? Phil Bridger (talk) 09:24, 7 March 2026 (UTC)

You'll need to elaborate on your idea before you post it here. For your 3rd concern there is already a bot on Wikipedia woaharang (talk) 09:24, 7 March 2026 (UTC)

There are many bots on English Wikipedia, unless you mean that there's an adminbot that deletes AI articles that I haven't seen? Tenshi! (Talk page) 11:24, 7 March 2026 (UTC)

I had recently dropped a PROD on the Yamaha RX-Z article which was removed by a temporary user. You can check the diff here. I propose that we implement a check which allows only registered editors to remove a PROD template to prevent abuse of WP:DEPROD. woaharang (talk) 09:23, 7 March 2026 (UTC)

How does knowing how to create a userid relate to accuracy of a removal? Phil Bridger (talk) 09:29, 7 March 2026 (UTC)

The editor removing the prod can be held accountable for the edits he made! woaharang (talk) 13:24, 8 March 2026 (UTC)

As anyone can remove a prod for any reason, what would be the point of looking at their other edits? If someone is creating an account, temporary or registered, to avoid a block or scrutiny of previous edits, we have policies and guidance to deal with that. Donald Albury 13:51, 8 March 2026 (UTC)

That any user can remove a PROD is a feature, not a bug. The only potential issue I see here is that neither the PRODder nor the DEPRODder left a descriptive edit summary. —Kusma (talk) 10:37, 7 March 2026 (UTC)

If someone removed dozens of prods in a couple of minutes, that would suggest abuse. But a single removal is not abuse. Use AFD if required. Graeme Bartlett (talk) 11:22, 7 March 2026 (UTC)

In fact the opposite is true: PROD is misused by unregistered accounts who don't know our deletion policy because PRODing is much less complicated than sending an article to AFD (especially since unregistered accounts are unable to directly create AFD discussion pages!), even though PRODs receive less scrutiny than AFDs. Helpful Raccoon (talk) 06:11, 9 March 2026 (UTC)

There should be a way to search by category with a higher depth. e.g. incategory:"Cities in Australia" doesn't give any results, because it only has subcategories. There should be a way to search within all of these subcategories in e.g. Cities of Australia at once. ChaoticVermillion (converse, contribs) 03:14, 28 February 2026 (UTC)

If you replace incategory: with deepcategory:, that will search subcategories to a depth of five: see mw:Help:CirrusSearch#Deepcategory. Alternatively WP:PetScan allows you to specify an arbitrary depth. Cheers, SunloungerFrog (talk) 07:09, 28 February 2026 (UTC)

 This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 18:07, 9 March 2026 (UTC)

I had a page that I decided to db-g7 and when it was deleted, I had an urge to thank them, but I don't see an easy way. Could something be added to enable thanks for things like page creation, page deletion, moves, protection addition or removal, etc. I'm expecting that would be technically complicated, but I thought I'd drop the idea here.Naraht (talk) 20:04, 3 March 2026 (UTC)

Deletions (including speedy deletions) are logged at Special:Log/delete, and you should be able to thank the deleter from there. mdm.bla 20:07, 3 March 2026 (UTC)

Or you could post your thanks about anything to the user talk page. It's not hard. Phil Bridger (talk) 20:15, 3 March 2026 (UTC)

Page creations can be thanked for via going to the page revision history and selecting the first diff. I don't think protection addition or removal is sth that should be thankable except for say creation of discussion regarding the protection status or similar (which can be thanked). Prototyperspective (talk) 18:07, 9 March 2026 (UTC)

what im suggesting is a mode where everything appears like your reading a book in a library, it firstly, citations and links flat out don't work, to check citations, you actually have to go to the cites page and links would be like being told to buy this other book, or you could make links and work but lets assume not, you would view articles in pages, swipe to go to a page on the left or right, the first page would be the cover, it show the title, (article name) author, (article creator), writers, (recent editors), publisher, (wikipedia) A [all categories of that article], (categories for that article) and more, i think long infoboxes should be their own page, you could also swipe down or press a button on top to close that book, then you could explore a library of books that are articles, i do think the library idea is unrealistic (?) so i think it is better to have a normal searchbar (?) Misterpotatoman (talk) 06:00, 27 February 2026 (UTC)

This feature would be extremely complex, and would almost instantly get a Wikipedia:PINKLOCK. Maybe it should be a feature just to turn off links? ~2026-11404-95 (talk) 15:14, 4 March 2026 (UTC)

Help:Printing Misterpotatoman (talk) 21:36, 6 March 2026 (UTC)

Why would anyone want the citations and links to not work? I sort of understand where you're coming from on the pages part (kind of like having an e-book), but I don't see the point of making people manually copy and paste citations into the URL bar to check the sources for accuracy. And hyperlinks are a main part of what makes Wikipedia so useful.

Sentimental Dork (talk) 23:21, 9 March 2026 (UTC)

If the idea is replicating an e-book perhaps the idea is to keep everything in black and white? Probably something any book view could handle via css. CMD (talk) 01:42, 10 March 2026 (UTC)

I really like that users now have the option to view Wikipedia in dark mode. However, the background is pure black. This is a good thing to some people, but for a lot of people the high contrast between the black background and white lettering can cause eye strain. For me, I don't like looking at Wikipedia's dark mode because it makes my eyes feel weird. This isn't really a problem because I usually prefer light mode anyway, but it would be nice to have a dark mode to switch to at night that's comfortable to look at.

My proposal: a third mode, where the background is dark gray or a low-saturation navy, and text is a slightly more muted shade of white. Several sites have a default dark mode that looks like this, and then a separate mode where the background is pure black. I feel like lots of people would appreciate a dark mode without such high contrast.

Sentimental Dork (talk) 23:16, 9 March 2026 (UTC)

I don't know if there is an easy way to do this unless you can switch to a different skin with darker colors at night. The way dark mode works (as I understand it) is that the whole page is inverted, then things that shouldn't be inverted are un-inverted (like images). -- Reconrabbit 17:31, 10 March 2026 (UTC)

The dark mode gadget does that. The dark mode that is part of the Vector2022 skin uses a color palette and sets it based on which mode is in use. Users can override those colors in their personal common.css file, but you need to be comfortable with CSS to do this (for anyone interested, see mw:Recommendations for night mode compatibility on Wikimedia wikis § Target night mode using standard media query as well as HTML classes and mw:Recommendations for night mode compatibility on Wikimedia wikis § Use CSS variables or CSS design tokens with fallback for background and text where possible). isaacl (talk) 17:53, 10 March 2026 (UTC)

I just have a small idea. I think the section "Other areas of Wikipedia" on the main page is too small and might get missed by people trying to navigate around Wikipedia pages (not articles) Perhaps this idea might help?Robloxguest3 (talk) 20:22, 10 March 2026 (UTC)

You've certainly not the first to suggest such an idea. The issue is that nobody's ever actually agreed on what a good solution would be.  novov talk edits 00:35, 11 March 2026 (UTC)

Perhaps just making it bigger? Or squeeze it in at the top of the main page Robloxguest3 (talk) 21:00, 11 March 2026 (UTC)

I Support it. However, I believe that before making any visual changes, it is necessary to discuss the actual purpose of the section to avoid changes without a clear direction and discuss this at Template talk:Other areas of Wikipedia or Talk:Main Page. {{Other areas of Wikipedia}} and {{Wikipedia languages}} are the only sections of the main page without a visual appeal, and Other areas of Wikipedia is the only one with a non-centered alignment, not that this is a problem, but it is worth noting, the problem, I believe, is the link to outdated sections such as the Portal Space.Guilherme Burn (talk) 12:32, 12 March 2026 (UTC)

I have a idea for new 2 namespaces, "Disambiguation" and "Disambiguation talk" namespaces. All disambiguation pages (and their talk pages) will go to this namespace. ~2025-42974-91 (talk) 19:58, 12 March 2026 (UTC)

What advantage over existing practice would this give? AndyTheGrump (talk) 19:59, 12 March 2026 (UTC)

I suppose it would allow disambiguation pages to coexist with a mainspace article of the same name in cases where there is both a most common use of the term but also multiple alternate uses, (so Table (furniture) could become just Table and the disambiguation page would move to Disambiguation:Table)

Whether this is a desirable state of affairs is an entirely different matter. Athanelar (talk) 16:43, 14 March 2026 (UTC)

We can already do that if we want, for example Chair and Chair (disambiguation). Anomie⚔ 18:53, 14 March 2026 (UTC)

If we were designing Wikipedia from scratch today then maybe we would implement this and maybe not. With the current state state of affairs I can't see that this would be worth all the upheaval. Phil Bridger (talk) 19:06, 14 March 2026 (UTC)

I'm new here, sorry.

A well-filtered dataset taken from Wikipedia contains about 200,000 architectural objects from all over the world.

You can check it out here (filters by architects, style and era are available):

https://apalladio.org/architecture-around/

This is not just a Wikidata issue, as 99% of objects have a link to a Wikipedia page, a description, and so on.

Here is the entire database (SQL dump):

Github: https://github.com/MyropolskyiHennadii/ArtefactsLocation-data

Zenodo: https://doi.org/10.5281/zenodo.18955341

There's also a Java model: https://github.com/MyropolskyiHennadii/ArtefactsLocation-model

The question is: if it's interesting and useful, how do you use it properly in a wiki? Myropolskyi (talk) 13:02, 11 March 2026 (UTC)

Really interesting map / app! I just wished this was possible within the standard Wikipedia app. Then more users could make use of this and learn about this as many have that app installed or install it for other reasons. Additionally, it gives people more reason to install the Wikipedia app. I think this could be made possible along with various other things if this wish was implemented whose potential I think is still not understood: W295: Filters for types of items shown on the Wikipedia app Nearby places map.

Could you upload some helpful images or ideally videos of what this webapp & mobile app can be used for and/or how to use it? I'd add them to c:Category:Wikimedia projects and maps. Prototyperspective (talk) 15:22, 11 March 2026 (UTC)

Ok, thanks. I'll try to do it in a (next) week. Not sure about video:) Myropolskyi (talk) 15:47, 11 March 2026 (UTC)

@Prototyperspective

Hi!

I'm not sure, that it is the best video, but I created it.

https://www.youtube.com/watch?v=7X9ptSoZOU4

And thanks in advance.

If something more would helpfull or you have questions - you are welcome. (And I supplemented the dataset-project by presenting a description of the methodology) Myropolskyi (talk) 15:55, 16 March 2026 (UTC)

It's useful, thanks. Would be best to also upload it as a webm to Commons and then adding the video to a new wiki page about the tool. Prototyperspective (talk) 23:41, 16 March 2026 (UTC)

@Prototyperspective

Sorry, I'm new here.

Could you please explain to me more precisely what I need to do (where I should create the new wiki page and where exactly "Commons" is located)?

Thanks Myropolskyi (talk) 06:14, 17 March 2026 (UTC)

The documentation page about the tool/site could be here on English Wikipedia or metawiki. Commons is here and the upload form for the webm video (you may need to convert it to webm) here. Prototyperspective (talk) 12:10, 17 March 2026 (UTC)

Thank you. Done.

https://meta.wikimedia.org/wiki/Architectural_Heritage_Map Myropolskyi (talk) 14:36, 17 March 2026 (UTC)

So... this basically shows buildings, artworks, etc. on a map. When you click on an item, you see the name and some of the Wikipedia article. Items are mostly located in Europe. For example, the entire Chicago area, home to almost 10 million people and many world-class museums, had about 8 (eight) points of interest.

I'm not sure how it could be useful within Wikipedia. However, editors at Wikivoyage might find it useful for finding attractions in a similar area. WhatamIdoing (talk) 17:28, 11 March 2026 (UTC)

@WhatamIdoing

I do not know, where do you find 8 items. I see 423. If editor allows images, I can set screenshot, but it does not allow me do that.

If you are using android version - you can go to app-settings and set radius more high. Or just move the map and app suggests you to refresh object. (Check on web-version)

And by the way: it is not about museums at all, it is not about POI, banks, theaters and so on. It is about architecture. Only. You are walking through Chicago and seeing 423 items.

Maybe it is not enough for Chicago, but that is what has been found in wikipedia itself for now WITH architectural STYLE. Myropolskyi (talk) 17:41, 11 March 2026 (UTC)

The mobile app has something similar (iOS; Android), idk whether @User:JTanner (WMF) would be interested? Kowal2701 (talk, contribs) 19:18, 11 March 2026 (UTC)

@Kowal2701 @WhatamIdoing

Sorry, I did not understand what do you mean with "something similar".

Just in case, I've uploaded screenshots to the project, because I can not show them here.

One is for Chicago in the Android app, the other is for the web app.

In the Android app, we see about 70 objects (within a 3 km radius), while in the web app, we see 483 (within a 10 km radius).

Android app screenshot:

https://github.com/MyropolskyiHennadii/ArtefactsLocation-data/blob/main/20260311_202356_Architecture%20Around_android_Chicago.jpg

Web app screenshot:

https://github.com/MyropolskyiHennadii/ArtefactsLocation-data/blob/main/2026-03-11%2020_41_35-Architecture%20Around%20-Chicago.png

I recommend using the Google Play app for Android:

https://play.google.com/store/apps/details?id=myropolskyi.android.locations&pcampaignid=web_share

In the web application, there is an "I" icon in the upper right corner, it will show you the legend (including the number of loaded objects).

And if you still only see eight objects in Chicago, I have to ask, sorry: are you viewing the web version on your phone?

Have you tried changing the zoom level? If you're zoomed in at 500-1000 meters, you might very well only see eight objects, why not? Myropolskyi (talk) 20:13, 11 March 2026 (UTC)

Sorry for not being clear, I was talking about a similar feature on the mobile Wikipedia app Kowal2701 (talk, contribs) 20:18, 11 March 2026 (UTC)

Please see my comment above regarding that. Prototyperspective (talk) 21:14, 11 March 2026 (UTC)

If only I could read Kowal2701 (talk, contribs) 21:31, 11 March 2026 (UTC)

Hey all (@Kowal2701, @Prototyperspective and @Myropolskyi, for those that don't know me Joseph Seddon, an Engineering Manager with Mobile Apps teams (and User:Seddon in my volunteer time). Firstly just wanted to say I love seeing any and all examples where people do cool and interesting things with data and content. That in an of itself is great.

@Prototyperspective thanks for noting that Community Wishlist item about improving and @Kowal2701's thanks for highlighting the idea about whether this might fit the mobile apps.

We try to keep the apps small in size because mobile data and internet speeds are still an issue for many in the world. This dataset alone would have a big impact on the apps size. We largely use API's to serve and support the features in the apps, in particular the Nearby feature.

In this instance the Nearby feature is powered by https://www.mediawiki.org/wiki/API:Geosearch which isn't maintained directly by the mobile apps teams. Whilst its certainly theoretically possible to build the feature on the client, it would require a lot of API calls and processing on device.

I think the ideal outcome would be to see how we might be able to add filters and context to Geosearch itself. Would you be okay with me updating https://phabricator.wikimedia.org/T360197 to reflect that? Seddon (WMF) (talk) 09:34, 18 March 2026 (UTC)

The size wouldn't really increase because the dataset is not contained in the app but just queried by the app (Nearby Places map). I don't think it necessarily/intrinsically would require many API calls. I don't know which update you'd like to make to that phab issue I filed; maybe a comment would be more suitable but I guess probably it would be fine. I didn't mean the app should or could have the exact same thing as currently in this app here – things would look and function a bit differently so e.g. probably you could not filter by architect since very few people are looking / would use that but one could filter for architectural buildings and maybe eventually somehow filter and/or add labels for architectural styles or things like that. Filtering for architecturally notable buildings would be just one way to use that; it would be great if this was possible within the app along and integrated with other ways to use filtering. Personally, I'd use it heavily whenever I visit a new city to see additional spots of interest nearby while exploring the city. The app currently can't be used for that albeit there is a lot of potential if just some filtering was possible (the more the better because then one could personalize it further to one's interests). Prototyperspective (talk) 13:48, 18 March 2026 (UTC)

The size wouldn't really increase because the dataset is not contained in the app but just queried by the app (Nearby Places map).

Indeed, my suggestion is that the way forward for doing this is to make improvements to the existing GeoSearch API which is what actually powers the Nearby feature on the apps. It not something our team owns and so I think the next is either to update T360197 or create a subtask detailing what improvements would need to be made. Seddon (WMF) (talk) 11:58, 19 March 2026 (UTC)

Thanks for clarifying – please go ahead with creating a task linked to that one about what would need to be done / is required for that task or change that task if you think that's the better approach. Prototyperspective (talk) 13:24, 19 March 2026 (UTC)

It's hard for me to judge, since I don't know how everything is set up for you.

But judging by Prototyperspective's response, the application accesses the server "as usually", and increasing the size of the database itself won't cause any noticeable slowdowns in the application's performance.

Indeed, architectural objects can be displayed based on user settings/filters: whether he wants to see them at all.

And I agree that filters by architect and period are unlikely to be frequently used; they're too specific. Furthermore, they're not as "clear" as filters by category.

One thing to consider when using a dataset is that I don't plan to stop working with the database at all in the next two years, so updates are possible.

I don't think there will be many, and I can't guarantee there will be any, but two or three updates are entirely possible.

(I mean: consider the possibility of reloading/updating the database. Here, we need to focus, of course, on the primary indexes of the tables; they have never changed and will not change, but other fields can change, new records can appear, etc. I am ready, if necessary, to agree on some necessary rules for maintaining the dataset.) Myropolskyi (talk) 16:45, 18 March 2026 (UTC)

I go to https://apalladio.org/architecture-around/ which defaults to Munich. "Search location" at the bottom of the webpage doesn't work, so I zoom out and drag to the US. I zoom in on the general Chicago area and click the blue "Search objects in this area". It gives me a little cluster of buildings, such as the Garfield Farm and Inn Museum (all of which are close together and none of which are actually in Chicago proper). I suspect that it is only searching for objects in a tiny area, and there's no way to know which area it's going to search for (e.g., it's not where the works "Search objects in this area" are showing on the page). WhatamIdoing (talk) 20:54, 11 March 2026 (UTC)

It's working (at least mostly) for me. It asked to know my location, I allowed that and it centred it on what looks to me the point x=50% y=0% of the 0.01° grid square in which I am geolocated in London and it showed me an interesting selection of points of architectural interest in that area (assuming the points shown are a representative selection of all eligible points, I'd estimate circa 40-50% coverage). Zooming out it appeared to have loaded all the points in a 0.1° grid square. Moving around and clicking "search objects in this area" it appears to load the points in the 0.1° degree area that contains the centre of the screen. The further out from central London the fewer the points it has.

Search sometimes works and sometimes doesn't. I moved to the Cheddar, Somerset area and it has only two points St Andrew's Church, Cheddar, which it identifies as Medieval architecture (our article just says 14th Century), and Cheddar Palace which it lists as "Ancient Roman Architecture" and "Events: Creation (approximately):Before Christ Era (BCE), 300 - 399 years" despite it being a Saxon palace dating to the 9th century CE. I would have expected, at the very least, to also see Market Cross, Cheddar as an architectural point of interest.

I did also look in Chicago, and I saw lots of points in what I assume to be the same coverage area, including in Chicago proper. I have insufficient knowledge of that city though to estimate how comprehensive it is. Thryduulf (talk) 21:46, 11 March 2026 (UTC)

When I typed "Chicago" in the "Search location" box, nothing happened. WhatamIdoing (talk) 22:18, 11 March 2026 (UTC)

The search box sometimes works for me as I would expect and other times doesn't, only sometimes autocompletes and when it does autocomplete gives some strange results. For example the first four results each time were:

• C (nothing)
• Ch Shenzhen, Chengdu, Xi'an, Taipei
• Chi Ho Chi Minh City, Karachi, Changchun, Jinan
• Chic (nothing)
• Chica Boca Chica
• Chicag (nothing)
• Chicago Chicago, Aurora, Joliet, Napierville

Searching Aurora the top four results are Denver, Colorado; Aurora, Colorado; Aurora, Illinois; Lakewood, Colorado.

When I click on the Chicago entry in the search results, it centres the view on what seems to be the southwest corner of the 0.1° degree grid square containing the centre of Chicago (i.e. 41.9°N 87.6°W / 41.9; -87.6) which in this instance is roughly 17 miles south of the city centre), but the view is too zoomed in to see the centre of Chicago. Thryduulf (talk) 23:45, 11 March 2026 (UTC)

@Thryduulf

Yes, it can be so.

This depends on the free geolocation service (https://secure.geonames.org/...), which sometimes behaves "unreliably".

I do not even know, what I can do here Myropolskyi (talk) 12:26, 12 March 2026 (UTC)

Thanks, I'll check these places. (The epoche appears from wikipedia-pages, but from one of the synonymes, not from all of them. I mean, if en-page with date was found the first with date, then this date comes to database. It can be and it could be mistakes in such dates) Myropolskyi (talk) 12:33, 12 March 2026 (UTC)

Thinking about Wikipedia:Wiki Shoot Me, from an editing side such a tool may be useful if it can identify what sites lack photos, articles (or sections in other articles), etc. From a reading side it has its obvious browsing use but that's not something we can really integrate. CMD (talk) 12:38, 12 March 2026 (UTC)

Hi, I was wondering if anyone here might have any input on my request to move the radio buttons in the switcher gadget from the top to the bottom. I have modified the script, but because I have basically no Javascript experience, I have not formally made an edit request.

My request, with more details, can be found here: MediaWiki_talk:Gadget-switcher.js#Buttons_at_Top

Thanks, CommonsKiwi (talk) 03:49, 23 March 2026 (UTC)

Have an idea to improve the editing environment in CTOPs. Basically, set up something like WP:EOTW where people get an award for collaborating well with a user they often disagree with, or for successfully leading consensus building efforts in a heated dispute. And editors have to be nominated by someone they often disagree with (read 'opposite POV'). This'd hopefully bridge the gap between 'POV trenches' and result in CTOPs having a handful of highly collaborative regulars, which then affects newbies entering the topic areas (and make true partisans stick out more).

Atm, our only way to encourage collaborative behaviour is through punishing objectionably uncollaborative behaviour (and barnstars, but that's rare), which is not great. From a 'game' perspective (and there's always going to be some editors who treat editing like a game, esp. in CTOPs), the status quo just encourages WP:CPUSHing and avoiding petty insults etc., while collecting evidence of their ideological enemies' slip-ups to try to weaponise conduct noticeboards and expel them from the topic area. This creates a lot of bad blood which makes the editing environment even worse.

Again from a 'game' perspective, this award would add to a user's social capital, and so incentivise people to seek it. Thoughts? Kowal2701 (talk, contribs) 14:14, 7 March 2026 (UTC)

This does not seem like the best idea. There should be zero "game" perspective. Editors that treat editing like a game should be sanctioned. Just give barnstars to editors who collaborate well with others, regardless of your POV. SuperPianoMan9167 (talk) 16:16, 7 March 2026 (UTC)

ideally, yes, but in practice it's not black or white Kowal2701 (talk, contribs) 16:57, 7 March 2026 (UTC)

At first glance it seems a good idea, but I can see gaming coming from "editors have to be nominated by someone they often disagree with". There are rarely only two "sides" to a dispute, so people would insist that this is clearly defined, and it could lead to manufactured "disagreements". Phil Bridger (talk) 17:59, 7 March 2026 (UTC)

I agree, I hope there'd be some 'panel' not restricted by legalisms determining noms, but I guess people from the peanut gallery can call out bad-faith noms/when there's similar POVs. Open to other thoughts and better ideas about the problem generally Kowal2701 (talk, contribs) 18:13, 7 March 2026 (UTC)

Facilitating, incentivizing, recognition for, and rewarding positive behavior and contributions does not imply editors "treat editing like a game". Stack Exchange users also do not treat that Q&A site like a game just because they can receive reputation and badges. However, I don't know whether "award for collaborating well in CTOPs" is a good idea and have doubts about it, e.g. due to requiring time-intensive manual subjective review etc. Prototyperspective (talk) 18:05, 9 March 2026 (UTC)

Thanks, I'd hope a nomination would include links to discussions which display it (there'd be a high bar), and I guess someone would scan the nominee's editing history (I was thinking AE admins would be a good fit for the 'panel' as a) it'd add prestige and b) they'll have more familiarity with CTOPs and such editors) Kowal2701 (talk, contribs) 19:01, 9 March 2026 (UTC)

Editor of the Week was deliberately set up as a low-stakes recognition initiative, to avoid making it something that people would spend a lot of time arguing about. While in principle it's fine to have a high-stakes recognition initiative, personally I'm dubious that this would improve the editing environment in areas where there is a lot of contention. My preference is to encourage low-stakes approaches that spreads out encouragement to lots of people for small acts of collaboration. isaacl (talk) 02:06, 10 March 2026 (UTC)

I don't know if Stack Exchange is the best example to use. It was deliberately designed by Jeff Atwood to gamify knowledge sharing, harnessing the desire people have to level up in service of building a repository of well-written answers. isaacl (talk) 01:56, 10 March 2026 (UTC)

Didn't claim it was the best example; it's a good example and what's your point even. It works well and Stack Exchange users also do not treat that Q&A site like a game just because they can receive reputation and badges.

Btw, maybe another idea for consideration would to do sth effective about contributors who repeatedly insult others and better enable constructive deliberation on contentious topics where for example users do not address people's points, make false claims about what others say (both of which leading to "bludgeoning" accusations and difficulty for others to participate) or rule by the majority of who happens to watch the article or some noticeboard linking to the page where the subjective opinion of the majority crushes any constructive calm respectful deliberation. On a related note, I think an issue will be that users who often actually act unconstructively will get awarded with what's described here just because they also often contribute very constructively in lots of contentious topics. Prototyperspective (talk) 13:16, 10 March 2026 (UTC)

The point is that Stack Exchange deliberately made a game out of sharing knowledge, and users did indeed treat it that way, seeking to level up. That had both positive effects and negative effects. Personally, I wouldn't use it as an argument in support of a similar system on English Wikipedia. That being said, recognition initiatives don't have to work the same way as on Stack Exchange, and trying to build more esprit de corps is a good way to foster cooperation. isaacl (talk) 17:10, 10 March 2026 (UTC)

and users did indeed treat it that way, seeking to level up Disagree with that unsourced/unsubstantiated statement. Whatever they did it worked and works remarkably well. recognition initiatives don't have to work the same way as on Stack Exchange indeed. I think for a start we need better feedback & recognition than mere edit counts which do not reflect well the constructivity and contributions of users. Prototyperspective (talk) 19:23, 10 March 2026 (UTC)

It was discussed by Jeff Atwood at the time of creation, and there has been discussion online about how Stack Exchange's incentive structure led to gatekeeping and ownership behaviour. The details are not really important, since I don't think a Stack Exchange-type system is going to attain consensus support on Wikipedia. The key takeaway is that making knowledge sharing into a game can have pitfalls as well as benefits. I think Wikidata has some interesting examples of making contributing info more like a game, without any badges or levels.

I think editors should be doing more to thank others publicly, to foster collaborative behaviour by demonstrating it. I appreciate, though, that this may not come naturally to a significant proportion of the community. isaacl (talk) 02:21, 11 March 2026 (UTC)

As said, that would not make it into a game, at least for the vast majority of users. SE which I did not claim was ideal did not make it into a game either. Prototyperspective (talk) 12:32, 11 March 2026 (UTC)

Let's not make barnstars be rare. In particular, I recommend The Teamwork Barnstar (for groups), the Half Barnstar (for two editors; two halves shown), and the Diplomacy Barnstar (for the peace brokers) for these situations. WhatamIdoing (talk) 03:26, 11 March 2026 (UTC)

Feel free to write an appreciative note on the talk pages of editors who act collaboratively, whether or not they support the same views that you do, and to encourage others to do the same. Personal notes are great, particularly when they list specific actions that are being appreciated, so they really convey your personal thanks. isaacl (talk) 23:12, 7 March 2026 (UTC)

I like this idea because it would let us make a cleaner case for who's pushing what POV, making it easier to eventually remove them from the topic area. Thebiguglyalien (talk) 23:53, 8 March 2026 (UTC)

I disagree with Thebiguglyalien. I don't think it would make a cleaner case for who's pushing what POV. It would only tell you which accounts have won the award. It is not possible to extrapolate much from that. And it is not currently technically possible to remove a person from the topic area. It is only possible to remove an account from the topic area. The non-equivalence between a person and an account means that removal acts as a filter that increases the concentration of people willing to employ deception and dilutes the concentration of editors unwilling to employ deception. This is why socks love to weaponize reporting systems of course because sanctions provide a very significant fitness advantage to people willing to employ deception via disposable accounts. This is where I disagree with SuperPianoMan9167 a bit. There is utility in thinking of Wikipedia as a game with payoff matrices.

I'm not sure whether the notion of 'collaboration' is the best target. First the caveats...

• I'm not sure what is meant precisely by 'collaborative behaviour' or how to measure it in a sensible way. Even if we could measure/recognize it (roughly) I'm not sure we have the kind of visibility into the topic area and all of its actors to make sensible evidence-based decisions. People mostly see shiny objects and hear the noise when most of the activity in the topic area just hums along undramatically in the background.
• I'm not sure that the kind of collaboration (talking?) that is being considered as worthy of merit or virtuous is an important factor in content creation in the topic area in practice since 'consensus usually occurs implicitly'. The vast majority of activity in the topic area is routine editing and does not involve conflict/disruption.
• I'm not even sure whether a collaborative environment is actually better than a diverse partly adversarial environment at producing policy compliance for something like the PIA topic area where content needs to capture things from all sorts of perspectives and sources. A bit of chaos might be better at doing that over time.
• I'm not sure whether WP:CPUSHing is good or bad given that the alternative to civil POV pushing is just POV pushing. POV pushing is not going to stop, and there is very little anyone can do about it without solving hard problems like the use of deception via disposable accounts. Editors in the topic area have POVs and it impacts every choice they make whether they are aware of it or not. So, for me, the number of active editors, their activity levels and their diversity of views is what matters much more than details about individual editors.

Having said all that, if there were an award, maybe it would be better to reward people for using the tools available to resolve conflict and find consensus on contentious issues. I'm thinking of RfC usage, things like that, tools intended to help people focus on policy-based decision making. It is those tools that I think have the best chance of making the topic area function better. Perhaps that was already captured by the 'for successfully leading consensus building efforts in a heated dispute'. Sean.hoyland (talk) 10:41, 9 March 2026 (UTC) 

Wikipedia is not survival of the fittest. It is not a battleground between "pro-RS editors" and sockpuppets. It is an encyclopedia.

Civil POV pushing is still POV pushing, so it is bad. The alternative to civil POV pushing is not letting your opinions come out in your edits at all. SuperPianoMan9167 (talk) 18:17, 9 March 2026 (UTC)

I think on here we've accepted the reality that on some topics few people put several hours every day into Wikipedia for free solely because they want to improve the encyclopedia, if we tbanned/blocked everyone with a POV this place would become a ghost town. Also, presenting and analysing evidence for POV pushing takes ages. So long as there's a diversity of POVs and they all collaborate well w one another, article quality turns out good. Kowal2701 (talk, contribs) 19:15, 9 March 2026 (UTC)

Article quality turns out good... if one happens to hold the POV that "wins" in that particular area. I believe most Wikipedia editors do want to write neutrally by properly summarizing the totality of sources/opinions, and do have the goal of improving the encyclopedia without tilting coverage one way or the other. But there are also many editors who are participating in bad faith by balancing articles and casting !votes in a way that strengthens their POV. Thebiguglyalien (talk) 21:26, 10 March 2026 (UTC)

by collaborating I mean compromising (assuming NPOV sits in the middle), RfCs are a joke in CTOPs Kowal2701 (talk, contribs) 22:00, 10 March 2026 (UTC)

I'm used to seeing users who were topic or community banned still having diplomacy and conduct barnstars on display, and similar cases like that. I don't think it's a good idea. 3df (talk) 22:48, 21 March 2026 (UTC)

Are you proposing that we order Damnatio memoriae when someone gets banned? I think we should let people be complex, and show both the good and the harm they did. WhatamIdoing (talk) 03:33, 24 March 2026 (UTC)

I want to reate a template for use in the Help, Template, and Project namespaces to identify that a feature, template, or the like is currently nonfunctional. For an example, the User scripts feature was recently disabled, and there was no notice given on the project page. Therefore, someone could go through all of the trouble of figuring out how to use it and then learn it is currently non-functional. I put my idea for it in my sandbox. Here is an example.

This project page is for a feature which is currently disabled due to abuse for a kajifillion years. The issue will be resolved as soon as possible. This page was last edited 3 months ago, at 19:13, 6 April 2026 (UTC) (refresh).

— Preceding unsigned comment added by FloblinTheGoblin (talk • contribs) 00:41, 23 March 2026 (UTC)

The reason there was no notice given is because they had to be turned off as an emergency measure due to a test of the system unwittingly running a malicious user script. —Jéské Couriano v^_^v ^{threads critiques} 17:21, 23 March 2026 (UTC)

Right, but that doesn't mean it couldn't have a project page warning. 𝓕𝓵𝓸𝓫𝓵𝓲𝓷 (Talk to me! · My contribs) 17:41, 23 March 2026 (UTC)

There was a watchlist notice at the time. 45dogs (they/them) (talk page) (contributions) 17:47, 23 March 2026 (UTC)

It's possible that they wouldn't've seen it.

I knew this template was going to be for rare cases, but I'm beginning to wonder how often things go down here. Is it even worth it for those rare cases? 𝓕𝓵𝓸𝓫𝓵𝓲𝓷 (Talk to me! · My contribs) 17:57, 23 March 2026 (UTC)

No matter what the problem is, some people won't see it. I once delivered messages to over 100 pages, held multiple discussions, and ran site banners for two weeks, and still had people saying they'd never heard anything about it. "Oh, those were the two weeks I was on vacation..." or "I don't watch any of those pages" or whatever.

For outages, the process I've found to be most function is to check Wikipedia:Village pump (technical). If someone's reported the problem, then you know that it's not just you, and maybe someone will have posted an explanation. And if they haven't, then report it yourself. WhatamIdoing (talk) 03:54, 24 March 2026 (UTC)

Alright then, I think that I'll abandon this. I don't think it's nearly as useful as I thought it would be. 𝓕𝓵𝓸𝓫𝓵𝓲𝓷 (Talk to me! · My contribs) 11:07, 24 March 2026 (UTC)

Article layout has been historically designed for a computer screen. Its width allows to present additional elements such as infoboxes along the main text column. This logic can't work on a narrow mobile screen, where additional elements are inserted between paragraphs. Mobile pageviews have surpassed desktop more than a decade ago, but the layout design is still desktop-oriented, with minimal considerations for mobile experience.

Infoboxes, a supplement material for the main text in the desktop version, are inserted after the first lede paragraph on a phone screen. This solution is problematic in multiple ways. The manual of style considers the lede the most important part of the article, and its priority is above any other piece of content. In practice, it is only respected for the first lede paragraph, because the majority of readers see an infobox next. With the size of infoboxes taking up to several phone screens and the amount of information inside, the comprehension certainly suffers by the time reader gets to the second lede paragraph, which is written to be read immediately after the first one. And huge infobox might be a nuisance itself, with tendency to fill it with tangential or technical data suitable for table form. Vladimir Putin, Biphenyl, Vietnam War, Mars, Arabic, Nguyễn dynasty, IPhone 15 Pro, SS United States - it's neither editors' nor readers' choice to have articles introduced with these long tables.

I doubt that current state of affairs is considered desirable or acceptable. In my opinion, generally only the infobox illustration is important enough to be displayed to mobile readers by default, and the rest of the infobox would be better hidden. I suppose it could be a viable workaround to make infoboxes a collapsible element, such as commons:Template:Wikidata Infobox, collapsed by default in mobile view. Better ideas might be suggested, but this is an important issue, and I hope it gets traction and some sort of solution gets developed. Qbli2mHd (talk) 22:03, 16 March 2026 (UTC)

In the mobile apps, infoboxes are collapsed. I'm not sure if that is a good default but there really should be a button to collapse the infobox at its top. Prototyperspective (talk) 23:45, 16 March 2026 (UTC)

@Qbli2mHd, the decision to put the infobox after the first lede paragraph, rather than the entire lead, was deliberate.

Someone else suggested this recently. @Prototyperspective, maybe you'd like to propose this at Template_talk:Infobox? A hide/collapse button would be handy on the mobile site. WhatamIdoing (talk) 03:50, 24 March 2026 (UTC)

As I understand it, the goal was to prevent the infobox being at the very top (T143139). I doubt that having lede broken up is the perfect outcome, but if infoboxes are made collapsible, their exact placement would not be so important. Qbli2mHd (talk) 12:14, 24 March 2026 (UTC)

Task on Phabricator: T421116 Qbli2mHd (talk) 14:21, 24 March 2026 (UTC)

Adding a button to collapse an infobox is something that we can do locally, so why did you decide to propose it on Phabricator, where it could take months or years, instead of doing it ourselves now? WhatamIdoing (talk) 16:40, 24 March 2026 (UTC)

Ever since I've read this talk page comment, I've been wondering about a possible generational problem for Wikipedia -- newer users, having grown up in a world where paper encyclopedias are not used much, don't have much of an idea of what an encyclopedia is -- and they may take Wikipedia's quirks and humorous areas as encyclopedic, or, if Wikipedia severely declines in popularity, have no idea of what is encyclopedic at all.

I think this has happened to some extent now -- just check venues like the Teahouse, the Help Desk, and the Reference desk for many confused people who, despite our nagging, are treating Wikipedia like an everything app and don't get why people are so hung up on this quality of "encyclopedic". Beyond simply telling the new editor what not to do, or having them read through policy, I'm wondering if it would make sense to have some sort of notification occur upon creating an account, saying something like "Welcome to Wikipedia, the free encyclopedia! If you're not sure what an encyclopedia is, you can look at these examples:" and then have a link to perhaps Britannica's website, or, if we wish to stay local to Wikimedia, links to Wikisource's archives of old editions of Britannica or other encyclopedias. (This could also boost Wikisource editing, but it could have the side effect of users thinking encyclopedias must be written about old fashioned topics, and could result in duplication of academic biases if that's what they pick up on in the encyclopedias).

Whatever we do, I really think we need to take this step as a clear way to show what our source of information is meant to be, something very important when people are reading more ChatGPT conversations than textbooks. ✨ΩmegaMantis✨^(he/him) ❦blather | ☞spy on me 21:55, 13 March 2026 (UTC)

This has occured to me too. Would all these people writing vanispamcruftisements be as eager to shoehorn then into Wikipedia if it was explained to them that that would be like barging into the Encyclopaedia Britannica writers' room and demanding they publish their garbage? Honestly, some of them probably would, but quite a lot might reconsider what they're doing. JustARandomSquid (talk) 22:49, 13 March 2026 (UTC)

Maybe we should, but I don't think it will make much difference. POV-pushers will still push their POVs and spammers will still spam, while good-faith editors will still think that an encyclopedia article has to be long and written in glowing prose, an idea which is disagreed with by the encyclopedias which I have on my bookshelves. Phil Bridger (talk) 23:23, 13 March 2026 (UTC)

Collector's items! Fear not; nearly half of all Wikipedia articles are stubs. Hawkeye7 (discuss) 23:57, 13 March 2026 (UTC)

Encyclopedias are outdated/obsolete, so I don't think we should give them any more attention than necessary. I also wonder how many new/younger users think Wikipedia is the more "serious" version of the different Fandom wikis. Some1 (talk) 14:31, 14 March 2026 (UTC)

I assume you mean print encyclopaedias, because, well, Wikipedia is an encyclopaedia. JustARandomSquid (talk) 15:28, 14 March 2026 (UTC)

Current Britannica online is pretty up-to-date -- it has an article on the 2026 Iran war. Showing new/younger users an encyclopedia like that will hopefully make people realize it is not simply another Fandom. ✨ΩmegaMantis✨^(he/him) ❦blather | ☞spy on me 00:47, 24 March 2026 (UTC)

Print encyclopedias are not obsolete as a medium. Many are still printed, bought, and read. The large, multi-volume general encyclopedias that would take up a whole shelf on a bookcase which people relied on for general reference in the pre-internet days are obsolete, but subject-specific encyclopedias are still useful reference works. (In-fact, many are cited as references here on Wikipedia.) – Scyrme (talk) 23:06, 24 March 2026 (UTC)

Monobook was great at doing so by utilising an open book as page's background. sapphaline (talk) 11:55, 16 March 2026 (UTC)

This feels somewhat condescending. If I were a new user I'd be a bit put off by the implication that I don't know what an encyclopedia is. Gnomingstuff (talk) 16:56, 16 March 2026 (UTC)

Better than confuse many people who genuinely don't know what one is and try to approach Wikipedia as something else altogether. ✨ΩmegaMantis✨^(he/him) ❦blather | ☞spy on me 00:49, 24 March 2026 (UTC)

Do we actually know that there are many people who genuinely don't know what an encyclopedia is? Is "go to the library" and get an encyclopedia off the shelf" no longer something that kids do in school? WhatamIdoing (talk) 03:46, 24 March 2026 (UTC)

To answer your second question, yes. They'll just use their school-issued laptops or school library computers to look up information. Some1 (talk) 22:57, 24 March 2026 (UTC)

Maybe it'd be better to start by writing a help or information page, similar to Wikipedia:What is an article?, but titled something like Wikipedia:What is an encyclopedia?. This would essentially be a more welcoming version of Wikipedia:Wikipedia is an encyclopedia, which already emphasises the points/intentions here but does so in a very forceful way. It would also be more concise and welcoming than the article Encyclopedia, with more of a focus on details which are especially relevant to Wikipedia.

The new page could then be added to some of the welcoming templates used by the welcoming committee. This would have the benefit that welcomers could target the message at people who seem confused about what Wikipedia is. An info page would also have the advantage that it could be linked in a discussion with someone if an explainer is needed, whereas a notification happens only once and could be buried or ignored.

As far as I know, presently there's only 1 notification when a new user joins and it only links to Help:Getting started. It would be a bit strange to add another just to explain what an encyclopedia is. If it were decided that another notification were needed (or the current one amended), the new information page could be linked to provide more information, rather than overwhelming new users with an explanation in their first notification(s). – Scyrme (talk) 23:42, 24 March 2026 (UTC)

I like this idea. WhatamIdoing (talk) 18:38, 25 March 2026 (UTC)

Should there be an edit notice for featured articles, saying something like
This is a featured article, meaning that it has gone through a community review process where it was checked for compliance with a strict set of criteria aimed at ensuring high quality. Please be cautious when editing it, and consider proposing significant changes on the article's talk page.
Open to different wording, idk if "cautious" is too much Kowal2701 (talk, contribs) 19:56, 22 March 2026 (UTC)

I support something like this, with wording worked out as needed. Perhaps an edit notice could be automatically applied by Template:Article history when currentstatus = FA. Thebiguglyalien (talk) 20:16, 22 March 2026 (UTC)

I hope this isn't supposed to imply that minor copyedits and what should be uncontroversial changes need to be explicitly discussed on the talk page. Katzrockso (talk) 02:31, 23 March 2026 (UTC)

It isn't, but if it gives someone second thought about whether an FA needs copyediting, that's not such a bad thing imo Kowal2701 (talk, contribs) 17:10, 23 March 2026 (UTC)

I'd support that on GA articles too. GeogSage ^{(⚔Chat?⚔)} 02:35, 23 March 2026 (UTC)

notified WP:FA and WP:FAC Kowal2701 (talk, contribs) 19:03, 23 March 2026 (UTC)

I support something akin to this, though I suspect the majority of editors don't even notice them. I suggest a link to WP:FAOWN which is policy and has basically the same contents as the proposed edit-notice (I assume that's intentional). A more formal, yet perhaps milder expression for 'be cautious' might be 'exercise additional caution'. The implication of 'additional' is that some measure of care or caution is exercised by the editor regardless of the article being edited, and that you are merely asking for a bit more of that on an FA. Mr rnddude (talk) 19:40, 23 March 2026 (UTC)

Would support with reference only to FAOWN (not for GA articles, which don't have a similar PAG carve-out, and for good reason) and only with tempered wording rhat highlights FA status does not mean improvements are impossible. ~~ AirshipJungleman29 (talk) 21:07, 23 March 2026 (UTC)

To save people some digging, that language in WP:FAOWN was added in this edit 16 years ago, based on this talk page discussion. I'd be really hesitant to do anything more than include a link to WP:FAOWN. It's all a bit of security theatre anyway; nobody pays attention to edit notices and I'm not even sure they're visible on all platforms. RoySmith (talk) 21:36, 23 March 2026 (UTC)

live example Template:Editnotices/Page/Canada Moxy🍁 21:57, 23 March 2026 (UTC)

If it’s all security theatre, no one need be hesitant about any of it. My experience is that people who do not care about good faith or etiquette will ignore edit notices, and those who are really interested in productively contributing will not. We should tailor edit notices for the latter group, not the former. ~~ AirshipJungleman29 (talk) 23:30, 23 March 2026 (UTC)

Just to clarify, my hesitation is about writing anything which goes beyond what FAOWN says. An edit notice which says "This is a featured article. Please see WP:FAOWN for advice about editing it" would be fine. RoySmith (talk) 11:13, 24 March 2026 (UTC)

I would support this - we already do something similar for TFAs, and this merely repeats what WP:FAOWN says. Now whether FAOWN should be changed is a different story, but reminding people to take extra care on a FA per FAOWN is not, in my opinion, unreasonable. Something like this may work, but thoughts are appreciated. – Epicgenius (talk) 16:15, 24 March 2026 (UTC)

The wording in that mock-up looks good Kowal2701 (talk, contribs) 16:19, 24 March 2026 (UTC)

Not yet. This was seemingly prompted by a certain discussion at ANI that has since spun off into an ArbCom request. We should let those close; if ArbCom decides FAs are a contentious topic, then we can add a warning. And in any case FAOWN needs to go, as it’s just promoting legitimized WP:OWNership. Dronebogus (talk) 16:26, 24 March 2026 (UTC)

If you'd like to talk about abolishing WP:FAOWN, that should be a separate discussion. It may be a good idea to discuss it at Wikipedia talk:Ownership of content. – Epicgenius (talk) 17:17, 24 March 2026 (UTC)

Done: Wikipedia talk:Ownership of content#Abolish FAOWN and possibly “stewardship” entirely? Dronebogus (talk) 23:10, 24 March 2026 (UTC)

• I post a lot of articles at WP:FAR and WP:GAR. Many status articles have information added that causes the article to no longer fulfil the WP:FA? or WP:GA? criteria. An article also deteriorates because it is not updated: this is especially relevant for WP:BLPs, growing institutions (like cities or businesses) and species with a conservation status. In these cases, oftentimes the nominator, after the article was promoted, did not monitor changes and also did not update the article with more recent statistics. This notice might prevent edits that would deteriorate the article quality, but would also prevent maintaining the article's currency of more recent events or research. If this is implemented, I would like to see a concurrent guideline directed at GAN and FAC nominators which states that, if the nominator wants the article to keep its status they should periodically check and update the article. Wikipedia should not discourage inexperienced users from editing these status articles unless it is willing to add more responsibility for experienced users. Z1720 (talk) 16:29, 24 March 2026 (UTC)

• I just tried editing today's FA – Despre tine – and got multiple popup edit notices which already seemed excessive:

You are editing Wikipedia right now!

"Despre tine" is today's featured article.

You are editing it, and if you press Publish changes, your changes may be publicly viewable immediately. Constructive changes are welcome, but please do not attempt to damage the article.

Use your sandbox for test edits, or go to Talk:Despre tine to make comments or suggestions. See our introduction on how to get started editing. We are excited to have you contribute! Thank you.

Note: This page is semi-protected so that only autoconfirmed users can edit it. If you need help getting started with editing, please visit the Teahouse.

23:00, 23 March 2026 TFA Protector Bot talk contribs changed protection settings for Despre tine [Edit=Require autoconfirmed or confirmed access] (expires 00:00, 25 March 2026) [Move=Require administrator access] (expires 00:00, 25 March 2026) (Semi-protecting upcoming TFA) (hist) (thank) View full log

It wasn't difficult to find a phrase that needed obvious copy-editing and so I actually made an edit.

More generally, I do not consider that this article represents Wikipedia's finest work. The topic is a Romanian pop single and other issues include:

1. In the FA nomination, the nominator is asked "Are you sure there are no reviews of the song?" and replies "The coverage on this is sadly very limited..." This immediately calls the notability of the topic into question.
2. The article does not seem to explain the theme of the song's lyrics - it just quotes some of them.
3. The article does not describe the musical qualities of the song – neither the instruments nor the technical aspects such as the key or the time signature.

This is not an isolated example as I recently observed that another article about a pop song contained zero chart information so again its notability was questionable. The issue was so blatant that it was then taken to AfD.

Elsewhere, we see a prolific FA editor being taken to ANI/Arbcom for being excessively defensive and, again, this doesn't seem to be an isolated example.

So, FA's don't seem to need more protective barriers; they seem to need more scrutiny and challenge.

Andrew🐉(talk) 19:09, 24 March 2026 (UTC)

@Andrew Davidson my response to you is the same as I've made in other venues. Rather than taking potshots at FA, come help make it better. We need more reviewers. Despre tine was just reviewed a couple of months ago. Had you shown up at the FAC and made your objections known, maybe they would have been fixed. Or maybe they would have been found serious enough that the nomination would have been archived. Either would have been more useful than sitting on the sidelines telling the people who do the work that they're not doing it to your minimum standards. RoySmith (talk) 19:23, 24 March 2026 (UTC)

@RoySmith I think the main thing stopping people from getting involved at FAC (or FAR) is the fact that it's not very intuitive, and is very unlike regular content editing. I made my first comment at one a few days ago, concerning a small error in the article text, and the expected formatting confused me a lot -- and I very nearly didn't make any comment at all! Looking at other FACs to try and get an idea of what I should say didn't help -- it has always seemed to be that many comments are focused on formatting, MOS, and Engvar-- copy editing type stuff that I have no eye for; I can't provide meaningful feedback. This goes double for FAR - I noticed some fairly close paraphrasing in Robert Sterling Yard last night, and I'm fairly confident that there's still more. These were all present back when the article went through GA, PR, and FAC all those years ago, and I like to think it wouldn't have passed even a GA review today. But all the instructions an steps and formalities and stages; I have no idea which criterion "this article had/has CLOP" would even fit under.... I think I'm just going to try and clean up the article to the best of my abilities, and ignore the FA star entirely. GreenLipstickLesbian💌🧸 20:03, 24 March 2026 (UTC)

You are right that FAC gets arcane. There's a lot of stuff people obsess over (citation formatting, MOS trivia, and Engvar are just the tip of the iceberg) but if you're not into that, you can look at other things. If you've noticed some close paraphrasing and you said "I'm just here to mention this one thing, but won't be doing a full review", that's a valuable contribution. RoySmith (talk) 20:23, 24 March 2026 (UTC)

@GreenLipstickLesbian: If an article has WP:CLOP concerns, then it does not fulfil WP:FA? 1f, which states that the article is "compliant with Wikipedia's copyright policy and free of plagiarism or too-close paraphrasing." If there are CLOP concerns in a featured article, please follow step 1 of the FAR process, which is to "Raise issues at the article's talk page". Feel free to ping me if there are any questions or think the article needs to be posted on FAR. Z1720 (talk) 21:24, 24 March 2026 (UTC)

@Z1720 Yeah, I'm probably explaining myself poorly - I don't claim to be perfect at this, but once I identify copied text, I do my best to remove it... because otherwise, it's probably also going to be me removing it, but in, like, 2028. So ideally, by the time I even leave a talkpage comment identifying the close paraphrasing, it's not going to be there anymore! And I have no idea how to say, in a formal, FA, manner - "I just put this article through major surgery - and while it's better off for it, it's definitely not in peak physical condition anymore". GreenLipstickLesbian💌🧸 18:31, 25 March 2026 (UTC)

Personally, I'd have no problem at all with seeing that sentence at FAC. UndercoverClassicist ^T·C 18:46, 25 March 2026 (UTC)

@RoySmith And that's okay; it's not going to be taken as too irritating for the other participants/coordinators to sift through? Also, can I take those exact words from you, because that's a lot nicer than the script I'd made for myself GreenLipstickLesbian💌🧸 18:26, 25 March 2026 (UTC)

I've wanted to get more involved in GA and FA review, but honestly the process is pretty overwhelming. I mostly want to nominate articles and work on them, I don't think that reviewing and writing are the same skillset. Trying to get my first article through GA might have soured me on the process, it was very time consuming (expected), and took two attempts due to the initial reviewer getting banned. I put in the initial request for review, but by the time it came through the amount of free time I had to work on it had dropped to nearly zero, committing to timely review of an article I'm not involved with is another challenge. I don't feel like I can nominate as freely as reviewing doesn't interest me that much, so I've been hesitant to get more involved. GeogSage ^{(⚔Chat?⚔)} 02:58, 25 March 2026 (UTC)

My suggestion would actually be to start with reviewing FA instead of GA if you're interested. With GA you're the sole reviewer and the things you're looking for are more specific, but FA has several reviewers so you just have to provide your thoughts about any possible issues or improvements and not worry about managing the whole process. Thebiguglyalien (talk) 03:06, 25 March 2026 (UTC)

Could we make that easier? Imagine a button that says Leave a comment about this article and puts your comment in a reasonable place.

Could we systematically recruit reviewers? USS Missouri (1841) is at FAC right now, and I see no notifications at MILHIST or the other WikiProjects listed on its talk page. There are only a dozen noms or so a week; can we get a standing list in WP:SIGNPOST? Can we post notifications here? I'd like a message that specifically asks for reviews on the things that are specific to the subject matter, like asking people whether any high-quality sources have been overlooked. Any FAC regular can handle things like citation formatting or grammar errors, so I would focus on the things that the FAC regulars can't easily do. WhatamIdoing (talk) 19:37, 25 March 2026 (UTC)

Odd. It has the proper {{WikiProject Military history}} template on the talk page. A bot should have picked it up and listed it at Wikipedia:WikiProject Military history/Open tasks but it's not there. I don't know why. RoySmith (talk) 20:02, 25 March 2026 (UTC)

It got added this morning. It looks like the bot usually runs once per day but for some reason didn't run for a few days. RoySmith (talk) 14:10, 26 March 2026 (UTC)

Be careful what you wish for... But I have limited bandwidth and wouldn't normally have time or interest in such a topic as Despre tine. I have no knowledge of the Romanian language and this seems needed for detailed work on this topic. Romanian editors are the most suitable in that case and, as there will be a limited pool of them, that's another reason we shouldn't raise barriers to their participation. Andrew🐉(talk) 20:11, 24 March 2026 (UTC)

Like so: w:en:Special:Diff/1345610343/prev. Or alternatively by having a bot edit 118K files. Or change WP:NFCC#10.
We have >118000 non-free files with "n.a." as the value for Replaceability and/or Commercial. And Stifle just tagged one of mine with {{di-disputed non-free use rationale}} and says that's helpful. As it happens, five years after uploading I'm still around, but many Wikipedians aren't and won't be able to "fix" (read: insert boilerplate fluff) their file pages. Imho WP:JUSTFIXIT would be more productive and equal effort, but who am I?
Arguably templates like {{Non-free comic}} satisfy the policy anyway, and "no (free alternative) available / not applicable (because how would a 0.1 megapixel image ever compete with commercial exploitation?) is arguably not wrong anyway for the vast majority of files. But here we are. — Alexis Jazz (talk or ping me) 10:28, 27 March 2026 (UTC)

I don't think anyone reads "n.a." as "no free alternative available".

I would just add that if someone doesn't care enough about a fair use image to fill out the short rationale template fully, that is likely an indicator the image doesn't meet the high bar for inclusion of non-free content at this free encyclopedia. Stifle (talk) 11:03, 27 March 2026 (UTC)

Stifle, I do. And as far as I know this is/was inserted as a default value by a script. It's not at all an indication of whether any given file meets NFC criteria. — Alexis Jazz (talk or ping me) 12:08, 27 March 2026 (UTC)

I would like for <math>...</math> to support more LaTeX packages from Comprehensive TeX Archive Network (CTAN). In particular, I would like to see

1. Support for commutative diagrams via, e.g., diagxy, TikZ (PGF/TikZ)
2. Support for LaTeX3 features provided by, e.g., expl3, l3*, xargs, xcoffins, xgalley, xparse, xstring, xtemplate

What gaps in wiki support of LaTeX packages are others feeling? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:24, 26 March 2026 (UTC)

I'm quite unsure why the programming macros are included. I think each math environment are handled separately and no states nor \newcommands are preserved.

As for the TikZ part I think it can quickly sprial out of control (you can pretty much do programming within TikZ grammars) and it is quite inefficient. You are welcomed to precompile your diagram (for example, with standalone document class) and upload to Wikimedia Commons. MilkyDefer 16:34, 26 March 2026 (UTC)

The LaTeX3 stuff would admittedly only be useful for someone who had something complicated inside <math>...</math>, but it is quite useful when things get complicated.

Pre-compiled diagrams make them uneditable by other editors, which is exactly what I would like to avoid.

Thinking more broadly, it might be useful for wikimedia to provide some sort of caching mechanism such that the heavy lifting is done when you edit a page rather than when you view it. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:12, 26 March 2026 (UTC)

Are the desired packages Open source, using the Four Freedoms (Free software) standard? WhatamIdoing (talk) 22:16, 26 March 2026 (UTC)

@WhatamIdoing: All are licensed under the LaTeX Project Public License; TikZ is also GPLv2. The fact that the math part of LaTeX (including some amsmath macros) is usable means that the LaTeX Project Public License is acceptable. MilkyDefer 03:42, 27 March 2026 (UTC)

I think you all want to be talking to @Physikerwelt, who knows a lot about mw:Extension:Math. You could also check phab:tag/math to see whether the feature request has already been requested. WhatamIdoing (talk) 17:21, 27 March 2026 (UTC)

Check https://arxiv.org/pdf/2401.16786 for an overview. So this would be in the order of a Million Dollar project. Physikerwelt (talk) 17:35, 27 March 2026 (UTC)