Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

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

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

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

Vector 2022 deployment - part 4

Sudden vector-2022 update?

Is it just me, or the "Tools" menu, and "General","Import/export","In other projects" moved to the right sidebar? —CX Zoom[he/him] ^{(let's talk • {C•X})} 21:16, 23 January 2023 (UTC)

They probably deployed it earlier than planned, based on some feedback. Was always going to arrive this or next week though. —TheDJ (talk • contribs) 21:23, 23 January 2023 (UTC)

As stated at Wikipedia:Vector 2022#A very brief timeline This change has been set to happen on the Week of January 23, 2023 since before the skin was deployed wednesday last week. Terasail^[✉️] 21:27, 23 January 2023 (UTC)

... with a sign on the door saying ‘Beware of the Leopard. TheMissingMuse (talk) 03:09, 28 January 2023 (UTC)

User contributions page breakage

Broken contribs page by CX Zoom as on 20230123

Resolved

Tracked in Phabricator
Task T327715

Interface of Special:Contributions/CX_Zoom is also broken, all of a sudden. Windows 11, latest version of MS Edge. —CX Zoom[he/him] ^{(let's talk • {C•X})} 21:22, 23 January 2023 (UTC)

Added a screenshot. This occurs with or without hiding the tools menu. —CX Zoom[he/him] ^{(let's talk • {C•X})} 21:28, 23 January 2023 (UTC)

I don't see that, the only issues I have with the tools sidebar is the Atom link is over the icon and the edit interlanguage links link isn't well formatted. Terasail^[✉️] 21:38, 23 January 2023 (UTC)

I wondered if it is some script doing these, but then I used safemode and it still shows up like this. Idk somethingis wrong with whatever they did. It was all fine 1 hour ago. —CX Zoom[he/him] ^{(let's talk • {C•X})} 21:41, 23 January 2023 (UTC)

I filed this as phab:T327715 Seems a conflict with the content translation beta. —TheDJ (talk • contribs) 21:45, 23 January 2023 (UTC)

Hey @CX Zoom, @TheDJ, @Terasail - thanks for reporting! We're looking into this right now and hope to have a quick fix by the end of the day/first thing tomorrow. OVasileva (WMF) (talk) 22:31, 23 January 2023 (UTC)

The fix for this was deployed —TheDJ (talk • contribs) 00:16, 26 January 2023 (UTC)

Vector 2022 Contributions bug

Resolved

This is what my contributions page looks like in all browsers (upt-to-date):

Coldbolt (talk) 10:59, 24 January 2023 (UTC)

@Coldbolt: Does this also happen on https://en.wikipedia.org/enwiki/w/index.php?title=Special%3AContributions&target=Coldbolt&safemode=1 (using safemode)? --Malyacko (talk) 11:29, 24 January 2023 (UTC)

@Malyacko: Unfortunately, yes. I'm trying to figure out what the problem is but I haven't found a solution yet. Coldbolt (talk) 12:11, 24 January 2023 (UTC)

Update: It is a 100% Vector 2022 bug because the problem doesn't exist with Vector 2010. I hope someone from the tech team can pick this up. @SGrabarczuk (WMF): Coldbolt (talk) 12:15, 24 January 2023 (UTC)

@Coldbolt Already covered above with phab tracking. — 🍊 Paper9oll 🍊 (🔔 • 📝) 12:24, 24 January 2023 (UTC)

Thanks I see! Coldbolt (talk) 12:27, 24 January 2023 (UTC)

Teeny text column on a laptop

Jane Austen, text column = five to seven words

I was just working on Jane Austen and it suddenly shrunk down to nothing!! Now the infobox and the two columns w/ tools appear wider than the lead text. This is 100% (not zoomed), 13 inch screen, set at 1280. Not an improvement. Victoria (tk) 21:50, 23 January 2023 (UTC)

Some options until the WMF cleans up a variety of whitespace and font size problems are to switch back to Vector 2010 (Preferences -> Appearance -> Vector 2010 -> Save), hide the Tools sidebar (which will make it move to a menu at the upper left), or customize your vector-2022.css file (scary if you are not a geek). – Jonesey95 (talk) 22:08, 23 January 2023 (UTC)

Thanks, Jonesey95, I've hidden the tool bar but it seems to need hiding w/ every page refresh, plus the other issues mentioned in this thread. I know I can change back, but have been giving V22 a test drive. There are some things I like about it and I've spent the past few days trying to get my eyes used to it. I posted the screenshot so the devs can see what a random laptop user who doesn't have access to prefs etc sees. It's not great. Pinging AHollender (WMF). Is this what you all have in mind for MacBook users? Victoria (tk) 22:21, 23 January 2023 (UTC)

If you collapse any menu, then it should save when you refresh the page. If your connection is being slow or you are expanding it in another tab there's a chance it's not working as expected. Can you try collapsing it, waiting 5 seconds then hard refresh the page? If this is still happening let me know and I'll look into this more first thing tomorrow. Jdlrobson (talk) 01:33, 24 January 2023 (UTC)

Hi Jdlrobson, thanks for the reply. Yes, it's more persistent now than it was. But it seems to depend on namespace. I.e if I have everything collapsed (including TOC) to get a decently sized text column, that doesn't persist from article to article. Furthermore, edit mode is full width (which is really really nice!), but preview isn't persistently in full width - I just ran into that on Maxfield Parrish where I was moving around images - some of the previews were in full width w/out TOC, others w/ TOC and w/ the narrow text column.

But all that aside, the biggest concern is that on a laptop the text column is absurdly small (I've since changed screen res to 1440, but w/out much effect); the infoboxes are huge and images are squashing out text. I have the luxury to set preferences, to fiddle, and to play with to get it right. A casual reader logged out reader won't. Victoria (tk) 01:50, 24 January 2023 (UTC)

Adding, in this edit the edit window was the size of the small text column, though TOC and tools were collapsed. As I'm typing this the edit window is the width of the screen. So the sizing isn't persistent. Victoria (tk) 02:10, 24 January 2023 (UTC)

The preview not being in full width is a known bug, T322385. – Jonesey95 (talk) 02:30, 24 January 2023 (UTC)

Now the opposite is happening. In article space the edit window is about 150% or more too long - about one to two pages long w/ only a portion visible. I zoomed out to 50% and still couldn't see the entire edit window. The same behavior is not happening here on this page. Seems to be only be this section on this page. Weird. Victoria (tk) 22:07, 26 January 2023 (UTC)

I encountered the same problem too. I re-enabled Preferences → Appearance → Skin preferences → Enable limited width mode and it seems to be okay for now. —Tenryuu 🐲 ( 💬 • 📝 ) 00:07, 27 January 2023 (UTC)

Atom link icon problem

Tracked in Phabricator
Task T327717

The icon next to the atom link overlaps with the link itself. This happens on pages that have feeds, like user contribution pages etc. —TheDJ (talk • contribs) 21:51, 23 January 2023 (UTC)

Ah I see that I wrote a duplicate phab ticket as you... I also reported the atom issue along with edit interlanguage links formatting that I am seeing phab:T327719 Terasail^[✉️] 21:55, 23 January 2023 (UTC)

If you want a temp fix, add #feed-atom { background-image: none; } to Special:Mypage/vector-2022.css --Chris 22:41, 23 January 2023 (UTC)

A new menu in the Vector 2022 skin

A bit more details, as well as more upcoming changes are available in this post on the RfC page.

Hey everyone,

Thank you all for continuing the conversation on the new skin and reporting thoughts, issues, and bugs as you come across them. Today, the new page tools menu was deployed to the Vector 2022 skin for logged-in users. This menu allows for a separation between navigation that is related to the entire wiki (Main page, random page, etc) and tools that are related to a specific page (what links here, related changes, cite this page, etc). It also collects all page-specific tools in a single menu, rather than splitting them between the main menu and the more menu. More information is available on the project page. Moving this menu to the right side of the page has the benefit of showing the table of contents further up the page without requiring people to scroll down to see the table of contents. We’ve noticed that this is one of the concerns we’ve been hearing over the last couple of days and hope this addresses it.

Let us know if you have any questions or experience issues with the tools menu. Thank you @CX Zoom, TheDJ, and Terasail: for reporting the menu doesn’t work with the Content Translation beta feature on the Contributions page - a quick fix for this will be available tomorrow morning. In a few weeks, we also plan to make the pinned menu sticky, just as the Table of Contents and the left menu.

We’ll keep updating here as well as changes and fixes are made over the next couple of weeks. Thank you! OVasileva (WMF) (talk) 00:44, 24 January 2023 (UTC)

The new tools menu appears to be creating a bug for me on some disambiguation pages, eg. ¿Dónde está Elisa?, where a large black space appears matching the vertical space taken up by the "Actions" tools. It does not appear on incognito, which suggests it relates to the tools. It also does not appear for every disambiguation page, as far as I can tell it appears on shorter disambiguation pages, pages like French are unaffected. CMD (talk) 05:05, 24 January 2023 (UTC)

Did you mean a "large blank space"? If so, this is T327714. – Jonesey95 (talk) 06:30, 24 January 2023 (UTC)

That's right, thank you, that Phab is exactly it. CMD (talk) 09:57, 24 January 2023 (UTC)

@Jonesey95, @Chipmunkdavis - thanks again for the quick report! This is now resolved. OVasileva (WMF) (talk) 22:53, 25 January 2023 (UTC)

Preview broken on 2017 wikitext editor

Tracked in Phabricator
Task T327778

Preview on template (Infobox person)

Preview on article (today's featured article)

Preview is currently broken when editing using 2017 wikitext editor (I don't edit using 2010 wikitext editor because it lacks keyboard shortcuts which is required for my day-to-day editing of which I got so used to using keyboard shortcuts (embed into my mind) that I can no longer move away from). I have tested with or without safemode on various namespace (main, talk, template), both yields the same results where the entire page content would be flushed entirely to the right side of the screen, leaving a huge chunk of whitespace on the left. — 🍊 Paper9oll 🍊 (🔔 • 📝) 07:13, 24 January 2023 (UTC)

Update: This issue is caused due to the coding changing to use rubbish CSS grid instead. Forcing .mw-body to use display: block!important fixed it but is rather a makeshift fix only which of course requires editor that uses 2017 wikitext editor to add the css styling to their common.css. — 🍊 Paper9oll 🍊 (🔔 • 📝) 12:20, 24 January 2023 (UTC)

@Paper9oll - thanks for the report! We have a fix for this that will be available by the end of the day. OVasileva (WMF) (talk) 20:05, 24 January 2023 (UTC)

@Paper9oll: Thanks for fining that temporary fix. It worked for me. Donald Albury 20:15, 24 January 2023 (UTC)

@Paper9oll, I can reproduce this in Safari/macOS, but it's flush-left for me. Whatamidoing (WMF) (talk) 19:25, 25 January 2023 (UTC)

@Whatamidoing (WMF) I think the fixes has been rolled out as I don't see the content flushed to the right anymore when previewing changes. @OVasileva (WMF) Correct me if I'm wrong. — 🍊 Paper9oll 🍊 (🔔 • 📝) 04:55, 26 January 2023 (UTC)

@Paper9oll - yes, this should be fixed now! We deployed the fix yesterday afternoon. OVasileva (WMF) (talk) 00:17, 27 January 2023 (UTC)

Vector 2020 left side toolbar not sticky

Should it not be sticky? (like the ToC) · · · Peter Southwood ^(talk): 10:00, 24 January 2023 (UTC)

There's a task for this. Sojourner in the earth (talk) 10:14, 24 January 2023 (UTC)

İ totally hating new design right now

even, i cannot find village pump easy!! bring back old design!! or make old design as default design!!! ----modern_primat ඞඞඞ ^TALK 18:32, 25 January 2023 (UTC)

@Modern primat, how were you previously finding the village pumps here at the English Wikipedia? Commons has a link in the sidebar for both Vector 2010 and Vector 2022, but the English Wikipedia doesn't, and hasn't for many years. Whatamidoing (WMF) (talk) 18:55, 25 January 2023 (UTC)

i forgor how to we find village pumps her. but... i dont know..... ----modern_primat ඞඞඞ ^TALK 19:11, 25 January 2023 (UTC)

There's a link on the Main Page, in the section "Other areas of Wikipedia", and similar links on other high-traffic pages. I think most experienced editors just search for the name in the search bar. Whatamidoing (WMF) (talk) 19:28, 25 January 2023 (UTC)

Hidden code in Vector showing when a Wikipedia page is linked in the Discourse app

Tracked in Phabricator
Task T328046

Since the transfer to Vector, a hidden code about « not-logged-in editors » is showing up when a link to a Wikipedia article is linked in the Discourse message board app.

See the discussion here on the Straight Dope Message Board:

https://boards.straightdope.com/t/wiki-links-pages-for-logged-out-editors-learn-more/978807

Don’t know if anything can be done about it, but thought I’d draw it to your attention. Mr Serjeant Buzfuz (talk) 15:57, 26 January 2023 (UTC)

The vector-2022 menu ("..." menu in the top right corner) does contain that label, and the rendered page does include:

<div class="vector-user-menu-anon-editor">
			<p>
				Pages for logged out editors <a data-mw="interface"
    href="/wiki/Help:Introduction"
     aria-label="Learn more about editing"><span>learn more</span></a>

			</p>
		</div>

— xaosflux ^Talk 16:54, 26 January 2023 (UTC)

@Mr Serjeant Buzfuz: I've opened a feature request at phab:T328046. — xaosflux ^Talk 17:00, 26 January 2023 (UTC)

Thanks!Mr Serjeant Buzfuz (talk) 19:05, 26 January 2023 (UTC)

Hiding table of contents by default

Tracked in Phabricator
Task T316060

I prefer to keep the table of contents hidden when using Vector 2022, but I have to hide it every time I load a new page. Is there a way to have it hidden by default? If not, is this planned in the near future? Thebiguglyalien (talk) 19:16, 26 January 2023 (UTC)

@Thebiguglyalien: I think what you are looking for is being worked on in phab:T316060. If you can wait to see if that gets rolled out, it will be better than writing a custom script just to hide it for you. — xaosflux ^Talk 19:24, 26 January 2023 (UTC)

Thank you, this is what I was looking for. Crazy that this isn't the default behavior already. Thebiguglyalien (talk) 19:30, 26 January 2023 (UTC)

horizontal scroll bar in diff view with vector2022 when there is a long word

When viewing this diff with the vector2022 skin, the page width is extended to accommodate more of the lengthy URL that was added in the edit, resulting in a horizontal scrollbar. This happens for me in both the visual diffmode and the source diffmode. Viewing the diff with the vector skin, the page width is kept to the browser width and so no horizontal scrollbar is added. When I edited the section to hide the long URL, the edit screen was also wider than my browser width, including the edit box. To the vector2022 development team: can the page width be limited in this scenario to not exceed the browser window width? isaacl (talk) 23:11, 26 January 2023 (UTC)

@Isaacl I don't seem to be getting that problem on a logged out account - any chance you have something else pushing it over? If you do scroll to the right, what is over there? — xaosflux ^Talk 23:18, 26 January 2023 (UTC)

I'm not seeing this issue either in an anonymous browser window. Do you see it when logged into your account? I see the rest of the page when scrolling to the right: the Wikipedia page is being rendered across the entire extended width of the page, making it hard to read the page or see the diff. I'm not using any gadgets or features that add widgets to the page, as far as I recall. I have the main sidebar collapsed and the table of contents sidebar enabled, but toggling those doesn't change the overflowing page width. isaacl (talk) 23:58, 26 January 2023 (UTC)

As I just linked to someone on IRC, this is in the ballpark of phab:T327886. Izno (talk) 23:19, 26 January 2023 (UTC)

I reported this earlier in another thread [1]. It seems to be happening randomly. Victoria (tk) 00:01, 27 January 2023 (UTC)

The huge horizontal screen disappeared with this edit.Victoria (tk) 00:08, 27 January 2023 (UTC)

A discussion on SGrabarczuk's talk page revealed that the problem should be resolved, and when I checked the diffs again, I no longer see a difference in the behaviour between Vector 2022 and the original Vector skin. Thanks to the design team for fixing the issue. isaacl (talk) 21:43, 6 February 2023 (UTC)

Vector 2022: CSS: RSS feed icon overlapping text due to 0px left padding

Tracked in Phabricator
Task T327717

(I'm on Firefox 109.0)

Issue

Have a look at my contributions page Vector 2022 and Vector skin, notice that in Vector 2022, the RSS feed icon overlaps with the text "Atom", which is not the case for the original Vector skin. (You can see the comparison here if you just want a quick look)

Cause

Vector 2022 does have a left padding styling of 16px for the feed link as shown in the CSS:

a.feedlink {
  background-image: url(/enwiki/w/resources/src/mediawiki.feedlink/images/feed-icon.png?2739e);
  background-image: linear-gradient(transparent,transparent),url(/enwiki/w/resources/src/mediawiki.feedlink/images/feed-icon.svg?cf8c4);
  background-position: center left;
  background-repeat: no-repeat;
  background-size: 12px 12px;
  padding-left: 16px;
}

However, this padding is not taken into effect (confirmed by my browser developer tools) due to this styling with more specificity than a.feedlink (specifically, this selector applies: .vector-pinned-container .vector-pinnable-element .mw-list-item a):

@media screen
.vector-pinned-container .vector-pinnable-element .vector-pinnable-header, .vector-pinned-container .vector-pinnable-element .vector-menu-heading, .vector-pinned-container .vector-pinnable-element .mw-list-item a {
  padding-left: 0;
  padding-right: 0;
}

Satricious (talk) 17:27, 27 January 2023 (UTC)

Indeed, it's a known issue. Being tracked at phab:T327717. the wub "?!" 17:31, 27 January 2023 (UTC)

Good to know. I posted a comment there pointing to what I described above so hopefully that helps somehow. Satricious (talk) 17:55, 27 January 2023 (UTC)

URLs now broken

Resolved

Currently, at least some of the time, the system is treating standard pages as edit pages with additional cruft in the URL.

https://en.wikipedia.org/wiki/Measuring_rod#Ancient_Rome

has become

https://en.wikipedia.org/w/index.php?title=Measuring_rod&oldformat=true#Ancient_Rome

No, that's completely unacceptable. (a) If you need to mark the format in the URL to keep the anon readers happy, it should just be a new format replacing the /wiki/: /w2/, /ow/, /wbetter/ &c. (b) Even if you need to keep the index.php cruft and put the oldformat marker on the tail end, it shouldn't be in the middle of the page name. Editors need to be able to quickly copy/paste the page names with the section tags to create links.

Was anyone on this redesign ever involved in actually editing Wikipedia? If not, can we scrap them and get them replaced by people who know how this works and why it's been so successful for decades? — LlywelynII 15:25, 29 January 2023 (UTC)

Like where ? examples please. No one can find a cause without knowing where to look. —TheDJ (talk • contribs) 15:29, 29 January 2023 (UTC)

As discussed at Wikipedia_talk:Vector_2022#URL_formatting_is_broken, this has nothing to do with the new skin, and likely is WikiWand and has been going on for years. —TheDJ (talk • contribs) 22:06, 29 January 2023 (UTC)

Vector 2022 only showing red links someplaces blue links elsewhere

Some time ago I had User:Stuartyeates deleted. When Vector 2022 was launched, I discovered that some links to User:Stuartyeates are red and some are blue. The two links circled in red in the attached screenshot go to the same place, but one is red and one blue. The appears to be consistent behavour for me for weeks. Do I have some odd setting enabled or is this a bug? Stuartyeates (talk) 03:58, 31 January 2023 (UTC)

@Stuartyeates: It's a deliberate feature of Vector 2022 that your userpage link at top of pages is always blue. phab:T312157#8132005 says: "IIRC the thought process was the user page and red link for contributions might be discouraging as red is associated with error and doing something wrong and both of these pages have information of value." PrimeHunter (talk) 05:48, 31 January 2023 (UTC)

@PrimeHunter: Thank you. While searching for how to craft a CSS override I found Wikipedia:Requests_for_comment/Rollback_of_Vector_2022 and have added my comment. Stuartyeates (talk) 06:46, 31 January 2023 (UTC)

@Stuartyeates for what it's worth unless you are really just trying to make a point that redlinked userpages are super cool, making your userpage a redirect to your user talk page is generally better for many things - including communicating with newer editors. — xaosflux ^Talk 14:48, 31 January 2023 (UTC)

@User:Xaosflux The point is not that consistency is an important part of design (including web design) because it is one of the key factors that make it easy to understand a design (make it 'intuitive'). Stuartyeates (talk) 18:07, 31 January 2023 (UTC)

I agree, my comment above was just an aside. — xaosflux ^Talk 18:37, 31 January 2023 (UTC)

Wider impacts

I've just discovered that this (or a similar issue) also impacts whether links in the 'tools' menu ('What links here', 'Wikidata item', etc) change colour once visited, deliberately undermining uswful browser functionality. Three times I've been tripped up by this. Stuartyeates (talk) 18:58, 6 February 2023 (UTC)

That's pretty normal, as elements like a and a:visited are commonplace in browsers. If you want to make both of the same colour even when the page has been visited, just set the color parameter to the same colour in your personal CSS. —Tenryuu 🐲 ( 💬 • 📝 ) 20:08, 6 February 2023 (UTC)

User:Tenryuu, are the links in the tools menu different colour once you visit them? Because they aren't for me, but they were in the original new vector. Stuartyeates (talk) 18:31, 7 February 2023 (UTC)

@Stuartyeates: They're not changing for me, but that's because it appears that .mw-list-item a and.mw-list-item a:visited use the same color parameter. —Tenryuu 🐲 ( 💬 • 📝 ) 18:48, 7 February 2023 (UTC)

Tools column not scrolling

Why does the tools column on the right not keep position while scrolling like the TOC? Every time I scroll down I get a return of the massive blank space. ~~ AirshipJungleman29 (talk) 16:42, 31 January 2023 (UTC)

This is a feature request from September 2022, T318169. – Jonesey95 (talk) 17:12, 31 January 2023 (UTC)

Persistence for fixed width for all users coming this week

Hey everyone,

the Vector 2022 skin's fullscreen toggle

TIt’s now been almost two weeks since the Vector 2022 skin has been live as the default on English Wikipedia.  Since implementing the change, the Web team has been focused on identifying issues, fixing bugs, and replying to community concerns.  The most commonly heard concerns so far were around the availability of the fixed width toggle.   Last week, we made a change that allows the toggle to show at the lowest possible width where it can have an effect (1400px).  This means that more users will have the options to toggle the width on more pages.

This week, we will be adding persistence for the toggle for logged-out users, starting this Thursday, February 2. This means that all users will see the width setting of their choice despite refreshing pages or opening new ones.  For those of you interested in testing the change ahead of time, it is already available in our testing environment.  

Ping @David Biddulph, IWantTheOldInterfaceBack, David Gerard, Davey2010, SmallJarsWithGreenLabels, Qwerfjkl, Peter Southwood, and DMacks.  We know many of you have asked for this specifically, so apologies to anyone that has been waiting for this that we have forgotten to ping directly.  

More details on the change and its technical implications for the future are available on the RfC page.  We also encourage you to bring your thoughts to our next office hours: Thursday, February 2 at 20:00 UTC (click here to join / dial by your location). We will be reviewing and discussing different community requests so far, and answering general questions about the skin.  

Thank you all for your continued feedback and your commitment to making the skin better for all. OVasileva (WMF), SGrabarczuk (WMF) (talk) 22:30, 31 January 2023 (UTC)

Thank you. This problem is being dealt with much more quickly than I was expecting, and I have hope that the pace won't slow in responding to other concerns. Still, this should have been fixed before the skin was pushed upon readers. small jars tc 22:44, 31 January 2023 (UTC)

1400px is not the "lowest possible width where it can have an effect". IWantTheOldInterfaceBack (talk) 02:23, 1 February 2023 (UTC)

True. Please see T326887, where I commented on January 19 that I did some experimenting with my window width, and without the sidebar or TOC showing, the toggle would remain useful down to about 1100 pixels, at which point the (IMO still excessive) left and right padding CSS becomes the only white space that matters. I uploaded screen shots. Feel free to upload some of your own; maybe you will be more persuasive than I was. – Jonesey95 (talk) 06:14, 1 February 2023 (UTC)

These two changes are/will be awesome and fix pretty much all my issues with the new skin. I'll get used to a little increased white space around the margins. Thank you! 199.208.172.35 (talk) 19:58, 1 February 2023 (UTC)

On some pages the infobox can obscure the tools menu

On Bipyramid the main info box overlaps the tools menu. I think this is caused by another overwide table below changing the width of the main text. I did quite like tools window on the left.--Salix alba (talk): 05:27, 1 February 2023 (UTC)

Hi @Salix alba - thanks for the report. Could you let me know what browser and operating system you are using? Also, could you let us know if adding the ?safemode=1 parameter (this link) removes the issue for you? This will help us know whether it's an issue with the setup, or potentially with a gadget you're currently using. OVasileva (WMF) (talk) 14:49, 2 February 2023 (UTC)

@OVasileva (WMF): Chrome on Windows and Chromebook. Adding ?safemode=1 removes the problem.--Salix alba (talk): 09:06, 3 February 2023 (UTC)

@OVasileva (WMF): I finally got round to looking at this and I've isolated the problem. It was the code in my vector.css which caused the problem.

#bodyContent {
  margin-left: auto !important;
  margin-right: auto !important;
}

I've now commented it out and things render correctly.

BTW For some reason problem only occurred when window width was > 1000px. --Salix alba (talk): 14:08, 10 February 2023 (UTC)

Table of contents on printed version

Tracked in Phabricator
Task T328871

Tracked in Phabricator
Task T306719

I have notice that the Wikipedia has changed its look. The main change I am concerned with is that the Table of Content is on the side. If you wish to print a page using the print/export tool, the table of content (TOC) is not included. Is there a way to include the TOC in the print/pdf? Theophilius (talk) 14:42, 5 February 2023 (UTC)

Nice catch. I looked for an existing bug report but was unable to find one. I created T328871. – Jonesey95 (talk) 16:23, 5 February 2023 (UTC)

Apparently, this is a deliberate non-feature. My bug submission was closed as a duplicate of T306719, entitled "Hide TOC in print mode (Vector 2022)". Here's a link to a brief discussion in which a few editors said "it depends" and one editor explained how it is helpful. It looks like you may have to enable User:TheDJ/Print options. – Jonesey95 (talk) 00:34, 6 February 2023 (UTC)

Vector 2022 not designed for those with advanced privileges

Since the rollout of the new skin, we have read a lot of comments about the new location of the login button. Initially, we had placed the login button behind a menu so that we can draw attention to the account creation workflow, and because logging in is a fairly infrequent action. However, due to current issues with the global authentication system (which requires people to log in more frequently than expected), as well as the number of concerns we're heard here and on the Technical Village Pump, we've revisited this and moved the log-in button outside of the collapsed menu and as a link on the page itself, as in the Vector legacy skin.

This means that now the login button will return to being accessible with just one click.

I saw this the other day and it struck me as so extraordinarily insulting that I feel compelled to write a very honest piece on how little thought you and yours apparently put into this decision, particularly in light of the above comment(s).

I am an 18-year veteran of the site. I have earned the privilege of leading one of the most innovated WikiProjects on the English Wikipedia, started several initiatives which have since been copied by other projects, introduced the first version of the now site wide standard issue ship template for both class and individual vessels, standardized the format for A-class reviews which have increased the likelihood of our project articles clearing FAC with minimal opposition, and along the way earned a position as Coordinator Emeritus due to the respect and innovation I have engendered among my project's members - both readers and coordinators.

In the course of earning this respect I also earned from the Wikipedia community a set of higher privileges: I am an administrator. One of only a few hundred on this site who are active. One of a shrinking number of people who are entrusted with closing reviews, blocking users, promoting consensus, deleting articles, and protecting pages from would be vandals and our more overzealous contributors. For me, logging in is NOT a "fairly infrequent action", its a daily or weekly action (depending on work schedules). I have been told in no uncertain terms by both the foundation AND the Arbitration Committee that I need to be especially cautious with this account because of the admin rights granted to it. I need a strong password. I am encouraged to use two factor authentication. And part of the responsibility that comes with this account is ensuring that when I'm not parked in front the computer others who may have more nefarious designs for pages can not access admin tools from my account and reek havoc across this site. I, therefore, am one of hundreds of people who do not have the ostensible luxury of leaving their account logged in on a 24/7 basis, and for you to assume this speaks very poorly to your understanding of and respect for the responsibility that come with an account that holds a higher set of privileges on this site.

I therefore deeply resent the notion of the double standard inherent to the above comment, that after being barked at by both the Arbitration Committee AND the Wikimedia Foundation at large you would turn around and ispo facto presume that removing easy access to the login button would not be a big deal to contributors like me "...because logging in is a fairly infrequent action". On the contrary, responsibility dictates that I NEED to log out when I am done on here to ensure the admin tools remain mine and mine alone, and I do not want to spend hours and hours looking for a button I've never had to look for before because some short sighted fool thought hiding it would be better so as to "...draw attention to the account creation workflow...". Not withstanding this obvious insult, I don't want to have to relearn where everything is all over again while logged out in order to catch the attention of my fellow admins or to do the admin assistance work I do on site (checking copyvio complaints, looking at URL references, assessing notability issues, etc) without immediately logging in. Your claim in rolling this monstrosity out was that it was done "...by the Wikimedia Foundation Web team with the goal of making the interface more welcoming and usable for readers and maintaining utility for existing editors." It hasn't done any of that, and if I have to look for something that was once so easy to find then obviously you've missed the marked by a very wide margin. Google, the #1 website in the world, hasn't changed its format at all in the 30 or so years its been running, and its getting rave reviews for exactly that reason. If they can do it, so can we - if you have courage to take a hands off approach. TomStar81 (Talk) 17:18, 5 February 2023 (UTC)

Acceskeys for own talk page and contributions in Firefox

MediaWiki provides keyboard shortcuts in the form of accesskeys. For example, "N" is the accesskey for the user's talk page, and "Y" is the accesskey for contributions Special:MyContributions. These two accesskeys do not work in Vector 2022 in Firefox. It seems to be caused by the fact that they are hidden under the menu. They work in Chromium, though. —⁠andrybak (talk) 19:58, 5 February 2023 (UTC)

It seems like this was a deliberate choice by Firefox 20 years ago... https://bugzilla.mozilla.org/show_bug.cgi?id=136041 —TheDJ (talk • contribs) 21:47, 7 February 2023 (UTC)

I think that should be worked around somehow – having accesskeys is rather pointless when you first need to click to open a menu in order to use them. I've created phab:T329318 for this. Rummskartoffel 17:46, 9 February 2023 (UTC)

Problematic new "features"

@OVasileva (WMF), SGrabarczuk (WMF), and Patafisik (WMF): I've been trying out the new vector, both logged in editing and logged out as a reader, and there are a few things not to like at the moment. I'm trying very hard to use the new skin, but its deficiencies at the moment outweigh the benefits in a few key areas. These are not things that should be fixable with a script, but points that affect both editors and readers that should be looked into more closely and hopefully changed:

1. the default to a narrow view is problematic. Studies may show shorter lines are easier to read, but people have their monitors or windows set to what they personally like, and the WMF shouldn't try to double guess that: let the article flow to 100% of page width, because people will have already adjusted their window to what they want – not you.
2. the lack of user links in the top right is a huge mistake – having talk, sandbox and contributions hidden in a dropdown is a backwards step. Why should anyone need to now have to double click for simple links when previously it was available on the page?
3. Having those top-right links as words, rather than icons would also be a huge benefit: icons mean different things to different people, while the words Talk, Sandbox, Watchlist and Contributions are much easier to identify. I have two degrees, run two companies and am a member of Mensa International, but I still have actively think about which icon means which link: that's poor design.
4. The 'drifting header' feature is a partial pain – click from another page onto a section and the drifting header covers both the title of the section and the edit button, so on talk pages, users have to scroll slightly to get the section name and edit link. This is something that should be fixed asap.
5. At the top of an article (one scrolling down the page), the block of links to other languages is dominant and unnecessary. That's a dropdown that should be on the left-hand menu. This is English WP: people are here because they speak English and don't need a link to all other languages to follow them down the page. It's particularly notable given this is the only bit on the top right that appears in words (big and bold), so acts as a distraction to reading the text: bad for readers, so get rid of it.
6. The bolding of sections in the left hand menu while reading an article is a complete distraction. When I'm reading and scrolling down, the bolding moves and my eye automatically flicks over at it, disturbing my reading – that's very poor.

These are not just issues to be faced by logged in editors (although you really need to take that into consideration), but for logged out readers too. While I'm trying to like the new version (and there are some advantages to it), I'm struggling to get over the obvious downsides built into it. I can see myself reverting to the previous version shortly if this isn't improved. – SchroCat (talk) 21:12, 7 February 2023 (UTC)

But you see... i disagree on all points.. And THAT is the problem we have here. Different people with different preferences. —TheDJ (talk • contribs) 21:45, 7 February 2023 (UTC)

So you think—for example—that a floating headline should cover the title end edit button of the section it’s supposed to highlight? It’s an interesting stance. You prefer to do two clicks of a mouse to see your sandbox or contributions? You honestly think that it’s advantageous to have a language tab following people down the page? Really? I’d like to hear your rationales on each of the advantages to the queries I’ve raised. SchroCat (talk) 00:54, 8 February 2023 (UTC)

@SchroCat, can you explain what you mean with #4? I assume that you mean you're clicking on a direct link to a section like Cancer#Epidemiology. When I click that link (Safari/macOS), I see the floating header followed immediately by the ==Epidemiology== section heading, with the usual section editing buttons. After that I see Main and See also templates, and then the image and the first paragraph of the section. It sounded like you're not seeing the section heading. Is that right? Whatamidoing (WMF) (talk) 01:04, 8 February 2023 (UTC)

Thanks @SchroCat. I'm glad to read that you've tried to test the skin. I also appreciate the effort it took to write all that. It's interesting that you're pointing at these very issues. I understand that these are your personal preferences, and I'm sure you may configure some bits. Have you perhaps tried to explore our documentation about Vector 2022? I encourage you to take a look! Here's like everything important in a nutshell you may skim through.

• In the FAQ, we've directly answered the argument that people may resize their windows (our answer is: they may, but most of them just don't). We've also explained why the dropdown (#2) is a step forward. (The same applies to #5 about the languages.)
• Regarding #3, we've announced this here on VPT in November: "In our user testing, users did not experience issues with any of the available icons with the exception of the contributions icon in the user menu, which is accompanied by a text label. A/B testing of the sticky header further showed that the icons in the header are recognizable. (Use of the sticky header decreases scrolling by 15%. Edits from the edit icon have higher completion rates and lower revert rates than edits started with any other edit link or button on the page, even though the edit icon isn't accompanied by a text label.)" I'm not sure if we can add anything to that.
• Regarding #4, this should not be happening, and does not happen to me. But perhaps this is because of your settings or software? Add ?safemode=1 to the URL, then go to a section, and see if the sticky header covers the heading. If it does, I'll be grateful for information about your browser and your OS.
• About #6, in our user testing, we learned that bolding the current section helps users with their orientation on the page. I guess this may be relatively easily configurable via the personal CSS pages, but I don't have the code handy right now. Would you like us (or any other tech-savvy Wikipedians) to write something un-bolding the section for you?

Thank you! SGrabarczuk (WMF) (talk) 04:15, 8 February 2023 (UTC)

I've already been over the pages where you justify the changes, and while they may work for small west-coast US focus groups, they don't necessarily work for the rest of us.

1. People already have their browsers set to their preferred width before they ever get here. WP is not the only site they ever visit, and most people will have their browsers aligned how they want them. To then have a width fixed by the WMF to something they don't want is a bit arrogant. (There are several comments on this page from IP readers about the bad width and this is repeated in the already archived threads and on other pages where people talk about the new skin. Your comment that people "may, but most of them just don't" isn't confirmation that it's right: it's an indication they don't know how to.

2. The claim that "the links are not presented cohesively as a unit" is relatively meaningless. They were all next to each other – that is presenting them cohesively as a unit. It's now two clicks to get to commonly used links. Why are you making it more difficult for people to navigate?

3. This isn't about the sticky header: this is about the icons at the top of the page: if you want icons on the sticky header, that's not a problem – but at the top of the page it is not an intuitive set of images. Icons mean different things to different people, the words don't. Why are you making it more difficult for people to navigate to regularly used pages?

4. This seems to have resolved itself from when I first started using it

5. You've explained that you have done it, but it doesn't stop it being a bad idea. It's the only word you have in the sticky header (if the WMF have an obsession with icons in the menu, the least you can do is have one for this too). It's odd but I've never felt the need, half way down an article, to decide to read the remainder of the article in French, Finnish or Farsi. People will make the choice before they start reading. I don't know the stats on this, but I cannot imagine we are dealing with a significant number of people who switch between languages frequently, and even less who do so mid article. I don't mind it at the top of the page, but the big bold word following me down the page is distracting – and if it takes my eye off the text, it's bad design.

6. Extra code isn't an answer. When I read WP (as opposed to editing), I do so logged out, so code on my account is pointless.

Among the many definite advantages to the new skin, you've spent a lot of money changing things that didn't need changing, and taken some things backwards in the process. I'm guessing that none of what I've written is going to make a blind bit of difference - the WMF tend to dig their heels in and be inflexible after they've spent big money, and I don't see this will be any different. Hey ho - back to the old skin for me: its disadvantages are myriad, but it's less painful than trying to use the new one. - SchroCat (talk) 08:39, 8 February 2023 (UTC)

new hidden category

Hello. Similar to other hidden categories, would it be possible to create a hidden category for the articles that have more than 800 unique references? This category would also be helpful for WP:MOSTREFS. They are currently doing this completely manually. —usernamekiran (talk) 06:06, 8 February 2023 (UTC)

eg Category:CS1 errors: invisible characters. ​ —usernamekiran (talk) 06:51, 8 February 2023 (UTC)

bump. —usernamekiran (talk) 14:30, 12 February 2023 (UTC)

@Usernamekiran: Tracking categories like Category:CS1 errors: invisible characters are added by a single citation template based on parameters in that citation. A category for number of references would have to be added and removed in edits by bots or users. I don't think that's worth the effort. You could instead suggest an addition to Wikipedia:Database reports at Wikipedia talk:Database reports. Something similar to WP:MOSTREFS but updated regularly by a bot scanning the whole database of articles. You would probably have to explain why such a report is useful and you may not get a "Type" column if somebody is willing to code the report. PrimeHunter (talk) 16:44, 12 February 2023 (UTC)

@PrimeHunter: Hi. I have already created a bot for that task successfully (User:KiranBOT/MOSTREFS). I did a lot of test runs, and in the end I did some test runs from toolforge using large number of pages to be scanned. My code was very efficient on server (did not consume resources), but it would take something like 15 to 18 days to scan ~4-5 million pages (redirects, disambs, stubs, articles with refimprove and similar templates are excluded). So I was looking for some other way to achieve the results. I thought this could be done by editing the reflist template, but the discussion at Template talk:Reflist says otherwise. —usernamekiran (talk) 16:56, 12 February 2023 (UTC)

This is basically not possible to do in Lua or template language, as those do not have access to the output of the <references> tag. You would need to change Extension:Cite to do what you want. That seems like needless processing.

Operating over the replicas or database dumps is appropriate in this scenario. Doing so with the HTML versions might be best since it would be trivial to get the quantity of items in the references list. 15-18 days honestly sounds about right for what you're trying to do if you choose a slow language, but even a fast one operating on HTML would take a while. I do not anticipate this kind of reporting needing to be done more than once a month at most, and I honestly don't see the value to doing so even that often. Izno (talk) 18:46, 12 February 2023 (UTC)

Display of U+A7A4 on iPhone

Hi, I don't know if here is an appropriate place to ask this question, but I noticed something very odd about the display of U+A7A4 (Latin Capital Letter N With Oblique Stroke) on my iPhone. It appears to be displayed as a cursive version of the lowercase "l", which is very strange because to my knowledge, there is no correlation between the letters N, N with oblique stroke, or L. Most characters in Latin Extended-D are unable to be displayed (rectangle), few are displayed correctly, but this incorrect display is extremely rare and I don't know how to explain it. Does this have to do with some computer bug, or is there a historical reason behind this? Because I personally don't see what good there is to have it displayed as something incorrect over being displayed as a rectangle.

What I see for U+A7A4 on my iPhone. I personally think it should be displayed like U+A7A5, if U+A7A4 can't be displayed correctly. Displaying it as a cursive l makes no sense at all.

Cmnpt (talk) 04:17, 9 February 2023 (UTC)

I do a lot of iOS and Mac OS troubleshooting, and there was surprisingly little on the web about adding missing fonts to iOS. I checked on my brand new, latest-OS iPhone (first new one in six years!), and I also see boxes. The best advice appears to be to install an app like AnyFont, then use it to add a font that will display these characters. Mac OS and Windows are the same way when it comes to displaying many Asian-language scripts; they just make it easier to add a font. – Jonesey95 (talk) 06:17, 9 February 2023 (UTC)

Thanks for the advice! The character being displayed incorrectly on iPhone isn't that much of a concern for me, since I use my computer instead. I'm just curious as to why an uppercase N with an oblique stroke is being displayed as a lowercase cursive L, since there seems to be no correlation between the two characters. Do you or anyone else know the answer? Thanks! Cmnpt (talk) 03:58, 10 February 2023 (UTC)

@Cmnpt I'm assuming this is happening for you in general, and not only when looking at this unicode character on Wikipedia? — xaosflux ^Talk 10:39, 9 February 2023 (UTC)

Yes Cmnpt (talk) 22:15, 9 February 2023 (UTC)

Let's at least link to the article/actually put the character: Ꞥ. Nardog (talk) 11:58, 9 February 2023 (UTC)

• With this being a "Some browsers don't display some unicode characters" problem, I don't think there is anything for us to do. On a very limited page such as Ꞥ itself, including an image of the character could be beneficial to some readers, and anyone is welcome to do that. — xaosflux ^Talk 13:38, 10 February 2023 (UTC)

  ...which I just did! — xaosflux ^Talk 15:58, 10 February 2023 (UTC)

Vector 2022 Search bar undesirable behaviour

Tracked in Phabricator
Task T327499

In Vector 2022, if you press Alt+F to bring up the Search bar, type a query, and press Enter, instead of being directed to the typed title as desired, you are taken to the suggestion that happened to be under the pointer and became highlighted, even if the pointer was never activated during the search. Has this been reported as a bug? (Sorry but I still can't make sense of Phabricator.) --Paul_012 (talk) 08:17, 9 February 2023 (UTC)

Yes, this has been reported, see phab:T327499. --rchard2scout (talk) 08:26, 9 February 2023 (UTC)

Thursday: reply tool is losing content

I just opened T329299 about a problem with reply tool losing data which looks like it started happening this morning. Has anybody else seen this? I'm not 100% sure I know how to reproduce it, so if you've got any better ideas, please update the phab ticket. -- RoySmith (talk) 15:54, 9 February 2023 (UTC)

Wow. So it turns out the root cause is User:DaxServer/Mark-locked.js. An extra special thank you to @TheDJ for tracking that down. If you run Mark-locked.js, you'll want to read the phab ticket and possibly disable the script before you get bitten like I did. -- RoySmith (talk) 21:25, 9 February 2023 (UTC)

woah, hold on. I didn't say it was the root cause. I can't 100% determine that. But it definitely contributes to a problem like this and should be fixed. —TheDJ (talk • contribs) 21:31, 9 February 2023 (UTC)

Any day: mw:Help:Locating broken scripts. --Malyacko (talk) 21:32, 9 February 2023 (UTC)

@DJ you're still my hero d'jour for finding that. -- RoySmith (talk) 21:42, 9 February 2023 (UTC)

Pinging the right user: @TheDJ -- RoySmith (talk) 21:42, 9 February 2023 (UTC)

Hey @RoySmith I've disabled the localstorage for now and also replied on Phabricator — DaxServer (t · m · c) 22:33, 9 February 2023 (UTC)

Logo in infobox

When you look at the logo in the infobox of WoodmenLife does it look squished or normal? I uploaded a cropped version to Commons, and it looks like it's trying to squeeze the old versions into the size of the new version. I'm on mono book if that matters. –DMartin 20:38, 9 February 2023 (UTC)

Wikipedia:Bypass your cache. Nardog (talk) 14:25, 10 February 2023 (UTC)

When will the blue pulsing dot under the Preview tab on the source editor be removed?

Tracked in Phabricator
Task T327515

Apologies if this isn't the best place to ask this, but I don't know where else to put it. As the title says, when will the Wikimedia Foundation remove the pulsing blue dot that appears under the Preview tab when editing a page's source? As an IP editor, I honestly find the pulsing animation annoying, and I hate how it appears every time I edit and how I have to click twice in order for it to stop. I'm sure many people already know about the existence of the feature, so why continue to display the distracting animation? I honestly hate it more than I hate Vector 2022, and that's saying something. When will the dot be removed completely? 2001:4453:565:1C00:577:4A:AC06:F616 (talk) 08:56, 10 February 2023 (UTC)

See mw:Talk:Reading/Web/Desktop Improvements. Tropicalkitty (talk) 09:00, 10 February 2023 (UTC)

No, the Realtime Preview feature is a response to a wishlist request, and completely separate from Desktop Improvements / Vector 2022. It looks like the blue dot should go away after the first time you click the Preview tab, and then click "Okay" on the introductory message: it sets a flag in localstorage WikiEditor-RealtimePreview-onboarding-dismissed: true. Does that not work for you? the wub "?!" 11:56, 10 February 2023 (UTC)

It comes back, a lot. — xaosflux ^Talk 13:30, 10 February 2023 (UTC)

• It should go away when phab:T327515 completes. — xaosflux ^Talk 13:30, 10 February 2023 (UTC)

You know, I noticed that blue, pulsing dot. I've just ignored it because it so obviously serves no useful purpose. No, no, no, I stand by that; it doesn't serve a useful purpose if we don't know what its purpose is. And its purpose can only be clear to the people who designed it. And it was designed by computer people for whom computers are not tools, but the be-all and end-all of existence--losers now on a power trip figuring out for us what we want, whether we know it or not, and giving us what they know we want, whether we want it or not.

So, what IS the blue, pulsing dot??? Uporządnicki (talk) 13:34, 10 February 2023 (UTC)

@AzseicsoK Have you ... tried clicking it? The button it's highlighting clearly says "Preview", I promise you nothing horrible will happen if you try it out. Is there another method you suggest for signposting new features to users? For the record, this feature wasn't a tool created by "losers now on a power trip figuring out for us what we want", it was created by the Community Tech team in response to a request made by 119 editors. Sam Walton (talk) 14:09, 10 February 2023 (UTC)

2001:4453:565:1C00:577:4A:AC06:F616, this has already been discussed at Wikipedia:Village pump (technical)/Archive 202#Turning off Realtime Preview notice. — Qwerfjkltalk 13:49, 10 February 2023 (UTC)

Fix this: Lua error in Module:Type_in_location at line 64: assign to undeclared variable 'args'.

Fix this: Lua error in Module:Type_in_location at line 64: assign to undeclared variable 'args'. [New Haven Hospital] — Preceding unsigned comment added by 181.22.90.26 (talk) 20:31, 10 February 2023 (UTC)

Thanks for letting us know. I've made the correction to Module:Type in location. Apparently require('strict') is viral to modules, since that module doesn't have that in its text. Izno (talk) 20:54, 10 February 2023 (UTC)

businessweek.com links

businessweek.com often redirects to a crufty url at bloomberg.com, (insource) 10,682 pages with links. They have bot detection software making it difficult to determine if it's a 200, 404 or soft-404. Any suggestions appreciated at WP:URLREQ. -- GreenC 16:02, 11 February 2023 (UTC)

FAs by prose size

Hi, WP:Featured articles/By length (and the query linked from it) lists FAs by wikitext size. I'd like a list ordered by word count, or at least readable prose size. Does anyone know how to generate one? Thanks, HJ Mitchell | Penny for your thoughts? 17:26, 11 February 2023 (UTC)

It's probably impossible without getting a bot to retrieve every relevant article and count their words. Certes (talk) 17:33, 11 February 2023 (UTC)

Page size should correlate with word count pretty well. For every few sentences, you will have a few refs (Which add a lot of the size), so the order should be mostly correct, as long as you account for any article being too high/low on the list by 10 places or so (Just my guess I have no evidence of this). Terasail^[✉️] 17:47, 11 February 2023 (UTC)

Wikitext is a very different measurement to prose size. Articles that use lots of templates or have lots of references will have much more wikitext than articles that use fewer templates or cite a small number of references (eg books) more times. Hence Maya stelae (36 kB, 5965 words) is #3 on that list but Douglas MacArthur, nearly four times the length (113 kB, 18667 words), is way down at #32. HJ Mitchell | Penny for your thoughts? 18:25, 11 February 2023 (UTC)

It's quite possible, as DrPda used to produce a report from his bot/script. See the talk page at WP:FAS for ten-year-old data he regularly updated whenever I asked. SandyGeorgia (Talk) 18:28, 11 February 2023 (UTC)

This is reasonably in the realm of bot-possible, or by hand using the wordcount script. Izno (talk) 20:58, 11 February 2023 (UTC)

I'm trying to write a script that does it. Have never done this before, so there is a risk I'll give up before I finish. —Femke 🐦 (talk) 17:07, 13 February 2023 (UTC)

Not sure if you're trying to do it from the rendered prose or the source wikitext? The first note at the bottom of User talk:Dr pda/generatestats.js describes a parameter for the script that will generate a list based on prose size. It loads each article so that the rendered prose can be parsed. isaacl (talk) 17:24, 13 February 2023 (UTC)

I'm using xtools' prosesize, which I understand is slightly less accurate that the prosesize script. I don't speak javascript though. —Femke 🐦 (talk) 17:29, 13 February 2023 (UTC)

I see—so by "script" you are referring to something run from the command line, versus within a browser? In terms of being able to break down the task into chunks more easily if desired, I think that's a good approach. isaacl (talk) 17:39, 13 February 2023 (UTC)

I'm running a jupyter notebook on wikitech:PAWS that talks to the xtools API and uses pywikibot. Problem is that I seem to have trouble connecting to PAWS on and off.. —Femke 🐦 (talk) 18:35, 13 February 2023 (UTC)

@Femke: just a heads up that I also started working on this following a request at WT:DBR. I assume the issues you're having with PAWS were caused by the WMCS outage earlier today (T329581). Legoktm (talk) 04:54, 14 February 2023 (UTC)

Wikipedia:Database reports/Featured articles by size now exists. I gave a more detailed explanation on the DBR talk page. Legoktm (talk) 06:44, 14 February 2023 (UTC)

Bug, or feature?

I noticed something odd today. When you hold the cursor over a wikilink to Campaign Against Antisemitism to open the pop-up preview, the page title appears blue, as if it were a wikilink itself. I checked a couple dozen other wikilinks and found that it only appears to happen when linking to this specific article. I tried to delve into why this happened but couldn't find anything of note in the lead or short summary. It's also unrelated to the page protection. Although this isn't particularly disruptive, it got me curious. Is this a bug or a feature I don't know about? What could be causing it? Prinsgezinde (talk) 21:38, 11 February 2023 (UTC)

@Prinsgezinde I don't see this when I look at the popup. Are you using page previews (Preferences > Appearance > Reading preferences) or the navigation popups gadget? Sam Walton (talk) 21:42, 11 February 2023 (UTC)

@Sam Walton I'm using the gadget. Turning that off and on again didn't change anything, and neither did WP:BYPASS. Prinsgezinde (talk) 21:49, 11 February 2023 (UTC)

Ah, I'm using the native feature so disregard my earlier comment :) Sam Walton (talk) 21:51, 11 February 2023 (UTC)

Curiously, I discovered that the same does not happen in incognito mode, so the cache is still most likely responsible. I can't imagine why this might happen (and to only that article in particular) but it's probably near impossible to reproduce, so I'd say that instead of a bug it's merely a minor anomaly. Prinsgezinde (talk) 22:00, 11 February 2023 (UTC)

@Prinsgezinde: It's black for me. Does it happen if you log out and click here to load the gadget code via the url? PrimeHunter (talk) 22:17, 11 February 2023 (UTC)

@PrimeHunter: it does not. Upon logging back in, however, it occurs again. I will note that I'm using dark mode and so the text is typically white for me, but that is unlikely to be related. Prinsgezinde (talk) 22:39, 11 February 2023 (UTC)

Another thing: in my previous post I meant that it does not occur when I use incognito and log in. That's why I mentioned that it is most likely a cache issue after all. Prinsgezinde (talk) 22:40, 11 February 2023 (UTC)

@Prinsgezinde: Assuming by dark mode you mean the "Dark mode toggle" in your Preferences > Appearance, this "bug" is fairly easy to reproduce: step 1. enable the aforementioned toggle, 2. go to a random page and enable dark mode, 3. hover over a wikilink and click on the page title on navigation popups, 4. come back to the page and observe the popup for the same wikilink again. This happens because the dark mode gadget explicitly sets color #6b4ba1 for "visited" links, i.e. URLs you've previously clicked on. (Relevant CSS: MediaWiki:Gadget-dark-mode.css#L-138) — DVRTed (Talk) 23:20, 11 February 2023 (UTC)

@DVRTed: If I understand correctly you're referring to the colour of links changing from blue to purple once you visit the page, but that's not what I meant. For me the title of the page in the pop-up window review is blue instead of the (dark mode) standard white, which piqued my curiosity because it is something I have never seen before. It's the exact same shade of blue that an unvisited wikilink would appear in. Prinsgezinde (talk) 23:44, 11 February 2023 (UTC)

@Prinsgezinde: Always say if you have color-changing features when you report color issues. I can reproduce the purple color mentioned by DVRTed with dark mode enabled and clicking the link inside the popup. What happens with other pages like The Example if you click the link inside the popup and not merely the wikilink? It becomes the same purple in the popup for me. PrimeHunter (talk) 23:59, 11 February 2023 (UTC)

Apologies, you're right. I guess I figured those were the standard settings because I haven't messed with the options a lot. I also missed that part of DVRTed's explanation. Clicking inside the popup box indeed reproduces the 'issue'. Case solved. Prinsgezinde (talk) 10:22, 12 February 2023 (UTC)

PressReader.com titles

This is probably not the right place to ask, but if someone could redirect to a more appropriate place great. Currently we have 409 articles using "PressReader.com - Digital Newspaper & Magazine Subscriptions" as the title of a reference rather than the actual title of the article being referenced. Is there any tool that can convert the title? As an example [2] that I have done manually. Keith D (talk) 22:12, 11 February 2023 (UTC)

@Keith D: "PressReader.com - Digital Newspaper & Magazine Subscriptions" is the html title of the page. The title of the displayed article isn't even in the html of the original page. I guess somebody would have to code a bot for this particular site. You could try Wikipedia:Bot requests. PrimeHunter (talk) 22:26, 11 February 2023 (UTC)

I think this is something WP:URLREQ can handle, or possibly something that User talk:Citation bot could. Izno (talk) 22:30, 11 February 2023 (UTC)

A good nomination for adding to the generic titles list at Help talk:CS1. Izno (talk) 22:29, 11 February 2023 (UTC)

Copy-paste into reply box sometimes moves cursor to the beginning???

• MacOS Monterey 12.6.1 (21G217)
• Chrome Version 110.0.5481.77 (Official Build) (x86_64)
• Firefox 109.0.1 (64-bit)
• Safari Version 16.3 (17614.4.6.11.4, 17614)

Within the past few days, I've started seeing an odd problem with pasting text into a discussion tools reply box. Sometimes, when I paste some text, it leaves the cursor at the *beginning* of the piece of text I just pasted. I'm seeing this in both Chrome and Safari, but not Firefox. It happens both when I'm logged in, and while logged out in an incognito window.

It also depends on what I'm pasting. If I grab the "From Wikipedia, the free encyclopedia" banner at the top of this page, it happens. It also happens when I grab "The default interactive shell is now zsh" from the login banner on a newly opened terminal window. It does NOT happen if I grab the URL out of the browsers's URL bar (i.e. "https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)")

I tried grabbing some text from the middle of a line; that doesn't make any difference, so it's not that I'm grabbing a trailing newline.

Anybody else seeing this? -- RoySmith (talk) 14:28, 12 February 2023 (UTC)

I assume this is related to T329439 and will be fixed in next deployment. Nardog (talk) 17:16, 12 February 2023 (UTC)

Yup, that describes what I'm seeing (including "Uncaught TypeError: this.getTarget is not a function" in the console. Thanks. -- RoySmith (talk) 17:44, 12 February 2023 (UTC)

Should be fixed now. Sorry about that. Matma Rex talk 15:02, 13 February 2023 (UTC)

Possibility of forcing rollback to V10

It seems probable that Wikipedia:Requests for comment/Rollback of Vector 2022 will result in a consensus to at least temporarily rollback to Vector 2010. However, to my knowledge, the WMF has not indicated that they would respect such a consensus if it were found, which would leave us in a situation similar to that with VisualEditor in 2013. In that case, it was possible to implement a hack that overrode the Foundation's changes. Do you code wizards have any idea if something like that would be possible here, and if so, what kinds of technical consequences we might be looking at? (Forcing a rollback would probably require another discussion, but it seems prudent to begin exploring our options, if we have any.) —Compassionate727 ^(T·C) 22:45, 12 February 2023 (UTC)

If the WMF refuses to change the skin (Assuming consensus for rollback is found) then any sort of attempt to override V22 and force Vector 2010 would be reverted and the user implementing the change is tempting an office block. Afterall they do have final say on the website they host. Terasail^[✉️] 23:42, 12 February 2023 (UTC)

Anyway, any sort of hack which would force vector 2010 for both logged in and logged out users would be less than ideal and probably be inefficient at best. Terasail^[✉️] 23:50, 12 February 2023 (UTC)

While I think it is very inadvisable, it could be possible to run a gadget that forces a preference change - for logged in users; it has lots of technical problems, starting with: how to skip users that purposefully opted in to v22. Besides, logged in editors can just opt-out if they want to at any time. As IP users don't have preferences, that mechanism can't be used there - there is no good way to do it for them - so it would come down to getting a developer to change the configuration. — xaosflux ^Talk 00:08, 13 February 2023 (UTC)

This is all rendered moot by the fact that Wikipedia's "consensus" system is just a comfortable lie whenever the WMF is involved. Thebiguglyalien (talk) 02:44, 13 February 2023 (UTC)

It's worth looking into the technical matter of whether we could change the default configuration for registered and/or anonymous editors. If not, then the other questions are irrelevant. If we could, the next question is whether we should. A rogue admin doing so unilaterally might, and probably should, be blocked, but if there is a consensus to revert by technical means then things get more interesting. Blocking someone for implementing a community consensus might lose that community's support on a much broader level. Certes (talk) 10:16, 13 February 2023 (UTC)

Separate Tab for Automated Messages on Personal Talk Page

Would it be possible to set up a separate tab for automated messages on a personal talk page? If so, how would you go about doing that?

To explain, I periodically receive notifications from various projects, such as newsletters and election announcements. Over time they start to build up and crowd out the actual discussions from other editors. (For newsletters, I even go back and delete them when a new one is delivered, but this is inconvenient.) However, I would like to continue receiving them, as they are still useful updates about what is going on. Therefore, directing them to a separate tab seemed like a good solution. To be clear, when I refer to a separate tab, I am envisioning something like the WikiProject infobox as seen on museums Wikiproject. –Noha307 (talk) 04:50, 13 February 2023 (UTC)

Wherever you subscribed to the automated messages, you can change to point to an arbitrary page in most cases. I would of course recommend pointing it to a user or user talk subpage of your own. For example, the Signpost's signup mechanism is at Wikipedia:Wikipedia Signpost/Subscribe, where you could remove your personal talk page and then add User talk:Noha307/Subscriptions instead, c.f. User talk:AfroThundr3007730/Newsletters already present in that list. Then you would just catch notices to that page with the usual Special:Watchlist. Izno (talk) 05:13, 13 February 2023 (UTC)

You might also find User:Evad37/OneClickArchiver useful. – Jonesey95 (talk) 06:28, 13 February 2023 (UTC)

Feature request + 2 keyboard shortcuts

I am requesting additional options for the "Find and replace" icon in the wiki edit source toolbar.

Proposal picture

.

• Keyboard shortcuts:

1. When you click Alt + Shift+ ↑ it would open the "Find and replace" option menu and position the cursor in the "Search for:" query.
2. When you click Alt + Shift+ ↓ it would close the "Find and replace" menu.
3. Add a find results toolbar under the "Search and replace" menu which would add a search result, highlight said result and indicate X/Y result it is.

• Increased functionality of finding results:

I hope this isn't too much to ask. If the 3rd option is too demanding, then at least the first 2 options should be able to get implemented fairly easily for quicker and easier editing, especially using regex, which would benefit the entire Wikipedia editing community. Qwerty284651 (talk) 23:18, 13 February 2023 (UTC)

Note that the WE2017 and VE editor already have keyboard shortcuts for find and its associated functions. —TheDJ (talk • contribs) 09:29, 14 February 2023 (UTC)

Can WE2017 be used for regex replacement as well? Qwerty284651 (talk) 11:37, 14 February 2023 (UTC)

To some extent. See phab:T306930 for what's not. --AKlapper (WMF) (talk) 12:44, 14 February 2023 (UTC)

signatures.toolforge.org down

Resolved

https://signatures.toolforge.org/check/en.wikipedia.org/Jonesey95 currently returns an error, "503 Service Temporarily Unavailable". It usually returns an editor's custom signature in wikitext form. Should this be reported on phabricator, or in some other way? Or has the tool moved, leaving no forwarding address? – Jonesey95 (talk) 00:46, 14 February 2023 (UTC)

@Jonesey95 You can try github or User talk:AntiCompositeNumber (in this case it's prob not software, but operations - so the talk page first). — xaosflux ^Talk 01:19, 14 February 2023 (UTC)

AntiCompositeNumber fixed it super-fast after I dropped a note on their talk page. – Jonesey95 (talk) 05:08, 14 February 2023 (UTC)

Tech News: 2023-07

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

Problems

• On wikis where patrolled edits are enabled, changes made to the mentor list by autopatrolled mentors are not correctly marked as patrolled. It will be fixed later this week. [3]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 14 February. It will be on non-Wikipedia wikis and some Wikipedias from 15 February. It will be on all wikis from 16 February (calendar).
• The Reply tool and other parts of DiscussionTools will be deployed for all editors using the mobile site. You can read more about this decision. [4]

Future changes

• All wikis will be read-only for a few minutes on March 1. This is planned for 14:00 UTC. More information will be published in Tech News and will also be posted on individual wikis in the coming weeks. [5][6][7]

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

MediaWiki message delivery 01:46, 14 February 2023 (UTC)