Wikipedia:Village pump (technical)

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

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for five days.

view · edit

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

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

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

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

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

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

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

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

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

« Archives, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

Google and Microsoft translators and Wikipedia tools

Hello, I'm from Central Kurdish Wikipedia. Google (Not official yet) and Microsoft have recently added our language to their translators. It's good news for us, but the problem is that some of our users use them without review, and they've created a lot of problems for us. Here, I want to know if there are any tools, gadgets, user scripts, filters or anything else to reveal how much content of an article was taken from those automatic translators? or we appreciate any other idea that makes our work easier. Thanks! ⇒ Aram Talk 19:08, 18 March 2021 (UTC)[reply]

Maybe a warning in the edit window (similar to the one for not copying from random internet sources) could help catch some of them62.98.99.49 (talk) 13:26, 19 March 2021 (UTC)[reply]

Thank you, Do you mean Mediawiki:Editpage-head-copy-warn‏? Any other idea? ⇒ Aram Talk 21:19, 19 March 2021 (UTC)[reply]

Aram, I don't think there is such a tool; I've never seen one mentioned in posts about awkward machine translations. If there were one, it could be helpful here as well as at the Central Kurdish Wikipedia. Perhaps some of the Google Summer of Code people would be interested in the idea. BlackcurrantTea (talk) 01:00, 23 March 2021 (UTC)[reply]

BlackcurrantTea, Thank you for your help! ⇒ Aram Talk 12:18, 24 March 2021 (UTC)[reply]

External links in signatures

Not sure if this is the best place to ask, but is there any way to block blacklisted external links from users' signatures? See this signature from a now-blocked for example. Paul Erik ^{(talk)(contribs)} 18:01, 21 March 2021 (UTC)[reply]

Should keep in mind, that if a user omits their signature, SigmaBot should not be prevented from identifying the user, because the url in a signature is from a forbidden list. I don't know the technical implementations though. Shushugah (talk) 18:41, 21 March 2021 (UTC)[reply]

@Paul Erik: from a non-technical perspective, in general these are disallowed and an editor may be blocked for link spamming (c.f. Wikipedia:Signatures#External_links), as far as other controls sites on the spam blacklist added to signature should get stopped by the blacklist, but the external site in that deleted edit doesn't appear to be on the SBL. — xaosflux ^Talk 13:57, 22 March 2021 (UTC)[reply]

Sorry to BEANs this thread but unless it's been fixed in the last couple of years, there was disruption from someone who found they could insert blocked URLs into pages by putting the URL in their signature then using three tildes. If this is still correct and Too Much Information, please delete my comment. Johnuniq (talk) 22:18, 22 March 2021 (UTC)[reply]

@Johnuniq: I just tried putting a blacklisted link in my signature, and the spam blacklist worked as expected.[1] If you find a way around that, best to file a private phab task, though. :-) Suffusion of Yellow (talk) 20:22, 24 March 2021 (UTC)[reply]

Thanks, it was some years ago that the problem was reported. Johnuniq (talk) 01:27, 25 March 2021 (UTC)[reply]

Incorrect number of pages in category

Tracked in Phabricator
Task T221795
Open

At WP:Good article nominations, the counter of unreviewed nominations at the top of the page is currently about five higher than the actual number. As discussed here, the root of the issue appears to be that Category:Good article nominees awaiting review lists (currently) 327 pages, but claims to have 332—in other words, something appears to be making the category add five pages to its count. Does anyone have any idea what might be causing this? Thanks, --Usernameunique (talk) 04:31, 22 March 2021 (UTC)[reply]

Well, in 2018 the frequency of category counts went down, due to two code changes (phab:rMWde75c4e63bd6aca3baaee57fdf79a757d4c1f622 and phab:rMW9a2ba8e21d820478f96adead39b544d92d1d6306). Wikipedia is after all an big website from an server standpoint. It is not adding any pages to the count, the count is simply outdated. This issue affects categories with more than 100 members, categories with less categorylinks are checked more frequently. The bug is T221795, there is additional info in T18036.--Snaevar (talk) 07:32, 22 March 2021 (UTC)[reply]

The count at WP:Good article nominations is made with {{PAGESINCATEGORY:Good article nominees awaiting review|pages}} which produces 491. {{PAGESINCATEGORY}} gives the number claimed on the category page and not the actual number if there is a difference. There is no way in wikitext to circumvent the bug and get the actual number. We have customized MediaWiki:Category-article-count to say "approximately" for numbers above 200. PrimeHunter (talk) 09:12, 22 March 2021 (UTC)[reply]

The odd thing is that the count seems to consistently be five over the actual number of pages in that category. Every time I've checked over the past several days, the difference is exactly five. In fact, while I was writing this post and rechecking, the count went from 327 to 328 and the actual number of category members went from 322 to 323. I've run into a similar thing in at least one other category as well. If it's going to be a consistent difference, perhaps we could adjust template {{GAN counter}}, to return the actual number by subtracting that five overage produced by {{PAGESINCATEGORY:Good article nominees awaiting review|pages}}. BlueMoonset (talk) 02:02, 23 March 2021 (UTC)[reply]

It's unlikely to remain 5. The count is updated by adding or subtracting 1 when a page is added or removed. The update occasionally fails to happen. Sometimes there is a full recount. PrimeHunter (talk) 10:03, 23 March 2021 (UTC)[reply]

Now both saying 320 — GhostInTheMachine ^{talk to me} 17:52, 23 March 2021 (UTC)[reply]

I'm seeing 318 count and 313 actual pages in the category when I click over to the second display page for the category which has 113 rather than the expected 118. (The first display page has 200.) But it sounds like there's nothing to be done in terms of fixing the count, so I think I'll monitor the situation for a while to see whether this behavior continues. Thanks for the information. BlueMoonset (talk) 00:37, 24 March 2021 (UTC)[reply]

Overview of capabilities and limitations for the mobile editing experience

Simple question really:

Is there a place where every difference to the regular desktop editing environment is listed? Just to take one random example, you cannot Thank using the mobile interface.

I'm talking about articles directed towards the general readership (i.e. wiki pages), not links into the code itself.

CapnZapp (talk) 11:10, 22 March 2021 (UTC)[reply]

For editor centric article, see Wikipedia talk:Editing on mobile devices and Help:Mobile access

As a reader, my biggest missing feature is ability to see Navigation based templates Shushugah (talk) 11:16, 22 March 2021 (UTC)[reply]

I have looked at both those articles (assuming you didn't mean the actual talk page there) but none go into any kind of detail. They seem to be the place where you'd find a detailed summary, but nope. CapnZapp (talk) 13:40, 22 March 2021 (UTC)[reply]

Sans some Phabricator/MediaWiki links (this is after all not exclusively a Wikipedia issue) the above two places would be good place to add Known limitations or something to that effect. The increased attention on mobile can only be a positive thing for the global movement Shushugah (talk) 13:44, 22 March 2021 (UTC)[reply]

@CapnZapp: I don't think there is a single page but if there is it isn't likely to be specific to the English Wikipedia. Also there are multiple "mobile" interfaces (Mobile Frontend, Mobile Apps). You can try following up at mw:Talk:Reading/Web/Mobile. — xaosflux ^Talk 13:47, 22 March 2021 (UTC)[reply]

There is a related table at User:Suffusion of Yellow/Mobile communication bugs. – Jonesey95 (talk) 14:51, 22 March 2021 (UTC)[reply]

Thanks. That table doesn't contain the Thanks notifications, so it's probably not even close to complete. CapnZapp (talk) 16:46, 22 March 2021 (UTC)[reply]

While I'm slightly surprised we aren't telling our readers what to expect - other than a general and vague "don't expect everything to work on mobile" - and think that what might have been acceptable ten years ago when mobile editing was a curiosity, no longer is when mobile editing is the standard... (far too many of the discussed pages still come off as talking to the "adventurous few" rather than presenting what billions of people today simply assume is the default)... I'm personally good with an answer of "no, there isn't".— Preceding unsigned comment added by CapnZapp (talk • contribs) 16:47, 22 March 2021 (UTC)[reply]

The mobile interface is limited compared to the desktop one. So, I suppose on the list of missing items for readers about Wikipedia are search, media support (I recently added info on this just now on Help:Mobile access), navigation, Special:Nearby and maybe wikimedia commons.--Snaevar (talk) 17:21, 22 March 2021 (UTC)[reply]

To complicate further, there are 4 skins of mobile. The default does include WP:Nearby but skips other features. And SOY's table is specifically about messaging users so I wouldn't call it "not even close to complete", just lacks information of other features because it's not intended to be a general comparison table. Slywriter (talk) 01:26, 23 March 2021 (UTC)[reply]

Of course, it isn't really complicated. I mean, if we really prioritized the mobile experience we would make this easy. Instead of today's situation, where it's apparently deemed a good UI to feature several skins, each with its own set of limitations, and essentially no non-technical documentation. But I'm a desktop user, so I don't care. CapnZapp (talk) 14:30, 23 March 2021 (UTC)[reply]

Can anyone find out what is going on?

WP:REFLINKS has been down for three days now. Usually routine maintenance takes less time than that. If anyone can find out what is up with the tool that would be helpful. Formatting bare urls becomes laborious without it so any help will be appreciated. MarnetteD|Talk 17:44, 22 March 2021 (UTC)[reply]

@MarnetteD: that external utility is not maintained by the community here, you can try leaving a message at: User_talk:Dispenser/Reflinks. — xaosflux ^Talk 18:28, 22 March 2021 (UTC)[reply]

Thanks Xaosflux. I was (sorta) aware that it was being overseen somewhere else but I appreciate you confirming that. MarnetteD|Talk 20:16, 22 March 2021 (UTC)[reply]

@MarnetteD: you could try the similar script, User:Zhaofeng Li/reFill. — xaosflux ^Talk 21:42, 22 March 2021 (UTC)[reply]

Thanks for the suggestion Xaosflux. I use it extensively - in fact I usually have one window with refill2, one with reflinks and one with citer when I'm working on those pesky bare urls. reflinks big plus is that it formats many PDFs which refill2 can't handle so when it is down those have to be done manually which slows everything down. An hour ago refill2 went down as well :-( Hopefully they are both being worked on. If not I'll be finding new wikignome tasks. Cheers. MarnetteD|Talk 22:42, 22 March 2021 (UTC)[reply]

ReFill down again?

Tracked in Phabricator
Task T278211

Not working for me today? Giant Snowman 12:16, 23 March 2021 (UTC)[reply]

@GiantSnowman: It's been down for me since yesterday sometime. --Ser Amantio di Nicolao^{Che dicono a Signa?}_{Lo dicono a Signa.} 22:01, 23 March 2021 (UTC)[reply]

I contacted Dispenser on freenode and they say they'll look into the outage tonight. – Muboshgu (talk) 19:09, 25 March 2021 (UTC)[reply]

@Muboshgu: Excellent - thanks for that. Hopefully this can be resolved soon. --Ser Amantio di Nicolao^{Che dicono a Signa?}_{Lo dicono a Signa.} 03:26, 26 March 2021 (UTC)[reply]

There is an update from Keith D here User talk:Zhaofeng Li/reFill#Help help help... that everyone should be aware of. MarnetteD|Talk 03:42, 26 March 2021 (UTC)[reply]

ReFill is working, just not when asking it to process an article on the English wikipedia. Is there something that may have changed on the English wikipedia in the last week that is causing the code to struggle to process the markup that it is ingesting? If I run the following cURL commands, the first (specifying the version of the Microsoft article on the German language wikipedia works as intended, but the second command to do the same on the English language wikipedia does not.

curl "https://refill.toolforge.org/result.php" -H "authority: refill.toolforge.org" --data-raw "page=Microsoft&wiki=de&method-wiki=Fix+page&noaccessdate=on"

curl "https://refill.toolforge.org/result.php" -H "authority: refill.toolforge.org" --data-raw "page=Microsoft&wiki=en&method-wiki=Fix+page&noaccessdate=on"

Curb Safe Charmer (talk) 17:35, 26 March 2021 (UTC)[reply]

Per this thread, the same appears to be true for Citoid; it's not working in English, but it is for other languages. (I can attest that it did not work for me in English earlier today.) --Ser Amantio di Nicolao^{Che dicono a Signa?}_{Lo dicono a Signa.} 18:20, 26 March 2021 (UTC)[reply]

Does it matter if http URLs that are unlikely to be the target of computer security attacks are used as references instead of the https equivalent?

What if the http URL redirects to https anyway in a fraction of a second? Sagittarian Milky Way (talk) 00:52, 23 March 2021 (UTC)[reply]

Yes, it still matters. Izno (talk) 01:17, 23 March 2021 (UTC)[reply]

So if I can make an article go under 100 kilobytes by doing find-and-replace on https://www.sitesoandso.com I shouldn't cause something bad might happen? (replace with http://www.sitesoandso.com) Sagittarian Milky Way (talk) 19:03, 23 March 2021 (UTC)[reply]

You asked if it matters and Izno said yes, it matters. Don't change https to http if https works. Even if the target size is completely safe and harmless, https gives more privacy and security against eavesdroppers on the connection. Wikipedia:External links#Specifying protocols says https is preferred. Saving one byte in the wikitext would be a really dumb reason for changing to http. PrimeHunter (talk) 19:26, 23 March 2021 (UTC)[reply]

Well it could be hundreds of bytes at 1 byte each but okay not worth it. Sagittarian Milky Way (talk) 20:01, 23 March 2021 (UTC)[reply]

The size of the link's expansion into HTML is many times larger weight than the character you add at the end of the day in the wikitext, never mind the page size associated with images. Do not worry about it. Text is cheap. Izno (talk) 00:41, 24 March 2021 (UTC)[reply]

(I wasn't being sarcastic BTW, PrimeHunter had already convinced me) Sagittarian Milky Way (talk) 01:35, 24 March 2021 (UTC)[reply]

I did not think you were being sarcastic, just reinforcing an unstated point. Izno (talk) 02:20, 24 March 2021 (UTC)[reply]

I thought you probably didn't misinterpret but wasn't certain. Sagittarian Milky Way (talk) 02:47, 24 March 2021 (UTC)[reply]

What does it mean when a table column font has an unwanted enbiggenment not commanded by wikitext?

The rightmost table column has text the size of the article, the other table text is smaller (but still easily readable in landscape on my c. half megapixel screen, and given the great length of this table the small font is probably preferable since this shortish note alone embiggens this row's height by almost 3 times (the average photo height would otherwise set the typical row height and it is only ~1/e^th this note)

This also happens to links sometimes and if you touch one it will shrink to normal size and the entire page will suddenly rearrange to what it would look like if the link you touched was the right form factor in the first place. This will often result in clicking an unwanted link which has now squirmed to under your finger. Sagittarian Milky Way (talk) 01:10, 23 March 2021 (UTC)[reply]

Please post an example. What is your browser/device and skin at Special:Preferences#mw-prefsection-rendering? PrimeHunter (talk) 09:52, 23 March 2021 (UTC)[reply]

For example Help:Table#Using_the_toolbar has right column text about twice the size of the other two but the producing wikicode is identical and identically sized. On Chrome browser, Android smartphone, MonoBook skin, wikipedia not m.wikipedia, desktop site checkbox on Chrome. It doesn't happen all the time though. An example for links is List of Mars-crossing minor planets, the sea of links are the same form factor as the lead text but when I touch or long press the links they sometimes shrink and rearrange the page to what it would've been if the ones I had shrunk and only those had never been big. They do not stay shrunk when clicking a link and immediately navigating back. One of the times I viewed the asteroid page today some of the links were already small before I touched anything, a column or two of a section but not the other column(s). Sagittarian Milky Way (talk) 15:47, 23 March 2021 (UTC)[reply]

I don't see any size difference or page change in Google Chrome 89.0.4389.90 on Windows 10 or iOS 14.4 on an iPhone. I don't have an Android device. PrimeHunter (talk) 19:14, 23 March 2021 (UTC)[reply]

@Sagittarian Milky Way: I don't either. Unless somebody else is able to reproduce this, I think that we are going to need a WP:WPSHOT. --Redrose64 🌹 (talk) 20:12, 23 March 2021 (UTC)[reply]

Done. Sagittarian Milky Way (talk) 21:29, 23 March 2021 (UTC)[reply]

It's your browser which does that and not Wikipedia. I don't know why it does it. PrimeHunter (talk) 23:34, 23 March 2021 (UTC)[reply]

There is no such word as "enbiggenment". Embiggen, however, is a perfectly cromulent word. --Redrose64 🌹 (talk) 10:20, 23 March 2021 (UTC)[reply]

Are you sure you don't mean unwanted embuggerance? Martinevans123 (talk) 10:29, 23 March 2021 (UTC)[reply]

I thought it should be embiggenisation? — GhostInTheMachine ^{talk to me} 17:56, 23 March 2021 (UTC)[reply]

Please provide the version numbers of your device and browser software. While I agree it is probably the browser's fault, it may also be related to the age of your device (I vaguely recall similar behavior a long long time ago). Izno (talk) 00:40, 24 March 2021 (UTC)[reply]

Chrome 89.0.4389.105. I don't know when my smartphone was designed but I bought it new less than a year ago and the battery still works great after thousands of hours of screen on which is a sign of youth, it's just very low-end (at least by recent name-brand standards). When links are in certain configurations like in prose or section hatnotes they seem to shrink never or maybe rarely while most loadings of pages with lists of links have shrinkage and the links after the touched one always move to fill the extra space, they never just stay where they were. Sagittarian Milky Way (talk) 02:41, 24 March 2021 (UTC)[reply]

This is built in functionality of mobile devices to make text more readable when you are using desktop websites. It is called "text size inflation" where it makes the font size of larger blocks of text as well as headers and links bigger based on the idea that it is more likely you will want to read them or touch them (links). Visited links have already been read, so it is unlikely you need to go there again and they are smaller. You shouldn't have this problem if you use the mobile site of Wikipedia. —TheDJ (talk • contribs) 10:37, 24 March 2021 (UTC)[reply]

I wish already visited links stayed shrunk for more than 0 seconds, if it was 30 minutes I wouldn't care. But it's good to learn that if I make a long article even a half megapixel desktop monitor would probably cause less scrolling. Sagittarian Milky Way (talk) 13:50, 24 March 2021 (UTC)[reply]

Can't edit Rudy Rochman by section

I can only edit this article as a whole - is this something to do with the ARBPIA edit notice I just added? Doug Weller talk 13:26, 23 March 2021 (UTC)[reply]

No, there was a __NOEDITSECTION__. I have removed it. PrimeHunter (talk) 13:42, 23 March 2021 (UTC)[reply]

It's usually added in VisualEditor by what-does-this-button-do users. A search [2] currently finds 52 in mainspace. It's never appropriate except on Main Page. There are probably editors clearing them periodically. PrimeHunter (talk) 13:56, 23 March 2021 (UTC)[reply]

@PrimeHunter: thanks. I've never run into that before. Doug Weller talk 19:53, 23 March 2021 (UTC)[reply]

I cleaned up a bunch of these round about the end of December. Many of the affected pages also had other inappropriate magic words, such as __DISAMBIG__ which VE also allows indiscriminate and inappropriate use of. --Redrose64 🌹 (talk) 20:26, 23 March 2021 (UTC)[reply]

Based on phab:T118796 and phab:T100691 it seems this issue will not be fixed in VisualEditor. We can hide these options from the Page Settings panel using sitewide CSS pretty easily though, and do so only for the mainspace. @PrimeHunter, Doug Weller, and Redrose64: Thoughts? Frankly I think everything but the "Redirect this page to" should be hidden. — MusikAnimal ^talk 19:43, 24 March 2021 (UTC)[reply]

I'd certainly support that. Doug Weller talk 20:05, 24 March 2021 (UTC)[reply]

I am not a fan of using CSS for VE making it too easy to access these. I'd prefer to see an edit filter on the point. Izno (talk) 20:22, 24 March 2021 (UTC)[reply]

I thought of that, but an edit filter adds an unnecessary expense (albeit tiny), and since this issue is mostly with new users, they may not be able to make sense of what they did wrong or even know how to get back to the Page Settings panel to fix it. They might instead abandon their edit. A configuration flag in VisualEditor would be most optimal but as I said it seems maintainers are adverse to doing that for whatever reason. — MusikAnimal ^talk 20:44, 24 March 2021 (UTC)[reply]

@MusikAnimal: Wait, we can hide these options now? Years ago there was a discussion about hiding the option to add __INDEX__ (which trips 930 (hist · log)), but no one could find a way, because OOUI.

Odd. There's a ve-test-page-settings-noeditsection class for the __NOEDITSECTION__ option, but I can't finding anything unique for __INDEX__. Suffusion of Yellow (talk) 21:13, 24 March 2021 (UTC)[reply]

Correct, unlike the other options discussed here, the option to add __INDEX__ does not appear to have a unique CSS class (though a patch to add one I'm sure would be merged). So we can't use CSS for that, but I think disallowing __INDEX__ in the userspace warrants a filter anyway because that can be abused (promo-only accounts, etc.), be it with VisualEditor or not. The other magic words we're discussing aren't ever abuse, just newbies clicking buttons. — MusikAnimal ^talk 21:18, 24 March 2021 (UTC)[reply]

They're both a cost. We can add 3 lines of CSS or we can prevent the edit. I'm just generally going to side on the prevent or warn on edit instead. :/ Izno (talk) 21:20, 24 March 2021 (UTC)[reply]

The CSS option seems less BITEy though. I'd only support a filter if vandals were using the wikitext editor to intentionally do this. Suffusion of Yellow (talk) 21:39, 24 March 2021 (UTC)[reply]

The cost of both I think is pretty trivial. You could argue the CSS is a hacky solution, but it's effective. The point is these options shouldn't be available to editors in the mainspace to begin with, hence why hiding them seems ideal to me. I'm okay with also having a filter too, if we want. While in this case I don't think we're dealing with vandals or bad intended editors, a vandal certainly could abuse these magic words (using VE or otherwise). In the case of Rudy Rochman, the editor apparently intentionally added __NOEDITSECTION__. While it wasn't quite vandalism, it suggests the editor would have manually added magic word via wikitext editing if they knew how. — MusikAnimal ^talk 22:20, 24 March 2021 (UTC)[reply]

Youtube citations not being created very well

Hi all

When I make a citation from a YouTube video using the VE citation tool e.g from a news organisation's channel its not providing very much information, only the name of the video and a link, and doesn't provide additional information which available e.g channel its from, publication date etc. One other idea (although I'm not sure how it could be done would be allowing users to easily add a start and end time for the citation, which would be very helpful in citing information from longer videos eg documentaries. Is there a place on phabricator etc I could make those requests?

Thanks

John Cummings (talk) 22:19, 23 March 2021 (UTC)[reply]

You can request a change to the information returned in the Citoid project. You will probably not get a start/end time, but channel and date are very possible. Izno (talk) 00:37, 24 March 2021 (UTC)[reply]

The development process for Visual Editor did not pay much attention to the need for references, and as referencing ability has been added in it can be confusing. Using Cite is not the only way. Any template which has Wikipedia:TemplateData can be added with Insert Template. Most of the citation templates do and Template:Cite AV media might give you what you need. StarryGrandma (talk) 00:53, 24 March 2021 (UTC)[reply]

thanks very much StarryGrandma and Izno, I created a task here, I hope its clear. John Cummings (talk) 01:11, 24 March 2021 (UTC)[reply]

Citoid uses Zotero for citation lookup and in Zotero there are translators for some websites. One of the websites with translators is youtube, it is configured to get title, url, duration, date, author and description. This is mostly an upstream issue, Zotero does for the most part get the same result as Citoid, but Citoid for some reason skips the website name. For duration and description there is a double issue, because even if Zotero would pick that up, the TemplateData Citoid mapping (in Template:Citation) is not configured for these fields, i.e. it would not know in what parameter that should go.

Johns Cummings bug report could be better, please read mw:How to report a bug. Typically bugs that are explained properly get attention sooner.--Snaevar (talk) 07:36, 24 March 2021 (UTC)[reply]

Snaevar thanks very much for the explanation and your comment on the phabricator task. John Cummings (talk) 09:55, 24 March 2021 (UTC)[reply]

Masking infobox coordinates from appearing inline

After a recent expansion and GA review of Martensdale, California, an infobox has been added to that article. Trick is, coordinates are needed to pull up a map. Exact coordinates for the site are not known, but the GA reviewer was able to pull up some coordinates that are so close it would have no visible effect on the pushpin map output. But it's still not best to pass off slightly inexact coordinates as exact ones. I thought I knew a method to pull this off, but after further looking around, it doesn't work like I thought it did. And looking at the documentation for Template:Coord (which is pulled by Template:Infobox settlement), there doesn't seem to be a way to not display the coordinates. Does anyone know of a workaround for here? Hog Farm _Talk 05:42, 24 March 2021 (UTC)[reply]

Adding display=no does stop the coordinates being displayed, but you do not get the map either

— GhostInTheMachine ^{talk to me} 14:09, 24 March 2021 (UTC)[reply]

Wrap in a span: <span style="display:none;">{{coord|35.49976|-119.16361|type:city}}</span> -- WOSlinker (talk) 14:13, 24 March 2021 (UTC)[reply]

This should be avoided; it makes the coordinates (such as they are in this situation) generally inaccessible.

I prefer Jonesey's take on it, or a footnote to the same effect as his suggested change. Izno (talk) 20:25, 24 March 2021 (UTC)[reply]

Help me coding for collapsible CS1 error & maintenance messages

I want to make CS1 error messages collapsible to make them less annoying. On this case, I want to show a small clickable icon (i.e. exclamation mark) on a citation to show / hide an error & maintenance messages by modifying the code from Help:CS1 errors#Controlling error message display. How should I code it?

I actually posted the same question on WP:VPI twice, but I didn't get the ideal answer. --Ijoe2003 (talk) 07:06, 24 March 2021 (UTC)[reply]

It is worthtless. If I am looking for problems to correct them I want to see them all. Otherwise I want to hide them all. So global option in private CSS is enough for me. However, there is build-in mechanism to make collapsible elements in mediawiki described in mw:Manual:Collapsible elements. So if you want this feature optional you have to write a gadget. The manual page consists of some source code, which might be adjusted for your needs. Paweł Ziemian (talk) 08:54, 24 March 2021 (UTC)[reply]

This might be possible in CSS exclusively but it probably ends up a bit hacky. Izno (talk) 16:11, 24 March 2021 (UTC)[reply]

Help with an EasyTimeline syntax issue

I left a message at Help talk:EasyTimeline syntax a few weeks ago, and have heard nothing. I just want to know how to plot a single split-color line for Edward D. White at Demographics of the Supreme Court of the United States‎#Catholic justices. Cheers! BD2412 T 17:01, 25 March 2021 (UTC)[reply]

Done in Special:Diff/1014206826. Note that you only actually need to give names to the split bar and every bar above it in the timeline, but I went ahead and gave names to every bar for consistency. * Pppery * _{it has begun...} 19:37, 25 March 2021 (UTC)[reply]

Thanks. I wish there was a somewhat more intuitive timeline builder. Ideally, we should have a tool where the editor can sketch out the bar inputs and it will spit out the syntax. BD2412 T

Linking to template result

Is there a way to link (either wikilink or URL) to a template, including parameters, so that clicking on the link produces a page consisting only of the result of the template call?

The closest thing I could come up with is, using a simplified example, [https://en.wikipedia.org/wiki/Special:ExpandTemplates?wpInput={{URLencode:{{Convert{{!}}2{{!}}mi}}}} link] which produces a link that shows the desired result as a "Preview", below lots of undesired stuff.

As a potential solution, is there any way for a page to access a query string appended to its URL, or the section specified by #Section? MANdARAX • XAЯAbИAM 20:13, 25 March 2021 (UTC)[reply]

You can find answer here. Ruslik_Zero 20:52, 25 March 2021 (UTC)[reply]

This CSS would hide everything above the preview in your link:

h2, #output, .mw-htmlform-ooui-wrapper, .firstHeading  {
  display:none;
}

If an interface administrator created a MediaWiki CSS page with it like MediaWiki:ExpandTemplatesPreview.css then your link plus withCSS=MediaWiki:ExpandTemplatesPreview.css would display the preview alone. PrimeHunter (talk) 21:19, 25 March 2021 (UTC)[reply]

Perfect! I tested it with my own CSS and it's exactly what I wanted. Thank you so much!

I'll probably submit a request tomorrow to create the CSS page described above, unless an interface administrator happens to see this here and takes care of it before then. MANdARAX • XAЯAbИAM 00:13, 26 March 2021 (UTC)[reply]

I'm not aware of MediaWiki pages made solely for withCSS or withJS. There are other possible uses like this to only display the page names in search results:

.searchresult, .mw-search-result-data {
  display:none;
}

If we make such pages then maybe they should have systematic names with a certain prefix. PrimeHunter (talk) 01:06, 26 March 2021 (UTC)[reply]

Such pages already exist, and the convention seems to be no prefix. MediaWiki:ExcerptTree.js, MediaWiki:G13-restore-wizard.js, and MediaWiki:FileUploadWizard.js are three examples I could remember off the top of my head, although there are probably more. * Pppery * _{it has begun...} 01:09, 26 March 2021 (UTC)[reply]

The page was created as MediaWiki:HidefirstHeading.css, and it works. Thanks again! MANdARAX • XAЯAbИAM 22:15, 28 March 2021 (UTC)[reply]

How do I print/save a wikipedia article without the brackets/numbers that are interspersed throughout the article?

I am trying to make a long post on reddit that includes me copy/pasting about 40 paragraphs of text from wikpiedia but all the text I grab includes numbers like this[1] and this[2]. Is there a fast way to remove the numbers with brackets around them? Also what are the bracketed numbers formally called? 2600:1006:B054:DE27:9042:63B0:7DA9:3E23 (talk) 02:10, 26 March 2021 (UTC)[reply]

They are called footnote markers or reference markers. Clicking them leads to a footnote or reference. Displaying the page with the added CSS .reference{display:none} will hide them. Your browser may have a way to do that. PrimeHunter (talk) 10:02, 26 March 2021 (UTC)[reply]

And when you ask a question only post it in one place. Also posted at Helpdesk. - X201 (talk) 10:35, 26 March 2021 (UTC)[reply]

Scripts use via meta have just stopped working

Two user-scripts that I invoke via on meta:User:Pigsonthewing/global.js have stopped working (but were working eysterday). That page has not been changed, and I have restarted my machine to no effect.

Is anyone else seeing this issue? Does anyone know why its happening? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:43, 26 March 2021 (UTC)[reply]

I tried the first script, and it's displaying the wikidata description under the article title for me. I checked with Firefox 87.0 on Linux and Chrome on my Android phone. William Avery (talk) 14:00, 26 March 2021 (UTC)[reply]

Does it work at other wikis, e.g. simple:Example? PrimeHunter (talk) 14:08, 26 March 2021 (UTC)[reply]

Yes; both working on Wikispecies; and on en.Wikisource. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:48, 26 March 2021 (UTC)[reply]

...and both now seem to be working again here. Very odd. Thanks for your assistance. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:50, 26 March 2021 (UTC)[reply]

Such periodic errors are often caused by random changes in loading order between scripts. You import a bunch in User:Pigsonthewing/common.js, and more in User:Pigsonthewing/monobook.js if your skin is MonoBook. PrimeHunter (talk) 18:05, 26 March 2021 (UTC)[reply]

@Pigsonthewing: if you are using "strict mode" privacy settings in your browser you may run in to certain issues as well (that could be failing without a way to give you the error directly). You could try setting meta as "allowed" in such privacy settings. — xaosflux ^Talk 19:34, 26 March 2021 (UTC)[reply]

List of Stuff You Should Know episodes

Five years ago there was an issue at List of Stuff You Should Know episodes where having too many templates was preventing the references from showing. Fred Gandt came to the rescue and split the article into multiple lists. That worked for a time, until Teafed recently updated the article. Now the original problem is back, and no references are being displayed. Can anyone help? --Slugger O'Toole (talk) 14:07, 26 March 2021 (UTC)[reply]

It transcludes around 1300 {{Cite web}} from the season pages. That's a large part of the reason for breaking the template limit. The list only shows episode number, title, length, air date. I think it can do without the references (most of them don't work anyway) when they are on the linked season pages. If they are placed in <noinclude>...</noinclude> on the season pages then they will only display there. Then the "Further information" links would also actually show further information. They haven't really done that since episode summaries were removed from the season pages as copyright violations. PrimeHunter (talk) 14:51, 26 March 2021 (UTC)[reply]

For now, I have commented out transclusion of the first 9 years to remove the page from Category:Pages where template include size is exceeded.[3] 8 wasn't enough. PrimeHunter (talk) 17:14, 26 March 2021 (UTC)[reply]

PrimeHunter, thank you. When you say "for now," does that mean you have a more permanent solution coming? Because as it stands now you just removed some information so that others might be displayed. -- Slugger O'Toole (talk) 17:46, 26 March 2021 (UTC)[reply]

The page was broken before. It isn't now. All the information can still be found by clicking the "Main article" links. I already suggested another solution: Don't transclude the references. I haven't tested whether it's enough to get below the limit and it requires more work to implement so I made a quick fix for now, so we don't show a broken page to readers and others get a chance to chime in. If there aren't objections then I may try the suggestion in a couple of days. You and others are of course also free to do something. PrimeHunter (talk) 18:01, 26 March 2021 (UTC)[reply]

PrimeHunter, I don't know how to do that, which is why I posted here. I do appreciate your help, though. -- Slugger O'Toole (talk) 18:57, 26 March 2021 (UTC)[reply]

Another option would be to show the 1300 references as raw url's on the long list and only do the expensive cite web formatting on the season pages. This could be done by inserting two <noinclude>...</noinclude> like this:

<noinclude>{{cite web|url = </noinclude>https://www.iheart.com/podcast/105-stuff-you-should-know-26940277/episode/how-safecracking-works-54991133/<noinclude> | title = How Safecracking Works | publisher = iHeartRadio | accessdate = March 25, 2021 | date = January 2, 2020}}</noinclude>

List of Stuff You Should Know episodes#References could mention it so readers know where to find the full references: "The references are only displayed as url's due to a technical limitation. They are shown with formatting on the yearly pages." PrimeHunter (talk) 19:48, 26 March 2021 (UTC)[reply]

The fundamental solution is not to transclude season pages into a single article. That practice causes this issue and the issue will not go away any other way. Izno (talk) 21:29, 26 March 2021 (UTC)[reply]

It's a common accepted practice. It uses {{Episode list/sublist}} which is designed for it: Template:Episode list/sublist#Transclusion of the list on another page. The idea is for the season article to have more details and the list to only display a one-line row per episode. In this case the season articles started out with more details in episode summaries but they were removed as copyvios. Season articles can also have general information about the show and season but they don't here. See List of 24 episodes#Season 1 (2001–02) versus 24 (season 1) for an example. PrimeHunter (talk) 22:49, 26 March 2021 (UTC)[reply]

Whether it is common and accepted and whether it can be fixed by anything other than hacks and workarounds are mutually exclusive considerations. Izno (talk) 23:00, 26 March 2021 (UTC)[reply]

"Pending changes" yet again

Following on from the discussion at Wikipedia:Village pump (technical)/Archive 188#Pending Changes again, it looks like I'm getting the "pending changes" error yet again, as can be seen from recent edits here. Why does this error keep coming back? Maestro2016 (talk)

Ultimately because the underlying bug hasn't been fixed yet, and while FlaggedRevs doesn't have an "owner" on the dev team it's unlikely to get fixed any time soon! ƒirefly ( t · c ) 19:01, 27 March 2021 (UTC)[reply]

Image alt parameters

I've been adding image alt text occasionally and noticed that when I mouse-hover over an infobox image, the alt text is revealled as an overlay; when the image is in the article body no such annotation occurs. Recent examples of non-infobox articles are at History of the Jews in Hull and Matlock Bridge being building and bridge descriptions repectively. A recent example of infoboxed is at Bart Simpson which shows the text overlay on Bart's caricature-illustration.

Could someone please confirm if this (non-appearance) is the 'norm' and known, and preferably check with a screen-reader? For my own peace of mind. I'm using only IBM and almost-exclusively with Firefox 87.0. Thanks.--Rocknrollmancer (talk) 15:01, 27 March 2021 (UTC)[reply]

@Rocknrollmancer: We've recently lost our Grade A1 alt-text expert, so I'll try to answer. The alt text is present on the images at History of the Jews in Hull, Matlock Bridge and Bart Simpson, you can check this using your browser's "Inspect element" or "View source" features; it's the alt="..." attribute of the <img /> tag. In the case of Bart Simpson (but neither of the others), the alt text is copied to the title="..." attribute of the enclosing <a>...</a> element, and it is that title that some browsers are displaying as a tooltip.

The purpose of alt text is not to provide a tooltip (although some browsers do that) - it's to provide replacement text for use when images are not available, or, more fully, The image given by the src and srcset attributes, ... is the embedded content; the value of the alt attribute is the img element’s fallback content, and provides equivalent content for users and user agents who cannot process images or have image loading disabled. (see HTML 5.1 spec). So when the image can be displayed, the alt text need not be rendered; but if the image can't be displayed - such as if the upload.wikimedia.org server is flaky - you instead get a rectangle of the appropriate size, but instead of the image it contains text such as "Close up of natural stone arched bridge and tapered piers over river on a sunny day with blue sky". --Redrose64 🌹 (talk) 17:04, 27 March 2021 (UTC)[reply]

@Rocknrollmancer, the infobox is using the module Module:InfoboxImage to display the image. If a title parameter is not passed to the module, the alt parameter is used as the title. – BrandonXLF (talk) 18:50, 27 March 2021 (UTC)[reply]

ThanQ Redrose64, BrandonXLF - I'm beginning to understand, I've been out for a few hours and realised when away from the keyboard that I'd not described adequately-enough the query. What I was needing to know was - for visually-impaired, is the alt text converted to a voice announcement? Or just the main caption? I know of a young lady who's lost her previous partial-sight totally about two years ago and is using Voice Over for iOS (?) on iphone, that's from memory as I'm unfamiliar with whatever that is (or if there's an equivalent on Android app or plug-in). Checking, she's taken it off her social media profile now, but the previous annotation stated not to send her images without a caption. That was the main gist of the enquiry, and I probably mis-stated when using the term screen reader. Hope that's clear-enough!--Rocknrollmancer (talk) 21:20, 27 March 2021 (UTC)[reply]

@Rocknrollmancer: Oh I see now. If someone is using a screen reader, the alt attribute of the image is always read, even if there's a caption. – BrandonXLF (talk) 22:12, 27 March 2021 (UTC)[reply]

Yes, this is why WP:ALT#Basics says The alt text is intended to be read out by screen readers just before the caption, so avoid having the same details in both. --Redrose64 🌹 (talk) 22:58, 27 March 2021 (UTC)[reply]

Good-O, pleased to have that clarified - it's been a long time since I looked; think it was when I tried to flush-right a TOC and it was reverted as potentially causing problems, but I couldn't quite remember on what device(s) were mentioned and how the hard/software may have developed since. Thanks for all your comments.--Rocknrollmancer (talk) 00:12, 28 March 2021 (UTC)[reply]

Indeed re alt text. VoiceOver is Apple's screen reader; for whatever it's worth Google TalkBack is the Android equivalent. It's not necessarily moving the table of contents to the right that causes problems for screen reader users like me; it's changing its position in the wiki-markup. Graham87 06:58, 28 March 2021 (UTC)[reply]

Find and replace

On Fandom, the editing window has a find and replace function. How can I get this on Wikipedia's editing window?--Laun chba ller 18:47, 27 March 2021 (UTC)[reply]

Launchballer, if you have the editing toolbar enabled, click Advanced. The search-and-replace function is the magnifying glass icon on the far right. Schazjmd (talk) 18:57, 27 March 2021 (UTC)[reply]

@Launchballer: If you want an editor like the source editor used at Fandom (at least from what I can tell), you can turn on the "New wikitext mode" beta feature. – BrandonXLF (talk) 19:02, 27 March 2021 (UTC)[reply]

I've enabled New wikitext mode. It's not quite right - I'm used to having 'Save' at the bottom and being able to enter my edit summary before I click Save - but this is better. Thank you.--Laun chba ller 20:29, 27 March 2021 (UTC)[reply]

Histmerge

Please histmerge Lowercase sigmabot III's archive mess at the Teahouse. 🐔 Chicdat ^{Bawk to me!} 10:32, 28 March 2021 (UTC)[reply]

@Chicdat: Please say what you refer to when you request help. I guess you mean the creation of many small archives after the bad maxarchivesize = 1B (meaning 1 byte)? I see nothing to histmerge there but I will clean it up. PrimeHunter (talk) 11:32, 28 March 2021 (UTC)[reply]

Thank you. 🐔 Chicdat ^{Bawk to me!} 11:33, 28 March 2021 (UTC)[reply]

Done. I copied all the small archives to Wikipedia:Teahouse/Questions/Archive 1102 and deleted them. PrimeHunter (talk) 11:51, 28 March 2021 (UTC)[reply]

Monitoring / alerting platform for tools?

We've lots tons of bots and tools that we depend on for the smooth running of enwiki. It's always surprised me that we don't have any standardized logging, monitoring, and reporting system for them. WMF has such systems for their internal use based on the common Graphite and Icinga packages, but they're not available for user-maintained tools, which means we tend to rely on somebody noticing and posting a "Hey, I haven't seen any XXX updates in a while, is it down?" query. So, a few questions:

Am I correct that no such facility exists for user-maintained tools?
Assuming I am, what do we want to do about it? The likely alternatives are:
1. Pester WMF to make such a facility available.
2. Stand one up ourselves.
3. Just keep stumbling along in the dark.

Comments? -- RoySmith (talk) 18:27, 28 March 2021 (UTC)[reply]

The tools that Community Tech has worked on are monitored on [4]. Restarts of tools are logged in the Nova resource namespace on wikitech.wikimedia.org and on [5]. Job run log is on sge-jobs.toolforge.org, example. It is also a good idea to follow Incident status on wikitech. Admittedly, other than that, I do not know much.--Snaevar (talk) 18:55, 28 March 2021 (UTC)[reply]

Watchlist changes

Has anyone noticed their watchlist changing in the past several hours? Mine used to look like File:Wikipedia watchlist.png, but now it's formatted like
* 20:50 Wikipedia:Administrators' noticeboard/Incidents‎ (diff|hist) . . +367‎ . . Tenryuu talk contribs →‎User:Marveldc111: Closing discussion (DiscussionCloser v.1.7.3)
That doesn't quite do it justice, as there's a massive gap between the first dot and the time. I checked in both Chrome and Firefox on a PC so I don't think it's on my end, but I figured I'd ask before seeing how to report a bug like this. Woodroar (talk) 21:17, 28 March 2021 (UTC)[reply]

Woodroar, that looks similar to how the watchlist looks when "Group results by page" is enabled. If you click on the dropdown with the label "x changes, x days" try to uncheck "Group results by page" if it's checked. – BrandonXLF (talk) 21:41, 28 March 2021 (UTC)[reply]

You can also go to Special:Preferences#mw-prefsection-rc and uncheck "Group changes by page in recent changes and watchlist" if you're using the non-JavaScript interface.– BrandonXLF (talk) 21:58, 28 March 2021 (UTC)[reply]

BrandonXLF, I was just going to reply that I found it in the Preferences. I wonder how it got enabled because I certainly haven't been messing around in there?! Anyways, thank you very much! Woodroar (talk) 22:01, 28 March 2021 (UTC)[reply]