Wikipedia:Village pump (technical)

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

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

view · edit

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

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

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

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

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

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

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

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

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

« Archives, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217

Edit conflict-like situation that recreated a draftified article

The other day in working on some articles in CAT:UNCAT, I came upon Mulashidi. I added a category and removed the uncatted tag, and there my interaction with the article ended, or so I thought. Then Liz came to my talk page to ask why I had recreated an article that had been draftified to Draft:Mulashidi. Huh? I looked at the article history and saw to my surprise that I had "created" this article. Extra huh??? Then I looked at the logs, and saw that SunDawn's draftification and my "creation" of the article happened in the same minute. Apparently I was finding a category at the same time another editor was moving it. I was not, to my recollection, asked if I wanted to create an article that didn't exist. This may be an oddball fluke, but since it happened to me, it could happen to others as well. The system needs some sort of way to handle such things that aren't checking the history to make sure you didn't just accidentally recreate an article that existed before you started editing. Thanks to Mandarax for looking at the situation and suggesting I bring it here. LadyofShalott 13:04, 1 December 2023 (UTC)[reply]

Maybe HotCat's API requests are not using proper edit conflict detection such as starttimestamp, baserevid, etc. The code appears to be at commons:MediaWiki:Gadget-HotCat.js. There doesn't appear to be an active maintainer, the history is an assortment of editors. Next step would probably be to post on one of the HotCat talk pages (Wikipedia talk:HotCat or commons:MediaWiki talk:Gadget-HotCat.js). –Novem Linguae (talk) 19:55, 1 December 2023 (UTC)[reply]

Not just HotCat; something similar has happened to me a few weeks ago when the article was deleted at the same time as I moved it to draft. Espresso Addict (talk) 23:15, 6 December 2023 (UTC)[reply]

Sidebar is hiding when a Wikipedia page was last edited and links below it

The Wikipedia Sidebar is now hiding when a Wikipedia page was last edited and the writing and links below it when you scroll down to the bottom of a page with many sidebar links. For example, the "Privacy policy", "About Wikipedia" and "Disclaimers" are also now hidden from view. Someone has recently edited the page layout on Wikipedia for the worse as this was not the case 5 days ago. 92.24.237.212 (talk) 05:36, 3 December 2023 (UTC)[reply]

I can reproduce this with Vector-2022 in Firefox, Edge and Chrome, logged in or out, with or without safemode. Pick a page with a long TOC, e.g. this page. Make sure the TOC is shown in the sidebar and not hidden. The TOC extends to the bottom of the window and covers the left part of the footer. "23, at 06:36." is the only visible part of "This page was last edited on 3 December 2023, at 06:36." The next lines become visible at "Attribution-ShareAlike", "a non-profit organization" and "Contact Wikipedia". Either the sidebar should stop before the footer or the whole footer should move to the right of the sidebar like the content of the wiki page. PrimeHunter (talk) 11:28, 3 December 2023 (UTC)[reply]

This is a known issue, and fixed in the next release. —TheDJ (talk • contribs) 13:26, 3 December 2023 (UTC)[reply]

Long tables of contents truncated

For articles/discussion pages with very long tables of contents, such as this one, in vector2022 on Firefox on a Mac, I am getting the table of contents truncated after a certain length. For instance, on this page, as I type this, the table of contents that I see (when I scroll down to the bottom of either the ToC or the actual page) shows the top few pixels of #Rotten tomatoes prose template (or rather "Rotten tomatoes prose" as the "template" wraps to the next line that I cannot see), and the next heading, #The center class, is completely omitted. I suspect some length calculation gone awry, as it is always near the end of what should be the full table of contents regardless of the number of entries. Is anyone else seeing this? Any ideas what to do to get it fixed? —David Eppstein (talk) 22:21, 3 December 2023 (UTC)[reply]

This is the same issue as #Sidebar is hiding when a Wikipedia page was last edited and links below it. Izno (talk) 23:44, 3 December 2023 (UTC)[reply]

I doubt it. It has nothing to do with how much of the window the TOC rectangle covers or what might be hidden under that rectangle. It is about the objects within the TOC rectangle and how much of them can be seen by scrolling within the rectangle. To put it another way: once it needs to scroll, the TOC rectangle is always the same size (the height of the window). The *contents* of the TOC rectangle (the stuff you can scroll) may be a much larger size. This bug involves some miscalculation of the size of the contents of the TOC rectangle, causing the TOC entries beyond the miscalculated size to be unviewable. —David Eppstein (talk) 01:23, 4 December 2023 (UTC)[reply]

Right, but the reason you can't see the last item is because it's overflowing the bounds it's supposed to and so under the typically-present bar at the bottom of the page that goes with the expander square on the right hand side. I am pretty sure it's the same issue. Izno (talk) 01:28, 4 December 2023 (UTC)[reply]

Maybe. On closer view, the problem is that the TOC rectangle is extending past some bottom margin on the screen. You can tell that it's the TOC rectangle being cut off rather than the contents of the TOC rectangle being cut off because the rounded bottom of the scroll bar is also cut off. Only the left sidebar has this margin; the main window and right sidebar contents extend past it. —David Eppstein (talk) 01:32, 4 December 2023 (UTC)[reply]

TOC cut off in 2022 skin

In Special:Permalink/1188211731, the section #Revoke TPA for temporarily blocked user does not appear in the table of contents in the left sidebar. It is section number 58 in this revision. –LaundryPizza03 (d c̄) 00:45, 4 December 2023 (UTC)[reply]

Both issues appear to have been fixed. Nthep (talk) 22:05, 6 December 2023 (UTC)[reply]

It's not fixed. It's still broken for me. WhatamIdoing (talk) 21:58, 11 December 2023 (UTC)[reply]

Hey everyone, do you still see this bug? It should have been fixed as part of the improvements to styling of Vector 2022. Thanks, SGrabarczuk (WMF) (talk) 01:24, 12 December 2023 (UTC)[reply]

Wikimedia\Rdbms\DBQueryError

Tracked in Phabricator
Task T352628
Resolved

I got this error when trying to edit an article. I see this has happened before in 2020. Looks like someone at Wikipedia:Help desk#Database error when trying to edit an article has filed a ticket at Phabricator, tracked at phab:T352628. InfiniteNexus (talk) 07:17, 4 December 2023 (UTC)[reply]

@InfiniteNexus I encountered the same bug about 10 minutes ago. Bug now, it seems that the this DB bug is resolved. Hooman Mallahzadeh (talk) 08:13, 4 December 2023 (UTC)[reply]

I keep getting this error trying to edit Wellington (disambiguation). I'm able to edit other articles. older ≠ wiser 12:05, 4 December 2023 (UTC)[reply]

I just got it, and reproduced, trying to do a small edit on Handball (disambiguation), something's fishy here.

[880bbfb7-540e-49ff-bd80-5d1f0880e872] 2023-12-04 13:11:04: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"

--Joy (talk) 13:12, 4 December 2023 (UTC)[reply]

My new attempts there also get:

To avoid creating high replication lag, this transaction was aborted because the write duration (3.465854883194) exceeded the 3 second limit. If you are changing many items at once, try doing multiple smaller operations instead.

[5b6f2722-25fb-4736-a8a1-061b5bc2d481] 2023-12-04 14:31:18: Fatal exception of type "Wikimedia\Rdbms\DBTransactionSizeError"

--Joy (talk) 14:31, 4 December 2023 (UTC)[reply]

JFTR that edit went through in the meantime. And Phabricator indicates the developers are figuring it out. --Joy (talk) 17:05, 4 December 2023 (UTC)[reply]

I also had errors on two edits in the last couple of hours. I didn't record the first but the second was

[29eec93d-299b-4bdf-89d1-88caca3466b5] 2023-12-04 14:13:41: Fatal exception of type "Wikimedia\Rdbms\DBTransactionSizeError"

on this edit. Both worked after I used the browser's Back button and clicked Publish again. Certes (talk) 14:17, 4 December 2023 (UTC)[reply]

Still getting an error on this. I was getting something about a transaction being too large and taking too long (>3 sec) for a couple attempts. This attempt I got

A database query error has occurred. This may indicate a bug in the software.
[4d773f04-424e-4f64-af0f-f259aa808ecd] 2023-12-04 14:44:28: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"

Attempts to edit my user sandbox page were successful.

Kimen8 (talk) 14:45, 4 December 2023 (UTC)[reply]

I've been getting this error this morning too: To avoid creating high replication lag, this transaction was aborted because the write duration (15.307519674301) exceeded the 3 second limit. If you are changing many items at once, try doing multiple smaller operations instead. [1cd8ddfe-f560-4300-b162-1d4d0448423c] 2023-12-04 16:19:03: Fatal exception of type "Wikimedia\Rdbms\DBTransactionSizeError" These aren't large changes I'm attempting. I have gotten a few edits through, but it's hit or miss. – Muboshgu (talk) 16:23, 4 December 2023 (UTC)[reply]

It seems to be an issue with DB queries taking too long, see https://phabricator.wikimedia.org/T352628#9379558 for more information NW1223<Howl at me•My hunts> 16:35, 4 December 2023 (UTC)[reply]

Got it when trying to edit Legislative Assembly of Costa Rica, but when I tried a second time, the edit went through fine. Cremastra (talk) 17:44, 4 December 2023 (UTC)[reply]

I got this type of error just now trying to edit Luzerne County, Pennsylvania. At least now I know what the problem is. QuicoleJR (talk) 16:46, 4 December 2023 (UTC)[reply]

Database error

I'm trying to revert this unsourced/WP:CRYSTAL edit to 2007 Formula One World Championship, but I keep getting error messages of the form:

A database query error has occurred. This may indicate a bug in the software.
[38a2ed1b-239f-4448-841c-e65ec46331ef] 2023-12-04 08:28:23: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"

I've tried a couple of different edit summaries, and I'm able to edit other articles. Could someone else please try reverting the edit? Thanks. DH85868993 (talk) 08:32, 4 December 2023 (UTC)[reply]

I tried to revert it and also got a DBQueryError. It looks like there is already a ticket filed on Phabricator; see Wikipedia:Village_pump_(technical)#Wikimedia\Rdbms\DBQueryError. Malerisch (talk) 08:46, 4 December 2023 (UTC)[reply]

Am having the same problem at First Mithridatic War and another editor has reported similar problems at WP:Teahouse - Arjayay (talk) 11:52, 4 December 2023 (UTC)[reply]

Have now edited First Mithridatic War - problem may be cleared/clearing? - Arjayay (talk) 12:46, 4 December 2023 (UTC)[reply]

Me as well at Vista, California ... [ab2894fb-78ff-4187-a212-713464e91635] 2023-12-04 12:22:58: Fatal exception of type "Wikimedia\Rdbms\DBQueryError". Magnolia677 (talk) 12:25, 4 December 2023 (UTC)[reply]

Same here, at Deer Park, New York: [a4dc9654-fbed-48be-8eb3-a597446272e9] 2023-12-04 12:32:07: Fatal exception of type "Wikimedia\Rdbms\DBQueryError" WikiDan61^ChatMe!_ReadMe!! 12:33, 4 December 2023 (UTC)[reply]

And the same here (in the UK), from about 2 hours ago, editing Caligula, using MacBook. Sometimes it lets me edit but not save. Other times, it works fine but not for long. There's no pattern to it that I can discern. My Watchlist responds to changes in all other articles. Haploidavey (talk) 12:59, 4 December 2023 (UTC) Just tried a test edit, and was treated to the following:[reply]

I am getting this with many different articles. Mellk (talk) 13:21, 4 December 2023 (UTC)[reply]

Database error

To avoid creating high replication lag, this transaction was aborted because the write duration (5.7858679294586) exceeded the 3 second limit. If you are changing many items at once, try doing multiple smaller operations instead.

[b08b554e-cf70-4cd8-8291-03dd2733d85a] 2023-12-04 13:01:46: Fatal exception of type "Wikimedia\Rdbms\DBTransactionSizeError"

Haploidavey (talk) 13:08, 4 December 2023 (UTC)[reply]

This is the kind I'm getting, and lots of them:

Database error

A database query error has occurred. This may indicate a bug in the software.

[74e1f80b-d290-4d16-836e-3c887005d683] 2023-12-04 14:01:55: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"

— SMcCandlish ☏ ¢ 😼 14:08, 4 December 2023 (UTC)[reply]

Getting the same issue with the article Martin Artyukh. [85a67d40-833b-409f-a662-ba0486de9b09] 2023-12-04 15:51:16: Fatal exception of type "Wikimedia\Rdbms\DBQueryError" --BlameRuiner (talk) 15:52, 4 December 2023 (UTC)[reply]

Yup, I'm getting the same error across multiple articles - sometimes takes multiple attempts to get a change to save. Parsecboy (talk) 16:23, 4 December 2023 (UTC)[reply]

Recovering from it?

When this error hits me, if I go "back" in the browser to get back to the text I was working on, all my changes are gone. This is actually weird behavior in Chrome. E.g., if I instead get an edit-conflict page, I can "Back" in the browser freely. But when this DB error happens, it's like it somehow messes up the page cache. Does anyone know of a way to recover the text that was being worked on? I have an article that did a whole lot of cleanup work in (probably a good half hour of it) and don't want to lose all that work if I can help it. I'm still sitting on the DB error page on that one. — SMcCandlish ☏ ¢ 😼 14:08, 4 December 2023 (UTC)[reply]

Update: I took a gamble, and it turns out that clicking the Reload button worked (caveats: in Chrome, and without triggering another DB error; I have no idea what another browser would do, or what would happen if the DB error had recurred, and it might, since in trying to make a typo fix at another page I had to try five times, though each time I did it as a manual edit, not a reload). — SMcCandlish ☏ ¢ 😼 14:28, 4 December 2023 (UTC)[reply]

FWIW in my Firefox, the back button got me back into the previous state, with the content and summary fields intact, so I can keep retrying trivially. --Joy (talk) 14:33, 4 December 2023 (UTC)[reply]

I'm in Microsoft Edge, and the back button gets me to the state pre-submission, with edits and summary in place. Though I am now taking a copy of the text before clicking Publish. Tacyarg (talk) 14:55, 4 December 2023 (UTC)[reply]

I'm using Chrome on a chromebook and if I hit the Back button, I get the original article state from when I hit edit (i.e., I lost my changes and edit summary). I'm just going to wait until it seems to be resolved before making any more edits. Kimen8 (talk) 14:58, 4 December 2023 (UTC)[reply]

Fixed?

phab:T352628 claims the issue is fixed. I went back to retry my edit at Deer Park, New York and was successful. WikiDan61^ChatMe!_ReadMe!! 18:06, 4 December 2023 (UTC)[reply]

It is indeed fixed. NW1223<Howl at me•My hunts> 18:11, 4 December 2023 (UTC)[reply]

Yep, fixed now. InfiniteNexus (talk) 18:54, 4 December 2023 (UTC)[reply]

Markup that derives the file page for a TimedText page

Tracked in Phabricator
Task T352955

While cleaning up Wikipedia:Database reports/Timed Text without a corresponding File, I keep tripping over the fact that in order to check that a TimedText page is deletable, I need to edit the URL to get from e.g TimedText:Dua Lipa Blow Your Mind (Mwah) sample.ogg.en.srt to File:Dua Lipa Blow Your Mind (Mwah) sample.ogg. Is there a template, parser function or whatever that can display such a link automatically? The titleparts one keeps the ".en.srt" bit in, making it useless. Jo-Jo Eumerus (talk) 17:39, 4 December 2023 (UTC)[reply]

I wonder if MediaWiki:timedmedia-timedtext-title-edit-subtitles can be edited so the "File:..." part in the top heading for an srt page is a wikilink which turns red if the file doesn't exist. If not, perhaps the responsible code in the TMH extension should be modified to link it. Nardog (talk) 17:49, 4 December 2023 (UTC)[reply]

Well, maybe we can add a link, but for that we first need to know how to strip the ".en.srt" (and equivalent) bits out. Jo-Jo Eumerus (talk) 07:41, 5 December 2023 (UTC)[reply]

$2 is already the file name with that part stripped. My suggestion is simply to turn it into a wikilink, not add extra text. Nardog (talk) 07:25, 6 December 2023 (UTC)[reply]

There is some javascript for that at c:Commons:Village pump/Technical#Gadget to jump from timedtext back to audio/video file. Another option is to open the player and click the i with an circle, that will also direct you to the file page. Snævar (talk) 19:09, 4 December 2023 (UTC)[reply]

That works for TT pages attached to working files, not for the scenario where the file was deleted or moved. Jo-Jo Eumerus (talk) 07:43, 5 December 2023 (UTC)[reply]

Or you just ctrl click the video and the browser opens the file page in a new tab (just like any image). Or right click and choose "open in new window/tab". And if there is no video found, it should not display a video in the page and you would get "There is no video associated with the current subtitle page." next to the subtitle content. —TheDJ (talk • contribs) 09:43, 5 December 2023 (UTC)[reply]

Does it also display "There is no video associated with the current subtitle page." when the video exists as a redirect, or is on Commons? Because in these cases measures other than deletion would be needed. Jo-Jo Eumerus (talk) 09:57, 5 December 2023 (UTC)[reply]

For TT pages that refer to Commons repos, It hides their contents and says: "You can view the description page for this file on Wikimedia Commons (production)" (example). For redirects it says "There is no video associated with the current subtitle page" (example). —TheDJ (talk • contribs) 13:42, 5 December 2023 (UTC)[reply]

MediaWiki:timedmedia-timedtext-title-edit-subtitles is a page heading which should not contain anything else (rather large letters for that, BTW).

MediaWiki:editnotice-710 might provide guidance.
You could grab the TimedText page title and extract the expected File: by Template:str rep pattern.
If desired, an {{#ifexist:}} for the related File: could issue a related warning for everybody, otherwise provide a link to the expected File: (perhaps always as requested by initiating this section).
TimedText:Seven (sample).mp3.pt.srt is not .en. but should be covered as well. Perhaps a note on wrong language.

Greetings --PerfektesChaos (talk) 13:06, 5 December 2023 (UTC)[reply]

Yeah, that last point is the problem - I need a code that can strip the text after the second-to-last dot. Str rep does not do that, it needs to be told "pt" or whatever. Jo-Jo Eumerus (talk) 15:49, 5 December 2023 (UTC)[reply]

If you #invoke Module:String#replace with |plain=false, that may do the job. Certes (talk) 16:15, 5 December 2023 (UTC)[reply]

For example, "

{{#invoke:String|replace|TimedText:Dua Lipa Blow Your Mind (Mwah) sample.ogg.en.srt|^TimedText:(.*)%.%w+%.%w+$|File:%1|1|plain=false}}

" produces "File:Dua Lipa Blow Your Mind (Mwah) sample.ogg". Certes (talk) 16:22, 5 December 2023 (UTC)[reply]

OK, that works better. To clarify, I am thinking to put

{{#ifexist:{{#invoke:String|replace|{{FULLPAGENAME}}|^TimedText:(.*)%.%w+%.%w+$|File:%1|1|plain=false}}|This timed text is attached to a redirect.|There is no video associated with the current subtitle page.}}

on MediaWiki:Timedmedia-subtitle-no-video so that we can tell the difference. Or would a software patch to create a new message for TimedText attached to redirects make more sense? Jo-Jo Eumerus (talk) 16:46, 5 December 2023 (UTC)[reply]

Yes, in the long run the TimedText:*.srt pages should be equipped with something like MediaWiki:timedmedia-timedtext-intro or whatever (empty by default).

I did suggest MediaWiki:editnotice-710 as first aid for now, since no other system message is transcluded today.
A phabricator proposal might work in some weeks or years.

Enjoy --PerfektesChaos (talk) 20:27, 5 December 2023 (UTC)[reply]

If the phabricator proposal is simple enough that it doesn't take me hours to verify that we won't break anything, wrt to performance or 3rd party users, i can easily fix them. I'm essentially the only person maintaining TMH next to brion so. —TheDJ (talk • contribs) 08:33, 6 December 2023 (UTC)[reply]

That's weird - when I make a test redirect on File:Test.mp3 and then create TimedText:Test.mp3.en.srt, the latter simply attaches the TimedText to the redirect target. I don't think it did the latter yesterday. Once I break the redirect however in this edit it displays "There is no video associated with the current subtitle page." Now I dunno anymore if splitting the MW messages is warranted or trivial (also, would that be one or two Phab tasks?) Jo-Jo Eumerus (talk) 08:51, 6 December 2023 (UTC)[reply]

Odd variation

Why does {{NUMBEROFARTICLES}} yield different counts when I look at main page, WP:VA3 and WP:VA5.-TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 20:22, 5 December 2023 (UTC)[reply]

The count (as well as most wiki content) is cached for performance reasons. You can refresh it by purging. Articles are created pretty quickly over here on enwiki, so the counts will likely always be a little bit off depending on when the page cache was last purged. Special:Statistics or using mw:API:Siteinfo should be more exact. — MusikAnimal ^talk 20:31, 5 December 2023 (UTC)[reply]

Thx.

Resolved

-TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 05:58, 6 December 2023 (UTC)[reply]

Background colour in table

(i) Does anyone know how you introduce colour to a table background, as here? (ii) Do people think it's effective? (I do—perhaps a slightly paler yellow, though.) Tony (talk) 03:12, 6 December 2023 (UTC)[reply]

@Tony1: the table has this: -style="background:LemonChiffon; color:black" is that what you're asking? WP:COLOR and MOS:COLORS have guidance on the use of colors. RudolfRed (talk) 03:59, 6 December 2023 (UTC)[reply]

Thank you very much, Rudolf.Tony (talk) 04:04, 6 December 2023 (UTC)[reply]

Infobox deletion discussion notice

I’ve noticed that, on the mobile website - for articles that transclude {{Infobox gender and sexual identity}} - the notice that states ‹ The template [X] is being considered for deletion › is displayed at the top of the page (and clashes with the opening sentence), rather than on top of the infobox itself (as I assume it should be doing). As an example, see this screenshot of the Transgender article.

I’m assuming that this is something that may (hopefully!) be able to be fixed by tweaking {{Template for discussion/dated}}, however, I’d have no idea where to start figuring it out myself! Is anyone aware if there’s any way to force the deletion discussion notice to stick to the top of the infobox on mobile web?

Best, ^user:A smart kitten_meow 10:44, 6 December 2023 (UTC)[reply]

The infobox has class="infobox" and is therefore moved down in mobile by mw:Reading/Web/Projects/Lead Paragraph Move. The deletion tag would also move in mobile if it had the infobox class but this adds unwanted formatting. Is there another way to make mobile move it? PrimeHunter (talk) 12:42, 6 December 2023 (UTC)[reply]

@PrimeHunter I went ahead and added the nomobile class for now, feel free to swap it out if someone comes up with a better solution. If there isn't a better solution, we might want to add nomobile to the sidebar option at Template:Template for discussion/dated. --Ahecht (TALK
PAGE) 21:58, 6 December 2023 (UTC)[reply]

@Ahecht One problem with adding nomobile to Template:Template for discussion/dated would be that it would mean people on mobile viewing pages that transclude templates at TfD wouldn’t be notified of the ongoing deletion discussion - and thus some of those who may be affected by a template’s deletion wouldn’t know to take part. Best, ^user:A smart kitten_meow 10:11, 7 December 2023 (UTC)[reply]

@A smart kitten Agreed, it's a stopgap at best, but it's better than implying that the entire transcluding page is going to be deleted. --Ahecht (TALK
PAGE) 18:11, 7 December 2023 (UTC)[reply]

Ahecht only added nomobile to the deletion tag on {{Infobox gender and sexual identity}}. I think infobox templates are rarely nominated. We could make a new class which tries to counteract the unwanted sideeffects of infobox but maybe somebody can find a cleaner way to move a tag along with an infobox in mobile. PrimeHunter (talk) 16:41, 8 December 2023 (UTC)[reply]

This is the first time in ever that I can think of where a TFD/M notice has been complained about in the context of this problem (and no, it has been more rather than less common to nominate infoboxes for TFM). I think documenting the weird placement on mobile on the relevant template page is sufficient. Izno (talk) 18:32, 8 December 2023 (UTC)[reply]

Pale Moon not showing wikipedia page

Pale Moon v32.5.1 (64-bit)

Mac OS X 10.8

Wikipedia not showing text / images; sometimes it shows sidebar only, then text vanishes when scrolling. 83.60.69.61 (talk) 13:41, 6 December 2023 (UTC)[reply]

Pale Moon is not a supported browser and the 11 year old Mac OS 10.8 is not easy to test against either, so it is really difficult to assist with debugging a problem like this. Have you tried the Pale Moon support forums ? These are probably more likely to have experts who can figure out why specific pages won't work in your combination. —TheDJ (talk • contribs) 09:22, 7 December 2023 (UTC)[reply]

Add an "are you sure?" pop-up when you log out

Several times, I have accidentally logged out while trying to view my contributions page. I think that when you press Log Out, there should be a pop-up where you confirm that you actually want to log out and did not just press the button accidentally. QuicoleJR (talk) 14:10, 6 December 2023 (UTC)[reply]

@QuicoleJR you could try or adapt one of these userscripts: User:Fred Gandt/confirmLogout.js, User:Guywan/Scripts/ConfirmLogout. — xaosflux ^Talk 14:14, 6 December 2023 (UTC)[reply]

I don't actually know how to use those. QuicoleJR (talk) 14:21, 6 December 2023 (UTC)[reply]

Hey QuicoleJR, if you edit this file and add the following:

mw.loader.load('//en.wikipedia.org/enwiki/w/index.php?title=User:Fred_Gandt/confirmLogout.js&action=raw&ctype=text/javascript'); // Backlink: [[User:Fred_Gandt/confirmLogout.js]]

You should then be prompted to confirm logging out

— TheresNoTime (talk • they/them) 15:36, 6 December 2023 (UTC)[reply]

I pasted the code in but it didn't work. QuicoleJR (talk) 15:42, 6 December 2023 (UTC)[reply]

@QuicoleJR: Fred Gandt's script didn't work for me either, but Guywan's did. Paste

mw.loader.getScript("/enwiki/w/index.php?title=User:Guywan/Scripts/ConfirmLogout.js&action=raw&ctype=text/javascript"); // Backlink: [[User:Guywan/Scripts/ConfirmLogout.js]]

into your common.js, and it should work. Cremastra (talk) 22:00, 6 December 2023 (UTC)[reply]

That did not work for me either. QuicoleJR (talk) 22:25, 6 December 2023 (UTC)[reply]

You can try accessing your My Contributions page using a hotkey. In Chrome you can use Alt-Y or Alt-Shift-Y, I think. hotkeys vary by browser and operating system, but the one for My Contributions will contain the letter Y. –Novem Linguae (talk) 14:27, 6 December 2023 (UTC)[reply]

@Novem Linguae: Thank you for the suggestion, but I edit on a mobile device, so that will not work for me. QuicoleJR (talk) 14:41, 6 December 2023 (UTC)[reply]

Are you using a browser (MinervaNeue skin), Wikipedia iOS app, or Wikipedia Android app? –Novem Linguae (talk) 14:47, 6 December 2023 (UTC)[reply]

Browser, but using Vector 2022 skin. QuicoleJR (talk) 15:37, 6 December 2023 (UTC)[reply]

Hidden ToC dis-appeares on it's own during scrolling

Tracked in Phabricator
Task T352930

Tracked in Phabricator
Task T352432

If, on my user page ( Steue ) ,

I have the Table of Content ( ToC ) hidden, and
do click into this little field to the left of my user name,
the ToC does open downwards.
Then I move my mouse pointer into this ToC and
then I start scrolling down ( with a side sweep on my touch pad ) within this ToC, which means:
the box with the ToC ( including the whole page i.e. what is out-side of the ToC ) is moving up-wards. - So far, so good.
But when a few upper parts of my 4th main section have appeared,
the whole ToC disappears - and this is not what I expect and want.

The result is:
The only way I can reach the lower sections of my ToC is by moving the ToC to the left---besides scrolling down the actual content.

What I want:
Once the Table of Content is dropped down, it should be scrollable down to the last line, and not dis-appear mid-way of scrolling.

Ping welcome, Steue (talk) 21:01, 6 December 2023 (UTC)[reply]

@Steue tried to duplicate, here is what I saw - is this what you see? If you scroll down enough so that the top of the collapsed TOC scrolls off the page, it moves (collapsed) to the header, to the left the of page title which also moves there. — xaosflux ^Talk 21:20, 6 December 2023 (UTC)[reply]

@ xaosflux

Exactly: If the top of the open ToC goes over the top, the ToC collapses.

My system: (I confess) Windows 8.1 and Firefox (as late as possible) 115.5.0esr (64-bit); mozilla-win-eol-esr115 - 1.0 .

Steue (talk) 21:29, 6 December 2023 (UTC)[reply]

@Steue: I've opened bug phab:T352930 on this. Please feel free to add additional information there, or subscribe to it for updates. This is not a condition that is happening only here on the English Wikipedia, but one that would need to be resolved in the software. — xaosflux ^Talk 23:44, 6 December 2023 (UTC)[reply]

@xaosflux: Thanks for the info and especially the task to Phab, because I don't have an e-mail address, so I can't register to Phab.

Steue (talk) 00:12, 7 December 2023 (UTC)[reply]

@Steue: looks like this is a duplicate report of phab:T352432; can you see if that page looks right to you when using upcoming Zebra 1? — xaosflux ^Talk 00:27, 7 December 2023 (UTC)[reply]

Hidden templates creating whitespace

On the page Duloxetine, three sequential "Use..." templates seem to create a big whitespace gap/line breaks after the Distinguish hatnote:

Removal of any one of them seems to remove this, perhaps there is an extra line break in one of them? There is also a hidden section name before the lead paragraph starts if that might complicate things. Could also be related to paragraph breaks seemingly having gotten bigger sometime last month? 9³ (talk) 04:11, 7 December 2023 (UTC)[reply]

There is nothing to be done about this, one too many templates in a row, even empty will do this. The best you can do is pick one and move it up a line.

I question the value of at least one of those templates, and probably a second of them... Izno (talk) 04:43, 7 December 2023 (UTC)[reply]

If one or all of these templates is edited to output a <nowiki /> tag, then the generated lines, after template expansion, will no longer be completely blank, and the parser will no longer see consecutive blank lines. This removes the white space. Tested by previewing User:John of Reading/X3 while editing Template:Use vanc name-list-style. -- John of Reading (talk) 08:16, 7 December 2023 (UTC)[reply]

Redlinked assessment categories, again

There's been a recurring issue at Special:WantedCategories with the "vital=" flag in a template autogenerating assessment categories that not only don't exist, but don't even seem to correspond to any established assessment queues at all.

For instance, "vital articles in Biology" is a thing that genuinely exists, while "vital articles in Biological and health sciences" is not, and yet things like Category:B-Class vital articles in Biological and health sciences, Category:Wikipedia level-5 vital articles in Biological and health sciences, Category:Start-Class vital articles in Biological and health sciences and Category:Wikipedia vital articles in Biological and health sciences have shown up as redlinks despite "biology" equivalents already existing for all three of those things — but I can find no trace of a reason why vital= is funnelling a random smattering of articles into "biological and health sciences" instead of "biology", even while funnelling most articles into "biology". I've redirected them all to their "biology" equivalents already, but the contents aren't moving.

And by the same token, "vital articles in Society" is a thing, while "Vital articles in society and social sciences" is not, but that didn't stop the generation of Category:B-Class vital articles in Society and social sciences, Category:List-Class vital articles in Society and social sciences, Category:Start-Class vital articles in Society and social sciences and Category:Unassessed vital articles in Society and social sciences.

But try as I might, I can't find hide nor hair of a reason why the vital= flag is filtering some articles into different categories than it filters other equivalent articles. Could somebody with more experience working with WikiProject templates look into this? Bearcat (talk) 17:02, 7 December 2023 (UTC)[reply]

I took a look at Talk:Cyrillic alphabets being in Category:List-Class vital articles in Society and social sciences for you. It appears to be due to data in Wikipedia:Vital articles/data/C.json maintained by User:Cewbot which is operated by @Kanashimi. Pinging them to the discussion. Anomie ⚔ 13:02, 8 December 2023 (UTC)[reply]

I think this is because the topic is different from the section title, please refer to User:Cewbot/log/20200122/configuration#Topics. This issue is expected to be solved by the following steps:

Wikipedia:Bots/Requests for approval/Cewbot 12 - The process is expected to take a couple of months.
Delete the setting of User:Cewbot/log/20200122/configuration#Topics.
Merge {{VA}} into {{WPBS}}
Rename the categories

Kanashimi (talk) 13:24, 8 December 2023 (UTC)[reply]

We could solve this today by updating the topic fields in the .json files to be consistent — Martin (MSGJ · talk) 13:38, 8 December 2023 (UTC)[reply]

I am following up at Wikipedia talk:Vital articles#Topics — Martin (MSGJ · talk) 14:33, 8 December 2023 (UTC)[reply]

Heads up for all tool users

As noted above in #Toolforge Grid Engine shutdown, some old infrastructure which supports a lot of tools is getting shut down soon. Mostly this is of interest to people who maintain those tools, but it affects users too. Please take a look at the list of tools still running on Grid Engine. If you see any tools you depend on, this might be a good time to start bugging whoever maintains that tool to make sure it's going to get migrated to the new infrastructure called Kubernetes.

If you're interested in the technical details, you can read more on wikitech. For those of you who aren't into the technical details, all you really need to know is that if the people who maintain the tool you use aren't working on migrating it, you should be working on finding a different tool to use before the one you're using now goes away. The most recent report says there's 445 tools yet to be migrated. With 6 migrations in the previous week and about 10 weeks to go before the toolpocolypse, the math doesn't look good. RoySmith (talk) 17:45, 7 December 2023 (UTC)[reply]

How are regular editors supposed to read that report and know whether a tool they rely on will break? It might be helpful for the Grid Engine administrators to schedule a planned multi-day or one-week outage between now and the drop-dead date, so that when tools break during that planned outage, we (1) know what still needs to be migrated and (2) still have access to the tools for a few weeks before they go away. – Jonesey95 (talk) 19:10, 7 December 2023 (UTC)[reply]

It looks like a serious step backwards in terms of tool availability. A wikiproject I work on has already been seriously hit by unmaintained tools stopping working due to internal database changes, and we'll be losing more soon when the useful columns are removed from the pagelinks table. Certes (talk) 19:19, 7 December 2023 (UTC)[reply]

Unfortunately the wiki sites grow a lot and as such, things have to change every now and then, to keep everything working and maintainable. The tools are something with a lot of access to the internals of the software stack and are thus pretty vulnerable to breakage of these specific mentioned changes, especially if they are effectively orphaned tools. But that's not really what we have here, this is more a case of how tools are run, which for most tools shouldn't be too difficult to fix (the biggest problem is likely with systems that were already shaky or that use a lot of external dependencies). If everyone pitches in, it's probably not going to be as bad as it looks right now. For instance, i've done a casual check of about 15 tools on that list, and about half aren't even working to begin with, so... —TheDJ (talk • contribs) 20:05, 7 December 2023 (UTC)[reply]

It's the 15 tools that we really rely on that I worry about, and I have no idea how to pick them out of the giant list. – Jonesey95 (talk) 20:19, 7 December 2023 (UTC)[reply]

You really rely on 15 tools (!). I started trying to compile a list of tools I recognized that would be affected, and gave up at around the letter "G" after realizing there would be too many to properly list. And the apocalypse is in one week (when "Any maintainer who has not responded on phabricator will have tools shutdown and crontabs commented out"), not 10 weeks. And it will be bad. — Preceding unsigned comment added by Pppery (talk • contribs) 20:53, 7 December 2023 (UTC)[reply]

I see there's some additional historical context (post within a thread), and an "Assurances and Support" post from the team from Friday, which may help folks who are just reading-along here. HTH. Quiddity (WMF) (talk) 21:27, 9 December 2023 (UTC)[reply]

There is a very rudimentary tool that helps developers convert from crontab to toolforge jobs framework .yaml file. --Kanashimi (talk) 01:44, 10 December 2023 (UTC)[reply]

If I'm reading it right, then the standouts to me in a quick scan are AfDStats, Yapperbot, Musikbot, and wugbot. Those would all go down if their maintainers don't do something in the next few months? Firefangledfeathers (talk / contribs) 05:31, 10 December 2023 (UTC)[reply]

There are also tools which help with disambiguation, producing reports such as Disambiguation pages with links. We're aware of these but haven't yet fixed them. Certes (talk) 16:19, 10 December 2023 (UTC)[reply]

Triangles in Special:Watchlist too big and pointing wrong way

~~WP:ITSTHURSDAY I imagine.~~ If you set your watchlist settings just right, each page's revisions will be collapsed until you click on a triangle. At that point the triangle will go from facing down to facing right, and the page's revisions will go from hidden to shown.

Anyway, this triangle recently doubled in size, and now always points down (won't point to the right when you click on it). This is on Vector and Vector 2022. Was not able to reproduce for Monobook.

The problem goes away in safemode, so the bug fix may need to be made in a local gadget related rather than MediaWiki core.

~~I suspect Vector changed the name or nesting of one of their elements, breaking our local gadget.~~

Files that might need repair (search for mw-enhancedchanges-arrow):

MediaWiki:Gadget-WatchlistGreenIndicators.css

–Novem Linguae (talk) 00:11, 8 December 2023 (UTC)[reply]

No train today, but I think this series of edits is likely the cause. Will wait for someone else's opinion before reverting. –Novem Linguae (talk) 00:49, 8 December 2023 (UTC)[reply]

Please don't. phab:T352456 fixed the watchlist display for me. There is an image in that task that shows how the arrows in my watchlist looked before the fix. Now uncollapsed watched items are marked by right-pointing arrows (much the same as collapsed categories on category pages). When uncollapsed, the watchlist arrows point down, again just like uncollapsed categories on category pages.

For me: chrome current, win10; at Special:Preferences#mw-prefsection-watchlist: Expand watchlist to show all changes, not just the most recent, Use non-JavaScript interface; at Special:Preferences#mw-prefsection-gadgets: Display green collapsible arrows and green bullets for changed pages in your watchlist, page history and recent changes (unavailable with the improved Watchlist user interface); all are checked.

—Trappist the monk (talk) 01:24, 8 December 2023 (UTC)[reply]

Yeah, I noticed this last Thursday, but I sometimes I tire of reporting bugs that never get fixed and have to go lie on my fainting couch for a while. Both the arrow direction and the uneven vertical alignment are fixed today. Thanks for reporting it, Trappist. Happy Thursday! – Jonesey95 (talk) 02:06, 8 December 2023 (UTC)[reply]

Fixed for me today too. Sometimes it's good that it [wa]s Thursday. Certes (talk) 11:13, 8 December 2023 (UTC)[reply]

I think I fixed it with these two changes: https://en.wikipedia.org/enwiki/w/index.php?title=MediaWiki%3AGadget-WatchlistGreenIndicators.css&diff=1188922324&oldid=1188825350

When the arrows were fixed for all of you above who enabled "Watchlist → Use non-JavaScript interface" in preferences, the same change also broke them for anyone who has it disabled. They should work correctly for everyone now. Matma Rex talk 15:25, 8 December 2023 (UTC)[reply]

Yeap, all fixed. Thank you!

Resolved

–Novem Linguae (talk) 21:23, 8 December 2023 (UTC)[reply]

Fixing Citoid created references for Youtube

Hi all

Youtube is the second most popular website in the world, with a huge number of reliable news sources using it as a platform for sharing video. Unfortunately Citoid doesn't work properly for creating refs for Youtube currently. This leads to poor quality labelling of references being made, and while there are some templates to specifically cite video content, they aren't user friendly at all. I started a Phabricator ticket in 2021 to try and address this issue, however its not been worked on. Can I request anyone interested in this:

Subscribe to the Phabricator task so its made clear this is an issue many people would like to be fixed.
Try citing Youtube videos in articles and give feedback in the Phab task if you notice anything I haven't mentioned.

Also just to say I've seen a couple of people say "Youtube is an unreliable source and shouldn't be used", I think this is a missunderstanding of what the platform is, its the channels that should be assessed for reliability rather than the publishing platform as a whole. E.g the BBC News channel is reliable (its listed under Perennialy reliable sources on en.wiki), where as My Toy Reviews or DailyWire or whatever are obviously not reliable.

Thanks very much

John Cummings (talk) 07:11, 8 December 2023 (UTC)[reply]

@John Cummings This might be a good task for the next Community Wishlist Survey. --Ahecht (TALK
PAGE) 17:08, 11 December 2023 (UTC)[reply]

CfD closure requiring template editor intervention

Wikipedia:Categories_for_discussion/Log/2023_November_28#Category:Templates_calling_Infobox_officeholder needs template editor assistance in closing, as it seems to be populated by a template (likely the template-protected {{Infobox officeholder}}), and I can't discern from the code of the sole member, {{Infobox Native American leader}}, if this is the case. –LaundryPizza03 (d c̄) 15:54, 8 December 2023 (UTC)[reply]

Done. It was populated by {{Wraps infobox}} on the documentation page — Martin (MSGJ · talk) 16:22, 8 December 2023 (UTC)[reply]

* in comment table?

Looking over some really old revisions, I see some where the wiki shows an empty comment, but the database has '*' as the value of comment.comment_text. These are mostly in 2001 and 2002, but I'm seeing a few as late as 2006. What's this all about? Some kind of primordial data corruption? RoySmith (talk) 04:51, 9 December 2023 (UTC)[reply]

Not primordial data corruption - if you type "*" as your edit summary today (as I did in this edit, and my previous one to the sandbox), it appears as no summary. * Pppery * _{it has begun...} 05:11, 9 December 2023 (UTC)[reply]

Interestingly, the * edit summary appears when I view the diff on mobile web, but not when I look in Special:Contribs (or when I switch to desktop mode). Best, ^user:A smart kitten_meow 07:10, 9 December 2023 (UTC)[reply]

It's apparently deliberate, and being visible in Special:MobileDiff (example) is probably a bug. —Cryptic 08:41, 9 December 2023 (UTC)[reply]

The API [1] also shows it but that's not a bug. The API always shows the stored characters without formatting. PrimeHunter (talk) 10:26, 9 December 2023 (UTC)[reply]

Image captions are displayed incorrectly inside infoboxes

See this discussion: is it possible to display captions from {{Multiple image}} in an infobox without shrinking the font size? Jarble (talk) 15:57, 10 December 2023 (UTC)[reply]

How to get top 100 categories available in most Wikipedias, but not created in a specific Wikipedia?

Hi, I wonder if we can get top 100 categories available on most Wikipedias, but still not created in a specific Wikipedia. Use Quarry (which I want this way if you can), API, SPARQL or any other way you prefer. If you can, add an optional condition to exclude those have __HIDDENCAT__ property, tracking and maintenance categories. Thanks! ⇒ Aram Talk 05:55, 11 December 2023 (UTC)[reply]

You can ask at d:WD:RAQ or d:WD:PC, they will know better. Izno (talk) 18:38, 11 December 2023 (UTC)[reply]

Hiding admin buttons

Could someone please provide the user script code to hide my admin buttons (blocking users, protecting pages), except those related to files? Thank you. --Leyo 09:22, 11 December 2023 (UTC)[reply]

Here's a quick script that will hide block, protect, and unprotect buttons. Add to User:Leyo/common.css, not User:Leyo/common.js. May need to do a hard refresh on each page for awhile (Ctrl-F5) after installing, since CSS files are usually cached.

#ca-unprotect, #ca-protect, span:has(> .mw-usertoollinks-block), #t-blockip {display: none;}

I can do more work on this if you let me know exactly what you need. Is your end goal to hide every single admin button (delete, undelete, change usergroups, etc.) except in the file namespace? –Novem Linguae (talk) 09:49, 11 December 2023 (UTC)[reply]

Special:ListGroupRights#sysop is longer than you may expect but many of them don't have buttons or aren't admin-specific. PrimeHunter (talk) 10:36, 11 December 2023 (UTC)[reply]

Thank you, Novem Linguae. When inserting this line to my .css (in preview mode), I get the following warning: Error: Expected RPAREN at line 2, col 38.

It's mainly about the buttons where there's a danger that I might forget my promise not to use them in relation to users, e.g. in case of vandalism, because I'm still using these buttons in two other projects. --Leyo 10:51, 11 December 2023 (UTC)[reply]

It worked for me. Did you copy paste correctly? Paren probably means parenthesis, so maybe double check that you copied all parentheses. –Novem Linguae (talk) 11:19, 11 December 2023 (UTC)[reply]

The validation used by mw:Extension:CodeEditor probably doesn't know about :has(). That error shouldn't prevent saving, and as long as your browser has support for it you should be ok. Anomie ⚔ 12:35, 11 December 2023 (UTC)[reply]

I've now saved it, where I got an error message. On one PC that I regularly use, the FF version is 115.4.0esr, i.e. too old. Is there an option without the has() function? --Leyo 13:24, 11 December 2023 (UTC)[reply]

Just change span:has(> .mw-usertoollinks-block) to .mw-usertoollinks-block, you get extra brackets but it's not a big deal. Nardog (talk) 13:37, 11 December 2023 (UTC)[reply]

Thank you, it works now. It would be great, if the block button in Special:Contributions as well as the deletion button for pages (i.e. except files) could be hidden, too. --Leyo 13:51, 11 December 2023 (UTC)[reply]

To do the file thing, we need to switch to JavaScript. So go ahead and delete the code from your common.css file, then add this to common.js:

mw.util.addCSS( '#ca-unprotect, #ca-protect, .mw-usertoollinks-block, #t-blockip, .mw-contributions-link-block {display: none;}' );
if ( mw.config.get('wgNamespaceNumber') !== 6 && mw.config.get('wgNamespaceNumber') !== 7 ) {
    mw.util.addCSS( '#ca-delete {display: none;}' );
}

–Novem Linguae (talk) 14:31, 11 December 2023 (UTC)[reply]

File pages have body.ns-6 and file talk has body.ns-7, which should be enough to do this without resorting to javascript (and the attendant FOUC). —Cryptic 14:39, 11 December 2023 (UTC)[reply]

I've just implemented Novem Linguae's JS code, but haven't yet deleted the CSS code. You are the experts. I'll just implement what you recommend. --Leyo 14:56, 11 December 2023 (UTC)[reply]

You can remove the CSS, since the JS does the same thing and more. Glad you are finding it helpful. –Novem Linguae (talk) 15:06, 11 December 2023 (UTC)[reply]

I was referring to Cryptic's comment that a CSS version would be possible and potentially favorable. --Leyo 15:36, 11 December 2023 (UTC)[reply]

Remove the JS and restore the CSS (amended per Cryptic):

#ca-unprotect,
#ca-protect,
.mw-usertoollinks-block,
#t-blockip,
.mw-contributions-link-block,
body:not(.ns-6):not(.ns-7) #ca-delete {
	display: none;
}

Nardog (talk) 20:15, 11 December 2023 (UTC)[reply]

Thank you. I implemented it. However, I still see the block and mass delete in Special:Contributions. --Leyo 21:37, 11 December 2023 (UTC)[reply]

How about now (edited the code above)? Nardog (talk) 21:42, 11 December 2023 (UTC)[reply]

Thanks, the first-mentioned button is gone now. For the latter, these is actually no danger that I could forget about my promise. I don't think that I have ever used this button. --Leyo 22:04, 11 December 2023 (UTC)[reply]

Improvements to styling of Vector 2022

Hi everyone. Today, the Web team from the Wikimedia Foundation will introduce improvements to the styling of the Vector 2022 skin. For those of you following our updates, you might recognize some of these as a subset of the previously tested content separation (Zebra) prototype. In particular you will see:

New background colors for the main menu that now match the remainder of our menus
New styling for the show and hide buttons for menus.
Bolding of menu titles

You will find more details in the project update on MediaWiki.org. These changes will also resolve some of the recent bugs with the table of contents, such as this ticket about scrollable elements. Please let us know what you think of these tweaks and if you have any further questions! SGrabarczuk (WMF) (talk) 18:30, 11 December 2023 (UTC)[reply]

Are these screen shots intended to show the exact same page, in the same configuration, before and after the changes? If so, it looks like the column dedicated to content, the thing everyone comes to Wikipedia for, has gotten even narrower, when it was already much too narrow to begin with. I hope this is not the case.

(Edited to add this rant: I just confirmed this in another browser, logged out. At John Dalton, with the (fewer visible vertical elements) TOC showing, and the Tools sidebar displayed, the content column shrank from 670 pixels wide to 618 pixels wide, just 50% of my 1228-pixel-wide browser window. With custom CSS that makes Vector 2022 more usable, I am able to get the content column to 856 pixels wide, 70% of the available space. And this isn't even addressing the unused vertical space at the top of the window that means even more vertical scrolling for our readers. I've got that ancient phab link around here somewhere, maybe T325219.) – Jonesey95 (talk) 21:47, 11 December 2023 (UTC)[reply]

Template talk:Static row numbers#bnwiki

Can anyone help fix it? আফতাবুজ্জামান (talk) 19:59, 11 December 2023 (UTC)[reply]