Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

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

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

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

Vector 2022 deployment update

Hi everyone,

Thank you all for your ongoing feedback - it has helped us make the skin better for everyone! As we previously discussed, we are preparing for the deployment of the Vector 2022 skin to all logged-out desktop users of English Wikipedia and those logged-in desktop users of English Wikipedia who both are using Vector legacy and haven't chosen Vector legacy in their global preferences. The change will take place on January 18 around 14 15:00 UTC.

We want to make the transition smooth, avoid breaking workflows, and limit confusion and post-deployment issues. We're sharing some details and useful links below to explain how the transition will be performed.

1. This week and early next week, we'll make sure that the software version next week will be free from any easily noticeable imperfections.
2. This week and early next week, there will be banners incentivising logged-in users to switch to Vector 2022.
3. This week, we are also going to update affiliates such as WMCA, WMDC, WMNGA and WMUK.
4. Shortly after the deployment, logged-out and logged-in users will see banners informing them about the change.
5. As always, it will take at most three days for most of the cache to be updated. Before that, Vector legacy will load on some pages. After that, readers will see the new skin on any page.
6. Before and after the deployment, we will be hosting office hours. At those meetings, we will be answering questions on the skin itself, on updating any necessary gadgets and scripts, as well as receiving feedback on future improvements to the new skin. Please, feel free to join us at the following times:
   • Thursday, January 12, at 20:00 UTC - on Zoom click here to join / dial by your location
   • Thursday, January 19, at 20:00 UTC - on Discord, the Open Meetings voice channel
   • Friday, January 20, at 6:00 UTC - on Zoom click here to join / dial by your location

As a reminder, logged-in users can opt out at any time. Those of you using a non-default skin (Timeless, Monobook, etc) will not see any changes. If you'd like to customize the skin, here's a dedicated FAQ section.

Thank you again! OVasileva (WMF), SGrabarczuk (WMF) (talk) 19:17, 10 January 2023 (UTC)

@OVasileva (WMF) and SGrabarczuk (WMF): I missed your original update I think, but I just want to clarify with regards to icons in the sticky header: which changes were made? I see the update mentions tooltips, but I think tooltips were already there pre-RfC? Were any further changes made to these after the RfC was started? ProcrastinatingReader (talk) 13:08, 14 January 2023 (UTC)

Hey @ProcrastinatingReader, thanks for your question! We did a couple of things after the RfC to improve the sticky header:

• Reviewed our original sticky header research on icon recognizability, specifically around the sticky header icons to confirm if there was sufficient understanding in what each icon leads to.  Users reported they were comfortable with most icons with the exception of beta features, preferences/gadgets, and contributions, all of which have labels within the user menu.
• Accessibility tested our tooltips in collaboration with the American Foundation for the Blind

• Worked on making the sticky header significantly more useful overall by adding a link to edit the page (which will be available in the deployment on Wednesday).  Our A/B test showed that using this new link made it more likely for people to complete the edits they start using the sticky header and that edits people initiated and published using the sticky header were less likely to be reverted.
• Prior to the RfC we also collaborated with the Editing team on improving the sticky header on talk pages, where the icon to add a new talk page topic also contains a label “Add topic” for clarity. (For details, see the #Talk page appearance section below.)

Does that answer your question? Did you have anything specific in mind which the answer above doesn't address? Thanks,

OVasileva (WMF) & SGrabarczuk (WMF) (talk) 18:17, 14 January 2023 (UTC)

Seems Gud...  :-) 60.241.201.38 (talk) 06:07, 18 January 2023 (UTC)

Sort of. Some of these seem to be pre-RfC, so I expect editors took these points and research into account when commenting with concerns. I'm wondering if anything specific has been changed or researched since that RfC, not including anything done or presented prior to that RfC starting. ProcrastinatingReader (talk) 15:23, 18 January 2023 (UTC)

@SGrabarczuk (WMF) I don't understand this phrase: "...and those logged-in desktop users of English Wikipedia who both are using Vector legacy and haven't chosen Vector legacy in their global preferences". I must be missing something, but how can someone be using Vector legacy if it's not chosen in global preferences? Can it be chosen in local preferences, maybe? (I'm not up on how all of the preferences work.) That phrase describes one group of users, right, who are "using but haven't chosen" vector legacy? Maybe I just need more coffee, but I am confused as to what this means. David10244 (talk) 10:51, 18 January 2023 (UTC)

Hey @David10244, thanks for this question. The preferences work the following way: when you go to the local preferences page, you'll see the default settings selected/activated for you. You may change them by selecting (choosing) anything different than the default. The global preferences are not active, though - by the default, there's no global skin selected. So in order to see the same skin across all the wikis, you need to activate it via the global preferences. Unless you do that, with each local change (such as the change of the skin here today), you'll experience this change. SGrabarczuk (WMF) (talk) 14:53, 18 January 2023 (UTC)

So. That notice at the top of my pages here...

The one that says

Try out the new interface improvements

Search, language switching, sticky toolbar, table of contents, and more

I have my editing all fixed-up the way I like it, so I have some questions about these changes (or "improvements"). I don't want anything about my editing to change and I don't know if I even have a choice, I just keep my head down and edit stuff around here. So do I have a choice? Is it possible to disable these "improvements" and keep editing tools/style/appearance the same as they presently are? And if editors 'can disable these upcoming changes, how do we do that? Thanks, Shearonink (talk) 16:24, 11 January 2023 (UTC)

@Shearonink This should be in reference to mw:Reading/Web/Desktop Improvements.

How to avoid this change: From reading the above, you should be able to opt out of this by setting your global skin preference to "Vector legacy (2010)" and ensuring that you do not have a "local exception on this wiki". This should mean that when the default changes, your skin will not (That is if I understand correctly). Terasail^[✉️] 16:50, 11 January 2023 (UTC)

Thanks for your answer. Shearonink (talk) 17:16, 11 January 2023 (UTC)

(edit conflict) @Shearonink, you will be able to change it at Special:Preferences. See #Vector 2022 deployment update. — Qwerfjkltalk 16:52, 11 January 2023 (UTC)

Thanks for your answer. Shearonink (talk) 17:16, 11 January 2023 (UTC)

Hi @Shearonink - thanks for your question and for trying out the new interface! Have you tried out the new skin for a couple of days? We've noticed that it can take a few days for folks to get used to the new skin and the new locations of the features. That said, you can disable it at any time. There's two ways to do this - the first is the link in the left sidebar that says "Switch to old look" and the second is from the appearance section of your preferences as mentioned above. OVasileva (WMF) (talk) 16:52, 11 January 2023 (UTC)

Lol, well, actually, no I haven't tried it out, I really don't want to. Oh I know it's wonderful and whatever but what I have now *works* fine for me. And I'm going to keep it. Shearonink (talk) 17:16, 11 January 2023 (UTC)

And, strictly speaking, the editing itself shouldn't be impacted, really. All editing tools work pretty much the same way on any skin. SGrabarczuk (WMF) (talk) 17:08, 11 January 2023 (UTC)

Good to hear. When the appearance of the editing window changes I find that confusing and off-putting. I like to know where things are and am an editing creature of habit. Shearonink (talk) 17:16, 11 January 2023 (UTC)

A side question: how is this banner scheduled to pop up? Is it still going to appear after the skin is deployed? There is no way to disable this banner in the preferences. I didn't want to adblock these banners, because I would hope they are supposed to be for important announcements. But now I am seeing it 4th time already despite having dismissed it. And I have toggled to the skin and back before and I have set my preferences - why does it still show up for me at all? Where is the "don't show again" option? —  HELLKNOWZ ∣ TALK 20:02, 11 January 2023 (UTC)

Perhaps when this goes live we put up a WLN as well. — xaosflux ^Talk 20:09, 11 January 2023 (UTC)

Hey @Hellknowz. Thanks for this comment. Sorry for making this a bit too annoying. I've decreased the number of times the banner appears from four to three. In many cases, it's five, for example in the case of the Community Wishlist Survey or the Wikimania scholarships season. (But for the call for nominations in the steward elections, it would be three.)

These banners will not appear after the skin is deployed. We will run different banners with a different target link. Those would appear three times per user at most, I think.

I aim at some balance between making sure many people know and not pushing too much. I hope I'm close :) SGrabarczuk (WMF) (talk) 22:28, 11 January 2023 (UTC)

Well, adblock it is then ¯\_(ツ)_/¯ —  HELLKNOWZ ∣ TALK 12:01, 12 January 2023 (UTC)

@Hellknowz: That shouldn't be necessary. It's a WP:CENTRALNOTICE, so it's not difficult to write a CSS rule to hide it:

div#DesktopImprovements_suggestion_its_coming { display: none !important; }

For English Wikipedia only, put it in Special:MyPage/common.css; for all WMF sites, put it in m:Special:MyPage/global.css. --Redrose64 🌹 (talk) 09:05, 15 January 2023 (UTC)

@Redrose64: Thanks for the suggestion. Unfortunately, the reply said "We will run different banners with a different target link" and didn't address being able to switch these off, so that won't help when something else pops up again later. —  HELLKNOWZ ∣ TALK 10:49, 15 January 2023 (UTC)

New Interface

Hi, So I decided to click the "New Interface" banner and now I regret it, Hate the new interface - it looks like the mobile version but just with more features, Is there anyway I can undo this new interface malarky ?, Thanks –Davey2010^Talk 02:16, 12 January 2023 (UTC)

Took me a while but eventually found it out, I don't know why anyone thought moving the Watchlist and Contribs to the "account" icon was a fantastic idea as it wasn't. My huge dislike is the reduced page size - I don't know why things couldn't stay relatively the same as now but just upgraded but then again Facebook, Twitter and YouTube like to "improve" their designs too and ironically I never liked those redesigns either but I live with it, .Anyway not for me I'm afraid. –Davey2010^Talk 02:31, 12 January 2023 (UTC)

There is a toggle width button in the right lower corner of your screen and you can change it in preferences. That way you have the new skin but the same width. Coldbolt (talk) 10:38, 14 January 2023 (UTC)

There is a toggle width button in the right lower corner of your screen There is not. The sidebar is ridiculously wide ... - David Gerard (talk) 16:40, 18 January 2023 (UTC)

The fact that the banner changes your skin if you click on it anywhere, but the ability to change it back is obscured by that very skin, underlines that the core feature of Scalar 2022 is coercion. It is an attempt to take away the reader's control over key aspects of their experience in favour of what the WMF have internally decided is best for them, especially article width, forcing the user into a linear reading experience. All this serves to do is to assert the primacy of corporate identity and power over freedom and respect for the user. This isn't anything new though: the aesthetics of power and linearisation have been festering in social media app design for years (recently reaching a new height of evil in things like instagram stories) but it's sad that it's finally infecting Wikipedia. –small jars tc 11:13, 14 January 2023 (UTC)

The most similar case might be the old vs. new Reddit interface. I have the browser extension that auto-redirects to the old version, of course, but things are predictably starting to break and not get fixed over time (most egregiously and recently in the form of random backslashes appearing in some pasted URLs). Sooner or later, this will also happen to Vector 2010. And that's not even touching on the trend of platforms deliberately wrecking their mobile websites to goad users into using the official apps instead, which make for a much more convenient data collection and shoving-ads-down-one's-throat environment. Of course, you do need a somewhat serviceable app for that, so it probably can't become a thing for Wikipedia for at least another decade or so... Dr. Duh 🩺 (talk) 13:16, 14 January 2023 (UTC)

Well I'm using MonoBook right now without any problems, so I don't think Vector proper is ever going to stop working. The problem is that most readers have no idea that there is a way to change the skin, and the page width toggle is worthless for logged out users because it resets every time you move to a new page. If that was fixed (and it could be with session storage and common.js) I would be a little bit happier, but Scalar gets in the way of readers' control over their experience in a bunch of other ways, and editors are going to have to do a lot of work reformatting articles so they don’t look terrible in the new skin.–small jars tc 14:42, 14 January 2023 (UTC)

I hope that this high-priority bug that is tracked at Phabricator since 13 November will be fixed before 18 January 15:00 UTC. --NGC 54 (talk｜contribs) 15:11, 16 January 2023 (UTC)

Hi @NGC 54 - Thank you for bringing this up! We've been keeping a close eye on this issue as well. The bug itself is not within the Mediawiki software but is an upstream bug in Chromium browsers (affecting browsers such as Chrome , Opera, and other Chromium-based browsers). We have reached out to the Chromium team who were able to put up a couple of patches to fix the issue late last week. Progress can be tracked here. OVasileva (WMF) (talk) 15:32, 16 January 2023 (UTC)

Opinion of a reader on this design change

Hello, I just read the RfC about (way too late unfortunately). I'm French and a reader. Today I feel frustrated, not listened and betrayed by the WMF. I've been trying to voice my opinion on the Vector 2022 ever since it was forced on the French Wikipedia. I'm normally a logged-out user. Here is what I have to say, I HATE IT. I deeply feel it's one of the dumbest changes of design I've ever seen. I created an account specifically to disable that disaster when it landed on the French Wikipedia. I still remember on the French Wikipedia how there was a lot of new account that just came to know how to disable or remove it. NO ONE LIKED IT or understood why it was forced on them, but the WMF is still pushing for it, not listening, no matter what. I voiced my opinion a number of time on the discussion page, but the WMF team NEVER listen to any of the negative criticism they were given. Each time someone tried to voice a negative opinion, someone from came gave as an answer "Have read this study and our blog that explain why did that?" (yes we did thank you, and we are still not convinced) and right after that we were ignored. Since then, I have lost any trust I had in the WMF to manage Wikipedia properly. And honestly, I have the feeling some higher up at the WMF is forcing this design on everyone else and everyone is afraid to say them no. Just look at the strategy they used to push the design, first targeting a non-English-speaking Wikipedia, so people can't complain but big enough to get feedback from the few English speakers who liked it and ignoring negative feed back (like mine). Then extending to other smaller non-English-speaking Wikipedias using the same strategy, then hitting small WMF services that barely anyone uses. See how the purposefully got around their biggest Wikipedia? Now they can push this disaster on it telling you "But look a majority of the other Wikipedia use it and are happy. Sorry, but the majority has spoken." And you'll see as much as in the discussion page all negative comments will be ignored, they will impose this on the English Wikipedia as they did to the French. DerpFox (talk) 23:50, 15 January 2023 (UTC)

Hello! This page exists for people to get technical help with Wikipedia. The technical workaround for your problem, for you, is to switch to a different skin in your Preferences. It sounds like you are upset with the process; I think a page like Wikipedia:Village pump (WMF) might be a better place to address those concerns. – Jonesey95 (talk) 01:30, 16 January 2023 (UTC)

Hi. The page you are pointing me to say to come here to talk about that subject. I know I'm not really in the right place. But there don't seem to be a right place for that anywhere I look, every time I posted somewhere I've been told "no this is not the place go look at *other page name*". The WMF have made it really difficult if not impossible to voice a negative option about that new design they are forcing on every one and the way they are operating that change. DerpFox (talk) 01:57, 16 January 2023 (UTC)

The WMF is hell-bent on imposing Vector 2022 and will never listen to the community on this one. The best we can do is change skins. For logged-in registered editors, this is an easy preference change, at least for now. When logged out, I intend to use User:Alexis Jazz/SkinEnforcer. Certes (talk) 12:00, 16 January 2023 (UTC)

Indeed. Having just checked it again, I have to say I totally don't get why they changed the old "menus at top and to the left, title plus article on remainder" to "menus at top and to the left, then a title, then a new line of menu items (underlined to make it look like a subtitle), and then the remainder of the article". It's a completely counterintuitive layout. Fram (talk) 15:28, 16 January 2023 (UTC)

This is on purpose?? I was trying to figure out where to report that it's giving me the mobile site. The new design is absolutely terrible. Thanks to Jonesey95 for pointing out the expand button in the lower right, which fixes most the problem, and is extremely easy to miss on a 4k monitor.

As a logged-out user, I shouldn't have to install some kind of script in order to have a readable site. I expect designs like this from social media apps that show contempt for anyone in a desktop browser, but not from Wikipedia. To reiterate: the new design is so bad I thought it was a bug. 2600:8800:619D:1200:1154:5DC4:1C57:4C8C (talk) 16:37, 18 January 2023 (UTC)

• Oppose, I really dislike this Vector variant ever since they introduced in my local-language wiki. It wastes lots of space on the side which should have been something useful (i.e. article text) or having some readily-accessible navigation there (like languages, permalinks, etc). Now various things only have cute "icons" and require click to actually see what the darn thing was, like how the dreaded social-control media sites are designed these days. And since these navigation elements are image now, have you ever tried to log in with images disabled? (I disable images a lot when I'm on GPRS connection with 6 KiB/sec download billed by megabyte, and Wikipedia had always been one of the sites usable in that condition)

I suspect you people at WMF haven't: you can't log in in that condition. (Spoiler: you will also have to disable CSS to see the login link, or you will have to enter the URL of Special:Login page manually)

At various points in beta-test (which I have not ever willing to participate), Vector 202x even killed navigability on my not-so-modern browser that I run without JS: language button died completely, user menu on the top went duds (prevented me from logging in to "opt-out"), left pane (when opened) end up pushing the article down into oblivion. The last one (including no-image bug above) still happen in this "iteration".

Also, my use of Wikipedia was 99.5% done in anonymous fashion; I'm not even given a choice to opt out in these cases, and had to manually append "?useskin=vector" (or "&useskin=vector") to the URL every single page load like a pleb because the damn thing doesn't record this preference in cookie when the session is not a logged-in one.

Overall, this is basically the same thing as shoehorning mobile web into desktop; and I condemn WMF for this.

Where did people vote to not have this Vector-202x as default again?

— :Nvtj (talk) 16:50, 18 January 2023 (UTC)

Going live and opting out

It seems from the above discussion that the new skin may go live on 18 January at 15:00. Is that the case? Whenever it happens, many (perhaps most) editors and readers will want to opt out of this change. Should we be more proactive in informing them of why Wikipedia looks different and how they can reverse the change if they wish? I think this needs at least a watchlist notice and possibly even a banner on the main page for the benefit of unregistered readers who have no watchlist. Certes (talk) 15:26, 16 January 2023 (UTC)

@Certes we're getting a WLN up on this. Readers won't be able to opt-out. — xaosflux ^Talk 15:31, 16 January 2023 (UTC)

Readers won't be able to opt-out officially, but DerpFox's comments above suggest that publicity for tools such as User:Alexis Jazz/SkinEnforcer would be very helpful. It might reduce the loss of readers to forks and mirrors which continue to use their preferred skin. Certes (talk) 19:37, 16 January 2023 (UTC)

@Certes - Thanks for your question! For logged-out users, we will also be putting banners up with more information on the change on the day of deployment. OVasileva (WMF) (talk) 15:34, 16 January 2023 (UTC)

Images and infoboxes competing for space

I'm not sure where to ask this question, perhaps if there's already a discussion, some more knowledgeable editor can link it for me here. Obviously Vector 2022 removes the table of contents from within the prose between the introduction and the first section, and this has a noticeable side effect which, similar to hiding the TOC on Vector legacy, brings the first section up, often to left of the infobox. Apparently over 3.1 million English language articles have an infobox. Many of these infoboxes are long, too long in my opinion, but that's another discussion. The end result however is, even when the "limited content width" box in the lower right is toggled on, that any images in the first section, say "History" or similar, get stacked up down the page, further and further away from their relevant prose. I work on several U.S. state articles, I'll point to Maryland, one I don't work on, as an example of this.

Help:Pictures#Avoiding stack-ups still advises me that stacking is a "problem" and gives several solutions to avoid it. I know users at WP:GAN or WP:FAC will frequently ding articles for this issue. Is stacking at the start of articles just an accepted byproduct, now that Vector 2022 will be the default? On my articles, should I do anything? Like should I avoid early images in the first sections? Should I use right-aligned tables to sit them next to infoboxes? Is there some new code coming to reduce the impact of long infoboxes? Or is all of this a moot point because desktop web browsing is dying and we should focus on how a page appears on mobile? Help, I'm very unsure here!-- Patrick Neil, _oѺ^∞/Talk 15:49, 16 January 2023 (UTC)

Hi @Patrickneil: Two things: On Year in xxxCountry" lists - usually with very long vertical TOC, I've changed TOC to {{horizontal TOC|nonum=yes|align=center}}. This results in the beginning content much higher on the display, even with very long right-side infobox. With that horizontal TOC there can be limit 2 or 3 to condense the TOC even more. A while back I switched (under Preferences/Appearance) to MonoBook Skin, and have not looked back to either Vector. There seem to be zero problems with MonoBook & it's quick. Second, for Avoiding stack-ups, I've seen some articles with Gallery at bottom of that section, to place 3, or 4 or 5 smaller bio images. An example is here. Also, using "right" parameter for a single image to keep the picture floating within a specific content section may be helpful. JoeNMLC (talk) 16:49, 16 January 2023 (UTC)

I raised stacking/sandwiching early on as a potential issue with removing the table of contents, and @Blaze Wolf/@Styyx raised it again during the RfC here. As far as I can tell, the developers have not weighed in.

This leaves us with basically two options. We can either decide that some sandwiching in the first section is tolerable and we can align images there to the left, or we can embark on a massive campaign to remove them. I lean toward the first option, even given that we're now working with a narrower default width, since I've never seen sandwiching as the greatest evil, and the thought of losing thousands of good images (the first section is often History, with cool historical photos) just because of this is too much to bear. I'll ping @SandyGeorgia for your thoughts, as I know sandwiching is something that comes up all the time in your FAC/FAR work. {{u|Sdkb}} ^talk 16:50, 16 January 2023 (UTC)

Was basically ignored because the example we gave also had a very small sandwich on the old skin, completely missing the point of the complaint. ~Styyx^Talk? 16:53, 16 January 2023 (UTC)

Maybe also reconsider if anyone really benefits from having a huge list of ‘state symbols’ at such a prominent spot in an article like Maryland, pushing stuff even further down. This boyscout-level collecting of meaningless symbols, is something that few outside a subset of the USA will truly care about or need to know. ;) —TheDJ (talk • contribs) 20:31, 16 January 2023 (UTC)

Thanks Sdkb et al, glad to know that at least this was pointed out earlier. I agree that for my personal browsing, I'm unlikely to stick with Vector 2022, but I feel like I need to know how articles might display to the general public, given that the majority of their readers won't be logged in or have a vintage skin selected. I know, for example, I've been making an effort to ensure my SVGs have transparent backgrounds and colors that also work on the Wikipedia app's dark mode for Android and iOS. But after staring at this skin all day, I can't help but think that, gee, there's this big block of wasted white space on the right side of the page. The TOC and/or Wikipedia menu takes up this block on the left side, but the symmetrical space on the right is empty. So I have to ask, has anyone suggested filling that space with the page's infobox? Again, there's 6.6 million articles, and 3.1 million of them have infoboxes. Below the infobox, it can just be white space, as it is on Vector 2022 now anyways. I made myself a little animation, since I can unsee this missed opportunity now. And yep, TheDJ, I am well aware of the utter trivial-ness of that Template:Infobox U.S. state symbols, it survived a merge attempt in 2020, but if anyone was to bring it to TfD, I would surely support that!-- Patrick Neil, _oѺ^∞/Talk 02:05, 17 January 2023 (UTC)

Moving infoboxes to the right is non-trivial since infoboxes are an editor construct today and not a construct that the system knows about. There have been prototypes in the past that play with this positioning like mw:Winter, and I think today the responsive content gadget does some playing with some of the other elements that naturally float inline with the content on a wide resolution.

Moreover, WMF is working on "Page Tools" moving to the right hand column, see mw:Reading/Web/Desktop Improvements/Features/Page tools. Of course this doesn't preclude having an infobox there in some way.

And ultimately, we would still have the problem of decreasing resolutions which would need to allow for the infobox being inline with the content or having some other way to 'dismiss' the infobox. Izno (talk) 02:40, 17 January 2023 (UTC)

Absolutely, I hear you about how tighter resolutions would bring the infobox into the prose anyways. Perhaps, like the app though, it could collapse the infobox in line after the first paragraph on narrow resolutions. I do think though that something with this omnipresence on Wikipedia should get considered in the sites future functionality, and not just be left as an "editor construct". But that's interesting about the tools, I'm certainly learning a lot about this process now, thanks!-- Patrick Neil, _oѺ^∞/Talk 03:18, 17 January 2023 (UTC)

I have turned off the "show me tons of white space" option in Preferences and adjusted my own common.css to make pages display better. If there is a massive outcry about the WMF imposing all of this white space on readers and editors, perhaps we could set our default site CSS to make page content use more space. – Jonesey95 (talk) 16:26, 17 January 2023 (UTC)

Visited link color

I switched over to the the new Vector for a few days. Overall, I can adjust to just about everything with it, save one thing. The shade of purple used for visited links just seems too... soft... for lack of a better word. I'd like to switch back to the darker color used in the legacy Vector. I know I could add some custom CSS to switch the color. Can someone help me out? Imzadi 1979 → 20:39, 16 January 2023 (UTC)

@Patafisik (WMF), I believe French Wikipedians have this documented somewhere in the archive of their Bistro. Could you find this? Thank you! SGrabarczuk (WMF) (talk) 22:06, 16 January 2023 (UTC)

This seems to be what is calculated, you can replace the color value with whatever you want:

a:visited {
  color: #795cb2;
}

— xaosflux ^Talk 22:13, 16 January 2023 (UTC)

What is the color of a visited link under the legacy Vector skin? Imzadi 1979 → 01:00, 17 January 2023 (UTC)

@Imzadi1979 it seems to be #0b0080 — xaosflux ^Talk 01:02, 17 January 2023 (UTC)

Thank you! Imzadi 1979 → 01:14, 17 January 2023 (UTC)

Are there CS attributes for visited interwiki and external links as well? I'm getting the new purple in those cases instead of the older #0b0080. Imzadi 1979 → 23:56, 17 January 2023 (UTC)

There is a closed task phab:T213778 which implemented the change but has had meaningful discussion since implementation was done that I think the team should readdress, potentially with a new task. I would guess that Femke would have some amount to say. Izno (talk) 02:34, 17 January 2023 (UTC)

Hi @Xaosflux:, the discussion on the French Wikipedia with the custom CSS is here. For further information about colors see also this explanation and this answer of AHollande (WMF).--Patafisik (WMF) (talk) 10:42, 17 January 2023 (UTC)

I found both link colors to be unreadably light, despite them apparently passing contrast tests. I added these customized colors to my common.css file, which worked for me:

a {
    color: #0645ad
}
a:visited {
    color: #58219a;

The colors came from me testing colors on a color wheel until they felt right, not from any scientific or precedent-based process. – Jonesey95 (talk) 16:28, 17 January 2023 (UTC)

My unscientific analysis of accessibility issues (using data that may under- or overestimate this easily by a factor of 2), indicated that almost a quarter of people had some accessibility issue with the new colours, which is likely less than the old colours. There is a follow-up discussion on the phab on my talk.

I still hope a further iteration is done, as it should be feasible to at least make the link colours distinguishable for colourblind people. I think that – rather than trying to solve this ourselves – we should look for precedents and ask WebAIM if they have example colours that work. —Femke 🐦 (talk) 17:22, 17 January 2023 (UTC)

I'm appreciative of the intent behind the new colors, but they're just too light. I applied the CSS above to Wikisource, which fixed a problem where new shade of purple for visited links just didn't stand out very well from the page status backgrounds on a page like Index:America's Highways 1776–1976.djvu. Imzadi 1979 → 23:59, 17 January 2023 (UTC)

The switch

It's now 15:00 UTC on January 18. As we can see the new Vector is being deployed on some pages after clicking links but mostly the old Vector styles still persists. Thingofme (talk) 15:54, 18 January 2023 (UTC)

There was apparently a minor delay of 30 mins or so? And it gives an hour window for changes to even start appearing. Special:Diff/1134415805 Terasail^[✉️] 15:57, 18 January 2023 (UTC)

There are problems here – I have manually switched back to Vector 2010 twice in my preferences (which FTR I strongly prefer, starting with the left-sidebar being far too wide (and not adjustable AFAICT) in Vector 2022), but pages keep defaulting back to 2022 layout against my fill. Please FIX THIS. I don't want to be forced to use Vector 2022. --IJBall (contribs • talk) 16:01, 18 January 2023 (UTC)

Same for me.

Articles are always displayed in Vector 2010 but talk-pages and project-pages revert to Vector 2022 at random. A couple of refreshes bring back V2010 but another additional refresh can revert to V2022. So, strange. How does these flaws make into live?! TrangaBellam (talk) 16:06, 18 January 2023 (UTC)

@IJBall: Came here to complain about that. According to the WMF staffer's post above, we have to change it back in our global preferences, otherwise the new skin will just override it again. If someone could explain to me why they have decided to make the local preferences unresponsive, I would be grateful. —Compassionate727 ^(T·C) 16:06, 18 January 2023 (UTC)

Also pinging TrangaBellam —Compassionate727 ^(T·C) 16:07, 18 January 2023 (UTC)

I have manually reset twice – it still does what User:TrangaBellam is referring to – randomly switching back and forth between 2022 and 2010. And, FTR, clearing my browser cache does not help. --IJBall (contribs • talk) 16:08, 18 January 2023 (UTC)

There are random switches, sometimes a page is shown Vector 2022 but sometimes the legacy styles were shown when I visit a page. Thingofme (talk) 16:13, 18 January 2023 (UTC)

@Thingofme Clear your page cache for any page showing the wrong skin? Hit Ctl+F5 to cold reload the page (On windows) This might help? Terasail^[✉️] 16:14, 18 January 2023 (UTC)

When I purged the cache the style immediately changed to Vector 2022 but after coming back again it reverts back to Vector 2010. Thingofme (talk) 16:17, 18 January 2023 (UTC)

Wikipedia:Vector 2022#What to expect on January 18th, 2023 Does state the change will "taking effect" until 16:30UTC, so should probably just wait the 20 mins to see if it calms down after then (hopefully) before ringing any alarm bells. Terasail^[✉️] 16:20, 18 January 2023 (UTC)

@IJBall and Thingofme: Like I said, you have to do in your global preferences. When you go into your preferences, you have to scroll down to the manage global preferences link, then change your appearance over there. See the screenshot. —Compassionate727 ^(T·C) 16:20, 18 January 2023 (UTC)

OK, that is seeming to work – thanks for the detailed explanation of doing it in Global settings Compassionate727!!

P.S. I wish they made it as easy to embed images in talk page discussion as you've done here... --IJBall (contribs • talk) 16:25, 18 January 2023 (UTC)

@IJBall - thank you for raising this and apologies for this situation. Since we are currently rolling out in stages in order to minimize server load, we are updating the skin default in four stages, which is affecting local preferences. Local preferences will work once as expected once again once the deployment is completed, in about 20 minutes. OVasileva (WMF) (talk) 16:18, 18 January 2023 (UTC)

OMG, how do I get my old display back? This is awful. It's like looking at the mobile version of the website. The menus at the top of the page are so tiny and sometimes they disappear completely. And there is all of this white space, there is actually less room for the content of the page. It doesn't make the page more readable but less readable. This website is all about the content, not having 30+% of the page be white space. And the links on the left-hand side are sometimes replaced by a table of contents. Is there an alternative to this view? I don't remember ever "choosing" this display. Help! Liz ^{Read! Talk!} 16:38, 18 January 2023 (UTC)

Once I found the Preferences link (which you have to hunt for), I was able to change my Display to Vector Legacy which resolved the problems with these new changes. I can't see, in any way, how these changes are an improvement. Some options you need, like an upper menu, are too small. The options/content you need is less visible and options you don't need are more prominent. I am just so grateful that there is the ability to go back to the more functional older version of the display. Liz ^{Read! Talk!} 17:04, 18 January 2023 (UTC)

@Liz, under "skins" in Special:Preferences / Special:GlobalPreferences. — Qwerfjkltalk 17:07, 18 January 2023 (UTC)

Why??

Why on earth was this unilaterally imposed on the community as the default after all?? An RFC was held to gauge the support to make this new skin the default and it ended with nothing close to a consensus in favor of Vector 2022, yet you just go ahead and ignore it and impose this on a community that clearly doesn't want it?? And what's worst is that none of the issued raised during the RFC have been addressed in any way. This is one of the worst cases of ignoring your community I have witnessed in the history of Wikipedia. Please roll back the switch of default as soon as possible.Tvx1 16:48, 18 January 2023 (UTC)

If this is the worst case of ignoring the community that you've seen, you've lived a gilded wiki-life. See WP:FRAMGATE as an example. Anyway, if you've been ported to the new Vector and you want to switch back, there's a bolded link in the left sidebar that will take you right to the setting in your preferences. Ivanvector (^Talk/_Edits) 17:07, 18 January 2023 (UTC)

@Ivanvector: agreed this isn't the worst WMF action ever but it's certainly not the best. Has there already been a well-attended discussion about whether this should be made opt-in rather than opt-out on WP? VQuakr (talk) 17:32, 18 January 2023 (UTC)

Highlighting, limit turned off?

In the past, when I have gone onto pages with complicated highlighting, the highlighting has often gone something like "Can't do highlighting in X ms, stopped trying". However now, I think I have been running into problems where it just doesn't stop. I can edit some articles, but ones like Chi Upsilon Sigma that would require compliated highlighting have frozen and in many cases crashed by browser. I turned off the replacement highlighting in preferences, but that doesn't appear to make a difference. Is there any way to either restore the limit for how long it will work on highlighting or turn it completely off? I'm working on chrome, but I've seen the same effects on other browsers, but Firefox seems just fine. Any suggestions on getting things working other than changing browsers to FF? Naraht (talk) 21:00, 10 January 2023 (UTC)

Syntax highlighting has been freezing large pages for me too recently. It's a really disruptive issue for a feature that ought to be stable at this point. {{u|Sdkb}} ^talk 22:02, 10 January 2023 (UTC)

I have to turn it off because I have a habit of having multiple edit pages open at the same time, which can cause my browser to freeze. It started happening to me a few weeks ago, it is a real shame since I found the feature useful. But I don't find freezing my browser regularly that useful. Terasail^[✉️] 16:52, 11 January 2023 (UTC)

Terasail How do I turn it completely off? I'm currently using FF on pages that are having large amount of syntax highlighting, but would like to go back to Chrome.Naraht (talk) 14:47, 12 January 2023 (UTC)

@Naraht you should just be able to click the highligter icon in the edit toolbar, then it stays off. — xaosflux ^Talk 14:59, 12 January 2023 (UTC)

xaosflux no change to the light grey highlighting when I click the highlighter icon above (the one to the immediate right of the puzzle piece) Note, it isn't really working that well anyway. Everything in this section that is indented with colons is highlighted, which I don't think it is desired.Naraht (talk) 15:14, 12 January 2023 (UTC)

@Naraht is that the highlighting from disucssion tools, while you are in READING mode, or is it highlighting while you are in EDITING mode? Check in Special:Preferences#mw-prefsection-gadgets to see if you opted-in to the gadget-based highlighter, and turn that off as well. — xaosflux ^Talk 15:31, 12 January 2023 (UTC)

xaosflux EDITING mode (reading mode has never been a problem). I had the gadget-based highlighter set on until about a week ago until I started trying to diagnose this, but it has been turned off since, and I'm still have the problem.Naraht (talk) 15:34, 12 January 2023 (UTC)

@Naraht try loading this page in safemode, is it off there? Are you using visual editor? Which skin are you using? — xaosflux ^Talk 16:32, 12 January 2023 (UTC)

Xaosflux In safe mode it does not show the highlighting. I'm *not* using the Visual Editor (I've used it a bit over the previous months, it is useful for a few things, but I'm using source editor entirely now). Skin is the Vector Legacy.Naraht (talk) 20:25, 12 January 2023 (UTC)

@Naraht above the edit window, on the toolbar, to the left of where it says Advanced, what happens if you toggle that highlighter control? — xaosflux ^Talk 22:02, 12 January 2023 (UTC)

Xaosflux I only get that about 10%(?) of the time, most of the time I only get the two rows of icons, is there any way to force that to appear?Naraht (talk) 15:31, 13 January 2023 (UTC)

@Naraht turn off everything you have on in User:Naraht/common.js and User:Naraht/monobook.js/User:Naraht/vector-2022.js/User:Naraht/vector.js; User:Naraht/common.css, User:Naraht/vector-2022.css/User:Naraht/vector.css first; then see if it is acting consistent. If it is, you have something conflicting in one of those, you can try turning lines back on one at a time to see then. — xaosflux ^Talk 15:38, 13 January 2023 (UTC)

Xaosflux I've commented out everything in all 7 files and I'm still only getting the two rows of icons. (and I tested on a file in my sandbox (with reload and reload while holding down each of the "shift type" keys respecitively) Is a brand new user supposed to get the part that says advanced or do I need to click on something in the two rows of icons to see it? Also, I had "Enable the legacy (2006) editing toolbar." turned on.Naraht (talk) 15:51, 13 January 2023 (UTC)

@Naraht yse if you open this page in a "private browsing" / "incognito" / etc browser you should see it logged out, with just the default options enabled. If you want to reset all of your preferences to what a new user would have, you can do so at Special:Preferences/reset and Special:GlobalPreferences/reset. Please be aware, there is no "UNDO" of a reset there. — xaosflux ^Talk 16:01, 13 January 2023 (UTC)

I was trying to use the image with the highlighter to turn it off, but the image in the small box of icons on the right (orangish shape with lines through it appears to turn it on and off. While that will turn things off, it still doesn't help with the overriding issue , but if I'm concerned on a file, I'll quickly edit something small to turn it off. (This at least helps with *that* part) (and if you'd like to move this conversation to my talk page, I'm fine with that. Also, do you know what I set that vies me the double link of icons above the edit window rather than the single line that starts out B I ? I'd like to have *both* things above, since the "B I" has access to special characters and the double line of icons has find/replace.Naraht (talk) 16:05, 13 January 2023 (UTC)

Depending on which toolbar you have enabled the highlighter may be an icon that looks like this: {}. — xaosflux ^Talk 16:26, 13 January 2023 (UTC)

OK. So I can turn the highlighter off, and I guess that takes care of things *for now*. I do still wonder how to get both of the choices above the edit window as I mentioned just above. I'll periodically check to see if they have the highlight fixed, but I guess it isn't as serious as before since I can do that before I access complicated scripts.Naraht (talk) 18:45, 13 January 2023 (UTC)

I experience no such problem. Can you try in private mode (logged out), and report the Chrome version you are using ? (I'm using 108.0.5359.124 ) —TheDJ (talk • contribs) 20:47, 11 January 2023 (UTC)

Removal of hlist from global styles

I've just removed hlist from global styles as a part of converting to TemplateStyles. If you see an issue, please leave a comment at MediaWiki talk:Common.css#Removal of .hlist. Izno (talk) 21:29, 11 January 2023 (UTC)

Plainlinks broken or changed?

Hi, My one-lined menu at User talk:Davey2010/TPMenu is broken, this is what it used to look like and now it shows as a bulleted list, Are there any fixes for this ?, Many thanks, –Davey2010^Talk 21:38, 13 January 2023 (UTC)

@Davey2010: hlist has been removed from MediaWiki:Common.css. You can use {{hlist}}. PrimeHunter (talk) 21:44, 13 January 2023 (UTC)

@Davey2010 The class hlist was removed, which is why your menu broke. I went ahead and swapped this to {{Hlist}} for you. Terasail^[✉️] 21:45, 13 January 2023 (UTC)

Many thanks for your help @PrimeHunter and @Terasail it's greatly appreciated and many thanks @Terasail for changing this for me, Many thanks, Warm Regards, –Davey2010^Talk 22:32, 13 January 2023 (UTC)

"Polluted" categories

Projectspace categories like Category:Lists based on Wikidata, Category:CSS image crop using invalid parameters or Category:Chem-molar-mass both hardcoded and calculated are automatically generated by maintenance templates, meaning that they're impossible to empty of draft or userspace pages that are using those maintenance templates -- so to avoid the database reports for categories with draft or userspace pages in them becoming cluttered up with permanent kludge that was impossible to resolve, Wikipedia has long had the {{polluted category}} template to flag certain categories as not of concern to category cleanup projects so that they would not get detected or listed by the cleanup reports.

However, something seems to have happened, and some categories that are tagged as "polluted category" are getting detected and listed at Wikipedia:Database reports/Polluted categories (2) despite the tag. All three of the categories I listed above, for example, are tagged as "polluted" categories, yet are listed in the current run. Could somebody investigate why this is happening, and apply whatever fixes are necessary to get these categories out of the way? Thanks. Bearcat (talk) 03:25, 12 January 2023 (UTC)

You should speak with the bot op first. Izno (talk) 04:11, 12 January 2023 (UTC)

@DannyS712: * Pppery * _{it has begun...} 03:44, 14 January 2023 (UTC)

I'll take a look when I get a chance, sorry - I didn't know about that template before. DannyS712 (talk) 08:16, 16 January 2023 (UTC)

Talk page appearance

Just a quick note so y'all can apportion blame properly:

The Editing team is planning some changes. These will only be visible to people who have enabled the "DiscussionTools" Beta Feature. If you see them, and don't like them, they can all be turned off in Special:Preferences#mw-prefsection-editing-discussion (last item, "Show discussion activity").

The upcoming changes that you should blame on the Editing team, rather than on the Web team, are:

• The discussion activity items that are currently visible in Talk: and User_talk: namespaces only will finally be enabled in other talk namespaces, but not in any even-numbered namespaces (e.g., the namespace this page is in).
• The old [reply] button will become a Reply button. This is because it's easier for brand-new editors to figure out what a button is. You'll still be able to re-style it, but if you're using the old script to change it, it'll probably need to be updated.
• [Later] They're going to add an extra "Add topic" button, so you don't have to scroll all the way back up to the top of the page to start a new section. For Vector 2022 only, this will be in its sticky header. (For all the other skins, I believe it will be at the very bottom of the page, which I guess doesn't help much if you're exactly in the middle.)
• [Later] They're going to add a line at the top of the page, under the =Page title=, that says how long it's been since the last signed comment ("Yesterday, in the kitchen with the knife, by WhatamIdoing"). This may not be helpful on this page (and won't appear here), but it should make it easier to spot whether there are any recent conversations on a more average talk page.

Pretty much all the other visible changes this month should be blamed on my teammate Szymon. ;-)

What might be useful for Editing to hear from this group in particular is:

• How should the software detect whether a talk page in a non-talk namespace (e.g., Help: or Wikipedia:) is the right sort of place for a discussion? If you have ideas about a reliable heuristic, I'm sure that they would be happy to hear them.

Thanks, all. Whatamidoing (WMF) (talk) 05:39, 12 January 2023 (UTC)

Is it just me or is the way that this message is worded crazy? It reads a bit like something I might post and I had to read it twice. First time I was being overwhelmed by who is blaming who? And then once to realise that this is just an annoucement of changes being made as part of mw:Talk pages project... Bit of a wild message and not the most constructive way to ask for feedback if you ask me. Terasail^[✉️] 13:00, 12 January 2023 (UTC)

It reads like humorous sarcasm that was also missed on me, until i saw the winking emoticon. ~ 🦝 Shushugah (he/him • talk) 14:11, 12 January 2023 (UTC)

WMF accounts should avoid inserting humour into valid updates for communities. It will often miss and come off as some "in joke" between staff. Being clear and concise is the best way to inform people of changes but insering humour both extends the message making it less concise as well as making it less clear what the goal of posting the message is. Terasail^[✉️] 15:42, 12 January 2023 (UTC)

@Terasail: It's about an upcoming interface change. Such changes always provoke posts on this (and other) pages along the lines of "I don't like it, change it back at once. Then fire the developers who foisted this on us without asking first." --Redrose64 🌹 (talk) 14:43, 12 January 2023 (UTC)

@Redrose64 While true, I run into the issue that this reads more like a "Go ahead and start complaining now at the editing team but just make sure you don't towards the web team" rather than anything particularly constructive. If the message trimmed all this finger pointing (Insert spiderman meme) that would be one thing, but it just doesn't read well for me. This would also be better if the message linked to the actual mediawiki pages which contain the explanations of each feature rather than giving long descriptions here along with coordinating some update through tech news. Terasail^[✉️] 15:40, 12 January 2023 (UTC)

Unfortunately for Whatamidoing (WMF), most of us view the WMF as one big entity and do not distinguish among the teams. I can't remember ever singling out one person at WMF for criticism (if I have done so, I was probably wrong to do it), but I have leveled plenty of criticism at the organization as a whole. I know from working in large bureaucracies that many well-meaning, helpful, intelligent, and dedicated individuals can exist within an organization that often makes large errors on a regular basis. Although I think the above inter-departmental jabs were intended as humor, WMF employees would do well to remember that when the WMF does something, the WMF as a whole gets the credit or the blame, and Wikipedians generally don't care about the internal politics. – Jonesey95 (talk) 16:01, 12 January 2023 (UTC)

The regulars on this page usually care about getting their feedback, in the most efficient manner possible, to the people who can fix the problems. These are the upcoming changes that folks should complain to the Editing team about (or ping me). If it's not on this list, you probably need to contact the Web team (or ping Szymon).

I'd hoped that these changes would go out last month, to avoid this potential for confusion, but there were delays on our end, so here we are. This is your cheatsheet for which team is causing which change.

And Redrose is right, at least about someone disliking any given change and someone saying that nobody was ever asked (e.g., in the multi-month massive consultation that started this project) or informed (e.g., in Tech/News and here). There are 116,100 registered editors here at the moment. Of course some people aren't going to see these announcements. (In 2013, my team ran high-volume CentralNotice banners for two weeks about the deployment of the visual editor, and I remember someone saying that they'd missed all the banners due to being on holiday for those exact 14 days.) Of course someone's going to dislike some of these changes. Of course someone's going to dislike all of these changes. It would be patently unreasonable of me to expect that many people to agree on any UI or design point. This is normal and expected. Whatamidoing (WMF) (talk) 18:46, 12 January 2023 (UTC)

FTR I appreciated the humor, and didn't think it was too much. Chris 12:42, 14 January 2023 (UTC)

Reply link now a link without square brackets on talk pages

I don't have an issue with it but don't recall there being any notification that they might be doing this. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 21:07, 17 January 2023 (UTC)

See #Talk page appearance above. — MusikAnimal ^talk 21:22, 17 January 2023 (UTC)

Here's a long discussion about it. – Jonesey95 (talk) 21:48, 17 January 2023 (UTC)

Image thumbnail bug

Default thumbnail

Size set to 375px

Size set to 250px, which calls the 375px thumbnail if system DPI scaling is set to 150%

Does anyone know why some thumbnails sizes for some images, like File:Weekday Color.svg at 375px (direct link), are not updating? No amount of purging or reloading seems to help. --Paul_012 (talk) 16:18, 13 January 2023 (UTC)

These all look about the same to me? Is this only happening for you here on the English Wikipedia? Is it only with commonswiki files (If so have you asked over at commons:Commons:Village_pump/Technical?)? — xaosflux ^Talk 19:21, 13 January 2023 (UTC)

Try using the direct link. The error is with the file served by the server, so it's reproducible on every Wikimedia site. I haven't asked at Commons VP as I believe it's less frequented. But if no one here knows what's going I guess it'd need to be reported at Phabricator. --Paul_012 (talk) 14:31, 14 January 2023 (UTC)

To be fair, there was an spike of HTML status 500 from the thumbnailing system at the time (https://grafana.wikimedia.org/d/Pukjw6cWk/thumbor?orgId=1&refresh=30s&from=now-12h&to=now). Snævar (talk) 19:42, 13 January 2023 (UTC)

I still see the difference here and also via the direct link (but not via a 320px direct link, for example). The middle image is showing more-saturated colors, i.e. the previous version of the file. The file was updated on 28 November 2022 and again on 29 November 2022. Is there something that can be done to purge a cache somewhere? – Jonesey95 (talk) 21:53, 13 January 2023 (UTC)

Hmm. This appears to have since been resolve somehow. Still don't know what was going on. --Paul_012 (talk) 08:21, 17 January 2023 (UTC)

I see the correct image in all three examples now as well, and in the direct link. It looks like some sort of cache was cleared, either by an automated process, or by a gnome who read this discussion. – Jonesey95 (talk) 16:31, 17 January 2023 (UTC)

Tables and the Edit Toolbar

In all my years of editing Wikipedia, I am still not sure how to produce tables. I have been to the help pages for table construction, and that says that to produce a table, one needs to go to the Edit toolbar and select "Insert Table". This does say that this is available on Google Chrome, the search engine that got me here, but I am not sure where the Edit toolbar is. Would someone like to explain to me where one can find it? Many thanks in advance for any help. YTKJ (talk) 18:13, 13 January 2023 (UTC)

@YTKJ: We have several help pages mentioning tables and several toolbars. Please link pages you refer to. See Help:Table for general help about making tables in the source editor. In the desktop version of the site, the default toolbar for the source editor is right above the edit area and has an "Advanced" option. You can click it and then a table icon to the right to insert a table. You can also copy an existing table and modify it, or write the table code from scratch. PrimeHunter (talk) 18:44, 13 January 2023 (UTC)

See also mw:Editor. Izno (talk) 19:31, 13 January 2023 (UTC)

@YTKJ, it sounds like you're reading the directions for the visual editor. This URL should open the visual editor in your sandbox: https://en.wikipedia.org/wiki/User:YTKJ/sandbox?veaction=edit

There's a button on the far side of the toolbars that looks like a pencil, and that will let you switch back and forth between wikitext and visual editing (unless you've disabled that in your prefs). Whatamidoing (WMF) (talk) 20:47, 16 January 2023 (UTC)

Cannot find interlanguage for links for Categories

Tracked in Phabricator
Task T326788

Moved from Wikipedia:Village pump (miscellaneous)

Hi, If I got to a category page (e.g. : Category:Contents), I cannot find links to the same category in other languages (e.g. fr:Catégorie:Accueil while the Wikidate item (e.g. wikidata:Q1281) lists them well ! Could someone explains me what is happening ? Thank you, Jona (talk) 16:44, 13 January 2023 (UTC)

@Jona This is a bug that seems to affect the language selection button on non-article (category, template, project...) pages on wikis using the Vector 2022 style - so English works OK but French is broken, German works OK but Danish is broken, etc. It was reported as phab:T326788; there has been a patch put out and so hopefully it should be fixed soon. Andrew Gray (talk) 18:31, 13 January 2023 (UTC)

Wikidata interlanguage linked templates not working

Tracked in Phabricator
Task T316559

There are 3 other language equivalent templates linked with Template:Diplomatic missions of Norway on Wikidata, but from en Wikipedia I get an error when selecting the language menu on top right (Vector skin 2020) Page contents not supported in other languages.. Any idea why? ~ 🦝 Shushugah (he/him • talk) 02:52, 14 January 2023 (UTC)

This is from a decision to make language switching unavailable for anything other than article space. See the phab ticket for more info. Terasail^[✉️] 02:58, 14 January 2023 (UTC)

... and is being adjusted, see other task. Izno (talk) 03:00, 14 January 2023 (UTC)

gallery mode="slideshow" broken

Tracked in Phabricator
Task T326990

I was away for a week and now I notice that gallery mode="slideshow" is broken. See, for example, 117th United States Congress#Party summary. Same issue for 118th Congress page as well. The gallery syntax of the articles has never been changed, so it must be happening due to something else in the background. Does anyone know what went wrong, and what can be done to fix it? Thanks! —CX Zoom[he/him] ^{(let's talk • {C•X})} 21:21, 13 January 2023 (UTC)

@CX Zoom: It appears to only fail when both slideshow and caption are used. Simplified example:

<gallery mode="slideshow" caption="Example">
File:Example.jpg
File:Example.png
</gallery>

You can omit caption as a workaround for now. PrimeHunter (talk) 21:39, 13 January 2023 (UTC)

I did not see an existing bug report, so I have created one. T326990. – Jonesey95 (talk) 22:09, 13 January 2023 (UTC)

Thank you very much PrimeHunter and Jonesey95. —CX Zoom[he/him] ^{(let's talk • {C•X})} 22:34, 13 January 2023 (UTC)

I tried doing that, see Special:Diff/1133460411#Party summary, and while the resultant is better than current situation, it continues to be buggy relative to its prior behaviour. For one, the first image is huge and all others are the older size, even though they are all the equally sized svgs. A few moments ago, there appeared a vertical scrollbar for no reason. I haven't seen it before. —CX Zoom[he/him] ^{(let's talk • {C•X})} 22:43, 13 January 2023 (UTC)

I saw this and checked the gallery I use on WP:ERT and it is also beyond broken with overflow. Its just as broken on test2 so it isn't just an enwiki issue... Terasail^[✉️] 23:19, 13 January 2023 (UTC)

Missing File section edit link in mobile web

Resolved

 – Local css was updated. — xaosflux ^Talk 16:42, 16 January 2023 (UTC)

Since yesterday, section edit links in mobile web has disappeared from File namespace. Issue exists even when logged out and tried in Opera and Chrome browser Android 10 OS smartphone. I did not find this problem in other namespaces and in desktop view. The only edit button visible is the one at the top of page, which for most part is useless since it only opens the "lead section" which will be empty for most files. This has made editing file pages impossible in mobile web. The button is visible in commons and other language Wikipedias, so this seems to be something specific to English Wikipedia. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 06:47, 14 January 2023 (UTC)

@ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ: When you click the edit button at top, the end of url contains #/editor/0. Change that to #/editor/all. This will open the entire page in editing views. A long process for a much smaller task, but until fixed, this is the workaround. —CX Zoom[he/him] ^{(let's talk • {C•X})} 08:22, 14 January 2023 (UTC)

• Notably, this appears to be working on testwiki, so may be something we are doing here... — xaosflux ^Talk 10:27, 14 January 2023 (UTC)
  • @Xaosflux: Looks like MediaWiki:Filepage.css#L-74 is probably the culprit. Anomie⚔ 13:29, 14 January 2023 (UTC)

    @Xaosflux @Anomie Thanks for the observations, I suggested a fix at MediaWiki talk:Filepage.css#Missing File section edit link in mobile web. Matma Rex talk 06:26, 16 January 2023 (UTC)

    Section edit buttons are back now after that css was removed. Thank you all for the help. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 10:27, 16 January 2023 (UTC)

Log out

Right now, if you happen to click "log out", it does just that. It was also like that quite some time ago (not sure when), when I came here (I believe) to ask about a delay of some sort. I was given a solution that made it so when you clicked on "log out", a small pop-up would appear asking: "confirm you want to log out" (or something like that). It was just what I was looking for and it worked well. But I noticed today that it no longer seems to be working. I inadvertantly clicked "log out" and was immediatetly booted out. Did something change? Is it possible to still have this... fix, in place? If so, pleaae let me know what I need to do. Thank you - wolf 07:07, 14 January 2023 (UTC)

User:Guywan/Scripts/ConfirmLogout.js works for me. Stryn (talk) 10:10, 14 January 2023 (UTC)

(edit conflict) :@Thewolfchild: According to your common.js, you're useing User:Fred Gandt/confirmLogout.js, written by @Fred Gandt:. I for one am using User:Writ Keeper/Scripts/logoutConfirm.js by @Writ Keeper:, which isn't working for me either ... when I press the cancel button on the confirmation prompt, I still get logged out. I'll go and check out the working one now ... Graham87 10:14, 14 January 2023 (UTC)

Nah as a screen reader user, I prefer the prompt type that WK's script uses. A screen reader doesn't automatically focus on the confirmation prompt in the script by @Guywan:; there may well be ways to fix that on the JavaScript end but I don't know what they might be. Graham87 10:25, 14 January 2023 (UTC)

Thanks for the replies so far guys. I'll keep an eye on this thread to see if a solution comes along. Cheers - wolf 10:30, 14 January 2023 (UTC)

None of those scripts appear to support the logout link in Vector 2022's sticky header. Nardog (talk) 10:44, 14 January 2023 (UTC)

I expect there will be a lot of issues like this moving forward with Vector 2022, and updates will be needed. I'll be looking at my own; I'm always looking at my own; updating code is a constant and often tiresome need. Can we have a show of hands for folks in this thread currently using Vector 2022? Fred Gandt · talk · contribs 15:00, 14 January 2023 (UTC)

I can confirm (no pun intended) that my script is working as expected with both the Vector legacy and 2022 skins. Mine works by literally replacing the html element containing the "log out" link rather than trying to change the original's behaviour and that's what it's doing. Clicking the default link should take the user to a confirmation page anyway (something that didn't happen when I built the script back in the dark ages), so users should never get booted out by an accidental click even if they're not using one of these scripts. All that previously striked-through is rubbish. Fred Gandt · talk · contribs 15:19, 14 January 2023 (UTC)

Still using Vector legacy 2010 default. So, is there a quick-fix for this...? Cheers - wolf 15:28, 14 January 2023 (UTC)

I'm using Vector legacy and my own script and it's working as expected, so I don't know what needs fixing. Fred Gandt · talk · contribs 15:32, 14 January 2023 (UTC)

Seems I'm using the same skin and the same script, but it stopped working for me. 🤷 Don't know what to say. (Except that I do appreciate you writing that script in the first place, as well as the help it provided me for the last couple years. Thank you for that). Other than that, I hope a fix comes along soon. Cheers - wolf 15:55, 14 January 2023 (UTC)

I just rewrote the script to use the default confirmation of Special:UserLogout. By default, Wikipedia has code in place to ignore the normal confirmation process and blast users straight out the door with a hardly noticeable wave. The way I solved this problem was to completely scrap the bizarre code by replacing the log out link, then offer the "Are you sure?" confirmation. I just removed the need for the confirmation since it's already built into the default interface thus removing a step for users who actually want to log out. You should see, with my script active, when clicking the log out link, that you land on Special:UserLogout and are asked to confirm. If you don't want to log out, just go back a page in your browser history and it's like it never happened; if you want to log out, hit the big blue button and you're gone. Fred Gandt · talk · contribs 16:09, 14 January 2023 (UTC)

@Thewolfchild: you may not be aware that user scripts are not loaded on user preference pages and as such, any user script (including these log out jammers) will not function on those pages. Please confirm if User:Fred Gandt/confirmLogout.js is not functioning as described in my previous comment on non Special:Preferences pages. Cheers Fred Gandt · talk · contribs 16:27, 14 January 2023 (UTC)

When I first got booted out, I was on an article page. But anyway, I just clicked "log out" from my talk page and it worked just as you described. Thank you Fred, it's appreciated. Cheers - wolf 16:46, 14 January 2023 (UTC)

Super duper :) Fred Gandt · talk · contribs 17:00, 14 January 2023 (UTC)

In re logging yourself out: One of the things I'm liking about Vector 2022 is that the logout button is hidden in a dropdown menu. I have not ever (yet?) accidentally logged myself out while using that skin. Usually, for me, it happens when I'm clicking on Special:MyContributions just as the UTC clock gadget loads, but this isn't a problem in the new design. Whatamidoing (WMF) (talk) 20:53, 16 January 2023 (UTC)

I use a completely different method. I remove the logout link entirely (add #p-personal li#pt-logout {display: none;} to your common.css). Then, if you want to logout, you can go to your preferences and use the link there. (What I actually do is add a logout link to my toolbox. I used to frequently accidentally logout when the link was in the default location, but in many years, I've never done so from my toolbox link. And there's a confirmation dialog if I ever do misclick.) MANdARAX • XAЯAbИAM 17:14, 14 January 2023 (UTC)

@Graham87 et al.: Sorry, I've known that my logout confirm script hasn't been working for a while, but just haven't gotten around to look into it. It should be fixed now! Writ Keeper ⚇♔ 17:23, 14 January 2023 (UTC)

Ingleside, Texas

I'm not sure what to do with the history section at Ingleside, Texas. It is completely unsourced, and is nearly identical to the history on the city website. The section was added by an IP back in 2010, and the original edit included a promo for a book. I'm not sure if the section needs to be removed and nuked. Thanks! Magnolia677 (talk) 12:44, 14 January 2023 (UTC)

@Magnolia677 Wayback suggests the city website dates to 2016.[http://web.archive.org/web/20160815000000*/https://www.inglesidetx.gov/317/Ingleside-History] Doug Weller talk 14:04, 14 January 2023 (UTC)

@Doug Weller: That answers the chicken and egg question. Thanks! Magnolia677 (talk) 17:46, 14 January 2023 (UTC)

@Doug Weller: I don't see how the Archive.org link you gave indicates anything about the website age. --R. S. Shaw (talk) 05:19, 18 January 2023 (UTC)

@Magnolia677: The Archive page at http://web.archive.org/web/20101202115028/http://inglesidetx.gov/InglesideHistory.cfm shows that all of the history text the IP added on 27 Dec 2010[1] existed on the city website at least 2 weeks earlier. Hence that text addition seems to constitute a copyright violation. This WP section says how to handle it, although apparently that means most of the history of the page would then unfortunately be inaccessible to non-admin users. --R. S. Shaw (talk) 05:19, 18 January 2023 (UTC)

I have to apologise. I see I was using the wrong url. Or maybe not, running the url again through Wayback now says "Saved 5 times between June 28, 2022 and January 14, 2023." which is NOT what it said the first time I ran it. This is worrying as we often depend upon Wayback for copyvio issues. Doug Weller talk 08:41, 18 January 2023 (UTC)

Editing window using Safari on iPad obscured

This is what I see on Safari, making it impossible to edit. Chrome doesn't have the problem. Doug Weller talk 12:03, 15 January 2023 (UTC)

Editing window using Safari on Ipad

Doug Weller talk 12:03, 15 January 2023 (UTC)

What version of hardware/software? IznoPublic (talk) 17:57, 15 January 2023 (UTC)

@Izno iPad Air, IOS15.6 which is old now, so I can't blame it on that. I'm guessing an update to Vector 2022 which I use. Doug Weller talk 13:12, 16 January 2023 (UTC)

Hey @Doug Weller, thanks for reporting this. Could you add &safemode=1 to the URL in the editing mode, and write back if you still see this issue? For me, Safari on iPad works fine but I see we're using different gadgets. SGrabarczuk (WMF) (talk) 21:36, 16 January 2023 (UTC)

iOS 15.6 is supported at both Modern and Basic levels in mw:Compatibility#Browser support matrix. At a minimum, it shouldn't look like that, so if it's still an issue in safe mode, it's something for WMF to look into. :) I'd have guessed it was display: grid that was the issue, but that looks more or less supported since iOS 10.3, so it is apparently Something Else. Izno (talk) 02:20, 17 January 2023 (UTC)

@Izno@SGrabarczuk (WMF) This is driving me a bit nuts. Adding safe mode seems to work but then at times it works without adding anything. Pretty erratic. Thanks everyone Doug Weller talk 13:38, 17 January 2023 (UTC)

If adding safe mode works, then it's about some gadget or user script you're using. SGrabarczuk (WMF) (talk) 15:35, 17 January 2023 (UTC)

Hi Doug it looks like you are loading vector-2022.js twice. You have an unnecessary line in User:Doug Weller/common.js that should be removed. That might be causing issues? Jdlrobson (talk) 16:25, 17 January 2023 (UTC)

@Jdlrobson I’m hoping that was the problem as things seem to be working, although something weird happened today with just error messages but I’m guessing that was Wikipedia. Doug Weller talk 20:05, 17 January 2023 (UTC)

Oops,forgot to say thanks! Doug Weller talk 20:06, 17 January 2023 (UTC)

Sadly the problem still exists, erratically. Doug Weller talk 21:22, 17 January 2023 (UTC)

You said it wasn't an issue with safe mode. You will need to troubleshoot the scripts and CSS you have. You can either disable/remove everything out of your CSS/JS and then re-add this content until the issue resurfaces, or do a binary search with the same process, where you do half, and if it's not in that half it's in the other half, etc. Izno (talk) 21:56, 17 January 2023 (UTC)

I worded that badly perhaps. Sometimes safemode works, but then sometimes it works without safemode. But it's not a change caused by anything I did, so I think I'll wait a bit to see if it goes away with some other change. Binary search sounds a great idea if I decide to go that way. Thanks for that. Doug Weller talk 09:13, 18 January 2023 (UTC)

Does it work reliably when safe mode is activated? If so and it sometimes works without safe mode, then it sounds like there is one or more race conditions with some of your customizations that causes the problem to manifest some of the time without safe mode. isaacl (talk) 17:22, 18 January 2023 (UTC)

Articles created not appearing in search results

Tracked in Phabricator
Task T327199

What's good y'all.

I've noticed that since my article on Émile Reutlinger, some of the article's I have created have not been showing up in seach results (unless you type in its exact name). This also applies to the articles for Johann Eustach von Westernach, Johann Kaspar von Stadion, and Death and funeral of Pope Benedict XVI. All of them are articles that I have made that fail to appear in search results even when linking to them in other articles. There doesn't seem to be an corelary between any of them, besides that I made them and all of them, with the exception of the article on Johann Eustach von Westernach, had the under construction template on them. Is this a known issue and what can I do to combat this? Knightoftheswords281 (talk) 00:26, 3 January 2023 (UTC)

I think this is a bigger issue than just your articles. Articles that I've created after the first week in December don't show up in search results via autocomplete, until I type the complete name. – Muboshgu (talk) 20:35, 15 January 2023 (UTC)

@Knightoftheswords281 what "search results" are you looking at? The on-wiki internal search, or an external search provider? For your example of Johann Eustach von Westernach, our article is the first result both on the internal search, and from Google when I check. — xaosflux ^Talk 21:47, 15 January 2023 (UTC)

The internal search provider. From my experience, if you type out the full name of the article, it will appear below the search bar, however, if you even subtract or add a character, said article disappears from the search bar. Knightoftheswords281 (talk) 21:51, 15 January 2023 (UTC)

I've been noticing this as well recently. The autocomplete doesn't suggest new articles when you start typing in the search bar. HJ Mitchell | Penny for your thoughts? 21:59, 15 January 2023 (UTC)

In the past, I've seen a delay for even autopatrolled articles to appear in the search bar, but it seems to be much longer now - Macks Creek Law was created in December, and Steele's Greenville expedition at the very beginning of this month, and neither is showing up for me in the autocomplete, and both would have been autopatrolled. Hog Farm _Talk 22:05, 15 January 2023 (UTC)

It used to be a delay of about a day or so. Now it's a month. – Muboshgu (talk) 02:43, 16 January 2023 (UTC)

• I created Statue of Queen Victoria, Hove on 2022-12-23. It appears in Google search results and it's patrolled (because I'm autopatrolled), but typing "Statue of Queen Victoria, H" into the search bar does not produce a suggestion for that article; it only suggests Statue of Queen Victoria (Hong Kong), as though it doesn't think the other article exists. What's the problem and how do we go about fixing it? HJ Mitchell | Penny for your thoughts? 16:34, 17 January 2023 (UTC)

  Would someone open this as a bug using this form? The documentation at mw:Help:CirrusSearch#How_frequently_is_the_search_index_updated? suggests there should not be such a delay. — xaosflux ^Talk 16:46, 17 January 2023 (UTC)

  @Xaosflux: I don't speak developer but I've put a description of the issue at phab:T327199. HJ Mitchell | Penny for your thoughts? 19:00, 17 January 2023 (UTC)

  @HJ Mitchell are there 2 problems going on? One that that "autocomplete" doesn't populate; two that the actual search fails to come up with results? — xaosflux ^Talk 19:03, 17 January 2023 (UTC)

  @Xaosflux: If I type the exact title into the search bar it finds it and search otherwise works as expected, but the article does not appear in the suggestions below the search box unless I type the exact title perfectly. HJ Mitchell | Penny for your thoughts? 19:14, 17 January 2023 (UTC)

  @HJ Mitchell ok so looks like this is 'both problems, likely related to the same thing. I'll expand the phab task. — xaosflux ^Talk 19:25, 17 January 2023 (UTC)

UTF-8 ZERO WIDTH SPACE in page title

Tracked in Phabricator
Task T196088

Maybe you want to take a look at quarry:query/70555 and maybe you do not like those invisible spaces in titles. Cheers from german wikipedia (we too have ~20 of them). --Wurgl (talk) 21:21, 15 January 2023 (UTC)

@Wurgl, you might want to remove redirects. — Qwerfjkltalk 21:40, 15 January 2023 (UTC)

It looks to me like every single entry is a redirect. In that case, we don't care. * Pppery * _{it has begun...} 21:42, 15 January 2023 (UTC)

You are right, all are redirects (i added this field to the query). --Wurgl (talk) 21:47, 15 January 2023 (UTC)

WikiProject banners visible only in preview

Tracked in Phabricator
Task T327047

Screenshots from Talk:Sharad Yadav

Broken WikiProject banner when viewing as wiki page

WikiProject banners visible in preview window

The above screenshots are taken from page Talk:Sharad Yadav in mobile web view, Opera browser, Android 10 OS. There are two WikiProject banners between {{Talk header}} and {{ITN talk}}. They are broken when viewing it as a normal wiki page and appear as two thick lines. However they render fine in the preview window. It is strange that we have software that works fine in preview but is broken in the actual page. I know there was some work on talk page banners recently before which they were completely hidden in mobile web, can something be done to fix this? ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 04:39, 16 January 2023 (UTC)

Thanks for the bug report, this is interesting. The issue also happens on other pages with other templates (e.g. Talk:Search coil magnetometer is another example).

I tracked down this behavior to the code that displays the "About this page" section on mobile. It (unintentionally I think) also removes some content from the "Read as wiki page" view. This happens in the code here: [2]. That's definitely a bug. I filed phab:T327047 about this.

However, that code hasn't changed in a couple of months, and I am pretty sure the templates displayed correctly before. I suspect some recent change in the templates broke some assumptions in the mobile code.

There was recent work on talk page banners, but those changes are not enabled on English Wikipedia yet. I am hoping we'll do that within a few weeks (I'm one of the developers). You can preview how the page will appear after these changes here: [3] – it doesn't suffer from this issue. Matma Rex talk 06:14, 16 January 2023 (UTC)

@Matma Rex the only recent change in the templates is the change you directed to remove the height 0 on the Signpost article talk page about mobile apps. IznoPublic (talk) 17:45, 16 January 2023 (UTC)

As for displaying correctly, this phenomenon was also discussed there. IznoPublic (talk) 17:46, 16 January 2023 (UTC)

I do not see the thick lines; I see everything as it should when "Read as wiki page" is enabled. On Chrome, Android 13. —CX Zoom[he/him] ^{(let's talk • {C•X})} 14:02, 17 January 2023 (UTC)

Tech News: 2023-03

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

• The URLs in "prev" links on page history now contain diff=prev&oldid=[revision ID] in place of diff=[revision ID]&oldid=[revision ID]. This is to fix a problem with links pointing to incorrect diffs when history was filtered by a tag. Some user scripts may break as a result of this change. [4]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 17 January. It will be on non-Wikipedia wikis and some Wikipedias from 18 January. It will be on all wikis from 19 January (calendar).
• Some changes to the appearance of talk pages have only been available on Talk: and User talk: namespaces. These will be extended to other talk namespaces, such as Wikipedia talk:. They will continue to be unavailable in non-talk namespaces, including Wikipedia: pages (e.g., at the Village Pump). You can change your preferences (beta feature). [5]
• On Wikisources, when an image is zoomed or panned in the Page: namespace, the same zoom and pan settings will be remembered for all Page: namespace pages that are linked to a particular Index: namespace page. [6]
• The Vector 2022 skin will become the default for the English Wikipedia desktop users. The change will take place on January 18 at 15:00 UTC. Learn more.

Future changes

• The 2023 edition of the Community Wishlist Survey, which invites contributors to make technical proposals and vote for tools and improvements, starts next week on 23 January 2023 at 18:00 UTC. You can start drafting your proposals in the CWS sandbox.

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

MediaWiki message delivery 01:08, 17 January 2023 (UTC)

ConfigException

Tracked in Phabricator
Task T327196

Within the last hour, both of the browsers on which I'm logged in (as User:Naraht) (Chrome & FF) are giving errors that look like

MediaWiki internal error.

Original exception: [bde13a11-c59e-4e46-8642-640488f9c898] 2023-01-17 18:35:14: Fatal exception of type "ConfigException"

Exception caught inside exception handler.

Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.

.

It isn't doing it on my Edge browser, but I'm not logged in there. I can't even get to the button on Chrome and FF to log out, so I'm guessing it is logged in vs. logged out, but I'm not sure.161.107.18.136 (talk) 18:44, 17 January 2023 (UTC)

Chrome seems to be working now. The C of E God Save the King! (talk) 18:45, 17 January 2023 (UTC)

I tried it incognito, same deal. Not sure what's causing it. Not sure why wikimediastatus.net insists we're still fully up, despite there being 2600 errors per second in the last few minutes. But as we can see it seems to be fixed now? --Golbez (talk) 18:45, 17 January 2023 (UTC)

I can confirm this was happening to me until just a minute ago, I could view special pages, lists of deleted revisions, and article histories, but couldn't view pages in any namespaces. I'm on Safari for iPhone. The Blade of the Northern Lights (話して下さい) 18:45, 17 January 2023 (UTC)

I'm having this smae issue. The "original exception" seems to change with each reload. Did the hamsters get tired for a moment? ― Blaze Wolf^Talk_{Blaze Wolf#6545} 18:46, 17 January 2023 (UTC)

I'm also having the same issue, but chrome is working now. Wesoree (Talk) 18:47, 17 January 2023 (UTC)

I have changed my preferences to the new vector skin and it is working just fine in Firefox after getting that bug page before. Daniel Case (talk) 18:47, 17 January 2023 (UTC)

I've been using that skin and was still having the same issue. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 18:51, 17 January 2023 (UTC)

It's not simply a logged in/logged out issue, as I was getting the same error(s). Weird. 199.208.172.35 (talk) 18:47, 17 January 2023 (UTC)

(edit conflict × 3) I tried refreshing the page. Seems there's only about a 5% success rate for me. Sheep (talk • he/him) 18:47, 17 January 2023 (UTC)

I am on both on my phone and my laptop tbh. Sheep (talk • he/him) 18:49, 17 January 2023 (UTC)

(ec) Have been having same problem both on desktop and mobile, and have confirmation from other users (off wiki communication) that they are also having it . Seems to be resolved atm. DuncanHill (talk) 18:48, 17 January 2023 (UTC)

Same, I was getting it intermittently for the last ~10 minutes. If I refresh a few times I get the page to load successfully. Firefox. Just tried refreshing a few pages 10 times to recapitulate the issue, but now it seems to be working for me all the time. Ajpolino (talk) 18:46, 17 January 2023 (UTC)

Is it me or is Wikipedia having a stroke? at least it is fine now, but reports from DownDetector are going up rn. Wesoree (Talk) 18:53, 17 January 2023 (UTC)

I mean.. people can fake DownDetector as evidenced when Elon Musk took over Twitter and the reports there went up even tho Twitter was just fine. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 18:56, 17 January 2023 (UTC)

Same, from my observation lasted ~5 minutes. —Alalch E. 19:15, 17 January 2023 (UTC)

if this was geared towards the many vandals on Wikipedia, then we could just have a long awaited break from rvv's. This seemed to last ~5 mins, as i was refreshing the page. The error msg's original exception would change each reload. Wesoree (Talk) 19:23, 17 January 2023 (UTC)

Unfortunately the vandals did not appear to be affected (I could still see them active via SWViewer) ― Blaze Wolf^Talk_{Blaze Wolf#6545} 19:28, 17 January 2023 (UTC)

Error message

Just for documentation.

MediaWiki internal error.

Original exception: [cb36079c-11b5-48cf-bf81-ee8db28eeb85] 2023-01-17 18:43:31: Fatal exception of type "ConfigException"

Exception caught inside exception handler.

Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.

— Vchimpanzee • talk • contributions • 18:51, 17 January 2023 (UTC)

See above. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 18:51, 17 January 2023 (UTC)

Me too. Same error on Edge, Chrome and Firefox. Just lasted a minute or two. — Maile (talk) 18:57, 17 January 2023 (UTC)

Apologies to all the affected people. There is an explanation at phab:T327196#8532474. Basically, the Editing team deployed two related changes, and the servers didn't process them in the logical order. The length of time that this was visible depended on which server you were reaching. It appears to all be fixed now. Whatamidoing (WMF) (talk) 21:03, 17 January 2023 (UTC)

So what you're saying is the servers didn't use common sense? ― Blaze Wolf^Talk_{Blaze Wolf#6545} 21:06, 17 January 2023 (UTC)

The servers did exactly what they were told to do. Taavi (talk!) 21:15, 17 January 2023 (UTC)

Gud 1. :-) 60.241.201.38 (talk) 06:18, 18 January 2023 (UTC)

Resetting my preferences across all projects

Hi, is there a way to reset my preferences to factory defaults across all projects without having to go into every project manually? Thanks, Interstellarity (talk) 12:33, 18 January 2023 (UTC)

@Interstellarity You can set your Global Preferences and as long as you don't have local exceptions, then it will change for all wikis. Terasail^[✉️] 13:24, 18 January 2023 (UTC)

There is also a local preferences restore option and a global preferences restore option Terasail^[✉️] 13:28, 18 January 2023 (UTC)

@Interstellarity to answer your question, no - you would have to click reset on each project. You can get a list of all the projects you are attached to here: Special:CentralAuth/Interstellarity. You may not have ever changed preferences at some of the projects you never edited on, so you may only need to look at the ones with edits (you can sort that output). — xaosflux ^Talk 14:34, 18 January 2023 (UTC)

Thank you, Xaosflux for answering my question. I will do that. Interstellarity (talk) 15:57, 18 January 2023 (UTC)

Tiny print

Resolved

 – Was a client zoom level issue. — xaosflux ^Talk 14:29, 18 January 2023 (UTC)

Here's a trivial, but mysterious problem. Yesterday, with no warning, my desktop computer and 34-inch monitor decreased the size of the print on the display of all wikipedia pages from approximately 14 point print to 10 point. All other webpages remained unchanged. On my second computer, the size of the print displayed also remained unchanged. So, given that this sudden change occurred on only one computer and only on wikipedia, what do you think the problem is? My old and tired eyes don't like small print. How do I increase the size of the display of print for wikipedia pages? Smallchief (talk) 13:35, 18 January 2023 (UTC)

@Smallchief: I guess you accidentally changed zoom in your browser and the browser treats it as your preference for the website you were on at the time. In most Windows browsers: Ctrl++ for larger, Ctrl+- for smaller, Ctrl+0 for default size. Holding Ctrl while scrolling your mouse wheel may also change size and is easier to do by accident. If this doesn't help then name your browser. PrimeHunter (talk) 13:52, 18 January 2023 (UTC)

@PrimeHunter: It worked. Back to normal (for me). All's right with the world. Thanks! Smallchief (talk) 14:02, 18 January 2023 (UTC)

Vector-2022: Avoiding slow animation

I can see how having a sticky-header on pages can be useful. But is there a way to avoid the slow animation of it appearing when I scroll down? It seems to have become a popular GUI feature, but I find it distracting. I move quickly, and it feels sluggish when the GUI has to "catch up" to what I'm doing. It also breaks by concentration by having so much motion at the top of the screen if I'm reading further down. MSOffice added that sort of thing a decade or so ago, and included a "disable animation" option. Could we have such a simple overall option, or is there a CSS trick for it? DMacks (talk) 16:13, 18 January 2023 (UTC)

@DMacks maybe it's my computer, but I'm not seeing this as an "animation" at all, it seems to be a "snap" overlay - tried with firefox and chrome; are you seeing this as a moving (rolling down?) header? — xaosflux ^Talk 16:37, 18 January 2023 (UTC)

It's like pulling down a window-shade over the top bit of content. Takes maybe half a second or so. DMacks (talk) 16:47, 18 January 2023 (UTC)

Thank you, anyone else got info on this? — xaosflux ^Talk 16:49, 18 January 2023 (UTC)

@DMacks, Xaosflux: There should be a "reduce animation/motion" option in your operating system which the sticky-header (and various other animated features on Wikipedia) will respect. See https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion#user_preferences for where to find the setting. the wub "?!" 16:49, 18 January 2023 (UTC)

@The wub thanks for the note, phab:T254399 talks about this a bit. According to phab:T290101 "slide" is the expected behavior. If you have set reduce motion in your client, and it is not working - there may be a bug. — xaosflux ^Talk 16:53, 18 January 2023 (UTC)

If I am reading this correctly, this is more of a visual preference rather than anything broken. So I provided some css below that should remove the animation and make the sticky header "just appear". Terasail^[✉️] 16:55, 18 January 2023 (UTC)

@DMacks Try adding the following to your common css

#vector-sticky-header {
	transition-duration: 0ms;
}

Terasail^[✉️] 16:54, 18 January 2023 (UTC)

@Terasail thanks for the snippet, DMacks, can you let us know if this works for you if you try it please? — xaosflux ^Talk 16:58, 18 January 2023 (UTC)

Vector-2022: Table-of-contents in diff-mode

When I am looking at a diff, the full article is below the two-column diff panes. The entries in the side-bar table of contents link to the sections in the full article pane. Except the "(Top)" table-of-contents entry, which takes me to the top of the diff panes rather than the start of the article in the article pane. DMacks (talk) 16:22, 18 January 2023 (UTC)

@DMacks making sure we got this, when looking at a diff such as this one, scroll down. Clicking on (Top) goes to the "#' (top most) section of the current page, but you would rather it scroll you to the top of the article text for section-0; correct? — xaosflux ^Talk 16:41, 18 January 2023 (UTC)

Bingo. It's inconsistent with the rest of the TOC. No objection to a "scroll to top of diff" link, but that's just as easy to do using my browser 'home' key. DMacks (talk) 16:44, 18 January 2023 (UTC)

Archive box not appearing on talk page

Resolved

 – Template was not present. — xaosflux ^Talk 16:41, 18 January 2023 (UTC)

Hello! So I helped out User:Moops by adding the archive bot to their talk page, however for whatever reason the archive box isn't appearing on their talk apge. Any idea what coudl be causing this? ― Blaze Wolf^Talk_{Blaze Wolf#6545} 16:31, 18 January 2023 (UTC)

@Blaze Wolf There is no archive box template on their talk page that I can see. Terasail^[✉️] 16:36, 18 January 2023 (UTC)

@Terasail: No there is. Unless I'm being stupid it's contained in the code for the bot. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 16:38, 18 January 2023 (UTC)

You added the archive bot template, but if you actually want a box, you also have to add {{archive box}} --Floquenbeam (talk) 16:38, 18 January 2023 (UTC)

@Blaze Wolf That is only for clue bot, you are using lowecasesigma bot in this case. Also you set up the bot with a counter of 8, so I moved the archive from /Archive 8 to /Archive 1 Terasail^[✉️] 16:39, 18 January 2023 (UTC)

Oh. *facepalm* That would be because I copied it from my own talk page. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 16:40, 18 January 2023 (UTC)

Turns out I just needed to add {{talk header}}. I feel stupid now. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 16:42, 18 January 2023 (UTC)

TOCs

My talk page is messed up. There is no TOC. This also appears to be the case everywhere. Mjroots (talk) 16:41, 18 January 2023 (UTC)

 Works for me @Mjroots did you change to vector-2022? If so the TOC is now in the left sidebar, under the tools. — xaosflux ^Talk 16:48, 18 January 2023 (UTC)

I haven't changed anything. TOCs have disappeared. Makes it hopeless trying to find sections of articles to edit, especially in long articles. Same for talk pages, Wikiproject talk space etc. Put the TOCs back as they were!!!! Mjroots (talk) 16:52, 18 January 2023 (UTC)

@Mjroots If you were using the Vector skin, a forced change to Vector-2022 may have happened for you, or you may have opted-in with a link. You can revert to Vector legacy here: Special:Preferences#mw-prefsection-rendering. — xaosflux ^Talk 16:55, 18 January 2023 (UTC)

I've gone back to the previous skin. New one is crap. There was nothing marked "tools" on the left of any page that I was on, so that comment was not useful for me. Mjroots (talk) 17:00, 18 January 2023 (UTC)

I've set the old one in my preferences, and it keeps switching randomly between them. ~ ONUnicorn^{(Talk|Contribs)}problem solving 17:01, 18 January 2023 (UTC)

@ONUnicorn, try Special:GlobalPreferences, or try again later. — Qwerfjkltalk 17:15, 18 January 2023 (UTC)

Is the new skin the universal default? It appeared today, and obviously as an IP I did nothing with preferences. 67.243.247.14 (talk) 17:04, 18 January 2023 (UTC)

Yes. — Qwerfjkltalk 17:14, 18 January 2023 (UTC)

Vector 2022 skin has been deployed

Hello everyone,

The Vector 2022 skin is now the default across English Wikipedia, which means that all logged-out readers and editors will see this skin, and that all logged-in readers and editors who had Vector 2010 as their skin were switched to the new one.  Thank you for all of your questions, feedback, and time dedicated to this project - it has helped us make the skin better for all readers and editors!

This is a big change for a lot of users, and today's deployment has been a major technical undertaking involving many staff. If you see any issues with the deployment, or are hearing about problems or confusion from others, please reply here and let us know so that we can pursue and fix them as soon as possible.

If you are new to the skin, we (the Web team at the WMF) encourage you to explore our landing page for information on configuration, gadget compatibility, bug reports, and the deployment and consensus-building process here on English Wikipedia.  For general questions, you can refer to our FAQ or ask us directly here or on the talk page of the project.  

If you would like to turn the skin off or switch to a different skin, you can do so from the "switch to old look" button in the main menu (left sidebar), or from the "Appearance" section in your preferences.  

For those of you looking forward to the new page tools menu - we've experienced some last-minute issues in the release of the feature and will wait for this week's deployment train to ensure all changes are as expected.  We will release the new page tools menu on Monday, Jan 23.  

Though today's deployment is a major milestone, we are definitely planning to continue to improve and adjust the new skin. We'll be fixing bugs and thinking about and discussing how else the skin can improve for editors and readers. Therefore, we're looking forward to your continued feedback on the new skin.  If you decide to try it out, we, the Web team, suggest trying it for at least one week prior to deciding whether to switch to one of our older skins. It usually takes a few days to begin feeling comfortable with the new interface. That said, if you are unsatisfied, you may switch to any of the other skins at any time.

Once again, we would like to thank all of you for your help over the last three years of development - from giving us constant feedback to helping us draft and run the RfC, to constantly keeping us accountable for our decisions and their impacts on readers, editors, and communities.  There are more of you than we can count, but to name just a few: the closers of the RfC who did a lot of work analyzing and summarizing the RfC (ProcrastinatingReader and ScottishFinnishRadish), and also: Andre, Awesome Aasim, Barkeep49, Bilorv, Blaze Wolf, Enterprisey, Femke, Ganesha811, Izno, JCW555, Jonesey95, L235, Lectrician1, Levivich, Pelagic, RoySmith, Sdkb, Sj, Steven Walling, Terasail, TheDJ, Qwerfjkl, WhatamIdoing, xaosflux, and Xeno - thank you, and let's keep the conversation going!

OVasileva (WMF) & SGrabarczuk (WMF) (talk) 17:19, 18 January 2023 (UTC)

I got forced to the new skin, and all TOCs everywhere dissapeared. PUT THE TOCs BACK!!!! Apparently there was supposed to be "tools" on the left hand sidebar, but I never saw anything saying "tools". Fortunately, I was able to go back to the previous skin. Mjroots (talk) 17:24, 18 January 2023 (UTC)

@Mjroots - thanks for your feedback. The new ToC should be visible on the left hand side of the page. It does collapse at low resolutions to allow for more content to appear on the page. It can be opened by using the button available immediately to the left of the page title. OVasileva (WMF) (talk) 17:27, 18 January 2023 (UTC)

@Mjroots The button for the table of contents looks like this the wub "?!" 17:34, 18 January 2023 (UTC)

I understand that there are limited resources to develop a proper desktop skin as well as a mobile one. However imo the desktop experience of the new skin is not optimal. It is highly likely that most editors would use the desktop view to do serious editing. One thing I liked in the old interface is that it allowed me to go to the main page immediately. Now this is a two-step process. 67.243.247.14 (talk) 17:29, 18 January 2023 (UTC)

67.243.247.14, One thing I liked in the old interface is that it allowed me to go to the main page immediately. Now this is a two-step process - how so? Clicking on the big Wikipedia logo on the top works for me. — Qwerfjkltalk 17:32, 18 January 2023 (UTC)

(Face palm) Indeed. Maybe I was hung up on the old "Main Page" link. 67.243.247.14 (talk) 17:36, 18 January 2023 (UTC)