Wikipedia:Village pump (technical): Difference between revisions

Browse history interactively

← Previous edit

Content deleted Content added

VisualWikitext

Inline

Latest revision as of 14:48, 12 January 2025

Table of contents
First discussion
End of page
New post

Shortcuts

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

Can we do something about the ridiculous message displayed whenever syntax highlighting is taking "too long"?

Syntax highlighting on this page was disabled because it took too long. The maximum allowed highlighting time is 20ms, and your computer took 22ms. Try closing some tabs and programs and clicking "Show preview" or "Show changes". If that doesn't work, try a different web browser, and if that doesn't work, try a faster computer.

The threshold is probably set too low to being with, and most people couldn't care less about it taking 0.03s vs 0.02s, so to tell them that a mere 2/1000 sec difference is "not allowed" is pretty ridiculous. If someone really does have a slow computer, that's hardly by choice, and to tell them to try a faster one is like Captain Obvious rubbing salt into their wound. More often than not, it's not even the fault of the computer, but rather some background crap (thanks, MS!), or the browser, or simply a very large and complex page (and possibly even the (gasp) wiki JS code). Ideally this should be a pref configurable by the user. Or, they could click a button if they don't care about things being slightly slower on the current page as long as they can still get the highlighting (the way browsers pop up slow JS abort/continue messages; in this case it wouldn't be modal, of course). But I think mostly it's about the overly low threshold, because when a large page is taking a number of seconds to load anyway, a few extra thousandths for this hardly make a difference. 61.84.123.149 (talk) 16:26, 1 January 2025 (UTC)[reply]

This seems to come from the Gadget mw:User:Remember the dot/Syntax highlighter. This is a user gadget and is not enabled by default here (but available for users to enable). You should report the issue to the author. But also see mw:User:Remember the dot/Syntax highlighter#Timeout – Ammarpad (talk) 16:58, 1 January 2025 (UTC)[reply]

Thanks a lot, that will probably do it for me. I was uner the impression it was a standard feature. 61.84.123.149 (talk) 17:36, 1 January 2025 (UTC)[reply]

Well there is a standard feature as well. You might even be using multiple. See WP:HILITE. —TheDJ (talk • contribs) 09:57, 2 January 2025 (UTC)[reply]

And the problem with the standard feature is that it doesn't have a timeout, so on very large pages it just freezes up the page until the browser eventually offers to kill it. --Ahecht (TALK
PAGE) 00:38, 5 January 2025 (UTC)[reply]

On what page does it actually freeze? CodeMirror is heavily optimized and much more performant nowadays. – SD0001 (talk) 09:00, 5 January 2025 (UTC)[reply]

@SD0001 I've been doing a lot of work cleaning up the top of Special:LongPages, and if I don't forget to disable syntax highlighting on any of those pages before editing the page locks up until eventually the browser offers to kill any running scripts. --Ahecht (TALK
PAGE) 21:33, 6 January 2025 (UTC)[reply]

Different assets for light and dark mode?

Is there any way to tell Wikipedia to display different images / media for Light vs Dark mode users? If not, could this be added in the form of a template, something like this?

{{adaptive|lightmode=[[File:Diagram (light mode).svg]]|darkmode=[[File:Diagram (dark mode).svg]]}}

Due to transparency, some SVG and PNG images have bad contrast when viewed in Dark mode.

(repost from WP:TH as they said would be better here)

CrushedAsian255 (talk) 04:38, 2 January 2025 (UTC)[reply]

It would have to be hardcoded in CSS. Dark mode is configured on CSS pages through templatestyles. In order to specify a dark and light mode image in a template like that, Phab:T320322 would have to be fixed first. Snævar (talk) 05:07, 2 January 2025 (UTC)[reply]

Have you tried using class=skin-invert-image already ? —TheDJ (talk • contribs) 09:55, 2 January 2025 (UTC)[reply]

{{If dark}} can be used to select what wikitext to display based on whether or not dark mode is enabled. isaacl (talk) 23:19, 2 January 2025 (UTC)[reply]

Usage of which really should be avoided though. —TheDJ (talk • contribs) 10:33, 4 January 2025 (UTC)[reply]

I agree that generally speaking, specific colours shouldn't be specified in wikitext, and using the CSS class to trigger colour inversion by the dark mode feature simplifies maintenance by having just one image. There are cases, such as a company logo with a variant designed for dark mode, where the ability to choose the appropriate image is desirable. isaacl (talk) 17:02, 4 January 2025 (UTC)[reply]

{{If dark}} may address the OP's question, although actual use of it may not be the best solution to the problem. – Jonesey95 (talk) 13:44, 7 January 2025 (UTC)[reply]

How to use inline style and CSS design tokens to color text?

I want to use {{NumBlk2}} to number the chemical formula P4-t-Bu#math_B and keep the color of the square brackets in the numbering.

The original chemical formula looked like this:

{{NumBlk|:|<math chem>\underbrace\ce{PCl5}_{(1)}\ \ce{->[t\text{-}\ce{Bu-\overset{\oplus}{NH3}.\overset{\ominus}{Cl}}]}\ \underbrace{t\text{-}\ce{Bu-N=PCl3}}_{(5)}</math>|[{{EquationRef|B}}]|RawN=y}}

\underbrace {\ce {PCl5}} _{(1)}\ {\ce {->[t{\text{-}}{\ce {Bu-{\overset {\oplus }{NH3}}.{\overset {\ominus }{Cl}}}}]}}\ \underbrace {t{\text{-}}{\ce {Bu-N=PCl3}}} _{(5)}

[B]

The result after using {{NumBlk2}} for numbering:

{{NumBlk2|:|<math chem>\underbrace\ce{PCl5}_{(1)}\ \ce{->[t\text{-}\ce{Bu-\overset{\oplus}{NH3}.\overset{\ominus}{Cl}}]}\ \underbrace{t\text{-}\ce{Bu-N=PCl3}}_{(5)}</math>|['''B2''']|RawN=y|Id=math_B2}}

\underbrace {\ce {PCl5}} _{(1)}\ {\ce {->[t{\text{-}}{\ce {Bu-{\overset {\oplus }{NH3}}.{\overset {\ominus }{Cl}}}}]}}\ \underbrace {t{\text{-}}{\ce {Bu-N=PCl3}}} _{(5)}

[B2]

(The ID must be unique, so I renumbered it to B2.)

But the recommendation is currently restricted to use inside TemplateStyles:

As described here, using design tokens directly in an article (e.g. some text) seems problematic. How to color text correctly in an article in light mode and dark mode in this case? Any ideas? Thanks. Justin545 (talk) 01:59, 5 January 2025 (UTC)[reply]

So you are adding link content, that you don't want to have colored as link content ? And for that reason you want to apply custom styles ? Is this a recurring pattern ? Then you make a template and use TemplateStyles. —TheDJ (talk • contribs) 11:10, 5 January 2025 (UTC)[reply]

Thank you for your advice. It does sound a bit strange to color the link the same color as normal text. I'm not sure if the use of square brackets in numbering occurs very often. If that's not the usual case, maybe it would be better to just use {{NumBlk}} instead of wrapper template {{NumBlk2}}:

{{NumBlk|:|<math chem>\underbrace\ce{PCl5}_{(1)}\ \ce{->[t\text{-}\ce{Bu-\overset{\oplus}{NH3}.\overset{\ominus}{Cl}}]}\ \underbrace{t\text{-}\ce{Bu-N=PCl3}}_{(5)}</math>|&lsqb;[[#math_B3|B3]]&rsqb;|RawN=y|Attr=id{{=}}math_B3 style{{=}}"margin-left: {{#expr:1.6 * 1}}em;"}}

\underbrace {\ce {PCl5}} _{(1)}\ {\ce {->[t{\text{-}}{\ce {Bu-{\overset {\oplus }{NH3}}.{\overset {\ominus }{Cl}}}}]}}\ \underbrace {t{\text{-}}{\ce {Bu-N=PCl3}}} _{(5)}

[B3]

If it's the usual case, maybe just make a template and use TemplateStyles as you said:

<!-- Template:Token -->
<templatestyles src="Token/styles.css" />

/* Template:Token/styles.css */

.token-color-base { color: var(--color-base); }
.token-color-disabled { color: var(--color-disabled); }
/* ... (omitted) ... */

.token-background-color-base { background-color: var(--background-color-base); }
.token-background-color-disabled { background-color: var(--background-color-disabled); }
/* ... (omitted) ... */

and then use it like this

{{Token}}
{{NumBlk2|:|<math chem>\underbrace\ce{PCl5}_{(1)}\ \ce{->[t\text{-}\ce{Bu-\overset{\oplus}{NH3}.\overset{\ominus}{Cl}}]}\ \underbrace{t\text{-}\ce{Bu-N=PCl3}}_{(5)}</math>|<span class{{=}}"token-color-base">[</span>'''B4'''<span class{{=}}"token-color-base">]</span>|RawN=y|Id=math_B4}}

(The source code above has not been tested and may contain errors.) —Justin545 (talk) 16:38, 5 January 2025 (UTC)[reply]

You should not worry about such weird specifics at all. This also produces different colours (= inconsistent behaviour) in the skins that do not use the same token. stjn 16:51, 5 January 2025 (UTC)[reply]

Thank you for reminding me about skins. Coloring text in Wikipedia is a lot more complicated than I thought. I haven't started to understand the skin part yet. So far I don't know if there is a correct way to handle coloring for skins and dark mode at the same time. If not, I may have to give up the idea of coloring text completely. Without coloring, I might just use {{NumBlk}} directly like B3. Justin545 (talk) 01:18, 6 January 2025 (UTC)[reply]

Or do you mean using name of colors or hex code of colors directly in styles.css instead of using design tokens? Justin545 (talk) 04:36, 8 January 2025 (UTC)[reply]

I mean that this is not an issue you should concern yourself with when you introduce more markup into the code and that markup is incorrect at least in one way. Wikipedia won’t be dead tomorrow because brackets are blue colour there. It is a complete non-issue. stjn 10:40, 8 January 2025 (UTC)[reply]

Rather than telling me what I shouldn't worry about or what I shouldn't concern with, wouldn't it be better if you could just give me links to some relevant guidelines or help pages? I think most official documents have very clear and specific descriptions and explanations, which are relatively easy to understand. And they don't contain emotions directed at specific people.

I raised questions and opinions about design tokens based on the MediaWiki recommendation. If you think I have misunderstood the recommendation, you can tell me directly where I misunderstood it. Justin545 (talk) 14:53, 8 January 2025 (UTC)[reply]

Broken icon

Tracked in Phabricator
Task T383023
Resolved

Hi, can anyone see why File:Gnome-colors-list-remove.svg is broken, nothing seems to have chaned but it's showing as a broken image in the latest admin newsletter. It should be a horizontal red minus to signify remove. Step hen 02:43, 6 January 2025 (UTC)[reply]

It seems to be working for me, both in that link and in the news letter in your user talk page (like in - Ferret).

What browser are you using? Are you using the mobile website (en.m.wikipedia.org)?

Is it affecting any of the previous newsletters? Is it affecting any of the other icons? – 2804:F1...CA:8CB5 (::/32) (talk) 02:58, 6 January 2025 (UTC)[reply]

That's weird it works for you. I'm on Chrome using the desktop site. All previous uses of the icon in old newsletters are broken too wherever I look. Step hen 03:49, 6 January 2025 (UTC)[reply]

I'm on Chrome desktop too... I wonder if your browser console shows any errors (Pressing f12 or three dots button (⋮) > More tools > Developer tools > Console tab and then refreshing the page).

There's also the network tab of developer tools, which for me shows a 20px-Gnome-colors-list-remove.svg.png line (the 10th line for me after refreshing) as successfully downloaded - if it had failed it would have been red, and apparently repeated a bunch of times one for each time it appears on your talk page.

What it says in the Status column, if it is red, or in Status code if you click it, might be of interest.

Also, does that direct link work? – 2804:F1...CA:8CB5 (::/32) (talk) 04:48, 6 January 2025 (UTC)[reply]

Suspect I am in Stephen's position. The direct link says "Unauthorized This server could not verify that you are authorized to access the document you requested." No errors showing up in my console, although the console is forcing the page into mobile view for some reason. CMD (talk) 04:56, 6 January 2025 (UTC)[reply]

Searching phabricator for that error reveals a very similar error that happened on a beta version (phab:T276179/phab:T277016)... seeing as it doesn't happen to me, it might be a codfw issue rather than a eqiad issue (which is the data center I'm assigned to) - but I'm just guessing, I've never looked at how these things actually work, it just seems to be a common cause of differences.

I'm pretty sure someone with backend access will have to look into this to find out what the problem is though.

Could try filing a bug report in phabricator? –2804:F1...CA:8CB5 (::/32) (talk) 05:59, 6 January 2025 (UTC)[reply]

I have the same error and filed ticket phab:T383023. cyberdog958^Talk 07:22, 6 January 2025 (UTC)[reply]

I was having the same problem with File:Hypercubestar.svg (used on four articles here and over 30 on some 14 languages of Wikipedia) and started a discussion at https://commons.wikimedia.org/wiki/Commons:Help_desk#SVG_image_claims_its_thumbnails_are_unauthorized before finding this discussion and the phab link. It would be interesting to learn whether this issue is more widespread. —David Eppstein (talk) 07:33, 6 January 2025 (UTC)[reply]

The bug report has been closed as fixed, please confirm. Issue appears to have been that a database container for thumbnails was mysteriously deleted, it was fixed by 'effectively re-creating the container' - an investigation on how/why it was deleted is now tracked at phab:T383053. – 2804:F1...42:FDB7 (::/32) (talk) 15:21, 6 January 2025 (UTC)[reply]
The developer said there are 43 thousand containers, this was one of them - I'm guessing that's why it only affected some people and only some of the images.

Cyberdog958 had already said in the phab task that it is working for him, before it was closed. Is it working for you four as well, @Stephen, @CMD, @David Eppstein and @SuperMarioA9H5?

– (different sig for pings) user in a /32, currently at 2804:F14:80F4:1F01:144B:E33B:3E42:FDB7 (talk) 15:53, 6 January 2025 (UTC)[reply]
Yes, seems it's fixed. Thanks, CMD (talk) 16:04, 6 January 2025 (UTC)[reply]

Fixed for me too, thanks all. Step hen 20:24, 6 January 2025 (UTC)[reply]

Image Preview Issue

I was looking through the Wikipedia article for the Buick Regal when I noticed that the thumbnail image for the third generation model is no longer displaying as it should. When I click on the image, it appears as normal, but only when it is clicked on. In Wikipedia Commons, the exact same problem is present. It also does not allow for resolution changes as most other images normally do. I have tested this on both Windows and mobile using Apple Safari, Google Chrome, and Microsoft Edge, and the problem remains consistent. I also found that there exist other images on Wikipedia Commons that are experiencing a similar problem. This image used to work perfectly before, so what could have changed to cause this? Is there any way this could be remedied? SuperMarioA9H5 (talk) 05:07, 6 January 2025 (UTC)[reply]

Might be the same issue as #Broken icon above (yet to be determined what the issue is though).

I can see the thumbnail on Buick Regal just fine as well. – 2804:F1...CA:8CB5 (::/32) (talk) 06:06, 6 January 2025 (UTC)[reply]

I can confirm it is the same issue, right down to the "Unauthorized" issue when selecting different sizes. Interesting that it seems to work for some yet not for others. I mainly asked as I wasn't sure if the image needed to be replaced due to an issue on Wikipedia's end. Hopefully whatever it is it can be patched out later. SuperMarioA9H5 (talk) 06:10, 6 January 2025 (UTC)[reply]

Common.css issue on Brave

Does anyone know why my common.css doesn't seem to work on Brave? I've just replaced Firefox with it due to its atrocious performance on YouTube with Ublock turned on. Now, I can't get my (very simple) common.css to work with it. Any ideas? Sol505000 (talk) 10:33, 6 January 2025 (UTC)[reply]

The name of the font should be in double quotes since it contains a space. – SD0001 (talk) 13:52, 6 January 2025 (UTC)[reply]

I changed it and it still doesn't work (also, it worked without the double quotes on Firefox just fine). The issue is that Brave seems to display the wrong font, rather than ignoring my common.css altogether. I think it displays DejaVu Serif instead of DejaVu Sans. Sol505000 (talk) 14:42, 6 January 2025 (UTC)[reply]

I tried uninstalling DejaVu Serif and the problem persists. Why can't Brave follow a simple instruction? Sol505000 (talk) 14:45, 6 January 2025 (UTC)[reply]

@Sol505000: The CSS spec for the font-family: property is rather complex. To me, it reads as if you don't need to quote font names, even if they contain spaces, unless not doing so would cause ambiguity. If Firefox tolerates the absence of the quotes but Brave doesn't, that tells me that the authors of the two browsers have read the spec in different ways. Personally I would err on the safe side and quote them (the quotes need not be double, but must be paired, as in my example stylesheet below).

On a related matter, I would not use a single font name - I would supply at least one fallback option, in case the device does not have your preferred font(s) installed; and the last of these fallback fonts should be one of the generic family keywords defined in the spec. Something like this:

.IPA
	{ font-family: "DejaVu Sans", Arial, 'Liberation Sans', sans-serif; }

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

Right-click on an element with the IPA class, select "Inspect", enter "font-family" in the filter under "Styles", and you can see what is overriding your custom style. You can also switch to the "Computed" tab and see what fonts are used in "Rendered Fonts" at the bottom. Nardog (talk) 06:08, 7 January 2025 (UTC)[reply]

Solved, what overrides the font are Brave Shields. Turning them off solves the problem (thankfully, WP isn't full of obnoxious ads that'd get in the way of browsing it). I'll report this to the developers. Thanks for the help everyone. Sol505000 (talk) 22:29, 7 January 2025 (UTC)[reply]

How to change placement of custom fields on Template:User infobox

I pretty much have what I want, just not in the location I want. Even if I place the custom fields where I want them in the code, as seen here, the displayed output doesn't change, and the custom fields—age and today's date, in this case—still appear at the bottom of the infobox. I want age below birthdate and place and today's date above current time. Also, is there a way to change the border color of the entire border around the infobox? I want it to be black so it looks better. Do I just add style="border: 1px solid #000000;" somewhere? Amaury • 23:09, 6 January 2025 (UTC)[reply]

@Amaury: When named parameters are used, the order that these are supplied in is immaterial; the order of display is goverened purely by the code inside Template:User infobox. I don't have time right now to look at the rest, will try to get back later. --Redrose64 🌹 (talk) 09:36, 7 January 2025 (UTC)[reply]

@Amaury: All fields, both custom and other, can only be displayed in the positions they have in the infobox to the right at Template:Infobox Wikipedia user#Usage. I suggest including age in the Born field with birthdate = {{Birth date and age|1991|11|8}} which produces: November 8, 1991 (age 33). Today's date can be included in current_time but then the date and time should use the same time zone, unlike now where your time is local but date is UTC. I examined the implementation and you can tag a border color onto another parameter like | tablecolor = #CBC3E3; border: 1px solid #000000. I don't promise it will always work if the implementation changes. PrimeHunter (talk) 12:39, 7 January 2025 (UTC)[reply]

@PrimeHunter: Okay, so the only way to change the placements of the parameters is to edit the template code itself; however, that shouldn't be done, of course, as it would affect everyone. I originally had the birthdate and age together, but I didn't like how the age in parentheses was going down to a separate line. Although I have now figured something out by increasing the width from the default 22em to 24em, which gives the age enough space to be on the same line. As for the date, my only minor nitpick with adding the date to the Current Time parameter is that time is technically not a date, so having Current Time also display a date would look weird to me. And, of course, there's no way to change the parameter name just for my own infobox. This is what I ended up doing instead. As a final question, is there a way to hide the Wikipedian with the icon thing just for my infobox or no? Thank you so much for help and advice! Amaury • 22:51, 7 January 2025 (UTC)[reply]

@Amaury: You can change "Wikipedian" with |role=. The row with two dashes will still be there even if you set it to something non-displayed like  . You can hide the gender icon with |gender=none but it has other effects. A template call can be wrapped in {{Replace}} or {{MultiReplace}} to change some of the output but it's messy and shouldn't be done in articles. If you try it then Special:ExpandTemplates can be used to find the exact current output. PrimeHunter (talk) 00:22, 8 January 2025 (UTC)[reply]

All templates broken beyond a certain point on a CfD page

The CfD page for January 6 (permanent link) has all templates broken beyond a certain point in the "States and territories (dis)established in YYYY" nomination, which uses Template:Lc exactly 1,353 times. Templates beyond this point are replaced by links to the underlying templates. –LaundryPizza03 (d c̄) 23:37, 6 January 2025 (UTC)[reply]

@LaundryPizza03: WP:TLIMIT strikes again. There are two clues to this: (i) the intended transclusions showing as links, as you describe; (ii) the page being in Category:Pages where post-expand include size is exceeded. The prime suspect here is Wikipedia:Categories for discussion/Log/2025 January 6#States and territories (dis)established in YYYY - do all of them need a {{lc}}, or just the first one? --Redrose64 🌹 (talk) 23:53, 6 January 2025 (UTC)[reply]

The issue was fixed by omitting around 1350 {{lc}} for annual subcategories.[1] They wouldn't even fit on a subpage with no other content. PrimeHunter (talk) 08:31, 7 January 2025 (UTC)[reply]

Enwiki dump?

Dump files. Enwiki:

2025-01-07 17:19:24 enwiki (new): missing status record

Everything else is available. Is this normal? I need a dump. -- GreenC 17:26, 7 January 2025 (UTC)[reply]

Probably https://lists.wikimedia.org/hyperkitty/list/xmldatadumps-l@lists.wikimedia.org/thread/5ABHNJRXSR53XBAMNH3TROLTMY5ZXEXF/ * Pppery * _{it has begun...} 17:28, 7 January 2025 (UTC)[reply]

Great, thanks. -- GreenC 17:57, 7 January 2025 (UTC)[reply]

Undo and thank buttons on Vector 2010

The undo and thank buttons in page history are coloured with Vector 2022 colours on Vector 2010. I'm not sure when this bug was introduced, but it wasn't there when I edited Wikipedia a month ago. Daß Wölf 19:08, 7 January 2025 (UTC)[reply]

RSS

When it comes to such feeds of pages' history, here, is it the feed itself that is not instantaneous, or the bot that delivers it? ~Lofty abyss 23:03, 7 January 2025 (UTC)[reply]

Why do you think it is not instantaneous ? —TheDJ (talk • contribs) 23:05, 7 January 2025 (UTC)[reply]

The timestamps differ variably, for some reason... I'm just wondering, then, if it's the feeds themselves, or the bots relaying it (as they're some free service, so presumably they don't prioritize them...) ~Lofty abyss 12:55, 8 January 2025 (UTC)[reply]

Are namespaces supposed to be case insensitive?

I discovered today that namespaces appear to be case insensitive, as opposed to following the normalization (canonicalization?) rules for page titles. For example, all of these end up at the same place:

This isn't mentioned at mw:Manual:Namespace, so it's not clear if this is intentional, a bug, or just some silly bit of undefined behavior. Is it intentional? RoySmith (talk) 02:19, 8 January 2025 (UTC)[reply]

Intentional I think. * Pppery * _{it has begun...} 02:54, 8 January 2025 (UTC)[reply]

Help:Link says: "If the target contains a namespace prefix, then the whole prefix and the first character after the colon are case-insensitive (so uSeR:jimbo Wales links to User:Jimbo Wales)." DMacks (talk) 03:22, 8 January 2025 (UTC)[reply]

It's mentioned at mw:Manual:Page title##1 and #2. Interwiki prefixes and namespace prefixes. PrimeHunter (talk) 08:57, 8 January 2025 (UTC)[reply]

It's been like that fot as long as I can remember, and I joined in May 2009. --Redrose64 🌹 (talk) 00:34, 9 January 2025 (UTC)[reply]

The oldest mention I found at mw is from 2007 namespace prefixes ... are case insensitive, and the edit summary said "from docs/title.txt in installation". It also means DISPLAYTITLE allows any capitalization in the namespace. PrimeHunter (talk) 09:18, 9 January 2025 (UTC)[reply]

Out-of-line references missing in an imported excerpt

Hello, fellow Wikipedians!

I'm stuck on a problem with undefined references in the Frogs in culture article, current version Special:PermanentLink/1265294861 from 26 December 2024.

It includes the lead section of Pepe the Frog through the {{Excerpt}} template in the Frogs in culture § Pepe the Frog in 4chan culture section. The included text has 12 references in it, 10 of which are defined in-line and appear to be properly included in the destination Frogs in culture article. However, the remaining two are defined outside the Pepe the Frog's lede, which results in Cite error: The named reference ... was invoked but never defined (...).

Those two are ref [53] named 'Branded' and [54] named 'ADL'.

How can I fix it within the destination article (that is, without moving the references to the lede in the source article)? --CiaPan (talk) 08:06, 8 January 2025 (UTC)[reply]

Certainly the easiest solution is to move the refs to the lead section of the Pepe article, since it doesn't apply WP:LEADCITE. Otherwise you have to recreate them as named references in the FiC article (which is not ideal since they could get orphaned) 𝕁𝕄𝔽 (talk) 11:12, 8 January 2025 (UTC)[reply]

@JMF: Yup, I've considered moving the refs to the lede. However, it could fail in some situations.
Suppose a reference is called by its 'Name' attribute from two different sections, and each section is transcluded in a different article. That's quite exotic scenario, but still possible. Then both original sections would have to define the same reference exactly the same way for all three articles to display properly.
That's why I would rather like to solve the problem on the 'receiving' side, if possible.

--CiaPan (talk) 09:11, 9 January 2025 (UTC)[reply]

In that case the only real solution is to copy the references into the article containing the {{excerpt}} as list defined references. Especially as leads are not the only type of section that gets transcluded, so LEADCITE isn't always applicable. -- LCU ActivelyDisinterested «@» °∆t° 23:40, 9 January 2025 (UTC)[reply]

And this is one reason section transclusion can be a really bad idea. Izno (talk) 21:23, 8 January 2025 (UTC)[reply]

@Izno: What is the solution, then? Possibly copy the whole section and add some HTML comment both at the source and a copy for editors to keep both copies in sync? But I don't know whether HTML comments are visible in Visual Editor...

--CiaPan (talk) 09:11, 9 January 2025 (UTC)[reply]

The objective should be immediate verifiability in the article of interest, while promoting WP:Summary style. Excerpt is either pulling a WP:LEAD-compliant lead, which has no references, so verifiability is hence a question in the relevant article, or is pulling one which does have references... in which case the other article needs fixing. It's just fundamentally really gross. What should instead happen is a summary of the Pepe article, and I imagine it should be a much shorter summary per WP:WEIGHT. Izno (talk) 20:07, 9 January 2025 (UTC)[reply]

Last time I tried to help on a closely-related matter I got shot down for it. --Redrose64 🌹 (talk) 00:35, 9 January 2025 (UTC)[reply]

@Redrose64: Sorry to hear it. Did a requester attack you for your help being inaccurate, or some bystander considered the whole idea wrong and outraged for you helping instead of disouraging the needy one...? --CiaPan (talk) 09:11, 9 January 2025 (UTC)[reply]

@CiaPan: Wikipedia:Village pump (technical)/Archive 217#List-defined refs. It's got a confusing sequence, because after I had fixed the original problem, and explained how, DuncanHill apparently decided to attack me for being an admin - but put those posts before the earlier replies. It spilled to other pages - note carefully the timestamp of this edit in relation to the timestamps in that archived VPT thread. Then ActivelyDisinterested had a go at me for reverting some edit or other, but never specified what I reverted. --Redrose64 🌹 (talk) 22:12, 10 January 2025 (UTC)[reply]

Templates that don't display on mobile

Sorry, I know that this is an old chestnut but I hoped that maybe it had been resolved without my noticing. The template {{Today/AD/SH/AH}} does not display on mobiles (or at least not on Android, but that has the largest market share worldwide). Is this a generic problem or something specific to that rather old and limited-use template? (If the latter, I'll go ask the template gurus.) 𝕁𝕄𝔽 (talk) 11:03, 8 January 2025 (UTC)[reply]

@JMF This is intentional. That template is based on {{sidebar}}, which, as it notes in the documentation, does not display on mobile devices. The WMF deliberately removed a bunch of templates (like navboxes) from the mobile site. 86.23.109.101 (talk) 13:35, 8 January 2025 (UTC)[reply]

Of course! Classic case of looking for a complicated reason (java) for a simple problem – I should have spotted that there is nowhere for a sidebar to go. So time for me to see if can be changed to an infobar. 𝕁𝕄𝔽 (talk) 16:54, 8 January 2025 (UTC)[reply]

Indeed, it is more {{infobox}}y than it is {{sidebar}}y. Izno (talk) 21:15, 8 January 2025 (UTC)[reply]

Current "emerging consensus" is to replace them all with {{Infobox calendar date today}}, see user talk:Gonnym#template:Infobox calendar date today. 𝕁𝕄𝔽 (talk) 23:14, 8 January 2025 (UTC)[reply]

Chinese nationality in the infobox refuses display on certain articles

Am I the only one who noticed how on some articles, for example the Hong Kong activist Nathan Law, if you add his nationality to the infobox, it is not visible to the readers and doesn't show up in previews. However if you add any other nationality such as Bahamian it does display in the preview. At first I thought maybe this was just a quirk of visual editor, but even in source code, the same problem persists. Here is the diff in case anyone cares to examine it. [2] Andro611 (talk) 15:29, 8 January 2025 (UTC)[reply]

The documentation for {{Infobox officeholder}} says the following:

nationality is not displayed if the corresponding country is mentioned in birth_place, for example |birth_place = Tokyo, Japan |nationality = Japanese.

I'm guessing that's why. Not displayed is a link to MOS:INFONAT, which seems relevant. – 2804:F1...96:BB60 (::/32) (talk) 15:50, 8 January 2025 (UTC)[reply]

I see, thanks, that makes sense now. Andro611 (talk) 00:20, 9 January 2025 (UTC)[reply]

Multiple citation templates

Why there were created multiple citation templetes (like Cite book, Cite journa) if they differ just by a few parameters? I wonder if there could be just one template with various attributes, because in practice the user usually fills up just some of them. Juandev (talk) 16:20, 8 January 2025 (UTC)[reply]

All those templates are wrappers for Module:Citation/CS1, but the parameters required/allowed by the different citations types varies. For example, {{cite web}} generates an error if |volume= is used but {{cite journal}} doesn't. This becomes even more important with the Wikipedia:TemplateData used by Visual Editor and various bots, where we want to vary which fields are presented to the editor. --Ahecht (TALK
PAGE) 17:32, 8 January 2025 (UTC)[reply]

Because people didn't create centralized templates at the time those were created (20 years ago). Someone eventually made {{citation}} and then someone else finally made {{citation/core}} which at least centralized how things were rendered but by that time we had the problem that there were stylistic differences between the two (which we have whittled since). We later turned that template into the aforementioned module when we got WP:Lua. If we had the right tools at the time, I suspect there would have been one template and one template only.

I guess we could make a {{citation cs1}} which would do the same things as {{citation}} without requiring the parameter tweaks for the style issue, but the other issue a single template has trouble with is that there are some rules that are harder to enforce (or guess at) when you have only one template. Izno (talk) 21:21, 8 January 2025 (UTC)[reply]

Yup, that sounds me like a reason, that before Lua you would need to format value inserted by the user different way for each type of a resource. Because otherwice it would be maybe better to have one big template providing samples of parameters for each resource type. Juandev (talk) 21:27, 8 January 2025 (UTC)[reply]

This is really a matter for Help talk:Citation Style 1. --Redrose64 🌹 (talk) 00:37, 9 January 2025 (UTC)[reply]

Moving the Cite CS1 templates into one would not be complicated. It could be done with moving "CitationClass" from being a config (template parameter) to being an argument (page parameter). The challenge is getting Citoid to work - the automatic citation filler in VisualEditor and RefToolbar - because it expects one template for news, one for web, one for books, etc. Changing the roughly 6 million pages to one template with a bot is also going to take awhile. You are going to need a conseus for all of this. Snævar (talk) 01:30, 9 January 2025 (UTC)[reply]

It sounds like you're talking about something like changing {{cite web|...}} to {{cite|web|...}}, consolidating to one template while retaining the background module code. I can't see how this would make anything better. Merging the documentation seems likely to cause more confusion than the current situation, since different modes accept different parameters and produce different formatting. I don't see how or why this would be a good idea. – Jonesey95 (talk) 05:26, 9 January 2025 (UTC)[reply]

A lot of the documenation is already maintained in a centralised way, through {{Citation Style documentation}}. Take a look at all its subpages, which contain the documentation that is identical for all CS1 templates. --rchard2scout (talk) 08:43, 9 January 2025 (UTC)[reply]

I am familiar with the documentation and have edited it over the years, which is why I think that it will be difficult to display for a single template with multiple modes. Take a look at the switch and if statements in the code for {{Citation Style documentation/title}}, for example. Editors already complain that the documentation for these templates is too complex; imagine a single documentation page with all of the modes explained on one long, green page. – Jonesey95 (talk) 14:32, 9 January 2025 (UTC)[reply]

Citation templates included quite a lot options. It would be nice to know the persentage of use of each option. We may see then, that some of them have rare use. Juandev (talk) 22:44, 9 January 2025 (UTC)[reply]

Have you looked at the monthly report available in the TemplateData section of the documentation? If you have specific suggestions for changes to one of the cite templates, Help talk:Citation Style 1 is the correct forum. – Jonesey95 (talk) 23:07, 9 January 2025 (UTC)[reply]

Some options are rarely used because they are rarely needed, but they are needed sometimes. Try citing a chapter in a book without "chapter", "chapter-url", or "chapter-url-access". Donald Albury 23:08, 9 January 2025 (UTC)[reply]

Well, I am not sure if VisualEditor would be a big deal. You just recreate MediaWiki:Cite-tool-definition.json and maybe also MediaWiki:Citoid-template-type-map.json. Juandev (talk) 14:41, 9 January 2025 (UTC)[reply]

External link screening JS script I just made!

Re recent events that I'm not going to mention because of WP:DENY/WP:BEANS, and also the very concerning {{Plain link}} template which can disguise external links as wikilinks (like this), I made a user script, at User:MolecularPilot/ExternalLinkScreen.js that presents a "are you sure this is the link you want to visit" screen when clicking through to external links, even if {{Plain link}} has been used or the link has a display name set, showing you the actual URL you are about to visit. This is common on many websites like YouTube, Twitter etc.

It's also able to prevent spoofing (IDN homograph attack) by showing the actual puny code and adding warnings for websites like https://wikipediа.org (spoiler alert: this isn't wikipedia, it's a trick using cyclic letters, you are actually taken to http://xn--wikipedi-86g.org/ which this script will tell you about).

Just wanted to post this here to let everyone know that can now install this (just add importScript('User:MolecularPilot/ExternalLinkScreen.js'); to your Special:Mypage/common.js or use Enterprisey's script installer).

Stay safe everyone, especially if you are editing in WP:ARBPIA! :) MolecularPilot ^{🧪️✈️} 06:14, 9 January 2025 (UTC)[reply]

Adding that if you want a "try before you buy", here's two link examples of the screen you will see (note that if you have the script installed, it you'll get 2 landing pages before reaching the link as opposed to the usual 1, if you click these):

Click here for a regular link.
[3] Click on that to see what happens with an IDN homograph attack.

MolecularPilot ^{🧪️✈️} 06:27, 9 January 2025 (UTC)[reply]

Interesting concept. I don't see why you need the toolforge site in the middle though, as that's just executing JS that could be run in the user script itself. – SD0001 (talk) 06:46, 9 January 2025 (UTC)[reply]

Also, pulling in punycode.js from Cloudfare CDN is against Toolforge policy. Use https://cdnjs.toolforge.org/ instead. – SD0001 (talk) 06:53, 9 January 2025 (UTC)[reply]

Oh, thanks for the tip, I'll fix the CDN now! (I also realised that I wrote my demo links incorrectly above, so the URL would be "null", which I've just fixed). Re: the use of a website, I think it's better psychologically because it adds a pause while the tool forge page loads and also makes you process (yes, I'm going to a different page) before automatically clicking the button. :) MolecularPilot ^{🧪️✈️} 06:55, 9 January 2025 (UTC)[reply]

SD0001, CDN fixed now! Thank you so much for your feedback, I really appreciate it! I might add a version that creates popups like Twinkle instead of using the landing page like most of the other websites do, because it may be better suited to our environment here. :) MolecularPilot ^{🧪️✈️} 07:12, 9 January 2025 (UTC)[reply]

I suggest you wrap the script in mw.hook('wikipage.content').add() and find links only in the jQuery node passed to the callback, or it may run before the whole page is loaded. Also all wiki-generated external links have the external or extiw class. Nardog (talk) 10:36, 9 January 2025 (UTC)[reply]

This is all a step in the right direction. I'd like to see something else as well, namely a bot that goes around flagging (or even disabling) external links that appear to be deceptive. That would protect editors who haven't installed any js. Exactly what properties would trigger it is a matter for discussion, as is how to catch enough cases without a flood of false positives. Zero^talk 11:27, 9 January 2025 (UTC)[reply]

That is what MediaWiki:Spam-blacklist is for. It blocks aditions of links that are listed in the list. The way I see it, javascript link warnings are for finding bad links or marking links that are not quite serious enough for Spam-blacklist. Snævar (talk) 00:13, 10 January 2025 (UTC)[reply]

No, the blacklist is for blocking links to malicious domains that have already been identified. It does not locate new deceptive links to other domains. We have a well-funded organization that plans to add deceptive redirects in order to dox editors and those links are not going to point to the organization's own domains. They will point to new temporary domains designed to be deniable. The question is how we will find those links before unsuspecting editors click on them. Zero^talk 02:04, 10 January 2025 (UTC)[reply]

Actually a good point re temporary domains, I will make the page warn if they domain is newly registered (i.e. in the last 30 days). Currently, the "do you really want to visit this link" isn't just for suspicious links, it's for all links to non-WMF sites (including Toolforge as anyone can host a tool) because sometimes there is no way to figure out where a link is going until you actually click it (and sometimes a user might expect a wiki link but it's a {{Plain links}} external link), so I thought this would be helpful. For example how do you know where this goes without clicking and how about this, you might not even think it leads you off-wiki? MolecularPilot ^{🧪️✈️} 02:11, 10 January 2025 (UTC)[reply]

"...a well-funded organization that plans to add deceptive redirects..."? If that's the case, perhaps the good folks over at WP:EFR can help out to prevent that from happening? --rchard2scout (talk) 13:43, 10 January 2025 (UTC)[reply]

I think that's a typo, Zero probably meant links not redirects. I don't think such links can be caught with a regex-like AbuseFilter pattern (but no links have been posted yet so you never know!) but just made this script to ensure people actually see where a link is taking them (and see appropriate warnings like about IDN homograph attacks and new domains) and confirm that it's correct before heading off-wiki, like many other sites do for safety/privacy. :) MolecularPilot ^{🧪️✈️} 00:29, 11 January 2025 (UTC)[reply]

Redlink count

How to count fastly redlinks here? ru:Депутаты Верховного Совета Республики Казахстан XII созыва Kaiyr (talk) 10:40, 9 January 2025 (UTC)[reply]

Open the browser console (see Help:CONSOLE for how to open) and use command document.querySelectorAll('a.new'). There are 214. – SD0001 (talk) 10:43, 9 January 2025 (UTC)[reply]

How to make list of this redlinks? Kaiyr (talk) 13:04, 9 January 2025 (UTC)[reply]

copy([...document.querySelectorAll('a.new')].map(e => e.title).join('\n')). This copies a plain list of titles to the clipboard. – SD0001 (talk) 15:19, 9 January 2025 (UTC)[reply]

"Edit" has disappeared and I only have "Edit Source"

Despite having (repeatedly) enabled the visual editor the "edit" function has disappeared from all my Wikipedia pages, leaving only "edit source", which is beyond my capability. Please help, but assume I am totally stupid in the way you reply - I will not be offended - thanks. Stagememories (talk) 17:28, 9 January 2025 (UTC)[reply]

You probably changed the "Editing mode" setting here. Sjoerd de Bruin (talk) 17:56, 9 January 2025 (UTC)[reply]

Sjoerd de Bruin, you are a star! Thanks. Stagememories (talk) 18:29, 9 January 2025 (UTC)[reply]

Pipe-related glitch

I've been having this happen for quite some time, and still don't know the root cause. Sometimes, although not all the time, a random wikilink ([[]]) will bug out and display a "post-open>" and post-close>" in visible text before and after the link, despite no changing to the source editor or any other input. The best example of this can be found at this diff. The "post" is usually highlighted in orange, so it may be some sort of issue with a script I have installed. A user on the WM Discord told me about a week ago that I'm not the only person that has reported this issue. This could easily be taken as vandalism, so I'd say it's relatively serious. E_F⁵ 17:37, 9 January 2025 (UTC)[reply]

I'd immediately be looking at some sort of Wordpress or other spelling or blog browser extension.... Izno (talk) 20:04, 9 January 2025 (UTC)[reply]

That’s the thing, I run Chrome (on my school-issued Chromebook) and Edge (on my home PC), neither of which have extensions installed (I have WWT, but this problem has gone on way before I installed it). E_F⁵ 20:41, 9 January 2025 (UTC)[reply]

The diff which added it is [4] where you used VisualEditor. I only found one other occurrence in searches and it was also you, 30 October 2024 [5] with the mw:2017 wikitext editor which is a mode within the VisualEditor extension. The diffs add nowiki which is MediaWiki code and VisualEditor is known for automatically adding nowiki in some situations so VisualEditor is probably involved but it may be a conflict with a script in User:EF5/common.js. You should load User:Epicgenius/ArticleQuality.js once and not 16 times, but that happened this week [6] so it's not the cause. PrimeHunter (talk) 21:15, 9 January 2025 (UTC)[reply]

I’ll mess around with my scripts a bit and see what happens. I normally catch it before publishing it by cancelling the edit (which usually fixes it), hence why it’s only shown up twice. E_F⁵ 21:24, 9 January 2025 (UTC)[reply]

I tried loading your common.js for myself, and immediately saw a visual glitch (just in read mode, not in the editor) that's eerily similar to the problem you get after saving pages: F58156448 (screenshot taken on The Fighting Temeraire). I can't tell which script of the eleventeen you have is inserting that markup, but it must be its fault. (Also, the way in which it breaks suggest it's vulnerable to XSS attacks, by processing HTML incorrectly, which is probably not good for you…) Matma Rex talk 22:55, 9 January 2025 (UTC)[reply]

It appears to be User:Moonythedwarf/extra-unreliable. nowiki is probably added by VisualEditor when the script messes with the page. PrimeHunter (talk) 23:52, 9 January 2025 (UTC)[reply]

Check out that script’s talk page, it’s definitely this script. Thanks for the help, it’s been really annoying having to deal with this weird visual bug! :) E_F⁵ 23:55, 9 January 2025 (UTC)[reply]

You could wrap the script in the following, it will then only run on page view.

if (mw.config.get("wgAction") == "view") {
//script here
}

Snævar (talk) 03:08, 10 January 2025 (UTC)[reply]

@PrimeHunter Thanks for finding the script. I suggested a fix: User talk:Moonythedwarf/extra-unreliable#Glitch fix. Matma Rex talk 17:21, 10 January 2025 (UTC)[reply]

Sections

I noticed that some sections are written like: == xxxxx == and some are written like ==xxxxx==. Some have gaps and some do not. Won't it be better if it was standardized? I prefer the one without gaps because it should save space. TrueMoriarty (talk) 06:47, 10 January 2025 (UTC)[reply]

No. Please write articles instead. —TheDJ (talk • contribs) 08:08, 10 January 2025 (UTC)[reply]

Articles about what?

TrueMoriarty (talk) 11:57, 10 January 2025 (UTC)[reply]

Or fix actual errors, of which there are literally tens of millions. – Jonesey95 (talk) 14:23, 10 January 2025 (UTC)[reply]

About what????? TrueMoriarty (talk) 16:43, 10 January 2025 (UTC)[reply]

The community hasn't made a project-wide standard for this. In general, you can use either style in articles you write, subject to the guidelines that do exist (see MOS:SECTIONHEAD as a start). But also, in general, match the style that already exists in an article and don't change style in an existing article without reason (see MOS:STYLEVAR). New guideline/rules are added sometimes, of course. I'd suggest editing and being around longer before considering making a proposal about this (not saying you are, just as a suggestion) (it's been discussed, at least tangentially many times: arbitrary recent example).(And welcome to Wikipedia and happy editing.) Skynxnex (talk) 16:16, 10 January 2025 (UTC)[reply]

I got your hint. If you don't want users newer than you to give some proposal here than you should put a password on this page and share it with users who you think is worthy and equal to you.

TrueMoriarty (talk) 17:01, 10 January 2025 (UTC)[reply]

I just was trying to give some background/history, in case you didn't know it. No objection to an actual proposal but I think if you want it to have a chance, you should do enough research to pretty comprehensively explain why and exactly what you'd want different. This is less a technical proposal and more a style or policy one, since English Wikipedia can't, as far as I know, make one of them technically impossible (since all Wikipedias share the common MediaWiki wikitext parser). Skynxnex (talk) 17:27, 10 January 2025 (UTC)[reply]

Please assume good faith. What you proposed is a cosmetic change. Cosmetic changes are discouraged because they clutter up watchlists, and require editor time to review without making any improvement to the Encyclopedia. Donald Albury 17:27, 10 January 2025 (UTC)[reply]

To address the original question. @TrueMoriarty: The presence or absence of the gaps makes absolutely no difference to either how the heading is displayed, or to how the MediaWiki software process the heading (such as, making section links work). Since they function identically, there is no advantage in altering either form to the other one.

Further: if an edit is made which does nothing other than remove those gaps, it doesn't save any space at all - in fact, it increases the amount of disk space that is used, since the MediaWiki software retains all previous versions of a page, effectively forever. You can see this by opening the "History" tab at the top of any page. --Redrose64 🌹 (talk) 13:16, 11 January 2025 (UTC)[reply]

request for new category

Hello. I have created a bot for updating amp url to its canonical/non-amp version. The BRFA will soon be approved. For now, I am using inputs from file(s), which were created using this list. In short, would it be possible possible to create a hidden/maintenance category which would contain articles that have "amp" anywhere in their url? False positives are preferred over missing amp url. The bot's programming is comprehensive so false positives wouldn't matter. Kindly let me know if this is possible, or if you need further information. Regards, —usernamekiran (talk) 10:52, 10 January 2025 (UTC)[reply]

PS: automatically populating category. —usernamekiran (talk) 11:34, 10 January 2025 (UTC)[reply]

It's possible, but in practice it's very unlikely you'd be able to convince MediaWiki developers to write and merge a change that does this. You'd probably do better to use a Toolforge database query or process a database dump. If you go the database query route, you'll probably need to batch your query with a condition like el_id > N AND el_id <= N+1000000 for relevant N to avoid timeouts. You'll also probably find that looking for just "contains 'amp'" gives very many false positives on words like "camp", "campus", "champion", "sample", "example", "Hampshire", and so on. Anomie ⚔ 12:51, 10 January 2025 (UTC)[reply]

Isn't that link just listing pages containing "https://amp." in wikitext? The bot can query for that directly using mw:API:Search instead of relying on a static list. – SD0001 (talk) 13:51, 10 January 2025 (UTC)[reply]

Some sites use path-based amp URLs, so adding searching for something like at least "/amp/" would be needed. But between these two that'd get almost everything. Skynxnex (talk) 15:37, 10 January 2025 (UTC)[reply]

As SD0001 said, you can use pagegenerators. For example:

from pywikibot import pagegenerators

site = pywikibot.Site("en", "wikipedia")
gen = pagegenerators.SearchPageGenerator('insource:"https://amp."', site=site)
for page in gen:
#your code

– DreamRimmer (talk) 16:49, 10 January 2025 (UTC)[reply]

Thanks everyone. I was doubtful about the category, so I was also working on code. But I had come up with:

for page in site.allpages(namespace=0):
#.. code
search_term = "https?:\/\/[^ ]*amp[^ ]*"

But the method suggested by SD0001, and DreamRimmer is less resource intensive. I will go with it. Regarding Anomie's query, I kept the search term intentionally lax, the bot has more regular expressions to weed out URLs containing words like "hampshire". I'm not sure if including such long code/strings in search would be a good idea. Thanks a lot again. —usernamekiran (talk) 13:22, 11 January 2025 (UTC)[reply]

Group changes by page doesn’t work in mobile view

The option to "Group changes by page in recent changes and watchlist" doesn’t work for me in mobile view. Am I missing something? YBG (talk) 12:38, 10 January 2025 (UTC)[reply]

Or perhaps this is a bug? YBG (talk) 02:50, 12 January 2025 (UTC)[reply]

V22's recent Appearance portlet has bigger min-content in grid than tools?

I'm trying to troubleshoot m:User:Aaron Liu/v22.css for when only the appearance menu is pinned to the right sidebar (i.e. tools is unpinned). For some reason, the right sidebar is much larger in this case, despite the grid template still being minmax(0, 1fr) min-content. Any idea why? Aaron Liu (talk) 12:56, 10 January 2025 (UTC)[reply]

Sergei Skripal wrong text displayed - mystery solved

The word "pleased" should be "convicted".

In the wiki-text it is "convicted".
I've done a history search using Wikiblame, I can't find the word "pleased" in recent history
I've purged the page.
I've done a nearly-null edit of the section.
In other browsers the word "convicted" appears, logged in or logged out.

Expand to see the reason, or puzzle over the mystery a little longer
Google Translate was re-writing the article, claiming to be translating from Russian to English.

All the best: Rich Farmbrough 13:38, 10 January 2025 (UTC).[reply]

Variable watchlist font sizes in Android desktop view

As shown below, when I view my watchlist in Desktop mode in Chrome on my Android phone, the font sizes vary the entire length of the list. It's disruptive! Can it be fixed?

I know I can use mobile mode, but it has its own shortcomings (such as all the edits to one page not being grouped together) so I often prefer desktop mode. Largoplazo (talk) 16:12, 10 January 2025 (UTC)[reply]

This is a Chrome/Mobile thing where it increases the font size of items which it thinks that you might be interested in. It's been raised on this page several times before, they should be in the page archives. In short: it's outside our control. --Redrose64 🌹 (talk) 13:21, 11 January 2025 (UTC)[reply]

Rollback does not count as an "edit"

Tracked in Phabricator
Task T382592

When an account conducts a rollback, the edit does not count towards their edit count according to Wikipedia, such as at their contributions page. At least, that is what I have observed. Because of this, there is a discrepancy between their edit count according to Wikipedia itself and their edit count according to XTools. Is this an intentional feature or a bug? By the way, I am not asking this because I am obsessed with my edit count, I am just curious as to why this is. Cyrobyte (talk) 21:09, 11 January 2025 (UTC)[reply]

This is a known bug that will be fixed with on the next WP:THURSDAY. T382592. * Pppery * _{it has begun...} 22:07, 11 January 2025 (UTC)[reply]

(edit conflict) Well, let's test it. As I type this, Special:Contributions/Redrose64, just refreshed, says "A user with 273,195 edits". I now make this edit, and I have 273,196 edits. I apply WP:ROLLBACK to that edit, and I again have 273,196 edits. So there appears to be truth in what you say. I'm wondering if there is some form of lag involved, and my edits might tick up later in the day. --Redrose64 🌹 (talk) 22:13, 11 January 2025 (UTC)[reply]

Background colour for Talk and other pages

How can I change the background colour of Talk pages without changing Skin. I'm using MonoBook, and the talk page background is blue, but I'd like to change it to white. I presume that I can edit my monobook.css or common.css (I have done previously for other similar things, eg Watchlist, so I'm familiar with the general process).

Do we have a list of all the tweaks that can be to CSS, rather than having to ask about individual ones? Mitch Ames (talk) 00:47, 12 January 2025 (UTC)[reply]

If that is what you really want to change, you can try adding this to your Special:MyPage/monobook.css :

body.ns-1 {
  background-color: white;
}

You can pretty much style anything at all, almost every element has a class or ID, view the page source to see them all. — xaosflux ^Talk 01:25, 12 January 2025 (UTC)[reply]

(edit conflict) @Mitch Ames: This is the current CSS in MonoBook:

div#content,
div#p-cactions li a:hover,
div#p-cactions li.selected a,
div#content div.thumb {
  background-color:#F8FCFF;
}

You could change it to white in Special:MyPage/monobook.css with !important added to override the existing CSS:

div#content,
div#p-cactions li a:hover,
div#p-cactions li.selected a,
div#content div.thumb {
  background-color:white !important;
}

CSS is a whole language and our skins have numerous things which can be targeted with CSS. A list of all possible tweaks is not realistic but maybe there should be an attempt to list significant tweaks many users may want. Some of Wikipedia:User scripts/List and Special:Preferences#mw-prefsection-gadgets make CSS tweaks without users having to copy the CSS. PrimeHunter (talk) 01:36, 12 January 2025 (UTC)[reply]

Help:User style § CSS has some info and sample changes. isaacl (talk) 04:11, 12 January 2025 (UTC)[reply]

Image placement is broken on Toque macaque

The images in the article Toque macaque (permalink to current version) are not placed correctly on desktop. Sometimes, the right-hand column of images overlaps with the reference section, but not always. –LaundryPizza03 (d c̄) 02:38, 12 January 2025 (UTC)[reply]

@LaundryPizza03: I used {{stack}} to avoid pushing down the left image.[7] Does that work for you? PrimeHunter (talk) 09:41, 12 January 2025 (UTC)[reply]