Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia
 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

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

Tech News: 2024-21[edit]

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

Recent changes

  • The Nuke feature, which enables administrators to mass delete pages, will now correctly delete pages which were moved to another title. [1]
  • New changes have been made to the UploadWizard in Wikimedia Commons: the overall layout has been improved, by following new styling and spacing for the form and its fields; the headers and helper text for each of the fields was changed; the Caption field is now a required field, and there is an option for users to copy their caption into the media description. [2][3]

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 21 May. It will be on non-Wikipedia wikis and some Wikipedias from 22 May. It will be on all wikis from 23 May (calendar). [4][5]
  • The HTML used to render all headings is being changed to improve accessibility. It will change on 22 May in some skins (Timeless, Modern, CologneBlue, Nostalgia, and Monobook). Please test gadgets on your wiki on these skins and report any related problems so that they can be resolved before this change is made in all other skins. The developers are also considering the introduction of a Gadget API for adding buttons to section titles if that would be helpful to tool creators, and would appreciate any input you have on that.

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

MediaWiki message delivery 23:01, 20 May 2024 (UTC)[reply]

Based on a quick search, it looks like the heading change will affect almost 300 scripts, many of which have inactive maintainers. Some arbitrary highlights from the top of the list include:
Plus many, many more. --Ahecht (TALK
PAGE) 19:22, 21 May 2024 (UTC)[reply]
A quick way to test these scripts right now, is to enable the Parsoid beta option (which already uses the new html structure) and to disable DiscussionTools, which uses a partial form of the new heading structure. —TheDJ (talk • contribs) 08:39, 22 May 2024 (UTC)[reply]
Indeed, you can already see it in Parsoid mode (but note that there are other differences – e.g. Parsoid output has <section> tags around each section, which may require a separate set of updates in some scripts).
Disabling DiscussionTools doesn't actually change anything though. The HTML structure is the same whether it's enabled or disabled, only the styles are different. Also, note that it uses a "hybrid" heading structure currently when using the default parser, as you say, but it uses the new structure when using Parsoid.
So in short, you can just use Parsoid mode to test these scripts today here on English Wikipedia, but beware that there may be extra issues. But if they work with Parsoid, they will work with the new headings too. Matma Rex talk 11:25, 22 May 2024 (UTC)[reply]
The technical 13 script was blanked, so we don't have to worry about that one.
Will the fact that they're rolling this out for only some wikimedia-deployed skins at this time make the patch more complicated? If I'm reading it right, the scripts may temporarily have to support both heading styles. –Novem Linguae (talk) 09:16, 22 May 2024 (UTC)[reply]
Yes, it does, and they have to. Matma Rex talk 11:20, 22 May 2024 (UTC)[reply]
At a glance, it seems that User:Mr. Stradivarius/gadgets/SignpostTagger.js already supports the new style, as it uses $( '#bodyContent h2:first' ).text() as a backup if $( '#bodyContent h2:first span.mw-headline' ) doesn't exist (line 291). — Mr. Stradivarius ♪ talk ♪ 13:09, 22 May 2024 (UTC)[reply]
Fixed RFUD-helper. Thanks for the ping. – SD0001 (talk) 18:33, 22 May 2024 (UTC)[reply]
This is going to break both my edit request scripts, I will try to fix them at the weekend. Terasail[✉️] 18:41, 22 May 2024 (UTC)[reply]
I'm assuming ~ and feel free to correct me if i'm wrong ~ that something about this deployment is why headings no longer have numbers (for me)? Will it be possible to go back to that at some point? I find long pages almost impossible to navigate around without numbered headings, so will have to learn a new way of working if it won't be possible. Thanks, Happy days, ~ LindsayHello 16:24, 27 May 2024 (UTC)[reply]
@LindsayH: No, that was removed a while ago. You may try the "Auto-number headings" gadget here. Nardog (talk) 19:31, 27 May 2024 (UTC)[reply]
If you're speaking about the table of contents, Vector 22 does not provide numbering. Vector, Monobook, and Modern do.
If you are speaking about each actual heading, then indeed the preference is gone and indeed there is a gadget for it now. You have correctly identified that gadget as needing to be updated for this change. It looks like the necessary change to the snippet (documentation) has already been made, so someone needs to port that here. Izno (talk) 19:59, 27 May 2024 (UTC)[reply]
Thank you, Izno, helpful. I'd assumed it was a script/gadget, as so many appeared to be affected above. I shall patiently wait in hope Happy days, ~ LindsayHello 11:51, 28 May 2024 (UTC)[reply]

Sorting titles, some with appended text[edit]

Hello, regarding List of cult films: K, it seems like the listings The Killer and The Killing, both which neighbor listings that have longer titles starting with Killer or Killing, wind up at the bottom of each respective group when sorting alphabetically, when they should come first, having nothing after that keyword. Am I doing something wrong? Is there a way to fix it? See for yourself here. EDIT: I guess I fixed it by adding two spaces after each title, but this feels like too much of a hack. Is there a proper way to do this? Erik (talk | contrib) (ping me) 15:58, 23 May 2024 (UTC)[reply]

It probably should be using {{sort}} rather than {{sortname}}. The latter makes the sort key "Killer, The" because it is intended to be used with the name of a person. Johnuniq (talk) 00:43, 24 May 2024 (UTC)[reply]
@Erik: The problem is that {{sortname}} automatically inserts a comma. {{sortname|The|Killer}} is sorted as "Killer, The". The comma sorts after the space in "Killer Nun" while the title should logically have been sorted before. In [6] you avoided the issue by placing spaces at the end in {{sortname|The|Killer }} so it sorts as "Killer  , The". It works in the current implementation where spaces aren't stripped but it's not a pretty solution and other editors can easily remove the spaces without knowing the consequence. You could use optional sort key in {{sortname}} to give "Killer" as the full sort key with no comma or "The". Should {{sortname}} be changed to omit the automatic comma? Probably not. It's mostly used for people and often mixed with manually written sort keys like "Doe, John". Omitting the comma when the template is used would mess that up. PrimeHunter (talk) 20:03, 24 May 2024 (UTC)[reply]
Omitting the automatic comma wouldn't even fix this case where "Killer The" would still sort after "Killer Nun". A possibility would be for {{sortname}} to add a special case where {{sortname|The|Anything}} ignores "The" and just sorts as "Anything". "The" is unlikely to be the first name of a person which should be included in the sort key. PrimeHunter (talk) 20:17, 24 May 2024 (UTC)[reply]
But it's not a natural person's name right  ? So why use sortname to being with ? —TheDJ (talk • contribs) 22:07, 24 May 2024 (UTC)[reply]
sortname is often used on "The", probably because it's well-known and convenient: hastemplate:sortname insource:"sortname The". I don't know how often it gives poor sorting but it's probably rare that the sorted items are close enough. PrimeHunter (talk) 22:33, 24 May 2024 (UTC)[reply]
I used explicit sort keys including a third problem entry The King.[7] PrimeHunter (talk) 09:48, 25 May 2024 (UTC)[reply]
Thank you! I will use this approach instead. Is there an easy way to identify problems like The King? On my laptop, I was just eyeballing the difference between the order in the code and the sorted order, but The King was too far down for me to see shift in order. Would like to be able to check all the pages and fix the order and sorting where needed. Erik (talk | contrib) (ping me) 00:03, 27 May 2024 (UTC)[reply]
I haven't done it before but here are three ideas which all require something:
  1. Zoom far out (Ctrl+- in Windows browsers) to view more rows at the same time.
  2. Use the sort arrow on a previewed version where the first rows have been removed or commented out.
  3. Copy-paste the sorted and unsorted rendered table with your browser and make a diff with some tool, e.g. someting at Google:online diff.
I tested it and spotted The Kingdom with all three. PrimeHunter (talk) 00:25, 27 May 2024 (UTC)[reply]

Template-generated category problems[edit]

The latest run of Special:WantedCategories features a weird cluster of "Decade in nothing" redlinks that are being autogenerated by {{Sport clubs (dis)established in the YYY0s category header}} because the template appears to be failing to import a variable. The template itself does not appear to have been recently edited at all, so it's very likely a module doing this, but as I don't have module-editing privileges I wouldn't be able to fix it myself even if I could find the issue, so the following categories are going to need somebody else to look into them.

Category:1810s in, Category:1820s in, Category:1830s in, Category:1840s in, Category:1850s in, Category:1860s in, Category:1870s in, Category:1880s in, Category:1890s in, Category:1900s in, Category:1910s in, Category:1920s in, Category:1930s in, Category:1940s in, Category:1950s in, Category:1950s in, Category:1960s in, Category:1970s in, Category:1980s in, Category:1990s in, Category:2000s in, Category:2010s in, Category:2020s in.

Thanks. Bearcat (talk) 13:46, 25 May 2024 (UTC)[reply]

There was a recent edit Special:Diff/1225161437 in the /core subtemplate, which doesn't seem suspicious.  Checking... in the sandbox using the special debugging parameter |diagnose=yes. —⁠andrybak (talk) 14:03, 25 May 2024 (UTC)[reply]
 Fixed in Special:Diff/1225599206. —⁠andrybak (talk) 14:14, 25 May 2024 (UTC)[reply]
@Gonnym, I think I figured out the root cause. In Special:Diff/1225161437, the pipe | was incorrectly left in the usages of {{lcfirstletter}}. That is, {{lcfirst:|{{{sport}}}}} instead of {{lcfirst:{{{sport}}}}}. Feel free to re-implement the switch back to magic words, I don't think this template relies on special features of templates {{ucfirstletter}} and {{lcfirstletter}} for skipping non-letter characters. —⁠andrybak (talk) 14:21, 25 May 2024 (UTC)[reply]
Thanks andrybak, sorry I missed the pipe and thanks for catching that! Gonnym (talk) 07:58, 27 May 2024 (UTC)[reply]

Help with regex[edit]

I'm looking to search for article with titles matching '[number][ordinal][space]Road', but for all my trying I can't get it to work. I get intitle and using []{} for a certain number of character but whatever I put together doesn't work. Any help would be appreciated. -- LCU ActivelyDisinterested «@» °∆t° 17:40, 25 May 2024 (UTC)[reply]

What is your specific search query? Izno (talk) 17:56, 25 May 2024 (UTC)[reply]
I don't a working one, I was trying "in title:/[0-9]{1,3}[a-z]{2} Road/ but I've obviously got something wrong. I'm looking to find pages such as 30th Road, 73rd Road, etc. -- LCU ActivelyDisinterested «@» °∆t° 18:01, 25 May 2024 (UTC)[reply]
I wasn't looking for a working one. :) You've misspelled intitle as in title, this query works. Izno (talk) 18:06, 25 May 2024 (UTC)[reply]
That's autocorrect it does the same for me with hastemplate becoming 'has template'. I'm apparently cursed when it comes to regex, I'd swear I had tried the exact same search. Thanks for the help. -- LCU ActivelyDisinterested «@» °∆t° 18:22, 25 May 2024 (UTC)[reply]

My brain hurts[edit]

I started to answer the question above, but quickly ran into something I don't understand. Regex searches ignore the indexes, so it makes sense to do a composite search which includes a term that hits the index and then a regex to filter that down. But when I try intitle:Road intitle:/[0-9]+/ (link) I get results that include London Inner Ring Road. That doesn't match the regex. H:BOOLEAN says Search terms are implicitly joined by AND but that doesn't seem to be what's happening here. RoySmith (talk) 15:20, 26 May 2024 (UTC)[reply]

intitle: often appears not to work. In this case, it's probably showing that result because of redirects such as A1202 road. Certes (talk) 15:27, 26 May 2024 (UTC)[reply]

Weird mobile web diff display[edit]

[8]

Normally, mobile (source, not visual) diff displays removed text in yellow and added text in blue in the same block of text. In this said diff, the edited paragraph is (confusingly) displayed twice, one copy indicating removed text, the other one added text. Could you reproduce this? Is this a bug or intended behavior? Thank you. Janhrach (talk) 07:52, 26 May 2024 (UTC)[reply]

Are you trying to use the mobilefrontend view with vector-2022, leading you to getting the desktop-type vector-2022 output? — xaosflux Talk 12:12, 26 May 2024 (UTC)[reply]
Huh? That diff is indeed what you get via https://en.m.wikipedia.org/w/index.php?title=Clan_Livingstone&action=history. I agree the repetition of "This battle was fought..." is highly misleading. Nardog (talk) 15:24, 26 May 2024 (UTC)[reply]
I filed a task for this at the tail end of the better diffs initiative last year. phab:T349335. Izno (talk) 16:28, 26 May 2024 (UTC)[reply]
Is that the same thing? That task doesn't seem to be about mobilefront end view? Here is the mobilefrontend+minerva (what should be default) view of the story in this thread: https://en.m.wikipedia.org/w/index.php?title=Clan_Livingstone&diff=prev&diffonly=1&oldid=1225714396&useskin=minerva . Is that not appearing as expected? — xaosflux Talk 16:18, 27 May 2024 (UTC)[reply]
@Xaosflux, mobile diffs now use the same machinery as normal diffs. And no, it is not appearing as expected, the paragraph beginning with This battle was fought between various north-western highland clans from the lands of Ross, against the Earl of Ross and his followers. is repeated. Izno (talk) 16:20, 27 May 2024 (UTC)[reply]
Thanks, see it now, yup seems buggy for sure. — xaosflux Talk 16:24, 27 May 2024 (UTC)[reply]
It's worth saying that this is a hard problem in general. You'd probably need to look at the code to see what's going on, but it's likely that the diff treats headings as special, then trying to identify the two paragraphs as derivatives may not be easy. All the best: Rich Farmbrough 18:53, 27 May 2024 (UTC).[reply]

New diff preview problem[edit]

This started sometime between midnight UTC last night and 10:30 UTC today, Monday 27 May. I use Edge on Win 11, Monobook, Navigation popups enabled, and the Use a black background with green text gadget. When I point my mouse at "diff" on my watchlist now the pop up/preview/whatever you call it is now very much harder to read, the change is "highlighted" by shewing the removed text in black on a grey background then the added text in black on a brown background. Please help! DuncanHill (talk) 11:09, 27 May 2024 (UTC)[reply]

@The wub? Izno (talk) 15:47, 27 May 2024 (UTC)[reply]
@DuncanHill This is an unintended side effect of a change I made so that Navigation popups work in the new Vector dark mode. I've revised that change so it shouldn't affect the black background with green text gadget, will see about getting it merged. the wub "?!" 21:33, 27 May 2024 (UTC)[reply]
@The wub: thanks so it should be more legible soon? DuncanHill (talk) 21:50, 27 May 2024 (UTC)[reply]
@DuncanHill Yes, just waiting for an interface admin to respond to my edit request. the wub "?!" 23:08, 27 May 2024 (UTC)[reply]
@The wub: Thank you, now working well for me. DuncanHill (talk) 01:36, 28 May 2024 (UTC)[reply]

Images in sidebars for mobile view[edit]

Hi. I have been fixing up climbing articles on Wikipedia (e.g. alpine climbing, mixed climbing, and ice climbing). I know that per 'Template:Sidebar', that the sidebar doesn't appear on mobile (which makes sense to me), but is there any way for the main image used in the top section of the sidebar to appear in mobile view (i.e. a qualifier in the sidebar image to say whether it should appear in mobile view)? The images that I have put into the top of the sidebar are good ones and have helpful captions that I think a mobile reader would enjoy? thanks. Aszx5000 (talk) 11:33, 27 May 2024 (UTC)[reply]

Do not use sidebars to provide meaningful images, is really the correct response, and in fact at some point they will not be available at all (somewhere in my backlog of work). If you want an image to display, you should use either a thumb image or an infobox, and of course both must fit the requirements for the main image. Izno (talk) 15:47, 27 May 2024 (UTC)[reply]

Why has my map broken?[edit]

Hi all

I spent ages building a map to help visualise the countries where WikiGap has been organised (a project to help close the gender gap on Wikipedia). The map was transcluded at the bottom of the main Wikigap page however it seems to be broken, no map is shown, the transcluded page doesn't appear to have been changed so I think it might be a technical change somewhere? If anyone knows how to fix it, please I'd love some help, its way beyond my technical ability.


John Cummings (talk) 18:55, 27 May 2024 (UTC)[reply]

It appears primary support for the underlying module there is provided at: w:de:Wikipedia Diskussion:Lua/Modul/Graph. — xaosflux Talk 19:19, 27 May 2024 (UTC)[reply]
meta:WikiGap/Map is in the hidden meta:Category:Pages with disabled graphs. It uses meta:Template:Graph:Map which makes <graph>...</graph> code. All such code in Wikimedia wikis has been disabled since April 2023. The English Wikipedia gives more helpful information from MediaWiki:Graph-disabled when a page tries to use <graph>...</graph>:
meta:MediaWiki:Graph-disabled has not been created so no message is displayed there. Affected pages are just added to the hidden category. Our own Category:Pages with disabled graphs is also more helpful. PrimeHunter (talk) 20:15, 27 May 2024 (UTC)[reply]

Thanks as ever PrimeHunter, ah, that's a shame, well I guess its just permanently broken and it will be some time until a replacement is made, I wonder if I can do it through Kartographer or something. John Cummings (talk) 20:57, 27 May 2024 (UTC)[reply]

WMF will start working on the graph extension in July, see Mw:Extension:Graph/Plans. Until then use Kartographer, there are templates that use it. Snævar (talk) 21:32, 27 May 2024 (UTC)[reply]

Tech News: 2024-22[edit]

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

Recent changes

  • Several bugs related to the latest updates to the UploadWizard on Wikimedia Commons have been fixed. For more information, see T365107 and T365119.
  • In March 2024 a new addPortlet API was added to allow gadgets to create new portlets (menus) in the skin. In certain skins this can be used to create dropdowns. Gadget developers are invited to try it and give feedback.
  • Some CSS in the Minerva skin has been removed to enable easier community configuration. Interface editors should check the rendering on mobile devices for aspects related to the classes: .collapsible, .multicol, .reflist, .coordinates, .topicon. Further details are available on replacement CSS if it is needed.

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 28 May. It will be on non-Wikipedia wikis and some Wikipedias from 29 May. It will be on all wikis from 30 May (calendar). [9][10]
  • When you visit a wiki where you don't yet have a local account, local rules such as edit filters can sometimes prevent your account from being created. Starting this week, MediaWiki takes your global rights into account when evaluating whether you can override such local rules. [11]

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

MediaWiki message delivery 00:12, 28 May 2024 (UTC)[reply]

Relocate mobile/desktop button[edit]

I would like to relocate the mobile view/desktop button to the top of the page (preferably, next to talk or in same line with the page title in the far right corner) for ease of access instead of having to scroll to the bottom each time to switch between mobile and desktop mode. Can this be done? Qwerty284651 (talk) 00:18, 28 May 2024 (UTC)[reply]

@Qwerty284651: I don't think that it can be relocated without a MediaWiki change, for which see WP:BUGS (it's worth noting that the Cologne Blue desktop skin already has the "Mobile view" link near the upper right, see e.g. VPT under Cologne Blue). But I'm pretty sure that somebody (not myself) can write some Javascript that will create an additional link in the desired place (the actual Javascript will need to be varied according to the skin). Once it's in place, you can then either leave the existing link alone, or hide it with some CSS: 
/* (i) hide the "Mobile view" link when in desktop; (ii) hide the "Desktop" link when in mobile view */
ul#footer-info li#footer-places-mobileview,
ul#f-list li#mobileview,
ul#footer-places li#footer-places-mobileview,
ul#footer-places li#footer-places-desktop-toggle {
  display: none;
}
This goes in your CSS, as it's skin-universal - the first two selectors are for Modern and MonoBook respectively, the third is for all other current skins, the fourth is for mobile.
Don't activate it until the replacement link has been set up, otherwise you will lose the ability to toggle the views. --Redrose64 🌹 (talk) 09:56, 28 May 2024 (UTC)[reply]
@Redrose64, looking at the Cologne Blue skin, I see the whole bottom section (languages, last modified, cats, other links) of the page was moved to the top.
Where can I find the CSS and JS pages for the Cologne Blue skin or any skin currently available, for that matter?
I can always undo the addition in my common.css page if I activate it before link setup. Qwerty284651 (talk) 14:11, 28 May 2024 (UTC)[reply]
If you always want to use the desktop view on mobile see User:Þjarkur/NeverUseMobileVersion. -- LCU ActivelyDisinterested «@» °∆t° 10:16, 28 May 2024 (UTC)[reply]
@ActivelyDisinterested, appreciate the proposal. I recently started using mobile version on mobile, mostly have been on desktop before. Qwerty284651 (talk) 14:00, 28 May 2024 (UTC)[reply]
I've always edited on mobile using the desktop site, the script saves me a lot of wasted time. -- LCU ActivelyDisinterested «@» °∆t° 14:04, 28 May 2024 (UTC)[reply]
Same here. I only use the mobile version for editing tables in VE, although it can be finicky when switching between selecting cells and editing them. Qwerty284651 (talk) 14:20, 28 May 2024 (UTC)[reply]

Bug in table creation[edit]

If I insert a new column with the GUI by clicking "insert before" on a column with colors in them, it breaks the columns.

See here for an example

https://en.wikipedia.org/w/index.php?title=Llama_(language_model)&diff=prev&oldid=1226056830 pony in a strange land (talk) 09:19, 28 May 2024 (UTC)[reply]

Some VisualEditor features don't work with cell formatting templates which add a pipe as part of the table syntax. The code said | rowspan="3" {{yes}}. VisualEditor thinks the cell content is rowspan="3" {{yes}}, but {{yes}} adds both cell attributes and a pipe which separates them from the actual cell content yes. It produces: style="background:#9EFF9E;vertical-align:middle;text-align:center;" class="table-yes"|Yes. You just have to use the source editor for some things. PrimeHunter (talk) 11:27, 28 May 2024 (UTC)[reply]

The obsolete nowrap attribute[edit]

See this edit and User talk:Awesometd#nowrap. The nowrap attribute on a td element, already deprecated in HTML 4 (December 1997), was marked as obsolete in HTML 5 (October 2014). The user says that they are copying its use from other pages, so does anybody know where in Wikipedia such usage is recommended or even suggested? --Redrose64 🌹 (talk) 10:30, 28 May 2024 (UTC)[reply]

I doubt it's suggested anywhere. A few cases may have been added long ago and some users just copy what they saw in other articles. The user is right that it's used in 2024 F1 season. Unsurprisingly it's also in previous seasons. It's common to start such pages with a copy-paste from another season. PrimeHunter (talk) 11:16, 28 May 2024 (UTC)[reply]
At a first estimation there are about 10k uses of it; I'm sure someone can refine that. Izno (talk) 15:26, 28 May 2024 (UTC)[reply]
There's many more obsolete attributes still being used in tables, such as align or bgcolor. If we truly want to get rid of them, the solution would probably be to extend the Linter extension, so that they'll be listed at Special:LintErrors. That's probably a discussion to be had over at WT:LINT. --rchard2scout (talk) 07:56, 29 May 2024 (UTC)[reply]

Mobile view Swiss flag[edit]

There is a bit of an issue on mobile view in when this template: "  Switzerland" (or its variants) is used, the flag will appear stretched horizontally. Also, it’s to be noted this template: "Switzerland" does not have this issue. —TwinBoo (talk) 11:35, 28 May 2024 (UTC)[reply]

File:Flag of Switzerland (Pantone).svg is square. MediaWiki:Minerva.css says:
.flagicon img {
	min-width: 23px;
}
{{flag|Switzerland}} produces:
<span class="flagicon">[[File:Flag of Switzerland (Pantone).svg|23x16px|border |alt=|link=]]  </span>[[Switzerland|Switzerland]]
I reduced the problem to the combination of flagicon and an empty link=. I only see the mobile issue in the first row below.
Code Result Mobile display size
<span class="flagicon">[[File:Flag of Switzerland (Pantone).svg|23x16px|link=]]</span> 23x16px
<span class="flagicon">[[File:Flag of Switzerland (Pantone).svg|23x16px|link=Switzerland]]</span> 23x23px
<span class="flagicon">[[File:Flag of Switzerland (Pantone).svg|23x16px]]</span> 23x23px
[[File:Flag of Switzerland (Pantone).svg|23x16px|link=]] 16x16px
<span class="flagicon">[[File:Flag of Switzerland (Pantone).svg|23px|link=]]</span> 23x23px
They all display the 16×16px https://upload.wikimedia.org/wikipedia/commons/thumb/0/08/Flag_of_Switzerland_%28Pantone%29.svg/16px-Flag_of_Switzerland_%28Pantone%29.svg.png. The mobile stretching just varies. PrimeHunter (talk) 12:16, 28 May 2024 (UTC)[reply]
The minimum width of a flag on mobile is 23px, because without a minimum width, flag icons risk going to 0x0 inside tables and other common elements when on mobile, due to lack of available width. —TheDJ (talk • contribs) 05:45, 29 May 2024 (UTC)[reply]
But can we make it keep the correct width-height ratio in all circumstances? I added a table row only saying 23px instead of 23×16px, but othwerwise identical to the distorted first row. This displays correctly for me as 23×23px in mobile. It apparently takes three things simultaneously to be distorted in mobile: flagicon, wikitext specifying both height and width, and an empty link= which omits a link on the image. PrimeHunter (talk) 11:49, 29 May 2024 (UTC)[reply]
We could turn it into: 
.flagicon img {
    min-width: 23px;
    height: auto !important;
}
No ideal, but will work I think... —TheDJ (talk • contribs) 12:09, 29 May 2024 (UTC)[reply]
It works for me in this section. PrimeHunter (talk) 12:42, 29 May 2024 (UTC)[reply]

Template gadgets[edit]

A discussion regarding the new use of "tempalte gadgets" is now open at Wikipedia:Interface_administrators'_noticeboard#Template_gadgets_-_naming_convention, please join in there if interested. — xaosflux Talk 11:53, 28 May 2024 (UTC)[reply]

Initial testing is available for anyone who would like to opt in to the first one of these. See the current bottom of Talk:Conway's Game of Life for info. — xaosflux Talk 20:09, 29 May 2024 (UTC)[reply]
The first one of these has been launched. Please @ping me if there are any reported issues. Follow up on the general concept of template gadgets is welcome at WP:IANB. — xaosflux Talk 15:29, 31 May 2024 (UTC)[reply]

Issue with cast template visuals, but only on Chrome[edit]

Was editing the page for Ezra (2023) and noticed that on Google Chrome, there is a huge issue with spacing. Wish I could show screenshots to detail what I see. But underneath 'Cast', I see a large, multi-paragraph jump of just blank, white space. It nearly takes up the whole screen. I do not see this on mobile, nor do I see it on Microsoft Edge -- just Google Chrome. Unsure how to fix this as I'm newer to Wiki. Is anyone seeing the same thing as me, and do they potentially know how to fix? Squiddyonwiki (talk) 02:02, 29 May 2024 (UTC)[reply]

Not seeing it on my chrome browser (Version 125.0.6422.76, Windows 11), apologies. CMD (talk) 02:46, 29 May 2024 (UTC)[reply]
I see that {{cast listing}} sets the style declaration min-width: min(25em, 100%) - is Chrome interpreting that as expected? First off, the min(...) function is in CSS Values and Units Module Level 4, which is still at the W3C Working Draft stage - not all browser vendors will impement it yet. Second, the spec says

For all three functions, the argument calculations can resolve to any <number>, <dimension>, or <percentage>, but must have a consistent type or else the function is invalid; the result’s type will be the consistent type.

- by my reading of that spec, 25em and 100% are not type-consistent. Chrome may be choking on that. --Redrose64 🌹 (talk) 06:30, 29 May 2024 (UTC)[reply]
min() is implemented by most of the browsers worth discussing. I think your observation about types is perhaps interesting. However, you are allowed to mix units in these min/max/clamp functions (see examples earlier in the page), and percentage is in a sense a unit...? I also know that CSS columns have a complex formula for how wide they are laid out and the 100% may be interfering with that. And that Chrome only recently (a couple years ago) made their CSS columns implementation much closer to fully specification compliant. Izno (talk) 15:18, 29 May 2024 (UTC)[reply]
That investigation just above aside, there is a possibility this was caused by a change that WMF made because they're thinking about how to make tables display appropriately when the width of the page is too narrow, based on your description of what you saw. The task for that is phab:T366119 and an initial bug report about suboptimal display was phab:T366119, after which there was some adjustment to how it functions - namely restricting this functionality to wikitable class tables. (There is still some things being learned there it looks like - though Isarra sorted most of this a while ago in Timeless....) Izno (talk) 15:33, 29 May 2024 (UTC)[reply]
That sounds like what I was seeing. What's weird, though, is that I'm on a Macbook now, still Chrome, and it looks normal. But on a Dell the display is what's bugged. Maybe it's based on the size of the laptop's screen? But unsure, because on my Dell on Microsoft Edge it was fine. Either way, I've never had to do a bug report but I will try to figure that out. Squiddyonwiki (talk) 15:38, 29 May 2024 (UTC)[reply]

Page previews not working[edit]

Since yesterday, page previews of links haven't worked for me. My "Enable page previews" option is turned on. Can anyone help? Thanks! LoganP25 (talk) 20:31, 29 May 2024 (UTC)[reply]

@LoganP25: Do you have an "Edit preview settings" link at the bottom of pages? If so, can you enable it there? PrimeHunter (talk) 20:53, 29 May 2024 (UTC)[reply]
I don't think so LoganP25 (talk) 21:12, 29 May 2024 (UTC)[reply]
@LoganP25: It should be to the right of "Mobile view" if you have it. Do previews work if you log out? Do you have the link there? Do previews work at https://en.wikipedia.org/wiki/Example?safemode=1, logged in or out? Does it work to disable previews at Special:Preferences#mw-prefsection-rendering, save preferences, enable it again and save again? "Navigation popups" should be disabled at Special:Preferences#mw-prefsection-gadgets if you use page previews. Is it? PrimeHunter (talk) 21:28, 29 May 2024 (UTC)[reply]
There's nothing to the right of "Mobile view" for me. Previews work when I'm logged out, but are broken again when I log back in. Previews don't work at the link you sent, and still don't after turning them off and on again. Navigation popups is disabled. Quite the enigma lol. LoganP25 (talk) 22:21, 29 May 2024 (UTC)[reply]
@LoganP25: What is your skin at Special:Preferences#mw-prefsection-rendering? What is your browser? Do previews work logged in at other wikis like simple:Example? You may have to first enable them in preferences there. PrimeHunter (talk) 22:39, 29 May 2024 (UTC)[reply]
My skin is Vector legacy, and I'm browsing on Google Chrome. Previews do work in other wikis, I hadn't thought to check that, but not in the English wikipedia. LoganP25 (talk) 22:47, 29 May 2024 (UTC)[reply]
@LoganP25 Hello. I also had the same problem here, but fortunately I made it! So I would like to share my solution to you as well.
The replies that you made to the questions of @PrimeHunter about having the link of "Edit preview settings" at the bottom of pages, the matter of "whether or not login/logout has an affect on page preview", "Navigation popups" options disabled or not along with all the other factors you mentioned matches exactly with mine. But I solved it in a different way.
Firstly, go to the "Appearence" in your "Preferences" & check the box of the "Enable page previews" (if its already checked then follow the next steps). Now, go to the "User profile", click on "Set your global preferences". On the "Appearance", there you should enable the (another) page preview option (both of the boxes should be checked). Save it & again return to your (original) "Appearance" in your "Preferences" just to make sure that, two things are there — the "Enable page previews" is not only checked but also grayed out & the "Set a local exception for this global preference" is unchecked.
Hope it helps. ERA (talk) 13:40, 30 May 2024 (UTC)[reply]
That worked, thank you so much! LoganP25 (talk) 14:03, 30 May 2024 (UTC)[reply]
Glad you finally worked it out. It sounds like a bug if you have to set a global preference to make a local preference work. I haven't heard of that before and didn't expect it. PrimeHunter (talk) 14:15, 30 May 2024 (UTC)[reply]

Production table formatting for correct text alignment[edit]

An experienced editor informed me that a table format - used over years with no negative feedback on numerous articles to display crop production data - "crashes" the text aligning to it in the right text margin. The editor says it works fine in Chrome, but doesn't on any browsers tried on a Windows PC.

The original table format parameters are 

{| class="wikitable" style="float:right; clear:left; width:14em; text-align:center;"
|-
! colspan=2|Mango* production – 2022
|-
!  style="background:#ddf; width:75%;"| Country
!  style="background:#ddf; width:25%;"| <small>millions of [[tonne]]s</small>
|-

The editor made a change based on a "wikitable floatright" parameter plus internal table formatting (column alignment left or right) using: 

{| class="wikitable floatright" style="width:15em; margin: 20px 20px 0px 20px"
|-
! colspan=2|Mango* production – 2022
|-
!  style="background:#ddf;"| Country
!  style="background:#ddf;"| <small>millions of [[tonne]]s</small>
|-

This is the history of editing. Please comment on parameters with potential text-table alignment effects:

  1. style="float:right
  2. clear:left
  3. style="background:#ddf; width: and the respective 75% and 25% (removed in the revision)
  4. the editor's revision: style="width:15em; margin: 20px 20px 0px 20px"
  5. table display effect on text alignment of different browsers using a Chromebook vs. Windows PC (vs. Apple).

Thanks for looking into this. Zefr (talk) 22:27, 29 May 2024 (UTC)[reply]

@Zefr: The floatright class, when used on a table, is equivalent to setting the float:right; clear:right; margin: 0 0 0.5em 0.5em; styles. Notice two things: (i) the clear is for right not for left; (ii) it doesn't affect text alignment within the cells. You shouldn't need to explicitly set margin values if you are also using the floatright class. For an axample of floatright without other styles, see the "Distribution of locomotives, March 1974" table in British Rail Class 24#Operation. --Redrose64 🌹 (talk) 16:52, 30 May 2024 (UTC)[reply]

OpenStreetMaps in Croatian? Is it just me?[edit]

The OpenStreetMap maps in the infoboxes at Radio City Music Hall and Carnegie Hall (and probably other locations) seem to be in Serbo-Croatian; at least all of the place names are spelled phonetically according to Serbo-Croatian rules. Is this true for everyone, or is there some weird setting in my Preferences I need to change? If it's true for everyone, can it be fixed? Surely OpenStreetMap has an English-language version of their map of Manhattan. —Mahāgaja · talk 11:28, 30 May 2024 (UTC)[reply]

I see this, too. If I click through to get a large map, it affects all of Manhattan but not the other boroughs, New Jersey, or (as far as I can tell) any other place. rbrwr± 12:41, 30 May 2024 (UTC)[reply]
For me it affects most but not all of Manhattan. Also raised at Talk:Manhattan#Question about the map. CMD (talk) 12:52, 30 May 2024 (UTC)[reply]
phab:T366136 for this issue. related ticket: phab:T195318. – robertsky (talk) 13:03, 30 May 2024 (UTC)[reply]

New Gadget for viewing CT images[edit]

We at Wiki Project Med have built a gadget to view stacks of images such a as CT scans, which you can see here[12]. We are wanting to install it on EN WP.

Previously mentioned to User:MusikAnimal here who want to verify community consensus first.

We have an earlier version working on Commons[13]. Based on Template:PD-medical we have collected a few thousand complete CT and MRI scans of various conditions. Doc James (talk · contribs · email) 19:13, 29 May 2024 (UTC)[reply]

@Doc James about how many pages would this need to run on? We are currently experimenting with our very first implementation of Template Gadgets (see a couple sections up) right now, which I imagine would be the way we would want to implement this (and most certainly not by hooking a full page text analyzer in to common.js). — xaosflux Talk 18:49, 30 May 2024 (UTC)[reply]
A template gadget version has been copied to mediawiki.org as a demo. See mw:Template:ImageStackPopup Bawolff (talk) 19:00, 30 May 2024 (UTC)[reply]
So User:Xaosflux sounds like it only loads when a specific category is present already. Doc James (talk · contribs · email) 19:21, 30 May 2024 (UTC)[reply]
@Doc James yes, where said category would come along with a template that would wrap whatever is being used. It sounds like all instances of this would use some template so that part isn't hard. What order of magnitude of pages would you expect this would get used on? — xaosflux Talk 19:23, 30 May 2024 (UTC)[reply]
User:Xaosflux few thousand at most, Doc James (talk · contribs · email) 19:44, 30 May 2024 (UTC)[reply]
Thanks for the note. — xaosflux Talk 19:24, 30 May 2024 (UTC)[reply]
The mediawiki version is quite a bit better.
  • For a default gadget, i'd have some concerns about the accessibility of the play button. It's not a button, and it's also not labeled.
  • Similar for the pager and slider in the window. This is unlabeled. It should have accessibility labels to make it possible to understand what the slider does.
  • The play button positioning and sizing might need a little bit more work, it seems kinda off (esp on iphone)
  • Might want to hide the play button on media print
  • Good to see that media credits are being linked.
  • Seems to work on mobile, but could use some additional spacing at the top controls, they are really difficult to hit because everything is so close together now.
  • Closing the dialog. All MW dialogs currently have close at the top (an old pattern i note due to mobile usage favoring thumb interaction at the bottom of a dialog). This does create an inconsistency, but i'm not particular concerned.
  • The whole ImageStackPopup-viewer is inside a label element atm. I think that's an accident?
—TheDJ (talk • contribs) 20:27, 30 May 2024 (UTC)[reply]
Perhaps we can use gitlab instead of mediawikiwiki for development? It can probably serve as the version which wikis copy from. I created a blank project at gitlab:repos/gadgets/ImageStackPopup, and can extend SDZeroBot 13 to support tracking updates from gitlab. – SD0001 (talk) 09:14, 31 May 2024 (UTC)[reply]
There's been some accessibility improvements in the latest version. Button is also now hidden on print. The label thing and the close button at the bottom seem to be due to using OO.ui.alert. I'm not sure why OOUI does it that way for alert boxes. Bawolff (talk) 13:18, 31 May 2024 (UTC)[reply]
Synced local fork from upstream. — xaosflux Talk 13:57, 31 May 2024 (UTC)[reply]
@Doc James, As one of our professors often says, "One view is no view in Radiology." From a content perspective, I am confident that these imaging stacks will enhance the quality of our radiology related articles. Looking forward to seeing this implemented soon. signed, 511KeV (talk) 19:03, 30 May 2024 (UTC)[reply]
Moral support for the idea, bug-report for the implementation: the stack is scrolled by a left–right slider, but when hovering over the image the stack scrolls when I move the mouse up-and-down and not side-to-side. DMacks (talk) 19:49, 30 May 2024 (UTC)[reply]
Given the bird's-eye view with the line indicating the location of the specific scan is an up-and-down position, having the slider be side-to-side is confusing. Everything needs to be in sync. DMacks (talk) 00:09, 31 May 2024 (UTC)[reply]
  • I've forked ImageStackPopup over for anyone that wants to test it out in sandboxes etc, you can either manually opt-in to it in the "testing and development" gadget section, or you can load it to a page with the ?withgadget query parameter. From discussion above, this seems like it will need some extensive testing and tweaking. Nothing should currently be placed in to an article that is dependent on this right now, as readers will not be able to make use of it yet. — xaosflux Talk 23:55, 30 May 2024 (UTC)[reply]
    The Vivarium template gadget being currently tested is much simpler, and we will make sure our roll out of template gadgets is done carefully. Additional discussion around if these should be able to be opted out of should also occur (i.e. not making them default+hidden). For a default here, we'll likely also use a fork, we have a bot to monitor remote changes and flag for promotion that can be used. — xaosflux Talk 23:58, 30 May 2024 (UTC)[reply]

The test version on Commons loads 250 images. Given how heavy these images are, this seems like a bad use case for a gadget and should potentially be in some sort of video instead, which won't try to download that many images all at the same time. Izno (talk) 00:24, 31 May 2024 (UTC)[reply]

That does seem like a lot if its all hitting the browser right away. Something that heavy sounds like it would be better to paginate and be done in mediaviewer perhaps. — xaosflux Talk 00:28, 31 May 2024 (UTC)[reply]
To clarify, the images get downloaded only after the user hits the play button, so only users who want to see them do the download. Perhaps that could be improved with a progress loading bar or something or the ability to cancel. The goal is to allow users to directly compare all the images all at once, so i'm not sure pagnation would work here. I agree that as a long term solution, transfering as a video with p-frames/temporal compression would probably be much more bandwidth efficient. Bawolff (talk) 05:43, 31 May 2024 (UTC)[reply]
Also, just to be clear, this gadget does not exist on commons. There is a separate gadget on commons called ImageStack, which is the inspiration for this gadget, but its a totally different gadget. Bawolff (talk) 09:46, 31 May 2024 (UTC)[reply]

Perfect. Got it working here on EN WP User:Doc_James#CT_scan_viewer. Agree a bit of fine tuning is still required.

I like the idea of a progress loading bar. As User:DMacks suggests lets move the scroll bar to the right of the image. We will need a naming convention for these pages User:Doc James/Appendicitis CT Doc James (talk · contribs · email) 15:43, 31 May 2024 (UTC)[reply]

this link can be used to manually enable to gadget once for others that want to see this without doing the opt-in. — xaosflux Talk 18:13, 31 May 2024 (UTC)[reply]

Replag[edit]

Another lengthy replag (~3 hours) on a Thursday night. Is there any place to go to find out when the estimated fix-it time will occur? Or is it just wait and see? Liz Read! Talk! 02:40, 31 May 2024 (UTC)[reply]

Mostly just wait and see. My guess is the cause is phab:T364299. * Pppery * it has begun... 03:01, 31 May 2024 (UTC)[reply]
Seems to have fixed itself. The highest I've seen it go was around 11 or 12 hours, so this one was not nearly as bad as it's been in the past. --rchard2scout (talk) 13:44, 31 May 2024 (UTC)[reply]

Phantom redirects[edit]

Tracked in Phabricator
Task T331127

I'm running into the recurrence of a problem I've brought here a few times before, where an incategory search of Category:Living people for drafts or user sandbox pages that shouldn't be in it offers up several pages that aren't actually pages in the category but cross-namespace redirects to real articles, which resulted from an editor adding categories to the page while it was still in draft or user space, and then moving the page into mainspace shortly afterward. That's a relatively common occurrence which doesn't usually cause any serious problems, but every once in a while it causes situations like this, where for some reason the redirect lingers in the categories despite not actually having any categories on it.

In the past I've usually resolved this by redoing the move: I would move the page back overtop the redirect, wrap the categories in the {{draft categories}} wrapper to disable them, and then move the page back into articlespace again, which usually worked to get the redirect out of the category — but of the four such redirects currently showing up in the search, I've already done that on two of them, meaning even that trick isn't working anymore.

Additionally, I need to note that there are four phantom redirects currently showing up in the search, yet the results counter at the top of the page is claiming that there are eight pages, meaning that there are four more phantoms I can't even find.

Because Category:Living people is a megacategory with millions of pages in it, it's not a category I can search manually for draft or user pages — it has to be done as an incategory search, which means I can't just work around permanent speed bumps and need the tool to be clean. It might also be related to the replag problem that's been discussed above, because even the normal categorized drafts or userpages that I pull out of the category the normal way are taking longer than usual to clear from the search as well — but could somebody look into whether there's any way to fix it? Thanks. Bearcat (talk) 17:20, 31 May 2024 (UTC)[reply]

Replag is currently around five seconds, so that's not it. It wouldn't affect searches on the live site anyway.
If I query the database for members of Category:Living people that are in namespaces user, draft, or their corresponding talk, I get no results. All four of the current false positives in search (Draft:Amre Hamcho, User:Miminity/Yoshinobu Yamakawa, User:Minmarion/sandbox/voice, User:WikiOriginal-9/David Hinds (gridiron football)) were moved within the last 24 hours. And neither a null edit nor an actual edit (both to User:Miminity/Yoshinobu Yamakawa) helped. Taken together, these lead me to guess - with absolutely no knowledge whatsoever of how the search backend works, mind you - that it's only the search indices that are out of date.
I suppose it's worth checking back in a day or so, without your move/edit/move workaround, to see if they clear up themselves. Failing that, I can build a database report for you, which might be more convenient than the search. (That is, unless you're worried about search results, too, not just what appears on the category page.) Any other categories to check besides Category:Living people? —Cryptic 18:39, 31 May 2024 (UTC)[reply]
@Bearcat: Have you tried this?
  1. Navigate to the redirect that is incorrectly listed at Category:Living people
  2. Edit the redir page to add [[Category:Living people]] and save it
  3. Edit the redir page to remove [[Category:Living people]] and save it
Does this work to delist the redirect from Category:Living people? --Redrose64 🌹 (talk) 21:15, 31 May 2024 (UTC)[reply]

Font size bug - mobile[edit]

Hello, I have question. For quite some time now, The font size is not correctly shown when I want to see it on visual editing (i mostly work with filmografies of actors) - basically, I want to change font size from 100 to 80, and its not working at all. It stays same. The whole filmography also gets bigger sometimes for some reason when I want to edit it only by visual editing. I remember there was a discussion about this long time ago but I dont know if there was any improvement. I work on mobile, so I dont know whether pc users have this problem as well. If there is any sollution or way how to make it work, feel free to comment your suggestions. Thx in advance. Kesseder (talk) 17:55, 31 May 2024 (UTC)[reply]

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