Jump to content

Wikipedia:Village pump (technical)

Page semi-protected
From Wikipedia, the free encyclopedia
(Redirected from Wikipedia:VPT)

 Policy Technical Proposals Idea lab WMF Miscellaneous 
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.

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

Today
[refresh]

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. [1] 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]

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):
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. Zerotalk 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. Zerotalk 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]

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]

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. EF5 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). EF5 20:41, 9 January 2025 (UTC)[reply]
The diff which added it is [3] where you used VisualEditor. I only found one other occurrence in searches and it was also you, 30 October 2024 [4] 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 [5] 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. EF5 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! :) EF5 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]
It is apparently intentionally disabled on mobile. It has been disabled in T228280. Matma Rex talk 17:43, 13 January 2025 (UTC)[reply]
@Matma Rex: is there any explanation of why it was disabled? Was there a bug? Is there a work item someplace to fix this functionality? I looked at the link you supplied but was unable to discern any reasons. Probably my shortcoming, but I’d appreciate it if you or someone else could explain.
As it is, I find myself swapping between desktop view to see the grouped changes and the mobile view to see the changes. Very inconvenient!
— YBG (talk) 06:23, 14 January 2025 (UTC)[reply]
Basically the only issue is that it's not mobile friendly. Izno (talk) 06:34, 14 January 2025 (UTC)[reply]
I don't know anything beyond what's written in the Phab task I linked, which just says it would be ill-suited for mobile. I guess phones were smaller in 2019… Matma Rex talk 08:12, 14 January 2025 (UTC)[reply]
Well, that mode is using separate tables for every row and just a counted number of spaces for correct spacing. It is not well-written and adapting it to mobile is practically impossible without major changes, so it is not a surprise that it was not enabled on mobile. There is a general task for a discussion about what to improve in RC/watchlist design, see phab:T380387, but it has a long way to go before resolving this. stjn 12:58, 14 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

Wrong word from unknown source in article - as viewed in Chrome, logged in.

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]
@PrimeHunter and Mitch Ames: I don't see why the !important annotation might be necessary. This rule sets the background colour for all talk namespaces, also all non-talk namespaces except article: 
div#content,
div#p-cactions li a:hover,
div#p-cactions li.selected a,
div#content div.thumb {
  background-color: white;
}
It works for me, and it should work for any other MonoBook user. It goes in Special:MyPage/monobook.css. As for do we have a list of all the tweaks that can be to CSS, the list is potentially infinite. --Redrose64 🌹 (talk) 15:24, 12 January 2025 (UTC)[reply]
Side note, this is an ancient customization from MediaWiki:Monobook.css#L-18, where you can see a few other places things are blue. Izno (talk) 20:32, 12 January 2025 (UTC)[reply]
And on that note, I adjusted the upstream CSS so some adjustment above will also be needed. !important is absolutely valid in user CSS, and is what I would recommend for this case. Izno (talk) 20:44, 12 January 2025 (UTC)[reply]
It's valid, yes, but it's not necessary. It artificially boosts the specificity when there should be no need to.
Anyway, this edit means that my CSS rule above should be replaced with the following: 
@media screen {
	body:not(.ns-0) #content,
	body:not(.ns-0) #p-cactions li a:hover,
	body:not(.ns-0) #p-cactions li.selected a,
	body:not(.ns-0) #content div.thumb { /* "Margin" for thumbs, padding for galleries */
		background-color: white;
	}
}
--Redrose64 🌹 (talk) 22:13, 12 January 2025 (UTC)[reply]

Will one of these solutions work on article pages, too? Today, every mainspace page i look at has a horrid off-puce colour background which i'm sure wasn't there yesterday ~ LindsayHello 08:52, 13 January 2025 (UTC)[reply]

@LindsayH Your colors are because your monobook.css appears to have some old copy of MediaWiki:Monobook.css in it that emulates the relevant CSS I adjusted today. The rules upstream were overriding these because they were more specific. Now they simply don't apply in mainspace so your rules are engaging. Try removing the CSS in the "LIGHT BLUE SECTION". Izno (talk) 06:39, 14 January 2025 (UTC)[reply]
(Except the .usermessage block which it looks like you've customized to be red rather than orange.) Izno (talk) 06:40, 14 January 2025 (UTC)[reply]
Thank you, Izno; this is one of the things i love about our community ~ there's always someone who knows more than i about...everything, but no one hoards it, it's all shared. Begone, puce ~ LindsayHello 08:26, 14 January 2025 (UTC)[reply]

Image placement is broken on Toque macaque

Screenshot with broken image placement that overlaps references section.

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 (dc̄) 02:38, 12 January 2025 (UTC)[reply]

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

Display bizarreness with green on black gadget

Wikipedia namespace pages (like this one) and my watchlist have started displaying oddly for me, a user of the green on black gadget. Instead of a black background they are shewing a white background with green text. Started in the last hour or so. DuncanHill (talk) 22:05, 12 January 2025 (UTC)[reply]

It's happening on Talk pages too. DuncanHill (talk) 22:18, 12 January 2025 (UTC)[reply]
Do you use Monobook? Izno (talk) 22:18, 12 January 2025 (UTC)[reply]
Yes, I was about to ask you if you had just broken it, after reading the thread above. DuncanHill (talk) 22:19, 12 January 2025 (UTC)[reply]
Amendments are required at MediaWiki:Gadget-Blackskin.css#L-677, unless Izno is willing to revert this edit. I can't do either, because I don't have the WP:INTADMIN right. --Redrose64 🌹 (talk) 22:34, 12 January 2025 (UTC)[reply]
Should be fixed. You may need to hard refresh. Izno (talk) 22:35, 12 January 2025 (UTC)[reply]
Seems fixed now. Talk pages and Wikipedia space fixed after a single hard refresh. Watchlist took three. Thank you. DuncanHill (talk) 22:37, 12 January 2025 (UTC)[reply]

Problem For Translate page

Hello everyone. I don’t know who is in charge for coding the Translate page on Wikipedia. But I wanted to send my message to the Wikipedia coders, and that is that in the Wikipedia translation system, the information boxes for individual persons (i.e personal biography box- see: Template:Infobox person) are not automatically translated, and it is time-consuming for Wikipedia users to manually translate and change the links one by one from English to another language. Please, could the coders come up with a solution for translating the information template boxes? Thank you. Hulu2024 (talk) 19:22, 13 January 2025 (UTC)[reply]

Use ContentTranslate. It is designed to translate links and will even give you a machine translation of text outside of templates too. It will not give you a final translation, you are supposed to review it yourself.
As for templates, English Wikipedia does not have a translation system. It is feasible for a template to translate dates and language names, but most things can not be translated by templates. It is not what templates do. Snævar (talk) 08:32, 14 January 2025 (UTC)[reply]
Thanks. My another question is that does your system enable to translate from non-english to another language too ? because i saw french and german and italic wiki pages and some of them doesn't had english equal page, but i didn't saw any trantion button (to Offer) for translating into persian language (because my native lang is persian). Should i ask it in Meta ? Hulu2024 (talk) 09:32, 14 January 2025 (UTC)[reply]
From fa:ویژه:ترجمهٔ_محتوا choose a different language instead of English. French and German will translate over to Persian. ContentTranslate uses Google Translate, MinT or Yandex to translate, so stay within the languages these engines can translate from. The links are translated from Wikidata, it uses the links from there.
For other languages than those supported by these existing engines, you would need an machine translator that is under a free licence (for example MIT, CC-BY-SA, GFDL) and you would ask your community first, then on phabricator. Snævar (talk) 11:58, 14 January 2025 (UTC)[reply]
@Snævar Thanks a lot. Hulu2024 (talk) 12:43, 14 January 2025 (UTC)[reply]

Is PetScan tool down or broken?

Hi, Today PetScan (https://petscan.wmcloud.org) is slow to startup, and when it does, Field names are in Red. A simple request that normally runs very fast, errors out with no results and displays <span style='font-size:7pt;color:red'>num_results</span> just below the "Submit" button. Not sure where to report so asking for help here. Regards, JoeNMLC (talk) 20:32, 13 January 2025 (UTC)[reply]

 Done - PetScan is now running again. Cheers! JoeNMLC (talk) 20:54, 13 January 2025 (UTC)[reply]

afdstats tool down message: Wikimedia Toolforge Webservice is unreachable

afdstats has been slow since yesterday

Getting this message today on the

" Wikimedia Toolforge Webservice is unreachable

The tool responsible for the URL you have requested, https://afdstats.toolforge.org/afdstats.py?name=Maile66&max=&startdate=&altname=, is not currently responding. If you have reached this page from somewhere else...

This URI is managed by the afdstats tool, maintained by 0xDeadbeef, Ahecht, APerson, Legoktm, Scottywong, Σ.

You may wish to notify the tool's maintainers (above) about the error. If you maintain this tool

The web service for this tool is running but cannot be reached. Please check the error logs of your web service."

— Maile (talk) 20:33, 13 January 2025 (UTC)[reply]

For the moment, it's working again. — Maile (talk) 20:42, 13 January 2025 (UTC)[reply]
cc @Ahecht Sohom (talk) 23:41, 13 January 2025 (UTC)[reply]
@Maile66 No idea. Seems to be working fine, and nothing obvious in the error logs. I restarted the webservice for good measure, but I'd chalk it up to toolforge weirdness. --Ahecht (TALK
PAGE) 05:27, 14 January 2025 (UTC)[reply]

Tech News: 2025-03

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

Weekly highlight

  • The Single User Login system is being updated over the next few months. This is the system which allows users to fill out the login form on one Wikimedia site and get logged in on all others at the same time. It needs to be updated because of the ways that browsers are increasingly restricting cross-domain cookies. To accommodate these restrictions, login and account creation pages will move to a central domain, but it will still appear to the user as if they are on the originating wiki. The updated code will be enabled this week for users on test wikis. This change is planned to roll out to all users during February and March. See the SUL3 project page for more details and a timeline.

Updates for editors

  • On wikis with PageAssessments installed, you can now filter search results to pages in a given WikiProject by using the inproject: keyword. (These wikis: Arabic Wikipedia, English Wikipedia, English Wikivoyage, French Wikipedia, Hungarian Wikipedia, Nepali Wikipedia, Turkish Wikipedia, Chinese Wikipedia) [7]
  • One new wiki has been created: a Wikipedia in Tigre (w:tig:) [8]
  • Recurrent item View all 35 community-submitted tasks that were resolved last week. For example, there was a bug with updating a user's edit-count after making a rollback edit, which is now fixed. [9]

Updates for technical contributors

  • Advanced item Wikimedia REST API users, such as bot operators and tool maintainers, may be affected by ongoing upgrades. Starting the week of January 13, we will begin rerouting some page content endpoints from RESTbase to the newer MediaWiki REST API endpoints for all wiki projects. This change was previously available on testwiki and should not affect existing functionality, but active users of the impacted endpoints may raise issues directly to the MediaWiki Interfaces Team in Phabricator if they arise.
  • Toolforge tool maintainers can now share their feedback on Toolforge UI, an initiative to provide a web platform that allows creating and managing Toolforge tools through a graphic interface, in addition to existing command-line workflows. This project aims to streamline active maintainers’ tasks, as well as make registration and deployment processes more accessible for new tool creators. The initiative is still at a very early stage, and the Cloud Services team is in the process of collecting feedback from the Toolforge community to help shape the solution to their needs. Read more and share your thoughts about Toolforge UI.
  • Advanced item For tool and library developers who use the OAuth system: The identity endpoint used for OAuth 1 and OAuth 2 returned a JSON object with an integer in its sub field, which was incorrect (the field must always be a string). This has been fixed; the fix will be deployed to Wikimedia wikis on the week of January 13. [10]
  • Many wikis currently use Cite CSS to render custom footnote markers in Parsoid output. Starting January 20 these rules will be disabled, but the developers ask you to not clean up your MediaWiki:Common.css until February 20 to avoid issues during the migration. Your wikis might experience some small changes to footnote markers in Visual Editor and when using experimental Parsoid read mode, but if there are changes these are expected to bring the rendering in line with the legacy parser output. [11]

Meetings and events

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

MediaWiki message delivery 01:39, 14 January 2025 (UTC)[reply]

Help needed for accurate table sorting

In the article for the List of wars by death toll, the table has the ability to automatically sort the list based on death range, year, etc. It recently came to my attention that, in the year section, the table doesn't seem to be identifying the BCs, and is ignoring them and only counting the numbers. I don't know how to fix this, and it's very annoying

Here's a screenshot: https://ibb.co/2d3J21P EarthDude (talk) 10:27, 14 January 2025 (UTC)[reply]

@EarthDude See Help:Sortable tables#Years BC are a problem which has a couple of options. the wub "?!" 11:08, 14 January 2025 (UTC)[reply]
Thanks a lot! That seems to have fixed the issue EarthDude (talk) 13:56, 14 January 2025 (UTC)[reply]

Finding articles with invalid parameters

There is a LTA that has been messing around with population figures in articles about settlements in Russia but also Ukraine. In some of their older edits, they have included invalid parameters in the infobox. See for example this edit where |pop_2024census= is invalid because there was no 2024 census in Russia (the last one was conducted in 2021, and before that, in 2010). This was later removed because it is an invalid parameter but the old population figures were missing as a result. Is there a way to find articles that have a similar issue due to invalid parameters being introduced? Thanks. Mellk (talk) 13:35, 14 January 2025 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=1269401464"