On the WP:Vital articles pages for each level, there is a random article button on each level as well as each category. Originally, the random article button was for the top-level categories beginning with Category:Wikipedia level-1 vital articles, level 2, level 3, and so on, but the articles are now sorted by article quality and category. I put a temporary solution in to combine multiple categories into one, but I am hoping for a solution that randomizes the vital articles better. I particularly like this feature of vital article for two reasons. Obviously, one is to improve the articles, but I also find it a neat way to read random articles as a reader. Any ideas on how I can do this? Interstellarity (talk) 00:50, 12 February 2025 (UTC)[reply]

As far as I know, this is not possible. Categories can be infinitely deep, so you cannot 'randomly' select something from them. That's why using subcategories is often not a good idea and have multiple categories is better, especially when you are essentially applying labels to something. —TheDJ (talk • contribs) 10:16, 12 February 2025 (UTC)[reply]

It's not a one-button solution and there's a bit of a learning curve, but PetScan can do this. All talk pages descending from Category:Wikipedia level-3 vital articles (depth 2) in random order. —Cryptic 10:45, 12 February 2025 (UTC)[reply]

@Cryptic Where can I ask for help using this tool to create a button? The only thing I've been able to do is for the articles to go into mainspace rather than talk space, which is a step in the right direction, but it's not what I'm looking for in the final outcome. I am hoping that whatever help you can provide me, whether it's asking somewhere else or from you, that would be great. Interstellarity (talk) 15:38, 13 February 2025 (UTC)[reply]

Interstellarity, here? This is the technical village pump. For instance, under Other sources > Namespaces you can select "Change to talk page". — Qwerfjkltalk 13:15, 14 February 2025 (UTC)[reply]

That's not what I wanted. I wanted to the random articles to go to the main namespace, not the talk namespace. Interstellarity (talk) 13:47, 14 February 2025 (UTC)[reply]

@Interstellarity Try toolforge:randomincategory, e.g. toolforge:randomincategory/B-Class_level-1_vital_articles&category2=C-Class_level-1_vital_articles&category3=FA-Class_level-1_vital_articles&category4=GA-Class_level-1_vital_articles&category5=Start-Class_level-1_vital_articles --Ahecht (TALK
PAGE) 20:48, 18 February 2025 (UTC)[reply]

@Ahecht: That's basically what the current script is based on. I was hoping for a simpler solution, but I'm assuming that's the best you could come up with. Interstellarity (talk) 23:21, 18 February 2025 (UTC)[reply]

@Interstellarity if I have a chance, I'll look into having randomincategory traverse a single level of child categories. There would be a significant impact on the time it takes to run the script, so I'd have to see how feasible it is. --Ahecht (TALK
PAGE) 13:50, 19 February 2025 (UTC)[reply]

@Ahecht Thank you for your help. I really appreciate it. Interstellarity (talk) 21:03, 19 February 2025 (UTC)[reply]

Hi all. Ideally there'd be a way to combine and automate the whole final inflation statement I want to see in prose, that I already had to break into three different templates. Here's where I am: approximately {{US$|474 million|long=no}} (equivalent to ${{formatprice|{{inflation|US|474000000|1993|r=3}}}} in {{Inflation-year|USD}})

If not, can someone suggest a way to correct the ${{formatprice|{{inflation|US|474000000|1993|r=3}}}} in {{Inflation-year|USD}} syntax that generates the weird output "$1000 million" upon the rendered page? It needs to say "$1 billion", lol.

Should I, at least temporarily, manually use expr and the word "billion" without violating WP:OR? Is it not OR if the numerical lead is calculated? approximately {{US$|474 million|long=no}} (equivalent to ${{formatnum:{{#expr:{{inflation|US|474000000|1993|r=3}}/1000000000 round 0}}}} billion in {{Inflation-year|USD}})

The examples above are for Crystal Pepsi where it doesn't work, and I don't know why Great Flood of 1951 does seem to work. And I wish both could be one template! ;)

Long ago, I scoured for a fix and posted an unanswered comment on the template's Talk page here. @Jonesey95: I was hoping you'd know. Thanks! — Smuckola(talk) 07:58, 17 February 2025 (UTC)[reply]

You're getting "$1000 million" because the value of {{inflation|US|474000000|1993|r=3}} is currently 999756738.079. So first {{format price}} decides that's best expressed "999.756738079 million" and then it rounds that up to "1000 million". A workaround might be to do |r=-6 to round the inflation value to millions before it's passed to {{format price}}, like {{formatprice|{{inflation|US|474000000|1993|r=-6}}}} → 1.03 billion. Anomie⚔ 12:25, 17 February 2025 (UTC)[reply]

@Anomie: Ok thanks a lot. Should I use -6 for all millions of dollars? Or just for output above $1 billion? And is the syntax otherwise optimal? It can't be combined into fewer templates? — Smuckola(talk) 23:15, 17 February 2025 (UTC)[reply]

To quote {{inflation}}'s docpage: It is advisable to avoid false precision; even if the start value is known to be exact, the template's result will not be because the inflation index tables are rarely accurate to more than about 1%, and a granularity of whole years is used.

In short, giving more than 2 or 3 significant digits in the output is rarely desirable. Because of how the template's written you have to change the value of the r= part based on how many decimal places are in the output value (unlike {{convert}} which has a sigfig= option). Presumably it'd be possible to add one of those to inflation as well...

It's certainly possible to write a wrapper template that just passes the arguments through to {{format price|{{inflation|...}}}}. I take it no one has done it because they didn't feel like bothering. --Slowking Man (talk) 03:11, 18 February 2025 (UTC)[reply]

What's wrong with "$1000 million"? One billion is 1000 millions (short scale, anyway). In some situations it might make more sense to talk about "1000 million", just as we sometimes say "12 hundred" instead of "one thousand two hundred". --User:Khajidha (talk) (contributions) 14:26, 18 February 2025 (UTC)[reply]

I mean there's nothing "wrong" with it in the most fundamental sense of "conveying false information". But it's not idiomatic English, and has a likelihood of confusing readers. This deviates a bit from MOS:NUMBERS. (Personally, I hate the "12 hundred" stuff as it can trip me up when reading. Just gimme the numbers, keep it simple! Eyy, I'm readin' heah!) --Slowking Man (talk) 21:39, 18 February 2025 (UTC)[reply]

Not idiomatic for who? I would tend to use "thousand million" in any situation where only a few values ranged into the billions to make the comparison to many values in the millions clearer.--User:Khajidha (talk) (contributions) 17:02, 19 February 2025 (UTC)[reply]

MediaWiki message delivery 21:18, 17 February 2025 (UTC)[reply]

Some scripts that seem to be affected by the last item:

--Ahecht (TALK
PAGE) 21:53, 18 February 2025 (UTC)[reply]

So how do we fix it? Mine was just copied from another script, but I don't know the scripting well enough to fix the issue. Please ping me in any replies to me. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 23:20, 18 February 2025 (UTC)[reply]

Nihonjoe,
1. remove 'mediawiki.Uri', from your mw.loader.using line
2. replace the line var uri = new mw.Uri(url); with var uri = new URL(url);
3. replace !$.isEmptyObject(uri.query) with uri.searchParams.size == 0
4. replace uri.path.slice with uri.pathname.slice
To play with this yourself, open the browser console and compare the objects that new mw.Uri('https://developer.mozilla.org/en-US/docs/Web/API/URL/URL?var=test') and new URL('https://developer.mozilla.org/en-US/docs/Web/API/URL/URL?var=test') produce. — Alexis Jazz (talk or ping me) 23:54, 18 February 2025 (UTC)[reply]

@Alexis Jazz: Thanks! How does it look now? ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 00:54, 19 February 2025 (UTC)[reply]

Nihonjoe, looks like you implemented the changes as I suggested. Note that I seem to have made a mistake, it should say uri.searchParams.size > 0 instead of equals zero.
I didn't test any of it, so you should verify that the script still works as intended. — Alexis Jazz (talk or ping me) 05:26, 19 February 2025 (UTC)[reply]

Okay, updated. It still seems to be highlighting as intended. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 17:54, 19 February 2025 (UTC)[reply]

@Alexis Jazz, Nihonjoe, Pythoncoder, The Wordsmith, and TheSandDoctor: I believe #2 should be var uri = new URL(linkraw.href);, since $(linkraw).attr('href') will return the relative URL but linkraw.href will return the fully-resolved URL that URL() is expecting. --Ahecht (TALK
PAGE) 21:05, 20 February 2025 (UTC)[reply]

@Ahecht: Does this look good now? ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 23:49, 20 February 2025 (UTC)[reply]

Done, thanks! The Wordsmith^{Talk to me} 03:04, 21 February 2025 (UTC)[reply]

Thank you very much for the instructions. As it happens, they applied perfectly to my script, which was another user highlighter fork, which was also largely a copy-paste job. It's also the motivation I need to make a more meaningful update to the script, because I've noticed some parts of it starting to break. —pythoncoder (talk | contribs) 05:50, 20 February 2025 (UTC)[reply]

Thanks for the notice, Ahecht! I've fixed up my script. :) Chlod (say hi!) 03:47, 19 February 2025 (UTC)[reply]

Likewise. Saw it yesterday, just in time for the kids' vacation! ~ Amory (u • t • c) 04:28, 19 February 2025 (UTC)[reply]

Thanks for the note. Have fixed the two of those, as well as MediaWiki:Gadget-dark-mode-toggle.js. – SD0001 (talk) 15:31, 19 February 2025 (UTC)[reply]

Thanks for the ping. I made the change here, does that look like it is now compliant? The Wordsmith^{Talk to me} 17:34, 19 February 2025 (UTC)[reply]

Thank you for the ping, Ahecht, and the notes above, Alexis Jazz. I've now updated mine for the first time since...2018! Been a while haha. --TheSandDoctor ^Talk 21:54, 19 February 2025 (UTC)[reply]

I haven't touched that user script in awhile. Ended up writing a bunch of unit tests before I did my refactor. Fun nerd snipe :) –Novem Linguae (talk) 22:44, 19 February 2025 (UTC)[reply]

I just fixed all three of mine. — Mr. Stradivarius ^{♪ talk ♪} 15:21, 20 February 2025 (UTC)[reply]

Hi everyone,

I’m seeking consensus to file a BRFA for testing a new ML tool that detects usernames likely to violate WP:USERNAME. Over the past week, I’ve developed a DeBERTa‑based model that assigns a risk score (0–100) to each new username detecting everything from blatant vandalism to subtle promotional names based on how likely it is to violate our policies. On the validation set, its false positive rate is under 1% (though real-world performance might be slightly different). The way the model works is very similar to how the model of an existing ML-based bot, ClueBot, functions.

You can review a demo on a sample (not every single one) from last week’s new usernames at User:MolecularBot/UsernameRisk. I’m happy to test any usernames through the model on request and answer any questions about the model or its training data.

The demo shows that while the model is multilingual (it detected German death threats and Chinese promotional names, and flagged fine usernames in another langur as low-risk), its primary strength is English. Most usernames scoring 95%+ genuinely violate our policies and should be reported to UAA. We already have a UAA reporting bot, DeltaQuadBot, which is very useful but due to its nature (regular expression) has a significantly lower accuracy (I would say the majority of usernames it reports aren't violations), so I don't see why a new bot that could pick up some additional violations that DQB misses (and is much more accurate) would be objected to adding some usernames to UAA in addition to the ones the other bot picks up, but am of course open and ready to address any concerns. A concerning amount of usernames the model would have reported are still unblocked and weren't picked up by humans or DQB, highlighting the need for this. Also I think the model is probably more accurate than the average user reporting to UAA, not just the DQB.

I propose two options:

Option 1: Use the DeBERTa model alone. Usernames with a risk ≥95% would be reported to UAA (in a new "ML bot reported" section), unless already flagged by DeltaQuadBot or a human. See the demo link above to see which usernames would have been reported to UAA in the past week.

Option 2: Implement a dual-model setup. Since my DeBERTa is a binary classifier, it doesn't tell us how "bad" a username is in terms of how severely it violates the policies, but rather just how likely it is to violate. Silly but harmless usernames like "Poop pee butt", death threats and blatantly promotional usernames are all rated the same likelihood because they are all blatantly obvious, even thought the violations are different seventies.

This is why, I developed a second model—a fine-tuned version of Gemma (Google’s open-source Gemini)—to recommend specific actions based on context. I want to be clear this isn't just giving the usernames to a generalist LLM that can make mistakes or hallucinations, the last few "layers" have been replaced and retrained to keep the contextual understanding in the upper layers of the model - important for understanding the username policies and all the context of the username but make it highly accurate and specific to username analysis (it will not work with any other LLM tasks anymore). Only usernames scoring above 90 by DeBERTa would be passed to Gemma, which can suggest one of the following:

• File a UAA report (this is what the bot would do 100% of the time without Gemma)
• Leave a TP warning and report to UAA if there are mainspace edits afterwards (this is mainly for promotional usernames, as this is basically what most admins do when a UAA is filed for these (warn and wait for mainspace edits), so there's no need to file a UAA right away).
• Just leave a TP warning (used for "silly" names that are picked up by DeBERTa like "Poopoopolice" or "TurtleButt420" that aren't UAA-worthy but the user should still know)
• Take no action (Gemma basically catches every single false positive from the other model, both models working together means that together there are incredibility low rate of false positives, almost less than 0.1% on the validation set, because both of them need to make a mistake in order for there to be one)

This dual approach would tailor our response and reduce unnecessary reports. Examples of Gemma’s recommendations based on usernames flagged by DeBERTa can be seen at User:MolecularBot/UsernameRiskCombined.

I welcome your feedback and am ready to address any questions or concerns. MolecularPilot ^{🧪️✈️} 01:52, 19 February 2025 (UTC)[reply]

Support option 2, as proposer. I believe option 2 is much more accurate at determining what should actually be reported to UAA. MolecularPilot ^{🧪️✈️} 01:54, 19 February 2025 (UTC)[reply]

Option 2 sounds good to me. The descriptions from Gemma look a bit verbose and UAA admins are likely capable of figuring out why a bad username is bad, so might want to think about making them shorter, removing them altogether, or including them as small text. – SD0001 (talk) 11:27, 19 February 2025 (UTC)[reply]

Also, I wonder if "no action" should be really be an option available to Gemma. Usernames like Zane eats toes, BOBTHEEDITORCANHEEDITITBOBTHEEDITORYESHECAN sound disruptive and are probably worthy of some action like a {{uw-username}} template, but folks more familiar with UAA can comment on this. – SD0001 (talk) 11:33, 19 February 2025 (UTC)[reply]

I've been experimenting with making them shorter for the past few days, you can see my progress at User:MolecularBot/UsernameRiskCombinedConsice (probably still a bit long imo), but thanks for the suggestion, it's definitely something I'm trying to get right! :) MolecularPilot ^{🧪️✈️} 21:05, 19 February 2025 (UTC)[reply]

I'm a bit concerned at the number of names. Your sample has approx 700 hundred names between scores 99-90. So maybe 100 usernames reported to UAA a day? A quick count for yesterday shows 42 names reported by humans, and 17 bot reported names. My concern is there is already a high number of names reported to UAA, that don't warrant administrator intervention, and I think this will just add to the problem. A quick scan through the names on your list shows a large number of names that purely on the name alone, do not warrant a block. --Chris 12:42, 19 February 2025 (UTC)[reply]

Hi Chris G! I'm not sure what you mean that names that would be reported to UAA from the list wouldn't warrant a block, in the model version that I'm proposing here (see User:MolecularBot/UsernameRiskCombined) I'd say almost every name in the "UAA report" section would warrant a hard indef, are there any you disagree with? MolecularPilot ^{🧪️✈️} 21:33, 19 February 2025 (UTC)[reply]

And there's certainly not 700, unless you are referring to the option 1 model (User:MolecularBot/UsernameRisk), where the proposal was only for 95%+ not 90% and I would say the majority of usernames in that section violate in some way (but are not all bad enough for UAA). Option 1 was only provided in case people were against the idea of a fine-tuned LLM sorting usernames, the option 2 model combination (linked above) performs much better and only reports very few, severe violations (some of which were actually missed by humans and the existing regex bot. MolecularPilot ^{🧪️✈️} 21:47, 19 February 2025 (UTC)[reply]

As a general note, WP:VPT is a good place for sorting out technical questions. This sounds more like a question for specifically WT:UAA and/or WP:VPPRO. Izno (talk) 20:11, 19 February 2025 (UTC)[reply]

Noted, I'll use VPPro or a more specific talk page next time, I assumed a bot was "technical"! :) MolecularPilot ^{🧪️✈️} 22:56, 19 February 2025 (UTC)[reply]

@MolecularPilot In general, leaving a TP note AND reporting to UAA is considered bad form. Either it's blatant, in which case the documentation of {{uw-username}} says the template shouldn't be used and it and should be reported directly to UAA, or it's not blatant and you should leave a note and only report to UAA if they edit again without addressing the username issue. --Ahecht (TALK
PAGE) 22:35, 19 February 2025 (UTC)[reply]

Hi Ahecht! What you said last is exactly what it does ("you should leave a note and only report to UAA if they edit again without addressing the username issue"), it never leaves a note than then immediately reports to UAA it will only:

• immediate UAA, no note, or
• leave a note, and if the user edits mainspace after the note report to UAA (this is what you said, and it's an option it has)
• just a note

depending on the severity. MolecularPilot ^{🧪️✈️} 22:47, 19 February 2025 (UTC)[reply]

Is there a way to discover if a visible anchor e.g {{va|Commodity – Part 1|Commodity}} is actually being used in any other article to link to the article with the anchor? The reason for asking is that List of Silent Witness episodes has a visible anchor for almost every episode title (there's 258 of them) and I don't think any of the anchors are actually being used. I've checked 12 random articles that link to it and all of them use the episode number anchor that is a function of the Episode table template e.g List of Silent Witness episodes#ep67. Or is it going to be a case of checking each article that links to it? - X201 (talk) 08:55, 19 February 2025 (UTC)[reply]

X201, it's also possible that external sites link to the anchor. — Qwerfjkltalk 09:33, 19 February 2025 (UTC)[reply]

@X201Manually checking all the source links (see user gadget User:PrimeHunter/Source links.js

) will omit transclusions via a template and is a practical way to check each wiki-coded instance.

Here is an absolute url example where you can replace Tesla and unions § United States with whatever sectioned example you want.

As others said, it could be externally linked (but that's not going to be reliable anyways. It will also match anchor templates like {{Section link}}, {{See also}}, {{Main}} which can all link to a section. ~ 🦝 Shushugah (he/him • talk) 20:08, 19 February 2025 (UTC)[reply]

@Shushugah: Thanks for that. Both options give me the answers I was looking for. - X201 (talk) 08:31, 20 February 2025 (UTC)[reply]

See Template talk:Infobox Belgium municipality#Local parameter doesn't work, template gives incorrect province. Basically, Zwijndrecht, Belgium recently switched from one province to another, but the infobox "province" info is based on an official number ("niscode") which didn't change (the "subdivision_name3" in the template code), and the manual overrides suggested at the infobox doc don't work. Only solutions I can think of is to remove the infobox completely, which seems like overkill, or to add a fake niscode, which replaces one bit of wrong info with another. Completely removing the niscode from the infobox makes it even worse. It would be appreciated if someone could make the manual override value actually work. Fram (talk) 15:47, 19 February 2025 (UTC)[reply]

 Done, let me know if you see any issues with the change, Fram. Writ Keeper ⚇♔ 16:36, 19 February 2025 (UTC)[reply]

Thanks, looks good! Fram (talk) 16:43, 19 February 2025 (UTC)[reply]

Fwiw, I updated the template documentation to reflect the actual operation of those parameters. region and community both also work like province used to; that is, only used if the NIS was absent. Manual overrides could be implemented for those in the same way as with province, but I decided not to do that unless there's a need, to avoid possible disruption elsewhere. But at least now the template docs aren't misleading. Writ Keeper ⚇♔ 16:54, 19 February 2025 (UTC)[reply]

Is there a way to hide an HTML element appearing on Event:Sandbox, using inline css/js or another way? I do not want users with the eventcoordinator permission to accidentally register the event, simply because the page is prefixed with Event:

The html div that should be hidden contains css class .ext-campaignevents-eventpage-enableheader ~ 🦝 Shushugah (he/him • talk) 19:13, 19 February 2025 (UTC)[reply]

I looked at the code and it turns out only the author sees that so there's no need to do anything. * Pppery * _{it has begun...} 20:27, 19 February 2025 (UTC)[reply]

@Pppery that makes this request moot (though I am still curious how it could be achieved). This would also make collaboration with different parties more challenging, e.g someone preparing a page creation, another person registering it. I am curious about page-swapping etc... now but these are edge-cases... ~ 🦝 Shushugah (he/him • talk) 21:01, 19 February 2025 (UTC)[reply]

Probably the least unreasonable way to achieve this would be a CSS-only hidden template gadget. By design nobody other than interface admins can add custom styling for things outside .mw-parser-output, which this isn't. Or (in an alternate universe where that check didn't exist), someone could file a request on Phabricator asking for a __NOEVENT__ magic word to solve the problem at the root. * Pppery * _{it has begun...} 21:03, 19 February 2025 (UTC)[reply]

CSS provides two properties which may be used to hide content. They are the display property and the visibility: property. They accept different values, and have different effects. For example, if an element is subject to the declaration display:none, it is physically removed from the rendered page - preceding and succeeding elements are presented adjacent to one another. But when an element is subject to the declaration visibility:hidden, it is replaced with blank space. Examples: The text following this has display:none. →This text has display:none.← The text preceding this has display:none. The text following this has visibility:hidden. →This text has visibility:hidden.← The text preceding this has visibility:hidden. --Redrose64 🌹 (talk) 22:08, 19 February 2025 (UTC)[reply]

@Redrose64 this is a good solution when the html wikitext is directly inline and I can create inline styling, but in this case the HTML is injected elsehow. ~ 🦝 Shushugah (he/him • talk) 22:23, 20 February 2025 (UTC)[reply]

Where some HTML "comes from" makes no difference, in regards to CSS style rules. That's why Pppery recommended a template gadget, which would add CSS rules which apply to the entire page. --Slowking Man (talk) 22:26, 23 February 2025 (UTC)[reply]

Is there a style guide for images and artwork, particularly how we're handling the transition to supporting both dark and light themes? A lot of articles have SVG artwork that's black-on-transparent and thus invisible on the dark theme. And I was going to ask how to fix this, perhaps there's a way to make SVGs the same color as the text, or maybe resort to giving these SVGs a white canvas. idk.

And are there any automated tools for this job, or is this something that we'd have to pick through manually? It sounds tricky, because obviously not all SVGs need fixed. Some SVGs do adapt to dark/light themes, matching the text color. Some don't. How could you automatically detect this?

Examples: Elder Futhark#Rune names, Runes#Younger Futhark (9th to 11th centuries) NomadicVoxel (talk) 19:02, 20 February 2025 (UTC)[reply]

@NomadicVoxel See Help:Pictures#Dark mode. --Ahecht (TALK
PAGE) 19:57, 20 February 2025 (UTC)[reply]

Oh thanks. NomadicVoxel (talk) 00:04, 21 February 2025 (UTC)[reply]

No automated tools for dark mode images have been implemented in Wikipedia yet, but a possible tool has been mentioned here, here, and here.

I also suggested the possibility of adding a white background to dark images here, but I do not know the progress on it. LightNightLights (talk • contribs) 07:59, 21 February 2025 (UTC) (edited LightNightLights (talk • contribs) 08:07, 21 February 2025 (UTC))[reply]

I made some edits today to the "Ultraconservatism" page. I did not have a user name, but after I published the edit I registered. Can my user name be added to the edits I made? Don Friedmann (talk) 19:15, 20 February 2025 (UTC)[reply]

No, this can't be done. Sjoerd de Bruin (talk) 19:19, 20 February 2025 (UTC)[reply]

But you could do a further edit, and claim that you are the same person as did the anonymous edits, in your edit summary. Graeme Bartlett (talk) 04:42, 21 February 2025 (UTC)[reply]

@Don Friedmann: If you want the IP address hidden then see Wikipedia:Oversight. It cannot be replaced with your username. PrimeHunter (talk) 10:26, 21 February 2025 (UTC)[reply]

Wikipedia:Content_assessment#Statistics has a handy list of articles by assessment, but the total number of articles differs from the official count at Special:Statistics. Folks on Discord suggested this is because the "???" column includes redirects. A couple questions, then: (1) How can we exclude redirects from that sort of calculation? (2) are there really that few redirects? — Rhododendrites ^talk \\ 20:06, 20 February 2025 (UTC)[reply]

@Rhododendrites articles without a corresponding talk page wouldn't appear in Wikipedia:Content_assessment ~ 🦝 Shushugah (he/him • talk) 22:25, 20 February 2025 (UTC)[reply]

Right, and neither would talk pages without a WikiProject banner. But the total at Wikipedia:Content assessment#Statistics is around 1.2 million larger than "Content pages" (mainspace pages excluding redirects) at Special:Statistics. There are far more redirects than that but many of them have no talk page or it has no WikiProject banner. Maybe talk pages of redirects are included in Wikipedia:Content assessment#Statistics if they have a WikiProject banner. It depends how the bot is coded. PrimeHunter (talk) 22:49, 20 February 2025 (UTC)[reply]

{{asbox}} has 2,383,450 transclusions, according to toolforge. Does that help? – Jonesey95 (talk) 01:49, 21 February 2025 (UTC)[reply]

Checking size of Category:All stub articles is probably more accurate, currently 2,331,844. – SD0001 (talk) 09:26, 21 February 2025 (UTC)[reply]

Querying count of non-redirect articles by byte size would be a better gauge. I don't know who/how that can be done. ~ 🦝 Shushugah (he/him • talk) 22:26, 21 February 2025 (UTC)[reply]

How big should talk page archives be? Is there ever an issue with loading talk page archives that are somehow too big? Is there an optimal size? Thanks, — Preceding unsigned comment added by Shearonink (talk • contribs) 04:12, 21 February 2025 (UTC)[reply]

This guidance says no more than 512K. I find that yearly archives (see the config box at the top of User talk:Jonesey95) make the most sense to me, and that my yearly archives do not come close to this recommended number. – Jonesey95 (talk) 04:57, 21 February 2025 (UTC)[reply]

I should have been more clear. I am concerned about article talk and their individual archive pages. Having individual talk archive pages be a 500K size seems somewhat unwieldy. When they get too big isn't that supposed to sometimes cause loading issues? - Shearonink (talk) 05:45, 21 February 2025 (UTC)[reply]

Not really. A bad case would be mobile. The average mobile internet connection overall is 6 Megabytes/second, so you would need over 100 thumbnails at default resolution to fill that along with a 500kb talk page. On top of that mobile has headings collapsed by default, so going through them is not that much of a pain. Snævar (talk) 20:44, 21 February 2025 (UTC)[reply]

The hard limit is 2000K, which is the maximum page size allowed by MediaWiki. You will start seeing rendering issues as you get close to this number, when templates used on the page cause it to exceed the post-expand include size. Personally, I feel like large pages become unpleasant to use around the 100K mark. Matma Rex talk 01:46, 22 February 2025 (UTC)[reply]

The default archive setting for Cluebot is 75k, while it's 150k for Lowercase sigmabot. Anything greater than 500k is going to start being an issue for some editors, remember not everyone has access is to the best technology. -- LCU ActivelyDisinterested «@» °∆t° 11:10, 23 February 2025 (UTC)[reply]

Something is creating a red-linked eponymous category in John Michael Montgomery and I can't figure out what. I can't find any category coding anywhere in the text. I've tried removing whole chunks and nothing seems to remove the category. What's causing this glitch? Ten Pound Hammer • ^{(What did I screw up now?)} 16:41, 21 February 2025 (UTC)[reply]

It was a mistake up in the 1998 section, where category and file markup were combined. Fixed now. --SarekOfVulcan (talk) 16:46, 21 February 2025 (UTC)[reply]

The Tools option on the Wikipedia talk:WikiProject Languages page is not working properly. Arbabi second (talk) 18:31, 21 February 2025 (UTC)[reply]

@اربابی دوم: I don't see a problem. Please be more specific. Does it work if you log out? PrimeHunter (talk) 22:17, 21 February 2025 (UTC)[reply]

@PrimeHunter

Look at the list of tools options and compare them to other pages. For example, there is no Wikidata item option. The problem is that the Persian page similar to Wikipedia talk:WikiProject Languages ​​linked to a Super-seeding article instead of the English version. But it seems to be under repair right now. Arbabi second (talk) 22:54, 21 February 2025 (UTC)[reply]

@اربابی دوم: Lots of pages have no Wikidata item and talk pages cannot have them at all. Please describe the perceived problem from the beginning another time. PrimeHunter (talk) 00:31, 22 February 2025 (UTC)[reply]

@PrimeHunter

The problem is quite simple. Please note. Wikipedia talk:WikiProject Languages ​​should link to versions of the same page on other language wikis. ویکی‌پدیا:زبان و زبان‌شناسی is linked to 26 languages. But instead of Wikipedia talk:WikiProject Languages ​​it is linked toSuper-seeding. The rest of the languages ​​have inter-language links. English also had correct links to 26 languages ​​until last night. The English link to Persian was also correct. But now these links have been removed. I noticed the problem when the Persian version was redirected to

Super-seeding. Arbabi second (talk) 08:04, 22 February 2025 (UTC)[reply]

@اربابی دوم: The mentioned ویکی‌پدیا:زبان و زبان‌شناسی is not a talk page. Wikipedia talk:WikiProject Languages is a talk page so it cannnot get a Wikidata item. The non-talk page Wikipedia:WikiProject Languages already has the wanted Wikidata item WikiProject Languages (Q8486980). The Persian page had two interlanguage links which overrode the Wikidata item. The first to Super-seeding was fixed in [9] and I fixed the second in [10]. The fix is to add a colon right after [[ so it displays as an inline link instead of adding a link to the languages list. The diffs may display the colon in an odd place in browsers because the page mixes left-to-right and right-to-left text. PrimeHunter (talk) 09:17, 22 February 2025 (UTC)[reply]

@PrimeHunter

I see that the problem with the Persian Wiki has been resolved. Thank you.😊 But I'm not sure about the other language wikis. I think until last night all of them were linking to the Wikipedia talk:WikiProject Languages, But it's fixed now. Thanks again. 😊 Arbabi second (talk) 09:48, 22 February 2025 (UTC)[reply]

That's because Wikipedia:Reference desk/Language (Q3906960) was changed a few years ago to point to Wikipedia talk:WikiProject Linguistics instead of Wikipedia:Reference desk/Language. I reverted that change a few hours ago because your post here brought it to my attention. jlwoodwa (talk) 20:45, 22 February 2025 (UTC)[reply]

I have numerous macros set up to assist my editing and most are activated by the alt key and a letter or number. For the last several weeks pressing the alt key in an edit box selects all text and any subsequent typing replaces the whole page.

What's going on? How can I fix this? This is only a problem in the Wikipedia edit window. Thank you. SchreiberBike | ⌨  01:06, 22 February 2025 (UTC)[reply]

What troubleshooting steps have you tried? Try logging out. Try a different web browser. Try a different computer. Have you changed any of your user Preferences in Wikipedia recently? – Jonesey95 (talk) 01:24, 22 February 2025 (UTC)[reply]

Thanks for the suggestions. It's only on my desktop. I'm using the latest Windows version of Firefox, but it doesn't happen in Chrome or the DuckDuckGo browser. If I log out it still happens. I'm not aware of any changes to Preferences. Thanks to the tech wizards. SchreiberBike | ⌨  12:28, 22 February 2025 (UTC)[reply]

This then is definitely a problem "on your end", likely having to to with your Firefox browser profile. When you say you "have macros set up" can you elaborate please? What are these macros "coming from" so to speak—describe for us how you set them up, please, we need more details. (Remember, we can't see your screen or desktop, we have no idea how things on your system are configured, we've never used it.) Are you using a browser extension in Firefox to provide these macros, or AutoHotkey, or what? --Slowking Man (talk) 04:32, 23 February 2025 (UTC)[reply]

Thanks for the suggestions. My macro program is Macro Express; it was the hot thing when I bought it in 2006, and it's still working well. I updated that and have run several cleanup and anti-virus programs. When I turn off Macro Express the problem continues. I've tried various online edit windows and on some of them pressing alt selects all and moves the cursor to the bottom of the page, while on others it has no effect. It happens when I press the alt on the on-screen keyboard too, so I don't think it's my hardware, but I'm borrowing another keyboard later today to test that. No other key presses seem to cause problems. Thanks for your help. SchreiberBike | ⌨  20:59, 23 February 2025 (UTC)[reply]

Ok, this is a guess: in beta prefs, do you have Improved Syntax Highlighting checked? And do you use the "native" wikitext syntax highlighting? Having both would cause you to get the new version of the highlighting software which may have clobbered your keys for its own purposes. Izno (talk) 21:07, 23 February 2025 (UTC)[reply]

Otherwise, it's likely to have been a new version of Firefox doing the same, based on your report that it doesn't happen in Chrome, so you will need to hunt down what Firefox is doing with those keys on your own and see if you can adjust some personal settings. Izno (talk) 21:08, 23 February 2025 (UTC)[reply]

Step one, then: launch a new "clean" Firefox browser profile, see if the problem continues to happen there too. If it doesn't happen under a "clean" profile, then it's something to do with the settings and extensions in your default Firefox profile, and you'll have to try fiddling them one-by-one to do a differential diagnosis of the cause. Step 1 for that: disable any and all browser extensions, see if that changes anything. --Slowking Man (talk) 22:13, 23 February 2025 (UTC)[reply]

 Fixed. That was it! I'd been trying to get the TitleCase browser extension to work with keyboard commands and there was a setting to enable the alt key. I've turned that off and now I'm back to normal. Thank you all so much for helping me troubleshoot this. I should've thought of that, but I didn't. Viva la VPT. SchreiberBike | ⌨  01:20, 24 February 2025 (UTC)[reply]

For several hours now, all my browsers and devices yield a 404 for GeoHack. I found nothing at Talk:GeoHack or GeoHack (MediaWiki links). Tens of thousands of articles link to GeoHack pages defined by coordinates. Anyone know what's going on here? ---Sluzzelin talk 01:59, 22 February 2025 (UTC)[reply]

Yup, it's down. Click the globe icon instead of the coordinates for a map in Katographer for now. This external tool is maintained by volunteers, hopefully they get around to it. — xaosflux ^Talk 02:07, 22 February 2025 (UTC)[reply]

Thanks, Xaosflux, and thanks for pointing out the Kartographer's globe! What I love about GeoHack is the plethora of map links it provides, all geared to the same point on Earth. ---Sluzzelin talk 02:13, 22 February 2025 (UTC)[reply]

FYI, it seems to be back online again, but running slow. — xaosflux ^Talk 14:40, 22 February 2025 (UTC)[reply]

When I click on the "total" value for the RfD row in Template:XFD backlog, which links to the nonexistent section "toc" (Wikipedia:Redirects for discussion#toc), nothing happens apart from a pop-up message on the top right of the page: "This topic could not be found. It might have been deleted, moved or renamed." I am using Google Chrome ("Version 133.0.6943.127 (Official Build) (64-bit)") on desktop. I'm unfamiliar with the technical side of Wikipedia, but according to this, the code should be:

| [[Wikipedia:Redirects for discussion#{{#time:F j|-8 days}}|{{#invoke:XfD old/AfD and MfD|rfd|month=total}}]]

| [[Wikipedia:Redirects for discussion#toc|{{#invoke:XfD old/AfD and MfD|rfd|month=total}}]]

Will someone look into this? Best regards, HKLionel (talk) 08:02, 22 February 2025 (UTC)[reply]

@HKLionel: The linked request was to replace the first line by the second and this was done.[11]. The reason the "section" link was broken for you is different: The toc anchor for the table of contents isn't in the current default skin Vector 2022 which displays the TOC elsewhere. It works in other skins like Vector legacy: https://en.wikipedia.org/wiki/Wikipedia:Redirects_for_discussion?useskin=vector#toc. But a link which is broken in the default skin is bad. I am reverting to the original code which currently gives a working section link but may not always if there is no corresponding date heading. PrimeHunter (talk) 09:49, 22 February 2025 (UTC)[reply]

I don't have much of an idea about what you're talking about, but thanks anyway! HKLionel (talk) 10:00, 22 February 2025 (UTC)[reply]

Answers tend to be technical here. I assumed you have "Vector (2022)" at Special:Preferences#mw-prefsection-rendering. The toc link worked for users with other skin selections. PrimeHunter (talk) 10:06, 22 February 2025 (UTC)[reply]

When I search for "Rocksteady" in the Template namespace, it doesn't find {{Mad Caddies}}. If I do an insource search for "Rocksteady" in the Template namespace, it finds {{Mad Caddies}}, plus an additional eight templates. I can see no reason why the first search can't find all 15 templates. Why is that? —Bruce1ee^talk 14:30, 22 February 2025 (UTC)[reply]

@Bruce1ee: It appears from [12] that elements with the autocollapse class is excluded from searches. It's usually collapsed on page load and usually of low relevance anyway for mainspace searches. This should probably be mentioned at mw:Help:CirrusSearch#Exclude content from the search index. PrimeHunter (talk) 16:28, 22 February 2025 (UTC)[reply]

@PrimeHunter: Thanks for that. So it's probably better to use an insource search to ensure it finds everything. —Bruce1ee^talk 17:27, 22 February 2025 (UTC)[reply]

I would not expect {{Mad Caddies}} to be found with a plain search for "Rocksteady". That string is buried in a wikilink that is inside a template parameter value. I'm honestly surprised that the plain-text search finds as many navboxes as it does; I never trust it. Simple insource searches work pretty reliably unless they time out. – Jonesey95 (talk) 06:22, 23 February 2025 (UTC)[reply]

Plain search works on the output so it's irrelevant whether templates were used. {{NPR Texas}} is expanded by default so it doesn't have autocollapse and is found on KTTZ. A mainspace search also finds articles using it. PrimeHunter (talk) 10:02, 23 February 2025 (UTC)[reply]

We must have a different understanding of the definition of the word "works". :) – Jonesey95 (talk) 16:36, 23 February 2025 (UTC)[reply]

 You are invited to join the discussion at MediaWiki talk:Gadget-popups.js § Bug: Popup uses HTML em and strong in place of i and b. — W.andrea (talk) 19:53, 22 February 2025 (UTC) edited 03:16, 23 February[reply]

 You are invited to join the discussion at Wikipedia talk:Requests for adminship § Formatting. FozzieHey (talk) 22:36, 22 February 2025 (UTC)[reply]

So I was searching "Golan Heights" using Bing and the search engine displayed the following text as the top result: https://www.bing.com/search?q=golan+heights

Golan Heights

This page is subject to the extended confirmed restriction related to the Arab-Israeli conflict. This page is subject to the extended confirmed restriction related to the Arab-Israeli conflict. The Golan Heights, or simply...

I cannot figure out where this is being inserted as it is not showing up in the source editor, but the fact that there are two of them and pushing the actual article text further is indicative that something is broken. I get this flag is needed for Abuse Filter 1341, but something needs to be done to make sure search engines are not reading the lines meant just for the filter.

Google does not have the same issue it seems, but this is something that should be fixed for all search engines. Aasim (話す（はなす）) 23:17, 22 February 2025 (UTC)[reply]

So it seems to be an issue with Module:Protection banner. Hmm... Aasim (話す（はなす）) 23:25, 22 February 2025 (UTC)[reply]

Do you still see this? I don't see that text on the bing search you linked. That said there are indeed two of them in Golan Heights (https://i.imgur.com/K3Yya6g.png), which is likely because it has 2 protection templates ({{Pp-move|small=yes}} and {{Pp-semi-indef}})- also Google does have this issue, it's just maybe rare? You can force it to search for the text in that page: [13].

I'm not planning on looking into it, just throwing out some observations. – 2804:F1...06:AD28 (::/32) (talk) 19:44, 23 February 2025 (UTC)[reply]

Awesome Aasim refers to this edit. --Redrose64 🌹 (talk) 19:52, 23 February 2025 (UTC)[reply]

Is there a way to log edits based on categories the page is in with the abuse filter? That might remove the need for this hack. Aasim (話す（はなす）) 20:07, 23 February 2025 (UTC)[reply]

Yes, this edit would do it. I would guess it's because it is marked as visibility: hidden, and in that regard it just... doesn't need to be. But either way, search crawlers are not required to observe styles applied by any CSS anywhere, so the only way to guarantee a fix for this issue is to choose not to output the text. Izno (talk) 20:11, 23 February 2025 (UTC)[reply]

Moved to Template talk:Convert § 1 mile is 5300 feet

 – ―Mandruss ☎ IMO. 13:22, 23 February 2025 (UTC)[reply]

Hello, I am trying to transfer this map modul from the French wikipedia fr:Modèle:Géolocalisation/Scandinavie to the English wikipedia: Module:Location map/data/Scandinavia LCC map. However I can tell that the coordinates are off, because the airfields I have marked are not where they should be. The values for top, bottom, right and left on the French wikipedia differ from the values on i.e. the German, Danish, Swedish wikipedia. However, when I enter i.e. the Danish values the locations of the airfields are depicted even further away from where they are actually located. I have no tried to transfer the other information in the French module (which is the most detailed of all modules), but with no success. Could someone with more experience with map modules please have a look and check what the error is? Thank you, and thank you for your time; noclador (talk) 16:46, 23 February 2025 (UTC)[reply]

Huggle will often place a warning on user talk pages in the incorrect section; not the current month's section. Sophisticatedevening and I left talk here: wp:Huggle/Feedback#Warning spacing bug There has not been any response. I often check and reorder warnings. Examples of misplaced warnings: [1] [2]. The default change provider XmlRcs has not been providing changes. I change to IRC or Wiki, but others don't seem to know about that solution. Is anything being done about this? Who should I ask? Thank you Adakiko (talk) 01:29, 24 February 2025 (UTC)[reply]

Extra diffs of the bug: (1 23) Sophisticatedevening ^(talk) 18:10, 24 February 2025 (UTC)[reply]

Is it just me, or is the default light gray background color suddenly much darker? I'm seeing it in the background of the left and right toolbars in Vector 2022, in the Category box at the bottom of every page, in the background of <code>...</code> tags, and in some block templates like the two at the top of #Huggle not working, above. If it's just me, never mind, but I'm pretty sure I didn't change anything. – Jonesey95 (talk) 05:34, 24 February 2025 (UTC)[reply]

@Jonesey95: Does it happen in safemode? If not then it's probably just you. There are 11 background-color in User:Jonesey95/vector-2022.css. PrimeHunter (talk) 09:55, 24 February 2025 (UTC)[reply]

In safe mode, the background color for code spans, the two templates at #Huggle not working, and the category box are still darker than I remember. Also, the unchanged parts of the page diff view have a gray background that I don't remember. The sidebars have a white background (yes, I customized those for contrast, but strangely, the background seems darker than before when I am not in safe mode). I am not complaining; I like the contrast. I just wondered if something had changed on a Sunday, an unusual time for changes. If it's not affecting anyone else, it's not a problem for me. – Jonesey95 (talk) 14:43, 24 February 2025 (UTC)[reply]

I compared directly to older versions of MediaWiki and the colors of code background or category box has not changed. It seems to be just you. Maybe you (or something automatically) changed the display color profile in your OS settings? (Or maybe you're using a different display?) Matma Rex talk 17:54, 24 February 2025 (UTC)[reply]

I just observed a bad contrast between the color of visited links and the plain text under images in dark mode.

This is in bright mode. Here, the hexadecimal code for the color of the visited link (Benelux) is #6960AF; and for the plain text it is #54595D.

And this is in dark mode. Here, the code for the visited link is #A29DB3; and for the plain text it is #A7A8AC.

Update: The unvisited link also had a bad contrast I think. But I forgot to screenshot it. Aminabzz (talk) 12:59, 24 February 2025 (UTC)[reply]

Not sure what you call this, but normally there is an automatic updated page view count at the top of each page. As of yesterday, that feature must be down. All I've been seeing is a tiny dot jiggling back and forth. Nothing else. — Maile (talk) 17:02, 24 February 2025 (UTC)[reply]

Seems to be working now. — Maile (talk) 17:27, 24 February 2025 (UTC)[reply]

For the record, it's made by the opt-in "XTools: dynamically show statistics about a page's history under the page heading" at Special:Preferences#mw-prefsection-gadgets. PrimeHunter (talk) 19:58, 24 February 2025 (UTC)[reply]

MediaWiki message delivery 00:38, 25 February 2025 (UTC)[reply]

I introduced a line to the template that was supposed to get rid of the need to sign your posts. This was because signing at the end gave the signature in the code box and it looked horrible. So I used subst:REVISIONUSER2 to post the username of the person who deployed the template. It was supposed to be static. Unfortunately, it's dynamic. Each time someone edits, the value constantly changes. I don't want that. It's definitely a PEBKAC issue, but I can't solve it alone. What should I have written instead? Szmenderowiecki (talk) 03:56, 25 February 2025 (UTC)[reply]

@Szmenderowiecki: Please provide links to one or more of the pages where {{subst:RfC closure review}} has been used, and which now show an incorrect user name. --Redrose64 🌹 (talk) 09:05, 25 February 2025 (UTC)[reply]

You wrote {{subst:REVISIONUSER2}} but {{REVISIONUSER2}} is not coded to work with subst. Maybe it should be. PrimeHunter (talk) 09:26, 25 February 2025 (UTC)[reply]

Here are some diffs in the thread that provoked this question. Each link is followed by the name of the editor linked by the template:

• [20] — Bluethricecreamman creates the request
• [21] — GoodDay adds a comment to the request
• [22] — Bluethricecreamman replies to the request
• [23] — Tule-hog edits a different section
• [24] — Springee replies to the request
• [25] — Rsjaffe edits a different section
• [26] — Springee says "hey, what's going on with the changing usernames"
• [27] — Szmenderowiecki says "oops, something's wrong with the template"
• [28] — Bluethricecreamman doesn't edit, but his name is now there properly, thanks to a fix by Voorts.

Redrose64, is this what you needed? Nyttend (talk) 10:33, 25 February 2025 (UTC)[reply]