Misplaced Pages

Latest revision as of 22:02, 17 January 2025

• Table of contents
• First discussion
• End of page
• New post

• WP:VPT
• WP:VP/T
• WP:TECHPUMP
• WP:PUMPTECH

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: Misplaced Pages:FAQ/Technical) Click "" 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 Misplaced Pages services, see Reporting a connectivity issue.

• Refining the administrator elections process
• Blocks for promotional activity outside of mainspace

• view
• edit
• history
• watch
• archive
• talk
• purge

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)

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

It is apparently intentionally disabled on mobile. It has been disabled in T228280. Matma Rex talk 17:43, 13 January 2025 (UTC)

@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)

Basically the only issue is that it's not mobile friendly. Izno (talk) 06:34, 14 January 2025 (UTC)

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)

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)

@Matma Rex, @Izno, @Stjn: Thanks one and all! I will see if I can find a work-around. — YBG (talk) 15:54, 14 January 2025 (UTC)

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)

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 01:25, 12 January 2025 (UTC)

(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 Misplaced Pages: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)

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

@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)

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)

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)

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)

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 ~ Lindsay 08:52, 13 January 2025 (UTC)

@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)

(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)

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 ~ Lindsay 08:26, 14 January 2025 (UTC)

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

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

Yes, thank you. –LaundryPizza03 (dc̄) 18:58, 12 January 2025 (UTC)

Display bizarreness with green on black gadget

Misplaced Pages 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)

It's happening on Talk pages too. DuncanHill (talk) 22:18, 12 January 2025 (UTC)

Do you use Monobook? Izno (talk) 22:18, 12 January 2025 (UTC)

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)

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)

Should be fixed. You may need to hard refresh. Izno (talk) 22:35, 12 January 2025 (UTC)

Seems fixed now. Talk pages and Misplaced Pages space fixed after a single hard refresh. Watchlist took three. Thank you. DuncanHill (talk) 22:37, 12 January 2025 (UTC)

Problem For Translate page

Hello everyone. I don’t know who is in charge for coding the Translate page on Misplaced Pages. But I wanted to send my message to the Misplaced Pages coders, and that is that in the Misplaced Pages 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 Misplaced Pages 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)

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 Misplaced Pages 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)

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)

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)

@Snævar Thanks a lot. Hulu2024 (talk) 12:43, 14 January 2025 (UTC)

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)

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

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)

For the moment, it's working again. — Maile (talk) 20:42, 13 January 2025 (UTC)

cc @Ahecht Sohom (talk) 23:41, 13 January 2025 (UTC)

@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)

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 Misplaced Pages, English Misplaced Pages, English Wikivoyage, French Misplaced Pages, Hungarian Misplaced Pages, Nepali Misplaced Pages, Turkish Misplaced Pages, Chinese Misplaced Pages)
• One new wiki has been created: a Misplaced Pages in Tigre (w:tig:)
• 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.

Updates for technical contributors

• 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.
• 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.
• 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.

Meetings and events

• The next meeting in the series of Wikimedia Foundation Community Conversations with the Wikimedia Commons community will take place on January 15 at 8:00 UTC and at 16:00 UTC. The topic of this call is defining the priorities in tool investment for Commons. Contributors from all wikis, especially users who are maintaining tools for Commons, are welcome to attend.

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)

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)

@EarthDude See Help:Sortable tables#Years BC are a problem which has a couple of options. the wub "?!" 11:08, 14 January 2025 (UTC)

Thanks a lot! That seems to have fixed the issue EarthDude (talk) 13:56, 14 January 2025 (UTC)

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)

Yes. That article was in Category:Pages using infobox Russian inhabited locality with unknown parameters. If you do not have the Preference enabled to show hidden categories, you might benefit from enabling it (although it can result in a lot of stuff that you may not care about). – Jonesey95 (talk) 15:18, 14 January 2025 (UTC)

Thank you. Is there any way to find specific invalid parameters (like the example above)? I was also thinking that it might be easier to comb through the edits of the ranges of known IPs (some of which have been blocked). Mellk (talk) 15:25, 14 January 2025 (UTC)

@Mellk: Category:Pages using infobox Russian inhabited locality with unknown parameters is sorted by the name of the unknown parameter. Click "Po" to get parameters starting with "Po" or "po" (and eventually something later). If there are multiple unknown parameters then it may be sorted by the first. You can also consider using User:PrimeHunter/Sortkeys.js or User:PrimeHunter/SortkeysAPI.js. PrimeHunter (talk) 16:31, 14 January 2025 (UTC)

I see, that makes a lot more sense now. Thank you! Mellk (talk) 17:16, 14 January 2025 (UTC)

Hiding Images

Anyone know if it's easily possible to block all images shown on Mediawiki:Bad image list? I don't want to deal with Anomie's hide all images script since I use images on my talk page and my user page (as well as there being other images on pages that aren't necessarily inappropriate), nor with having to import every page into my common.css using .page-(Name) img {display: none;}. I'm not entirely sure if there will ever be a scenario where I will encounter an image from the bad image list since I revert vandalism with AntiVandal and I mainly go to pages without these images, but I'd still like something just in case. Thank you! / RemoveRedSky 16:54, 14 January 2025 (UTC)

Hmm... This is a more fiddly task than it may appear at first glance. The absolute "best" way to, is to install in your browser a content blocker extension such as uBlock Origin, take the bad image list and process it into a filter list it can use, then add that filter list. Or alternately filter your network traffic "upstream" at your LAN Internet gateway to block "fetches" of those files in the list.

The "foolproof", or nearly enough, way to do it via a user script, is going to involve sticking a CSS rule in your user CSS to default-hide all images, and then have a user script go through and un-hide all of them that aren't on the bad list. That is similar to what Anomie's image hider is doing.

Anything else can't guarantee you won't see the images, before it then is able to hide them—it inherently suffers from race conditions, the flash of unstyled content problem "infamous" in Web development. Your browser goes right ahead and tries to load everything and render and show it to you since that's what it's designed to do; meanwhile, it also loads all the client-side JavaScript and executes it, with no guarantees of what gets to run first or how long it takes to load & execute. That all has to happen before any script can then go through and hide bad images—so the unpredictable result of what happens on any given page load, is based on what "wins the race": the browser's page display rendering, or its JavaScript engine? The "best" methods I detailed avoid this issue by either running as a browser extension, which has much more control over the browser and what it does and doesn't do; or, by just gatekeeping your network connection on a completely separate device. (You could also do the network filtering by running a filtering proxy server and pointing your browser at the proxy.)

I think I might be willing to take a crack at hacking something up if you'd find it useful. Like I said, the method I recommend is to massage the bad image list into a format something like uBlock can use. So let me know if you find any of the suggestions here helpful. --Slowking Man (talk) 05:11, 16 January 2025 (UTC)

if anyone is bored, I'd suggest to try to write a Service worker and filter the requests like that. Then there could be lists of blocked images, that people could share and import from each other with levels of criteria that they want to apply. It would help avoid the flash of content. —TheDJ (talk • contribs) 10:33, 17 January 2025 (UTC)

Adding categories to vital articles

I would like to add a category to all the vital articles. For example, on Talk:Albert Einstein, there is a category that says Misplaced Pages level-3 vital articles in People. I would like to add Misplaced Pages level-3 vital articles to the page without manually adding each category to every page. It seems like there is a template that added the category so I am wondering if it has to do anything with the template to add the category. Interstellarity (talk) 17:06, 14 January 2025 (UTC)

Interstellarity, Category:Misplaced Pages level-3 vital articles is a container category. It should not have individual articles. — Qwerfjkltalk 18:09, 14 January 2025 (UTC)

Saw the notice. Didn’t see that. Interstellarity (talk) 18:34, 14 January 2025 (UTC)

"Hidden" template formatting issue

Content 2.1

I present for your consideration two transclusions of {{hidden}}. I see less space between Header 1 and Content 1.1 than between Header 2 and Content 2.1. Yet the only coding difference is the existence of Content 2.2. Why? Does anyone not using Windows/Firefox see this anomaly? If not, I'll assume a browser issue. If so, can the template be modified to correct this? ―Mandruss ☎ 05:33, 15 January 2025 (UTC)

Different OS/browser comment here and I see it, so it's not just you. I'll leave it to someone more versed in templates to try to troubleshoot, but you aren't crazy and it doesn't seem to be a browser/OS specific issue. -bɜ:ʳkənhɪmez | me | talk to me! 05:33, 15 January 2025 (UTC)

The parser/renderer, or whatever it's called, inserts <p>...</p> tags into the second one, but not into the first one.

<div class="mw-content-ltr mw-parser-output" lang="en" dir="ltr"><style data-mw-deduplicate="TemplateStyles:r1214851843">.mw-parser-output .hidden-begin{box-sizing:border-box;width:100%;padding:5px;border:none;font-size:95%}.mw-parser-output .hidden-title{font-weight:bold;line-height:1.6;text-align:left}.mw-parser-output .hidden-content{text-align:left}@media all and (max-width:500px){.mw-parser-output .hidden-begin{width:auto!important;clear:none!important;float:none!important}}</style><div class="hidden-begin mw-collapsible" style=""><div class="hidden-title skin-nightmode-reset-color" style="text-align:center; text-align:left;">Header 1</div><div class="hidden-content mw-collapsible-content" style="">
Content 1.1</div></div>
<link rel="mw-deduplicated-inline-style" href="mw-data:TemplateStyles:r1214851843"><div class="hidden-begin mw-collapsible" style=""><div class="hidden-title skin-nightmode-reset-color" style="text-align:center; text-align:left;">Header 2</div><div class="hidden-content mw-collapsible-content" style="">
<p>Content 2.1
</p>
Content 2.2</div></div></div>

This is not really an explanation, but it may help someone track down why it happens. – Jonesey95 (talk) 06:13, 15 January 2025 (UTC)

Thanks for that, it will help. Someday I might take the time to learn how to do that myself. I know it can't be that hard. ―Mandruss ☎ 07:03, 15 January 2025 (UTC)

Special:ExpandTemplates can be fun. I used the "Show raw HTML" option. – Jonesey95 (talk) 15:01, 15 January 2025 (UTC)

Many templates use a parameter for each line to avoid multi-line inputs. Your input contain line breaks which the parser is handling in a way you don't like. You could decide to use {{Break}} to achieve this in your example:

Or you could use collapse templates for more natural multi-line support if you are okay with a different look and feel:

At least you may have some options now. Matthew Yeager (talk) 07:18, 15 January 2025 (UTC)

Thanks. I'm not interested in kludgy workarounds for a problem that shouldn't exist in the first place. I'm a retired non-web developer; some called me a perfectionist because my quality standards were higher than theirs. If I were an editor who had some time invested in {{hidden}} (pride of partial authorship), I'd be all over this. I'm also not interested in a solution to my case alone; my focus is on the project.I'm hoping someone will take this on. If no one does, I'll just live with the problem. ―Mandruss ☎ 08:09, 15 January 2025 (UTC)

Number of G13 deletions

How many abandoned drafts are deleted as G13 each month or year? Is there a report or metrics showing how many G13 deletions are performed? More generally, are there statistics showing the frequency of the various types of speedy deletion including G13? It is G13 at this time that I am asking about, but, as a former quantitative program management analyst and computer performance analyst, I will probably be interested in any sort of deletion statistics. Robert McClenon (talk) 16:32, 15 January 2025 (UTC)

G13 deletions. – DreamRimmer (talk) 16:51, 15 January 2025 (UTC)

Other deletions. – DreamRimmer (talk) 16:57, 15 January 2025 (UTC)

Thank you, User:DreamRimmer. That is interesting. So it appears that there are more than 5000 G13 deletions each month. Robert McClenon (talk) 18:35, 15 January 2025 (UTC)

The page history of User:SDZeroBot/G13 Watch shows the daily numbers. 160–220 per day. – SD0001 (talk) 10:01, 16 January 2025 (UTC)

Dark mode and {{Yes}}

Hi, so {{Yes}} has always been a bit hard to add dark mode compatibility for. skin-invert isn't that useful as it doesn't blend in with the natural background (i.e. the dark mode background isn't #000). I made Template:Yes/styles.css, however anywhere I put the templatestyles tag introduces problems in one way or another. I think the easiest solution is to insert these styles into MediaWiki:Common.css, since light-dark() function in CSS doesn't have good compatibility. Thoughts? —Matrix(!) _{ping one} {u - t? - _uselessc} 17:37, 15 January 2025 (UTC)

As I mentioned on that template's talk page, it would be great to have a fix that worked for all of the templates in Category:Unified table cell templates. – Jonesey95 (talk) 20:54, 15 January 2025 (UTC)

@Jonesey95: yeah, that's the issue. There's no good place to insert a templatestyles tag, and there are downsides with inserting stuff into MediaWiki:Common.css (namely only IAs can edit). Maybe what we can do is have a hidden gadget that loads CSS from a template-level CSS page (Template:Yes/styles.css) so that any template editor can edit it. —Matrix(!) _{ping one} {u - t? - _uselessc} 18:11, 16 January 2025 (UTC)

What's the issue with adding the templatestyles tag? – SD0001 (talk) 19:47, 16 January 2025 (UTC)

It can not be done because the template is used within a table. The parser then removes the <> characters and tries to make it work as an table styling, rendering it completely useless. Snævar (talk) 22:21, 16 January 2025 (UTC)

I would word it as.. the template does not output wikitext, it outputs inline CSS. As such it can only be used in places that accept inline CSS and those places do not handle arbitrary wikicode, so they cannot handle the templatstyles tag being added by the template. This is not surprising, we've always been warning about these inline 'table fragments' generated by templates, and it is also why they don't work in things like Visual Editor. —TheDJ (talk • contribs) 10:21, 17 January 2025 (UTC)

But {{Yes}} is inline CSS followed by a pipe followed by table cell content, which is wikitext, alongside which adding the templatstyles tag should be possible. – SD0001 (talk) 11:06, 17 January 2025 (UTC)

Yes, you can add the tag. What you cannot do is ensure the tag comes before the class name.

I have a few reasons why I haven't bothered touching these templates.

1. The above.
2. I have a niggling feeling you'd start seeing some pages hitting one or another parser limits, either PEIS for the addition of the tag, or the strip marker expansion limit (which is apparently and surprisingly possible to hit despite its big size because the contents of each tag are expanded before they're de-duplicated, IIUC).
3. I've been thinking about whether it makes sense to have the styles like this in a bunch of separate templates or whether it makes sense to have a single table style template. Maybe a mix between the commonly used ones and the others.

Izno (talk) 18:58, 17 January 2025 (UTC)

I think centralizing the styling for templates intended to be used for individual table cells would make sense. It would make it easier to ensure that the styling remains accessible in both light and dark modes, and different skins (regardless of where the skin-specific adaptations are made). I think this is worth the additional cost of having to add a <templatestyles> element before the table. A helper template could be used, and it could take arguments to allow it to select one or more categories that it could map to specific stylesheets. isaacl (talk) 19:17, 17 January 2025 (UTC)

Harv warnings on bundled refs

Could one of you referencing mavens around here please take a look at Mount Vernon and tell me why the multiple refs introduced back in February 2024 by another editor aren't working? I know that some of the bundled refs are working for cite web references but the ones for cite books are not. If you could explain what is going wrong here and tell me here how to fix the issues, I'd really appreciate it. Maybe if I do it myself and understand what is going on, I'll be able to fix something similar next time. Thanks, Shearonink (talk) 20:48, 15 January 2025 (UTC)

What do you mean by "not working"? I don't see any error messages or problems. Give a specific example of what you think should happen and then explain what is currently happening. – Jonesey95 (talk) 20:56, 15 January 2025 (UTC)

Sorry I wasn't more clear. There are 9 Harv warnings being thrown at present. They are all emanating from these 2 refs:Ref 52 & Ref 65, both of which have similar nomenclature and were added at the same time. I know you know all about this but for the kibitzers in the back, if one can't see Harv errors and Harv warnings one has to install User:Trappist the monk/HarvErrors.js. Thanks - Shearonink (talk) 21:30, 15 January 2025 (UTC)

I see them. They're warnings, not errors. You can safely ignore them. --Redrose64 🌹 (talk) 22:28, 15 January 2025 (UTC)

Oh I know they're warnings and they can be ignored, but sometimes I like to tidy things up around here... - Shearonink (talk) 00:41, 16 January 2025 (UTC)

(edit conflict)

If you think that there won't be any {{sfn}} or {{harv}} templates linking to the nine long-form citations in the three bundles (permalinks: ref 52, ref 54, ref 65), you can set |ref=none in each long-form citation template in the bundles to suppress the warning messages.

—Trappist the monk (talk) 22:39, 15 January 2025 (UTC)

Thanks Trappist the monk, I appreciate the tip. I do know about the ref=none fix but what I want to know is *why* are these particular bundles throwing Harv warnings when other bundles in the article aren't? It's probably as plain as the nose on my face but I just can't figure it out. - Shearonink (talk) 00:41, 16 January 2025 (UTC)

The warning messages have nothing to do with bundling. Were those long-form citations unbundled and listed as individual long-form templates, they would show the same warning messages until they were linked by matching {{sfn}} or {{harv}} templates. The long-form citations show the warning now because (apparently) there is no need to link to any of them individually with {{sfn}} or {{harv}}.

So, of course, your next question is: What about "George Washington's Last Will and Testament" in ref 52 (permalink)? It doesn't show the warning message because that {{cite web}} template does not name an author/contributor/editor. To create a CITEREF anchor ID, all cs1|2 templates require at least one author/contributor/editor name parameter; no author/contributor/editor: no CITEREF anchor ID so nothing for a short-form template to link to so no warning message. Setting |ref=none tells cs1|2 that it must not create a CITEREF anchor ID; same as if there were no author/contributor/editor.

—Trappist the monk (talk) 01:17, 16 January 2025 (UTC)

With the harv script that I am using, bundled refs have always shown the "Harv warning: There is no link pointing to this citation. The anchor is named CITEREFWashington" messages for unlinked citation templates, while unbundled, unlinked refs in the same article do not show errors. I always figured this was a limitation in the script. I am using the Ucucha script. – Jonesey95 (talk) 02:17, 16 January 2025 (UTC)

Special:LintErrors/duplicate-ids lists citations with the same author and year, even if there is no harv or sfn linking to them. It also has other ID conflicts. For example Mount Vernon lists three errors. Snævar (talk) 14:30, 16 January 2025 (UTC)

Selection of image displayed at the top of the article / in the search results on mobile devices

When I view 2008 Formula One World Championship on my mobile device, the image displayed at the top of the article is the second image in the article, which is an image of the driver who finished second in the championship. The same applies to the image displayed when I search for the article in the search bar on my mobile device. Other editors report seeing the same thing. It would be preferable if it displayed the first image in the article, which is an image of the the driver who won the championship, as occurs for most (all?) the other Formula One season summary articles, e.g. 2009 Formula One World Championship, 2010 Formula One World Championship, etc. Is there a way to select/specify which article is displayed at the top of the article / in the search results on mobile devices? Thanks. DH85868993 (talk) 20:51, 15 January 2025 (UTC)

When I look at that article in Safari on my iPhone in mobile view, I see the lead, then the F1 season box, then four images, just below the F1 season box. There is no image at the top of the article. Let us know how you are viewing the article, and maybe provide a screen shot. – Jonesey95 (talk) 20:59, 15 January 2025 (UTC)

Interesting - I see the correct first image of Hamilton after the season box (first in a group), so all ok there, but I can confirm seeing the second of Massa as the thumbnail when searching for it, which probably shouldn't be happening. I can't see anything affecting those images which should mean one gets skipped unless it's somehow related to the use of {{Multiple image}} Andrew Gray (talk) 21:14, 15 January 2025 (UTC)

@DH85868993: I don't know what you mean by "the image displayed at the top of the article". The image in mobile search results is selected by mw:Extension:PageImages#Image choice which says "images smaller than 119 pixels are negatively weighted". The first image has width 111px due to a small width/height ratio and the current parameters to {{Multiple image}}, so the second image is selected instead. total_width = 500 or other images could change it. PrimeHunter (talk) 21:18, 15 January 2025 (UTC)

@PrimeHunter: Changing the total_width has fixed it, thanks. Re the image at the top of the article: When I view the article in the Misplaced Pages app on my Android Samsung phone, it displays an image at the top, above the article title. (Sorry, I didn't realise that I was viewing the article via the app). DH85868993 (talk) 21:34, 15 January 2025 (UTC)

Another category/java space user mess

Can someone with the tools & know-how look at User:RL0919/JWB-settings.json (the user hasn't edited for two years) and remove the page from the redirect Category:NA-Class Theatre articles (and preferably from all pages as well). Thanks in advance. Timrollpickering (talk) 21:44, 15 January 2025 (UTC)

The page hasn't been edited in two years but RL0919 has thousands of other edits in that time and several in the last week. The page is evaluated as wikitext when categories are added so each {{WikiProject Theatre|...}} causes categories. For js/css pages it can be avoided with wikitext comments inside js/css comments but the json format doesn't have comments. It could be avoided by making some valid json which contains <!-- before the first {{WikiProject Theatre|...}} and --> after the last. It could for example be arbitrary replace rules which will never be applied in practice. PrimeHunter (talk) 22:51, 15 January 2025 (UTC)

Would changing the page's content model from JavaScript to JSON help with the unwanted categorization? Only User:RL0919 or an interface administrator would be able to do it. —⁠andrybak (talk) 22:58, 15 January 2025 (UTC)

That might do it. The source of User:Jackmcbarn/sandbox.json contains ] but the page is not in Category:X1. It would have been there if it had content model JavaScript or CSS so it appears JSON pages are not evaluated as wikitext when link tables are made. PrimeHunter (talk) 23:12, 15 January 2025 (UTC)

I have changed the content model to JSON. * Pppery * _{it has begun...} 23:14, 15 January 2025 (UTC)

As the page name hints, that page is settings related to the JavaScript Wiki Browser tool. This page is updated whenever I use the "Save to wiki" option to save my JWB settings. I just did it to confirm that. If this can result in the page getting placed into a category (presumably through saving settings related to editing a category or the pages therein), then you might want to report the issue at User talk:Joeytje50/JWB, so you won't have to do manual fixes every time someone else uses this option. --RL0919 (talk) 23:40, 15 January 2025 (UTC)

It looks like JWB used to save settings at .js and automatically moved it to .json, hence the mismatch between content model and page name/file type. There are 22 such user pages. Nardog (talk) 00:18, 16 January 2025 (UTC)

The only category currently in the 22 pages is Category:Pages with missing files in User:Joeytje50/JWB-settings.json, but maybe an interface admin should change content model for all 22 to avoid future issues and make the pages more readable. PrimeHunter (talk) 00:35, 16 January 2025 (UTC)

I've fixed it for User:Joeytje50/JWB-settings.json. – SD0001 (talk) 10:08, 16 January 2025 (UTC)

I updated the batch JS-->JSON. — xaosflux 10:34, 16 January 2025 (UTC)

Unable to access contribs or talk page for user

On NPP I came across Conditional probability/temp, which was said to be created by ]. When I try to click that user name, or the links to their talk page or contributions, I get the "Bad title" special page, saying "The requested page title contains unsupported characters: ">"." I can't even link to his name here. I don't know if this user exists, or if it is some other glitch, but if the user exists then I guess such user names should be disallowed technically. Fram (talk) 11:30, 16 January 2025 (UTC)

It's an import artifact. Looking at the deleted page, it's linked as nost>Larry Sanger, which goes to the right place. It was reimported properly into Conditional probability, where it's correctly linked] to User:Larry Sanger (the 29 June 2001 edit). —Cryptic 11:40, 16 January 2025 (UTC)

Okay, thanks. Seems like a waste of time to create a temp page and get it deleted just so we now have this edit in the history as well, but that's not a VPT issue of course. Perhaps getting the correct user link in the NPP feed would be better though. Fram (talk) 11:46, 16 January 2025 (UTC)

Some old edits from before the current MediaWiki software have been found and systematically imported. See Misplaced Pages:Misplaced Pages's oldest articles. There isn't always a corresponding MediaWiki user. PrimeHunter (talk) 13:26, 16 January 2025 (UTC)

Yeah that was a silly mistake on my part and comes from not checking the " Assign edits to local users where the named user exists locally " check box in the import form (that box is normally left unchecked for imports from other language Wikipedias, but in this case where it's from one English Misplaced Pages database to another, I ideally want to check it). See my logs at "Conditional probability". My current project is to try to match accounts in the August 2001 database dump with those in the current database as closely as possible. Graham87 (talk) 01:49, 17 January 2025 (UTC)

can't pan around map on Red Rock-Secret Mountain Wilderness with a mouse / touchscreen

When I click on / expand the map for Red Rock-Secret Mountain Wilderness I can't move around on the map by clicking and dragging with my mouse. I can move around with the directional keys on my keyboard but not a mouse or clicking and dragging with my touchscreen.

Any ideas? TerraFrost (talk) 14:38, 16 January 2025 (UTC)

Can confirm. JS console reports shape.getElement is not a function. (In 'shape.getElement()', 'shape.getElement' is undefined) It seems other pages with other maps and shapes work, so I suspect it is something particular to this shape. —TheDJ (talk • contribs) 10:08, 17 January 2025 (UTC)

Adding italics to links in the visual editor

When you highlight a link in the visual editor and italicise it, it makes the code ] rather than '']''. Is this easy to fix? Kowal2701 (talk) 19:50, 16 January 2025 (UTC)

It's possible to work-around the problem, but very difficult to fix it so that it never occurs. In a nutshell (and for simple examples like this), if the text is made italic first, and then a link is added, it will result in the desired outcome. If the text is linked first, and then made italic, it will result in the example you write above. There are technical details in phab:T247241#5957890 and in phab:T52098. HTH. Quiddity (WMF) (talk) 20:13, 16 January 2025 (UTC)

Okay, thank you. I'll remember to italicise first Kowal2701 (talk) 20:25, 16 January 2025 (UTC)

What happened to Geohack?

Today, upon clicking the {{coords}} template (example), I got a 404. Maybe this is a temporary problem, but given the use of the coords feature it's fairly impactful. JayCubby 16:04, 17 January 2025 (UTC)

• It's down, and it isn't maintained by volunteers that are active on-wiki. The last RFC to move away from it didn't pass (c.f. Misplaced Pages:Village_pump_(proposals)/Archive_202#h-RfC:_Updating_Template:Coord_to_use_Kartographer-20230510062200 and Template_talk:Coord/Archive_14#Switching_to_Kartographer ). — xaosflux 18:13, 17 January 2025 (UTC)

  One of the maintainers, Magnus Manske, is still active on wikidatawiki, I've pinged them to this report there. — xaosflux 18:19, 17 January 2025 (UTC)

Click the globe icon instead of the coordinates for a map in Katographer for now. — xaosflux 18:15, 17 January 2025 (UTC)

Heading in history view

The following edits and show a different heading (corresponding to the section being edited) in the edit summary than edits (which was made using the convenient discussions tool) and (which was made using the reply tool). When navigating from the history view, clicking on the heading in the edit summary for the first two edits results in a popup saying This topic could not be found. It might have been deleted, moved or renamed. I made my edit using the default wikitext editor. Does anyone know why it would produce an incorrect heading in the edit summary? isaacl (talk) 19:34, 17 January 2025 (UTC)

@Isaacl there are problems in jumping to the correct section when the section heading contains links, either ] or {{ }}. Nthep (talk) 19:39, 17 January 2025 (UTC)

Sure; just wondering why the behaviour is inconsistent with the reply tool and the default wikitext editor (I would have thought the same code would be used to generate the heading for both use cases, but I guess not). isaacl (talk) 19:48, 17 January 2025 (UTC)

@Isaacl: Your post was confusing because your third link was the same as the second and you didn't clarify what was supposed to be different. The wikitext of the actual heading says Dark mode and {{tl|Yes}} which renders as "Dark mode and {{Yes}}" without tl being displayed. Your second link uses the wikitext with tl in the edit summary and fails to link to the section. Your third link should have been where the edit summary uses the rendering without tl and links correctly to the section #Dark mode and {{Yes}}. Different discussion features apparently use different ways to generate the automatic section edit summary and one of them works better in this case. phab:T69068 from 2014 is about the issue. Misplaced Pages:Manual of Style#Section headings (which doesn't apply to project space) says "For technical reasons, section headings should: ... Not contain template transclusions." PrimeHunter (talk) 20:46, 17 January 2025 (UTC)

tracking attributions in material copied from a draft

For better or worse, I copied the contents of a draft article to mainspace. I later added the standard WP:RIA attribution, but since the source is a draft it will go away in six months, so I also included a list of contributors. Is this sufficient? I was unable to find requirements in WP:COPYWITHIN.

The article at issue is Generation Beta / Draft: Generation Beta. Thanks, Dan Bloch (talk) 22:02, 17 January 2025 (UTC)

• Misplaced Pages village pump