Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia
 Policy Technical Proposals Idea lab WMF Miscellaneous 
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.

Packed galleries still having problems in mobile[edit]

Since my post last May, which fizzled out with nothing fixed, looks like the issue with galleries on mobile continues to persist. See for example the gallery at Southeast Asia#Demographics. Issue encountered on Chrome for iOS. Do this also affect other browsers? Android? TagaSanPedroAko (talk) 07:38, 1 July 2023 (UTC)Reply[reply]

  • Fine on Firefox for Android, also the default Samsung browser and the app. Looks like an iOS issue. Black Kite (talk) 10:32, 1 July 2023 (UTC)Reply[reply]
    There was a Phabricator ticket that has been opened for that issue, but nothing have came out of it. Maybe someone should reopen it or file a new one. TagaSanPedroAko (talk) 05:43, 6 July 2023 (UTC)Reply[reply]
    Please do not open a new task or file a new one. And "bumping" tasks is somewhere in the realm of "don't do that". Izno (talk) 17:40, 6 July 2023 (UTC)Reply[reply]
    Well ok. The thing with the current ticket regarding packed gallery is that there was no progress since it was first posted. The previous thread was already archived. TagaSanPedroAko (talk) 09:22, 8 July 2023 (UTC)Reply[reply]

Flipping/mirroring images[edit]

I wonder if it would be possible to enable flipping/mirroring of images in standard image templates, which will help in various cases, when for example a (non-human) subject of an image should face the text (per the MOS). This is often an issue in animal articles, and particularly in the paleontology Wikiproject, where drawings of extinct animals are frequently used, but can be unwieldy if not facing the desired direction. One solution has been to upload flipped versions of images, but this is a huge, seemingly redundant task if this could simply be done with code by using an optional parameter in image templates. FunkMonk (talk) 15:44, 4 July 2023 (UTC)Reply[reply]

You need to be very careful if doing this. Per Wikipedia:Manual of Style/Images#Editing images, Images should not be changed in ways that materially mislead the viewer. For example, images showing artworks, faces, identifiable places or buildings, or text should not be reversed (although those showing soap bubbles or bacteria might be). --Redrose64 🌹 (talk) 15:57, 4 July 2023 (UTC)Reply[reply]
Definitely follow Redrose64's guidance above. That said, here's a tool that can be used for good or evil:
 <div style="transform: scaleX(-1);">[[File:Example.jpg|thumb|This is a caption]]</div>
which looks like:
This is a caption
Jonesey95 (talk) 16:37, 4 July 2023 (UTC)Reply[reply]
Yes, the template page should state what it can and can't be used for. But this goes for flipped images in general whether they are uploaded as a new file or not. Having an automatic parameter would instead help us eliminate a lot of useless flipped versions of files; if it is determined that an image of, say, a person, should never have been flipped, all we have to do is remove the hypothetical flip parameter from the image template. But if it exists as a flipped file on Commons even after it has been removed from an article here, it's a much longer process, there will be a chance it will be added again later, that is has been added to a non-English Wikipedia in the meantime, and it may have to go through a drawn-out deletion request process. As for the example above, doesn't it also flip the caption? FunkMonk (talk) 17:01, 4 July 2023 (UTC)Reply[reply]
And the text in the image. In general, don't do what you're suggesting, as I suspect it will also be a general performance degradation relative to uploading a flipped image. Izno (talk) 17:29, 4 July 2023 (UTC)Reply[reply]
Yeah, images with text or other cases where asymmetry is important should not use the parameter, just like we shouldn't upload flipped versions of such images, so it isn't really a novel issue. The difference is just that the parameter is much easier to just remove from an image template than getting rid of a wrongly flipped file. FunkMonk (talk) 17:42, 4 July 2023 (UTC)Reply[reply]
I suspect it will also be a general performance degradation relative to uploading a flipped image. remains of interest. Izno (talk) 17:46, 4 July 2023 (UTC)Reply[reply]
For the technique described (where the flipping is achieved using the CSS declaration transform: scaleX(-1)), the WMF servers simply serve the unflipped image and the flipping is done entirely client-side. Therefore any performance degradation will be at the client's end, and WP:DWAP doesn't come into it.
If the client (the user's browser) does not support CSS Transforms Module Level 1, it will fail gracefully, with the unflipped image being displayed. Most current browsers support that CSS module, but they don't have to, because it's not yet a full W3C Recommendation. --Redrose64 🌹 (talk) 21:33, 4 July 2023 (UTC)Reply[reply]
1) It is additional CSS going down the pipe. That is the first point of minor performance degradation. 2) The second point is that it will take longer on the client side to digest and use that CSS. Transforms in particular cost more in computing than many of the other CSS properties. They are both minor but not non-existent.
I am unconcerned about browsers that do not support it as there are (basically) none that we support at/above grade C.
Besides those two points, I think this adds additional complexity for something that any image creator can take care of trivially, without degradation in performance. Izno (talk) 22:13, 4 July 2023 (UTC)Reply[reply]
What level of "performance degradation" are we talking about here, and do we have any reason to even suspect it poses significant (or any at all) challenges to most modern computers? And flipping with code is already being done in many articles that have cladograms with illustrations, so again, I see no realistic downside to making this less unwieldy to do. We're literally just talking about making it possible without also flipping the captions, flipping with code is already possible and being done all over the place. FunkMonk (talk) 17:07, 6 July 2023 (UTC)Reply[reply]
A template with TemplateStyles targeting <img> rather than random CSS would work here. Izno (talk) 17:30, 4 July 2023 (UTC)Reply[reply]
I think the rules are made for editors, and not vice versa. If there are layout reasons why the image can't be placed on the other side of the page, then personally I would prefer to just live with the subject looking outwards. (I appreciate if the image is of a drawing where there was no particular reason or asymmetry for the subject to look a given way, flipping it wouldn't matter, but without knowing the background of the drawing, it would be hard to know this.) isaacl (talk) 21:03, 4 July 2023 (UTC)Reply[reply]
In the case where a representation has been created by the uploader and they know the image can be safely flipped, I think it would be better for them to upload both versions with appropriate indications in the file name, which would signal their intent. isaacl (talk) 21:10, 4 July 2023 (UTC)Reply[reply]
But in this case, many editors do prefer what the guideline recommends, which is that subjects face towards the text. It simply looks better. And we're talking about thousands of images from various sources, not just some by the editors themselves here and there. A method of flipping a the image itself which doesn't also flip the entire caption and frame would be enough. FunkMonk (talk) 00:08, 5 July 2023 (UTC)Reply[reply]
I feel fidelity to the original image is a greater concern. Images can be placed on the left side, too. isaacl (talk) 00:50, 5 July 2023 (UTC)Reply[reply]
Perhaps, but that's irrelevant to the guideline and the fact that many editors do want to make images face the text, and it also does not address the fact that flipped versions of images are already being uploaded en masse, which is an even more severe infringement on their fidelity. We simply don't need flipped versions if it can be done automatically instead. FunkMonk (talk) 03:15, 5 July 2023 (UTC)Reply[reply]
Yes, my comments on flipped images are regarding uploaded flipped images, as well as any instances using a client transformation. Putting images on the appropriate side so the subject will face the text does address the style issue. isaacl (talk) 03:27, 5 July 2023 (UTC)Reply[reply]

Dropdown menu bug[edit]

Dropdown menu bug in other wikis[edit]

Bug in question

I recently came across a bug in every wiki except for Wikipedia. I have no idea how Phabricator works, so can somebody please file a ticket for this? Thanks in advance, QuickQuokka [⁠talkcontribs] 10:04, 5 July 2023 (UTC)Reply[reply]

@QuickQuokka I've never been able to get my head around Phabricator, either. I'd suggest posting at WP:VPT might get the attention of more technical folk. Nick Moyes (talk) 10:12, 5 July 2023 (UTC)Reply[reply]
Doesn't seem like a MediaWiki bug. Commons works fine for me. One or some of the gadgets might be trying to add tabs in way not working with Vector 2022. Did you try to switch to Vector? What gadgets are you using that add this things as semi-tabs? Nux (talk) 11:01, 5 July 2023 (UTC)Reply[reply]
@Nux: Using the old Vector skin seems to fix it, but I'd honestly rather not use it.
Here is my global.js, Here is my common.js QuickQuokka [⁠talkcontribs] 11:16, 5 July 2023 (UTC)Reply[reply]
@Nux: Also btw I haven't changed anything in my gadgets or JavaScript files lately[a], the closest thing is me changing my global.css to change the color of redirects and interwiki links. --QuickQuokka [⁠talkcontribs] 11:28, 5 July 2023 (UTC)Reply[reply]
@QuickQuokka seems like a problem with the meta:MoreMenu. I'm not using it, but maybe @MusikAnimal might be able to help. Seems like V22 might be not supported yet. BTW, MusikAnimal you might want to try out Wikipedia:Wikiploy for deployment from Github 🙂. Nux (talk) 11:38, 5 July 2023 (UTC)Reply[reply]
This is a known incompatibility between Twinkle and Vector 2022. See this Twinkle talk page thread for details and a workaround. – Jonesey95 (talk) 11:51, 5 July 2023 (UTC)Reply[reply]
@Jonesey95: I tried adding that into my global.css and previewing it, but it seemed to change nothing. --QuickQuokka [⁠talkcontribs] 12:26, 5 July 2023 (UTC)Reply[reply]
Really? I haven't noticed anything. — Qwerfjkltalk 16:00, 5 July 2023 (UTC)Reply[reply]
@Qwerfjkl: I have noticed it (see T337893), but I thought it was fixed, and up until today it was working fine. --QuickQuokka [⁠talkcontribs] 16:47, 5 July 2023 (UTC)Reply[reply]
@QuickQuokka, if it's on other wikis but not this one, it might be an ITSTHURSDAY issue (which will happen on Wednesday for smaller wikis). — Qwerfjkltalk 16:57, 5 July 2023 (UTC)Reply[reply]

@Qwerfjkl: Now thinking about this, you're absolutely right. I see that all the wikis where this happens are group 1 wikis (which I mostly use), so it makes sense. Hope they resolve this. --QuickQuokka [⁠talkcontribs] 17:04, 5 July 2023 (UTC)Reply[reply]

This has been fixed for meta:MoreMenu on all wikis. It will be fixed in Twinkle before the breaking changes arrive here on enwiki tomorrow. For interface admins on other wikis, you can either go by phab:T319358#8989477 or wait for it to be fixed upstream (assuming they're using the new version of Twinkle and that Twinkle devs are actually maintaining that. I'm not even sure…). MusikAnimal talk 16:59, 5 July 2023 (UTC)Reply[reply]

The buttons particularly are phab:T340952. It will be fixed soon. Izno (talk) 17:07, 5 July 2023 (UTC)Reply[reply]

@Qwerfjkl: Yep, now broken on enwiki too 🥲 --QuickQuokka [⁠talkcontribs] 09:51, 6 July 2023 (UTC)Reply[reply]

Notes

  1. ^ I did try out a new script, but I removed it shortly after

In Farsi Wikipedia the bug still persists. See https://fa.wikipedia.org/wiki/%D8%B5%D9%81%D8%AD%D9%87%D9%94_%D8%A7%D8%B5%D9%84%DB%8C

And this screenshot: Thumbnail

But English Wikipedia has fixed it. Please do the same fixing as English Wiki for us. Thanks, Hooman Mallahzadeh (talk) 14:16, 6 July 2023 (UTC)Reply[reply]

@Hooman Mallahzadeh: Is it the Twinkle menu that shows up like this? CX Zoom[he/him] (let's talk • {CX}) 15:55, 6 July 2023 (UTC)Reply[reply]
@CX Zoom Yes, "توینکل" in Farsi is equivalent to "Twinkle" in English. Hooman Mallahzadeh (talk) 15:59, 6 July 2023 (UTC)Reply[reply]
@Hooman Mallahzadeh: Then, the local installation of Twinkle on fawiki needs to be edited to bypass this error. For example this edit was required for Twinkle to be fixed on enwiki. phab:T319358#8989477 lists the changes that needs to be made for an immediate fix, or you can wait until this is fixed from software side at phab:T340952. CX Zoom[he/him] (let's talk • {CX}) 16:06, 6 July 2023 (UTC)Reply[reply]

Top right drop down menus (enwiki)[edit]

Anyone else have some of these just become expanded by default? Gråbergs Gråa Sång (talk) 09:15, 6 July 2023 (UTC)Reply[reply]

It seems to be changing, atm it's the Twinkle one. Gråbergs Gråa Sång (talk) 09:17, 6 July 2023 (UTC)Reply[reply]
Same here. Happy Thursday! -- Tamzin[cetacean needed] (she|they|xe) 09:18, 6 July 2023 (UTC)Reply[reply]
Not an issue logged out... Maybe it's about Twinkle specifically? -- Tamzin[cetacean needed] (she|they|xe) 09:20, 6 July 2023 (UTC)Reply[reply]
Could be, at least now. It was the user and tools menus before. Gråbergs Gråa Sång (talk) 09:21, 6 July 2023 (UTC)Reply[reply]

I am having the same issue and I think it is WP:Twinkle as if I disable it in preferences it is just fine. Lightoil (talk) 09:28, 6 July 2023 (UTC)Reply[reply]

If you need Twinkle, you can always switch to the Monobook skim, which is working fine. —Kusma (talk) 09:35, 6 July 2023 (UTC)Reply[reply]
Seen. A Vector 2022 skin change caused Twinkle to break again. I'm working on a Twinkle patch. Stay tuned. –Novem Linguae (talk) 10:40, 6 July 2023 (UTC)Reply[reply]
Thanks for working on a Twinkle patch, @Novem Linguae
@Kusma's suggestion of using the Monobook skin may solve the dropdown issue ... but for me, after a few weeks of adjusting to the Vector 2022 skin, switching back again would be a pain. So I'll keep on swearing at the fallen-down dropdown until the goddess of code smiles on Novem's labours. BrownHairedGirl (talk) • (contribs) 10:54, 6 July 2023 (UTC)Reply[reply]
+1. Gråbergs Gråa Sång (talk) 11:04, 6 July 2023 (UTC)Reply[reply]
Thanks! Gråbergs Gråa Sång (talk) 11:02, 6 July 2023 (UTC)Reply[reply]
The hotfix is ready for an interface admin: MediaWiki talk:Gadget-Twinkle.js#Hotfix for vector-2022 Twinkle dropdown menu appearanceNovem Linguae (talk) 11:06, 6 July 2023 (UTC)Reply[reply]
Bless you, @Novem Linguae.
My stock of swearwords was being rapidly depleted, but your speedy fix has saved me from the trauma of a completely empty stash. BrownHairedGirl (talk) • (contribs) 13:30, 6 July 2023 (UTC)Reply[reply]
No worries. I'm happy to help. I'll probably apply for interface admin soon so I can do these faster. –Novem Linguae (talk) 18:58, 6 July 2023 (UTC)Reply[reply]
Fixed! :-) ~Oshwah~(talk) (contribs) 12:23, 6 July 2023 (UTC)Reply[reply]
👍 Gråbergs Gråa Sång (talk) 13:48, 6 July 2023 (UTC)Reply[reply]

Content translator not working[edit]

Hello, I asked in Wikipedia:Help desk and ppl recomended to write here.


I checked all the pages and I have extended autoconfirmed status, but when translating from Catalan to English I get a warning


On the English Wikipedia machine translation is disabled for all users and this tool is limited to extended confirmed editors (see WP:CXT).


and a


Translation services not available for the selected languages. Why?


I don't understand why, because both Google translate and Apertium translate from Catalan to English. TaronjaSatsuma (talk) 13:44, 5 July 2023 (UTC)Reply[reply]

@TaronjaSatsuma the technical answer is: because the community doesn't want that enabled here. — xaosflux Talk 15:41, 5 July 2023 (UTC)Reply[reply]
For non-technical background see Wikipedia talk:Content translation tool and its archives. — xaosflux Talk 15:42, 5 July 2023 (UTC)Reply[reply]
Ok, I see it's general.
I believe that the situation should be better explained in the tool itself.
Still, thanks for your answer. TaronjaSatsuma (talk) 16:29, 5 July 2023 (UTC)Reply[reply]
Xaosflux made MediaWiki:Contenttranslation-summary which is displayed at top of Special:ContentTranslation. It currently says: "On the English Wikipedia machine translation is disabled for all users and this tool is limited to extended confirmed editors (see WP:CXT)." I do think it's a little confusing. It sounds like "this tool" refers to machine translation and then it becomes self-contradictory. Many users probably don't know that machine translation is just a part of the content translation tool. WP:CXT explains more but many users ignore links. I suggest: "On the English Wikipedia this tool is limited to extended confirmed editors and the machine translation part is disabled for all users (see WP:CXT)." PrimeHunter (talk) 11:46, 6 July 2023 (UTC)Reply[reply]
updated to clarify. — xaosflux Talk 13:24, 6 July 2023 (UTC)Reply[reply]

Search bar[edit]

What is wrong with the search bar on the main page in Vector 2022 skin?? Never works on my ipad, I have to click on an article just to get the search bar working! ♦ Dr. Blofeld 07:54, 6 July 2023 (UTC)Reply[reply]

@Dr. Blofeld: It works on my iPhone. In a narrow window you may have to first click a magnifying glass icon at the top to make the search bar appear. Does it work in safemode or if you log out? PrimeHunter (talk) 11:14, 6 July 2023 (UTC)Reply[reply]

Editing through the "+" link[edit]

I strongly disagree with the change a few months ago where edits to pages by clicking on the "+" link put the user in a radically different environment from the regular edit. Now users have two editing interfaces, the regular edit interface and the new "+" interface. When a user clicks on "+", they should have the same environment as if they clicked on "edit". Can we go back to the status quo ante, please? As an example of the madness of this new interface, I always sign my comments starting with an em dash. In this new environment, instead of the Insert menu, I have to click on the Omega icon to get the special characters to appear. Users should not have to contend with idiosyncrasies such as this. By the way, for both environments, I use the source editor and avoid the visual editor. —Anomalocaris (talk) 09:13, 6 July 2023 (UTC)Reply[reply]

You can disable this feature in Special:Preferences#mw-prefsection-editing under "Enable new topic adding". -- Tamzin[cetacean needed] (she|they|xe) 09:16, 6 July 2023 (UTC)Reply[reply]
Tamzin: Thanks! But why anyone thinks that users should have to contend with a special interface for new topics, different from the regular edit, is beyond me. This is a total violation of sound interface design. —Anomalocaris (talk) 16:58, 6 July 2023 (UTC)Reply[reply]
There are many ways to edit Wikipedia. Do not think that because you learned one way that everyone should learn the same way or in fact that everyone does. Izno (talk) 17:52, 6 July 2023 (UTC)Reply[reply]
Izno: See my comment at mw:Talk:Talk pages project/New discussion#Please fix the vague instructions. —Anomalocaris (talk) 18:39, 6 July 2023 (UTC)Reply[reply]
Regarding example 1, the intended interaction for most editors in the future is to use the "Reply" button, not the "edit" button, to reply to comments. Which provides the same interface as the + button now does. If you don't have those links, that's because you've already customized your interface via either CSS or the options I think available in preferences to remove them. Regarding item 2, WAID already provided the suggested remedy: turn it off in your preferences.
In general, data has already shown that the talk pages project has improved talk page use. Izno (talk) 19:08, 6 July 2023 (UTC)Reply[reply]

Change to WikiProject banner shell[edit]

A less verbose design has been rolled out for {{WikiProject banner shell}}, after discussion at Template talk:WikiProject banner shell § How project banners should look. Though the change was fully implemented in WPBannerMeta, please discuss any issues at the section linked above. DFlhb (talk) 12:40, 6 July 2023 (UTC)Reply[reply]

Where did "Forgot your password?" go?[edit]

I remember that it used to be possible to select "Forgot your password?" on the Log in page, and give the username/email address to receive a temporary password over the email. See the log in page of Beta Wikipedia where it is still present. But on the real Wikipedia, its gone. CX Zoom[he/him] (let's talk • {CX}) 17:31, 6 July 2023 (UTC)Reply[reply]

Works for me. * Pppery * it has begun... 17:33, 6 July 2023 (UTC)Reply[reply]
I'm sorry, I was wrong in my assessment of the situation. Actually, that link was gone for me on enwiki. So, I check where that leads leads to on Beta, and then I manually opened Special:PasswordReset on enwiki, and got the error "Your IP address is blocked from editing. To prevent abuse, it is not allowed to use password recovery from this IP address." because apparently I'm in this range. I was then able to recover my account via a password reset at metawiki. CX Zoom[he/him] (let's talk • {CX}) 17:38, 6 July 2023 (UTC)Reply[reply]

It's included in Category:Pages where post-expand include size is exceeded. And yet it's such a minuscule page, calling, from what I can tell, another tiny template once.

What's going on here? 17:47, 6 July 2023 (UTC) Headbomb {t · c · p · b}

Headbomb: Your linked page was deleted, so kindly restate the issue. —Anomalocaris (talk) 18:43, 6 July 2023 (UTC)Reply[reply]
 Fixed the link. Headbomb {t · c · p · b} 18:45, 6 July 2023 (UTC)Reply[reply]
I think that the problem is recursion. The page Template:User19 is attempting to transclude Template:User-multi/template which in turn is supposed to display some documentation, which itself should display some examples of actual {{user19}} use, but it's not. All we see is a link to Template:User-multi/template; plus (if at Preferences → Appearance you have enabled "Show hidden categories") a category box containing Pages where post-expand include size is exceeded - the link appearing instead of a transclusion suggests WP:PEIS, the presence of the category confirms it. --Redrose64 🌹 (talk) 22:00, 6 July 2023 (UTC)Reply[reply]
I'm sure you're right. {{User19}} has doc=yes while the very similar {{User17}} has doc=no. I previewed an edit of {{User19}} after changing it to use doc=no and the result was that the category no longer applied. {{User17}} has some "NODOC" code which looks pretty useless to me. I'll leave saving the edit for the moment to give others who might understand the situation to have a look. Johnuniq (talk) 01:43, 7 July 2023 (UTC)Reply[reply]
While wondering why templates like {{User11}} work but {{User19}} has this include-size-exceeded problem, I discovered that Template:User19/doc exists and is transcluded. It probably contains something that leads to the recursion. I intend to delete the /doc page because I think better documentation is generated automatically if /doc does not exist. If that would be a bad idea, please speak up. Johnuniq (talk) 06:08, 8 July 2023 (UTC)Reply[reply]
{{User19/doc}} caused {{Userspace linking templates}} to be transcluded a second time and it has a huge post-expand include size which is made worse by being passed through other templates. The only real content was that duplicate transclusion so I have deleted {{User19/doc}}. {{User19}} renders now. PrimeHunter (talk) 11:22, 8 July 2023 (UTC)Reply[reply]

{{pp}} should only display a padlock by default, not banner[edit]

I have read that template's talk page, there's little discussion about this (to look it up just simply Ctrl+F "default"). What do you all think about this? Hddty (talk) 04:28, 7 July 2023 (UTC)Reply[reply]

Is there any way of identifying the most recent links to a specific page?[edit]

Is there any function that would allow me to check Special:WhatLinksHere and get result sorted by when the links were added to the target pages? The purpose would be, for example, to find the most recent instances of when a particular guideline is invoked in a discussion through linking.

Or is there some other way to achieve the same thing than WhatLinksHere? Peter Isotalo 09:07, 7 July 2023 (UTC)Reply[reply]

Related changes, aka Special:RecentChangesLinked, shows changes to pages which link here. (Select "Show changes to pages linked to the given page instead".) However, the addition of new links may be drowned by other changes to pages that already linked here. Also, as the name implies, changes are only shown if they are recent (3 days by default, 30 selectable), not if they are older but still the latest. I hope that helps, but I suspect it doesn't. Otherwise you'll probably need a bot, because the list of which pages already linked here yesterday (and should thus be excluded from the report) isn't maintained. Certes (talk) 09:56, 7 July 2023 (UTC)Reply[reply]
Help:Searching#linksto: can be combined with "Advanced search", "Sorting order", "Edit date" at Special:Search to find the most recently edited pages with a link but the link could have been added at any time. User:PrimeHunter/Search sort.js gives another way to select sorting order. PrimeHunter (talk) 13:39, 7 July 2023 (UTC)Reply[reply]
One option is run WhatLinksHere or equivalent locally at your chosen time interval, saving the results to compare with the next run. If you don't fancy writing a simple program for that, a browser add-in such as Distill might help. However, it's still not going to spot a second link to the same target, for example if someone starts an ANI section citing WP:NOTHERE when it is already linked in an ongoing ANI thread. Alternatively, we could hope that this wishlist item is better supported next year, which would satisfy the request easily. Certes (talk) 14:40, 7 July 2023 (UTC)Reply[reply]
Many thanks for the tips. This is good enough for my purposes for the moment. Peter Isotalo 14:50, 7 July 2023 (UTC)Reply[reply]

Wikiproject Film script error (with Supported by Japanese task force??)[edit]

Resolved

Hello, This message "Category:Script error: The function "quality" does not exist.-Class Japanese cinema articles" appears on various TP of articles in the Project Fillm that are of interest for the Jp task force. Can anyone help with that? Examples: TF page itself, or here or here. Thank you. -MY, OH MY! (mushy yank) 12:39, 7 July 2023 (UTC)Reply[reply]

See this discussion. The change that caused this problem was just reverted; affected pages may require a WP:NULLEDIT. – Jonesey95 (talk) 12:47, 7 July 2023 (UTC)Reply[reply]
Thank you very much. -MY, OH MY! (mushy yank) 12:55, 7 July 2023 (UTC)Reply[reply]

Making fields default in visual editor?[edit]

When I insert {{dyknstr}} in the visual editor, there are no fields selected by default. You always want at least "article" and one of "prep" or "queue. What do I need to do to make those get inserted by default? RoySmith (talk) 15:25, 7 July 2023 (UTC)Reply[reply]

Template usage in the Visual Editor is guided by the Template Data code in the template's documentation. See Wikipedia:TemplateData. – Jonesey95 (talk) 15:34, 7 July 2023 (UTC)Reply[reply]
Cool, got it. Thanks. RoySmith (talk) 01:03, 8 July 2023 (UTC)Reply[reply]

Redirects for article titles ending in periods[edit]

I have just made a redirect to Mail Boxes Etc. from Mail Boxes Etc - because when various email clients and other tools encounter the plain text string https://en.wikipedia.org/wiki/Mail_Boxes_Etc. they make a link to https://en.wikipedia.org/wiki/Mail_Boxes_Etc (without the period).

Every article ending in a period should likewise, it seems, have a redirect from the version without a period.

Before I request a bot to do this, is there any case where it might be problematic? Should we do it for other punctuation characters? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:47, 7 July 2023 (UTC)Reply[reply]

I know that I have seen this question before, but it will be tricky to search for a discussion about it. Do we, or should we, have an "R from" template for this sort of redirect? It could go on Mr and Ph. D and many more. – Jonesey95 (talk) 02:06, 8 July 2023 (UTC)Reply[reply]
{{R from modification}} or {{R from alternative punctuation}} could be used if something more specific isn't created. Anomie 13:09, 8 July 2023 (UTC)Reply[reply]
I remember a discussion about issues with trailing parenthesis causing issues in some locations; I can't remember where it was, but the result was against the creation of redirects. BilledMammal (talk) 14:26, 8 July 2023 (UTC)Reply[reply]
Here's a similar case: the wikilink Westward Ho! goes to the town in Devon, England; but if you use the full URL instead, the MediaWiki parser doesn't recognise the terminal bang as part of the URL unless you percent-encode it - compare https://en.wikipedia.org/wiki/Westward_Ho! (which goes to a dab page) with https://en.wikipedia.org/wiki/Westward_Ho%21 (which works as intended). This shows that the terminal period isn't the only punctuation that is affected. --Redrose64 🌹 (talk) 09:38, 8 July 2023 (UTC)Reply[reply]
Correct. Another character that would be a problem in this case, is the space character. This is because URLs require percent encoding to have all the information. But because encoding is hard to read, browsers started hiding the encoding (Mediawiki realized the same early on actually and replaced spaces with underscores to improve readability). Especially when you copy paste an unencoded url into other applications that then do URL detection, this becomes problematic. There is not enough information being preserved, so you have to guess and guessing inherently allows for guessing wrong when it comes to edge cases. —TheDJ (talkcontribs) 11:14, 8 July 2023 (UTC)Reply[reply]
We don't have article titles ending in a space, do we? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:13, 8 July 2023 (UTC)Reply[reply]
No, MediaWiki doesn't allow that, even to the point that links such as e.g. https://en.wikipedia.org/wiki/Foobar_ or https://en.wikipedia.org/wiki/Foobar%20 go to Foobar. Anomie 13:57, 8 July 2023 (UTC)Reply[reply]
Looking at both the classic parser and parsoid, MediaWiki's own logic drops any of ,;.:!? from the end of a URL, and also ) if the URL doesn't contain an (. Other services may, of course, behave differently. If we go with MediaWiki's list, it appears there are currently 125010 mainspace redirects (list) that would need to be created, 23668 of which (list) would point directly to articles and 101342 would bypass a double redirect. Whether any other namespaces should be processed is a good question. And while WP:MASSCREATION applies more to actual articles than redirects, as a BAGger I'd still want to see a WP:VPR discussion showing consensus for the creation of these redirects.
P.S. If we want to go ahead with this, it might be worth asking me to adapt AnomieBOT's EnDashRedirectCreator code that already handles various issues like double redirects, conflicts in possible targets, automatic G8 tagging if the target is deleted, and so on. Anomie 13:09, 8 July 2023 (UTC)Reply[reply]
Rather than stating a duplicate discussion, I have posted a pointer to this one, on VPR. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:21, 8 July 2023 (UTC)Reply[reply]

Test links[edit]

For convenience, I have created:

If anyone sees the need for similar links for other characters, feel free to continue the series in my userspace. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:29, 8 July 2023 (UTC)Reply[reply]

Discussion (Redirects for article titles ending in periods)[edit]

Math markup doesn't work[edit]

While reading, I came across some math markup that doesn't display properly. Here's the markup at WP:MATH: <math>E=mc^2</math>, , but it displays as E=mc^{2}, with the broken image icon above it. I am using Google Chrome 103 on El Capitan. – dudhhr talk contribs (he/they) 05:58, 8 July 2023 (UTC)Reply[reply]

Is "Math" in Preferences -> Appearance set to "SVG"? Nardog (talk) 07:11, 8 July 2023 (UTC)Reply[reply]
Yes. Math markup displays properly on my iPad (iOS 12, Safari whatever version), and on my MacBook Pro (High Sierra) and Windows 10 PC; both of those use the latest release of Firefox. – dudhhr talk contribs (he/they) 07:22, 8 July 2023 (UTC)Reply[reply]
Seems like what you see is an alt of the SVG image. You might want to clear cache in that Chrome. Or just use Firefox :) Nux (talk) 13:40, 8 July 2023 (UTC)Reply[reply]
I think it might be a certificate issue: Wikipedia, Commons, and upload.wikimedia.org gave warnings for invalid certificates, but I'm not sure what domain the math markup images use. Probably just an issue that comes with using an old OS version, iOS 9 has the same problem. – dudhhr talk contribs (he/they) 21:13, 8 July 2023 (UTC)Reply[reply]
The image is here [1] if that shows a warning then that is the problem. Apple is using vendor locking on iPhones so I don't think you can work this out without changing your phone (installing Firefox probably won't make a difference). Nux (talk) 21:26, 8 July 2023 (UTC)Reply[reply]
The problem is more important on my El Capitan iMac (it's from 2007!) than my iOS 9 iPad (I have a newer iPad), but yes tha was the issue. I told the browser to ignore the invalid certificate and it displays now. – dudhhr talk contribs (he/they) 22:00, 8 July 2023 (UTC)Reply[reply]

Expanding and hiding of dropdown menus cause no change in their indicator symbol[edit]

Hi, at the top menu of Wikipedia there exists dropdown menus named "tools" and "languages" and "TW". These menus are by default at the state of "hidden" and have the symbol "˅". But after clicking on these words, the dropdown menus's state changes to "expanded". The problem is that their indicator symbol should change to "˄", but this scenario is not applied, and the symbol does not change and remains "˅". This changing of symbol to "˄" is necessary to indicate dropdown menu's state is "expanded" and a click on it causes a "hide" action. This scenario is nearly always applied in MS Windows's dropdown menus. Hooman Mallahzadeh (talk) 13:31, 8 July 2023 (UTC)Reply[reply]

From a UI standpoint, yeah obviously this should've been the case, but I've never faced a functional problem due to it, so it might not be that much of a priority than some other very pressing issues. CX Zoom[he/him] (let's talk • {CX}) 15:38, 8 July 2023 (UTC)Reply[reply]
I'm not sure why our UI should follow Windows UI design standards ? There is no need to change the icon to indicate state change. The dropping down of the menu is already indicating the state change. —TheDJ (talkcontribs) 09:34, 10 July 2023 (UTC)Reply[reply]
@TheDJ The purpose of changing of such symbols is not for "showing the menu's state", instead it is for indicating the correct "action" of this symbol. The symbol "˅" indicates "expand the menu" and the symbol "˄" indicates "hide the menu". Hooman Mallahzadeh (talk) 09:54, 10 July 2023 (UTC)Reply[reply]
You may raise this issue at mw:Talk:Reading/Web/Desktop Improvements if you want to. CX Zoom[he/him] (let's talk • {CX}) 11:38, 10 July 2023 (UTC)Reply[reply]
@CX Zoom Thanks, I raised the issue there. — Preceding unsigned comment added by Hooman Mallahzadeh (talkcontribs) 11:55, 10 July 2023 (UTC)Reply[reply]

Help with the longstanding "®exp_filter" PetScan bug[edit]

Sometimes WP:PetScan adds ®exp_filter into text fields after you hit the "Do it!" button. Those "®exp_filter"'s break the search. User:Certes explained the issue:

PetScan accepts a URL parameter called regexp_filter. "Link to a pre-filled form..." inserts &regexp_filter=value into the URL it generates. (value is usually blank.) This works perfectly when the link is clicked. However, such links are often pasted into wikitext or HTML. Some browsers interpret the string "&reg" as an HTML entity for the registered trademark symbol, even when not followed by a semicolon, so &foo=bar&regexp_filter= becomes &foo=bar®exp_filter=, appending the unwanted text to the preceding parameter and usually causing it to make an unwanted appearance in one of the input boxes.

And they added:

Could we change the parameter name to something that doesn't begin with reg? Of course, regexp_filter= should also be accepted for backwards compatibility, but if a replacement parameter name not beginning with reg can be offered in "Link to a pre-filled form" then the problem should be solved.

Other discussions about this longstanding annoying bug:

This page is very active, so maybe someone here knows how to fix this? I believe this is a bigger issue than it looks, because many people who use PetScan don't notice ®exp_filter in text fields that break their PetScan searches, so people just assume that the search simply just didn't find anything. So, next time when your PetScan search doesn't give any results, check the text fields if there's a ®exp_filter. 2001:14BA:9C35:6600:193F:16A0:BF8A:43A1 (talk) 19:33, 8 July 2023 (UTC)Reply[reply]

The image on this page was inserted strangely; the problem is that the caption is, as usual, in the centre, while the image is on the left (opening the page from a mobile phone). JackkBrown (talk) 21:52, 9 July 2023 (UTC)Reply[reply]

As far as I can tell, removing
<div class="floatnone">
from the expanded output of {{CSS image crop}} appears to allow the image to stay in the center on mobile. That's as far as I got, though, and I could be going down the wrong path. – Jonesey95 (talk) 22:12, 9 July 2023 (UTC)Reply[reply]
This is affected by changes in the default CSS and structure changes in images. In any case probably using built in classes for this template is not a good idea. Instead of floatnone etc the template should use its own classes and a templatestyles CSS. At this point in time it would probably be best and easiest to do the layout with display:flex. Nux (talk) 00:05, 10 July 2023 (UTC)Reply[reply]
@Jonesey95: @Nux: I directly removed the image (by the way, I found that the image was cropped; there are other people in the original image); I edited quickly, I hope I didn't damage the infobox. JackkBrown (talk) 00:35, 10 July 2023 (UTC)Reply[reply]

When I open the page, I find an error message saying that "Lua error in Module:User_scripts_table at line 22: attempt to index local 'jsContent' (a nil value)." It looks like a big red link, and when I click on it, it shows:

Lua error in Module:User_scripts_table at line 22: attempt to index local 'jsContent' (a nil value).

Backtrace:

  1. Module:User_scripts_table:22: in function "chunk"
  2. mw.lua:527: ?
  3. [C]: ?

A huge table with rankings of user scripts should be expected. The person who loves reading (talk) 03:23, 10 July 2023 (UTC)Reply[reply]

Fixed. Nardog (talk) 03:25, 10 July 2023 (UTC)Reply[reply]
Thanks! The person who loves reading (talk) 03:31, 10 July 2023 (UTC)Reply[reply]

Trace categories of an article[edit]

Is there a tool that shows the path how an article is part of a category much higher in the tree than the first-levels categories of that article? Example: I'm trying to address CS1 errors for classical music and opera articles. I'm baffled by PetScan results that shows that the article Electrothermal-chemical technology is member of Category:CS1 errors and Category:Opera (here) as well as Category:Classical music (here). How do those categories become (far removed) parents of that article? -- Michael Bednarek (talk) 05:55, 10 July 2023 (UTC)Reply[reply]

I haven't been able to find a good tool, but I was able to find, using Special:CategoryTree and some educated guessing/randomly clicking, the following sequence of parent categories: Electrothermal-chemical technology -> Category:Propellants -> Category:Pyrotechnics -> Category:Special effects -> Category:Stagecraft -> Category:Opera -> Category:Classical music. I hope this helps! --rchard2scout (talk) 08:30, 10 July 2023 (UTC)Reply[reply]
I think someone may be able to write a query for this. Yesterday Cryptic wrote a query for me that shows the category path in the result table see quarry:query/75085. You may talk to him directly, or ask at WP:RAQ. CX Zoom[he/him] (let's talk • {CX}) 09:12, 10 July 2023 (UTC)Reply[reply]
I've simplified that query to quarry:query/75121. Feel free to fork and reuse it, you only have to change the basecat in the first line and the page title in the last line. --rchard2scout (talk) 09:51, 10 July 2023 (UTC)Reply[reply]
Thank you both for your assistance. It's very much appreciated, and I made a note of this tool and your code, although I admit it's above my pay grade, but thank you for showing it so clearly. I'm still baffled by the subtle ways Wikipedia's category system works. -- Michael Bednarek (talk) 12:06, 10 July 2023 (UTC)Reply[reply]

Live side preview window[edit]

Often times we come here to bitch and moan about stuff not working.

Well this time, I want to throw my hat to whoever came up with that idea and coded it. It works very well, and is extremely useful!

The da Vinci Barnstar
If you were involved with this, give yourself this barnstar. Remember to subst it or something. Headbomb {t · c · p · b} 14:12, 10 July 2023 (UTC)Reply[reply]

Headbomb {t · c · p · b} 14:12, 10 July 2023 (UTC)Reply[reply]

@Samwilson, MusikAnimal, and TheresNoTime. Nardog (talk) 14:35, 10 July 2023 (UTC)Reply[reply]
Thank you!! :) All of the Community Tech team should get credit here, but also to @Czar and all of the voters and participants in the 2021 wishlist proposal, and finally and perhaps most importantly @TheDJ who wrote the original user script that inspired the proposal and project as whole! :) All of you should feel entitled to advertise this barnstar in your userspace if you wish. I will refrain as this was in a work capacity for me. Warm regards to all, MusikAnimal talk 17:01, 10 July 2023 (UTC)Reply[reply]
@MusikAnimal: I'm giving you full permission to give yourself that barnstar (alongside whichever boss made you work on this). Because in the past, even if stuff ended on the wishlist, they were often not worked on. Or they rolled out half assedly.
This thing just seems to work and not interfere with anything else. Which is... unusual for a tool was rolled out en masse, which changes the editing experience so radically. Headbomb {t · c · p · b} 21:47, 10 July 2023 (UTC)Reply[reply]
@Headbomb: I'm so glad to hear this! Thanks for using it, and thanks for your nice words. :-) The thing I was most worried about was changing the default height-resizer, because that appears all the time even without the preview pane being open. All seems okay though. :-) Sam Wilson 01:35, 11 July 2023 (UTC)Reply[reply]

Tech News: 2023-28[edit]

MediaWiki message delivery 19:51, 10 July 2023 (UTC)Reply[reply]

How do I request deletion of a recently created template?[edit]

HI, I ran into this new template Template:Stop AAPI Hate. I believe this has been created in error. The topic should be Stop Asian Hate not Stop AAPI Hate (which is a non-profit mostly gathering data) and I am not sure the subject needs a template. And I find it alarming that the "Groups associated with opposition" is there at all. When I try to google or search for "Wikipedia delete template" I get sent to pages about templates for deleting everything but templates. I'm sure the problem is between the chair and the keyboard, so I am coming here for some assistance. Could someone point me in the right direction? Thanks! WomenArtistUpdates (talk) 23:09, 10 July 2023 (UTC)Reply[reply]

The venue you are looking for is Wikipedia:Templates for discussion. * Pppery * it has begun... 23:20, 10 July 2023 (UTC)Reply[reply]
Thanks Pppery! I'll start with a ping from the template's talk page and then move on to "Templates for discussion". Best, WomenArtistUpdates (talk) 00:00, 11 July 2023 (UTC)Reply[reply]