Wikipedia:Village pump (technical)

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for five days.

view · edit

Frequently asked questions (see also: Wikipedia:FAQ/Technical)

Click "[show]" next to each point to see more details.

If something looks wrong, purge the server's cache, then bypass your browser's cache.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.

No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an `accesskey` property on it (default to `accesskey="f"` in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.

No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.

If you have problems making your fancy signature work, check Help:How to fix your signature.

If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.

If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.

For server or network status, please see Wikimedia Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

« Archives, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217

Parent categories

An editor has requested a change to the way we display categories in the Category: namespace. The existing system, which looks approximately like this:

Categories: Category name 1, Category name 2, etc.

does not seem intuitive. @PrimeHunter figured out how to change the existing category footer to something that makes the meaning more obvious:

Parent categories: Category name 1, Category name 2, etc.

and to have this only appear in the Category: namespace (i.e., will not change/screw up any articles).

Could we please get this change implemented here? It would only require copying the contents of testwiki:MediaWiki:Pagecategories to MediaWiki:Pagecategories.

WhatamIdoing (talk) 20:18, 22 January 2025 (UTC)[reply]

This sort of sounds like it would be an overall general improvement - that is not something special for only the English Wikipedia, and for only users with their interface language in en. If so, this should be requested upstream. — xaosflux ^Talk 01:56, 23 January 2025 (UTC)[reply]

I think it'd be better to do this locally, where it's been requested. If it seems to be a net improvement, we could always suggest it for widespread use (which would require re-translation of the string for all 300+ languages – not something that can happen quickly). WhatamIdoing (talk) 03:44, 23 January 2025 (UTC)[reply]

+1 for doing it (it's an improvement), and +1 for doing it locally (no need to wait, and can easily undo the local change if and when upstream decides to do it). DMacks (talk) 19:55, 26 January 2025 (UTC)[reply]

Done The local customisation can be removed if/when a gerrit patch has been merged to change the message across all wikis. – SD0001 (talk) 05:35, 31 January 2025 (UTC)[reply]

Thank you WhatamIdoing (talk) 05:37, 31 January 2025 (UTC)[reply]

Nonsense redlink

Twice in the past three days, AnomieBOT has created the entirely unpopulated maintenance category Category:Articles lacking reliable references from 2025-01-19 from January 2025, which has in turn generated a nonsense redlink for Category:Monthly clean-up category (Articles lacking reliable references from 2025-01-19) counter — but since YYYY-MM-DD is not part of our naming format for either "Articles lacking reliable references" or "monthly clean-up category" maintenance categories, neither of these are categories that should ever exist at those names at all. But when I deleted the referencing category as both nonsense and empty earlier today in order to blow up the monthly clean-up redlink, the bot came along and recreated it again a few hours later even though it's still both nonsense and empty.

Could somebody look into this and figure out how to make it stop? I haven't deleted the category again this time, though I have wrapped the template in {{suppress categories}} since the redlinked parent still needed to go away regardless. Thanks. Bearcat (talk) 01:29, 23 January 2025 (UTC)[reply]

The somewhere to ask about this begins here: User talk:AnomieBOT. — xaosflux ^Talk 01:53, 23 January 2025 (UTC)[reply]

AnomieBOT created that because Category:Articles lacking reliable references from 2025-01-19 existed. Garbage in, garbage out. * Pppery * _{it has begun...} 02:43, 23 January 2025 (UTC)[reply]

More specifically, because Category:Articles lacking reliable references from 2025-01-19 existed and was in Category:Wikipedia maintenance categories sorted by month. As the latter says, A bot, currently AnomieBOT and formerly Cerabot~enwiki, will monitor the categories in this category and create the necessary monthly subcategories. Anomie ⚔ 12:54, 23 January 2025 (UTC)[reply]

@Bearcat and Xaosflux: It's not the fault of AnomieBOT. The problem stems from these two edits by En rouge (talk · contribs), who added more than fifty instances of {{Irrelevant citation}}, each of which used |date=2025-01-19 and not |date=January 2025 as advised by the template doc. They also manually created Category:Articles lacking reliable references from 2025-01-19, which has since been deleted. --Redrose64 🌹 (talk) 10:08, 23 January 2025 (UTC)[reply]

Some input validation could help there. — xaosflux ^Talk 10:22, 23 January 2025 (UTC)[reply]

If that was the cause of this, then why was it not in the category I asked about, either time that it appeared at WantedCategories? I found that other category by perusing the edit history of an individual editor whom I was able to figure out had some connection to the issue after asking about this here, but it was never, ever filed in Category:Articles lacking reliable references from 2025-01-19 from January 2025 at all, so how can it possibly have cascaded into the creation of a parent category it was never in? Bearcat (talk) 16:18, 24 January 2025 (UTC)[reply]

Did you check the link that I provided? If you do so, and go to the categories box at the very bottom, the first cat shown - a redlink - is Articles lacking reliable references from 2025-01-19. This means that the article was in that category, between 22:16, 19 January 2025 (UTC) (the time of the first of that pair of edits) and 01:51, 20 January 2025 (UTC), which is when this corrective bot edit was applied. --Redrose64 🌹 (talk) 00:35, 25 January 2025 (UTC)[reply]

@Redrose64, Anomie, Bearcat, and Xaosflux:

I'm sorry for the inconvenience...
Glad I found an appropriate template, I've zapped reading about specific date format.

But I think this template {{Irrelevant citation}} should be improved to be more robust: for instance using the template {{Date}} instead of requiring a strict date format?
I think this case (regularly updated citation page) is probably missing in the list of cases in article: [[ ?? ]] (sorry, I can't remember/find the page about erroneous citation)

PS: I replace {{Irrelevant citation}} with {{Failed verification}}, I think it's a more appropriate template.

Thanks, En rouge (talk) 21:33, 27 January 2025 (UTC)[reply]

@En rouge: {{Irrelevant citation}} (and also {{Failed verification}}) is one of a large group of cleanup templates, most (if not all) of which accept a |date= parameter; and this parameter, if provided, always takes the date in one form, and one form only: month and year, e.g. |date=January 2025. This is the form described in the documentation for each cleanup template; no other formats are permitted. To make this parameter behave differently for {{Irrelevant citation}} would introduce an inconsistency, and lead to confusion: people would start trying the format with other cleanup templates, and puzzle about why it doesn't behave as expected.

The problem with using {{date}} is that it would contribute to each page's WP:PEIS, and could tip some of them over into Category:Pages where post-expand include size is exceeded. --Redrose64 🌹 (talk) 23:24, 27 January 2025 (UTC)[reply]

asterisks

List item
- Second level list item

- - Third level list item if there's a line separating this from the previous list item

^^ Why is this the default behavior for multiple asterisks? Does anybody ever actually want every asterisk to render as an additional dot? Why isn't *** by default just a twice indented bulletpoint, even if not immediately preceded by a once indented bulletpoint? This silliness is why many people wind up starting lines with e.g. :*:::: or :::::*, which if I recall correctly isn't ideal for accessibility. At minimum, given the ubiquity of unordered lists in wiki discussion pages, shouldn't indents be the default behavior (with perhaps some template for anyone with a weird multi-bullet use case)? — Rhododendrites ^talk \\ 03:46, 23 January 2025 (UTC)[reply]

Because any ‘lists’ with newlines between them are not actually one united list. See MOS:LISTBREAK. Sadly MediaWiki does not make this obvious enough, if anything, but both are bad for accessibility. Editors should be advised not to insert blank lines between list items, or at least to insert them as blank lines with indentation (*** <blank>), as that would generate a hidden empty list item that would unite the markup. stjn 04:59, 23 January 2025 (UTC)[reply]

It becomes immediately obvious when using hashes to make an ordered list:

List item
1. Second level list item

1. 1. Third level list item if there's a line separating this from the previous list item

Notice the lack of an item numbered 2. This is such a long-established feature of the MediaWiki software that it's unlikely to be changed. But you can use CSS to highlight the problematic markup. Here's a quick-and-dirty rule that draws a thick dashed red line in the gap of the first example above:

ul+ul { border-top: 2px dashed red; }

--Redrose64 🌹 (talk) 23:43, 23 January 2025 (UTC)[reply]

I actually have a user style called user:stjn/linter.css (in Russian Wikipedia) that highlights a bunch of accessibility/markup-related issues like this, including one mentioned here. I mostly advertised it on Discord, though.
(Recently I’ve been thinking of turning it into a user script that can then provide more refined suggestions, since CSS can have too many false positives if you try to write, for example, a rule specifically for a list containing only another list.)
— stjn 00:33, 24 January 2025 (UTC)[reply]

Specifically regarding discussion threads, I created an experimental stylesheet to highlight the nesting levels. See User:Isaacl/style/discussion-threads for a mockup of how it looks. isaacl (talk) 23:28, 25 January 2025 (UTC)[reply]

Your style does something entirely different: instead of highlighting incorrect code, it just styles discussions a certain way. stjn 16:15, 26 January 2025 (UTC)[reply]

Yes, that's what I said. As a side effect, it makes it easy for me to see problems in list nesting levels, but doesn't highlight them. isaacl (talk) 17:06, 26 January 2025 (UTC)[reply]

Wikipedia:Manual of Style/Accessibility § Lists and Help:Talk pages § Indentation have the relevant guidance on nested lists, including not having blank lines between list items that are part of the same list. Wikipedia:Colons and asterisks is another page that is typically mentioned by others. My version is User:Isaacl/On wikitext list markup, where I show examples between the recommended markup and the unsemantic markup. In a nutshell, don't leave blank lines between list items, and when adding an additional nested level, copy the previous prefix and add an additional character (*, :, or #) to the end of the prefix string. isaacl (talk) 23:26, 25 January 2025 (UTC)[reply]

Weird, garbled, link encoding.

In T158577, I made a request for AWB to cleanup section-link encoding, e.g.

When you have a link such as

[[People%27s_Park_(Berkeley)#May_15.2C_1969:_.22Bloody_Thursday.22|Bloody Thursday]]

fix it to

[[People's Park (Berkeley)#May 15, 1969: "Bloody Thursday"|Bloody Thursday]]

However, turns out that the encoding that follows the section marker, #, isn't really encoding. It's exactly like % encoding, but with the percent signs switched to dots. This issue is fairly widespread, see [1] where I'm searching for the pattern .28[...].29, for a matching set of parens which would normally be encoded as %28[...]%29. I get about 8.5K hits, which includes some unrelated things, but that indicates the scale of the issue.

1) Does someone know the cause of such half-garbled links? Or can investigate to find it/have some insights? Most incidents I can find seem to have been added in the mid 2010s, e.g. [2]

2) Bot cleanup is likely needed on this. I haven't made a WP:BOTREQ yet, but bot/script coders and technical people might want to chime in on what might be involved for cleanup here. Even a better / more comprehensive regex search would be useful here. I've used round brackets for my search, but quotes (%22), ndash/mdashes, slashes/backslashes, and other %-encoded characters would likely be fruitful.

Headbomb {t · c · p · b} 12:39, 26 January 2025 (UTC)[reply]

Going to courtesy ping @Rjwilmsi: for whatever additional insights they may have. Headbomb {t · c · p · b} 12:40, 26 January 2025 (UTC)[reply]

The cause is that that's what MediaWiki used to generate. It was an XHTML4 thing that the anchor targets were "officially" restricted to a subset of ASCII characters, so "percent encoding with % changed to ." was used to turn section titles into valid anchor targets. Once MediaWiki switched to HTML5, anchor targets could contain basically any UTF-8.

I don't know that cleanup is really needed. The encoded targets are still also output so as to not break old links (as long as the target is still there at all). Unless MediaWiki devs have indicated that they plan to turn that off? Anomie ⚔ 13:30, 26 January 2025 (UTC)[reply]

BTW, note that the dot-encoding isn't necessarily trivially reversible. For example, while == 0% == produce an XHTML4-style anchor of "0.25", so does == 0.25 == because the dot itself is not encoded. Anomie ⚔ 14:13, 26 January 2025 (UTC)[reply]

Cleanup is needed in as much as things are extremely hard to read in the edit window. Look at the difference this makes. Headbomb {t · c · p · b} 14:19, 26 January 2025 (UTC)[reply]

That argument sounds very much WP:COSMETICBOT. Why should a bot go through these specifically, rather than letting people do it manually in cases like that article (or bots do it as general fixes along with a more substantive edit) as we do for other cosmetic things? While someone could argue that the changed fragment in the rendered link is (barely) non-cosmetic under the first bullet, since readers do see the fragment if they follow the link, you're not making that argument. Anomie ⚔ 14:32, 26 January 2025 (UTC)[reply]

I'm making the argument that this is extremely editor-hostile wikitext, and should be fixed to something sane, much like AWB already does for properly %-encoded links. Manual cleanup of this would be very, very tedious and error prone. Headbomb {t · c · p · b} 14:45, 26 January 2025 (UTC)[reply]

@Anomie: There's no such thing as XHTML4. There's XHTML 1.0, and there's HTML 4.0, with considerable overlap between the two specs, but with one being more restrictive than the other in certain areas. Prior to HTML5, our servers produced XHTML 1.0 pages. The relevant parts of the specs are C.8. Fragment Identifiers in XHTML 1.0 and the ID token in HTML 4.0, from which it is clear that the restriction prohibiting the percent sign was not with the URL fragment, but what it pointed to in the served page. --Redrose64 🌹 (talk) 17:07, 26 January 2025 (UTC)[reply]

Congratulations for being more technically correct. 🙄 I also shouldn't have said "anchor target". Anomie ⚔ 18:00, 26 January 2025 (UTC)[reply]

Anomie is exactly right, here's some additional context from the time the change was made: $wgFragmentMode, change 362326, T152540.

I would advise caution when changing these links automatically, as there are real section names out there that look just like this encoding – for example, IEEE 802.11#802.11-1997 (802.11 legacy) – and trying to "fix" them would break them. At minimum the bot would have the verify that the link still works after the change. Matma Rex talk 14:04, 27 January 2025 (UTC)[reply]

Archiving problem

Checking ref 15 in 1452/1453 mystery eruption I found that it was a bad link. I then checked it in the wayback machine and found that although the most recent copy on 2 April 2022 is also a bad link, there is a good copy dated 22 February 2003 at [3]. I ran the article through Analyse a page and it archived the recent bad copy, so the ref now has both the original and archived copies bad. Is this a weakness in 'Analyse a copy' and is there any way round it? Dudley Miles (talk) 14:15, 26 January 2025 (UTC)[reply]

@Dudley Miles: InternetArchiveBot determines which archive link to use by the access date, which was set incorrectly in this case. I've fixed both the link and the access date onwiki and fixed it as far as possible on the InternetArchiveBot side using this tool, which is linked from the "Fix dead links" tool via Toggle navigation/Manage URL Data/Manage individual URLs. Graham87 (talk) 00:32/03:59, 27 January 2025 (UTC)[reply]

Thanks Graham87. Dudley Miles (talk) 08:55, 27 January 2025 (UTC)[reply]

Why does pinging without a signature not work

Why does pinging without a signature not work?

What is the technical limitation that requires a signature?

Wouldn't it be easy for a bot to follow an EventStream and notify people of failed pings?

Why is my alleged "brain" incapable of doing it correctly the first time? Polygnotus (talk) 16:10, 26 January 2025 (UTC)[reply]

Because of edits that are NOT a reply ;) —TheDJ (talk • contribs) 17:08, 26 January 2025 (UTC)[reply]

Archiving would be a pleasure! win8x (talk) 17:26, 26 January 2025 (UTC)[reply]

My understanding is that it's a heuristic used to identify new comments, in order to avoid sending a notification when someone copy edits a comment, or moves a comment to a new location, for instance. isaacl (talk) 17:12, 26 January 2025 (UTC)[reply]

Yes, it's not a technical limitation but a deliberate feature. We don't want a lot of notifications when somebody makes manual archiving of a discussion or something like that. PrimeHunter (talk) 20:52, 26 January 2025 (UTC)[reply]

You can help your brain a lot by using the reply tool, instead of editing wikitext ;) Help:Talk pages#Reply tool Matma Rex talk 14:06, 27 January 2025 (UTC)[reply]

@Matma Rex: Unfortunately you can't add buttons to the reply tool, which means I would have to remember a bunch of stuff, which means it is more difficult, not less. This ticket is 4 years old. Polygnotus (talk) 19:12, 27 January 2025 (UTC)[reply]

Polygnotus, there's always WP:FACTOTUM. — Qwerfjkl talk 20:58, 27 January 2025 (UTC)[reply]

Qwerfjkl, there was a reason why I decided to not use Factotum. But to be honest I can't even remember what it was! I'll give it another try, thanks. — Polygnotus (talk) 01:06, 28 January 2025 (UTC)[reply]

You can; it's just complicated and outside the stable interface. Nardog (talk) 09:49, 28 January 2025 (UTC)[reply]

Page titling error

Hi, WP Technical Village Pump Team and happy belated New Year! I attempted to boldly move the Cartoon Network (British and Irish TV channel) page to Cartoon Network (United Kingdom and Ireland) on 24 January. I was expecting the software to deny it so I can instigate an RM for it, but strangely instead, it was granted and executed, only for the page to revert back to the prior title without any record on the page history except rather for the page history of my suggested title (see here and here for proof). Is something wrong with the bold-move mechanism of the software that's cusing this, as this is so new to me or because this is something I barely witness from the software's mechanisms? Intrisit (talk) 19:47, 26 January 2025 (UTC)[reply]

@Intrisit You moved the redirect Cartoon Network (British & Irish TV channel) to Cartoon Network (United Kingdom and Ireland), not the article Cartoon Network (British and Irish TV channel). Note that the redirect has an "&" in its title, while the article has an "and". 86.23.109.101 (talk) 20:28, 26 January 2025 (UTC)[reply]

Oh right! I now see the mistake!! Thanks, IP user!! Intrisit (talk) 20:34, 26 January 2025 (UTC)[reply]

@Intrisit: Generally speaking, redirects should almost never be moved. I see that there are now:

Cartoon Network (British and Irish TV channel) (edit | talk | history | protect | delete | links | watch | logs | views)
Cartoon Network (United Kingdom and Ireland) (edit | talk | history | protect | delete | links | watch | logs | views)
Cartoon Network (British & Irish TV channel) (edit | talk | history | protect | delete | links | watch | logs | views)

Some cleanup is required, but I'm not sure what. --Redrose64 🌹 (talk) 21:17, 26 January 2025 (UTC)[reply]

Is it possible to rollback vandalism without reverting subsequent good edits using Ultraviolet?

Basically IP address makes several questionable unsourced edits, but subsequent edits by another user were constructive and I don't want to undo them. SigillumVert (talk) 21:39, 26 January 2025 (UTC)[reply]

At worse, just readd it manually (stating you're doing so in the summary). Adam Cuerden ^(talk)_{Has about 8.8% of all FPs.} 21:45, 26 January 2025 (UTC)[reply]

I don't know about Ultraviolet, but the standard "Undo" feature can do that (as long as the subsequent edits haven't touched the same area of the article). Matma Rex talk 14:09, 27 January 2025 (UTC)[reply]

I'm not quite sure where this belongs, or even if it's an issue

But the Public PAWS thing (https://public-paws.wmcloud.org) is hosting copyright violations and general spam, which perhaps want to be purged. https://public-paws.wmcloud.org/72516402/?C=S&O=D

https://public-paws.wmcloud.org/76932120/ccminer/?C=S&O=D (crypto mining stuff? it's freely licensed, but anyway) https://public-paws.wmcloud.org/62136246/?C=S&O=D (more crypto stuff) Jay Cubby 03:45, 27 January 2025 (UTC)[reply]

PAWS is a part of Wikimedia Cloud Services (WMCS). wikitech:Help:Cloud Services introduction#Communication and support has details on how to contact the Cloud Services team. – DreamRimmer (talk) 04:45, 27 January 2025 (UTC)[reply]

Invisibly populated category redirects

Can anyone work out why Category:1951 events in Europe by month, Category:2007 events in Asia by month and Category:2008 events in Asia by month are appearing in Category:Wikipedia non-empty soft redirected categories? No contents are displayed, not even delayed caches, and yet they declare themselves non-empty. Timrollpickering (talk) 12:01, 27 January 2025 (UTC)[reply]

Probably the job queue being slow to update the categorylinks, or (less likely) it having dropped some jobs. When null-edited one of the cats, it disappeared from Category:Wikipedia non-empty soft redirected categories. Anomie ⚔ 12:10, 27 January 2025 (UTC)[reply]

Is there supposed to be a job for this? Category:1951 events in Europe by month has {{Category redirect}} which tests whether the category is non-empty and should be added to Category:Wikipedia non-empty soft redirected categories. If the category is emptied without editing the category page or any template it transcludes then I wouldn't expect the wikitext of the category page to be reparsed automatically but I don't know whether it happens. PrimeHunter (talk) 13:25, 27 January 2025 (UTC)[reply]

Yes, the MediaWiki servers should be re-parsing every page periodically, but they do not do so. See T132467, a long-standing feature request from 2016. (And the related T157670.) As far as I know, a cron job needs to be set up, but it has never been followed through on. I think Wbm1058 is still running a bot on the English Wikipedia to refresh stale pages, and that this query shows the current staleness of pages by date (the maximum appears to be 88 days right now). It is not great to be dependent on a bot for this critical maintenance, and 88 days of staleness is too much. It would be great to know that pages would never be more than X hours or days stale, with X being a small number. – Jonesey95 (talk) 15:07, 27 January 2025 (UTC)[reply]

I briefly discussed this matter with a Foundation employee at Wikiconference North America in Indianapolis last October. As the English wiki continues to grow, closing in on 7 million articles, it becomes technically more and more difficult to frequently work though the entire database and refresh each and every page, whether they need refreshed or not (the vast majority don't). At my bot's peak performance, I had the refresh lag down to about 30 days for mainspace and 80 days for all other namespaces. After the database was restructured last year, my bots struggled to keep up and the lag times increased substantially. Only recently, they've come back down to 41 and 87 days, and the "new normal" may be 40 and 90 days, rather than 30 and 80. My bots should be considered as equivalent to that "cron job" – basically, I think, if such an internal job were set up, I doubt it would be much more efficient or timely at refreshing links than my bots are. My bots should be viewed as a stopgap; the last line of defense insuring that a link possibly still needing to be refreshed is refreshed after 90 days, and not nine years. The path forward is to identify the links refreshed by my bot that actually needed to be refreshed, determine why they failed to get refreshed before my stopgap bot refreshed them, and then fix that issue in order to refresh them a lot more quickly than my bot refreshes them. To that end, Phabs like T132467 are helpful, and I suggest that a higher priority be placed on T132467 than T157670. I'll look closer at what needs to happen with T132467 – maybe I can develop yet another bot to address that specific issue. – wbm1058 (talk) 16:57, 27 January 2025 (UTC)[reply]

Probably worth mentioning this issue to the WMF annual plan and the community wishlist since both are open. Snævar (talk) 19:09, 29 January 2025 (UTC)[reply]

This particular category is an easy case to manage. I just ran a script to purge the cache of each member of the category, which quickly reduced the category membership from 90 to 30. Then I noticed that there were still newly-empty categories in this category, so I ran the script again, which reduced membership to 25. There were still newly-empty members, so I ran the script a third time and that kept the membership at 25 as just as many new members arrived as my script had just purged out. Is this category always so active, or is something special happening now to make it more active than usual? I can add this operation to my bot that runs twice hourly, or maybe run it even more frequently than twice an hour; that would keep the membership better, with a minimum number of short-term empty members. – wbm1058 (talk) 01:10, 28 January 2025 (UTC)[reply]

Looks like User:JJMC89 bot III is moving a bunch of categories for Wikipedia:Categories for discussion/Speedy#Current requests, which are apparently showing up in Category:Wikipedia non-empty soft redirected categories momentarily. Anomie ⚔ 01:19, 28 January 2025 (UTC)[reply]

Yes. Basically, there's an ongoing WP:CFD/S process to rename categories of the form "Date events in Foo" to "Date in Foo", that is, to remove the word "events" and one adjacent space. So for example Category:March 1979 events in North America has been moved to Category:March 1979 in North America. I think that it should have been a full CFD and not a speedy, but there you go. --Redrose64 🌹 (talk) 10:54, 28 January 2025 (UTC)[reply]

Addendum: as I typed the above, Category:March 1979 events in North America was in Category:Wikipedia non-empty soft redirected categories, and its cat page was listing March 1979 in Canada as a subcat, whereas a visit to Category:March 1979 in Canada showed the cat box containing March 1979 in North America. Visiting Category:March 1979 in North America did not list March 1979 in Canada as a subcat. I tried a WP:PURGE of all three categories, which had no effect (as I suspected it wouldn't), and then performed a WP:NULLEDIT of Category:March 1979 in Canada, which did not itself change, but it did cause both Category:March 1979 events in North America and Category:March 1979 in North America to be corrected, and the former to drop out of Category:Wikipedia non-empty soft redirected categories. --Redrose64 🌹 (talk) 11:04, 28 January 2025 (UTC)[reply]

Right, looking at Special:Log/move/JJMC89 bot III, that's the culprit. My understanding is that my "null edit" cache-purging bot enters tasks into the "job queue", or, rather usually executes its tasks nearly instantaneously, and its tasks only spend time waiting in the job queue at times when the system is particularly busy and overwhelmed by too many task requests being pushed at it simultaneously. The fact that my bot's purges are happening right away indicates to me that the page-moving software, which should be purging categories right after it moves them, isn't doing that. Search Phabricator for something like "Special:MovePage needs to purge the cache of Category: namespace pages immediately after moving them". I'm adding this to-do item to my MediaWiki core developers thread. Foundation management hasn't assigned the page-moving code to any employee's responsibilities as I guess they're waiting for volunteer me to push myself into the role. – wbm1058 (talk) 11:23, 28 January 2025 (UTC)[reply]

In the meantime, while waiting for Special:MovePage code fixes, maybe User:JJMC89 could enhance his bot to make it purge each category page right after it moves the category. Updating bot code is magnitudes easier than updating MediaWiki code. – wbm1058 (talk) 11:43, 28 January 2025 (UTC)[reply]

Looking at the timestamps of Redrose64's example, the category really was non-empty for a few seconds.

Category:March 1979 events in North America was moved at 2025-01-27 23:41:02. At this point it becomes a non-empty soft redirected category, and recentchanges indicates it was added to Category:Wikipedia non-empty soft redirected categories at this time.
Category:March 1979 events in North America had its template updated at 2025-01-27 23:41:04.
Havana Jam was removed from Category:March 1979 events in North America at 2025-01-27 23:41:08. At this point Category:March 1979 events in North America presumably becomes empty, but the category page isn't reparsed.

So for about 6 seconds from 23:41:02 to 23:41:08, Category:March 1979 events in North America really was a non-empty soft redirected category. Based on the mw.categorize entries in recentchanges, it looks like all three of the above edits did immediately update the category links. What didn't happen immediately is the re-parsing of Category:March 1979 events in North America to determine that it was now empty. If User:JJMC89 bot III was going to purge to have an effect here, it would have to have been after the Havana Jam edit emptied the category, not after the category was moved. Anomie ⚔ 13:02, 28 January 2025 (UTC)[reply]

Oh, I see. This bot is editing at an incredibly high speed. 42 edits at 23:59, 27 January 2025, that's like an edit every 1.4 seconds, a majority of them being page moves. – wbm1058 (talk) 14:14, 28 January 2025 (UTC)[reply]

Here is the bot's edit log for the relevant time span. March 1979 events in North America-related activity seems to be co-mingled with Novels with lesbian themes-related activity. What's the algorithm here? Are two separate instances of the bot running in parallel? wbm1058 (talk) 14:14, 28 January 2025 (UTC)[reply]

There's some misunderstanding here. A purge doesn't work, it must be a WP:NULLEDIT; and doing that on the moved category isn't any good either, it needs to be performed on the category's member pages. --Redrose64 🌹 (talk) 22:12, 28 January 2025 (UTC)[reply]

@Redrose64: Indeed. I use User:RMCD bot/botclasses.php function purgeCache($page), which in turn uses mw:API:Purge with |forcerecursivelinkupdate=1, which is more or less functionally equivalent to what you call a null edit. The category's member pages are indeed categories themselves. – wbm1058 (talk) 23:06, 28 January 2025 (UTC)[reply]

There can be up to two instances running at the same time, one for WP:CFD/W and one WP:CFD/W/L. This is so the large batches on CFD/W/L do not delay processing of the ones on CFD/W. Usually there is only one running since CFD/W/L is not used most of the time. — JJMC89 (T·C) 08:05, 29 January 2025 (UTC)[reply]

The bot makes a follow-up edit to the category after the move. I've reordered that step to after it recategorizes the contents instead of immediately after the move. That should remove the need to purge. — JJMC89 (T·C) 07:58, 29 January 2025 (UTC)[reply]

Thanks. An editor User:Gray eyes is creating category soft redirects (e.g., Category:Sports in Gdańsk, Category:Organizations based in Łódź, Category:Sports in Lublin) which are populating Category:Wikipedia non-empty soft redirected categories. I don't know why these empty soft redirects are populating the non-empty category, nor why they are being created in the first place, given that the template produces a message "Administrators: If this category name is unlikely to be entered on new pages, and all incoming links have been cleaned up, click here to delete." implying that these newly-created categories should be deleted. – wbm1058 (talk) 17:02, 29 January 2025 (UTC)[reply]

I had to use this template (Template:Sports clubs and teams in Fooland category header) to create a Category:Sports clubs and teams in Gdańsk. These categories will be automatically emptied. Gray eyes (talk) 06:22, 30 January 2025 (UTC)[reply]

OK, now there are hundreds of empty categories in Category:Wikipedia non-empty soft redirected categories. I'll add a twice-hourly purge/null-edit to my bot, to manage this issue as a stopgap, until the issue with the MediaWiki software is identified and fixed. Any time a category is removed from a page, I think a forcerecursivelinkupdate purge should be done. – wbm1058 (talk) 12:55, 30 January 2025 (UTC)[reply]

Tech News: 2025-05

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

Weekly highlight

Patrollers and admins - what information or context about edits or users could help you to make patroller or admin decisions more quickly or easily? The Wikimedia Foundation wants to hear from you to help guide its upcoming annual plan. Please consider sharing your thoughts on this and 13 other questions to shape the technical direction for next year.

Updates for editors

iOS Wikipedia App users worldwide can now access a personalized Year in Review feature, which provides insights based on their reading and editing history on Wikipedia. This project is part of a broader effort to help welcome new readers as they discover and interact with encyclopedic content.
Edit patrollers now have a new feature available that can highlight potentially problematic new pages. When a page is created with the same title as a page which was previously deleted, a tag ('Recreated') will now be added, which users can filter for in Special:RecentChanges and Special:NewPages. [4]
Later this week, there will be a new warning for editors if they attempt to create a redirect that links to another redirect (a double redirect). The feature will recommend that they link directly to the second redirect's target page. Thanks to the user SomeRandomDeveloper for this improvement. [5]
Wikimedia wikis allow WebAuthn-based second factor checks (such as hardware tokens) during login, but the feature is fragile and has very few users. The MediaWiki Platform team is temporarily disabling adding new WebAuthn keys, to avoid interfering with the rollout of SUL3 (single user login version 3). Existing keys are unaffected. [6]
View all 30 community-submitted tasks that were resolved last week.

Updates for technical contributors

For developers that use the MediaWiki History dumps: The Data Platform Engineering team has added a couple of new fields to these dumps, to support the Temporary Accounts initiative. If you maintain software that reads those dumps, please review your code and the updated documentation, since the order of the fields in the row will change. There will also be one field rename: in the mediawiki_user_history dump, the anonymous field will be renamed to is_anonymous. The changes will take effect with the next release of the dumps in February. [7]

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

MediaWiki message delivery 22:12, 27 January 2025 (UTC)[reply]

Unfathomable and hidden redirect

I moved a page today to deal with a misspelling (Under-occupied developments in China → Underoccupied developments in China — there is never a hyphen with the under— prefix), and of course I cleaned up all the things that go awry when one does this, including the redirects. There was one exception, though: Somehow, a whole lot of articles about Chinese ethnic minorities and foreign resident populations are linked to that old, misspelt title with the hyphen. I cannot find the link in any particular article. I was hoping that a single tweak of one template might banish all those articles from the "What links here" list, but I can't find it. I hope that somebody can get to the bottom of this. You will find the source of my annoyance here. What are all those ethnic articles doing there, linked to "Under-occupied developments in China"? And how are they linked? If somebody can find out and unlink them (for they really have nothing to do with China's underoccupied developments), that would be most helpful. The current situation is quite silly. Kelisi (talk) 22:48, 27 January 2025 (UTC)[reply]

The link in Template:Immigration to China, perhaps? Anomie ⚔ 23:18, 27 January 2025 (UTC)[reply]

Indeed, here's the template space links. Izno (talk) 23:19, 27 January 2025 (UTC)[reply]

Ahah! Yes, all the ethnicity titles are gone now. Thanks. — Preceding unsigned comment added by Kelisi (talk • contribs) 01:49, 28 January 2025 (UTC)[reply]

OK, this is not what you asked but — who says you never use a hyphen with "under"? I've never heard that at all. Both versions look OK to me, but the one with the hyphen looks a little better, and my browser puts red squigglies under the non-hyphenated version. --Trovatore (talk) 23:31, 27 January 2025 (UTC)[reply]

Trovatore, https://grammarist.com/spelling/over-under/ (this should not be interpreted as me picking a side, but you asked who says that and this is an example of someone saying that) — Polygnotus (talk) 01:13, 28 January 2025 (UTC)[reply]

That page actually says the hyphens are "not wrong". --Trovatore (talk) 02:37, 28 January 2025 (UTC)[reply]

Who says, indeed? Any English teacher, which is what my shingle says. That's who. Furthermore, any English teacher can tell you that only proper dictionaries and grammars are to be trusted, as no software publisher has ever come out with a thoroughly reliable spelling and grammar checker. Bear in mind, too, that as freely usable prefixes, over—, under— and out— can form many perfectly acceptable words that do not appear in dictionaries. Examples might include "overvigilant", "undercooked" (actually, that one is quite common, but I see that the wiki unaccountably puts a red squiggle under it), "overdrink", "outread" ( = "read more than"), "underperform" (and I think we've all heard that one, but nonetheless, there's that stupid squiggle again) or "outdance". The lesson there is to use a bit of sense. A word isn't wrong just because some witless computer puts a red squiggle under it. Kelisi (talk) 02:18, 28 January 2025 (UTC)[reply]

Kelisi, keep in mind that I don't know you. I don't even know that you're an English teacher; I know only that you say so.

Still, I have no active reason to doubt that, but this still does not remove my skepticism that "any" English teacher would agree with you.

So maybe you could point me to a reference that specifically backs up your claim. If you know of ones that don't, it would be a good show of intellectual rigor to mention those as well. --Trovatore (talk) 02:37, 28 January 2025 (UTC)[reply]

Mobile infobox placement

An editor noticed that on mobile view, the infobox for Syria is placed prior to the first paragraph, instead of the expected after the first paragraph. Looking throuhg its first paragraph links, Lebanon and Israel display the same behaviour, while Jordan and Turkey have the first paragraph first, as do Syrian transitional government, Mediterranean Sea, and Damascus. What is causing the difference for Syria, Lebanon, and Israel? CMD (talk) 02:34, 28 January 2025 (UTC)[reply]

@Chipmunkdavis: Mobile tries to move the infobox down a paragraph if it's at the start in the wikitext but sometimes it thinks certain templates before the infobox are a paragraph so the infobox shouldn't be moved further down. It can be tested by previewing the lead in mobile without different templates before the infobox. For Syria it appears to be {{pp|small=yes}}. PrimeHunter (talk) 09:26, 28 January 2025 (UTC)[reply]

Thanks. That seems a common enough template that I hope it's flagged somewhere. CMD (talk) 09:53, 28 January 2025 (UTC)[reply]

Proposal: Move User:Enterprisey/easy-brfa.js to the MediaWiki namespace

This proposal is not necessarily to turn User:Enterprisey/easy-brfa.js into a gadget, but rather to simply move it to that namespace. The idea behind this is so that people can go to Wikipedia:Bots/Requests for approval/request and just click a button, which would redirect them to that same page plus a parameter such as withJS=MediaWiki:Easy-brfa.js, allowing them to use the tool straight away without having to install it, similar to what we have at DRN. Enterprisey has expressed no objection to this idea off-wiki. JJP_{Mas_ter} (she/they) 01:51, 29 January 2025 (UTC)[reply]

Are you offering to maintain the script? If so, I'll move it. There's a brief earlier discussion at Wikipedia:Bots/Noticeboard/Archive 19#easy-brfa, where there weren't really any objections. – SD0001 (talk) 15:17, 29 January 2025 (UTC)[reply]

@SD0001: I don't know how I would be able to maintain it as a non-interface-admin, but if I could, then I would agree to do so. JJP_{Mas_ter} (she/they) 14:40, 30 January 2025 (UTC)[reply]

@Enterprisey: any comment? — xaosflux ^Talk 19:20, 30 January 2025 (UTC)[reply]

UserHoverStats: Show the Edit Count and Number of Articles Created

I'm working on learning Javascript and created a small script that will display the number of edits and articles an editor has made when the hover their mouse over an editors name. I was wondering if anyone could give me some feedback, ideas, improvements, dire warnings etc. This was mostly a fun little coding exercise for me so I don't know if people will find any use for it. Dr vulpes (Talk) 03:53, 29 January 2025 (UTC)[reply]

@Dr vulpes You might want to look at User:Chlod/Scripts/UserHighlighter, which has a similar hover text to show the user's groups. Might be something worth adding (minus the highlighting part). --Ahecht (TALK
PAGE) 19:24, 29 January 2025 (UTC)[reply]

@Ahecht thanks I'll take a look! My background is in R so I'm still getting used to Javascript in general. I've already found things I don't like about my script that I need to work out. Dr vulpes (Talk) 20:15, 29 January 2025 (UTC)[reply]

Cite errors

The 2024–25 Port Vale F.C. season article seems unable to recognise named references anymore when the reference name isn't in speech marks ([ref name = "quote"] works but not [ref name = quote]. I can't explain why that would be? Echetus Xe 09:36, 29 January 2025 (UTC)[reply]

It looks like two pages stuck together with Pritt stick. Why are there two Reference sections, two lots of defaultsort, two lots of categories? I suspect this is the source of your problems. DuncanHill (talk) 10:51, 29 January 2025 (UTC)[reply]

It's very odd, if I try to edit the whole page I only get down to the first reflist and set of nav templates and cats. DuncanHill (talk) 11:11, 29 January 2025 (UTC)[reply]

It looks like it was a problem on a transcluded page, this edit by @SKennedy157: seems to have fixed it. DuncanHill (talk) 11:26, 29 January 2025 (UTC)[reply]

ah thank you! Echetus Xe 15:43, 29 January 2025 (UTC)[reply]

Tool enabled without approval?

People here may be interested in or may shed light on Wikipedia talk:Short description#Wikimedia Apps/Team/Android/Machine Assisted Article Descriptions. Feel free to cross-post elsewhere or ping editors / WMF people if that seems useful. Fram (talk) 12:13, 29 January 2025 (UTC)[reply]

Massive, un-asked for, blanking

This has happened a few times, most recently here. I edit an article to fix an error, add my edit summary, preview, and then when I click "Publish changes" a gert lump of the article has disappeared. Edge on Win 11, Monobook. Any ideas what is happening and how to prevent it? — Preceding unsigned comment added by DuncanHill (talk • contribs) 12:16, 29 January 2025 (UTC)[reply]

Was there a delay before you published? I've sometimes done something similar when I make an edit and preview but then get distracted by real life. When I go back the publish only saves the section I'm working on. It seems associated with reloading the page (or the browser restarts) as the section isn't part of the url. — Jts1882 | talk 13:43, 29 January 2025 (UTC)[reply]

Maybe a slight delay, not more than a minute or two range, long enough to double-check I haven't missed or broken anything else. DuncanHill (talk) 17:55, 29 January 2025 (UTC)[reply]

I had the same thing happen at Template:SEC baseball record vs. opponent, which doesn't have sections. It was fine in the preview, but published with most of the text missing. Took a few days before Gonnym spotted the missing content. --Ahecht (TALK
PAGE) 19:26, 29 January 2025 (UTC)[reply]

Watchlist query

Resolved

I keep copies of my watchlisst on notepad++, do timed entries remain active and unchanged ? - FlightTime (open channel) 17:04, 29 January 2025 (UTC)[reply]

@FlightTime: Not sure I understand the question. We got Help:Watchlist#Temporarily_watching_pages and mw:Help:Watchlist_expiry. Polygnotus (talk) 18:37, 29 January 2025 (UTC)[reply]

When an entry expires it is removed from your watchlist. If you are exporting from /raw, the expiration time isn't included in the export - so if you were to clear and re-import from a text file the expiration time would be lost. — xaosflux ^Talk 19:55, 29 January 2025 (UTC)[reply]

@Xaosflux: Thank you. - FlightTime (open channel) 19:58, 29 January 2025 (UTC)[reply]

No deletion log for long-ago-deleted article

When I went to https://en.wikipedia.org/wiki/Resource_discovery, I was surprised to see a MediaWiki:thisisdeleted notice (View or undelete 2 deleted edits? (view logs for this page | view filter log)) but no deletion log entry, nothing like what you'll see if you visit the recently deleted https://en.wikipedia.org/wiki/Snape_kills_Dumbledore. (Sorry for external-style links, but the message there is different from the message you see on the edit screen.) Turns out that the article was deleted in 2004, when its entire content was:

{{delete}} I LOVE ALEXANDER DESPATIE

Is this normal behaviour for a page that was deleted so, so long ago and never recreated? Nyttend (talk) 20:28, 29 January 2025 (UTC)[reply]

Yes. The current log system dates back to December 2004. Older logs can be found at WP:Historical archive/Logs/Deletion log. * Pppery * _{it has begun...} 20:34, 29 January 2025 (UTC)[reply]
- Yes, indeed. The days when the deletion log was a list that people with deletion privileges maintained by hand. And there was no undeletion mechanism. And the deleted revisions table got cleared by the people who ran the servers every so often. Uncle G (talk) 14:48, 31 January 2025 (UTC)[reply]
@Nyttend: It's easy to check; go to Special:Log/delete, and on the line "(newest | oldest) View (newer 50 | older 50) (20 | 50 | 100 | 250 | 500)", click the "oldest" link. --Redrose64 🌹 (talk) 21:42, 29 January 2025 (UTC)[reply]

Creation of new citation template for the U.S. Gov Damage Assessment Toolkit (DAT)

The U.S. Government has a website called the Damage Assessment Toolkit (DAT). This website is an interactive map and database, where the National Oceanic and Atmospheric Administration uploads information regarding any tornado in the United States between roughly 2011 to 2025.

Note: This was directed to VPT by administrators after a decent discussion on the Wikipedia Discord Server.

Background of issue

The DAT (screenshot of it seen to the right; Image 1 & Image 2) is cited on hundreds of articles, including GAs and FAs. At several GANs/FACs, as well as on general article talk pages (and at the WikiProject Weather talk page), several users have expressed the desire for a separate citation template for the DAT. Why? Well, the screenshot to the right (Image 1) is a good example. The red line and subsequent triangles along the red line represent the U.S. government's information regarding the 2024 Greenfield tornado (92,000 page view article). The red line represents the track of the tornado and the triangles along the red line represent every "Damage Point" documented by the National Weather Service.

Each of these "Damage Point" triangles is clickable and by clicking the triangle, you can see it contains information. Image 3 to the right shows the information regarding a water tower hit by the 2023 Rolling Fork–Silver City tornado. This specific water tower is (1) actually discussed and mentioned directly in the Wikipedia article and (2) used as a photograph on the Tornadoes of 2023#March 24–27 (United States) article. In fact, that photograph is the photograph of it on the DAT. Since the DAT has photographs, the Commons has a stand-alone copyright-related template for it ({{PD-USGov-DAT}}). However, as seen in Image 3, the DAT does not just contain photographs. Specifically, information from the DAT is cited in the article including: The rating ("EF4") and the comments, "Collapsed water tower, bent just above near base, with anchoring pulled from concrete. Tank contained water, caused crater on ground impact. Potentially compromised by flying debris."

Now, why is this a problem? So, editors and readers alike have to manually change the date in the top right corner of the website (Image 1, Image 2) to match the date desired. The DAT is always being updated/changed, since hundreds of tornadoes occur in the U.S. every year. Because of this, the DAT automatically shows only the last week. Everything from more than a week ago is stored and accessible, by anyone, as long as the date is changed. For example, so see the DAT information for the 2013 Moore tornado (263,000-yearly viewed article), users need to change the date to May 19, 2013 to May 21, 2013. After the date is changed, users have to manually zoom into the area desired. The DAT shows the entire U.S. when it is first loaded up. Once loaded, users can zoom (just like on Google Maps) into the desired area.

To See this, I recommend setting the date from May 19, 2013 to May 21, 2013 and then zooming in on southern Oklahoma City, Oklahoma, to see the entire 2013 Moore tornado.

Due to the interactivity of the DAT, there is no "triangle-specific" or even "tornado-specific" URLs to cite; just the base DAT URL from above. This has led to some incidents of reviewers being unable to instantly verify the information and some other user having to explain how they can verify the information (Talk:2024 Greenfield tornado#Failed verification an example of this issue and subsequent discussion, where Sumanuil, a non-weather editor, was unable to verify the information in the article and another user (myself) had to explain how to verify the information).

What is being requested?

Since URL-specific citations are not able to be created, a citation template is being requested for it (even requested in the past at Wikipedia:Requested templates by Departure– in November 2024, which led nowhere).

The main things the DAT is used as a citation for on Wikipedia articles is the following items:

Tornado Tracks
- Tornado Length {how long was it on the ground for; distance}
- Tornado Width {how wide was the tornado; distance}
- Tornado Track comments {statements by the U.S. government on the tornado; press releases}
"Damage Points"
- The rating of the location(s) on the Enhanced Fujita scale
- Estimated wind speed at the location(s) {in miles-per-hour}
- Damage Point Comments {statements by the U.S. government on the tornado; press releases}

Is there a way for a template to be made which would allow users to cite the DAT-base URL and have options to specify the date, location, and then options for the different things above? The current citation for the DAT (as seen on the Tornadoes of 2024 article) is this: ^[1] The Weather Event Writer (Talk Page) 18:46, 30 January 2025 (UTC)[reply]

+1, this would be extremely beneficial to the tornado-space as a whole. A few articles that use the Damage Assessment Toolkit as a reference:

2011 Cullman–Arab tornado (GA)
2015 Garland tornado (GA)
Tornado outbreak and derecho of April 1–3, 2024 (GA)
2011 Ringgold–Apison tornado (GA)

I could name several more, but my point is proven. E_F⁵ 13:37, 31 January 2025 (UTC)[reply]

References

^ Branches of the National Oceanic and Atmospheric Administration; National Weather Service; National Severe Storms Laboratory (2024). "Damage Assessment Toolkit". DAT. United States Department of Commerce. Archived from the original on 2020-04-23. Retrieved 2024-01-20.

New button in IP contrib page, dead link

Hi, there's a new button in IP contributions page, labeled global contributions, that brings you to Special:GlobalContributions/whatever the IP is, that is broken (use Special:Contributions/127.0.0.1 as an example). I believe this is a new mw feature, as the special page does exist on meta wiki m:Special:GlobalContributions), but not yet on the English Wikipedia.

At mw:Trust and Safety Product/Temporary Accounts/Updates in section December it says

"Special:GlobalContributions will be able to display information about cross-wiki contributions from registered users, IP addresses, IP ranges, and temporary accounts in the near future. (T375632)".
Myrealnamm (💬Let's talk · 📜My work) 21:27, 30 January 2025 (UTC)[reply]

@Myrealnamm This is a known bug, see phab:T385086. The special page only exists on wikis with temporary accounts enabled. 86.23.109.101 (talk) 21:43, 30 January 2025 (UTC)[reply]

great… Thanks for the reference! Myrealnamm (💬Let's talk · 📜My work) 22:00, 30 January 2025 (UTC)[reply]

I have used MediaWiki:Nospecialpagetext to add a message to pages like Special:GlobalContributions/86.23.109.101 which is linked on Special:Contributions/86.23.109.101. PrimeHunter (talk) 00:30, 31 January 2025 (UTC)[reply]

[DAT-1] Branches of the National Oceanic and Atmospheric Administration; National Weather Service; National Severe Storms Laboratory (2024). "Damage Assessment Toolkit". DAT. United States Department of Commerce. Archived from the original on 2020-04-23. Retrieved 2024-01-20.

[1]