Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

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

If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for five days.

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

Re: Pushpin map of the world's FAs (discussion from March)

Hello, a little update to everyone involved in the discussion "Pushpin map of the world's FAs" from March, @Sdkb, Jéské Couriano, Pppery, The wub, Donald Albury, NguoiDungKhongDinhDanh, TheDJ, Agathoclea, Whatamidoing (WMF)):

As of yesterday, it is possible to use geopoints from Wikidata in Kartographer maps, via QID or SPARQL query. -- Best, Johanna Strodt (WMDE) (talk) 10:09, 27 September 2022 (UTC)

How cool, thanks very much Johanna! And please pass on my thanks to those who worked on this improvement, I'm sure it will be useful for a lot of other applications. Only just saw this as I didn't get a notification about your message for some reason. I had a go at making a map for the featured articles, pinging Sdkb as the person who originally requested it. the wub "?!" 23:25, 2 October 2022 (UTC)

Amazing; thanks so much! I'm going to go ahead and add it to WP:FA. A future improvement might be to color-code the icons by type. {{u|Sdkb}} ^talk 22:38, 3 October 2022 (UTC)

Thanks for your replies. I've passed the feedback on to our team. -- Best, Johanna Strodt (WMDE) (talk) 08:41, 4 October 2022 (UTC)

Can i just confirm whether this works for all planets/moons (eg the cyclonia (location of the Mask on Mars. Also I saw a problem (that I can't find now :-( ) a few months tago with an external website's map of Terran shipwrecks that used wikidata showed a location on a minor planetoid, as being a wreck 1000)") km off South Australia with no land near by Wakelamp d[@-@]b (talk) 10:25, 9 October 2022 (UTC)

The "reply" link cannot be used to reply to this comment

Can someone fill me in on the reason for this "error" popping up? (Full text: The "reply" link cannot be used to reply to this comment. To reply, please use the full page editor by clicking "Edit"., most recently noticed when attempting a reply to this post). 199.208.172.35 (talk) 15:03, 4 October 2022 (UTC)

My first instinct would be that it is confused by the {{od}} outdent template in the message you're trying to reply to. You could look thru the links at Wikipedia:Talk pages project#Open bugs to see if this has been reported before. --Floquenbeam (talk) 15:15, 4 October 2022 (UTC)

That was my thought, but a quick test at ANI showed that "reply" worked on other outdented posts; it only seems to error out on outdented posts by Cullen328. I'll check the links you mentioned. 199.208.172.35 (talk) 15:20, 4 October 2022 (UTC)

Hmm. No explanation at those links, least not that I could find, though other folks may have had the same problem (1, 2). This section talks about the error message but none of the examples apply (I think) to this case.

On an unrelated note, I really don't like that talk page setup, what a pain to try to skim/search old posts... 199.208.172.35 (talk) 16:45, 4 October 2022 (UTC)

I was able to fix the behavior by moving {{od}} out of the block of text. I would guess that Parsoid isn't parsing the block of text with {{od}} inline the same as Parser.php. Izno (talk) 16:55, 4 October 2022 (UTC)

- I'll file that knowledge away for future reference... well, the "move {{od}}" part, at least, the other stuff is way over my head. 199.208.172.35 (talk) 14:55, 5 October 2022 (UTC)

For future reference, this is the edit that fixed it: [1]

This was actually a case of Accidental complex transclusion, as described on the page that you linked to. When parsing wikitext markup like {{od}}{{u|username}}blahblah, Parsoid wants to generate a HTML <p> tag after the outdent, before the mention. Since there is nothing between these two things, the generated <p> tag ends up being marked as generated by the {{u|…}} template. Now you have an unclosed tag generated by a template, the transclusion is extended until it is closed, and we accidentally created a complex transclusion. (And the reply tool refuses to reply when they are involved, on the assumption that something weird is going on on the page.)

You can see this easily by opening the page in visual editor, where the entire comment will be marked as "Template content". [2]

By adding the line break, you cause the <p> tag to be generated by the line break character, and avoid this problem.

We actually have a task for this on Phabricator: T313093 (there's also a more detailed explanation in it), and we actually could make the reply tool work in this case – it's just a matter of us not knowing what else could possibly be affected in a negative way. But since this issue keeps coming up (yours is the 3rd case since I started noting them down), perhaps it is worth trying. Matma Rex talk 19:50, 6 October 2022 (UTC)

Thank you for the detailed explanation, your highness, @Matma Rex, sir (are you king of math? water buffalos? both? )! Most semi-experienced users know what to do when that error pops up, but it did confuse a newcomer at the Teahouse - they actually assumed it was a deliberate breaking of the reply tool on Cullen328's part. I'm glad to hear the issue is at least known and being tracked, and now I can explain the problem when I come across it in the future. 199.208.172.35 (talk) 21:53, 7 October 2022 (UTC)

It was math, and it is an old nickname ;) Glad that helped. Matma Rex talk 11:04, 8 October 2022 (UTC)

Forcing a cessation

Currently, whenever I refresh a page on Wikipedia or restore a previously viewed page using the back arrow, a banner drops down saying "View simplified page?" It only occupies about 10% of the page but the problem is that the 10% it occupies is enough to completely obscure my entire page header as well as all of the page links and notification links therein contained. And the banner remains in place for nearly 10 seconds which seems like an eternity with desired functionality unavailable while it is displayed. If anyone knows how I can force a cessation of this banner's display, please advise me of how. I am hopeful and eager to see a reply. Thank you.--John Cline (talk) 06:47, 5 October 2022 (UTC)

In furtherance of my desire to force this banner not to display, I reviewed my preference options, selected the "banners" tab and deselected all of the banner options which had all been selected. The "simplified view" banner is still appearing. I presume that others, if not all editors, encounter this banner. Am I correct in that regard? If so, does anyone else find its manner of display annoying? Best regards. --John Cline (talk) 09:18, 5 October 2022 (UTC)

@John Cline The 'view simplified page' popup is a feature of your web browser, not Wikipedia, so turning off Wikipedia banners will have no effect. What browser are you using? There are instructions online for disabling this feature on Chrome; I'm not sure if it's something other browsers have too. Sam Walton (talk) 10:26, 5 October 2022 (UTC)

Thank you for this reply. I use Firefox and will pursue disabling it from there. Got to go for now. Thanks again.--John Cline (talk) 10:52, 5 October 2022 (UTC)

Is the problem specific to Wikipedia? If not, perhaps you have Firefox's reader view enabled. Certes (talk) 11:06, 5 October 2022 (UTC)

Firefox reader view doesn't behave this way. The description appears to be a Chrome 'feature'. Neils51 (talk) 11:57, 5 October 2022 (UTC)

@John Cline: When you write I use Firefox, do you mean that the problem appears when using Firefox, or that the problem appears when you use some other browser (which?) and you have worked around the problem by browsing in Firefox instead? Certes (talk) 15:29, 5 October 2022 (UTC)

I say that I use Firefox because I designated Firefox as my default browser in my device settings and therefore believe that Firefox is the browser I use. I may in fact be wrong in my belief as much is assumed and little is actually known. Additionally, I've come to realize that technology has a way of imposing its own agenda with users of limited technical prowess; like me. Best regards.--John Cline (talk) 23:40, 5 October 2022 (UTC)

If you manually start a browser by clicking its icon then whichever browser you start will run. If you click a link in a non-browser program then your default browser may start. What does this say: https://www.whatismybrowser.com/. PrimeHunter (talk) 00:52, 6 October 2022 (UTC)

Your provided link says my browser looks like Chrome on Linux and then says my browser announced itself as Chrome 94 for Android 11. As such, Chrome usurped control of my settings for I never changed the Firefox designation, nor would I ever have; I dislike using Chrome. Best regards. --John Cline (talk) 13:39, 6 October 2022 (UTC)

It sounds as if you've been lured into accepting the default option for one of those confusing "refrain from opting out from refusing to change your browser?" pop-ups. Just change your default browser back to Firefox and everything should be how you like it again. You can do that in Firefox by visiting about:preferences, or in your operating system (the exact method depends which OS you use). Of course, this will apply to all websites: I don't think we need to change anything within Wikipedia. Certes (talk) 15:23, 6 October 2022 (UTC)

If you start the browser by clicking a browser icon then compare File:Google Chrome icon (February 2022).svg and File:Firefox logo, 2019.svg. PrimeHunter (talk) 20:01, 6 October 2022 (UTC)

Ironically, my Firefox settings show my designation of Firefox as my default browser and my phone's settings also show Firefox as my default browser, yet Chrome continues to prevail as the browser in actual use. Perhaps my manner of launching Wikipedia is ultimately at fault. The procedure I use follows: 1.) I click the Google search bar. 2.) I choose Wikipedia from the list of frequently searched terms 3.) I choose Wikipedia from the search results given 4.) I refine the subsequent result by choosing English Wikipedia and end up at Wikipedia's main page. If pages chosen from Google search results default to using the Chrome browser, I am my own worst enemy. And ask how I can launch Wikipedia by better means. Thank you.--John Cline (talk) 03:54, 10 October 2022 (UTC)

Yes, the problem is with step 1: Don't use Google's search bar on your phone from the phone's 'desktop'. Either acquire a custom search bar or launch Firefox directly. Izno (talk) 04:03, 10 October 2022 (UTC)

Indeed, this has identified my error and resolved the issue prompting this posting.Thank you all. --John Cline (talk) 17:54, 10 October 2022 (UTC)

PetScan or DB query for categories exclusively in Category:Hidden categories and Category:Tracking categories

I have stumbled upon a tracking category for a template, which was categorized into exactly two categories: Hidden categories and Tracking categories. Is it possible to do a WP:PETSCAN or a DB report for categories which are in these two categories and no other categories? That is, to generate a list of "uncategorized" maintenance tracking categories – in my case I've added the category to the tree of Category:Wikipedia template parameter issues. —⁠andrybak (talk) 00:15, 6 October 2022 (UTC)

Here you go. —Cryptic 00:40, 6 October 2022 (UTC)

I cleaned up things only in Category:Hidden categories in December 2021. Admittedly that involved dumping a few in Category:Tracking categories when I couldn't come up with a better parent. Another set of categories that don't count is subcats of Category:CatAutoTOC tracking categories * Pppery * _{it has begun...} 01:38, 8 October 2022 (UTC)

There's currently another 61 cats when that tree is permitted. —Cryptic 02:07, 8 October 2022 (UTC)

I'm slowly going through quarry:query/67919. Mostly categorizing them under tree of Category:Template parameter issues by topic. Six categories so far were (or are about to be) deleted per WP:G8 because templates that used the categories are either deleted or stopped using them. —⁠andrybak (talk) 11:44, 8 October 2022 (UTC)

Gitlab

WMF has "migrated" my bots to https://gitlab.wikimedia.org/toolforge-repos/milhistbot. [3] So now they cannot be updated any more. Anyone have any ideas as to how to work around this problem? Hawkeye7 (discuss) 06:36, 7 October 2022 (UTC)

As the mailing list thread says, login to wikimedia gitlab with your wikimedia account, and accept the email invitation to get push access to your repo. – SD0001 (talk) 09:16, 7 October 2022 (UTC)

@Hawkeye7, did you get that sorted out? Whatamidoing (WMF) (talk) 17:45, 10 October 2022 (UTC)

Yes, I got it sorted out in the end. I was not aware of the Wikimedia account that was used. Hawkeye7 (discuss) 18:24, 10 October 2022 (UTC)

"Camp"-string being blocked

I've noticed on one of my webbrowsers that any page containing the string "camp" is being blocked from edit or purge actions. I can still read the base page, and use what-links-here, related-changes, on these pages. I suspect this might be caused by some blacklist, but individually disabling my extensions doesn't isolate the problem to any one of them. I suspect this occurs with any url with **wikipedia.org/w/index.php?title=(title containing the string "camp" or similar)

Does anyone have a suggestion? If this is a common problem, it might need to be propogated up the chain to whomever maintains whatever block is causing this.

-- 65.92.247.226 (talk) 07:29, 7 October 2022 (UTC)

Just editing this section results in a URL that gets blocked from being viewed. (the new URL generated after a save contains a section link with the string "camp" in it, which results in the problem occurring). The error reported is that the redirects are occurring incorrectly and will never complete.-- 65.92.247.226 (talk) 07:32, 7 October 2022 (UTC)

Test edit to see if I get blocked URLs. —⁠andrybak (talk) 09:33, 7 October 2022 (UTC)

If this is a common problem – nope, it seems to be local to your network. Talk to whoever administrates it. —⁠andrybak (talk) 09:34, 7 October 2022 (UTC)

If it's only one browser then it must be something in the browser. Which browser? I assume it happens at https://en.wikipedia.org/w/index.php?title=Camp&action=edit. Does it happen at https://example.org/w/index.php?title=Camp&action=edit? PrimeHunter (talk) 10:32, 7 October 2022 (UTC)

No, that loads. -- 65.92.247.226 (talk) 05:42, 8 October 2022 (UTC)

Does it happen if you open your browser in safe-mode (no extensions)? — xaosflux ^Talk 13:50, 7 October 2022 (UTC)

It does not happen with a fresh profile. I already suspect it is a setting or an extension, but I couldn't isolate it by individually turning off the extensions. I had something similar happen before to several URLs containing the string "advert" or "ad", that was tracked down to a blacklist (thanks to Wiktionary tech people for tracking that down), but that also occured on the standard page, so isn't exactly the same problem. I can load the standard article page, but the purge and edit pages causes problems (either loading as the regular article page or not loading with the error message), as does coming out of a SAVE that contains this section header link in the URL. -- 65.92.247.226 (talk) 05:42, 8 October 2022 (UTC)

Template-transcluded categorization

Earlier this year, WP:FILM decided to deprecate its former practice of deeming base national film categories to be all-inclusive ones that had to directly include all films from that country even if they were already extensively subcategorized for genre or other characteristics, because that was resulting in the base national film categories being far too large with some categories populated into the tens of thousands -- so in recent months, there's been a cleanup project underway to diffuse the categories by removing them from films that were already subcategorized and then subcategorizing the remaining stragglers that weren't already subcategorized.

However, in the process of trying to work on cleaning up Category:Japanese films, I've found that a considerable number of films there don't actually have that category directly declared on them at all, and instead have it artificially transcluded by one of their templates. The likeliest candidate seems to be {{Infobox animanga/Video}}, because that's the most directly film-oriented of the Infobox animanga templates that have been common to all the affected films I've seen so far -- but the complex template coding is far, far beyond my ken, so I can't edit it myself, but I can't diffuse the Japanese films category if I can't get it off the films that are transcluded into it via the template.

So could somebody edit that template to ensure that it doesn't add Category:Japanese films to those films anymore? Thanks. Bearcat (talk) 15:07, 7 October 2022 (UTC)

It does appear to assign that category in one #if statement. This conversation should probably move to Template talk:Infobox animanga. This may be a violation of WP:TEMPLATECAT, but it's good to check locally to see if there is a good reason to flout the guideline. – Jonesey95 (talk) 16:14, 7 October 2022 (UTC)

(There aren't.)

@Bearcat, first you need to verify that there is a manual placement of the category for each automatic placement by the infobox. Then removal should be more or less easy. I would recommend following up at the talk page indeed. All of the categories should go, but that's going to take some time I think. Izno (talk) 16:39, 7 October 2022 (UTC)

@Bearcat: {{Infobox animanga/Video}} tries to add a year category based on |released=. It only adds Category:Japanese films if |type=live film and |released= is set but is not a valid date. Then it also adds Category:Anime and manga articles with malformed first and last infobox parameters. released must be a raw date with no reference and not made by a template with additional output like {{Start date}}. I'm not saying this is appropriate but just describing it. [[Category:Japanese films]] could simply be removed from the template code if the category is never wanted but it might (I haven't checked) leave some articles without any category for Japanese films. Category:Anime and manga articles with malformed first and last infobox parameters can be added in other ways. This shows cases where it was probably added by {{Infobox animanga/Video}}: insource:/released *=/ hastemplate:"Infobox animanga/Video" incategory:"Japanese films" incategory:"Anime and manga articles with malformed first and last infobox parameters". In most cases it's because released uses {{Start date}}. I'm not judging whether {{Start date}} should actually be removed or the category should be avoided in another way. PrimeHunter (talk) 09:42, 9 October 2022 (UTC)

Images with search results

Tracked in Phabricator
Task T306883

Tracked in Phabricator
Task T320337

Some time this afternoon (UTC), search started to display thumbnail images alongside search results. See e.g. insource:/\<ref( [^\>]*)?\>https?:\/\/[^ \<\>\{\}]+ *\<\/ref/i

I guess some people will like that, but for my purposes the images are just distracting clutter. Is there any setting in Preferences for those of us who don't want the images to turn them off? BrownHairedGirl (talk) • (contribs) 17:59, 7 October 2022 (UTC)

The way some of the images are displayed is odd as well, for example the way MTN 8 shows up on the search result it centers the infobox image and cuts off the sides of the image, so that around half of each logo is displayed which isn't useful (I searched "Top 8" to see that listed). If the image pulled isn't a square it zooms into the center and cuts off the sides which isn't always helpful. I'm sure this might be useful to most people, but I would also like to know how to turn this off if possible. - Aoidh (talk) 18:10, 7 October 2022 (UTC)

Seems to be related to phab:T306883 - seems there is a class, so a gadget could perhaps hide these. — xaosflux ^Talk 18:20, 7 October 2022 (UTC)

Should just be able to set the class "searchResultImage-thumbnail" to display:none in CSS to not show any of the thumbnails in the searches. Terasail^[✉️] 18:53, 7 October 2022 (UTC)

Thanks, that works a treat! I also see the advantages, especially for readers rather than editors, but I often copy search results into JWB or elsewhere for further processing, and that's much easier without the images. Certes (talk) 21:47, 7 October 2022 (UTC)

Editors making this change may also wish to include Izno's CSS to restore full width, described below. Combined diff. Certes (talk) 12:34, 8 October 2022 (UTC)

The best solution would be a tick-box in the Advanced search interface (with a remembered state). That should also allow a matching option in the search URLs so that canned searches can suppress the thumbnails — GhostInTheMachine ^{talk to me} 20:52, 7 October 2022 (UTC)

Thanks to @Xaosflux for the CSS snippet, which has hidden the images for me.

I'd still prefer a checkbox setting somewhere to disable them server-side. I don't like having to accumulate CSS kludges.

And I'm not thrilled to find that developer time has been going into another annoying feature, while there is no fix for slowdown of search caused by Elasticsearch 7, leading to my work being disrupted by search timeouts.

I agree with @Nobbo69's comment below: Keep Wikipedia no frills slim & trim. BrownHairedGirl (talk) • (contribs) 00:35, 8 October 2022 (UTC)

Search results use only about 40% of the screen width

Is it just me, or does each of these new search results take up even more vertical space than the old ones? In my browser (Firefox for Mac, running legacy Vector), the results use less than half of the vertical space available, and with the images stuffed into that already limited width=(about)40% column, each search result is taller. I see only four results per screen scroll instead of the already-lame five, when there is enough room to show eight or ten if the window width was used properly. I can post screen shots if I am the only one.

Is there a way to regain this horizontal space? If I wanted to lose horizontal whitespace deliberately, I would have switched to the New New Vector. – Jonesey95 (talk) 22:08, 7 October 2022 (UTC)

Yes, I have some CSS to make search results max width; see User:Izno/common.css#L-44. I think this max width case should be removed in New Vector (and more generally obviously; I'm sure there's something somewhere that says it's a good idea to limit these results...). Izno (talk) 22:27, 7 October 2022 (UTC)

Thanks. I love small improvements like this that should just be part of the skin. There is a faction at WMF that dearly loves its whitespace, even though optimal line lengths for scanning prose is not something that is relevant on search result pages. – Jonesey95 (talk) 05:06, 8 October 2022 (UTC)

The casual user is still scanning on a search results page, so for that set there is still merit I think. Power users of course are mostly using search results to identify gnoming targets and mostly only need the displayed results to ensure they don't waste time on false positives. Izno (talk) 16:22, 8 October 2022 (UTC)

I love this. It literally did not occur to me that someone would use Wikipedia's iffy built-in search to find an article rather than going to a real search engine and typing "wiki name of topic", which always works. My Wikipedia usage is so far outside the standard deviation that I can't even see that I'm on a curve. It's just a horizontal line in both directions, real close to the ground. – Jonesey95 (talk) 17:17, 8 October 2022 (UTC)

:) Izno (talk) 17:55, 8 October 2022 (UTC)

You're kidding, right? I get so irritated by search engine results that do not contain the only word that I want to see. I'm not talking about shirt without stripes problems (how is that still a red link?!). I'm talking about wanting all the web pages that contain "these five exact quoted words", and, if none exist, then just telling me that, instead of making up garbage results about "four" "vaguely" "related" "terms". Whatamidoing (WMF) (talk) 18:12, 10 October 2022 (UTC)

Thanks, Izno. That's a handy wee improvement. BrownHairedGirl (talk) • (contribs) 05:40, 8 October 2022 (UTC)

As a note, the selectors change periodically for whatever reason (I think that's the third or fourth version for me). Hopefully with mw- class names they'll finally be stable enough. Izno (talk) 16:20, 8 October 2022 (UTC)

Sincere apologies from the engineers about this; to make it so narrow wasn't intentional. This is interestingly the default width that MediaWiki uses for search results width and the change resulted in falling back to this. We'll get this fixed ASAP. Seddon (WMF) (talk) 20:54, 11 October 2022 (UTC)

New Searches Now Appear with Unwanted Images...

Hello! The Search Results page now seems to be adding images to the left of the suggested page titles and blurbs. Is it possible to stop this in my Global Preferences? It doesn't help (I come from the Reading the Words rather than Looking at the Pictures school of brain capabilities) and it is slowing things down loading in the images and probably making my browser use even more bloated than the blue-whale-of-blubber (a possible rebranding concept for Firefox...) it already is when I open 500 to quickly (now slowly) scan through things. I have loads of stuff open on a geriatric laptop, and I am keen to Help the Aged. PS: KEEP WIKIPEDIA NO FRILLS SLIM & TRIM! Not everyone has amazing computers and nippy bandwith (or much patience for things we don't need or want)... Thx! - I see the bloke above is having a similar grumble, and Terasail has suggest a CSS edit. Sadly, I am a Jack of Some Trades, Rubbish at Everything Else and Terasail's assumption seems to be that we have any idea how to actually do that, which I for one don't :(::::: Nobbo69 (talk) 21:13, 7 October 2022 (UTC)

@Nobbo69: you can put the following code snippet in to to: Meta:Special:MyPage/global.css

/*Remove search thumbnails*/
.searchResultImage-thumbnail {display:none}

Open that page, create it/edit it, and put those 2 lines in there. — xaosflux ^Talk 21:28, 7 October 2022 (UTC)

It's telling me I don't have permission.— Vchimpanzee • talk • contributions • 21:53, 7 October 2022 (UTC)

@Vchimpanzee that should land you at meta:User:Vchimpanzee/global.css, make sure you are logged in. If it is still failing and you want that added there, let me know and I'll force it for you. — xaosflux ^Talk 22:08, 7 October 2022 (UTC)

Thanks, I didn't know I could sign in.— Vchimpanzee • talk • contributions • 22:09, 7 October 2022 (UTC)

Correct me if I'm wrong, but I think display:none still loads entire content except that it is not displayed. If so, the user's "slowing things down" issue would remain unresolved? —CX Zoom[he/him] ^{(let's talk • {C•X})} 22:22, 7 October 2022 (UTC)

@CX Zoom it mostly "depends" on your browser settings; but that's all that we can do with a script hack - if you want these to not be generated at all (perhaps with an option) you will need to file a feature request. — xaosflux ^Talk 22:46, 7 October 2022 (UTC)

It should still slow things down "less", even if your computer fetches the image, with display:none it won't have to build out a section in the DOM for it, or actually render the file (on most browsers). — xaosflux ^Talk 22:48, 7 October 2022 (UTC)

FYI (everyone) this issue is apparently being rolled out across all of Wikidom, from Commons to Wikidata, and I've raised the issue on both projects. Glad to see it finally ticked off enough people here. Did it really get pushed into implementation by a single request to Phabricator without any broader discussion or feedback? I'm surprised (or maybe I shouldn't be?) that such a major visual change was forced upon everyone with no announcement, no feedback. I thought Wikipedia was open and transparent? Aside from the reduced screen space, a major annoyance is that it is now much easier to mistakenly click on the thumbnail than the intended article link (or Wikidata item, on that platform), which brings the user to the image first, requiring an additional couple clicks to get to the intended target. It also drastically worsens the efficiency of browsing simple searrh results on Commons, as every thumbnail is now a cropped square, regardless of original image aspect, which means that a lot of visual content is obscured, making many images appear poorly composed (or even lacking the sought after elements) until one clicks on the file. --Animalparty! (talk) 01:30, 8 October 2022 (UTC)

I encourage you to leave a comment about the clickability issue on a related task I filed today at phab:T320299.

Aoidh above discusses the question of cropping above. I think that would be feedback to leave on the task-proper which is phab:T306883.

Regarding whether it was a single request, mobile has displayed results similar to this in its dropdowns since a while and I know that at least Vector 2022 does the same (which will sooner or later be the default skin). I see this as making Special:Search reasonably consistent with those search bars. This factor also likely motivated the WMF to perform this work; the task of interest was made more as a work task than as a feature request. (Review WP:CONEXCEPT.)

I am however surprised this feature got turned on without a mention in the Tech News. Izno (talk) 01:59, 8 October 2022 (UTC)

One day I'd like to get a heads up about a major change in the tech report. Hawkeye7 (discuss) 20:49, 8 October 2022 (UTC)

Not quite what you wanted, but I've had success with a similar fait accompli at m:Talk:Tech/News: the incompatible surprise release I reported was publicised in their next issue. Certes (talk) 21:00, 8 October 2022 (UTC)

Yes, usually they will run things a week late if a note gets dropped on the task of interest. Legoktm sniped me to adding that as a comment on this task. Izno (talk) 22:52, 8 October 2022 (UTC)

I ultimately left my own comment about clickability on that task. Izno (talk) 02:20, 8 October 2022 (UTC)

@Izno: Thanks for that. I've never been able to log into Phabricator (OAuth/MediaWiki doesn't seem to recognize my info or email, although I can use pretty much any other project or tool). There are currently at least two related discussions on Wikidata and Commons that would be useful to bring to the attention of Phabricator folk. --Animalparty! (talk) 02:39, 8 October 2022 (UTC)

There had been a discussion on it at WP:Village pump (proposals)/Archive 191#Consultation on Search improvements. Adding images to search results was the first proposal and it was probably the single most opposed proposal but they went through. I assume they'll follow suit and the remaining proposals will also be enacted soon. —CX Zoom[he/him] ^{(let's talk • {C•X})} 05:58, 8 October 2022 (UTC)

This is a particular problem in that now non-free images are being displayed in search results too, which is against NFCC#9. I realize the pages are being generated automatically, similar to NFC maintenance categories, but that's still a problem, since it is possible to identify non-free files and thus not include them, and they serve no purpose on search results. --Masem (t) 01:32, 8 October 2022 (UTC)

Can you provide a representative search where that is an issue? Izno (talk) 01:48, 8 October 2022 (UTC)

First search on "Kiriko" (as searching) or "Kirikko", both have first results that are NFCC images. Masem (t) 02:28, 8 October 2022 (UTC)

The other thing to consider here is that this is consistent behavior with mobile and Vector22 implementations of the search bar, the former of which I believe has had prior discussion on WT:NFCC. Izno (talk) 02:45, 8 October 2022 (UTC)

Or, search for "Spider-Man", where nearly every thumbnail of the first 20 is non-free. WP:NFEXMP however seems to argue preview popups are exempt from WP:NFCC policy. --Animalparty! (talk) 02:49, 8 October 2022 (UTC)

Kusma mentioned what looks to be a pretty relevant task in Wikipedia talk:Non-free content/Archive 65#Jimbo on NFC philosophy (phab:T124225). However, NFEXMP is indeed relevant here and the relevant commentary looks like it was added by none other than Masem here. :) Izno (talk) 02:54, 8 October 2022 (UTC)

Some followup chatter in WT:Non-free content/Archive 67#WP:NFEXMP and article preview popups. Izno (talk) 03:01, 8 October 2022 (UTC)

Non-free images appearing as part of alternate presentations of the article like an article preview is arguably compliant and covered by the non-free use rationale for the article. The appearance of these images in search results is akin to a list and WP:NFLISTS is applicable. In other words, these non-free image should not be appearing on search results as they have no non-free use rationale for that, nor do they meet WP:NFCC#8. Whpq (talk) 12:37, 9 October 2022 (UTC)

Searching for "Queen album" is particularly egregious. Our hand curated Queen discography does not use any non-free images, and these search results do. That's just not right. If non-free images in search were okay, our WP:NFLISTS arguments to keep them out of curated lists would no longer make any sense. —Kusma (talk) 07:26, 9 October 2022 (UTC)

@Xaosflux The one place I might want this feature is Commons. Is there a way to make this css say don't display unless I'm on Commons? Nthep (talk) 11:48, 8 October 2022 (UTC)

@Nthep: I don't think that the css supports the IF wrapper, but you could do this, on commons:Special:MyPage/common.css, put this snippet:

/*Renable search thumbnails blocked in my global.css*/
.searchResultImage-thumbnail {display:unset !important}

— xaosflux ^Talk 15:54, 8 October 2022 (UTC)

thanks. Nthep (talk) 16:15, 8 October 2022 (UTC)

@Nthep and Xaosflux: Luckily, another way is possible using a namespace specific attribute being provided:

.mw-search-result:not(.mw-search-result-ns-6) .searchResultImage-thumbnail { display: none; }

This hides thumbnails except for file searches (namespace 6 is for files) and works also outside of Commons. — Speravir – 16:49, 10 October 2022 (UTC)

Hello @xaosflux - thx! I have a vector.css I use to make my default background colour softer, but I do not have a global.css and when I landed on that page and refreshed, it too said I do not have permission. I read Wikipedia in dozens of languages, so going global in this instance is very useful for me - can you please insert your techno-crowbar and use The Force? @CX Zoom 's point is also very interesting as it is definitely taking longer to load the search results with only 20 per page, let alone 500. If there is somewhere better in Wikipedia for me to go and stamp my feet, pout and rant, please point the way. Victor Meldrew, watch and learn! :D

RANT START. I have had this moan before when the French Wikipedia went all frilly-featury and became too complicated for me to edit the simple bits of detail that make Wikipedia special, NOT the unnecessary background frills! The moan seemed to work or was just well timed as they took off loads of tinselly guff - for now! I worry it is part of a gradual process of slowly denying creative access to the vast majority of people that have made Wikipedia so amazing in the first place. There are probably hundreds of thousands of would-be editors and contributors being put off by all the unnecssary scripting requirements - just adding proper references and verifications is awkward enough - and Wikipedia should be making things EASIER, not harder. Big Thanks from a MousyHairedBoy to @BrownHairedGirl for agreeing with me! Wikipedia is ripe for appropriation by the wrong sort of global that has done nothing to create it. RANT OVER. :) Nobbo69 (talk) 09:49, 8 October 2022 (UTC)

@Nobbo69: try reloading the page, if you are blocking cookies you may need to click logon - it is the same username and password you use here. — xaosflux ^Talk 15:54, 8 October 2022 (UTC)

images when searching

Hi, how do you I get rid of this new thing where every time I do a search each article has an image next to it? There are several reasons why it's problematic, and I would have prefered for this not to have been automatically added to my interface. Thank you! Dr. Vogel (talk) 00:06, 9 October 2022 (UTC)

@DrVogel: see above. — xaosflux ^Talk 00:09, 9 October 2022 (UTC)

Thank you. I added that line and the annoying images are gone. Much appreciated.

But from my console, I can see that my browser is still downloading them from the server etc. Is there a way to opt out of interface "improvements" forced on my account? Thank you! Dr. Vogel (talk) 00:40, 9 October 2022 (UTC)

@DrVogel you could file a feature request on phabricator to make that an option for search results. We can't change that locally. If you open one, please let us know the tracking number here as other may want to follow it. — xaosflux ^Talk 01:54, 9 October 2022 (UTC)

• Just another unwanted and unnecessary "feature" foisted on us without consultation. Stop fixing what ain't broke. There are enough problem with Search, not having images was not one of the,, geez. Beyond My Ken (talk) 06:15, 9 October 2022 (UTC)

• Thanks for the hack, though, which seems to be working fine. Obviously should be a switch in Preferences/Search. Beyond My Ken (talk) 06:18, 9 October 2022 (UTC)

Unfortunately I missed the consultation request for this 'feature'. It now means that copy and pasting search results into Excel is rather problematic. A switch in Preferences should have been a part of the implementation, it shouldn't have to be requested. Many thanks for the CSS workaround. Neils51 (talk) 09:39, 9 October 2022 (UTC)

Special:Search changed?

Seems like Special:Search recently had a bit of an overhaul in how the results are presented, including showing an image from the respective articles. However, I both do not like this and did not know this was ever going to happen. Anyways, I figured VPTECH may be the place to bring up this concern for the following inquiry: Is there any way to revert back to the way Special:Search was before with either a setting or some sort of ".js coding magic"? Steel1943 (talk) 01:50, 9 October 2022 (UTC)

@Steel1943 there is a CSS hack above you can use. — xaosflux ^Talk 02:03, 9 October 2022 (UTC)

Request to disable images

Tracked in Phabricator
Task T320337

Based on feedback from many above, I've opened phab:T320337 to have a way to disable this built in. Any support or feedback to that request is welcome on phabricator. Thank you, — xaosflux ^Talk 02:02, 9 October 2022 (UTC)

See also mw:Bug management/Phabricator etiquette and remember that voting-type behaviors (including what we might call "consensus building" at this wiki) are not wanted in Phab tickets. The information that belongs there is the information needed by a coder to do the work, and not, e.g., comments asking someone to do the work. Whatamidoing (WMF) (talk) 18:23, 10 October 2022 (UTC)

CSS hacks

Below are the CSS hacks mentioned above. — xaosflux ^Talk 12:57, 9 October 2022 (UTC)

Global

To hide these on all projects: you could put the following code snippet in to to: Meta:Special:MyPage/global.css. If you don't go to metawiki often you may have to click logon first (if prompted, it is your same username and password)

/*Remove search thumbnails*/
.searchResultImage-thumbnail {display:none}

Only hide here on the English Wikipedia

Same code as above, but put in Special:MyPage/common.css

Global except certain projects

If you hide globally, but want to unhide on only one project: Go to that project, and on that project go to your Special:MyPage/common.css and put in:

/*Renable search thumbnails blocked in my global.css*/
.searchResultImage-thumbnail {display:unset !important}

Add. by Speravir:
So, let me add the alternative to the rules above here, as well:

Hide thumbnails except for file searches

/* Remove search thumbnails except for file searches */
.mw-search-result:not(.mw-search-result-ns-6) .searchResultImage-thumbnail { display: none; }

— Speravir – 19:48, 11 October 2022 (UTC)

How to get the WMF to reverse this?

It was opposed when proposed, it is unwanted now, and it shows non-free files in a place where this is not allowed (the same stunt they pulled with "related articles" and so on in the past, glad to see they learning nothing from their previous errors). Is there a way to get the WMF to quickly reverse this, and then to only implement this after it has gotten consensus? Fram (talk) 16:16, 10 October 2022 (UTC)

• I agree this should be reverted immediately. Changing the way we use non-free images is a massive change that can't be decided without a big sitewide RfC. Other changes break lots of workflows for too little demonstrated gain, and should at least be optional. —Kusma (talk) 16:32, 10 October 2022 (UTC)
• As far as I remember this was always the case on mobile. At least for years if my memory serves me right. A bit strange to see the issues have only been noticed now, now that it's on desktop. Anyway, the rule around non-free is for legal reasons, right? It shouldn't be a problem with the WMF is okay with it, they probably would have consulted with the legal team about it (or they should if they haven't). Consensus doesn't matter if it's a legal issue, and if it's not a legal issue, then the consensus would merely deal with aesthetic preferences, not any legal restrictions around non-free images. TryKid ^{[dubious – discuss]} 17:04, 10 October 2022 (UTC)

  No, the rule around non-free is not for legal reasons, it is because we aspire to be a free encyclopaedia, where all content except for rare exceptions is under a free licence. —Kusma (talk) 17:21, 10 October 2022 (UTC)

  Search results aren't "content" though. Using non-free content willy-nilly in articles might trouble reusers, but displaying them internally, in the "related pages" or search results, does that make reuse of Wikipedia articles any more difficult or different copyright/free-use wise? TryKid ^{[dubious – discuss]} 17:37, 10 October 2022 (UTC)

  I don't know, but reusers aren't the only reason why Wikipedia uses little non-free content. I would happily vote for a free (WP:VEGAN) Wikipedia if given the chance. —Kusma (talk) 18:50, 10 October 2022 (UTC)

I don't know what was WP:Village pump (proposals)/Archive 191#Consultation on Search improvements for, if they had to push through anyway. As I said above, image in search was the single most opposed *improvement*. —CX Zoom[he/him] ^{(let's talk • {C•X})} 17:11, 10 October 2022 (UTC)

Hi everyone, I'm the Community Relations Specialist for the Structured Data Across Wikimedia project, which also is responsible for the deployment of this new feature of article thumbnails. I'm deeply sorry for the lack of proper announcement about the deployment of this feature, and the least I can promise is that this will not happen again for next deployments.

Also, I'm collecting your feedback about bugs and problems you're having with this feature, and I already shared them with the development team. Here are some of the answers that they gave to me:

• About how thumbnails are displayed: thumbnails are made to fill the required square, so any overflow is not visible. Unfortunately, this is not fixable at code level (there would be multiple cases to support and this would impact negatively on code), but if you want this could be fixed with a wiki-specific CSS override, in order to restore the traditional way of rendering the full image within the available bounding box.
• About non-free images: since such images are sourced from the project and already used in other similar places as well (go bar autocomplete), it was (uncorrectly) assumed they were ok to use. We stand corrected, and will correct the code to list free images only.
• About turning off the feature: we defined the feature to be turned off with a CSS hack, but I know that a Phabricator ticket (phab:T320337) has been opened to make this a preference. We are taking into consideration this, and I will let you know as soon as possible if there are news on this.

Again, I'm deeply sorry about this whole disruption, and will see that in the future this won't happen again. Meanwhile, feel free to ping me and let me know any problem you're noticing. --Sannita (WMF) (talk) 08:29, 11 October 2022 (UTC)

Sannita (WMF): Have you fixed the bug that causes the images to link to the File: page instead of the article page? I reported it on one of the phab tickets. I have turned off images, so I can't check it. – Jonesey95 (talk) 14:00, 11 October 2022 (UTC)

@Jonesey95 We're working on all the bugs you reported, but it takes time to fix all of them. I'll keep you posted about it. Sannita (WMF) (talk) 15:25, 11 October 2022 (UTC)

With as much respect as possible: It is simply not true that WMF staff are working on all the bugs I have reported (T174303 is old enough to go to kindergarten). WMF staff appear to be focusing on new features, many of them unwanted by the community and which cause new bugs and problems of their own. It is very frustrating, and it is a significant cause of burnout and resentment among veteran technical editors. – Jonesey95 (talk) 16:41, 11 October 2022 (UTC)

I can promise that THIS team is taking the feedback here seriously. Seddon (WMF) (talk) 20:59, 11 October 2022 (UTC)

Random tech question

Hello Vilage Pump Tech denizens,

I had a random question I'm hoping you can either give me a Yea or Nay on. I know there is a tool that compiles an editors' last 500 votes on AFDs and compares them to the actual closures of these deletion discussions. Is there any easy way to compile admin stats on how admins close AFDs, you know their stats on closing discussions as Delete, Keep or No consensus? I'm just curious at this point and maybe these kind of stats are not desirable. Also considering that there are probably only a dozen or so admins closing AFD discussions, it might be too small of a group of affected people to be worth setting up a tool for this. It could be a part of adminstats, I guess, and I suppose it could also be possible to extend it to RFD/CFD/TFD/MFD if anyone creating a tool is that ambitious.

What brought up this question in my mind is the coming evaluation of admin and editing activity in January 2023. I was thinking that if an admin tended to close discussions as No consensus, Redirect, Merge or Draftify, that act wouldn't show up as an admin activity in a log whereas an article Deletion would show up on an admin log of activity. I hope my request is straight-forward and not overly complicated. If this is information that no one has an interest in or there is no interest in developing this tool, I completely understand, I just thought I'd venture and put forward this query. Thanks! Liz ^{Read! Talk!} 00:38, 8 October 2022 (UTC)

Is there any easy way to compile admin stats on how admins close AFDs, you know their stats on closing discussions as Delete, Keep or No consensus? "Does this exist today?", no, I don't think so. I think it could be done in a similar way to how things are counted today, but that's a volunteer thing to work on and set up. :)

I was thinking that if an admin tended to close discussions as No consensus, Redirect, Merge or Draftify, that act wouldn't show up as an admin activity I don't really understand this comment. The new inactivity rule starting in January 2023 is based solely on edits and all closures cause at least one or two edits....

From a more general "do we need something like that?", I think probably not. Checking to ensure admins are making good closes is the only useful direction I can see for that kind of tool, but bad closures have established processes for review already that do more or less a good job. Izno (talk) 03:13, 8 October 2022 (UTC)

@Liz, I think this is what you're looking for? Extraordinary Writ (talk) 03:53, 8 October 2022 (UTC)

Sticky header rows gadget breaks display of table

I've got the gadget enabled in settings labelled as "Make headers of tables display as long as the table is in view, i.e. "sticky"". I found out today that when this gadget is enabled, it breaks the display of the table at Template:Wikidata/doc#Configuration_flags. When the gadget is disabled, the table looks fine, but when it's enabled, it looks like this. The bottom row is displaying incorrectly for some reason when this gadget is enabled. Would it be possible to fix this somehow, perhaps with a bug fix to the gadget? Thanks. – numbermaniac 05:48, 8 October 2022 (UTC)

It's a known issue when the last row only has header cells declared in the row itself. Fixed by adding a non-displayed row.[4] PrimeHunter (talk) 11:01, 8 October 2022 (UTC)

Discussed at Wikipedia:Village pump (technical)/Archive 200#Help with Table. PrimeHunter (talk) 11:06, 8 October 2022 (UTC)

Interesting, good to know what the cause of it is. Thanks for fixing it! – numbermaniac 15:06, 8 October 2022 (UTC)

Allowing anons to use gadgets

Anons are a large portion of Wikipedia visitors, but when it comes to gadgets they are shit out of luck if the desired gadget isn't loaded by default. They can load it by modifying the URL (like ?withgadget=dark-mode) but that's forgotten once you navigate to another page. They can use something like Greasemonkey, but it's not reasonable to expect users to do that.
I'm suggesting to consider setting something up that would give anons more options. Originally written for testing purposes, I realized something like User:Alexis Jazz/AnonLoader might actually be useful for non-testing purposes. You can demo it at https://commons.wikimedia.beta.wmflabs.org/wiki/Main_Page where anons can enable/disable ConvenientDiscussions, Dark Mode and Factotum using sidebar links. Consider it a proof of concept. — Alexis Jazz (talk or ping me) 10:02, 8 October 2022 (UTC)

Thanks: that seems to have great potential, though it might be hard to advertise to those who need it most. I was about to write a simple Tampermonkey script to insert ?useskin= when I visit Wikipedia anonymously, but this tool could do that job too. Certes (talk) 13:05, 8 October 2022 (UTC)

Certes, great idea! (but not quite as simple as I thought) I wrote SkinEnforcer (should work with *monkey too) and added it to AnonLoader on betacommons so it can be taken for a test drive. Two brand new scripts in a day, not bad. — Alexis Jazz (talk or ping me) 01:30, 9 October 2022 (UTC)

Thank you. I'll adopt that if (when?) the default skin changes. It looks a lot more professional than the simple and non-portable hack I had in mind. Certes (talk) 10:07, 9 October 2022 (UTC)

OAuth/pywikibot help

I'm having a problem trying to get OAuth working with pywikibot on ToolForge and was hoping someone here would be able to help. (I've posted on #pywikibot but that seems to be low traffic.) I've looked through the archives here and found this test file:

import pywikibot
site = pywikibot.Site() # or site = pywikibot.Site('en', 'wikipedia')
site.login() # Logs in
site.logged_in() # Test if logged in


which I've created in the bot user account. If I run "python3 test1.py" on this file I get "pywikibot.exceptions.NoUsernameError: Failed OAuth authentication for wikipedia:en: The authorization headers in your request are not valid: No approved grant was found for that authorization token."

I set up user_config.py using the values I got from https://meta.wikimedia.org/wiki/Special:OAuthConsumerRegistration/propose to fill in the authenticate strings per https://www.mediawiki.org/wiki/Manual:Pywikibot/OAuth. The registration page gave me three values, rather than the four listed on the OAuth page:

authenticate['en.wikipedia.org'] = ('consumer_token', 'consumer_secret', 'access_token', 'access_secret')

so I have no value for the 'access_secret' field, and I can't see anything in the documentation about what to put there. I'm guessing that's the problem but I can't be sure. Any pointers to where I can find documentation on this would be much appreciated. Mike Christie (talk - contribs - library) 16:21, 8 October 2022 (UTC)

Update: now resolved (I think) via help received on IRC. Mike Christie (talk - contribs - library) 17:07, 8 October 2022 (UTC)

Follow up question for anyone who understands how to run a Python tool on ToolForge. I have started the webservice with " webservice --backend=kubernetes python3.9 start", and have a .py file that uses OAuth that will run interactively in the shell. If I name that file app.py and move it to ~/www/python/src/ I thought it would respond to https://ganfilter.toolforge.org, but it doesn't. What do I need to do to have code respond to that URL? Thanks for any help. Mike Christie (talk - contribs - library) 21:54, 8 October 2022 (UTC)

Your app.py just prints a string – that would not make it respond to the web endpoint. You have to create an app object using some web framework like django or flask and assign that to a top-level variable named app in app.py. The quick start code from flask docs should work when placed in app.py. – SD0001 (talk) 10:16, 9 October 2022 (UTC)

Thanks -- I tried that and per the uwsgi.log it seems "from flask import flask" is failing (from flask import Flask / ModuleNotFoundError: No module named 'flask'. Per this page I think that means the venv I built is not working. I just went back into the venv with the command given at that link and did "pip install flask"; it says "Requirement already satisfied" so it appears the install worked. I restarted the webservice and I still get a 503 error, and the uwsgi.log shows the import is still failing. Can you suggest anything else I might be doing wrong? I did also notice when trying to import some of the other modules I want to use that some were not found; e.g. "pip install re" fails. Mike Christie (talk - contribs - library) 11:37, 9 October 2022 (UTC)

All commands for installing packages inside the venv should be done within a webservice shell (first command from that link). If you did any pip installs from outside, I suggest deleting the venv and starting afresh.
re is a standard python module, it need not and cannot be installed. – SD0001 (talk) 12:02, 9 October 2022 (UTC)

I did everything inside the webservice shell. The only difference between the commands given at that link and what I typed is that I used 3.9 rather than 3.7, and I did “pip install flask” rather than using a requirements.txt file. Mike Christie (talk - contribs - library) 12:18, 9 October 2022 (UTC)

I deleted the venv and redid the steps from scratch, as you suggested, and this time it worked. Thanks for the help! Mike Christie (talk - contribs - library) 12:55, 9 October 2022 (UTC)

Working outside tools

Greetings. How we check for redirects these days? ౪ Santa ౪^99° 19:35, 9 October 2022 (UTC)

@Santasa99, if you want to check redirects to a given page, you can do so from the associated WhatLinksHere page, i.e. Special:WhatLinksHere/Page. — Qwerfjkltalk 19:57, 9 October 2022 (UTC)

Thanx Q, yes, that should help. I am going to try it right away. ౪ Santa ౪^99° 20:09, 9 October 2022 (UTC)

RFC: Column name/position/content for binary computing units

See Template talk:Quantities of bits#RFC: Column name/position/content for binary computing units for full RFC

There is an RFC to answer questions about the {{Quantities of bits}} and related templates. Please see the questions there and answer as you see fit. —Locke Cole • t • c 01:24, 10 October 2022 (UTC)

Hide an image

I want to try to hide images that are offensive. I seen the Help:Options to hide an image. I tried the code for hiding the bad images. Cwater1 (talk) 03:39, 10 October 2022 (UTC)

@Cwater1: First, define "offensive". But see also Wikipedia:Village pump (idea lab)/Archive 41#Personal censoring as an option for an account. --Redrose64 🌹 (talk) 14:41, 11 October 2022 (UTC)

Images that are disturbing or inappropriate. I seen the Help:Options to hide an image. -Cwater1 (talk) 23:45, 11 October 2022 (UTC)

No boundary available for Livingston, Louisiana

The Wikidata item for the town of Livingston, Louisiana, is missing the boundary of this town, despite being clearly visible in OpenStreetMap as a gray outline. When fixed, this outline should become red, and only the area outside of the town should be shaded. –LaundryPizza03 (dc̄) 04:33, 10 October 2022 (UTC)

In the meantime, the infobox on the town's article has been changed from "shape-inverse" (which shades the area outside the demarcated region) to "shape" (which shades the area inside the demarcated region). More details at Template:Maplink. –LaundryPizza03 (dc̄) 22:02, 10 October 2022 (UTC)

As the shape is also not filled when shown as a a normal shape... this looks like there is a gap in the shape somewhere. If you look at https://maps.wikimedia.org/geoshape?getgeojson=1&ids=Q2177827 (the data request), I'm actually seeing the same shape delivered twice I think ?? That's kinda strange, not sure what is causing that. Can you please file a phabricator ticket ? —TheDJ (talk • contribs) 10:44, 11 October 2022 (UTC)

@LaundryPizza03, TheDJ It looks like the normal approach here is for OSM to contain the Wikidata ID, not the other way around - WD itself does not normally have the boundaries.

In this case, OSM has two seperate things both tagged with the same Wikidata ID (relation, way). I am not sure exactly what the correct model from the OSM side is here, but if we jump east along the highway to Albany, the relation has the Wikidata ID but the way does not, and testing {{maplink}} on that item seems to show up with the correct box. So I'm guessing that may be the ultimate source of the problem, and removing one of the IDs should solve it? Andrew Gray (talk) 12:01, 11 October 2022 (UTC)

@Andrew Gray: What are the Wikidata IDs of these labels? The one associated with the English article is Q2177827. –LaundryPizza03 (dc̄) 00:14, 12 October 2022 (UTC)

@LaundryPizza03 Both Livingston OSM items are tagged with Q2177827 (so the Livingston WD item). For Albany - which works correctly - the OSM relation is tagged with Q2216044, which is the WD item linked to Albany, Louisiana. (Sorry - I'm a little unclear what you mean by labels? I hope this is the information you're after) Andrew Gray (talk) 14:37, 12 October 2022 (UTC)

@Andrew Gray: You said that there is a duplicate border? Just delete one, and see what happens. What's the difference between "Relation" and "Way" in OSM? –LaundryPizza03 (dc̄) 14:57, 12 October 2022 (UTC)

Move table to right

I can't seem to find an instruction on how to move a table to the right side of the page, with text on the left. Any help you can give me at User:Magnolia677/sandbox would be appreciated. Thank you! Magnolia677 (talk) 08:14, 10 October 2022 (UTC)

@Magnolia677: This is happening because your code currently says style=""float:right" (with one extra quotation mark). Change that to style="float:right" and it'll fix it. —CX Zoom[he/him] ^{(let's talk • {C•X})} 08:22, 10 October 2022 (UTC)

You had an extra double quote after |style=: Special:Diff/1115201393. —⁠andrybak (talk) 08:24, 10 October 2022 (UTC)

@Andrybak: Thanks for that. But when I added more text, the table floats right and below the text. Is there a way to make the text wrap to the left and beside the table? Thanks again. Magnolia677 (talk) 08:27, 10 October 2022 (UTC)

All good. Thanks for your help. Magnolia677 (talk) 09:36, 10 October 2022 (UTC)

@Magnolia677: We provide the floatright class for this, you would use it as {| class="wikitable mw-collapsible mw-collapsed floatright" and you then don't need a style= attribute. This class provides some extra styling, primarily setting the left and bottom margins of the floated box to 0.5em - compare Special:PermaLink/937219298#Operation (no margins) with Special:PermaLink/955699497#Operation (margins set by the class). --Redrose64 🌹 (talk) 14:26, 11 October 2022 (UTC)

Thank you! Magnolia677 (talk) 14:41, 11 October 2022 (UTC)

Tech News: 2022-41

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

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 11 October. It will be on non-Wikipedia wikis and some Wikipedias from 12 October. It will be on all wikis from 13 October (calendar).
• On some wikis, Kartographer maps in full size view will be able to display nearby articles. After a feedback period, more wikis will follow. [5][6]

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

14:06, 10 October 2022 (UTC)

Publishers Weekly error

When automatic citations are created for articles from Publishers Weekly [7]https://www.publishersweekly.com/, the url shows up with a dropped letter "l" in the word publishers. I had noticed this because the link is dead on arrival in articles I worked on. There is currently an effort to correct the nearly 150 citations with this "typo." However, it is not a typo of the part of the editor, but something in the automatic coding. Any help in fixing this weird glitch would be appreciated by those of us who work on articles about authors and books. Rublamb (talk) 18:48, 10 October 2022 (UTC)

Please always post an example when you report a problem. There are no live examples because they have all been fixed but I chased down an example fix. The source is https://www.publishersweekly.com/9780312898281 but its own html is missing 'l' in: <meta property="og:url" content="https://www.pubishersweekly.com/9780312898281">. The tag is supposed to give a canonical url the site wants people to use when they link a page with multiple url's so the citation tools are technically doing the right thing. We could work around it by making an exception for this site but I think we should simply try to tell them they screwed up and see if they fix it. I have mostly bad experiences (being ignored) about telling sites about their errors. Anybody good at it? PrimeHunter (talk) 19:34, 10 October 2022 (UTC)

I could bring a few examples too (of being ignored) when I brought up similar errors to various sites in the past. Imo, the main problem seems to be that the people who administer the site content and who may be contacted, are not the ones maintaining its code. So several different parts must move together. Even assuming one could discover the domain's technical contact (now de facto widely considered privileged information when not the ISP), it is highly unlikely he/she would jump to contact the site's developers for something so minor. The branding people at PW may be more interested, but this may be technical gobbledygook for them, especially since it is unlikely their target demo will ever notice this. 204.19.162.34 (talk) 20:23, 10 October 2022 (UTC)

I hope the webmaster (or whatever they're called this decade) would be very interested. I may be well out of date here but the canonical URL was important for SEO: content found on duplicated across many domains would be penalised except when at its canonical URL. There's a typosquatter on the misspelled domain, who must be taking some traffic away from the real site. Certes (talk) 10:36, 11 October 2022 (UTC)

Thanks for the tips. I should probably start by making it clear it's serious in non-technical terms and ask to forward it to somebody who can act on it. I looked at https://www.publishersweekly.com/pw/corp/contactus.html and mailed the below to DIRECTOR OF DIGITAL OPERATIONS Michael Morris. PrimeHunter (talk) 11:17, 11 October 2022 (UTC)

Title: publishersweekly.com has many url's to a malicious site instead of your own 

Please forward this post to those responsible for generating your website code.

Many of your pages have a wrong url to a probably malicious site instead of your own site. Visitors may blame you for anything they experience there, and your website may be punished in search engines.

For example, the HTML code for https://www.publishersweekly.com/9780312898281 contains this with an 'l' missing in "pubishers":

<meta property="og:url" content="https://www.pubishersweekly.com/9780312898281">

The code indicates your preferred url for the page is https://www.pubishersweekly.com/9780312898281
But pubishersweekly.com is probably controlled by a malicious typo squatter. I get security warnings and don't want to enter the site. Some tools use your wrong code when making links to the site. I'm an administrator at the English Wikipedia. We recently discovered more than 100 broken links where our citation tools had used your false url's. We fixed the existing links but new broken links will keep being made by us and others until you fix your HTML.

Gadget (definition) (talk) namespaces

I observed that the first character of page titles in Gadget (definition) (talk) namespaces is case-sensitive, which doesn't seem to be the case for most Wikipedia pages. See Gadget:Example and Gadget:example. Why is this? Railtransportfan (talk) 22:55, 10 October 2022 (UTC)

The recent software change at phab:T300000. Izno (talk) 23:16, 10 October 2022 (UTC)

@Railtransportfan: Don't worry about these four namespaces. We don't use them for their intended purpose (and we never have), and AFAIK we won't use them in the future either. Gadget contains only a redirect (left behind when a page was moved to a non-colliding name in mainspace just before the namespaces were set up); Gadget talk contains a proper talk page - for that redirect; Gadget definition and Gadget definition talk are completely empty. --Redrose64 🌹 (talk) 13:37, 11 October 2022 (UTC)

If we don't use them, why are the pages in those subject namespaces superprotected, even from administrators? Deletion seems to be the action that should be taken, superprotecting pages that aren't and won't ever be used seems to only create problems. Railtransportfan (talk) 00:13, 12 October 2022 (UTC)

Are they causing any harm to the project? Are they creating any difficulties for you? I would say no, and probably no: in which case (as I said earlier), don't worry about them. --Redrose64 🌹 (talk) 05:41, 12 October 2022 (UTC)

Section edit save returning view to top of page

On saving a source edit for a section, I am getting returned to the top of the page instead of the top of the edited section. Windows 11, latest Firefox, default skin. Is this happening to anyone else? · · · Peter Southwood ^(talk): 00:26, 11 October 2022 (UTC)

It is also happening when logged out on Chrome.· · · Peter Southwood ^(talk): 00:33, 11 October 2022 (UTC)

It does not seem to be happening on talk pages. · · · Peter Southwood ^(talk): 01:05, 11 October 2022 (UTC)

It may be restricted to one section of one article. I will check later. · · · Peter Southwood ^(talk): 02:36, 11 October 2022 (UTC)

Well that was weird. I tried all sorts of things and nothing worked until I cut the entire contents of the subsection with ctrl-X and saved. I got returnrd to the now empty section. Then I pasted back exactly what I had just cut with ctrl-V, and it seems to now be working normally. I have no idea. · · · Peter Southwood ^(talk): 04:49, 11 October 2022 (UTC)

Please always include an example when you report an issue. This was about Diving safety#Occupational safety and health in professional diving. The line with the section heading ended with a tab at the time. A test shows that this omits the automatic addition of a section link to the url after saving a section edit. The edit summary still gets the section link but not the browser. When you blanked the section the tab was removed and you didn't restore it afterwards. You probably didn't delete the tab yourself but trailing whitespace at the end of the whole edit is automatically removed when you save. PrimeHunter (talk) 09:56, 11 October 2022 (UTC)

This can happen if the section heading contains characters that need encoding when made into URL fragments; this is one reason that we discourage the use of templates in headings. Basically, if the encoding fails, your browser cannot jump to the section anchor, so goes to page top - this being the normal behaviour of all browsers if a fragment doesn't match any id= attribute within the page. --Redrose64 🌹 (talk) 14:16, 11 October 2022 (UTC)

This was a different case where the tab was after == ... == . No #... is generated at all in the url. I tested it at User:PrimeHunter/sandbox#2016–17. It can be tested with a null edit which just gives https://en.wikipedia.org/wiki/User:PrimeHunter/sandbox. User:PrimeHunter/sandbox#2015–16 has no tab and gives the expected https://en.wikipedia.org/wiki/User:PrimeHunter/sandbox#2015%E2%80%9316. PrimeHunter (talk) 15:20, 11 October 2022 (UTC)

BernsteinBot disabled

FYI

 – Pointer to relevant discussion elsewhere.

Please see User talk:MZMcBride#BernsteinBot disabled. This will impact a lot of processes. --Redrose64 🌹 (talk) 09:35, 11 October 2022 (UTC)

@Legoktm I wonder what are the chances of SDZeroBot 10 being approved by the toolforge admins? It could be used to easily replace a number of BernsteinBot reports. – SD0001 (talk) 19:38, 11 October 2022 (UTC)

@SD0001: I genuinely don't know. I'm still a bit iffy on the concept, maybe there's some middle ground where it only works on semi-protected pages or something? Starting a Phab task would be the right way to get an "official" decision. Legoktm (talk) 15:08, 12 October 2022 (UTC)

In the "replacement" realm, User:Community Tech bot may be a good candidate, it already does other database reports. — xaosflux ^Talk 15:15, 12 October 2022 (UTC)

Looks like User:HaleBot (Wikipedia:Bots/Requests for approval/HaleBot) is going to do this. — xaosflux ^Talk 15:19, 12 October 2022 (UTC)

Opened phab:T320657. Hope I added the right tags. – SD0001 (talk) 16:15, 12 October 2022 (UTC)

lynx 2.9.0dev.6-3~deb11u1 version diff pages show white text only

i have applied code given at Wikipedia:Browser notes on lynx. i am using debian bullseye on userland app. i am using xterm. i did not installed another terminal. how it looks (jpg image). diff pages show white text only..... i mean links & others are colour. article text is white colour only. is this normal? <_>— jindam, vani (talk o e-mail o contrib o actions) 15:03, 11 October 2022 (UTC)

That is normal behavior. I am using lynx 2.8.9 on macOS 11.7 and the rendering is identical judging from the image you provided. 65.88.88.92 (talk) 19:53, 11 October 2022 (UTC)

To add, the diff window will show plaintext by default irrespective of the browser. Is there another page section that does not render properly? 65.88.88.92 (talk) 20:04, 11 October 2022 (UTC)

ok, lynx does not show text with

background colours, it plainly shows [INS: :INS] for insert instead of colour. just to be sure for anyone who has stumbeld: diff with colours on browser (.jpg) & diff without colours on lynx (.jpg). so, my assumption is incorrect. <_>— jindam, vani (talk • e-mail • contrib • actions) 01:44, 12 October 2022 (UTC)

You may want to experiment with your lynx.lss file, although the "syntax highlighting" section seems limited: lynx.lss 50.75.226.250 (talk) 16:33, 12 October 2022 (UTC)

Quick question about category redirects

As an editor who from time to time works with Special:WantedCategories to clean up redlinked categories, I've noticed in the past several weeks that a redlinked category for "Indian philoshopers", obviously a simple spelling error for Category:Indian philosophers, has repeatedly reoccurred -- I would clean it out by correcting the category to the correct spelling, only to then have it come back with whole new entries again the next time I looked at the redlinked category list. I was able to establish that it gets repeatedly added by IP numbers -- it's obviously the same editor given their persistent inability to spell "philosopher" correctly, but it isn't always the same IP, and some of the IP numbers have been editblocked for block evasion.

So in the hopes of not having to deal with it showing up on the Wanted Categories list anymore, I created Category:Indian philoshopers as a category redirect to the correctly spelled category last week, so that the bot that cleans out non-empty category redirects would fix the IP's typos automatically -- only to find just now that several articles had been readded to it since then, but the bot never actually touched any of them at all. (I've cleaned them out again, but was hoping to not have to deal with that anymore.) RussBot appears to still be active, so I wanted to ask: am I missing some other code that needs to be added to flag it for RussBot's attention? Bearcat (talk) 20:24, 11 October 2022 (UTC)

"Not in Wikidata"

Resolved

Also related to Special:WantedCategories, there was a redlink sitting there called Category:Not in Wikidata with seven articles in it -- but they all feature that category as an artificial transclusion from a template rather than as a direct category declaration. It seems incredibly likely to just be redundant to something else, considering the sheer number of maintenance categories in Category:Wikipedia categories tracking data not in Wikidata that are already much, much more specific about what particular piece of data is "not in Wikidata", but I've been unable to figure out what template it comes from -- and per its history, it appears to have also been created and then deleted once before, meaning that whatever's going on this isn't the first time it's happened.

So can somebody determine what template is causing the seven articles in Category:Not in Wikidata to display that category, so that they can be revised to move them to a more specific sibling category? Thanks. Bearcat (talk) 23:12, 11 October 2022 (UTC)

My guess is Module:WikidataCheck, which says return "[[Category:" .. catbase .. " not in Wikidata]]". Something may be calling it without the |category= parameter. – Jonesey95 (talk) 23:39, 11 October 2022 (UTC)

Yeah, called from {{F-Droid}}. (To track this down, blank a bit of the article, preview, and repeat until the category goes away.) —Cryptic 23:41, 11 October 2022 (UTC)

You can also use Special:ExpandTemplates to see where the category code is. In this case the fourth external link in Avare says: [https://f-droid.org/packages/com.ds.avare/ ''Avare''] Android package at the [[F-Droid]] repository[[Category: not in Wikidata]]. PrimeHunter (talk) 23:46, 11 October 2022 (UTC)

• Okay, thanks for that. In light of that explanation, then, I'm going to suggest that the "Not in Wikidata" category should be kept as an error-catcher, since this sort of thing might well happen again in the future, instead of just being deleted as soon as this is resolved. Bearcat (talk) 23:50, 11 October 2022 (UTC)

I have fixed the template and created the necessary category. A null edit should put all of those articles in the correct category. – Jonesey95 (talk) 23:53, 11 October 2022 (UTC)

Peer Review not properly closed

Wikipedia:Peer review/François St-Laurent/archive1 was closed back in January 2021, however it still is showing up on Article Alerts as active. Any idea how to fix this? Kaiser matias (talk) 23:14, 11 October 2022 (UTC)

It was still showing up in Category:Requests for peer review because its talk page used {{peer review}} instead of {{old peer review}} (also see the closure instructions). I've fixed this case as well as all those listed at User:SDZeroBot/Peer reviews ... there were older ones listed there, as can be seen by sorting the date column. Graham87 10:07, 12 October 2022 (UTC)

Main page image display issue

One of the images on the current main page does not display in some browsers. The issue is described at Wikipedia:Main Page/Errors#Today's FA. Schwede66 00:59, 12 October 2022 (UTC)

Here's a permalink to the discussion. Graham87 09:13, 12 October 2022 (UTC)

Can't cut and paste or copy and paste anymore

Recently, I lost the ability to archive my old messages and add templates to the backs of articles. When I scan messages and templates and what not, to move and remove them, once I get to the blank pages I want to add them to, the icon that usually contains the "paste" command isn't there anymore. And from what I've read, this isn't just a problem on Wikipedia. Reddit users have also been having this problem. -------User:DanTD (talk) 14:48, 12 October 2022 (UTC)

"the icon that usually contains the "paste" command". What kind of app are you using to browse Wikipedia ? Because generally copy paste is operating system or application level logic and not website logic. —TheDJ (talk • contribs) 15:19, 12 October 2022 (UTC)

Can a blocked editor edit through protection of their own talk page?

A blocked editor can (unless specifically set otherwise) edit their own talk page when blocked. Can they still do that if it is a protected at a level that they would be able to edit through if they weren't blocked? i.e. an autoconfirmed user who is not blocked can edit their talk page if it is semi-protected, can they do that if they are blocked? What about extended-confirmed editors and ECP protected pages and admins and fully protected pages?

The circumstances in which it would be desirable to do any of this are obvious extremely limited, but not non-existent - e.g. if it is desirable to let a blocked editor communicate on their talk page but other editors comments and/or responses on the page are not helping to the situation. Thryduulf (talk) 15:22, 12 October 2022 (UTC)

@Thryduulf yes. A blocked autoconfirmed user can still edit their own talk page, even if it is SPP; a blocked admin can still edit their own talk page, even if it is FP. — xaosflux ^Talk 15:29, 12 October 2022 (UTC)

Thank you. Thryduulf (talk) 15:31, 12 October 2022 (UTC)

@Thryduulf note, blocking will never make you be able to edit more (e.g. a blocked autoconfirmed editor can not edit their talk page if it is full protected). — xaosflux ^Talk 15:32, 12 October 2022 (UTC)

Replace links to joanjoc/sugart.php to working tool

There is a tool https://tools.wmflabs.org/joanjoc/sugart.php , helping to find articles in some wikipedia not having interwiki link to another language section. This tool doesn't works for several years. 2 years ago I wrote a replacement tool, https://mbh.toolforge.org/pages-wo-iwiki.cgi , and today we in ruwiki decided to replace all links to broken tool to new one, for example. May I do this bot run in enwiki? MBH (talk) 16:18, 12 October 2022 (UTC)