Talk:Reading/Web/Desktop Improvements

Vector 2022 is just awesome, but I have some recommendations

 * Thank you very much for this new design!
 * It is clearly arranged and flexible, I really love it!


 * Here are my recommendations:


 * The buttons for "Your alerts" and "Your notices" should be in that bar too, that pops up, when you scroll down. At least in that user menu.
 * There should be an opt-in for having all the subentries in the table of content (toc) fold out by default.
 * Also I noticed, that when you hover the mouse in the toc and scroll to the top or the bottom of it, it will begin to scroll the text on the right (article for example) and the toc will reset to the position that matches the position in the text. That is really annoying.


 * Best Regards --KleinerKorrektor (talk) 19:21, 18 February 2023 (UTC)

The new layout looks horrible
Hello,

I study education and am in deep shock about the new wikipedia layout. Why the fuck do UI designers think removing borders and cramping everything into togglers actually makes things better? Like who the fuck sparked that trend? Apple?

What used to look like an encyclopaedia now looks like a white wall of simply nothing. There no longer seems to be any visual (like actually visuable) organization of a page beyond the paragraphs.

It isn't just that there aren't any visible borders anymore, there also is no contrast whatsoever and the text flickers while scrolling! It horrid and counterintuitive as fuck, because it makes your eye get lost and is utterly immemorable and thus fails to fulfill the basic criteria of visual educational material.

Get education experts when designing the UI next time. This is shameful.--2A02:908:966:63E0:E94E:DAB1:D3A:483 12:55, 21 January 2023 (UTC)


 * I totally agree with your comment! I have no idea how someone may break so much the user experience as they did. I haven't been logged to wikipedia for more than a decade, but had to, to choose some older variant of visual style, to even usefully read an article. A shame on them, a shame! How come they have not tested it before release. Sslukt (talk) 15:11, 21 January 2023 (UTC)
 * Small correction, they did test it before release (and I hated it then too), but couldn't figure out how to put it into words. The OP states it excellently. Wiki joedirt (talk) 23:16, 30 January 2023 (UTC)
 * Same! I haven't logged in for 7 years, but now had to, just to change the layout.. why do you even need to log in for that? makes no sense. P3rttiz (talk) 14:30, 17 February 2023 (UTC)
 * I agree, but it's not just here. The entire Web seems to be going through a phase of ugly and stark being considered design statements. I do hope it passes quickly. 74.115.78.80 15:28, 21 January 2023 (UTC)
 * Absolutely agree. All the illustrations have been reduced to postage stamps. It looks fine on a phone, but is utterly unusable on a computer screen. The aesthetics have been trashed along with the functionality. The web is a visual experience and Wikipedia has just died... 2001:8003:D40E:7E00:ACDF:D45C:10E0:7BF4 17:06, 21 January 2023 (UTC)
 * Agree. Some websites tend to change themselves radically (e.h. IMDb) when old version is working just fine. Gevorg89 (talk) 17:29, 21 January 2023 (UTC)
 * I agree, the new-look looks extremely unorganized, but at least you can switch back to the old one... Telltemmne (talk) 18:54, 21 January 2023 (UTC)
 * Certainly, the new layout looks utterly dreadful, good thing we can change back to either vector legacy or monobook. Interlacing (talk) 20:02, 21 January 2023 (UTC)
 * Agree. Clear-cut downgrade. Forresthopkinsa (talk) 21:12, 21 January 2023 (UTC)
 * I've been using Wikipedia since day 1 and I had to create my first account today just so I can change the layout to the old format. What a HORRIBLE redesign.  It's looks like garbage on a widescreen laptop monitor.  Why is there so much white space on the left side?  Is wikipedia for Zoomers on iPhones now, like TikTok or some other garbage?  This is the worst website redesign I've ever seen, including that one that Digg did like 12 years ago that made literally everyone leave the site for Reddit.  Just BAD BAD BAD. 76.104.139.237 21:31, 21 January 2023 (UTC)
 * so fucking true man 71.226.203.33 23:41, 30 January 2023 (UTC)
 * It is nothing but worse. Jacob Agar (talk) 21:33, 21 January 2023 (UTC)
 * I actually came here to say the same thing; the new UI isn't just ugly, but it's genuinely painful to use on desktop, to the point of being borderline-unusable. It was clearly designed with mobile users in mind, despite the fact that, afaik, the overwhelming majority of editors prefer desktop; I say this as someone who does mobile edits from time to time. I don't want to have to log in every time I use Wikipedia just so I can even navigate a page! Change it back! Birdn4t0r (talk) 22:02, 21 January 2023 (UTC)
 * You can get the mobile UI on desktop already with .m in the url. I just switched from the mobile view that had opened up by accident to desktop view and I think the layout is even worse on desktop than the actual Mobile UI. This style is not ready for prime time and should in no way have become the default.
 * The UI getting old and stale is worse than being actively bad.
 * Shadowmaster13 (talk) 08:26, 25 January 2023 (UTC)
 * Count me in on that one: Huge waste of screen real estate, on my 1920 pixel width screen only half is used by content and it would not be more if resize the browser window to full screen. The article-outline was separated from the article, no visible connection between article and pictures/graphics, way too light UI overall, languag switcher anywhere and search-field moved anywhere else.
 * Seems like it was designed to fuck up and bug out the user. No real user experience while designing this was in mind i think. 2A02:8109:9D40:1F1C:E475:3EC8:7B5E:28CE 23:34, 21 January 2023 (UTC)
 * I made an account with wikipedia just to switch it back. It's not so much the design is horrible, but it looks exactly like the mobile layout and I don't use the mobile layout for a reason. I don't entirely unsupport the idea of re-optimizing Wikipedia for modern UI (not that I wouldn't switch it back anyways lol) but doing it in a way that just feels like copying the mobile format is so weird. 47.146.190.208 02:16, 22 January 2023 (UTC)
 * While I disapprove of the profane language used in this comment, I have to echo the sentiment. The amount of white space in the new layout is so jarring it makes articles absolutely dreadful to read on a desktop display. Does Wikipedia even care about how resoundingly negative the feedback to this new design has been? 2600:6C44:747F:98D5:E9C9:BDC3:1868:6F99 03:30, 22 January 2023 (UTC)
 * Uninspired redesign, neither better looking or more functional, so I have no idea what was the intention of whoever came up with this. There is no way someone beta tested this because it would not have gone live.
 * I have no idea why someone thought the interface needs a change in the first place since it was optimized for a dictionary, but on top of that, it made no sense to take away the access to international versions and Wikimedia on the side which represent additional references. It would make more sense to make the old one default and offer the new one as option. 2600:1700:20C1:4920:B8D9:705C:D86C:BF8F 04:31, 22 January 2023 (UTC)
 * I'm mostly reply just to increase the number of replies so they see we don't like this; while the profanity is unnecessary I wholeheartedly agree that desktop websites should have desktop layouts and mobile layouts should stay on mobile. The same complaints were made when Windows 8 came out and when Facebook did it I stopped browsing their website on desktop entirely.  At the very least you can change it back in the preferences menu (although that's only available to those of us who've made accounts), unlike Facebook and the new Steam Library (which is not that new anymore). Jacob p12 (talk) 05:49, 22 January 2023 (UTC)
 * Completely agree. Vector 2022 sucks due to clearly very little thought being put into it. Excelsiorsbanjo (talk) 05:51, 22 January 2023 (UTC)
 * I literally went to the step of creating an account just so I could complain about (and hopefully get rid of) the horrific new UI. I've seen better web design in simple html pages from the 90s. --118.149.76.228 10:27, 22 January 2023 (UTC)
 * My main issue with it was that the text was not wide enough and it was harder to read. Glad there's a button at the bottom to make the width fluid. 5.15.71.147 12:06, 22 January 2023 (UTC)
 * This mostly fixed it for me, thanks for that!
 * While I'm here, my suggestion is for a border to be added to the edges of the container. The white blends into the grey too easily and it is a bit disorientating. The border helps the user find the edge of the page/container, and it also has the benefit of looking more authoritative. Moissanite (talk) 19:59, 8 February 2023 (UTC)
 * You're totally right. I also had to make an account to select the proper UI. This is clearly some change pushed by some kid who thinks JavaScript frameworks are the best just because some marketing move told him so. Maybe some company author of the framework donated money to Wikipedia to make this change. Otherwise it makes no sense and it just makes Wikipedia worse. Microph123 (talk) 12:45, 22 January 2023 (UTC)
 * Maybe the real purpose of the change was to get us all to make accounts.... 66.214.69.101 01:46, 26 January 2023 (UTC)
 * Thıs is absolutely true, there was no need for a resign as the older one was perfectly fine and the blank white space in the sides is horrid and a waste of space. Klad 2 (talk) 13:28, 22 January 2023 (UTC)
 * The new layout sucks so bad. While I think that the old layout looked kinda ugly, I definitely prefer the old one, because it's much easier to read with the old layout. Old is gold, especially on Wikipedia 109.247.106.208 13:45, 22 January 2023 (UTC)
 * I think maybe if they added a dark mode it wouldn't suck as much though. 109.247.106.208 13:47, 22 January 2023 (UTC)
 * At least it helped for user count, I had to create an account to revert to the old appearance. 2A02:AA13:7200:8A80:B8E5:F3A9:623C:352D 17:54, 22 January 2023 (UTC)
 * Can't agree more. I don't know if it was their intention to confuse people at first, and then force them to make an account to switch back from the horrible redesign, a la Reddit style. Terrible decision. 62.167.140.205 18:40, 22 January 2023 (UTC)
 * this is what i came here to say! the only reason i created my user account is so i could revert to the old design! the new one makes me want to vomit. Jakeyounglol (talk) 23:31, 22 January 2023 (UTC)
 * I can only agree. The new design is pretty much a compilation of every awful UI design from the past decade.  It's genuinely awful and makes the experience actively worse.  It really, really, really needs to be rolled back.  And I'm hoping WMF isn't going to dig in their heels about this.  Because the old design is flat out superior. 2600:1700:1471:2550:2195:BD59:6E8E:AB0C 01:29, 23 January 2023 (UTC)
 * Couldn't agree more, the new look is atrocious and an unbelievable waste of space. This is a perfect example of attempting to fix something that isn't broken. ElaenaS (talk) 01:47, 23 January 2023 (UTC)
 * I've been trying to give Vector 2022 a chance over the last few days, and what I really don't like so far is how dead it feels. Like, this lack of visible page organization, as you pointed out, makes it very dull. All this white without much contrast actually makes my eyes uneasy. That is my experience so far. RoadTrain (talk) 02:37, 23 January 2023 (UTC)
 * I too am chiming in to say I made an account for the first time in 30 years of using wikipedia to revert to the old format. The new vector is atrocious to look at and makes reading a chore. The old layout was engaging and helped you intake information. Thats part of the reason people could get lost in wikipedia it was so easy to read. 2603:8080:A704:5A81:A800:FCEE:7F61:1D8F 10:19, 23 January 2023 (UTC)
 * I created an account just to voice my distaste for the new layout. WHY is the width limited??? I get that to some it may be easier to read, but for me, with a 27" screen, I now have to scroll quite bit to read the same content. I MUCH rather read longer lines than be forced to scroll every couple seconds.
 * The previous design was clean and compact. Some may say cluttered, but really everything was at your fingertips and super convenient.. Like an airplane. The new design hides things behind annoying menus, and the TOC being hid behind toggles is REALLY DUMB. Now I can't see the outline of a page without guessing and randomly clicking on toggles?? WTF?! The new design also wastes ~2/3rds of horizontal space on a 27" monitor which looks really goofy. It feels so sterile, and like a clone of other wastelands of the modern web. Ugh. Frustrating. At least with an account, now I can revert the look. Jammnrose (talk) 17:56, 23 January 2023 (UTC)
 * Adding my voice to those who had to create an account just to go back to the old layout. The new one is just awful. Hargan2 (talk) 22:48, 23 January 2023 (UTC)
 * Ive always donated to wiki since i graduated college. I will never give them a cent ever again. Same thing with mozilla and mdn. Its like they used the same brain dead designer Randt1234 (talk) 23:39, 23 January 2023 (UTC)
 * I don't normally comment on talk pages, but good god is this new UI design the most useless one I've ever seen. Nobody asked you to hide everything behind unintuitive buttons, it was working just fine before you fiddled with it. Hobtan (talk) 23:49, 23 January 2023 (UTC)
 * Have to agree that this new redesign looks very bad. Please revert it!! 83.254.212.105 23:53, 23 January 2023 (UTC)
 * This is garbage.. I can't resize the content in a widescreen monitor to get full viewing width. Who thinks this is actually more usable ? Psiberfunk (talk) 03:21, 24 January 2023 (UTC)
 * I'm chiming in as a UX designer–this is shameful and I'm so very tired of "new" UI improvements just turning out to be hiding functionality behind toggle screens. Enuui (talk) 06:11, 24 January 2023 (UTC)
 * I've used the new layout for two weeks. I'm switching back to the old look because it displays the article in a wider column for reading and editing, because it doesn't have a right-nav bar for Tools that I have to hide, and because it uses gray backgrounds to guide my eyes. PRRfan (talk) 16:52, 24 January 2023 (UTC)
 * Couldn't agree more. HATE the new layout. There is so much white space it almost makes me sick. I don't know how web developers get the idea that they know better than I do about what size I want my window to be. I set it to a given size, some smart a**e developer sets 5" borders other content! How arrogant is that. If I wanted it that size I could easily do so. Guess what, I didn't. IanKennedy1965 (talk) 17:08, 24 January 2023 (UTC)
 * Agreed. New format is harder to navigate, particularly on the desktop. Many articles are actively more difficult to read, between the increased white space on the page and the way the text boxes have been 'streamlined'. Not sure if anyone in authority at Wikipedia is reading these comments, but you really dropped the ball on this redesign. 128.164.30.116 19:01, 24 January 2023 (UTC)
 * If I want to read on my phone, I grab my phone. Why do developers everywhere think that a desktop website should look like a phone website. This new appearance may disappear.
 * Why must everything always be hidden for an empty appearance?
 * More search and click work for the same result. Like logging in. To create an account one click. To log in two clicks. Willem ter Haar (talk) 21:12, 24 January 2023 (UTC)
 * The new UI looks awful. It's so bad it made me come here to let my voice be heard. Please change it back to the previous version while you come up with something better ☹ 71.208.54.176 22:56, 24 January 2023 (UTC)
 * Like many, I have created an account to switch back to the old style. Maybe this was the idea? The new design is woeful. What's the point of having a large monitor if you put all the text in a ribbon down the middle, with huge amounts of white space on each side. Horrible. 81.107.32.77 23:16, 24 January 2023 (UTC)
 * I agree. I thought the site was broken at first, then came to find out that this was done on purpose.
 * If nothing else, it pushed me to figure out how discussion pages work. But I'm deeply not in favor.
 * I'm not sure where all of the content on the left side of the page went. Is there a migration tutorial? 2600:1700:EB0:3790:D07F:D785:80DD:AC07 01:28, 25 January 2023 (UTC)
 * I thought i was on the mobile version then found out this was actually a new layout. This is just all around dumb. DarmaniLink (talk) 08:56, 25 January 2023 (UTC)
 * I will stop donations immediately if this is NOT changed back to default. The new "theme" is total shit and I will have NONE of it. This is not the reason I donate money to Wikipedia. Whoever made this decision should have been ousted yesterday. Revert it back to the previous DEFAULT and MAKE people choose the crappy 2022 (genX-edition) if they feel compelled. Newlayoutsucksass (talk) 10:58, 25 January 2023 (UTC)
 * I agree. As one may guess, I made an account just to be able too change the look. Please don't make non registered users suffer, they're people too! WikiP&#39;sNew2023UIisTRASH (talk) 20:20, 25 January 2023 (UTC)
 * While you’re welcome to voice your opinions/feedback about wiki functions, please do not take it into account usernames. Tropicalkitty (talk) 20:33, 25 January 2023 (UTC)
 * Had to make an account just to go back to the old design where the content isn't squished into a tiny section just to make room for whitespace 108.31.241.8 20:26, 25 January 2023 (UTC)
 * I completely agree!! I thought that the CSS template was not loading properly to start with, then that facepalm moment.
 * I am surprised because they think MOBILE MODE is a must, that there wasn't a forced DARK MODE as well.
 * Even the Skin Appearance Preferences does NOT SAVE EITHER, Seriously WTF Shealladh (talk) 10:47, 26 January 2023 (UTC)
 * totally agree, horrible UI, but fortunately you can change it in preferences, what i encourage you to do, then they will know in theirs A/B testing that users actually really prefer old layout. 176.221.123.255 12:10, 26 January 2023 (UTC)
 * I agree that the new design isn't ideal. I am most frustrated by the large borders/sidebars on the sides of desktop monitors. Why squish all content into the middle of the screen and leave these massive blank rectangles on the side? Less information on the screen at a given time = bad, in my opinion. That is my main gripe... I like the idea of a sticky table of contents, but I am too jarred by the sudden change in page size relative to monitor resolution/aspect ratio. Donlad26 (talk) 15:50, 26 January 2023 (UTC)
 * I too can only agree. The MASSIVE amount of whitespace introduced is a complete backwards step that I cannot believe passed to the end. 2A01:4B00:8786:D00:9CCA:920:18FE:893D 19:40, 26 January 2023 (UTC)
 * I was using the "?useskin=vector?useskin=vector" thing to force the old design, but that stopped working it seems. So here I am, a glorious, new registered user.  My username conveys my feelings on the matter. Yournewdesignsuuuucks (talk) 19:41, 26 January 2023 (UTC)
 * 100% agree. At first I thought I'd accidentelly opened the mobile version, but then to my shock realised that someone at Wikipedia apparently thought it was a good idea to make this the design of the main version of Wikipedia. This should be reverted asap and the person who greenlit this should be fired. Luckily there is an option to switch back to the previous design, but the user experience should be good out of the box without having to manually change some settings first. -- Cyberhopser (talk) 18:35, 27 January 2023 (UTC)
 * Oh wow what a worseification.... i hope next time they beg you for donation they receive at most only 1/4 of the usual, clearly they have to much money to waste.
 * - Language selection, much more inefficient
 * - New right side menu distracting from the article
 * - Horrible, completley unusable new TOC
 * - Switching from a design usable at all resolutions (usually i even preferred it on mobile, as i didn't like the castrated mobile version aswell) to a fixed width is a massive step backwards too. (As others noted already: lots of wasted space) BorisSapulu (talk) 18:39, 27 January 2023 (UTC)
 * It is quite awful, and I created an account to revert to the old layout. 198.102.103.103 01:25, 28 January 2023 (UTC)
 * echoing here the new ui is eye bleed inducing i feel as if i will get a headache looking at it for too long. the cramped appearence makes reading anything a chore and makes things ugly with the spacing what is with that planing to add huge banner ads? the only reason i made an account was to revert this change will likely cause some people to leave if its not fixed this should be an optional theme not the defult your going to have infogalactic eatting your lunch. change for the sake of change is never good, if you need your ui design team to earn their keep then have them work on optional skins for the end user to select. the mobilefication of the net needs to stop theres a reason .m exists use it. Bobboter (talk) 05:13, 28 January 2023 (UTC)
 * I made an account specifically to save my preferences regarding the appearance. I'd rather check wikipedia on my phone than go through the 2022 layout. Awful. VangyTuft (talk) 08:24, 28 January 2023 (UTC)
 * I do agree with you - like I agree 100% with everything you said - but you can change back to the original layout, so I'm not too upset. I don't really see them taking away the legacy layout either. 2604:3D09:A977:3600:5DEE:6E28:6C0:7871 11:14, 29 January 2023 (UTC)
 * Yep. I actually registered on Wikipedia just to have the preferences option to switch to the old layout. It's just amazing how bad the new one is. Yegork1978 (talk) 19:29, 29 January 2023 (UTC)
 * About the only 'positive' is a separate TOC, and even that is rather badly implemented. It should be the topmost left table, separated from other menus and options, aligned with the article. Vinner19 (talk) 21:35, 29 January 2023 (UTC)
 * I totally agree!! I can live with if design is not too nice-looking, but I hate when it's unpractical. And this new look is just too horrible to use. I often switch languages, sometime even those I don't talk or read, only now its impossible task to do it quickly with that stupid select box, if there are twenty languages. Moreover, I have to log in in each language to set old layout, that is so very annoying. I could write quite a list what else is useless, but I see others wrote it down already. BeaBeta (talk) 23:38, 29 January 2023 (UTC)
 * Yes. I do not understand the disregard for users screen space. I purchased a large monitor only to find that 'designers' throw away large parts of it's space. An wiki page is not there to look beautiful (not that you could call the new design beautiful! but at the end of the day I suppose that's a matter of taste.) It's form should start with and follow function; it's there first of all to provide information, and options at your fingertips. Both are reduced significantly.
 * I am very glad to be able to switch back! 2A02:A46A:A337:1:14E3:853E:3CB2:6782 09:02, 30 January 2023 (UTC)
 * The new layout is EXTREMELY inaccessible for people with disabilities in my opinion.
 * The text being all smashed together is harder to read, the white space is distracting, and the god awful hamburger menu requires extra movements and clicks to open. Everything is so unintuitive, frustrating, and makes my head hurt. I imagine people who need screen readers are having an even harder time than I am using this site. People shouldn't have to make an entire account just so they can use an educational website without suffering.
 * Wikipedia 1000% did not have people with disabilities in mind when working on this redesign and approving it, as seems the case with most websites who push for the atrocity that is "modern" web design. I wonder if Wikipedia realises they aren't required to follow the the trend of having an ugly website that's terrible to use.  Azethes (talk) 09:11, 30 January 2023 (UTC)
 * I think it depends on the person. I have disabilities and prefer the new layout. The previous desktop version looked to me like an overwhelming wall of text. Each line was so long that I couldn't keep track of what I was reading, and constantly moving my eyes from left to right across that wide field caused fatigue. Screen readers helped me maintain focus, but I would just opt to browse on my phone instead.  The new layout provides short, digestible lines of text, and the white space creates a cleaner, focused appearance. I do agree that modern web design sucks, but I find this revamp to be helpful. Otherwise, I would love to use MonoBook!
 * I'm sorry you're having a difficult time with the new layout. It looks like many people are in the same boat. I'm glad we are able to toggle between different layouts in order to figure out what works best for us. All I can say is that I'm thankful to have the new layout as an option. TheCowboyPirate (talk) 08:39, 1 March 2023 (UTC)
 * The only good thing about the redesign is the TOC sliding down with us on the left as we scroll the article. Everything else is bad. The one thing we could have used is a dark mode and we're being told it *was* technically impossible to do, has recently become possible, but won't be done regardless. I've never heard anything like it. 81.100.55.96 00:26, 31 January 2023 (UTC)
 * THANK YOU. It looks SO bad dude. This needs to be reverted ASAP. Thank god they at least made it easy to change back. Sleampy (talk) 23:30, 31 January 2023 (UTC)
 * Agree. Created a Wikimedia account today to change my theme preference, lol Jessveness (talk) 07:35, 2 February 2023 (UTC)
 * I am so glad I am not the only one that thinks the new layout is god awful! I thought I was going insane when I was google searching "new wikipedia layout" and all the top results were news articles with headlines like "Wikipedia gets its first makeover in over a decade… and it’s fairly subtle" (link). I was so happy when I found out that I could get rid of the layout by logging into my account. Sockbucketfrance (talk) 08:35, 2 February 2023 (UTC)
 * Definitely agree. New look is a piece of shit. Hire some UX designers! and think twice - it looks ugly on the huge PC screens! 213.210.175.85 12:05, 3 February 2023 (UTC)
 * Couldn't agree more. It is absolutely horrible. 213.160.161.52 21:56, 3 February 2023 (UTC)
 * I was trying to save my appearance preferences to one of the older themes, and it straight up will not apply. Every time I re-visit a wikipedia page it is set to vector 2022. Is there a fix for this? I've already cleared my cache/cookies. CapSAR (talk) 03:40, 5 February 2023 (UTC)
 * I agree! this needs to be revised back to the older verson by default. Webpages need to be functional, and not minimal. The new layout is not even optimized to view more text! Haldardhruv95 (talk) 05:57, 5 February 2023 (UTC)
 * i fully agree!
 * been using wikipedia for all my life and this new ui is a major shock, whos fucking idea was it to change it without a poll or something? Zekromisblack (talk) 00:56, 6 February 2023 (UTC)
 * I am more worried if it gets worse, like when they start introducing a fixed sticky nav toolbar in the next design (I thought they listened in 2020) and ram it in yer face constantly as you scroll the page where it is in the way and distraction.
 * I am totally against it. It should be down the user what they want to see constantly on their viewing and not a few people who think they want it stuck constantly against their wishes in the guise that it will help and the users are somewhat stupid and confused.
 * They will loose my donations once they do that on Wikipedia. MrMobodies (talk) 02:45, 14 February 2023 (UTC)
 * Agree, less intuitive, less effective real estate. Suggest making it optional, not default and seeing how many actually opt-in. Saucypuck (talk) 01:23, 8 February 2023 (UTC)
 * Have to agree, unfortunately. While I don't have a flickering issue, the layout is absolutely terrible and seems to combine the worst of a desktop and mobile layout in one. Please go back to the previous default and save us from the weirdness of wasted space combined with restricted element sizes. There's no reason to make such a change here - sometimes something is just good and you should leave well enough alone. P.S.: it's not "subtle". Wolfbeast (talk) 08:19, 9 February 2023 (UTC)
 * I agree! I made this account just to change to Vector legacy... I love you Wikipedia but this new layout has go to go! 178.55.41.49 10:04, 11 February 2023 (UTC)
 * I would also like to express my discontent with the new layout. Like many people here, I've made a wikipedia account just to go back to the old theme. 79.186.222.249 17:26, 11 February 2023 (UTC)
 * I'm a long time donator and small time contributor to wikipedia, and I add my voice to what appears to be hundreds of others concerning the layout change. It is incredibly cramped, counterintuitive and disorienting, and overall much worse than before. "Improvement" for the sake of improvement is a modern plague. Considering the overwhelmingly negative nature of the feedback I see here, why isn't this change reverted at once? Numero4 (talk) 06:49, 12 February 2023 (UTC)
 * I know, why is it under desktop "improvements" Higuys153 (talk) 04:52, 13 February 2023 (UTC)
 * I cannot claim to be an expert in editing Wiki pages, but as a retired academic I have a lifetime of reading journals in science. I'm now not too well and most of my Wikipedia-reading is done on a 15" laptop while sitting in a reciner chair.  I typically spend hours a day reading it.  I also take the trouble to donate for this :-)   I use Firefox and I have a large collection of bookmarks, which I normally keep visible on the LHS of the screen.  For a little  while I have noticed that the longer pages of Wikipedia have lost their valuable pale blue indexes, so useful because as you read parts of a page, the sections you have previously visited change colour.  Very recently I have discovered that if I close down my bookmarks view I see a sort of quasi contents list (with nothing of the precision of the old contents lists).  Also, there is stuff on the RHS that I hardly ever look at (was it ever there before?).
 * Today I have looked around and discovered this "skins" issue, and if the changes I am witnessing are anything to do with this, then I don't like it - AT ALL. The old American saying "If it ain't broke then don't fix it" comes to mind. I pretty much agree with all the above complaints and I think it's time Wikipedia did a "revert".  I note some commentators suggested that the new presentation should have been an option to opt into for a year or so; that would heve been much sounder treatment of us users.
 * At this point I have just gone to my desktop with its 24" screen an run up tabs showing the Vector 2022 and previous skins. To me it's no contest: lots of white space on the new skin, pleasant document-style layout on the old.  Anyway, as I now know how to view pages using the old skin, that's what I'll be doing. Bicyclic (talk) 16:51, 13 February 2023 (UTC)
 * I see a SPAMMY FIXED HEADER here but thanks to this extension (CAN'T BELIEVE I expressed my concerns in 2020 to grant user a choice that I am at the liberties of browser extension like this one:
 * Chrome: Sticky Header Hider aka Fixed Header Fixer
 * Firefox:StickDucky
 * This page looks nicer
 * "Currently, many functionalities on wiki pages are only available to users at the top of the page."
 * NO I DON'T WANT THAT.
 * Main page:
 * "This becomes problematic on longer pages, when scrolling past the first few paragraphs means the user would need to scroll back up to access the tools and other resources again." I'd rather do that than have something slapped in my face constantly. Dont under stand how annoying that is". RUBBISH! Put on the side panel then.
 * If ANYTHING IS problematic it is having fixed nav toolbars and widgets rammed into my faced constantly and follows down the page as I scroll away from them totally unwanted and undneed and they are still there in the way and as a distraction.
 * "Our proposed method of addressing this is to make the site header “sticky” This means it stays fixed to the top of the screen (above the content) as you scroll up or down the page."
 * No I DON'T WANT THAT. That is NOT HELPFUL THAT IS ANNOYING.
 * It wasn't a problem before LEAVE IT ALONE.
 * Absolutely no regard for the preferences from users.
 * The side panels was fine as long as I can hide it. But when you start slapping things that span the top the follow down the page, unable to hide it that maybe unwanted by the user as in in the way, that is what I class SPAMMY BEHAVIOUR. Reminds me of the browser toolbars that came installed with flash player and adbobe web installers and also the so called "free games" last decade.
 * The tools above I see in this form that seems GOOD enough until you take them away and put them on the spammy toolbar that gets hidden by the extension.
 * Developer: "The users are very stupid and confused and don't know what they are doing, they are naturally born with a very low IQ level and low abilities which means they can't navigate websites and can be very challenging for them so a fixed header will help people in that it is always there if they want it or not which means it is quicker and easier to get to... lets plaster it everywhere for their own good."
 * No I don't want it. I want it left alone.
 * So far so good on the exisiting wikipedia. I don't sign inI just read articles. As soon as I see a fixed nav/header/toolbar on Wikipedia you can forgot the donations.
 * I do not have difficulty using it, I do however have great difficult navigating a website with unwanted fixed things that are in the way of the contents and serve as a distraction. instead of flowing with the rest of the page. MrMobodies (talk) 02:20, 14 February 2023 (UTC)
 * The new look is awful, with far too much white space. Perhaps Wikipedia should provide users some simple control over the appearance. And perhaps browser makers could get together and incorporate some sort of "style" preference (eg. navigator.style="[compact|mobile|desktop|...]" then every web site could automatically provide multiple css choices accordingly. Unfortunately CSS has become grossly convoluted and overly complicated, as have the javascript intrusions. Really this whole UI mess needs a lot of cleaning up. 208.71.172.42 03:05, 14 February 2023 (UTC)
 * It looks like it was designed for mobile not desktop, absolutely terrible and unneeded change. I hope they're listening instead of burying their head in the sand until the criticism dies down then declaring it a success based on people giving up. Thenewdesignisterrible (talk) 07:15, 14 February 2023 (UTC)
 * Replying to concur, the new layout is terrible and highly inaccessible. The design is completely inappropriate for Wikipedia. Freedom4U (talk) 03:33, 16 February 2023 (UTC)
 * the new layout is terrible on desktop, *especially* for a multilingual user like me 2601:600:C980:2DA0:80BF:252A:BF4:8EBC 12:08, 18 February 2023 (UTC)
 * I agree, I hate everything about this new layout Muddiebuddie (talk) 04:09, 19 February 2023 (UTC)
 * Agreed. Had to switch back to Vector Legacy 2010 in Preference here:
 * https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-rendering Intrepid-NY (talk) 16:11, 21 February 2023 (UTC)
 * agreed. looks worse and harder to read 128.6.36.140 20:16, 27 February 2023 (UTC)
 * Agreed, Vector and in particular the left hand 'bookmark' or whatever it's called removes too much content. The previous version (2010) was much easier to read in my opinion. Can we improve without taking away too much of the content which the reader wants to read? Textualism (talk) 11:11, 28 February 2023 (UTC)
 * Agreed, I had to make an account just to get the old layout back.
 * For me the most annoying thing is that the language selector is hidden in the new version. As a multilingual user I usually read articles in all languages I can read to get the most of it. 88.115.148.22 07:18, 3 March 2023 (UTC)
 * The only reason I made an account was to revert it to previous layout and provide feedback on how much I HATE this new layout.
 * It reminds me of when someone sends you a mobile link on desktop and the .m.wikipedia in the URL causes it to look poorly formatted with a bunch of useless white space. RevertToLegacyLayout (talk) 08:21, 3 March 2023 (UTC)

Came here to say the new layout looks horrible. Whose idea was this? 69.245.61.93 17:32, 23 January 2023 (UTC)

Signed up just to agree how horrible the new layout is. I have a 2560x1440 display and the new design uses 1/3 of it. Why are we treating desktop sites like mobile sites. You HAVE a mobile site, mobile.wikipedia.org, use that for you vertical/skinny text display. Stop taking away my screen real estate, you are NOT fandom. Stop ruining your website experience. --Kinomora (talk) 21:30, 31 January 2023 (UTC)

It's growing on me. But there's always the option to stick with the old layout. I just got here by clicking through the "preferences" menu. PaulHammond (talk) 19:32, 23 January 2023 (UTC)

Vector 2022 must die.

Agreed, I made an account just because i read you can change the layout back to the original and when the survey asked what reason i had for creating my account today and since it didn't allow me the option of telling them to delete this new layout i'm posting it here

I agree, the new design sucks. The one function I use as a multilingual person - changing language - has for some reason been hidden behind a drop down gadget. "More prominent" my ass, it's much less usable now than simply clicking on the language on the left side. --2A00:5500:80E8:AB00:0:0:0:100 18:01, 24 January 2023 (UTC)


 * This was the key problem that drove me to log in and setup preferences. Frequently change languages. Used to be a consistent annual donor, but clearly they don't need the money if there's budget to waste on removing all the functionality out of a UI that wasn't broken. Everyone who signed off on this, the whole way up the management chain should tender their resignation immediately. Dvulrich (talk) 20:30, 25 January 2023 (UTC)
 * Fully agree with you! I don't get why websites that are LONG established and work perfectly fine feel the need to be..... *sigh* [record scratch, turns baseball around] HIP! With it! In with the crowd! Not like your parents! So don't frown! [end lame 90's nonsense that ad companies though was cool] They need to stop. They all need to stop. Pinkfluffyunicorns88 (talk) 03:29, 4 February 2023 (UTC)
 * It is more prominent. English is not my native language, but the majority of articles I read, are in English. Every now and then, I change between English, Norwegian, Danish, Swedish, and a few times in the past, even French. Heck, I've even looked at articles in German. I prefer the new drop-down in favour to the old list of languages. Now the languages are always in the same spot, there's no long list of text claiming attention when I don't need it, and most importantly: no more need for scrolling to change language. That was so annoying about the old design; having to scroll down.
 * And now that I'm here, I'd like to inform you that the old design was not perfectly functional. I've tried creating a dark mode skin on top of Vector, and that's a truly horrible experience. Technologically, the old Vector skin was terrible. And it was not built for the screens of today either.
 * I hope the redesign of Wikipedia can bring us a much easier experience for building custom skins. Imagine, a future with lots of skinning abilities. Where those that want thick borders get that, those that want no borders get that, you can freely change between light and dark modes without issues, etc. Andcraft (talk) 04:03, 26 February 2023 (UTC)

I concur: this 2022 as a default is a horrible waste of page space. 99.73.36.110 01:43, 25 January 2023 (UTC)


 * Same here. Not only doesn't it look like anything educational, it wastes space on any screen bigger than 8", and the stark whiteness leaves you lost in space. I switched back to the one with the book, that at least looks pretty. 92.200.175.206 20:36, 29 January 2023 (UTC)
 * The new layout of Wikipedia is horrible, we all know that at this point. But I noticed something entirely else. The English version of Wikipedia is downgraded with this Vector 2022 nonsense but the German and Russian Wikipedias use the superior old Vector 2010 layout. Yes this is true-you can check this right now if you don't believe me. I do not know Russian or German language, I was just clicking around to see what is going on with their layouts. So good for them and for English readers we get the bad user experience.
 * Why the team that works on this decided that the English readers and editors should be tortured with this new layout?! How and when the other non-english communities have negotiated to be spared and not suffer the Vector 2022 disaster??? They have their voice heard and opted out but we the English using community are second class citizens now? How the other communities managed to convince you and we fail when we say we do not like Vector 2022? 94.26.15.134 16:29, 30 January 2023 (UTC)
 * Agreed. This is a massive downgrade on anything but a small phone. Varixai (talk) 16:19, 13 February 2023 (UTC)

I'm making a wikipedia account just to get away from the waste of space.

Make an account? - Thank you, I didn't know about that. Vector legacy is really a more enjoyable experience. It's why people go to cinemas even though they can watch at home. What a difference. Changing the format for mobile is understandable but doesn't make sense for desktops.Preroll (talk) 16:21, 5 February 2023 (UTC)


 * Just another who thinks this 'new look' is nasty, harder to use, harder on the eyes, just plain annoying, effed up bs.  😨😡 Wikiwavy (talk) 17:24, 10 February 2023 (UTC)


 * This mess seriously undermines the credibility of Wikipedia -- as if Wikipedia didn't already have ENOUGH credibility problems.


 * The previous "skin" was clean, clear, matter-of-fact -- giving Wikipedia at least the appearance of being a no-nonsense reference -- and was far easier to use.


 * Where did the article's Table of Contents (ToC) go? It's no longer visible (unless you poke around and find the pop-up, which -- if it's a moderately long ToC -- scrolls off the screen, and is horribly awkward and frustrating to use.


 * I finally figured out I could undo the damage, at least when "I" view it, by making changes to the "Preferences" setting (I'm a Wikipedia "Veteran Editor," extensively certified computer professional, state-licensed educator in computers, and former award-winning web developer, so I should have been able to figure out a personal solution, but it was not obvious) -- and MOST ordinary (non-editor)  Wikipedia  visitors will have NO idea the option exists.


 * This screw-up is what happens when you let some amateur idiots make changes for the sake of change -- they'll "fix" what isn't broke, break it as a result, and then shout "Progress!"


 * Raises extremely serious questions about the leadership, governance and future of Wikipedia. Penlite (talk) 13:05, 12 February 2023 (UTC)
 * What do we have to do to get this eyesore reverted? It's honestly the worst change I've ever seen. Dyaluk08 (talk) 10:24, 26 February 2023 (UTC)


 * '''I finally figured out how to go back to the old look, or so I thought. Only works for the one page you are on. Surf to another page, ugly look is back. StyxinConn47 (talk) 18:05, 2 March 2023 (UTC)

Search Box
The worst aspect of this new front page is having to click to open the search box before you can use it. Apart from being a bleeding nuisance, if we assume that the vast majority of users need it when they join the site, consider the bandwidth involved in thousands of unnecessary clicks. 12:17, 12 February 2023 (UTC) — Preceding unsigned comment added by Chevin (User talk:Chevin • Special:Contributions/Chevin) 12:17, 12 February 2023 (UTC)


 * Hello @Chevin. The Search box is ready to type-in. Only when the window is under 1000px wide, the Search box is collapsed into a magnifying glass icon that need to be clicked to unfold. Zapipedia (WMF) (talk) 21:50, 19 February 2023 (UTC)
 * Thanks for that. Possibly my setup then whch saves me eyestrain User:Chevin 08:26, 20 February 2023 (UTC)

More TOC concerns
On pages with long headings (f.i. en:Wikipedia:Closure_requests), the new TOC is highly impractical. The headings are difficult to parse, sometimes cutting words in two. A lot of scrolling is also required to get an overview of what discussions to close. Will it be possible to go back to the old TOC on a per-page base? I can imagine a lot of non-article pages will have similar problems (including this one).

Less importantly, I noticed that the default is having only the top heading displayed. In some pages / articles there are very few top-level headings, and this would always require the reader to uncollapse. Can this be made more dynamic? Femke (talk) 18:09, 14 July 2022 (UTC)


 * Would it be possible (probably only on bigger screens) to use the empty white space on the right for tools (for logged-in editors), so that the TOC is less cramped? Solves two problems in one. Femke (talk) 17:00, 18 July 2022 (UTC)
 * Thank you for your question! That is actually one of the next steps we hope to take for the new skin.  More details are available on the page tools feature page.  In terms of the ToC, we actually estimate the length of the ToC and decide whether to open or close the subsections based on that.  For pages with shorter ToC's, all subsections should be open by default.   OVasileva (WMF) (talk) 11:51, 23 August 2022 (UTC)
 * I liked Wikipedia when you didn't need to create an account to read it. Now either you create an account or you can't read it properly.
 * This change is BS and I don't care how cool your JS framework is, nobody likes this and you shouldn't force your frontend bootcamp brands on us. Microph123 (talk) 12:48, 22 January 2023 (UTC)
 * @Femke thanks for your comments. We worked with the Editing team to determine whether or not to use the updated, sidebar table of contents on talk pages. You can see that discussion here: https://phabricator.wikimedia.org/T294784. While there are some drawbacks, particularly long section titles wrapping (as you mentioned), there is also a large benefit of consistency between article pages and talk pages. Do you think that truncating the section titles in the table of contents, and making the full title available via a tooltip on hover would help with this situation at all?
 * [[File:Truncated_section_titles_in_table_of_contents,_with_tooltip_on_hover_(Vector_2022).png|thumb|Truncated section titles in table of contents, with tooltip on hover (Vector 2022)]]
 * cc @PPelberg (WMF) @NAyoub (WMF) (from the Editing team) who might have some other thoughts or ideas to add. AHollender (WMF) (talk) 17:55, 29 August 2022 (UTC)
 * I really like the page tools on the right. Invisible for readers (who can be converted to editors by the simple edit button), and by default visible to editors that want it. This also means I can collapse the other links on the left by default (assuming that script writers move their script links).
 * The current TOC I see on this page seems to have a smaller font size than previously, and (4 comments) in grey below. It's an improvement, but I still miss the overview of the numbers.
 * The initial link I mistyped (en:WP:Closure requests) at the moment only has the top-level heading (so it only shows requests for closure, so that seems to be a bug? Or can you only toggle between top-level / all level uncollapsed? On that same page, the end of the heading is often the most interesting, so I'm not sure that having truncated section titles will help much. You'd want a quick overview (similar to en:WP:ANI), to see what discussions you'd like to engage in. Femke (talk) 17:44, 31 August 2022 (UTC)
 * @OVasileva (WMF), @AHollender (WMF), @Femke: I've had a similar bad impression as Femke and other users about the new TOC. The new TOC is a mess. Please restore the old TOC and make the new TOC appear as a pop-up menu when the full TOC is off-screen. The full TOC should also be collapsed and numbered by default, as before. This would be a solution to all problems, and would also be aesthetically elegant, indeed. 37.160.249.144 10:29, 6 September 2022 (UTC)
 * @Femke thanks for these notes.
 * Regarding: "but I still miss the overview of the numbers" — can you expand on this thought? And to clarify, are you thinking just about Talk pages here, or Article pages as well?
 * Regarding the TOC on en:WP:Closure requests: the TOC is currently setup to automatically expand all sections if there are less than 20 sections & sub-sections within the page (e.g. en:Plant Stem). If there are more than 20 the top level sections get collapsed in the TOC, to allow for easier scanning of the TOC (e.g. en:Paris). In the case of en:WP:Closure requests there are more than 20 sections & sub-sections, and unfortunately they are all nested within one section. This is the least optimal page structure in terms of working well with the new TOC. Do you think it's reasonable to expect editors to eventually restructure certain pages to avoid this kind of situation where everything is nested within one (collapsed) section in the TOC?
 * AHollender (WMF) (talk) 15:43, 7 September 2022 (UTC)
 * Thanks for your response :)
 * I miss the numbering in the TOC most in pages that are long by necessity, to get an easy overview of how long the backlog is. So that's behind the scenes pages (en:WP:ANI, AN, CR, ..). I think I can get used to it in other places.
 * For the article talk pages, the TOC without numbers will probably work okay if there are less than ~12 discussions. (that is, if the plan is to break up the en:WP:sea of blue with n comments there too). And most article talk pages do not need to have more sections that that, so I hope there will be an increased tendency to set up archiving.
 * Would it be possible to collapse up to a lower level if there are say >20 overall and <4 top level? So for closure requests to have the 4 subsections show up, but not the subsubsections? Or, to set this per page, in a similar way as en:template:TOC limit? Restructuring CR in particular isn't trivial given that the archiving bot will have to be rewritten, and I have no idea how easy that is. Femke (talk) 17:13, 7 September 2022 (UTC)
 * Another example is en:WP:FAC, where the default top-level doesn't really make sense (four headings), and you'd want to show the first two levels of headings by default. The third level headings aren't too relevant either. The current TOC only gives you the option of too much or too little information. Femke (talk) 14:07, 11 September 2022 (UTC)
 * Hey @Femke, ok so on a high level I'm understanding your request as something like: certain administrative Wiki pages (e.g. ANI, Closure requests, FAC, etc.) would benefit from more fine tuned configuration regarding which level of sections in the table of contents are expanded/collapsed by default. While it is possible to restructure the pages themselves (rather than reconfigure the table of contents), it is unclear how easy it would be to do this because the archiving bots would need to be updated. Let me know if that sounds right to you.
 * My next step is to bring this up with @OVasileva (WMF) at our next meeting. I think it might also make sense to include @Jdlrobson in this discussion, as he might have more information regarding the effort involved to restructure those pages and update the archive bots. AHollender (WMF) (talk) 13:52, 14 September 2022 (UTC)
 * Mostly yes.
 * All of these pages are archived in slightly different ways, and I believe restructuring wouldn't interfere with archiving outside of closure requests. The other pages have less scope for restructuring I believe. For en:WP:FAC, the solution could lie in making the TOC responsive again to the en:template:TOC limit, which does not seem to affect the new skin. Femke (talk) 18:16, 14 September 2022 (UTC)
 * If we were going for the most simple solution here: do you think offering an optional table of contents configuration where all sections and subsections are expanded by default would at least improve the situation for these pages somewhat? AHollender (WMF) (talk) 18:59, 14 September 2022 (UTC)
 * That would resolve my less important issue, yes.
 * Is is technically too difficult to unbreak the TOC limit template? Femke (talk) 19:06, 14 September 2022 (UTC)
 * @Femke that's a good question, I'm not sure what the answer is though. I met with @OVasileva (WMF) and she thinks we should be able to find a solution. I've just opened this phabricator task: https://phabricator.wikimedia.org/T317818. Let's move the discussion over there. AHollender (WMF) (talk) 21:52, 14 September 2022 (UTC)


 * TOC depth does not show enough, therby confusing say level 3=== and 4====. Made me loose TOC overview. (this for the record, will look for similar posts). -DePiep (talk) 15:00, 1 December 2022 (UTC)
 * Hey @DePiep I think I understand what you mean. Can you provide a link (or several) to and article where this issue is present, just to make sure I'm properly understand what you're describing? AHollender (WMF) (talk) 17:12, 6 December 2022 (UTC)
 * See File:WP_vector_2022_Menu_indenting,_illustration.png, on purpose annotated screenshot. From en:Hydrogen. Actually, first met the issue in a talkpage, en:Talk:Periodic_table, where indenting can be more .. chaotic.
 * Description: The examples have up to level h4 (====), old numbering "1.2.3" then. Now, the TOC captions are indented all right, but to my eye not distinguishing (easily): it requires a second look, not by glancing. Confusion added by longer section titles.
 * Opinion: Personally I support the 'sticky' idea to the max: TOC overview from every page position, yeah. I'd gladly offer some bodyspace-width for this informative TOC in LH margin. Consistently: button 'unfold/fold _all_ levels' expected. Same for page menu ("What links here"-list) btw. All this about desktop view and from heavy Editor not Reader. DePiep (talk) 09:25, 7 December 2022 (UTC)
 * @DePiep some more conversation about this over here: https://phabricator.wikimedia.org/T307316#8448770 AHollender (WMF) (talk) 21:02, 13 December 2022 (UTC)

Start of redirect targets hidden by top horizontal bar
See, e.g., en:WP:RELATED: the first line of text visible reads "intended to link to topics that are simply...". In other skins, the first line of text visible is the section title: "Linking to articles that are related to the topic". Fgnievinski (talk) 03:00, 14 September 2022 (UTC)


 * Hi @Fgnievinski, I unfortunately can't replicate - I checked on two browsers (Chrome and Firefox) and three widths (full, which is 2,5k px, ~1000 px, and ~400 px, and every time, the section title is the first line of visible text for me. What browser and display resolution do you use? Do you use any additional browser zoom? SGrabarczuk (WMF) (talk) 14:44, 14 September 2022 (UTC)
 * here's a screenshot: https://pasteboard.co/v1lMc2Q1Hjn9.png
 * my screen resolution is 1280x720 and zoom level is 100%.
 * I'm using Chrome in incognito mode to avoid add-ons.
 * the problem only appears after I login into Wikipedia.
 * Here are some of my preferences:
 * - Skin: Vector (2022)
 * - Skin preferences: Enable responsive mode (Adapt layout to screen size on mobile.)
 * - Beta: New wikitext mode
 * Thanks for your support. Fgnievinski (talk) 19:18, 14 September 2022 (UTC)
 * I can replicate the Problem, though my first line is "Disambiguation...". I sometimes have the same Problem while using the new TOC. It seems to have something to do with the sticky Header. At first the Heading is visible for a blink of an eye, than the sticky Header pops up and the Text is blocked. HirnSpuk (talk) 07:10, 22 September 2022 (UTC)
 * @HirnSpuk, @Fgnievinski - could you tell me what browser version and device you were using? Thank you!  OVasileva (WMF) (talk) 22:37, 9 December 2022 (UTC)
 * I'm using Google Chrome on a PC running Windows 10. Fgnievinski (talk) 22:46, 9 December 2022 (UTC)
 * @OVasileva (WMF), I'm sorry, I don't remember anymore. Might have probably been Desktop-Firefox under Linux which I use mostly. I just tested in Win/Edge. The Problem is there. Standard Configuration, no zoom, middle font. Tested in Chrome, standard-configuration, problem is there. When clicking the given Link, the heading is there for a split second, than the "sticky-header" kicks in and moves over the heading. HirnSpuk (talk) 15:06, 15 December 2022 (UTC)
 * @OVasileva (WMF), I noticed some other weird behavior. When jumping to a specific Heading via special:permanentlink I'm not getting to the paragraph but somewhere below that. Might be related. Compare: b:de:Spezial:Permanentlink/1008062 or b:de:Spezial:Permanentlink/1003322
 * Regards --HirnSpuk (talk) 14:20, 4 January 2023 (UTC)
 * I am getting this too. Any time a redirect points to a section, the sticky header bar obscures the first line or two of text at the target page, so one has to scroll up to see if it is the right place (uncover the header). It looks like the page is opened at the right place, and then the sticky header is opened on top of it, covering the top text. This must be compensated somehow to correct for the reduced space at the top of the page for visible content but it is nor immediately obvious how it should be done. I am using Firefox latest version on windows 10 on desktop, and windows 11 on laptop. Effect seems to be consistent and repeatable. I notice that this effect does not occur when using the ToC, so it should be fixable by using a similar procedure. I would guess that for the ToC case, the content frame (whatever it is called), is already defined taking the presence of the sticky header frame into account, so the content is rendered after the header is already in place, so the top is not obscured.Pbsouthwood (talk) 05:52, 10 January 2023 (UTC)

This Problem seem to be still there! Does anyone know, if there's already a bug report? HirnSpuk (talk) 15:48, 17 February 2023 (UTC)


 * Confusing: I just tried a second time logged in, with full-width and hidden tools-menu, and it worked for once. Then I popped open the tools menu and switched back to narrow view... After that I logged out. Now it works in every case... Maybe I'll try again and will keep you posted in which configurations it works and in which it doesn't. HirnSpuk (talk) 16:01, 17 February 2023 (UTC)

Please revert to old skin on swwiki
Hi we discussed the changes during our admin conference for Swahili Wikipedia. We request you to kindly revert to the old skin for our wikipedia. We see that we would have to rewrite our help pages considerably and presently do not have the capacity. We tried to communicate this to user:SGrabarczuk (WMF) but he did not react so far. Kipala (talk) 07:50, 30 October 2022 (UTC)


 * Hey @Kipala, thanks for reaching out. We apologize for this inconvenience. Because it might be helpful to us as the developers of the skin: can you help us better understand why you would have to rewrite your help pages considerably? Is it because the main menu is now different? AHollender (WMF) (talk) 14:35, 31 October 2022 (UTC)
 * For clarity, we're talking to that community in a few different places; currently, I think, mainly via email. SGrabarczuk (WMF) (talk) 17:14, 9 November 2022 (UTC)
 * Hi AHollender, you are right. Our help pages (like basically all I have looked at) refer to the menue and positions of items on the screen. See e.G. here https://sw.wikipedia.org/wiki/Faili:Menyu_Wikipedia_Chanzo.jpg . For a small wikipedia with very few users who have ever worked on the help pages it means either a huge workload for which we presently have nobody - or having misleading help pages which definitely is not a good idea.. Kipala (talk) 17:24, 11 November 2022 (UTC)


 * We just had a vote on swahili wikipedia. See https://sw.wikipedia.org/wiki/Wikipedia:Jumuiya#Muonekano_mpya_wa_kurasa_zetu_-_kura! We had 13 participants (which is an excellent participation) and the vote was 13-0 for returning to the previous surface as default, until we are in a position to redo our help pages. So are you the right people here to effect this? Or do we have to talk to someone else? Kind regards Kipala (talk) 17:30, 11 November 2022 (UTC)


 * Dear people we notified SGrabarczuk (WMF) by Email on 10.11.2022 that we had done the vote in the swwiki community, we notified you here and until now nobody gave us a reply. Are you too busy or just impolite? Or are we too small and unimportant? Kind regards Kipala (talk) 12:35, 19 November 2022 (UTC)
 * Hello @Kipala. I'm sorry that you were waiting so long. I needed some time to consult with the members of our team.
 * Again, we understand and respect your care for help pages.
 * According to my knowledge, most of the discussion took place in a closed channel, accessible mainly or exclusively for admins of your wiki. We've only been able to talk to your group via proxy. We would much rather be able to communicate directly with the community to figure out how we can help. I believe we might set up a meeting in addition to an on-wiki discussion. SGrabarczuk (WMF) (talk) 02:48, 23 November 2022 (UTC)
 * Dear ones, I find this behaviour not acceptable. We did not discuss in some closed channel but we had an open debate and vote in our community. Openly: https://sw.wikipedia.org/wiki/Wikipedia:Jumuiya#Muonekano_mpya_wa_kurasa_zetu_-_kura! You were free to contribute. You guys do not dare to act like this vis a vis a large wikipedia like dewiki, Why do you think you can do this towards a small african language version??
 * So when do we see the revert, please?? Kipala (talk) 07:16, 11 December 2022 (UTC)
 * My apologies @Kipala, I was of the impression that the topic on wiki with all these votes was a direct consequence of a discussion previously taking place in a closed group. We'll talk to you on your wiki, then. SGrabarczuk (WMF) (talk) 22:16, 13 December 2022 (UTC)
 * @Kipala Do you have a list of help pages that would need to be updated? The file you mentioned shows only the 2010 wikitext editor, which is not changing. AntiCompositeNumber (talk) 04:18, 12 December 2022 (UTC)
 * Our help page are in the respective category. So would you guys kindly respect the open and inclusive decision of the community and asap revert the change you decided to do without obtaining consent? Kipala (talk) 11:36, 12 December 2022 (UTC)
 * Hi @Kipala - apologies that this is taking so long to resolve! Our concern with any type of revert here would be that we are in the process of switching the majority of Wikipedias to the new skin and the new experience.  Having some wikis stay on the old skin by default would add effort to the development team, and potentially confuse users on the wiki because of the switch.  Would it be possible for us to assist in some way to get the help pages ready and updated in a more prompt manner instead?  We'd also like to mention that we plan on making other various improvements to desktop in the future as well that are smaller and could affect existing documentation.  Our advice here would be to write any documentation or help pages without referring to a specific layout or interface.  Our software evolves and improves over time and it would be great to see documentation that is flexible enough to allow for this.   OVasileva (WMF) (talk) 20:24, 21 December 2022 (UTC)
 * Dear, the confusion is in place because you changed the skin without asking for approval from us. If you would kindly take a bit of time and look thru our help pages you will see that help pages must refer to the way items are arranged on the screen. if you do not write Swahili I do not see how you will help us. As you know German wikipedia took a vote to keep the "old" skin as default. And of course, because that is a large an influential community, you have not done anything without their approval. (I guess in enwiki the situation is similar). So if you can live with dewiki for the time being, I do not see any argument why you cannot live with swwiki and old skin default as well. So kindly just tell me what hinders you from reverting? (Except the fact that you do not like it and we are a small and unimportant wikipedia?) And kindly tell me since when community decisions can be just ignored? Kipala (talk) 22:24, 29 December 2022 (UTC)
 * Hi @Kipala -  Our sincere apologies for the delay in response here.  Our intention is not to ignore the consensus of the Swahili community.  We do believe the merits of the new skin for readers of Swahili and want to ensure that we are giving them the best possible experience.  We have discussed internally and have prepared a few options for moving forward.  We've written up these options for next steps and plan on sharing them with the Swahili community on the Swahili Wikipedia Village Pump as well as scheduling a meeting with the community where we can make a plan on moving forward together.  How does this sound?  Thank you and apologies again for the delayed response. OVasileva (WMF) (talk) 20:47, 16 January 2023 (UTC)
 * Since n't responding to this reply, understandably, I think the plan can move forward for now. Aaron Liu (talk) 21:24, 22 January 2023 (UTC)
 * Hi @Kipala and all! Just a quick update - we're currently translating our message for the Swahili Village pump into Swahili and hope to have it posted there by the end of the week.   OVasileva (WMF) (talk) 15:10, 26 January 2023 (UTC)
 * Don't you think that here, as in many other discussions related to Vector 2022, you interpret everything (even someone's silence) in a way that fits your own expectations? 83.30.229.13 19:14, 26 January 2023 (UTC)
 * No, why would you think that? Aaron Liu (talk) 19:33, 26 January 2023 (UTC)
 * "Our intention is not to ignore the consensus of the Swahili community." But we will ignore he consensus of the Swahili community. Well... 83.30.229.13 19:11, 26 January 2023 (UTC)

Hi ! Habari? Olga: how about just reverting the default and helping sw:wp update their help pages? The concern about having them change in lockstep seems thoughtful and probably what we should all be doing before making skin changes that change common workflows :) perhaps Swahili WP is just more keenly aware of the need for and use of those docs. Future skin updates you mention would hopefully not have so many changes at once.  Warmly, Sj (talk) 03:03, 20 January 2023 (UTC)


 * @Kipala Although I don't speak Swahili, I would like to assist with updating the help page screenshots (as I did for some on the English Wikipedia). Could you point me to where they are? You mentioned above https://sw.wikipedia.org/wiki/Faili:Menyu_Wikipedia_Chanzo.jpg but that is a feature which has not changed with Vector 2022.
 * As far as I can tell sw:Wikipedia:Mwongozo and its other tabs are the main help pages on Swahili Wikipedia, but using Google Translate that says "The guide has provided information specifically for those using the MonoBook page format. Since September 2010 the shape of the pages as seen by non-logged users is Vector. The guide has not yet been rewritten." and they have MonoBook screenshots. Surely those can't be what you're suddenly so concerned about? the wub "?!"  00:03, 26 January 2023 (UTC)

Jambo ! hongera! n-a-Kipala-penda, nakupenda. (kigiriki el.wiktionary, Central) Sarri.greek (talk) 04:11, 26 January 2023 (UTC)

Dark Mode
Make any theme with native Dark Mode. Time for filling everything around with any color, on condition that it is "white", has passed.

Seregadushka (talk) 21:45, 7 November 2022 (UTC)


 * someone had a decree of the Ministry of Health of the United Kingdom on reducing the brightness of monitors. I can't find the link. The savings were measured in hundreds of millions of F (reduction of electricity consumption, equipment resource, treatment of eye diseases, payment of sick leave, ...). It's time for Wiki to listen to this. Seregadushka (talk) 00:26, 8 November 2022 (UTC)
 * Native dark mode is necessary for global environmental friendliness and for a better experience.
 * It reduces power consumption when using OLED displays.
 * Also, white screens are very glaring when transitioning from other dark-mode enabled websites. (And the new theme is more "white"!) Futchitwo (talk) 17:29, 9 November 2022 (UTC)
 * @Seregadushka, @Futchitwo, thank you for your comments. I've just updated our answer about dark mode in the FAQ.
 * In short, we are not going to do that as part of this project. At the beginning of the project, we would even say that it's not possible. It has become technically possible recently, though, and someone at the Foundation could work on that.
 * Perhaps you would consider taking part in the Community Wishlist Survey and voting for dark mode? This is an easy way for editors to ask for a specific technical change. The period for making proposals will be in January, and voting would be around late January - early February. (See the Wishlist's FAQ to learn how to take part.) Thank you! SGrabarczuk (WMF) (talk) 22:55, 9 November 2022 (UTC)
 * I can't figure out how to participate in the survey. Where is the choice of questions ? 4 periods are specified, but there are no actual tasks of this survey. Prudently. On the topic -- now absolutely all operating systems of mobile phones and computers have "Dark Mode". Stop hanging around in the past, when there was nothing but a white Apple. If the design is only white? My eyes hurt from the work of your designers ! Seregadushka (talk) 03:27, 16 December 2022 (UTC)
 * Hey @Seregadushka. We also believe having the dark mode would help. As I wrote, this mode has only been made possible recently, as a consequence of this project. (The Survey hasn't started yet - the first phase will start in January.) SGrabarczuk (WMF) (talk) 16:11, 16 December 2022 (UTC)
 * And my eyes hurt when I try to read bright text on dark background. Also you seem to be (deliberately?) forgetting that even Apple I had white text against black background (as did Apple II and MS-DOS) - I'd say there's a reason we moved away from that. 2A02:A312:C539:8D80:78DE:760D:452F:23E2 19:58, 19 January 2023 (UTC)
 * Talk:Reading/Web/Desktop Improvements|I see you don't even mention these reasons, because there is no reasonable explanation for this. What you don't know how to do working with CSS styles is not the reason. The whole world is striving for green technologies. But you don't understand (intentionally?) that millions of monitors operating in the mode of maximum energy consumption disrupt the general movement of humanity to reduce the impact on the environment. Hire other programmers who understand CSS. Seregadushka (talk) 23:26, 19 January 2023 (UTC)
 * "At the beginning of the project, we would even say that it's not possible."
 * This is a completely false statement. From a programmer's point of view I can guarantee everything that such a change is extremely easy.  But on a LARGER NOTE -- the Wikipedia Android Mobile App has had dark mode for quite some time.  And the time is far overdue for the web interface to catch up and stop being both a drain on electricity and a strain on eyes. ClimbAll (talk) 09:34, 21 January 2023 (UTC)
 * I wouldn't call dark mode easy, or impossible. Somewhere in the middle. There are dozens of CSS elements you never think about or notice until dark mode messes them up.
 * I have been using Skin:Citizen for quite some time on my wiki with very few problems. It has an excellent dark mode that automatically engages when user browser preference is set.  I think WMF should make it available for logged in users. Flounder ceo (talk) 16:18, 31 January 2023 (UTC)
 * Hello from a fellow programmer. I have tried making a dark mode of the legacy Vector skin. It's horrible. You are very much wrong when you say that it is extremely easy. It seems like you have very little experience in this field. Building a system with both light and dark modes from scratch, isn't so bad. Wikipedia wasn't built for that, and the articles written since were styled for a bright interface.
 * I also use the mobile app, and in a dark style. I like it. But you can't escape from the fact that the mobile app was built almost from scratch, and that there's several visual problems with it.
 * The Wikipedia system wasn't constructed for this. It seems like the new one is enabling that. That's great. Andcraft (talk) 04:13, 26 February 2023 (UTC)
 * > At the beginning of the project, we would even say that it's not possible. It has become technically possible recently, though
 * This is an insane thing for you to have to say. If the redesign made darkmode impossible and it has only recently allowed for it for be done very difficultly, you should consider whether the redesign is any good at all. 81.100.55.96 00:15, 31 January 2023 (UTC)
 * Hello! Let me clarify, I meant this project has just recently made it possible to build the dark mode. Before that, with the previous skins and in the early stages of the project, it wasn't possible. SGrabarczuk (WMF) (talk) 02:01, 28 February 2023 (UTC)
 * I am astounded that after such a large update to the UI, native dark mode for desktop is still not a feature. Frosck (talk) 23:31, 21 January 2023 (UTC)
 * In fact, I made a naïve assumption that a native dark mode would be a part and parcel of the new UI— calling it "not possible" is laughable at best TheLucifer0509 (talk) 04:20, 22 January 2023 (UTC)

There are several dozen applications for Windows browsers, that have the conditional name "Dark Mode". One change the display for ANY site. And they are practically not mistaken. I.e. they have a universal mechanism of operation for all Internet sites. And you can't make a "Dark Mode" specifically for Wikipedia, when you don't have to guess, all the properties are known. Almost always people make decisions (and answer questions and suggestions) who understand little in questions asked. I'm not a programmer, I haven't sold a single website, I'm not paid to know CSS, it's a hobby for me. As the programmer ClimbAll (talk) has already said, this is extremely easy to do:

And that 's all ! Currently, the whole Wikipedia works on the same CSS style, only the properties are swapped (even if you use PHP, it won't be much more difficult). You only need to provide switching  and Of course, you can choose different colors for texts of different purposes, different degrees of "grayness" of the background of the pages. But these are conventions. I assure you, the entire amount of work will not go beyond 10 KB :) Seregadushka (talk) 17:36, 24 January 2023 (UTC)


 * For users interested in Dark mode who have not yet participated in the related discussion of the Community Wishlist Survey 2023, you can do so here meta:Community_Wishlist_Survey_2023/Reading/Dark_mode. Patafisik (WMF) (talk) 11:07, 31 January 2023 (UTC)
 * Last year WMF removed dark mode from the wishlist. Flounder ceo (talk) 16:07, 31 January 2023 (UTC)


 * The Wikipedia App has already two different dark modes and a sepia one. On the desktop I always use the firefox add-on Dark Background and Light Text by Mikhail Khvoinitsky with the option "Stylesheet processor", but sadly not everything is displayed correct at Wikimedia-Projects. Links are all blue for example. Also it takes more cpu usage instead of loading a native darkmode site. --KleinerKorrektor (talk) 19:34, 18 February 2023 (UTC)

Long article blurry
Vector 2022: Long articles (for example Johann Sebastian Bach) show blurry (a little bit bold) fonts after scrolling to references. Mouse hover corrects artifacts to normal font. Grimes2 (talk) 21:11, 25 November 2022 (UTC)


 * Hi @Grimes2, thank you for the report. Can you verify if your problem is the same of this task? Patafisik (WMF) (talk) 12:27, 5 December 2022 (UTC)
 * Yes, same problem, here on English Wikipedia (logged in, Vector 2022), Opera 93.0.4585.37, Win 11. Grimes2 (talk) 12:42, 5 December 2022 (UTC)
 * TOC is the problem. How can I switch off buggy TOC in Vector 2022? Grimes2 (talk) 13:41, 21 December 2022 (UTC)
 * Unusable. Changed to Vector legacy (2010) Grimes2 (talk) 09:34, 7 January 2023 (UTC)
 * Please visit this page with instructions.--Patafisik (WMF) (talk) 17:35, 18 January 2023 (UTC)
 * Doesn't work. Still at Vector 2010. Grimes2 (talk) 18:15, 18 January 2023 (UTC)
 * Seems to be fixed today. --Grimes2 (talk) 22:29, 24 January 2023 (UTC)

Purge-by-clock disappears
In old and new vector, I can purge a page by clicking the clock, somewhere top-right. OK. In Vec2022, the clock is in the usermenu (top-right, dropdown). (1) It now is invisible by default (sort of undoes its usefulness, a read-only-but-often). (2) the clock disappears from that menu when page is scrolled down. E.g., when I am down somewhere in section #4 on a /testcases page, I can unfold the usermenu all right, but the clock is not there and so I cannot purge the page. Have to go to top of page for this.

I'd expect (1) the clock be more often in view (possiby in top-of-page only, agree), and (2) the clock/purgebutton to be in the dropdown menu for purging when scrolled down (sticky-in-the-menu?). BTW for me, the purge could be a distinct menu item just as well. DePiep (talk) 15:11, 1 December 2022 (UTC)


 * Hey, thanks for reporting this. There are a few different issues, I don't have all the answers yet, so I'll get back to you when I know more.
 * A quick direct to your last thought is that there are other gadgets adding the purge as menu items, for example MoreMenu. Another one is mentioned here: w:Wikipedia:Purge. SGrabarczuk (WMF) (talk) 13:50, 9 December 2022 (UTC)
 * I posted a feature request at the talk page for the clock gadget. Jonesey95 (talk) 01:46, 15 December 2022 (UTC)
 * I have seen this. With Vector 2022 the purge clock appears and disappears at random; it’s often not there (as in not even as a menu item), but sometimes it’s there.
 * One reason I don’t use Vector 2022 (there are other reasons...). Al12si (talk) 01:20, 10 February 2023 (UTC)


 * I don't see any clock in the dropdown usermenu at all, how does one switch it on? I wish we could have more control over the usermenu and what displays without dropdown TBH. Ain92 (talk) 10:42, 19 January 2023 (UTC)
 * re User:Ain92 In my preferences (at enwiki), I have chosen "Vector 2022), then in "Gadgets" I choose option Add a "Purge" option to the top of the page, which purges the page's cache". DePiep (talk) 18:13, 22 January 2023 (UTC) -DePiep (talk) 18:14, 22 January 2023 (UTC)

Please, add classic style
Could you please, please, add somewhere (visible) 'Classic style' or something? For logged or not logged people? Some of us wish to stay with the classic style. I cannot find it when I am not logged. Thank you for all your efforts, but we need Classic everywhere, in all wikimedia projects. Please? Please? Sarri.greek (talk) 23:28, 9 December 2022 (UTC)


 * @Sarri.greek: Have you checked Special:GlobalPreferences (select Vector instead of Vector 2022)? -- NGC 54  ( talk |  contribs ) 23:46, 9 December 2022 (UTC)


 * Thank you @NGC 54, I clicked some buttons there. But is this for unlogged people? I would like a visible button somewhere 'Classic' (not hidden in a menu). I presume that if I go to History, at previous versions, I can see the normal style. Sarri.greek (talk) 00:02, 10 December 2022 (UTC)
 * @Sarri.greek: No, it is not for unlogged people. -- NGC 54  ( talk |  contribs ) 00:06, 10 December 2022 (UTC)
 * Boooooo. 👎👎 172.58.174.193 18:44, 18 January 2023 (UTC)
 * And that, my friends, is the problem. I don't want to be logged in on my work computer but the new layout is SO LOATHLY (Yet Another Change Is a Downgrade But Try Telling the UX Wags That -- Gmail, my bank [all of them actually], imdb, reddit, digg and now, heaven help us all, wikipedia -- it's all at "Gnome3" levels of hateration, folks) that I'll probably make a fake-me login there just. for. this. one. reason. That can't have been your intention. I have a number of friends and relatives who are creating users just so they can have Their Wikipedia Back, with no intention of EVER being editors or authors.
 * Yes, this is a must-have feature for non-logged-in people. How strongly must we put it in order to succeed in bringing about this change. There's a tribe of UX mavens who need to be reminded that Change Is A Downgrade for your existing users, even the ones who don't log in.
 * cheers...ank Ansak (talk) 23:08, 5 February 2023 (UTC)
 * Hello @Sarri.greek. This is unfortunately not possible, the same way it's not possible for logged-out users to use Monobook instead of Vector legacy. You can read more in our FAQ (Why is the opt-out link not available for logged-out users?). SGrabarczuk (WMF) (talk) 21:43, 13 December 2022 (UTC)


 * Thank you @SGrabarczuk (WMF). Thankfully, all wiktionaries are in classic style except the French, which we avoid. For wikipedias, we may try to find equivalent projects. Sarri.greek (talk) 10:23, 14 December 2022 (UTC)
 * @SGrabarczuk (WMF), why not add a permanent global little banner line with
 * For Classic Style, log in and click Classic2010 here
 * Sarri.greek (talk) 11:51, 14 December 2022 (UTC)
 *  this 
 * i lurk every day becuase i dont have to put up with tracking bullshit this is a spit in the face  to longtime users that dont  simply want another stupid platform to login to 2601:644:9180:31B0:C177:B313:1C8D:2C7F 04:00, 21 January 2023 (UTC)
 * That's such a bullshit non-answer. Tons of sites have figured this out without any issue. It's 100% within the capability of the servers. 24.242.64.48 16:11, 19 January 2023 (UTC)
 * I agree, it shouldn't be that difficult to add a simple drop-down list with a selection of CSS styles and save a cookie with the choice. 2A02:A312:C539:8D80:78DE:760D:452F:23E2 20:15, 19 January 2023 (UTC)
 * I agree 100%, if Reddit can do it, and if switching to Monobook (objectively the best design) is even still possible for signed in accounts, that means that the layouts merely manipulate what data is available, not build every page from the ground up... so therefore could easily be deployed and used as people saw fit. You don't want that because people would be switching back to Monobook and your designs would be discredited as being an advancement (which they aren't) IF they can't, then I want the old Vector 2010 back since the new design is absolutely laughable. there's literally twice as much white space than text. (I have a big monitor) Ikaruseijin (talk) 00:42, 21 January 2023 (UTC)
 * Another annoyed Wikipedia user here; corporate policy at work is 'no personal accounts on corporate computers'. Any suggestions for reverting to a usable Wikipedia skin? 192.157.110.190 02:09, 20 January 2023 (UTC)
 * I am afraid this might drive people to find information elsewhere. I was already considering alternative sources for quick knowledge on organic chemistry, but luckily read that you could create an account and change the style back. I find the white-spaces and compact text-boxes with short lines an eyesore and very difficult to skim through, unfortunately. Mftp96 (talk) 19:29, 20 January 2023 (UTC)
 * Hello,, friend 192.157.110.190, take a look at the end of next section. I want there, and it is fun. Sarri.greek (talk) 20:04, 20 January 2023 (UTC)

Let the public decide
My opinion is this. The phsyiognomy of wikiprojects: style-structure-content is known to the public as its fundamental characteristic. If a radical change were to be introduced, it should first be monitored as a choice of the public. If the two thirds of the public show preference to a new style in a span of e.g. 5 years, then, and only then, it could be introduced as default. The technical aspect, especially for mobile phones, is a spearate issue. Sarri.greek (talk) 16:42, 14 December 2022 (UTC)


 * I strongly agree. People react much more positively if they get a choice like "Hey we have an exciting new Theme you might like better: click here to try and tell us what you think."
 * Instead of just changing the look of what is basically public utilities by now to a version that should have had more testing. This was handled poorly, IMHO.
 * --Real Joe Cool (talk) 00:20, 16 January 2023 (UTC)
 * Absolutely. If the developers think it's just going to be something like the introduction of Windows Vista—no, it is not. There is not a single thing that is preferable about this new version when compared to the old version. A timespan of 5 years is not exaggerated at all. I could even argue that it should be a decade instead, and instead of 2/3 it should be 3/4 in favour. Vector 2022 is just a bunch of random pointless modifications to the old UI, an ego booster for Wikipedia's design team. I don't even know how this ever got out of the think tank. 172.58.174.193 18:42, 18 January 2023 (UTC)
 * I had to dig up and use my long abandoned login just to get away from this new heinous design on all my browsers. This should be a choice at the top of the page at the very least. Yes, it should be possible for unlogged visitors via cookies. Fredirc (talk) 21:09, 18 January 2023 (UTC)
 * I had to create a user on wikimedia just to revert to the old design. The new design is terrible for desktop. I am not browsing on a phone so it should not look like I am. 50.53.69.99 21:12, 18 January 2023 (UTC)
 * I for one have made my contribution in the fight against this abominable UI on [this page](https://www.mediawiki.org/wiki/Talk:Reading/Web/Desktop_Improvements). These annoying, constantly moving, constantly taking space table of contents and the bar at the top, eating my screen space, will unirinically make me stop reading Wikipedia. Yes, my mental health is more important. And if I were an editor, I would lose all inspiration to keep editing if logged out users would see it this ugly and irritating.--Adûnâi (talk) 01:19, 19 January 2023 (UTC)
 * Well,, I will not exaggerate. The new style is elegant. Which, I presume, is why the French wikipedia and wiktionary have been using it for some time: très chic. It is a) habit and b) the lack of Contents, Languages, that hinders me from using it. Is consistency between wikiprojects a problem? Then, small changes could have been introduced bit by bit over the years. Of style, of practical issues. This 2023 change was too abrupt. I cannot see why so many wikipedias voted for it (Have the voted? or were they told?). No unlogged reader has the time to go to some preferences and start ticking things... For wikiprojects that vote yes, to make the new vector default, please add a visible link 'switch to clasicc look' Thank you all. Sarri.greek (talk) 03:03, 19 January 2023 (UTC)
 * Elegant? How so? The new design is clunky, awkward, hides tools and options, makes the dealing with the ToC a chore, switching languages more cumbersome... (the original full list of languages, on the left, was best. Why Wikipedia ever strayed from that, I will never understand ...and any claim, that the new design frees up space, can be countered by not only the point that the space the side-bar takes up, has never been a problem, but also with the fact that there still is a sidebar. It's just empty ...which is weird and unsettling)
 * It takes more time and effort, to do anything or get any information. Ones ability to get an overview of things, or to navigate, is clearly diminished. Functionality, practicality and efficiency is severely hampered. Not because it is an unfamiliar set-up, but because it is an inherently, objectively, and significantly, less functional/practical/efficient design. (and this is true of most "upgraded"/"updated"/"modern" website designs, from about the 2010's onward)
 * The new design makes the desktop design, closer to the mobile design ...but I have yet to see, any reasonable argument (or any argument whatsoever), for why that would be a good thing. Why one should make the desktop version, be closer to a design that has to be severely limited, by the severely limited abilities of mobiles (most notably, their minimal and extremely clumsy and imprecise touchscreens)--155.4.221.27 08:25, 19 January 2023 (UTC)
 * Of course, -155.4.221.27 functionality is terrible. Which is why this new Vector=default must be reversed. Currently we avoid all wikiprojects using it. Thank you.  Sarri.greek (talk) 08:41, 19 January 2023 (UTC)
 * I've "voted" by cancelling my donation. The new UI is awful and I don't want to support its development in any shape or form. iliaarpad 10:21, 19 January 2023 (UTC)
 * Same. Cannot believe there is no way to change for unlogged users. 2001:4898:80E8:2:FE3F:D790:8002:69A9 22:15, 19 January 2023 (UTC)
 * The French Wikipedia didn't choose the new design. We were forced into it as a testing ground. And no matter what we said, it stayed. DerpFox (talk) 20:54, 21 January 2023 (UTC)
 * I too am one of those who sole made an account to change back to the old layout and start complaining about the change. Looks BAD on desktop. And my most used feature, changing languagebetween those I'm familiar with, is hidden behind extra clicks now. Khyprus (talk) 11:39, 20 January 2023 (UTC)
 * i made an account after like a decade of constant reading and occasional editing just to avoid the new layout. its hideous. way too much whitespace. hoping it gets fully reverted soon. 66.189.54.146 03:23, 21 January 2023 (UTC)
 * Couldn't agree more. I made an account specifically to switch back to the old layout.
 * I would be surprised to learn that anyone in the design team is over 40. This screams "mobile generation" to me. It's like someone was hired to improve the layout and the best they could come up with to justify their job was to turn every user into a mobile user.
 * I have a wide screen monitor for a reason. Let me use it. Shittylayout (talk) 04:37, 21 January 2023 (UTC)
 * Highly agree that desktop layout is much better than phone layout, and ditto re not donating any more. 2user2

Is there a way, for unlogged people, to copypaste texts of wikipedias in a different .htm thing, -sorry, I know nothing about computers-, so that we will have a permanent viewing medium? Something like a 'style-converter' outside wikipedia? Could a programmer make a webpage with such a thing? Preferences are for editors with a username, not for readers. E.g. I have Edge, and cannot see Contents. Languages are somehwere on top. Also, I like to see the Classic style (that is why it is called 'classic', one does not change it) I have saved lots of lemmata from earlier stages of wikipedia because they are more concise, and they look fine. Sarri.greek (talk) 22:31, 19 January 2023 (UTC)


 * There are websites that provide a different frontend to Wikipedia, like Wikiwand. Just note that they are usually ad-supported products. Longbyte1 (talk) 22:48, 19 January 2023 (UTC)
 * Thank you ! Very good: I can see Contents there. They miss languages, like en el fr etc or αγγ ελλ γαλλ .. I like the 3 strata, a very wise approach of an encyclopaedia: basic (what is encyclic general knowledge), medium (a bit more for one interested) and expert (all details there)! This is a solution to the "curse of red shoes": lemmata that grow larger and larger; very difficult to read. Thank you indeed. Very good for older people like me. I don't install things, too scared to click changes! Thanks. Sarri.greek (talk) 04:47, 20 January 2023 (UTC)
 * Hello. Maybe this little trick can help you: simply add «?useskin=vector» to every requested URL. It works for non-logged users. 37.134.90.176 08:44, 23 January 2023 (UTC)
 * Thank you dear 37.134.90.176. I have a username, so I fixed Preferences and can read here too, in the widths and styles I choose. It is you we are worried about Sarri.greek (talk) 18:54, 23 January 2023 (UTC)
 * The trick 37.134.90.176 mentioned, works for non-logged-in IP users/readers. It is annoying to manually add that "?useskin=vector" to the end of every Wikipedia-URL, however ...but it's nice that one can at least do that. 155.4.221.27 03:00, 25 January 2023 (UTC)
 * I just used it to try out monobook, as well, to see what that is ...and man, that took me back. I'd say that "classic" vector was a slight improvement, in looks (mainly the changed font size), but no real change in functionality. The new vector, however... 155.4.221.27 03:08, 25 January 2023 (UTC)
 * That's a life-saver, thanks you! Here is the Google Chrome extension which does the same (analogous to the old.reddit redirect).--Adûnâi (talk) 20:54, 31 January 2023 (UTC)

2022 is BAD.


Does Vetor 2010 really that bad at something? Fits in the screen too god? Uses the space in a too rational way? Like "Eeh, it's too god; users don't deserv it; we gonna screw it" There is NOTHING to argue about. Just look at it:

What ARE thouse gaps?

You can add the language switch and the table of contents from the 2022 – they ARE pretty neat. And again – if you will, 2010 will be even MORE better than 2022. But does it really mean you have to cripple THE ENTIRE page design? I don't think so. Jiira (talk) 12:03, 14 December 2022 (UTC)


 * Thanks @Jiira for reaching out to us. I guess you added this comment soon after you saw the skin for the first time. Am I correct? Have you maybe had a chance to read our documentation about the white space and the goals for this project? SGrabarczuk (WMF) (talk) 18:29, 15 December 2022 (UTC)
 * Hi @SGrabarczuk (WMF) . I had the same initial white space concerns after checking out Vector 2022 on 16:9 desktop. New format may be better for mobile users, and unification of experience across platforms is admirable, but I will be sticking to 2010 as I am primarily a desktop user. Seldom on mobile, but does this change affect the (android) app (or other apps)?
 * Also, I (probably like Jiira) was brought to this page directly from my account preferences - can that link be updated? Preferences > Appearance > Vector (2022) > Discussion.
 * If you are here like me looking for further information, I suggest https://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Deployment_of_Vector_(2022)#Discussion
 * or
 * Reading/Web/Desktop Improvements
 * Thank you Grabarczuk. MC the MD (talk) 00:22, 14 January 2023 (UTC)
 * I completely agree with the first post here and just look at the screenshots. The new website needs a manual switch to make text fill the whole display width in 2023?! Is this a joke? A manual switch for something which is now automatic on all modern websites made in the last decade??? The switch is not even visible on low resolution displays and we have to zoom out the browser to even see the switch-did someone even test this thing?
 * The first thing that should be done right away is to make the text fill the whole display automatically without any need for user actions and it should work on all widescreen resolutions on modern displays. No one needs so much white space-a little is ok but not the current amount. The users without account are not given any choice-this sucks too. To me it looks we are forced as readers to make an account just to make the site usable. If we do not make an account we have no option to use the page layout we like, no one offers anything to avoid the weird new design. Very bad design overall, I will stop my reading sessions here if this is the only option, sorry but this goes way too much in the wrong direction. I even try to edit some small mistakes but now the motivation to even read will be severely killed. 94.26.15.134 14:18, 17 January 2023 (UTC)
 * Kudos. Absolutely describes my sentiment. I had to browse through dozens of proxy lists for hours just to find a free working residential proxy to comment here. As an avid wikipedia reader who uses a VPN and thus cannot register an account, this new change just handicapped at least 5% of all wikipedia users who must use VPNS in order to access the website because of their country. The new design is so ugly I can't even concentrate on reading anything here anymore. 172.58.174.193 18:37, 18 January 2023 (UTC)
 * New layout is horrible, we don't want to know why it seemed like a good idea if we are saying it is not. Full width please. 149.170.16.251 11:16, 19 January 2023 (UTC)
 * Genuinely awful. It's insane that you have to make an account now to access the old look. There are myriad solutions to that problem that could have been implemented. 24.242.64.48 15:53, 19 January 2023 (UTC)
 * delete? 2001:9E8:6700:2B00:FA32:C515:A23D:3E1D 18:17, 6 February 2023 (UTC)
 * Yeah this is pretty awful, I'm not sure what documentation you followed or corporate Feng Shui web design manual you guys read, but this sucks. I didn't buy a monitor that's 2560 pixels wide only for it to be filled with content that's 1000 pixels wide, if I wanted to read things vertically, I would use a vertical device aka my phone, where the Wikipedia mobile website works just fine. Not sure why you guys decided to mobile-ify a perfectly fine Desktop site, but it's bad, genuinely bad, and whoever made this decision surrounded by yes-men needs to be told that they screwed up and made a bad decision. 104.202.250.242 16:39, 19 January 2023 (UTC)
 * If anyone is interested in a phone UI, then press this
 * Wikipedia (phone)
 * and tell me if it looks better than 2022 or worse Pondekuda46 (talk) 16:57, 13 February 2023 (UTC)
 * I did read the "explanation," and the white space is still ridiculous. If someone has an issue with to many characters on a line, did you know that you can resize browser windows? So, the only thing you are achieving here is taking options away from users, as widening the window does not restore the the content to full screen width.
 * Also, the explanation as to why logged out users are not allowed to change the layout holds no water. Setting a cookie with the preference should be fairly straightforward. The only context where any of this makes sense is as an attempt to get users to create accounts so data can be harvested. 193.190.231.132 12:05, 20 January 2023 (UTC)
 * The documentation on why there's so much white space indicates it's better for comprehension but worse for scanning. Why does finding specific information not warrant any consideration? Much of it also indicates that it's a subjective prefrence. Why not assume people are using full screen or wide windows because that's their preference? There are so many options to make the screen smaller already. 38.64.242.125 23:41, 20 January 2023 (UTC)
 * The old design has a lot of wasted space too, just in different places. You just don't notice it because you're used to it:
 * https://files.catbox.moe/u2t44s.png
 * 2001:8B0:DFDC:12BC:759:79A4:937E:9CC8 20:49, 19 January 2023 (UTC)
 * That whitespace is mostly isolated to horizontal whitespace at the top of an article, whereas the new whitespace persists vertically over the entirety of the page.
 * It's like comparing a novel with large chapter headings to a novel with 4cm margins. 144.32.240.151 17:19, 26 January 2023 (UTC)
 * Forcing narrow new layout has no respect for different learning styles or preferences. Before people could get a narrower or wider view by simply resizing their browser window.  Now, for some reason you want to force half my screen to be blank because some other people like narrow lines?  Stop being one-size-fits all and instead be inclusive.  Go back to letting us choose our preferred width.

72.66.107.22 19:12, 19 January 2023 (UTC)


 * I would absolutely add that I'm in the users that have absolutely newly registered an account solely to get usable width of pages, visual differentiation between what is UI and what is article, and TOC on desktop again. Desktop wikipedia does not need to be a mobile browser. 63.227.213.235 20:03, 19 January 2023 (UTC)
 * Me too, made an account for the express purpose of reverting layout and complain about the new one. Its bad design and has hidden used features behind MORE CLICKS. Khyprus (talk) 11:44, 20 January 2023 (UTC)

Tools menu and language switcher feedback
I will use https://ro.wikipedia.org/wiki/Utilizator:NGC_54?vectorpagetools=1&uselang=en and https://ro.wikipedia.org/wiki/Fran%C8%9Ba?vectorpagetools=1&uselang=en as examples.


 * The tools in the "More" sections should be above tools in the "Tools" section.
 * The sister projects are missing.
 * I like the idea of adding the "Add interlanguage links" in the language switcher (T310259). The "Wikidata item" link could be moved there, too. Or maybe it cold be moved in the "In other projects" section.
 * "Upload file" and "Special pages" are not page-specific but are bundled with page-specific tools.
 * "Printable version" and "Download as PDF" are missing.
 * "User contributions", "Logs", "Block user", "Email this user", "Mute preferences" and "Change user groups" are user-specific, but they are bundled with page-specific tools.
 * T317898: The "move to sidebar" option should also be shown to unlogged users. This menu contains links interesting to readers, like "Cite this page", "Download as PDF", "Printable version", "Permanent link", "Page information" and the links to other projects.
 * There is no link to the page logs (https://ro.wikipedia.org/w/index.php?title=Special:Jurnal&page=Fran%C8%9Ba). This is not Vector 2022-specific, but Vector 2022 could fix this.

I propose the following order for pages that are not in the user space (like https://ro.wikipedia.org/wiki/Fran%C8%9Ba?vectorpagetools=1&uselang=en):
 * Actions
 * Move
 * Delete
 * Protect
 * General
 * Page logs
 * What links here
 * Related changes
 * Page information
 * Print, share, link
 * Permanent link
 * Cite this page
 * Download as PDF
 * Printable version
 * In other projects
 * (The list of pages)
 * Others
 * Special pages
 * Upload file

I propose the following order for pages that are in the user space (like https://ro.wikipedia.org/wiki/Utilizator:NGC_54?vectorpagetools=1&uselang=en or https://ro.wikipedia.org/wiki/Discu%C8%9Bie_Utilizator:NGC_54?vectorpagetools=1&uselang=en):
 * Actions
 * Move
 * Delete
 * Protect
 * General
 * Page logs
 * What links here
 * Related changes
 * Page information
 * User
 * "User contributions"
 * "User logs"
 * "Block user"
 * "Email this user"
 * "Mute preferences"
 * "User groups"
 * Print, share, link
 * Permanent link
 * Cite this page
 * Download as PDF
 * Printable version
 * In other projects
 * (The list of pages)
 * Others
 * Special pages
 * Upload file

P.S. Please fix the T322978 bug. The task was created on 13 November, and now is 14 December. It is annoying to meet it daily :(

P.P.S. See ro:Special:Contribs/79.115.125.90 and ro:Wikipedia:Cafenea (permalink) for some feedback regarding the limited width and the new TOC (by an anonymous reader). -- NGC 54  ( talk |  contribs ) 17:15, 14 December 2022 (UTC)


 * @NGC 54 thanks for this comment, it's very helpful. Regarding the missing items, those bugs will be fixed soon. Regarding the grouping and ordering of items in the menu, we've discussed enabling control of the page tools menu in a way similar to the main menu (which uses MediaWiki:Sidebar), which would allow individual wikis to customize the grouping and ordering. For now we are going to maintain the ordering and grouping that exists in Legacy Vector, but generally speaking we agree with you that there could be some improvements. AHollender (WMF) (talk) 14:30, 5 January 2023 (UTC)
 * And I would also like a link to Special:CentralAuth. I often use this feature, and I would like quick access to it. -- NGC 54  ( talk |  contribs ) 13:26, 23 January 2023 (UTC)

Contents missed out while printing
While printing a document, that is in Vector 2022 layout Contents list is missed out on the Print...It should be fixed. KCCian24 (talk) 08:03, 16 December 2022 (UTC)


 * I, again, second that! TOC is needed in Print, especially for wikibooks it's important. Regards, HirnSpuk (talk) 14:28, 4 January 2023 (UTC)


 * Hi thank you for your feedback; About printing or not the TOC you can read previous discussion and tasks here, here and here. I was discussing about this this morning at the Teahouse too.
 * Hi thank you for your feedback and for adding your comment on Phabricator. Actually the Web Team is especially focusing on discussions with the community of the English Wikipedia, but I agree with you, it will be useful to consider different needs of projects other than Wikipedia, like Wikibooks ones, so please remind us in few weeks if we forget it (but I hope not).--Patafisik (WMF) (talk) 16:32, 23 January 2023 (UTC)
 * Hi @Patafisik (WMF), what exactly would you like to be reminded of? Fun Fact: If the toc is "hidden" it is printed. How about just "triggering" the old-style toc via the magic word "toc"? I can understand, that's normally not necessary to have the printout, right-setup and limit option for wikipedia-articles. But except for wikibooks as my "home-wiki" I also think about community, talk and help pages. Regards HirnSpuk (talk) 18:37, 23 January 2023 (UTC)
 * @HirnSpuk Remember us about this issue for Wikibooks when the Team will be less busy with the English Wikipedia, but before the deployment on other projects to allow them to fix it if needed.
 * What do you means with "If the toc is 'hidden' it is printed"? That the preview is not showing the same layout that is printed? Can you detail me steps to reproduce, browser are you using, the link you are using to print, with an example of page, please? If it is a bug I can open a ticket on Phabricator, or you can do it too. Thank you Patafisik (WMF) (talk) 10:27, 24 January 2023 (UTC)
 * @Patafisik (WMF), thanks, I'll try to remember! Regarding the 'bug'(?): there's a little link in the toc to "hide" it at the Top-Heading. Then it's printed, though with a poor layout. If it's in the side-bar, it's not. Tested in Windows/Edge and Linux/Firefox. Although I wouldn't give it a high priority from your pov, because you are focusing on Wikipedia and V22 and I suppose nobody would ever notice in Wikipedia. I just did, because in my impression it's a thing with (at least german) Wikibooks. One could even think about this as a feature, to "choose" if the toc is printed or not. Regards, HirnSpuk (talk) 07:10, 26 January 2023 (UTC)
 * New TOC is taking too much space in the print; And a messege saying "printable version is no longer available" is displayed in English Wikipedia... It should be fixed. KCCian24 (talk) 09:09, 4 February 2023 (UTC)

Could we default to (or at least allow) default collapsing of level 3+ headers in TOCs?
Currently, when a level 2 header in the TOC is expanded, all the sub-headers are shown, no matter their level, and the only visual indication of header level is then a small indent, about the width of a character. This is strange and unhelpful behavior for navigation, especially on pages with several header levels, like long disambiguation pages (e.g., expand "Arts and entertainment" on Star (disambiguation)). When I expand an L2, I would expect to see only the L3's, which I could then expand as needed (and same for L4's etc.) to find what I'm looking for (like in the Windows Registry).

I think this should be the default behavior (anyone else?), but if it can't be, can we at least get a magic word to set that behavior on a page-by-page basis? Or failing that, could we get some vertical lines to emphasize the level of indentation? Swpb (talk) 15:34, 19 December 2022 (UTC)
 * I agree that this behavior is contrary to how TOC UIs have always worked. They should open one level at a time, with a key-press option to allow opening of all levels (on Mac OS, this has always been the Option key). As for the visual distinction between levels, I have found that the best way to get that is to restore numbering. See for the feature request and https://en.wikipedia.org/wiki/User:Jonesey95/common.css for implementation. Jonesey95 (talk) 19:34, 27 December 2022 (UTC)
 * @Swpb thanks for this feedback. Firstly I want to acknowledge that the new TOC is probably the most complex feature within Vector 2022, and I anticipate that we (community & WMF together) will continue to iterate on it for the foreseeable future. We've been hearing a lot of feedback, and it seems like some additional configurability, magic words, or other such things might be valuable (such as T317818, and more high-level things likeT318186). You can see the current collection of tasks here: T325064
 * Regarding your point: should we show all of the sub-sections (h3, h4, h5, etc.) when expanding an h2, or only show the next-level down (e.g. h3)?
 * I think this is probably an 80/20 thing — 80% of the time (or maybe even more) it makes sense to expand all sub-sections at once (because if there are sections beyond h3s, there will not be many of them, so if we have expandable headings at each level it will require a lot of extra clicking), and 20% of the time (or maybe even less) it makes sense to have collapsable arrows/parent sections for each level.
 * In general, headings below h2s don't seem to be used in a very consistent way across articles. There is not always a clear difference between an h3, an h4, and an h5. Often times it seems to be an editorial/stylistic choice. However h2s do seem to be significantly different than other headings (both in terms of how they are used, and how they are styled). Therefore I think there's an argument to be made that we can draw a line between h2 and h3/h4/h5/etc., and say that h2s are special, and therefore can be treated differently (with this unique "parent" quality, with an expandable arrow), in the table of contents.
 * In specific cases, like disambiguation pages which you bring up, the use of headings might be a bit more systematic/formalized. I agree that in these cases it might make more sense to have a magic-word or something similar to allow that configurability.
 * A few years ago we collected data regarding the frequency of h2s, h3s, h4s, etc. I'm not exactly sure how this data might be helpful in making decisions here, but it seems relevant. Link to data: https://phabricator.wikimedia.org/T18691#5027417
 * Thanks, AHollender (WMF) (talk) 15:44, 5 January 2023 (UTC)
 * In response to this, I think it makes more senses if L1 hearers were expanded by default (or at least with an option for this to be the case). I argue that a main use-case of this site is for rapid reference checking of something (e.g., "what's the formula for the conditional distribution of a multivariate normal distribution again?"). With the current setup of only L1 headers being shown as collapsed, a user landing on the multivariate normal distribution wiki would not see as an option and would instead have to seek through the L1 headers until they stumble on the "conditional distribution" subheader (or hope they get lucky using the right words with cntrl+F).  However, if L2 headers were visible by default they could easily see that the conditional distributions section falls under the "Properties" heading (rather than the falling under the similar "Statistical Inference" heading).
 * I agree that we need to find a balance between information density and not being overwhelming (like the massive fully-expanded Vector 2010 TOC could sometimes be), but, looking at the stats you provided above, it seems that it makes sense for the L2 headers to at least be exposed considering they are available for 93% of articles. Further, this stat shows Vector 2022, in its current form, will slow down the majority of "quick reference use-cases" searches by not having quick navigation. Seankski (talk) 18:33, 6 February 2023 (UTC)
 * Thanks, AHollender (WMF) (talk) 15:44, 5 January 2023 (UTC)
 * In response to this, I think it makes more senses if L1 hearers were expanded by default (or at least with an option for this to be the case). I argue that a main use-case of this site is for rapid reference checking of something (e.g., "what's the formula for the conditional distribution of a multivariate normal distribution again?"). With the current setup of only L1 headers being shown as collapsed, a user landing on the multivariate normal distribution wiki would not see as an option and would instead have to seek through the L1 headers until they stumble on the "conditional distribution" subheader (or hope they get lucky using the right words with cntrl+F).  However, if L2 headers were visible by default they could easily see that the conditional distributions section falls under the "Properties" heading (rather than the falling under the similar "Statistical Inference" heading).
 * I agree that we need to find a balance between information density and not being overwhelming (like the massive fully-expanded Vector 2010 TOC could sometimes be), but, looking at the stats you provided above, it seems that it makes sense for the L2 headers to at least be exposed considering they are available for 93% of articles. Further, this stat shows Vector 2022, in its current form, will slow down the majority of "quick reference use-cases" searches by not having quick navigation. Seankski (talk) 18:33, 6 February 2023 (UTC)
 * Thanks, AHollender (WMF) (talk) 15:44, 5 January 2023 (UTC)
 * In response to this, I think it makes more senses if L1 hearers were expanded by default (or at least with an option for this to be the case). I argue that a main use-case of this site is for rapid reference checking of something (e.g., "what's the formula for the conditional distribution of a multivariate normal distribution again?"). With the current setup of only L1 headers being shown as collapsed, a user landing on the multivariate normal distribution wiki would not see as an option and would instead have to seek through the L1 headers until they stumble on the "conditional distribution" subheader (or hope they get lucky using the right words with cntrl+F).  However, if L2 headers were visible by default they could easily see that the conditional distributions section falls under the "Properties" heading (rather than the falling under the similar "Statistical Inference" heading).
 * I agree that we need to find a balance between information density and not being overwhelming (like the massive fully-expanded Vector 2010 TOC could sometimes be), but, looking at the stats you provided above, it seems that it makes sense for the L2 headers to at least be exposed considering they are available for 93% of articles. Further, this stat shows Vector 2022, in its current form, will slow down the majority of "quick reference use-cases" searches by not having quick navigation. Seankski (talk) 18:33, 6 February 2023 (UTC)
 * In response to this, I think it makes more senses if L1 hearers were expanded by default (or at least with an option for this to be the case). I argue that a main use-case of this site is for rapid reference checking of something (e.g., "what's the formula for the conditional distribution of a multivariate normal distribution again?"). With the current setup of only L1 headers being shown as collapsed, a user landing on the multivariate normal distribution wiki would not see as an option and would instead have to seek through the L1 headers until they stumble on the "conditional distribution" subheader (or hope they get lucky using the right words with cntrl+F).  However, if L2 headers were visible by default they could easily see that the conditional distributions section falls under the "Properties" heading (rather than the falling under the similar "Statistical Inference" heading).
 * I agree that we need to find a balance between information density and not being overwhelming (like the massive fully-expanded Vector 2010 TOC could sometimes be), but, looking at the stats you provided above, it seems that it makes sense for the L2 headers to at least be exposed considering they are available for 93% of articles. Further, this stat shows Vector 2022, in its current form, will slow down the majority of "quick reference use-cases" searches by not having quick navigation. Seankski (talk) 18:33, 6 February 2023 (UTC)

Old style TOC in Vector-2022 Skin
Is there a possibility to set up old style TOC in Vector-2022 Skin at my Mediawiki website v.1.39.0? Fokebox (talk) 11:41, 21 December 2022 (UTC)


 * This problem has been raised multiple times both here and on en.wiki. Many users have expressed their preference for the old style TOC. However, this has been completely ignored by the developers, both here and on en.wiki. Moreover, in the general request for comment on en.wiki a majority of users expressed themselves AGAINST the implementation of Vector 2022; it has been completely ignored, and the result has even been sold as an endorsement. 37.161.248.115 05:42, 28 December 2022 (UTC)


 * Basically I do like Vector 2022 except TOC style. I like how it is done in MW 1.38.x - there is a refreshed Vector skin, but with old TOC style. And I have couple wiki websites and just because of this fact I don't have desire to update to 1.39 ... if so I will have to change skin (Timeless as an example). Fokebox (talk) 07:38, 28 December 2022 (UTC)


 * I agree, the new horrible TOC and the white spaces and width are the main problems of Vector 2022. But the complaints have been ignored by the developers. 37.161.248.115 09:34, 28 December 2022 (UTC)


 * Very strange position ... I don't think it takes a lot of efforts for developers two make TOC view optional (old / new TOC style at vector-2022) for users and for those who has wiki websites!!! Fokebox (talk) 10:43, 28 December 2022 (UTC)


 * I 1000% agree. I had to go back to the 2010 version of the skin just so I could navigate the page. This change is complete trash. This should have had a toggle to go back immediately. 24.42.211.97 22:47, 31 December 2022 (UTC)


 * Hey @Fokebox and other folks in this discussion: I just want to acknowledge that the requests for the old style of the table of contents have not been ignored. We've read and responded to all of these comments, and we've written extensive documentation as to why we think the current implementation is a better approach. I understand it is frustrating: you want a certain change made, you think your idea is better than what is currently implemented, and you think we are ignoring you. However in this case your opinion represents a very small minority. It's not that we're ignoring you, instead it's that we've gotten more positive feedback than negative feedback, plus the extensive consideration of the 12+ designers at the WMF, so we've concluded to stick with the current implementation. Thankfully MediaWiki software is configurable, so you still have options. AHollender (WMF) (talk) 15:55, 5 January 2023 (UTC)


 * "We've gotten more positive feedback than negative feedback". Where? On en.wiki a majority of users (165 vs 154) voted AGAINST Vector 2022, and many doubted the source and reliability of the data you presented in support on your choices. 37.161.68.229 15:59, 6 January 2023 (UTC)


 * That would be this round of community feedback: Reading/Web/Desktop Improvements/Third prototype testing/Feedback


 * Positive: 110, neutral: 38, negative: 23


 * You can read more here if you are interested: Reading/Web/Desktop Improvements/Features/Table of contents AHollender (WMF) (talk) 03:15, 11 January 2023 (UTC)


 * Also, your summary of the RfC is misleading in this context. Around 70% of the people who opposed Vector 2022 specifically opposed the limited width (which is now optional). Maybe 3 or 4 people objected to the table of contents. Every day, here and on Phabricator, we engage in fact-based conversations about the layout and various configurations/tradeoffs with community members, and are grateful for the engagement and feedback. If your goal is to make a case that the skin is poorly designed, and the WMF is not responsive to community feedback, I am confident you will not find evidence to support that. AHollender (WMF) (talk) 03:20, 11 January 2023 (UTC)
 * How is the limited width optional? I'm sincerely asking as someone who has tried for the last half hour to get rid of it (without having to make yet another account on another website). It's either bugged or unintuitive... 92.234.239.124 01:28, 24 January 2023 (UTC)


 * My Personal concern as a Mediawiki website owner. I do like new Vector style except the placement of TOC. And I do know that my website visitors also will be against of that. So that all I ask to make an option - to have new style TOC and have the old style TOC. Fokebox (talk) 09:26, 19 January 2023 (UTC)

I haven't tried the instructions, but this FAQ entry is entitled "How to restore the old table of contents". Jonesey95 (talk) 00:55, 11 January 2023 (UTC)


 * I tried by adding the script to my 2022 Vector javascript, but I saw no change in behaviour. I did not get the old TOC back. Jay (talk) 04:59, 19 January 2023 (UTC)


 * As I said, I haven't tried it. It looks like that text was added by, who is usually pretty good at communicating on talk pages. Jonesey95 (talk) 06:51, 19 January 2023 (UTC)
 * Hah, thanks :D So @Jay if it's not working now, then I'll try it out and ask my colleagues, developers at the team, to update the code. It will take a few days, though. In advance, I'd like to thank you for your patience! SGrabarczuk (WMF) (talk) 00:08, 20 January 2023 (UTC)

Section [edit] button disappears
Seemingly at random, the [edit] -this-section button does not appear when page is opened (like, disappears between sessions). Recently from en:User:DePiep/current; while at the same time in mainspace articles it is present (=OK). Purge did not solve it, but sometimes it reappears (by unknown action), later in a session. DePiep (talk) 09:05, 28 December 2022 (UTC)


 * @DePiep: thank you for making us aware of this issue. I too am NOT seeing [edit] links appearing after the H2 level section headings on User:DePiep/current...are you able to share links to pages where you are experiencing this issue [i]?
 * i. To be doubly certain we're on the same page, I understand the issue you're experiencing as follows: at random (seemingly),  links are NOT appearing next to H2 level section headings (read:  ). PPelberg (WMF) (talk) 00:56, 7 January 2023 (UTC)
 * Yes, as you describe. "No [edit] button in h2 header line, in certain pages/situations". I add A: my "it reappears" remark may be incorrect (no proof of truly being time-related). Add B: same bad behaviour in lower headers (h3, h4). add C: hypothesis: cold be caused by actualy page content (templates?).
 * Yes, as you describe. "No [edit] button in h2 header line, in certain pages/situations". I add A: my "it reappears" remark may be incorrect (no proof of truly being time-related). Add B: same bad behaviour in lower headers (h3, h4). add C: hypothesis: cold be caused by actualy page content (templates?).


 * Pages that do show this behaviour:
 * en:User:DePiep/current/test-2023
 * Pages that do not show this behaviour (that is: show & behave as expected wrt this):
 * en:User:DePiep/chembox/test-2023
 * note: linter errors on the faulty page (&lt;i&gt; unbalanced). I will have to remove them first.
 * I'm sorry for delaying this reply. I hope to be able do some more tests shortly (like, test by page content).
 * -DePiep (talk) 07:04, 16 January 2023 (UTC)
 * Both test-pages now  without  linter messages.
 * To be clear:
 * en:User:DePiep/chembox/test-2023 is OK, shows [edit] links per sectionheader as expected. h2, h3 levels.
 * en:User:DePiep/chembox/test-2023 is buggy: hides [edit] links (expected in section headers).
 * Important note: this same report is valid when working in Vector 2010 (old skin). In other words: bug appears the same. DePiep (talk) 18:08, 22 January 2023 (UTC)
 * @PPelberg (WMF) @DePiep searching in en:User:DePiep/current/test-2023 with CTRL+F, the number of  is not the same number of  . See Section edit links disappear following an unclosed {{. 37.103.49.5 17:03, 25 January 2023 (UTC)

Anchors imprecise
I've been encountering a problem that I think may be caused by New Vector. When I click on the table of contents links at a long page, the place it scrolls to often isn't exactly the thread I clicked on, but rather one or two above or below. Is this a known issue? &#123;{u&#124; Sdkb  }&#125;  talk 22:36, 9 January 2023 (UTC)
 * , Is this on talk pages? Pbsouthwood (talk) 06:30, 10 January 2023 (UTC)
 * Yes, or project pages that consist of discussions like w:WP:VPR. &#123;{u&#124; Sdkb  }&#125;  talk 06:43, 10 January 2023 (UTC)
 * I'm not yet able to reproduce this on w:WP:VPR. What section are you clicking on, and what section is appearing on your screen? Can you provide links to other pages you're seeing this issue on? Also can you provide other potentially relevant details (operating system, browser, browser width, etc.). Also can you check if you can reproduce this in an incognito/private window (append  to the URL). Thanks,  AHollender (WMF) (talk) 05:06, 11 January 2023 (UTC)
 * I tried to replicate it in an Incognito window with Vector and couldn't, so maybe it's an extension I'm using. I'll do some further testing and see if I can isolate the issue. &#123;{u&#124; Sdkb  }&#125;  talk 16:37, 11 January 2023 (UTC)
 * Having paid attention for a few days, the issue seems to occur when I click on notifications from conversations I'm subscribed to, not when I click on a table of contents. I'll follow up with the talk pages project. &#123;{u&#124; Sdkb  }&#125;  talk 16:32, 16 January 2023 (UTC)
 * Hi @Sdkb, thank you for your feedback, are you still experimenting this? I reported your issue here in the talk page of the Topic Subscriptions project, hope this should help. Patafisik (WMF) (talk) 16:51, 17 February 2023 (UTC)
 * Yes, I have been. Thanks! &#123;{u&#124; Sdkb  }&#125;  talk 18:28, 17 February 2023 (UTC)
 * I don't know what exactly is causing this for you (I can't reproduce), but I looked into problems with links to sections in Vector 2022 in general, and figured out why they happen and proposed a fix at T330108. Matma Rex (talk) 02:58, 21 February 2023 (UTC)
 * Much thanks, @Matma Rex! That should hopefully fix it! &#123;{u&#124; Sdkb  }&#125;  talk 03:48, 21 February 2023 (UTC)

Sticky header is not tall enough for a two-line header
The header for logged in users on the Konkani Wikipedia is two lines to accomodate two scripts. When you scroll down, the sticky header is not tall enough for two lines. Should we fix this by modifying the height of the header locally in the css, or should it be fixed globally in the software skin? The Discoverer (talk) 07:22, 14 January 2023 (UTC)


 * Hey @The Discoverer, thanks for reporting this. To clarify: does this only happen on the Main page, or on other pages as well? AHollender (WMF) (talk) 14:10, 16 January 2023 (UTC)
 * @AHollender (WMF), It only happens on the main page, because the main page is the only one that is explicitly formatted to be on two lines. On all other pages the headings are shortened using ellipses (...) and do not wrap. The Discoverer (talk) 15:52, 16 January 2023 (UTC)
 * @AHollender (WMF) / @Patafisik (WMF) / @OVasileva (WMF) / @Zapipedia (WMF): Please could you give some feedback regarding this? The Discoverer (talk) 06:36, 2 February 2023 (UTC)
 * Hi @The Discoverer sorry for the delay. I open this task. Patafisik (WMF) (talk) 12:51, 25 February 2023 (UTC)
 * Grazie, @Patafisik (WMF) ! The Discoverer (talk) 18:51, 25 February 2023 (UTC)

addPortletLink
Hey! Function  loses    class in Vector 2022. Am I doing something wrong - ru:Участник:Iniquity/related-js-css-links.js? Iniquity (talk) 20:56, 17 January 2023 (UTC)


 * Hi @Iniquity, sorry for the delay, we are receiving a lot of feedback and it's hard to answer to all in a short time. I reported your message to the team, I hope this should help. Patafisik (WMF) (talk) 09:20, 25 January 2023 (UTC)
 * @Patafisik, thanks! :) Iniquity (talk) 11:01, 25 January 2023 (UTC)
 * We'll look at this as part of https://phabricator.wikimedia.org/T327369 (a few other issues are being reported). Jdlrobson (talk) 16:24, 31 January 2023 (UTC)
 * @Jdlrobson, thanks :) Iniquity (talk) 21:21, 31 January 2023 (UTC)

Watchlist icon duplication request
At the English Wikipedia, when I have scrolled down the page, the stand-alone "go to watchlist" (GTW) icon disappears, and is to be found under the silhouette icon. Observing my own behavior, I'm scrolled-down far more often than I'm at the top, and so I've quickly become accustomed to clicking 'silhouette → GTW icon'. However, this frequency is training me to—by default—reach for the silhouette to find my GTW icon, and that isn't the case when I'm atop a page. Does that make sense? Placement of the GTW icon is inconsistent and dependent on editors' location on a page, and I find myself wasting time due to the skin training me to expect the icon in one place, but only some of the time.

Can we either (a) stick with one implementation or the other all the time, or (b) put the GTW icon in both places all the time to accommodate all editors? Thanks for listening, Fourthords (talk) 22:13, 17 January 2023 (UTC)
 * Looks like it's already in the page (as it seems that the skin hide/shows based on screen width) so you could hide the one outside the dropdown and show the one in the dropdown, as I'm planning on doing. TerraCodes (talk) 09:34, 19 January 2023 (UTC)
 * Hi thank you for your comment, it is an interesting suggestion. Let me give you more context: the sticky header is showing in a single bar some links that originally are distributed in 3 different menus/bars at the top of the page, so there is not the place for all, considering also narrow screens, and a choice was needed. At the beginning of the project, the watchlist button was inside the User menu, and it was at the same place at the top of the page and in the sticky header. There was consistency. Actual situation is a trade off: early adopters wikis strongly supported for a watchlist icon outside the User menu, there was a discussion about simplicity vs. intensive use reasons. Do you know that you can also use a shortcut to open your watchlist?--Patafisik (WMF) (talk) 17:42, 23 January 2023 (UTC)
 * So you're saying that, when scrolled-down, there isn't room for the GTW icon in the floating horizontal bar, and that's why it's tucked inside the silhouette? That behavior changes when atop the article because feedback early-adopters wanted a stand-alone GTW icon?  If I'm understanding correctly, that inconsistency is frustrating and doesn't preclude including (duplicating) the GTW icon inside the silhouette menu when atop any given page.  Does that make sense?  Fourthords (talk) 13:59, 24 January 2023 (UTC)

disgusting
it is stupid as shit, incredibly boneheaded to make such a change to core page ui. making me make an account to restore functionality is driving a nail into my skull and telling me i get grab a hammer to pull it out. everybody involved in the decision to push this to people who didn't ask for it and didn't want it should be ashamed and should never be allowed to make decisions affecting other people ever again. 76.174.240.67 17:00, 18 January 2023 (UTC)


 * Wow. Absolutely describes my sentiment. Hope they don't just remove your topic just because it uses slur words. This new layout is absolutely disgusting—and to force it on non logged-in users instead of making it an option? Incredibly stupid and unthoughtful 172.58.174.193 18:24, 18 January 2023 (UTC)
 * In my couple of years of experience on Wikipedia, I have never seen a topic removed for just having swears in it. Given this isn't a personal attack, I would be very confused if it got removed. Skarmory (talk) 20:19, 19 January 2023 (UTC)
 * Although I agree with OP the UI options should be available on the front page and stored via cookies. I would like to add this is my first time reading a Wikipedia thread in my whole time of using Wikipedia since it's founding, and I am glad to see it's as much of a cesspool as Reddit, kiwi farms and 4chan in terms of internet culture which I find impressive. I would like to add the new theme isn't so bad but requires some tuning and I hope the web devs absorb some of the constructive and possibly personally developing feedback that is being corroborated here. 45.92.45.198 03:43, 12 February 2023 (UTC)
 * Fortunately you are wrong as this page is not representative of what Wikipedia discussions are like. Many of the commenters here say they didn't even have a username before, and this is probably the first time many of them have seen a Wikipedia discussion page. They brought their discussion style here. kyykaarme (talk) 08:15, 12 February 2023 (UTC)

VPN Users Handicapped
As someone who reads wikipedia and its sister projects with a VPN and without an account, I have no way to revert back to the old legacy layout. The new layout is absolutely terrible especially since I am a desktop user with a wide monitor. I have no plans to ever use the 2022 vector layout as it just looks like the mobile layout which I also hate. Can you make it so that you can change the skin for your IP, so even if you don't have cookies enabled you can still have preferences? 172.58.174.193 18:22, 18 January 2023 (UTC)


 * Hello. Maybe this little trick can help you: simply add «?useskin=vector» to every requested URL. It works for non-logged users. 37.134.90.176 09:14, 23 January 2023 (UTC)

List articles with photographs are broken
Noticed this mostly on List of Manchester United F.C. players. The photos are on top of the table with the list below, instead of the photographs beside the table. It's odd, because on other articles, the photos can be beside the list. I'm trying to figure out how to fix it on this article. MAINEiac4434 (talk) 18:44, 18 January 2023 (UTC)
 * Okay, it works when I toggle the wider layout, but it should also work the default layout as well.MAINEiac4434 (talk) 18:46, 18 January 2023 (UTC)
 * That is a very wide table. If you want those photos to appear alongside the table for all readers, you may need to wrap the larger table in a second table, where the existing table is in one cell of the only row and the photos are in a second cell. This may not be a good idea, however. Jonesey95 (talk) 05:59, 26 January 2023 (UTC)

New layout
Just came across the new layout for the first time right now, and immediately switched back to the old one.

Sorry, but this is simply awful. There's way too much empty white space, and articles are needlessly compressed as a result while it looks woefully antiquated from an aesthetic standpoint. We don't need such massive side margins, for God's sake. What's the point of that? I thought somehow it had switched to the mobile version.

Perfect example of unnecessarily trying to build a better mousetrap. Beemer69 (talk) 20:29, 18 January 2023 (UTC)


 * Couldn't agree more, classic case of "fixing" that which wasn't broken. Xx78900 (talk) 21:21, 18 January 2023 (UTC)
 * +! from me Grl570810 (talk) 23:12, 18 January 2023 (UTC)
 * Hello @Beemer69, @Xx78900, and @Grl570810. Thank you for writing here.
 * We've briefly explained our motivation in the FAQ, and on this page, there's a longer essay. Many individuals may have different preferences and answers to the question "what settings provide you with the best reading experience", and it's possible to customize our interface. As logged-in users, you may set up a preference disabling the limited width. Early next week, we'll move the page tools to the right column, so there will be a bit less empty space. SGrabarczuk (WMF) (talk) 23:14, 18 January 2023 (UTC)
 * Why can’t we leave it for readers to narrow their browser windows down?[edit]
 * Most users don't resize their browser windows or use browser plugins to improve the design of the websites they view. Wikis should be good-looking immediately, in their basic form.
 * And yet now the Wiki is worse-looking by far in its basic form. A gaudy redesign that incorporates the worst features of Britannica's online layout, seemingly in imitation thereof.
 * Xx78900 (talk) 08:53, 19 January 2023 (UTC)
 * I also don't understand why so much empty white space is needed between the article and links (to the left). If readability is such a big issue, they should increase the white space to the right (for infoboxes) and increase the vertical spacing as well. You won't be able to read a damn thing, but it would fullful the "white blank space is useful" prophecy that the FAQ proclaims. -Jetro (talk) 12:54, 22 January 2023 (UTC)

Enter key is not left click
When I'm finished typing something in the search bar and hit enter, I expect the top result to show up, not the page where my cursor currently rests. If I want to click on a page that's not at the top, I'll just use my mouse or touchpad's left click because that's closer to my fingers. This is a big problem for me as I often use keyboard shortcuts and therefore have to physically move the cursor away in order to search properly. lol1 VNIO 🧧🐈 ( I made a mistake?  talk to me ) (talk) 20:35, 18 January 2023 (UTC)


 * Day two of this problem and I've decided to change back to 2010. lol1 VNIO 🧧🐈 ( I made a mistake?  talk to me ) 20:03, 19 January 2023 (UTC)
 * It seems this isn't the case anymore. Now I feel more comfortable with V22. lol1 VNIO 🧧🐈 ( I made a mistake?  talk to me ) 10:27, 25 February 2023 (UTC)

Icons should be labeled
Icons, like the ones at the top, or the persistent ones when scrolling, can be vague and confusing, whereas text is instantly understandable. For example, the "notices" icon at the top could be interpreted as 10 different things. Why not label it to make things easier? 73.162.34.195 21:21, 18 January 2023 (UTC)


 * Hello, thanks for asking this question. During our user study, we did not note any icons which were missing labels that were confusing. Users taking part in tests were able to identify the meaning of the icons quickly and correctly. We may revisit this if we have more comments pointing at specific icons, just like you've pointed at the "notices" icon. So, thank you for being specific about this! SGrabarczuk (WMF) (talk) 00:15, 9 February 2023 (UTC)

Article text reduced to half of usual page width on 1440p monitor/fullscreen browser? I scroll enough at work!
This is pretty ridiculous, although in keeping with "modern" design themes for ludicrously empty spaces. Given my monitor size, the old design lost ~5cm to the left menu. The new design loses a whopping ~25cm for a contents menu and login/user menu. The article text, the crucial content, has lost a little under half its screen space.

Did nobody notice that people come here to read text? Preferably without excessive scrolling?

This a travesty of style trumping function, and you spent my donation dollars on it? Well, that won't continue at this rate. 94.102.193.206 21:25, 18 January 2023 (UTC)


 * Hello! Thank you for writing to us. We've briefly explained our motivation in the FAQ, and on this page, there's a longer essay. Many individuals may have different preferences and answers to the question "what settings provide you with the best reading experience", and it's possible to customize our interface. SGrabarczuk (WMF) (talk) 22:59, 18 January 2023 (UTC)
 * No, actually, if you are not logged into an account, you cannot customize your interface. Because generating one single cookie would just be too hard. 142.162.17.231 02:06, 19 January 2023 (UTC)
 * +1 on the matter of logged-out users being unable to change theme. For such a significant change, a cookie is the least that should be done to respect users who don't have or want an account for any reason they may have. MajorArchitect (talk) 03:16, 19 January 2023 (UTC)
 * I would also like to add to the chorus of both 1) disliking the new width and 2) pointing out that it is still bad if you are logged out 23.84.252.165 00:10, 20 January 2023 (UTC)
 * There's a button in the bottom-right corner of the screen that looks like a "fullscreen" button. Click that, and it'll get rid of the limited content width. AP 499D25 (talk) 05:56, 14 February 2023 (UTC)

The new UI will make me leave Wikipedia
My mental health is more important than trying to fight the incredibly irritating things such as the constantly moving and flashing sticky table of contents and the sticky bar at the top eating my screen space. The ToC doesn't remember being collapsed. Requires more clicks to change the language. It's an absolute travesty as I already said over the past 1.5 years in other comments here. Mobile design breaks computers. Adûnâi (talk) 01:23, 19 January 2023 (UTC)


 * Just... change back to Vector 2010? It's not that hard, just Preferences > Appearance > Vector 2010. Skarmory (talk) 03:49, 19 January 2023 (UTC)
 * I won't type my password a dozen times a day just to get a UI that doesn't make me depressed, sorry. But wait, phone users never log out, I forgot phone users are the only ones that matter, apparently.--Adûnâi (talk) 11:18, 19 January 2023 (UTC)
 * Oh, do you not stay logged in? That never crosses my mind as something people do because it automatically just feels counterproductive, I always forget about shared computers though. Skarmory (talk) 20:16, 19 January 2023 (UTC)
 * You wouldn't even want to use it on a phone or tablet!
 * Take it from a mobile phone editor switching to desktop. Pondekuda46 (talk) 16:38, 13 February 2023 (UTC)
 * It might be easy for people with accounts, but what about those without who have this layout forced on them? DolimiccanDragon (talk) 05:08, 19 January 2023 (UTC)
 * I thought about that, but given the fact that I was replying to someone with an account, I figured it wasn't relevant in this case. Skarmory (talk) 20:12, 19 January 2023 (UTC)

"Missing in norsk" is nonsensical
All pages with a full Norwegian translation are missing a Norwegian translation according to the language dropdown. Norwegian has two variants, including on Wikipedia, Bokmål (common) and Nynorsk (rare), there's no other thing when both variants are covered.

Right now, it is like complaining that a page with both a British variant and an American variant isn't available in English. KristofferR (talk) 02:21, 19 January 2023 (UTC)


 * Hi @KristofferR, perhaps your problem should be the same of this task? I will notify the Language Team about your feedback in the Talk page of the Universal Language Selector, I think there are decisions that are better suited for other teams. Thank you for reporting this issue. Patafisik (WMF) (talk) 13:26, 19 January 2023 (UTC)
 * I tried reproducing this but could not. Can you give an example on which page on which wiki are you seeing this? Nikerabbit (talk) 09:14, 24 January 2023 (UTC)
 * CC @KristofferR Patafisik (WMF) (talk) 17:09, 26 January 2023 (UTC)
 * I'm seeing it on all English articles. https://en.wikipedia.org/wiki/Buckwheat for example, is missing Norsk, while being available in Norsk Bokmål and Norsk Nynorsk. KristofferR (talk) 14:33, 27 January 2023 (UTC)
 * Video demo @Patafisik (WMF):
 * https://i.imgur.com/zQOJVTD.mp4 KristofferR (talk) 14:37, 27 January 2023 (UTC)
 * I have a guess. Can you open a developer/javascript console of your browser and write  in there, press enter and paste the output here.
 * I guess you have  in the list there for some reason. Nikerabbit (talk) 13:49, 30 January 2023 (UTC)
 * Yup, I do. Array(5) [ "en", "se", "nb", "no", "nn" ].
 * I also wonder why I have the microlanguage Davvisámegiella (se) in that array, I only clicked on it after I wondered what the hell it was. However, I am interested in Swedish articles, and read them all the time, so that seems like an additional bug that should also be fixed.
 * I wonder if the code has a bug where it uses both ISO 3166-1 and ISO 639-1, despite the same words meaning different things, like se. KristofferR (talk) 17:48, 30 January 2023 (UTC)
 * Thanks for the info. We are tracking the suggestion issue in Phabricator: https://phabricator.wikimedia.org/T328435 Nikerabbit (talk) 12:08, 1 February 2023 (UTC)
 * Thanks, good luck figuring it out!
 * BTW, is there any way for me to set the FrequentLanguageList manually? That would be helpful. KristofferR (talk) 08:58, 12 February 2023 (UTC)
 * No easy way. It's stored in browser local storage under key . There is also   in JavaScript. Nikerabbit (talk) 13:34, 15 February 2023 (UTC)

Lack of left border
I tried giving Vector 2022 a shot, but the lack of any kind of border or even a change in the background colour between the text and the whitespace to the left of it is a big problem for me. It is difficult to explain, but I felt something similar to strong sense of vertigo when I started reading text after a certain point.

I identified the cause as the emptiness in the left space after you scroll far enough down. It is alright at the top, since the off-colour background of the sidebar serves the role as a border, however, there's nothing in that space once you scroll further down. This issue isn't present in Vector 2010 because it has an explicit border in addition to a different background colour beyond said border.

Oddly, the feeling of vertigo is greatly reduced with the narrow mode, likely due to the whitespace being balanced on the right side, and there being an eventual change in the background colour. However, I highly dislike the narrow mode, so I wouldn't want to use that even without the vertigo. JAK0723 (talk) 05:18, 19 January 2023 (UTC)


 * I completely agree, expanding the view and collapsing the floating menus (because i 1. dont want the TOC on my screen at all times since it creates unnecessary visual noise, 2. am not an active editor so i dont need that tools section), looks like a barren css-less html webpage, no borders, no consistent spacing, the lines between headers starting and ending in random places... vertigo is exactly how i would describe it. looking back and forth from monobook to this mess, monobook feels way more defined and grounded, you can always find where the page begins, estimate the indentation by eye... this is autism speaking but its true. 147.32.90.103 01:44, 6 February 2023 (UTC)

Inconsistent width (I have default settings enabled = limited width mode enabled)
I personally think the design is overall nice, simple and modern. And I think will attract more users to use Wikipedia due to the more modern design, and therefore, consistent design with other websites and operating systems. As I wouldn't be surprised if some people avoided using Wikipedia because it looked "too old". And I think this overall design combats that stigma and gets more people to use it (or use it again), which is an undeniably positive thing for the website and Wikipedia as a whole.

But I can't help and just find the width to be inconsistent within the new skin/theme. When I look at a page, the width is just a bit too thin for my liking (and apparently others as well as I've read on this page - especially for the editing page - also where is the view changes button?). But when I then go to my contributions page, the width all of a sudden is back to (basically) full width. I do use an overall large computer with a large screen, so maybe that's the reason. But I would've hoped, and are hoping, that this new theme (which I must say again, I do like the design of), is tested upon on all screen sizes (from the smallest of computer-tables to the largest of desktop screens).

Lastly, I do think there should be a short-cut button to the most used of features such as the contributions button and perhaps preferences as well. Or even better, according to the data which Wikipedia has, create shortcut buttons for the top 3 most clicked/used button. As before, I did think the top right of the theme was overly crowded and messy (with shortcuts I've never even clicked), and now I think its too simple to the point in where clicking the profile button to access my most used button (contributions) is a bit of an annoyance.

In short, I think the overall more modern and simplistic design great and I hope attracts more users back to the site of Wikipedia. But the simplicity in regards with the usability of the site should be brought back a touch. Perhaps a middle-ground of the old default theme (in regards with usability), but the simplistic design of the new default theme, would be a fantastic middle-ground and satisfy majority of users (which I assume is the goal at the end of the day).

Apart from that, I really do appreciate the fact that there is a discussion page to this new theme. It really shows how open you guys are to constructive criticism and shows how much you want to satisfy the majority of users. 81.227.94.216 08:26, 19 January 2023 (UTC)


 * This is actually happening to me on iPad too. The new UI is good for touchscreens (obviously) but sometimes the page layout is so zoomed in that you need to scroll for ages through large text, and sometimes it’s normal again. But the Safari page zoom settings have no effect, and there’s no place I can find to fix it on the website.
 * Really disappointing design and rollout 125.253.36.248 16:45, 7 February 2023 (UTC)

New UI clearly not liked by the majority of people
Seeing how the UI was made default very recent and seeing how many people are talking about it looking bad and/or having multiple mistakes makes it very clear that the majority of people don't like this new UI, so I think that the new UI shouldn't be default on desktop. The old UI was much easier to navigate with and clearly more liked by the majority of people. I personally think that the old UI is also much better than the new one. 90.145.57.18 09:19, 19 January 2023 (UTC)


 * I agree and I had to make an account to change back to the old one. Vector2022makesmesad (talk) 09:27, 19 January 2023 (UTC)
 * 10/10 name 90.145.57.18 10:46, 19 January 2023 (UTC)
 * To be fair, I think we can say that editors who don't like it are more vociferously opposed than those who do like it. I've not seen good quantitative info that the majority of readers prefer the old interface. But, similarly, the fact that the majority of beta testers and pilot wikis were broadly in favour may stem from self-selection in those groups. T.Shafee(Evo&#65120;Evo)talk 02:58, 23 January 2023 (UTC)

The insolence to think you know better than me what my preferred reading arrangements are
I'm actually mad at you guys. Your stupid hamburger menus and your stupid wasted space. THERE'S PLENTY OF ROOM FOR EVERYTHING. Stop hiding stuff behind stupid button presses. DON'T FORCE A MAXIMUM WIDTH ARE YOU STUPID? Skoinksx (talk) 10:54, 19 January 2023 (UTC)


 * If you prefer the old look, you can switch back to it by changing the skin under user icon→"Preferences"→"Appearance" to "Vector legacy (2010)" —Kri 13:12, 19 January 2023 (UTC)
 * thank you for the explanation. Hi Please read this Sockpuppetry, in particular the section Creating an illusion of support. About Vector 2022 you can find more information here and here, for example how to customize the content width. Please don't attack us, I understand you are frustrated but it is not very useful for us or for you. Please consider not using the capital letters too, on the internet it is considered like shouting. I'm hearing you and you are free to choose your preferred skin locally or globally. Hope those links should help. — Preceding unsigned comment added by Patafisik (WMF)  (User talk:Patafisik (WMF)  • Special:Contributions/Patafisik (WMF) )  16:01, 19 January 2023‎
 * Hey, you "forgot" to sign your post. It is considered good etiquette to sign your comments with ~ . Please explain why you are accusing this user in particular of sockpuppetry - there is really no need of using sockpuppets to post complaints about the new UX because many users are posting about it anyway. Freedomlinux (talk) 16:35, 19 January 2023 (UTC)
 * I accused nobody. If this person is not concerning by sockpuppetry can just ignore my message. Patafisik (WMF) (talk) 17:24, 19 January 2023 (UTC)
 * Seriously? By telling them "using alt accounts is wrong" you are accusing them of socking. Why else did you bring it up? And could you "just ignore" their personal attack? Aaron Liu (talk) 23:44, 19 January 2023 (UTC)
 * Alternative accounts? Do you think I'm the only person in the world that thinks your changes are idiotic? You think I'm the only person who thinks you didn't even read your own research? You REALLY think that?
 * And I AM SHOUTING because you're stupid and you need to be shouted at because you've forgotten yourselves. The absolutely gall to think that you know better than your users what their subjective opinions are BOGGLES THE MIND. You morons didn't even read your own UX research and that is plainly evident when you read the articles you use to explain it. They said "blank space is not wasted space" and "use blocks of blank space to separate logical blocks of information". You plonkers took it to mean that there must ONLY be blank space. How? What twisted mind led you to that conclusion?
 * Please tell me, exactly where in your research did someone come across the thesis: "the users will appreciate having to click multiple times to drill down into useless menus" OR "it's a good idea to hide information behind multiple disparate menus, located in every corner of the screen". You say you've been working on this redesign for years. In all those years, did not at least ONE of you say "oh you know what would be a good idea if we're limiting max text width?", and brace yourselves here, because I may just blow your little minds: PUTTING TWO COLUMNS OF TEXT PER PAGE. LIKE WORD? You know Word? You know WORDPAD? Fucking Wordpad understands stacking two pages side by side to fill the screen and Wikipedia doesn't.
 * The fucking gall. I wish I could take my donations back. Not because of the changes but because you've obviously grown to love the smell of your own farts to the point where you prefer them to air. Skoinksx (talk) 05:19, 20 January 2023 (UTC)
 * @Patafisik (WMF) Why are you bringing up of sockpuppetry for seemingly no reason when replying to people who are against the new design? You've done it multiple times on this page. I don't think it's helpful because it could end up making people assume that some of the posts that like the new redesign are actually sockpuppets, especially considering how few there are. WikEdits5 (talk) 16:41, 20 January 2023 (UTC)
 * He's not attacking you, he's attacking your ridiculous new layout that makes the site hard to use and makes everything unreadable. You should at least have the sense to take the current mass criticism and learn from it instead of accusing users of personal attacks. Freja Draco (talk) 22:15, 22 January 2023 (UTC)
 * did say ARE YOU STUPID?, so did use a personal attack. I agree with the rest though. Aaron Liu (talk) 02:29, 23 January 2023 (UTC)

Why the wasted space?
Why the hell is 2/3 of the screen on desktop used blank unused space? It looks ugly and it makes reading articles in the cramped space frustreating. I implore the wikimedia team to reconsider these design changes as they are terrible 37.247.3.52 12:22, 19 January 2023 (UTC)


 * Thank you for your feedback. In this section of our FAQ there is an explanation of why Vector 2022 has the limited content by default. You can personalize your experience (log-out users can increase the width of the page by selecting the toggle in the bottom right corner of the screen). Zapipedia (WMF) (talk) 12:37, 19 January 2023 (UTC)
 * What toggle? I've yet to find it. Murgatroyd49 (talk) 13:03, 19 January 2023 (UTC)


 * It's in the bottom right corner of the web page (i.e., of the web browser), not in the bottom right corner of the middle third of the web page that the contents are limited to. —Kri 13:19, 19 January 2023 (UTC)
 * Nope, still can't find it, all I get bottom right is the Wikimedia and Mediawiki buttons. I'm using Safari (MacOS edition) if that makes a difference Murgatroyd49 (talk) 14:18, 19 January 2023 (UTC)
 * That toggle would be fine if it actually persisted, but having to toggle it on every single page, every single time you click a link or come to a new page from a search engine or whatever is far too burdensome to be useful or practical, and as such, basically may as well not exist for all the good it does. In all the years I've been using Wikipedia, I've never had to actually log into my account just to have an acceptable viewing experience, and I'm not willing to continually log in everywhere now just to overcome a bad design choice. Hopefully there will be a browser extension available soon that fixes this error automatically because the FAQ makes it clear this is the direction Wikipedia is intent on taking, users be damned. 24.251.3.86 14:33, 19 January 2023 (UTC)
 * Hear, hear. It's difficult for me to understand why making readers push a toggle on every single page on every single visit would be an acceptable alternative. Or an alternative at all. --Kizor (talk) 16:53, 19 January 2023 (UTC)
 * If it is really desired to have this be the default, at least allow users to override the default to their preference WITHOUT creating an account. It is extremely easy to do this with cookies.
 * Personally this new layout makes me want to disable max-width altogether as this one css 'feature' makes reading incredibly difficult. Reukiodo (talk) 01:29, 26 January 2023 (UTC)
 * Do these design principles hold for a website like Wikipedia? If I read an article on Nature, I am reading large blocks of text which, yes, I prefer to view in a smaller paragraph. But in this case, the whole article is a continuous, sequential narrative which requires sequential reading of paragraphs and strong retention of information. However Wikipedia articles are usually not read sequentially and (in my own case, at least) when someone opens a Wikipedia page they generally scroll down to the heading that they want rather than reading sequentially from the start. Having the wide layout, with more information on the screen at once, allows this by providing more points of orientation. It's why I find navigation on mobile Wikipedia so frustrating - I want to scroll up and down to the relevant section, but the restrictions of the mobile screen make it so difficult to orient myself since wherever I scroll all I see is an identical block of text (I'm not sure that can be fixed on a small phone screen, mind you).
 * You may say 'just use the table of contents', but with a wide layout and a scroll wheel, I can navigate an entire Wikipedia article without even moving my mouse. With the narrow layout and less points of orientation, I'm more inclined to a.) move my mouse to the table of contents and navigate that (without being able to see at a glance what each section contains) or b.) take my eyes off the article to look at the table of contents and scroll with the scroll wheel (also annoying since I can't actually see the contents of the article while I do so!) There is also c.) look at the article and scroll with the wheel, but since less information is on the screen at the time this is just less effective than before. LifeOnTheTurtlestack (talk) 21:39, 26 January 2023 (UTC)
 * Wholeheartedly agree with this. I've used Wikipedia for 20 years now and finally bothered to make an account just so I can actually use my whole monitor. Designing for mobile is understandable considering the market share, but punishing desktop users makes absolutely zero sense, more so when it's entirely possible to adapt body size to screen size. LamerGamer44 (talk) 15:48, 19 January 2023 (UTC)


 * Thanks for the toggle button. I am unable to log into wiki at work and this button will be getting heavy use. Its a clean and simple design solution for something that is unnecessary but regrettably will probably stay. 2406:3400:21E:2A50:28A6:361F:3B24:1E10 00:03, 20 January 2023 (UTC)

Please sort the interwikilinks alphabetically - especially for visitors without an account !
It's been said from some dicussers here already (if you search the discussion arhives related to this

discussion) here in this discussion and i want to stress that this is my point of view, too !

I like switching between articles in German, English, Croatian - and sometimes i want to surprise myself by clicking at an unknown language. Switching with your new created language switch tool is a horror and takes me - an un unregistered user - a very lot longer, compared to the 2010 interface, to find myself the language i want to switch to.

Well I haven't, an I don't think others have (some might, of course) THAT geographic knowledge to guess what language is located in which region. Knowing how a language name is spelled is a very easy thing for me. If I know the alphabet and if I search Croatian, i look at the top of an alphabetical drop-down-list, if i search German, i will look more in the middle of the list, if i search English i scroll from Croation a little more farther down. This is an easy thing. So why did you create these regional blocks ?

So please: Do unlogged users a favour and give them a chance to choose a language list option, that gives them a sorted list as from a to z. Thanks - that would be a great thing ! 188.174.249.250 17:19, 19 January 2023 (UTC)


 * THoT_-_languages.png
 * Hi
 * the selection of user interface language is only available for logged-in users, who can disable it in their Preferences (at the end of the page, uncheck "Use a compact language list, with languages relevant to you."). For English Wikipedia, the input method contextual menu is disabled by default. Logged-out or anonymous users have already the list in alphabetical order, can you confirm please? When searching, you can just type the Language codes (e.g.,   or  ) and the language will be suggested by the functionality. For more information about the Universal Language Selector please visit the FAQ page. Patafisik (WMF) (talk) 08:31, 28 February 2023 (UTC)

New update not allowing me to permanently revert back to old skin
I am not a fan of the new update - It has slowed down my ability to edit pages and aesthetically I find the text too large, the white space too much, and the tools to edit or access other aspects of a page more cumbersome than before. I have repeatedly tried to change back to the old skin via preferences and every time I save my preferences it momentarily goes back to the old skin but when I click on a page or load another wikipedia tab it reverts back to the updated skin. Has anyone else had this problem? Does anyone know how I can keep the old skin permanently? CarCai (talk) 20:19, 19 January 2023 (UTC)


 * Update: after changing to the old skin once again, it seems to have kept. I'm not sure why it was not working before but it seems to be fixed now. I also wanted to add some clarification to my above "cumbersome" comment, since it takes more precedent than my aesthetic preferences. When the new skin was implemented the change of the Cite feature and the Link feature to a full screen page rather than the previous pop up when editing articles made it take longer to edit pages. However, upon checking this feature again it seems that it has been changed back to a pop up version. --CarCai (talk) 02:46, 20 January 2023 (UTC)
 * Second Update: I have changed to using the 2022 Vector skin to try it out more thoroughly. After a few days, the aesthetic of it was growing on me. I think there were only 2 thing I personally kept noticing during my use. One was how much I had to scroll with the new skin. I understand this may be more desirable for some but it was a little clunky compared to the old version. I saw that someone had found a way to disable the max width, which helped some. Secondly, I wish there was an option to customize which icons appear in the top right corner or be able to see all of the icons at once. I think the drop down menu looks cleaner but for me it is not the most practical set up. CarCai (talk) 06:35, 27 January 2023 (UTC)

Upcoming Page Tools sidebar: font size and line spacing too large
This is a comment about the upcoming Page Tools sidebar, which is visible by going to https://en.wikipedia.org/wiki/Universe?vectorpagetools=1

At least in my browser, the font size and line height used in this Page Tools sidebar, as is true with the font size used in the Table of Contents and Main Menu when they are pinned to the left sidebar, are all much too large. My browser tools "inspector" feature tells me that the font size in all three of these sidebar menus is the same as the font size in the main body of the article. In Vector 2010, the sidebar text is considerably smaller, with narrower line heights, allowing much better information density and the ability to scan for the desired option easily without having to scroll.

I have had to use custom CSS to restore the left sidebar and sidebar TOC to a reasonable (i.e. smaller) size and line spacing in Vector 2022, and I will have to do that with the page tools if the size stays the way it is.

I can post screen shots here or to a phab ticket if I am the only one experiencing this suboptimal UI. Pinging, who suggested that I post comments here. Jonesey95 (talk) 01:28, 20 January 2023 (UTC)
 * I see the same: standard body-text font size, and uniform line-spacing similar to a bulleted list in the body, make both right and left margins rather hard to read or to distinguish from body text. Sj (talk) 04:57, 20 January 2023 (UTC)
 * If the font size in those sidebars were reduced to the Vector 2010 size, the sidebars could be made much narrower while showing the same number of characters per line. This would make more space available for the page content, which is highly desirable (especially with two sidebars instead of one). Jonesey95 (talk) 05:48, 20 January 2023 (UTC)
 * Oops,, it appears that the sidebar was deployed with these problems in place. Here's hoping for a quick fix (or temporary revert). Jonesey95 (talk) 22:12, 23 January 2023 (UTC)

Challenges: TOCs + magic words; protected templates breaking; sidebars

 * TOC


 * Magic words like NOTOC / FORCETOC are no longer being respected.
 * Some pages expect an expanded TOC by default as an important part of the page presentation. There should be a [new] magicword for this, at least
 * After hiding the sidebar TOC it is impossible to find and restore again. Why not use the familiar [show]/[hide] style used everywhere else?
 * Long TOC lines, and long vertical TOCs, involve line wrapping and scrolling, but it's hard to see a distinction b/t the TOC and the content (no background color difference, almost no font size difference)
 * When scrolling down a long page, the flickering of the TOC as it automatically scrolls too, and as different sections get auto-highlighted, is disorienting for me. Others have described vertigo.  Something that does not draw attention would be better.


 * Major templates (which have their own mechanism for breaking up long lines)


 * now breaks on many pages. I'm not sure why.   That's a traditional way of making better use of screen width with multiple narrow columns.
 * References-section multicol still works, but are now constrained to the narrower body div. They should be able to use the full screen width instead.

It's one thing to leave the long tail of templates out of scope, but less so for core templates used everywhere. And in these examples, a functional way of using the entire available screen to show a lot of useful information with short line widths has been degraded. Reference display is universal enough -- and a large enough % of all page scrolling, especially on high-traffic pages -- to be worth treating with care.


 * Sidebars generally

These feel like they're getting the short edge of the page. The placement of the various buttons at the top (for collapsing part of the sidebar, for collapsing the TOC) seem less coordinated than the rest of the topnav; the padding between the right edge of the l.h.s. and the left edge of the main content seems large, even by the standard of the new design. The "switch to old look" and "look elsewhere for languages" notes in the l. sidebar seem hasty, somehow. The current draft of tools in the r.h.sidebar suggests further changing font and linespacing. I don't have more specific comments, just... please treat these parts of the skin with love. ~ Sj (talk) 05:27, 20 January 2023 (UTC)
 * On my screen, the fundamental cause of the above column-related problems is the width allocated to the non-sidebar page content. Div col and reflist columns on en.WP are 30em wide by default. In my browser window, I have about 86em (950px) of page content space to work with because the wide left sidebar and TOC are still taking up too much horizontal space. And this is after I used my common.css file to reclaim a bunch of space on the left and right sides. In Vector legacy, I have 94em (1038px) for the content because the sidebar is appropriately narrow.
 * See the comment above about the font size in the left sidebar and the (coming soon) right sidebar. If the font size in those sidebars were reduced to the Vector 2010 size, the sidebars could be made narrower while showing the same number of characters per line. This would make more space available for the page content, possibly allowing enough space for 30em to be a meaningful column width. Jonesey95 (talk) 05:46, 20 January 2023 (UTC)
 * About the magic words: I mentioned that last year in T273473, will try to follow up on it! XanonymusX (talk) 12:39, 20 January 2023 (UTC)
 * About the magic words: I mentioned that last year in T273473, will try to follow up on it! XanonymusX (talk) 12:39, 20 January 2023 (UTC)


 * And, please consider wiktionaries which are dictionaries, not encyclopaedias. And also please consider small wiktionaries, who do not have volunteer progammers to make nice adjustments for us. See my asking for help from TOC programmers at enWP Not to mention 'interwiki languages' We rely on the mother-language-wiktionary, and heavily on en.wikt for ProtoIndoEuropean etymologies, etc. They must be immediately available (of course, we can write links with their addresses at the See also section: an extra task). Thank you for this post, from el.wiktionary, ( Central )Sarri.greek (talk) 10:53, 8 February 2023 (UTC)

Lack of visual contrast between areas of the page
I missed the original discussions, so hopefully there's still some room for feedback here. The reduced content width is actually one of the main things I like about the new skin as someone using a wide monitor, and the main reason I started adopting it a few months ago.

My main complaint is the lack of visual contrast between different areas of the page. Only the sidebar has a visual background and border separating it from the rest of the page, as well as infoboxes and templates within the article itself. Everything else is a sea of white: the article body is narrower than the white content area, increasing the appearance of unused space to the right and leaving no defined border around the content. There is no obvious separation of the header at the top of the page, reducing the apparent personality of the site.

There are also no borders between the TOC and the article section unless the TOC is long enough to show a scrollbar, which makes its appearance inconsistent. The TOC is also harder to identify because the "Contents" header is now in normal font and less emphasized than the current highlighted section of the page, as opposed to the old skin which has "Contents" in bold, and is hidden once the contents are long enough.

There are a number of unintuitive elements in the UI as well, namely the toggles to show or hide the sidebar and TOC. The positions of the header elements (search bar, talk, edit, history, and language dropdown) shift around when scrolling down enough for the logged-in floating header to show. The search icon position in particular is unintuitive, being moved to where the logo normally is.

These issues are magnified when toggling full width or having a narrower screen. There's no background change at all and the entire page only has the single white background, and the icons and links in the header are pushed even further to the sides.

Would it good idea to move either the sidebar or TOC to the right side of the page? This stops them from fighting for the same space on the left and partially resolves the issue of the right side being completely unused. - Sonicwave ( talk &#124; c )  19:35, 20 January 2023 (UTC)


 * This lack of visual contrast is what's bothering me too, I think it makes my eyes strain more than before. I also was frozen for a moment when I clicked [hide] on the TOC for the first time and it just disappeared into the void. I actually had to reload the page and click it several times to find out how to enable it back. Sometimes I encounter very unintuitive UI on the Internet but I was surprised to see it here, on one of the most visited sites in the world. RoadTrain (talk) 02:46, 23 January 2023 (UTC)
 * Thank you for your detailed feedback @Sonicwave32. We were working with the American Foundation for the Blind to improve accessibility of Vector 2022 but some changes are still in progress, look at T318373 and T310033 for further information. The Article tools will be soon moved to the right side of the page (you can see a prototype here). Zapipedia (WMF) (talk) 16:43, 23 January 2023 (UTC)

I'm also sharing this complaint. What i described was it was all borderless with no defined space. It gives it a "floaty" look.Blue Pumpkin Pie (talk) 23:29, 20 January 2023 (UTC)

Bring back the TOC
There are many things about the new 2022 interface that made me a bit uncomfortable on first using it, but in my experience so far the designers have made only one game changer, deal breaker change, by removing a feature I can't give up, so I will stay with the 2010 interface forever if they don't bring that feature back, at least as a user appearance preference. That's their removal of the old inline TOC at the top of the article, of course. The new pop-up sidebar TOC with its floating button is not a static TOC, it's a different feature entirely, innovative and useful in its own way (although the way its floating button always blocks the upper left corner of the page is very visually annoying, and you cannot get it out of the way no matter what you do by repositioning the page). But no matter -- that's not the deal-breaker. The pop-up sidebar TOC, whether you like it or not, isn't a TOC at the beginning of the article, which has been the signature appearance of every Wikipedia article since time immemorial.

When you open a Wikipedia article you expect to see a lede (like the abstract of a research article), followed by a table of contents showing the structure and organization of the article, giving you an instant idea of whether this article is 1 or 100 pages long, and how developed it is. As you refer to the article again and again over time, you will probably depart from that TOC to places you have discovered within the article again and again, your body developing a kind of muscle memory for the way the space inside the article branches out from the top. Your mind is learning the geometry of part of the vast space that is Wikipedia. The TOC at the top of every article illustrates one local part of that space. The TOC is the article editors' best attempt to choose a geometry for that subject that makes sense. It is editor-written content, artistry, not merely a generated index or search results; in fact it is the most important content in the article, after the lede. Sometimes it's all you read of an article (the lede and the TOC), and it tells you that you don't need to know any more. It can be collapsed or expanded, as suits your personal need of it, but surely it should not be entirely hidden in an always-collapsed pop-up sidebar.

The designers should fix this flaw in the new interface by simply bringing back the static TOC exactly as it is in the 2010 interface. The pop-up sidebar displaying the TOC can remain too, just don't display its floating button until the display is scrolled down to below the static TOC. It would also be a diplomatic policy decision (a no-brainer, really) to provide a user appearance preference for a static TOC, a pop-up TOC, or both. Dc.samizdat (talk) 21:35, 20 January 2023 (UTC)
 * I prefer also the TOC in 2010 interface. --Ensahequ (talk) 02:22, 21 January 2023 (UTC)
 * Yeah I agree, I like the static Table of Contents at the top of the article, I don't want to have to start scrolling to find the TOC so I can skip to the particular section of an article that I want to read. B 897 (talk) 04:28, 21 January 2023 (UTC)
 * I want to add my full support to bringing back the classic ToC. The new sticky ToC can coexist with the classic one instead of replacing. I think each serve different purposes and could be complementary. I also made similar comments in the w:Wikipedia:Requests for comment/Rollback of Vector 2022#Bring back the TOC. Thank you. Al83tito (talk) 05:43, 28 January 2023 (UTC)
 * Not to say its old good numbering scheme, now lost. No matter where the TOC appears, it should retain the numbering scheme. 37.134.90.176 07:55, 23 January 2023 (UTC)

Suggestions to fill right-side whitespace
First, thanks to the new redesign, it's fantastic.

Second: could you try out a few prototypes that would fill the white-space on the right side? That might address the criticism by some people, and it would still limit the width of the contents. Here are the ideas:


 * Don't include impose a content width limit on infoboxes and right-aligned thumbnails. If the page gets wider, the images & infobox can move beside the contents, so it gets more space to breathe.


 * Bring up references on the right, instead of scrolling the user to the bottom of the page. It would look like this (though it could be made cleaner & more usable than that).
 * The 2nd point would be especially nice if it could prevent the 2-steps necessary to read shortened footnotes (Sfn). Currently, click on a footnote, and you get scrolled down to, say, "Hawkins (2020), p. 4". Click on that, and you go to the reference, but there's no button to go back to the contents from that second reference (that button is only on the footnote). Usability could definitely be improved there. This would bring strong encyclopedic benefits, since it would help people follow the references more conveniently.

Note: I'm not suggesting that my two ideas would necessarily be better than the current version, which is basically perfect as-is. They're just things that I'd like to see tried out; maybe they'd be better. DFlhb (talk) 23:54, 20 January 2023 (UTC)


 * Thank you very much for your constructive feedback @DFlhb. I will pass your suggestions to the team. Indeed, whitespace at the right will be soon occupied by the Article tools. Zapipedia (WMF) (talk) 16:47, 23 January 2023 (UTC)

Scrap the 2022 skin
This new skin has no perks at all. Just put it to rest quietly, noone will miss it. 37.247.31.205 00:21, 21 January 2023 (UTC)
 * Sorry, I agree. --Ensahequ (talk) 02:24, 21 January 2023 (UTC)
 * I agree too. Scrap this weird skin or move it to the mobile version of Wikipedia. No one will miss it. Nothing in Vector 2022 is better or attractive at all. Nothing. I'm shocked how some people say they like it, what is to like in this weird layout made for phones? 94.26.15.134 02:44, 28 January 2023 (UTC)

Why is the log in button hidden behind the three dots symbol?
Currently, on Vector 2022, the top right corner shows the button "Create Account", as well as a symbol of three dots. The log in button is hidden behind these three buttons. Why is that? This means that users need unnecessary amount of clicks to log in. The corner has plenty of empty space, so the log in button would fit well next to the "Create Account" button.

If the white space in the top right corner is for some reason important, why isn't the log in button visible and account creation behind the three dots symbol? After all, users usually only need to create an account once, but they need to log in many times. Valtaisa varpunen (talk) 12:34, 21 January 2023 (UTC)


 * I'm happy to see that the log-in button is no longer hidden in Vector 2022. Thank you! Valtaisa varpunen (talk) 15:49, 15 February 2023 (UTC)

Suggestion for alternative look for Vector 2022
Vector 2010's grey sidebars (#f6f6f6) and single-pixel blue border (#a7d7f9) have been a significant part of Wikipedia's look and identity since V2010's rollout and it would be a shame to lose this, especially to a layout where there's a lot of whitespace between the sidebars and the article content itself. I understand this is so the article can appear centered, but I think it would achieve this better if the table of contents were put in the sidebar instead. I've made a quick mockup to demonstrate.

For the record, I personally have no problem with the limited-width approach that V2022 adds, but a necessary consequence of that is a lot of whitespace that could be put to use in anchoring the article and drawing the eye to it - which it would do much better if the grey colour didn't end halfway through. With current V2022, the articles look disconnected and floaty. AsmodeanUnderscore (talk) 16:43, 21 January 2023 (UTC)


 * Just want to chime in and say I'd personally love this!! A lot of the jarring feeling comes from the sheer amount of whitespace, and you're right, it feels quite unanchored at the moment. An edit like this may fix a lot of people's initial hesitation to adopt Vector 22. A slight problem would be in just sticking the TOC in the sidebar, which may cause a bit of user confusion, but overall I think bringing back the grey sidebars would help a lot in grounding this redesign in some familiarity. Enuui (talk) 06:34, 24 January 2023 (UTC)
 * https://di-visual-design-borders-bgs.web.app/Zebra#top (9) outside article background (solid)) looks better. -- NGC 54  ( talk |  contribs ) 11:59, 1 February 2023 (UTC)
 * (9) but with the borders staying blue would be the best iteration of this i think AsmodeanUnderscore (talk) 14:43, 1 February 2023 (UTC)
 * The blue borders are not bad, either. -- NGC 54  ( talk |  contribs ) 14:50, 1 February 2023 (UTC)

More feedback (ToC, logging-out, Settings menu and user menu)
I just want to underline some things.

I want to underline 2 issues with the new ToC:
 * ToC issues
 * 1) See this image: https://ibb.co/DwTZH8r. Why does the ToC is so short? If the ToC would be longer, then the reader would have to scroll the ToC less often.
 * 2) See this video: https://vimeo.com/791479775. 1. When your mouse cursor hovers over the ToC box and 2. you scroll trough the ToC 3. while the ToC scrollbar is at the lower end, the reader should not be able to scroll the content of the page. It happened to me to want to choose the last section, but I was unable because when I wanted to click that section, the content of the page moved and the ToC turned back to the upper (first) sections. This is annoying.

Previously, the issue described here occurred only when clicking the log-out link from the sticky header. Now, it also occurs when clicking the log-out link outside the sticky header (from the user menu that is not part of the sticky header).
 * Log-out process

I like the idea of providing the settings menu from https://patchdemo.wmflabs.org/wikis/10b47eaaa5/wiki/Space?useskin=vector-2022 and I would like to see it deployed on Wikimedia wikis. However, I think that due to its placement (the lower right corner), most readers would miss it, even if they would like to change one or more of those settings. If this would be deployed, these settings should also include the ability to disable/enable the Page Previews (and the Reference Previews for wikis which have them), and could also include the ability to disable/enable the dark mode when and if the dark mode will ever be built and deployed (and if there would not be any better location for the dark mode toggle, of course). -- NGC 54  ( talk |  contribs ) 18:41, 21 January 2023 (UTC) -- NGC 54  ( talk |  contribs ) 13:33, 27 January 2023 (UTC)
 * Settings menu (Site preferences)
 * User menu
 * 1) I have previously reported this, but it is still unfixed. 1. Make sure that you are not logged-in on Commons. 2. Click "Uploaded menu" from the user menu. 3. You arrive on Commons at Special:ListFiles/Some IP, not at Special:ListFiles/Your user name.
 * 2) Sometimes, you can click some links from the sticky header user menu even when hidden. See this video: https://vimeo.com/793346408.
 * P.S. For me, it is often hard to tell apart sections from subsections. T307316 would be a solution. -- NGC 54  ( talk |  contribs ) 13:24, 23 January 2023 (UTC)

Congrats to the Vector 22
I am not sure if this is the correct venue where to place this, but I am getting more and more fond of Vector 2022. I just noticed that the script is bigger when searching special characters like Ω. Other features are good, too. For now, the one thing I am bit worried is if the reader will also know, the TOC is hidden behind the three bullets. The solution is great for the editors, though. Paradise Chronicle (talk) 21:32, 21 January 2023 (UTC)


 * Thank you very much for your feedback @Paradise Chronicle. Regarding the TOC, you can learn more about our user testing research here. Zapipedia (WMF) (talk) 15:25, 23 January 2023 (UTC)

I would like to hide the switching to the previous exterior.
I wish I could set it up with css or something. 2400:4152:6600:2900:EDE8:C00D:BB73:F5F9 03:47, 22 January 2023 (UTC)

Impact and goals
Second try, reposted from Vector 2022 Post-Deployment Update from WMF team:

Thank you for this update. It's depressing that it takes a pitchfork mob on the English Wikipedia for the Wikimedia Foundation to answer an obvious question which previously went unanswered for a year: what are you trying to achieve here? How will we know that a certain version of the skin helps with the goals?

Unfortunately, this collection of cherry-picked statistics cannot tell us much, because we still have no idea what the strategy is behind this entire exercise. I could comment on the individual statistics but it would be pointless. I do notice there's nothing about onboarding new users, making editing more effective or "cross-project and cross-language functionalities" (recommended by WMF's own supposed strategy).

Because interfaces are a trade-off, changing things for the sake of improving some metric will inevitably worsen some other metric, so I can only assume that overall strategic goals are affected negatively by the changes.

Separately I also posted a comment on the strategy, which evidently failed to provide useful guidance for this project. Nemo 10:42, 22 January 2023 (UTC)

Wikipedia is wasting donation money on pushing some JS framework nobody cares about.
While you could be doing something useful with the money, you decided to invest a lot of time and money on creating a problem that now requires a lot of fixes because nobody likes it or just features don't work/are missing.

I believe it's an insult to Wikipedia readers to do such move. You wasted the money on creating a "postmodern low-quality Wikipedia" just because some JS framework marketing campaign washed your brains.

Change it back. Use the money properly, adding value instead of breaking what didn't need to be fixed. Microph123 (talk) 12:57, 22 January 2023 (UTC)


 * This response makes little sense. You might not like the design, but the entire implementation is standard CSS and HTML and the only thing that requires JS is to move the ToC while you turn your view from wide to narrow or the other way around. If anything, this is probably the least amount of JS an interface like this could be built with. I get that some people don't like the new design, but this technical argument brought forward here definitely does not apply. —Th e DJ (Not WMF) (talk • contribs) 15:56, 23 January 2023 (UTC)

Translations link
I cannot find any feedback or question page and I hope I can get information from here, and that the pinging is OK. In the  drop down list "Translations" is shown for me, taking me to the translation tool. That is all good and it might be some setting I have activated. But on the, when scrolled down, the "Translations" choice is not available. It had led to some confusions when it has been missing.SGrabarczuk (WMF) Is that a feature or a bug? LittleGun (talk) 13:43, 22 January 2023 (UTC)


 * Hi @LittleGun, thank you for your feedback. Please look at this comment for more information about this change. Patafisik (WMF) (talk) 09:07, 25 January 2023 (UTC)
 * Patafisik (WMF): OK, thanks for linking my comment to the phabricator task. LittleGun (talk) 12:38, 25 January 2023 (UTC)
 * Hi @LittleGun I'm not sure you are reading the correct line. What is your account on Phabricator? Are you reading the comment by the Principal Software Engineer, Language Engineering team writing Dec 12 2022, 11:59 AM "I just removed these menus from sticky header for now. Will revisit later(or even remove them permanently as persistant entry point for translations is ready)"? CC Patafisik (WMF) (talk) 13:03, 25 January 2023 (UTC)
 * Patafisik (WMF): I do not have any account on phabricator, and I hardly ever understand the threads the few times I have read any.
 * In this case I understood the topic was the same as mine, that the work was paused by "santosh" ("removed for now"), and that you added the comment:
 * "Hi @santhosh, just FYI here a user is confused by this change."
 * And "here" was link to this thread.
 * So I thanked you for linking my feedback in the Phabricator thread. LittleGun (talk) 13:30, 25 January 2023 (UTC)

Line-length Study
There really ought to be a better reference here. This "study" is just a random PDF - it appears to be unpublished, unreviewed, has no citations and scant details on data. 98.14.66.93 14:09, 22 January 2023 (UTC)


 * Thanks for your comment. I'm not sure which particular study you're referring to - could you give us some more detail? As a part of our research, we reviewed 7 academic studies, as well as the WCAG accessibility guidelines.  More information on our sources and motivations are available on this page.   OVasileva (WMF) (talk) 15:39, 10 February 2023 (UTC)

Deployment roadmap on Chinese wikis
Hello, there is currently a local discussion about postponing the deployment on Chinese Wikipedia. In the discussion, some editor have shared concerns about the issue of Chinese Language Converter not working in Vector-2022 (T306862). Although Vector-2022 has already been deployed on most wikis, when will it be deployed on Chinese wikis? Will Vector-2022 be deployed on Chinese wikis after the issue of the Language Converter is fixed? Thank you. cc SCP-2000 (talk) 16:39, 22 January 2023 (UTC)


 * @SCP-2000 According to the ticket the issue is marked as a blocker and it seems last friday there was a new patch started to work on a fix for it. —Th e DJ (Not WMF) (talk • contribs) 15:52, 23 January 2023 (UTC)
 * Hello @SCP-2000! Thanks for letting us know about that discussion. Right now, we are focused on the feedback coming from English Wikipedia where Vector 2022 became the default last week. We don't have any specific deadline set up for discussing with the communities of the Chinese-script wikis. SGrabarczuk (WMF) (talk) 16:07, 23 January 2023 (UTC)

I don't like it.
For me, the old skin was fine. I was used to it, I knew where things were. No problem.

The new skin seems pointlessly different. Different isn't always bad, but in this case, there seemed to be way too much exra whitespace, meaning that the information density is lower.

I apologize to the people who I'm sure worked hard on it, but I did not follow the suggestion to "try it for at least one week prior to deciding whether to switch". I switched back to the previous Vector as soon as someone gave me the link. (Thanks, ). It was an easy decision.

This is unfounded speculation, but I suspect there's a certain amount of Politician's logic involved here. There was a (doubtless well-intentioned) goal to "make the interface more welcoming and usable", and there was money available to do the work... but once you've got a mandate and some money, you're not going to just tinker around the edges, you've pretty much got to do something big and bold and different, which means it's bound to be disruptive. —scs (talk) 17:09, 22 January 2023 (UTC)

purge-by-clock: slowness effects
About the purge-clock in my user-dropdown menu (top-right on desktop). When I open a page, in the Usermenu (top right), circa position #6, a  clock  appears as menu option (showing UTC time), to Purge the page. All fine.

Now when I click that menu option directly after opening that page (purge the page as first action), the clock is not added completely: '' when clicking the clock, it activates menu option "Log out". That is: the menu option previously in that position (before the clock was added in between). This situation exists some 1 or 2 seconds.

This is a nuisance (logout-screen appears unexpectedly; though very strange unexpected so logout by mistake is not often.). But also, the logout screen looks similar to other screens (like, "purge" manually alternate GET\POST screen), and so logout may easily happen.

TL;DR: The Purge Clock in Usermenu installs slowly, thereby connecting to a  different  menu item -- namely the menu item "Logout". (for 1 or 2 seconds after page opening). DePiep (talk) 18:27, 22 January 2023 (UTC)


 * Hi @DePiep, thank you for reporting this, can you verify if this subject has already been addressed, and if your can found an answer, in replies in this talk page? Thank you, Patafisik (WMF) (talk) 12:24, 24 January 2023 (UTC)
 * Moot by now: the clock-to-purge is repositioned to outside of the menu (now in top usermenu bar).
 * In the new situation, the issue does _not_ appear.
 * (FWIW, aftertalk: in the problematic situation and _after_ the request by Patafisik (WMF) was posted here, I experienced the old (bad) behaviour. The clock appeared, and for circa 3 seconds - the clock counts itself ;-) - clicking meant opening the Logout screen (the unexpected behaviour).
 * At this moment, with the repositioned clock, some seconds of time delay is still present but *no* wrong page is opened.)
 * This report may be Closed as Moot/Resolved. DePiep (talk) 21:12, 5 February 2023 (UTC)

Font and Scrollbars — Bad Choice!
Font. The new skin turns every page into a section of the Great Text Wall, it's basically unreadable. Wikipedia is supposed to be read. A standard Wiki page has a great deal of text with a few illustrations. That's why Wiki's most important GUI feature, IMHO, is readability.

The basic readability requirements for websites are very simple. It's color (standard choices: white on black, black on white, and brown on sepia) and font. Font should be easy to read, that's all, nothing fancy, nothing "pretty", no personal preferences, nothing special. It should not be "stretched out" vertically or horizontally. There should be clear separation between paragraphs, a suitable interval between words and between lines, and even larger space before headers. Check any novel from a reputable publisher in any book store, see the width-height proportions, space between letters and words, and the paragraph formatting. Choose similar sans serif font and use the same formatting. That's all. Isn't it easy?

Scrollbars. I have 3.5" (9 cm) empty space between the content and the article (27" monitor), and 3 scrollbars to use (additional vertical scrollbar for the content). That's really ridiculous. Back in the 90s, all web designers raved about "liquid" design and scorned frames. 30 years later — yay! we've got our scrollbars back! I can still kind of understand 4-6 scrollbars in Google Sheets, but here?

In short.

The first time I opened Wikipedia with its new skin, I was greeted with a message like "We did some improvements". Was that a joke?

Spljushka (talk) 22:23, 22 January 2023 (UTC)


 * Just to put this out there.. The font of the content and it's spacing didn't change, as far as I can tell using the web inspector...... —Th e DJ (Not WMF) (talk • contribs) 15:46, 23 January 2023 (UTC)

Why, Wikipedia, why?
If I wanted to use the mobile version, I would use the mobile version. But I want to use the desktop version on a desktop computer, so why are you forcing me to look at a mobile-like layout? The mobile-like layout is NOT optimized for use on a PC. Freja Draco (talk) 22:38, 22 January 2023 (UTC)


 * Hello @Freja Draco. These changes are created specifically for desktop interfaces. You can learn more in our FAQs and at the Desktop Improvements project page. Thank you. Zapipedia (WMF) (talk) 15:34, 23 January 2023 (UTC)
 * That's not true. You do not listen to the voice of users at all and do not address the allegations. You just keep repeating your corporate talk about how "great" your ideas are. It's sad. 83.30.229.13 16:28, 24 January 2023 (UTC)

Much harder to read, lowers accessibility
I have problems reading text on screen if it is not black text on a light background, but of course having the entire page bright white is also not brilliant for eyestrain.

The previous style was great for me because parts of the page were a darker grey colour which evened out the eyestrain and I never had a problem reading wikipedia pages, but now everything is bright white and makes it very hard for me to read the page.

I don't see how the new design is intended to actually help accessibility for people like myself. RCTJ1991 (talk) 00:22, 23 January 2023 (UTC)


 * Hello @RCTJ1991, thank you for your feedback, I will pass it to the team. We were working with the American Foundation for the Blind to improve accessibility of Vector 2022 but some changes are still in progress, look at T318373 and T310033 for further information. Zapipedia (WMF) (talk) 15:45, 23 January 2023 (UTC)

Don't fix what ain't broke
Oh come on Wikimedia, you know better than that! What was wrong with the old layout? What problem did you solve?

For me, everything was right! It was clear, it worked in old browsers, and it allowed me to quickly switch between languages by a simple click. Is someone suffering from "new is always better" syndrome over at Wikimedia? ;) There was no better way to spend the money I send you every year?  If we all sent you less, would such "upgrades" be out-of-budget in the future? :) I fear that Wikimedia got infected by Parkinson's Law, project managers looking for some raison d'etre, wasting resources. I hope I'm wrong.

If you must have this new "better" layout, please, at least give people an easy way to go back to the one they prefer. Without logging in of course - such nonsense! Write a flag in a cookie, problem solved.

Thank you for the otherwise awesome and free encyclopiedia! I use it daily, can't imagine internet without it!

Success metric tracking
Hi, is there a place we can follow along with the initiative's success metric tracking? czar 05:58, 23 January 2023 (UTC)

menu design
Designing menu's is a tough puzzle. What helps:
 * 1) mutually exclusive options should be excluding each other in one menu. For example:
 * 2) *article/talk/history/wikidata item/page information
 * 3) *Chinese/English/French/Italian
 * 4) *read/edit/print/add-to-watchlist/download to PDF
 * This rule ensures that a user needs to look only in one menu to see mutually exclusive choices. This is hard to get right. It is tempting to move low frequency options to a separate menu.
 * 1) Options that can be combined should be in separate menu's, but close together. For example:
 * 2) *article English read
 * 3) *article English edit
 * 4) *article English add-to-wachtlist
 * 5) *article Italian print
 * 6) *talkpage French edit

An object - action approach 'article English read' deviates from spoken English 'read English article' and that is OK. It's UI design, not spoken language design. An object - action approach will make it easy to show the available actions for a chosen object. For example Uwappa (talk) 17:47, 23 January 2023 (UTC)
 * article English: read, edit or print
 * article Afrikaans: create, translate from English, translate from French
 * history English: read, print

Menu inefficiency
It is counterproductive to place Talk, Sandbox, Preferences, Contributions, and Logout into the account submenu. Users (myself included) have to search around for these, and likely ask for assistance. There is plenty of space to place them visibly on the main menu line where they have been in the past. This (a) informs users that these functions are available, and (b) allows users to access these functions without wondering where they are and clicking around to find them.

Removing and hiding features may give the page a cleaner look, but functionality must be the most important design criteria. Otherwise, we could just serve a blank page.

Edibobb (talk) 20:27, 23 January 2023 (UTC)


 * Putting commonly-used links like my Talk and Contributions into menu lists is the biggest effect of the new skin for me. My beef is that the order of the items in the menu lists seems to be random.  It doesn't seem to be alphabetical, adaptive, functional or anything but arbitrary.  Please can you make the order alphabetical and/or provide some ability for the user to control and customise the sequence.  If there's something missing in my understanding, please clarify. Andrew Davidson (talk) 14:21, 10 February 2023 (UTC)

Changelog?
I notice many big (realtively speaking) changes happening to Vector 2022 on English Wikipedia today.

I went to check this thread but it only lists updates up until December.

From what I see, 'Tools' now appear in the right column (was empty), and the main menu has increased font size and spacing, and also the empty margin between the menu and main content seems to have been lessened. The menu has a hide option on top and the "back" button (which was actually a menu button) on the top left has been removed.

Where can we see a list of changes like this that are currently being done? Many of the complains that have been made are being invalidated by changes like this happening.—Jetro (talk) 22:30, 23 January 2023 (UTC)


 * Hi @Jetro, for exemple you can follow Desktop Improvements on Phabricator. Please look at this presentation and at this page for more details about the Desktop Improvements in general. About updates, you should be interested also in this update on the Village pump (technical) of January, 20th. The team is still receiving a lot of feedback and improving Vector 2022 according to some community requests. An update in the dedicated sub-page will be published in few weeks as usual. Patafisik (WMF) (talk) 11:30, 24 January 2023 (UTC)

New font size + linespacing for sidebars is very confusing.
Please revert to the original styling of the sidebar, for the l.h. sidebar and for the new r.h.s. presentation of tools.

The current setup is more linespace than the body text, rather than less; and the same font-size as body text. That's hard to read. The lack of different style for the sidebar section-headers makes it hard to find where you are. The extra linespacing also makes it hard to see all options at once... Written up as Sj (talk) 22:31, 23 January 2023 (UTC)

Hot Take: I love the Redesign. But...
Okay, I love the redesign. I've been an early adopter since I heard about it, and seeing it actually put into mainspace is glorious. The latest update (the one that moved the "additional tools" box to the right hand) really gave me a little rush of giddy excitement. Sad to see people don't quite like it, but then again, that might be the doomscrolling I've been witnessing.

However, I have some icks about it.

I feel as though that the ToC navbox should be contrasted with the background, possibly using #f6f6f6 or similar. It should also have a border, colored #d8dbdf or similar. Also, the ToC tab (for small screens) should be circular, similar to the hide bar on en:Chinese Wikipedia with a hint of Material Design's "hamburger menu".

Either way, great job on the work going on! I really wish people could have a more open mind about the new layout. Explodicator7331 (talk) 00:03, 24 January 2023 (UTC)


 * Hi @Explodicator7331 thank you for your feedback. About colors, the Web Team has tested a prototype and collected (and still collecting) feedback to improve the visual design. A very specific request about colors might be better suited to a customization, perhaps? What do you think about this possibility? Please read our FAQ, in particular this section. Patafisik (WMF) (talk) 11:17, 24 January 2023 (UTC)
 * Hmm, I'll try editing the CSS/JS for my skin, and see if I prefer it over the main settings. If I actually think it could come into fruition as a feature, I'll see my inquiry as a serious proposal, as opposed to a silly suggestion. Explodicator7331 (talk) 14:50, 24 January 2023 (UTC)

New screenshots needed.
I thought I'd done something stupid that had altered my page layout today, but after the earlier Vector 2022 I'm now loving the Tools menu being moved from the left side of the page to the right. A great idea to also be able to hide it in with the other 'tabs', too. We now need some new screenshots to reflect the default appearance of Vector 2022, please. Nick Moyes (talk) 00:17, 24 January 2023 (UTC)


 * Thank you @Nick Moyes for your feedback, I reported your request for screenshots to the team. Patafisik (WMF) (talk) 11:41, 24 January 2023 (UTC)
 * @Nick Moyes I would be happy to upload some screenshots for you. Are there any particular things you'd like in terms of projects, articles, etc? AHollender (WMF) (talk) 17:28, 24 January 2023 (UTC)
 * Thanks, AHollender (WMF). At this stage I'm still getting used to things, and haven't got my head around precisely what's going to be outdated. A few years back I spent quite a few days checking and making new images and fixing all the inconsistencies in our en.wiki 'How to' pages when we simply swapped from 'Save changes' to 'Publish changes' (see here). So I suspect there's now a lot of out-of-date imagery and instructions that'll need altering to reflect Vector 2022. It depends whether more layout changing are coming as to whether it's worth doing immediately or waiting a month or two (e.g. the tools menu oving to the right).
 * I do tend to like demonstration images that focus on neutral topics, such as 'The Earth' or a globally-known animal species such as a lion or elephant, but at this stage I can't suggest specifics. What will be key is good nomenclature and categorisation of every screenshot - we have a wealth of old and new images, often shoved all together on Commons, and it can often be hard to work out which are the most up-to-date ones to use. I accept that it's not just examples in English that will be needed, but I can only really comment on my own native language. Nick Moyes (talk) 11:04, 25 January 2023 (UTC)
 * Just to merge information: Nick Moyes suggests here to have also a category on Commons for icons used by Vector 2022 for helping volunteers who will update help pages.--Patafisik (WMF) (talk) 10:32, 1 February 2023 (UTC)
 * @Patafisik (WMF) thanks for linking that.
 * @Nick Moyes ok, well once you've got a list of screenshots you need I'd be happy to help you get them in any way that I can. I'm not sure if my screenshotting abilities are anything special, but happy to lend an extra set of hands : ) AHollender (WMF) (talk) 17:08, 13 February 2023 (UTC)

You promised a skin, you touched the veins
and trampled our hearts. Why, o why, didn't you put it up therenot default for a year? That is what good manners and respect dictate. We would try it out (at all projects) in good faith. Ample time to fix bugs. Ample time to propose improvements. The question would be: Even if you like it or even if you are indifferent to it, do you think, with your experience as editor, Fellow editors of English wikipedia, who say you like it. (I might like things there too). You are the flagship of all projects. Think global. Not just wikipedia. Think of small wikis who have no chance, no power to influence decisions. Please, allow it be non default for a transitional phase. Wikimedia, please, rework it and present it anew. Preferably call it Vector2023, notify the press of your brave decision and let us all forget this unfortunate incident. I am so sad. A wiktionarian Sarri.greek (talk) 04:30, 24 January 2023 (UTC)
 * that it will satisfy the needs of editors of all wikiprojects, all kinds of pages, all languages. Is it tangible to apply this format everywhere?
 * that it will satisfy readers?


 * While no, I'm not the hugest fan of it, it was there in the preferences; this wasn't some random change. Unknown-Tree (talk) 00:55, 25 January 2023 (UTC)
 * Was it, . I never got a message that a trial was commencing (I come from other projects). Thank you, Sarri.greek (talk) 01:05, 25 January 2023 (UTC)
 * I'm not sure if there was a message, but it was definitely in the preferences. Unknown-Tree (talk) 03:37, 25 January 2023 (UTC)
 * Καλημέρα @Sarri.greek. I've seen your user name in many different sections here and on English Wikipedia. Thank you for those. I wasn't sure which of the points you've made so far I should address first, but I'll try with this one.
 * "Why, o why, didn't you put it up there not default for a year?" - as you may find out reading the main project page (Deployment plan and timeline), we began working on this in 2019. Since 2020, this has been the default on a growing number of wikis, and at the same time, it's been a non-default everywhere else. Over time, it has become the most popular non-default skin on English Wikipedia and a number of other large Wikipedias. We've been working with the early adopter wiki communities since 2020, and they've helped us with many decisions and bugs. Recently, after several months of discussions, we have deployed Desktop Improvements on English Wikipedia. Perhaps it's more easily noticeable now, especially for those who don't read Portuguese, Indonesian, French, Hebrew etc., but do read English.
 * Will it satisfy the needs of users (incl. readers) of all wikis - among the early adopter wikis, there are both small and large projects, Wikipedias, sister projects, written in different scripts and different parts of the world... so in principle, yes, this project is dedicated to be working everywhere. But each wiki may need some adjustments, sometimes mostly on our side, sometimes mostly on the community side, sometimes impossible without collaboration. We haven't talked to the Commons community yet. Certainly, we'll need to change something for Wikisource. We still need to discuss adjustments to Wikidata. I see now that the English Wiktionary community will also need to update their custom code. But yeah, we work on this to meet the needs of all or almost all projects. (Also, I encourage you to take a look at the blog post Prioritizing equity within Wikipedia’s new desktop and to explore the Repository tab.)
 * Will it satisfy the needs of all users on those wikis? No, but we don't expect that. Still it will be better than the previous interface which didn't satisfy the needs of users, as our research shows.
 * To make a product without the disadvantages only active editors may help to solve, we need to work with active editors. I'd like to invite you to follow us closely; look at the section Get involved & Contact, and help us with our future projects.
 * Thank you again. Personally, I like answering this kind of questions about the "general approach". Hopefully, this clarifies something. What do you think about my answer? Do you have additional questions? Later this week, I think, we'll post a large update on the English Wikipedia RfC. I recommend opening that page before the weekend! SGrabarczuk (WMF) (talk) 03:03, 9 February 2023 (UTC)


 * Thank you, Sir, for your time. SGrabarczuk (WMF), Apart from my personal opinion, which is anti-commercial.mobile.look, and pro 'least possible design', We have seen banners for wikimania. Banners for 'vote photo'. Banners for Conduct. We have never seen a Banner: In the following months, our pages will have a new look for desktop readers. Please try it out here and... And after it is deployed: Our desktop pages have a new look. Please try it and tell us.. Logged readers may choose ... here, not-logged readers may add ?useskin=(their choice).. or something. These banners should be permanently shown everywhere. For months. I think, it is basic courtesy. Even if only for 1% of readers.
 * Of course I understand that WMF has the right on the skin and all technical issues. I did not imagine that a new look would be applied outside wikipedias.
 * Wiktionaries (at least el.wikt) would have to rewrite many pages to also show _TOC__ manually (present at hundreds of pages like Appendices). Also, we will have to add the addresses of recommended interwiki links in the See also section. We already show the mother language wiktionary. Dictionaries are different from encyclopaedias. Thank you.  Sarri.greek (talk) 09:13, 9 February 2023 (UTC)
 * Thank you @Sarri.greek. We have been running banners on Wikipedias (English, Greek, Spanish, German, and others) for many weeks since May 2022. Perhaps for some reason you haven't noticed them? Anyway, it is because of those banners that so many individual users have opted in. If the numbers of edits you've made across wikis indicate how much time you spend on a given wiki, the reason why you haven't noticed the banners is because we haven't run them on Greek or English Wiktionary. Simply, we're focusing on Wikipedias now, and because Wiktionaries may be different in some ways, we think we'll focus on those issues later. But shortly before we know we have the capacity to talk to the sister project communities, we will turn these banners on. (We can't run them for months continuously because it's a practice not to run more than two different banners for the same audience at the same time.)
 * It's interesting that you mention the TOC "magic word" and other potential issues for Wiktionaries. If you have the time, let's perhaps take notes on what, according to you, should be adjusted on Wiktionaries, on a separate page? This way, it will be less likely for your comments to be lost in the archives.
 * What do you think about that? SGrabarczuk (WMF) (talk) 01:44, 10 February 2023 (UTC)

Some examples
Please compare at both vectors. el.wiktionary appendices (about Tables of Contents) wikisource el./fr... (about ?match) While changes and fixes are happening in real time, we cannot be sure which of our tests & comments is dated or not. Please keep announcing versions of that vector so that we re-test our pages to see what is solved. Plus: Contents should be immediately viewable. This is their natural place. To seek them is not. Thank you Sarri.greek (talk) 06:57, 24 January 2023 (UTC) The sticky line: it cannot be different from what it is initially: to recongnize it as 'the same thing'. Searchbox cannot 'walk' across the page. Sarri.greek (talk) 07:11, 24 January 2023 (UTC)
 * The ToC is in the div=right Used in numerous non lemma pages (talks, rooms, appendices). E.g. all declension tables lead to an appendix like this one OO the hidden Contents are not numbered 1. 1.1. 1.2. ...,
 * In this grammar appendix, it is written manually. Glad to see NOTOC works.
 * https://el.wikisource.org/wiki/Τα_ψηλά_βουνά/Το_ξεκίνημα   This one has languages with arrows opening frames. I cannot see the arrows to get
 * https://el.wikisource.org/wiki/Τα_ψηλά_βουνά/Το_ξεκίνημα?match=fr
 * now click the blue link Τσιριτρό which directs to https://el.wikisource.org/wiki/Τα_ψηλά_βουνά/Τσιριτρό?match=fr
 * And now, how does one go back to 1 language..  The 'match' is now rare but very useful. All wiktionary 'quotations' link to wikisource. I presume, wikipedia's too.

Please give a democratic Vector2023 for all readers
It was explained that the Wikimedia Foundation, has not released the funds needed for buying the equipment necessary for a button that switches back and forth for Classic VectorLegacy (2010) and the new Vector 2022 (for unlogged readers). Please, board of trustees. Give us a democratic Vector 2023 or 2024, Give us ample time to adapt. Thank you. Sarri.greek (talk) 16:38, 21 January 2023 (UTC)
 * A democratic principle in designing would be: Allow maximum possible freedom to the users. Make it possible to not impose sizes, lengths. Allow everyone to feel comfortable. Do not force them to log in.
 * Transitional periods for switching environments, allow some months of easy choice between old and new.
 * Uniformity between projects is not strict. The necessities and idiocyncracies of each project, each language are different.
 * Uniformity between mobile view and desktop, is not desirable to many. Also, the rapidly advancing technology will probably set new challenges in the near future.


 * Hello again @Sarri.greek. From our perspective, we are offering the freedom to the users. In the FAQ (Why don't you provide preferences to choose between different versions of the features? as well as Why are there no preferences for anonymous users? and other sections), we've explained what are the limitations to this. I hope I've addressed the remainder of your concerns above. SGrabarczuk (WMF) (talk) 13:27, 10 February 2023 (UTC)
 * Now there are many solutions at the internet. I have not downloaded one yet, so I keep adding ?useskin=vector or other (because I view wikipedias unlogged). Thank you SGrabarczuk (WMF).  Sarri.greek (talk) 13:37, 10 February 2023 (UTC)

Some opposes and supports with same argument

 * Moved at https://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Rollback_of_Vector_2022#Some_opposes_and_supports_with_same_argument

Language-switcher pushing translations
I've been using the new layout for quite a while and haven't had any big issues with it, until now. I was quite surprised to see that the language-switcher now suggests that the user/reader can create a translation if the article doesn't yet exist in a specific language. Has there been discussion about this feature, and if so, where could I find it?

The Content translation tool (CX) is not a universally loved tool, and I think it's quite problematic that it is suggested to pretty much anyone who clicks the language-switcher in any wiki that has Vector 2022 on it. "You can translate it in minutes!", it claims. There are often quality issues with CX articles, and the worst problem is that inexperienced users are not told that their CX creations might not be well-received by the community. kyykaarme (talk) 13:51, 24 January 2023 (UTC)


 * Thank you @Kyykaarme for your feedback, you are pointing out some interesting issues. As specified in the Content translation project, section Purpose of the tool, the tool should properly communicate the purpose of translations in Wikimedia context and help the user to avoid bad quality translations. I reported your comment to the Wikimedia Language engineering, if you prefer you can leave a feedback also here. For more information about the Language switching as part of the Desktop Improvements project look at here, for providing an entry points to translation see this task and this one. Patafisik (WMF) (talk) 12:42, 2 February 2023 (UTC)
 * @Patafisik (WMF) Thank you for the comment and the links! I might look into it more later. kyykaarme (talk) 20:39, 5 February 2023 (UTC)

Option to auto-hide content bar
I do quite like the new redesign layout in general but the content bar to the left of the screen irritates me for some reason. It just doesn't seem to fit and is static while scrolling the page so it is quite jarring as well. I find it distracting when reading, so I often have to hide the content bar by clicking on it to hide it away, so I would like to have a toggle to auto-hide the content bar. DR333AD (talk) 18:58, 24 January 2023 (UTC)


 * Hello @DR333AD! Thank you for reaching out to us here. Are you referring to the table of contents, so a list of headings, or the sidebar, a list of links to other pages on the same wiki? You may hide both of those menus: in the table of contents, there's a link [] next to the "" label, and in the sidebar, the same link is next to the "" label. If you hide either of those, it should stay hidden even if you go to a different page or refresh the page. This only works for logged-in users, though.
 * Does that help you? SGrabarczuk (WMF) (talk) 00:07, 9 February 2023 (UTC)
 * Doesn't really help me since I usually have either multiple tabs opened at ocne or come back to Wiki randomly. Also, I often use devices that I don't want to be logged in either (public devices with multiple accounts), so an option that saves the preference to a browser instance would be nice. DR333AD (talk) 16:21, 10 February 2023 (UTC)

The Redesign Does Not Work for Wikipedia
Hello,

Like many people, I recently pulled up a Wikipedia page and immediately felt something was off. The new redesign is definitely a big departure from Old Wikipedia, and I've been trying to figure out whether my and many other people's distaste for it was due to an aversion to change or an actual design issue with the new look. While I can appreciate the intent behind the redesign, to improve readability and comprehension by shortening line length, I believe this mission fundamentally misunderstands how people use Wikipedia. People don't go on Wikipedia and sit down and read the full article on a topic, like they would on the New York Times (an example used by admins to support this design) they quickly skim an article for information relevant to the purpose they came on Wikipedia for. Therefore, the primary motivation behind the design of a Wiki page should be on making it as easy as possible to find relevant information, i.e. skim the page. The old design did this extremely well, the page's width being filled with text, and the new design fails spectacularly, requiring way more scrolling and fitting less information on the page at once. There are other issues with the new design, but those have been brought up already. Wikipedia's design should fit Wikipedia, not follow the example of other sites with completely different purposes and use cases. BringBackOldWiki (talk) 00:56, 25 January 2023 (UTC)


 * Hello @BringBackOldWiki. Thank you for your feedback, you can personalize your experience and use the full width. Zapipedia (WMF) (talk) 16:15, 25 January 2023 (UTC)

Open RfC
For those weighing in here on the theme, you may want to weigh in on the open "Request for Comments" linked to here: https://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Rollback_of_Vector_2022#RfC:_Should_Wikipedia_return_to_Vector_2010_as_the_default_skin? 192.184.150.142 03:38, 25 January 2023 (UTC)

Jan 23 update from Web team
Hi all,

if you haven't still read it please look at the latest update from the Web Team here.--Patafisik (WMF) (talk) 14:33, 25 January 2023 (UTC)

Just for entertainment...
While switching back and forth in "appearance" and trying out some of the other/older alternatives, I noticed: Is V22 becoming more or less like the timeless skin? Though I was initially liking V22 but really don't what's done with the toc, I like timeless more than V22 in it's current form. Strange feeling. Regards HirnSpuk (talk) 07:23, 26 January 2023 (UTC)


 * Hi @HirnSpuk. That's interesting. Have you perhaps figured out what exactly has made you change your mind? (And yes, V22 feels a bit more similar to Timeless now with page tools on the right side of the screen.) SGrabarczuk (WMF) (talk) 00:00, 9 February 2023 (UTC)
 * @SGrabarczuk (WMF), really? You were part of the process, and you answered to some of the things I said. I posted what's bugging me on these occasions:
 * 2022-04-28: Topic:Wuiv4dwq6ngqed62, I even told you personally here almost a year ago.
 * 2022-06-22: Talk:Reading/Web/Desktop_Improvements/Archive4
 * 2022-07-20: Talk:Reading/Web/Desktop_Improvements/Archive5
 * This all led to 2022-09-21: Talk:Reading/Web/Desktop_Improvements/Archive6, where I pinged you.
 * I commented to other points on 2022-09-22: Talk:Reading/Web/Desktop_Improvements/Archive6
 * and: Talk:Reading/Web/Desktop_Improvements/Archive6, here I brought an example for the "underlying concern" that I think is a problem here.
 * and proposed a compromise the same day: Talk:Reading/Web/Desktop_Improvements/Archive6
 * I'm still trying to make my point: 2022-10-13: T317818 and my following comments on this discussion
 * So, you asking what changed my mind is a little confusing to say the least. Simplest example, what changed my mind: I couldn't use the TOC to find this paragraph, when I opened this page, I needed Ctrl-f.
 * Side note: I've never seen the page tools moved. Not here, not in english wikipedia not in my "home-wiki" wbde, while using V22.
 * I think a new skin would be beneficial, I like most of the things done with V22, but I think there should be "a step back". Reading RfCs on english wikipedia and the general "bulkiness" right now doesn't feel right. It's confusing... But I'll get used to it somehow, and if I don't I always can revert back to the old skin. The sad thing is (and always will be) I need to explain this stuff to readers and new users, and right now, I don't know how I will manage that in the future. But at least the problem isn't that big in smaller wikis like wbde. Regards HirnSpuk (talk) 21:21, 11 February 2023 (UTC)

Contrast and spacing
Coming from en Wikipedia here. I kind of like the change with the table of contents so I'm interested in using this new look. However, I find it hard to read the content when it isn't separated from everything else. The old layout put everything outside the article content in a grey (or blue) background – is there any way of doing this in the new layout?

Also, I feel the left sidebar takes up much more space than it needs to. Is it possible to adjust its width to be similar to what we had before.

Thanks. –CheChe (talk) 19:41, 26 January 2023 (UTC)


 * Hi thank you for your feedback. About the background color, discussions are going on and you can follow two tasks on Phabricator: T259240 and T328111. For more information about Visual Refinements, please look at this page and this one. Patafisik (WMF) (talk) 10:09, 7 February 2023 (UTC)

How to change the logo to a temporary one?
To change the logo image,wordmark and tagline, which CSS file should be changes ? Global.css ? Lotusccong (talk) 06:37, 27 January 2023 (UTC)


 * https://m.mediawiki.org/wiki/Skin:Vector/Customizing_the_logo_for_special_events is probably the most up to date reference. Hope that helps! Jdlrobson (talk) 22:32, 27 January 2023 (UTC)

Separate scrolling for the TOC bar is not helpful
Hopefully these criticisms are constructive. I'm not here just to harangue you guys or send abuse.

It's much harder to find things in the TOC than it used to be for the following reasons:

1. The TOC sidebar doesn't appear at all on some pages until you scroll down. If I'm looking for something specific, I can't even see where to look for it until I scroll.

2. Long TOCs (like the one on this page!) are difficult to use because you have to scroll through it to see it all. It's not possible to see the whole thing at once.

3. If you briefly navigate away from the TOC, e.g., to scroll on the main reading area (IDK what to call this, apologies), the TOC resets, making you lose your place again, so that you have to scroll through it all, again.

4. Because the TOC is narrow, long headings are hard to read, making it still harder to use. This is ironic because readability is a key reason that's been given for the re-design: yes, very long lines can be hard to read, but so can very short ones!

5. The contents aren't numbered so it's difficult to know where you are. This makes it especially annoying that the table insists on resetting itself!

I don't like having to log in separately on every sister project, just so that I can make the page not broken. And I say 'broken' because, when I saw the new design, I genuinely didn't realise it was a new design at all: I thought something had gone wrong with my browser settings. It didn't occur to me that it could be a deliberate choice to make Wikipedia look as it now does. I may be in the minority but I do think the designers should reflect on that. I think even if I were aware the change was coming (which even as a daily Wikipedia user, I wasn't), I wouldn't have realised this was it. (This is strictly a separate issue, but I'm raising it here because I don't want to create yet another heading which will be impossible to find in the TOC sidebar!)

Finally, there's a note at the top of this page asking me to 'link a username' if I want to notify a member of staff (which I do, because I'm genuinely trying to be constructive and help the project), but I don't know how to do this. This is, ironically, a very good example of the failures of communication around this whole redesign. Do I type @OVasileva? Do I type User:SGrabarczuk_(WMF)? I can see what other people have done but I have no idea if this did successfully notify the staff members in question. — Preceding unsigned comment added by FrankSanPod (User talk:FrankSanPod • Special:Contributions/FrankSanPod) 11:35, January 27, 2023 (UTC)


 * I aggree, FrankSanPod. I come from el.wiktionary and Contents are very important for us to see immediately, full and numbered. You can change your preferences for all wikiprojects here
 * https://www.mediawiki.org/wiki/Special:GlobalPreferences#mw-prefsection-rendering
 * Remember to scroll down the page to click Save
 * Also, we sign at Discussions with  at the end. Thank you for your comments!  Sarri.greek (talk) 02:20, 28 January 2023 (UTC)

Re: How the new Wikipedia design focused on accessibility
(Reposted from How the new Wikipedia design focused on accessibility.)

It's very significant that accessibility testing was performed, thanks for stressing this. "Overall, the results were positive, and we saw noticeable improvements comparing the original experience with the new." Can you clarify where this finding comes from?

T263834 doesn’t mention anything of the sort. T323634 doesn’t mention any question about the overall accessibility improvements; it mentions 4 specific points on which feedback was sought, of which 2 received positive feedback. No positive assessment is mentioned for the remaining 2 points, which are arguably the most impactful changes in the new skin: the table of contents and the language selection.

Not quite a ringing endorsement. Nemo 18:46, 27 January 2023 (UTC)


 * I see the report is at Reading/Web/Desktop Improvements/Repository/Accessibility testing. It confirms what above: mixed ratings for TOC and language selection. Nemo 11:10, 28 January 2023 (UTC)

Disabling Limited Width Mode leads to horizontal scrolling
Hi, I've disabled Limited Width Mode and I've hidden each of the sidebars to permit full-width text display from this English Wikipedia talk page, and it's still got a horizontal scroll bar for about 10% of the overflow text to the right. w:Talk:Byzantine Empire

This is uncommon; not all talk pages overflow like this, so I suspect it is due to some object on the page forcing a width beyond my web browser's ability to display.

Windows 10 Professional with all updates; Google Chrome Version 109.0.5414.75 (Official Build) (64-bit), 1920x1080 full-screen resolution, maximized browser window. Elizium23 (talk) 22:37, 27 January 2023 (UTC)


 * Hi @Elizium23, thank you for your feedback, this task was closed recently about a similar issue. Are you still experimenting this problem? For debugging javascript gadgets, can you verify if this is still happening adding   at the end of the URL? Patafisik (WMF) (talk) 09:58, 7 February 2023 (UTC)
 * @Patafisik (WMF), thanks for the reply and the reference! No, I have not experienced this basically since I reported it, and even on the page I linked, the problem has gone away, so I'd say that this was precisely the fix we needed. Cheers! Elizium23 (talk) 12:51, 7 February 2023 (UTC)

Why fix what wasn't broken?
As many others have said in the threads here, I made an account after all these years of using wikipedia simply to complain about the new layout and view the old one. Vector 2022 looks atrocious. Gives me a headache just looking at it. The old layout was in use for a decade for a reason: it worked. It was simple, clean, functional, and easy on the eyes. The new one looks like garbage. Please reevaluate forcing this garbage on people. 2600:8800:22C:E00:D5A2:9E15:C7CE:BAFC 05:10, 28 January 2023 (UTC)


 * Hello! Thank you for sharing your viewpoint. I understand that you may have other needs and this interface may not be the best for you. I'd like to encourage you to read our documentation pages, such as the FAQ, to explore how many different tests we have performed and what were our findings (for whom the previous interface didn't work and why). That said, we will continue working on the skin, and we hope to make more improvements, some of which you may like. For instance, this may include the dark mode. SGrabarczuk (WMF) (talk) 02:07, 9 February 2023 (UTC)

Better insight about the "Feedback summary" section
I don't know why but my question was archived two times without having been answered so I'm posting it again.

It was archived with these and.

Moved from Topic:X8tm9pidprwslpdt

Hi, since the new page tools are going to be implemented in the next weeks into the Vector 2022 skin I was wondering if it would be possible to have a better insight of the data roughly presented in the "Feedback summary" section in the Prototype testing with editors paragraph.

IMO a presentation of the data with percentages and numbers like it was done in this paragraph would be clearer and more transparent than words like "the majority", "split pretty evenly" and "many people".

Thanks in advance for your disponibility and your work.

Please ping me when you'll answer to my question. WikiLuke (talk) 12:41, 28 January 2023 (UTC)


 * Hey @WikiLuke! I'm really sorry this happened to you. I've shared your suggestion with my team mates. SGrabarczuk (WMF) (talk) 23:38, 8 February 2023 (UTC)

wardrobe is a poor metaphor, wiki is a workbench
Clothes you use once a day, but when you work all the time, you need everything to be easily accessible. Look at what the workbench looks like:

https://upload.wikimedia.org/wikipedia/commons/1/11/Work_area_of_a_jeweller.jpg

The "argument" about consistency with the mobile version is completely pointless. Desktop and mobile are completely different environments that work differently, and mobile is much more limited. Trimming the desktop version to the limitations of mobile systems is counterproductive. Freja Draco (talk) 14:17, 28 January 2023 (UTC)


 * Hi @Freja Draco! Thanks for your comment and for the link to the file. You're right, we might use a different metaphor. In addition to the wardrobe, in presentations we've been giving at events, we've been using a metaphor of a library vs. an airplane cockpit. I suppose a workbench would work just as well. Anyway, the point we tried to make is that there are users who need many tools because they work on wiki, and a different audience needs to focus on content because they simply want to learn. And since the goals of the project are to improve the latter without harming the former, there are some tradeoffs to be made.
 * Regarding the consistency with mobile, we didn't want to trim the desktop version to the limitations of mobile. There are other similarities we need to bear in mind. For example, the styling of links, icons, etc. When people interact with the same website on mobile and on desktop, they should understand that this is the same website. I'm not sure if this is the best thing I may be pointing at; I've asked the team mates to give better examples. SGrabarczuk (WMF) (talk) 23:57, 8 February 2023 (UTC)

Link color
I don't hate the new layout; I've known it was coming for a long while now, and while it is rather jarring, I think I'll eventually get used to it if forced to do so – I prefer the older layout, though, out of strong familiarity.

I do have one very concrete qualm, though: of reading Wikipedia with the old skin (and the one before Vector, also) very strongly conditioned me for two things: inside-wiki links are a darker blue, this one, #0645ad, to be exact, and external links are a lighter color, #36b. External links are also followed by a small squared-arrow icon, but for me the strongest identifier has been the color: dark, high-contrast for wikilinks that I'm probably interested in, and light, faded-out blue for external ones that I can skip over with my eyes. The new skin makes all links the same color as external links, and it's tripping me up. The slight color differentiation was an excellent usability feature, and I just don't see why that needed to be given up along with everything else.

(Visited links used to be #0b0080, while they're now #795cb2 – I don't hate this cange as much, visited links were always a bit hard to see (although that's kind of the point, since they've already been read), but it's still a bit weird having them be so light in color, with so much less contrast between text and background.) All the best, Oatco (talk) 22:42, 28 January 2023 (UTC)


 * Hi @Oatco, thank you for your feedback. The new external link icon was deployed to follow the Wikimedia DSG's icon guidelines (T261391), link colors to fit the Web Content Accessibility Guidelines. More information about the choice of colors here on the prototype testing page, here with the answer of AHollande (WMF), and here on frwiki for a suggestion of customization, hope this should help. Patafisik (WMF) (talk) 09:50, 7 February 2023 (UTC)

Inconsistent edit page width
Vector-2022 has max-width limits for large screens. But on edit pages, unlike read pages, max-width limit is disabled and page width is stretched. Why edit pages are exempted from max-width limits? Moreover, when I preview or view diff when editing, max-width limit is enabled still even on edit page yet. I think page width should be consistent. Gustmd7410 (talk) 15:50, 29 January 2023 (UTC)


 * Hi @Gustmd7410, thank you for reporting this issue, it was pointed out few days ago and a task is already open on Phabricator. Patafisik (WMF) (talk) 08:23, 31 January 2023 (UTC)
 * Thanks for information. But the task already open only points that preview page ignores disabling limited width setting. I meant that edit page without preview ignores enabling limited width setting. I think my problem and the task already open are similar but different problem. The existing task is trying to fix by removing max-width of preview section even though the page's max-width was disabled and it doesn't fix my problem. "vector-feature-limited-width-disabled" class of body element should be removed on edit page when limited width setting was enabled. Gustmd7410 (talk) 09:12, 31 January 2023 (UTC)
 * Thanks for information. But the task already open only points that preview page ignores disabling limited width setting. I meant that edit page without preview ignores enabling limited width setting. I think my problem and the task already open are similar but different problem. The existing task is trying to fix by removing max-width of preview section even though the page's max-width was disabled and it doesn't fix my problem. "vector-feature-limited-width-disabled" class of body element should be removed on edit page when limited width setting was enabled. Gustmd7410 (talk) 09:12, 31 January 2023 (UTC)

Tables
Hi! I've previously mentioned that I'm actually quite fond of the new look, but if I had to have one complaint, I'd say something needs to be done about tables. From my experience these past few days since the change, most articles with wikitables have seen those tables become really squished, which is just plain unpleasant to look at (Example). I'm not sure how Wikipedia handles tables, but perhaps adjusting them to simply display at a smaller size would be helpful. Krisgabwoosh (talk) 18:50, 29 January 2023 (UTC)


 * Hi @Krisgabwoosh, thank you for your feedback. This issue is concerning more skins then Vector 2022 and there is not a easy solution, discussion is still going on. Please look at this task on Phabricator about it, especially this comment. Patafisik (WMF) (talk) 08:35, 31 January 2023 (UTC)

Suggestion for "in other projects"
I think the in other projects menu would be better located beside the "Add languages" button as these serve broadly the same purpose - finding content on the same topic on other projects. Garuda3 (talk) 21:40, 29 January 2023 (UTC)

Watchlist - "Live updates" button gets hidden unnecessarily
In my watchlist views, there is a list of filters and controls for changing them, and this box contains a "[Hide]" link which allows me to collapse the box, which is large and usually unnecessary. Unfortunately, the "[Hide]" control also affects the "Live updates" button for no good reason. This button could easily be placed to the right of the hidden filter box. But it is hidden and the user then loses control of the Live Updates feature with no explanation.

"Live updates" seems to be an entirely separate feature from the application of filters. It does not make sense to group this in the same "Hide" collapsible box, especially because a hidden filter box leaves plenty of lateral space for the button. Please ungroup this so that the user may retain control of Live Updates even while others are hidden. Elizium23 (talk) 13:39, 30 January 2023 (UTC)


 * Hello @Elizium23. Thanks for sharing this. The problem you've described appears in other skins, not just Vector 2022, doesn't it? I think it may not only be beyond the scope of this project, but it perhaps belongs to a different team overseeing the code of watchlists. SGrabarczuk (WMF) (talk) 02:13, 9 February 2023 (UTC)
 * @SGrabarczuk (WMF), thank you for your prompt reply. Yes, I understand that this is more of a deeper interface issue and watchlist-specific. Is this a job for Phabricator, then, you think? Is that where core watchlist code is maintained? I'll poke around a bit. I'm a noob over there. Elizium23 (talk) 10:37, 9 February 2023 (UTC)
 * It's ok, it doesn't matter if you're a noob to these things :) This would be documented on Phabricator anyway. The problem I'm pointing at is that it would be a job for someone else. I checked out in the meantime and confirmed. It'd be a job for the Growth team if Growth weren't all busy with their most important job - Newcomer experience. I'll just ping my colleague working with Growth - @Trizek (WMF), FYI! SGrabarczuk (WMF) (talk) 00:50, 10 February 2023 (UTC)
 * Thank you @SGrabarczuk (WMF) for the ping.
 * Hello @Elizium23. Back in the days, when we designed this interface, we received feedback regarding the space the new filters take on the RC page. As a consequence, the solution offered (and prefered) was to hide everything. Hence, all components are hidden: the filters, the edits/days selection and the live update button.
 * I documented your idea. However, I can't promise anything regarding changing it. First, because there are no plans at the moment to change RCs and Watchlist (Growth only takes care of major, impacting bugs regarding RCs and Watchlist), and also because some other users might not like this change (as they didn't liked it when we worked on it). I wish you to see your idea considered when some efforts will be put back again on this interface!
 * Trizek (WMF) (talk) 12:28, 10 February 2023 (UTC)

Uploads link gone
Commons New Look lacks "Uploads" link


 * 1) Visit https://commons.wikimedia.org/wiki/Main_Page logged in.
 * 2) Look for the Uploads link (https://commons.wikimedia.org/w/index.php?title=Special:ListFiles/...

There is none. There should be one.

Sure "Switch to old look".

Anyway, all the emphasis is on Uploading things, but never looking back to see what you uploaded.

In Preferences there is a whole section for Upload Wizard, but no way to get a link to click to see what one already uploaded.

Sure, "Use the browser's bookmarks." Jidanni (talk) 05:47, 31 January 2023 (UTC)


 * Hello @Jidanni. Are you still experiencing this? When I go to Commons and use Vector 2022, I see the "Uploads" link. If you don't, please add ?safemode=1 to your URL and then check, and if it's not there, tell me what browser and operating system you're using. SGrabarczuk (WMF) (talk) 23:36, 8 February 2023 (UTC)
 * Thanks. I see it today. Jidanni (talk) 04:53, 19 February 2023 (UTC)

Why is the main menu hidden by default?
This is not covered in the FAQ.

Why is the main menu hidden from the main page non-registered users? What is the reasoning for that? Jetro (talk) 02:08, 1 February 2023 (UTC)


 * Hi @Jetro, thanks for reading our documentation and asking us here!
 * This is explained in detail on the page about the collapsible sidebar feature. Essentially, readers mostly don't use the sidebar, and if they're able to collapse it, they mostly choose to do that, and they rarely un-collapse it. From the technical perspective, the state of the un-collapsed sidebar is a preference, and logged-out users don't have preferences, so the un-collapsed state isn't saved anywhere for them.
 * Regarding the risk of some important things being missed if users don't see those links - as part of the Core Experiences group, we're working on exposing the community side of the wikis. Growth is working on visible points of entry to contributing, and after Vector 2022, we'll try to make further changes to the interface to, metaphorically, "open the kitchen" of Wikipedia. For example, we're thinking about a text "recently edited by X" instead of the enigmatic "View history". But the future project is not something we're discussing in detail since our work on the Desktop Improvements isn't done yet.
 * I hope this answers your question! SGrabarczuk (WMF) (talk) 23:33, 8 February 2023 (UTC)

I can't change the theme
Hello,

I have a wierd issue, whenever I change the theme, the theme I've choose last for 1 second and then goes back to the old one.

Did anyone knows how to fix that ? 91.206.189.246 10:42, 2 February 2023 (UTC)


 * Hi, thank you for your feedback, can you give us more details? Can you describe your configuration (browser, OS, etc.) and how you change the theme, and what happens, step by step? Please look at this task on Phabricator about the persistent settings and check if your problem should be described and resolved by this task. Patafisik (WMF) (talk) 09:32, 7 February 2023 (UTC)
 * Hello, I have find the problem, it was due to a chrome extension ! (odern for Wikipedia
 * MaitreGuigz (talk) 15:10, 7 February 2023 (UTC)
 * MaitreGuigz (talk) 15:10, 7 February 2023 (UTC)

Jan 31 update from Web team
Hi all,

if you haven't still read it, please look at the latest update from Web team: the persistence for fixed width for all users is coming this week.--Patafisik (WMF) (talk) 12:29, 2 February 2023 (UTC)


 * Why are you ignoring the majority of Wikipedia users who DON'T WANT THE NEW LAYOUT? Why are you bandaiding these features when in the big picture, a big majority don't want this layout-change *AT ALL*! Not ONCE have you acknowledged the critizism from users regarding shoe-horning a design far from finished! Fixed width is only one of many complaints, why aren't you honouring the majority of voters who DON'T WANT THE VECTOR 2022 DESIGN AT ALL!! The default layout for everyone logged-in or not, should be Vector 2010.. Vector 2022 should be OPT-IN with a big banner. You guys are professionals at skewing results in your favour, if you'd actually made a vote for EVERY WIKIPEDIA USER, LOGGED IN OR NOT, you'd get humiliated in the results.. what a sham! Holundiman (talk) 13:25, 4 February 2023 (UTC)

radical idea
hi.

latest announcement ("Desktop improvements. A new change is coming!") says:

".... This change also addresses the concern for the location of the table of contents. Previously, some editors using an earlier version of Vector 2022 told us that because the table of contents appeared below the sidebar, it was placed too much down below the page. After this change, the sidebar will be shorter...."

here's a radical idea: how about bringing back the ability to _fold_ the different sidebar sections?

we had this in original vector for a long while, but at some point (around 2014?) this was removed, and i've been missing it ever since. never understood the rationale behind this removal - it was good UX, and we actually have it now for the new TOC, when there are "subsections". why not for the menus too?, קיפודנחש (talk) 21:41, 3 February 2023 (UTC)
 * Hey קיפודנחש. Thank you for your suggestion. We have noted that this is a possibility (T318168) but right now, it seems that we don't consider this as a priority. I've copy-pasted your comment into a comment on Phabricator - perhaps this would initiate a discussion. SGrabarczuk (WMF) (talk) 21:34, 9 February 2023 (UTC)

Preference toggle for article preview fade in animation/fade in rate adjustment
Hi, I really like the visual and accessibility improvements incorporated with the new Vector 2022 theme, however I've noticed that hovering over a link to preview an article feels sluggish and unresponsive in comparison to the legacy Vector theme. In relation to accessibility, animations triggered by motion such as moving a cursor over a link to display may be problematic for people with motion sensitivities. Perhaps a more immediate or subtle fade in effect could alleviate both of these issues? Better yet, an option to turn off all animations on the website entirely would in my opinion be a positive step forward. 2001:BB6:7A0C:5A58:7C32:BD56:5D3C:17AD 18:12, 4 February 2023 (UTC)


 * Thank you for your feedback. At the user Preferences, in the Appearance tab, is it possible to disable the page previews. Zapipedia (WMF) (talk) 10:21, 9 February 2023 (UTC)

“In other projects” in “Tools”?
Love that page tools have finally been moved to their own menu!

However, I’m not sure “In other projects” is in the right place. Sure, these links are specific to the current page, but they are not tools for editors, not even tools at all, they are navigation links, mostly for visitors that won’t open that tool menu. In the medium term, I think finding a better place for those, along with a better way to think of cross navigation between projects, could be necessary. The closest feature that has already been redesigned is the interwiki, with links between languages but within the same project, with the nice new language selector. One direction to go could be to have a project selector next to it? Just an early thought. At least I think these links are not discoverable enough by readers now that they are in the page tools menu. Nclm (talk) 16:08, 6 February 2023 (UTC)


 * Thank you very much for sharing your feedback @Nclm. Zapipedia (WMF) (talk) 08:58, 13 February 2023 (UTC)

Other option for borders and backgrounds?
I’ve seen quite many comments here and there from people who find that the all white pages, without delimitations, makes it hard to mentally process the interface: what’s the article, what’s around, etc.

I remember from the Visual refinements stage that there were a few options, notably number #9, that were addressing this issue quite successfully.

I do like option #1 myself, but I do agree that #9 creates a very nice demarcation between content and container, as well as feeling more “Wikipedia” (which almost always had a white article page over a gray background). Option #9 also got the most votes.

I’m wondering if it would be beneficial now to reconsider going for #1, and to implement something akin to #9 instead.

Alternatively, we could imagine that #1 would be the default for MediaWiki, and #9 the default for Wikimedia projects. It would create a nice distinction between random other wikis that just happen to run MediaWiki (and also provide them with a blank state on which to customise), and actual Wikimedia projects (which would look a little bit more “traditionally Wikipedia” with the gray around the article). Nclm (talk) 16:24, 6 February 2023 (UTC)


 * I made myself a rough userstyle for trying out something like this, so I thought I could share it here maybe :)
 * Preview:
 * Code: meta:User:Nclm/global.css
 * Nclm (talk) 20:58, 10 February 2023 (UTC)
 * Nclm (talk) 20:58, 10 February 2023 (UTC)

Full width toggle is great!
I liked everything about Vector 2022, even the table of contents, now that it's always there maybe I might use it for once lol. Now both wiki languages I use (French and English) look more consistent now.

I just discovered the Full-width toggle and it's a super convenient feature. I retract all my previous complaints about the design. I don't think this was part of the original release, but if it was I don't think I noticed. Nor did I know you could revert back to the old skin— I had been using a janky browser extension to modify the CSS sadly.

Hopefully most users' grievances will so easily resolved by the FAQ page... probably not but it did for me!

Symphoricarpos albus (talk) 17:50, 6 February 2023 (UTC)


 * Hey @Symphoricarpos albus. Thank you for your kind comment. Indeed, this wasn't part of the original design. We built it last year. Thanks again! SGrabarczuk (WMF) (talk) 23:10, 8 February 2023 (UTC)

The new design is a nightmare! Please revert to classic design
The new design is a horrible mess for a multitude of reasons well explained by many users above and elswhere:
 * unused whitespace over half the screen width wasting resources, hardware, energy, money and sympathy of the readers
 * diffuse page layout, no guidelines or orientation lines for reading, very bad page overview and orientation
 * buttons, menus and interaction elements erratically scattered all over the page/screen
 * more clicks neccessary for accessing menus and other features (as for restoring page usability)
 * ... and much more!

Trying to circumvent some of the problems caused by this horrible design and broken defaults by adding even more complexity to this mess by just somewhere adding a few more buttons as for for skin selection, textwidth, or else does not help at all!


 * For just reading a page as Wikipedia without neccessity for interaction I do not want to log in for privacy and further reasons - and this should not be neccessary!
 * I deeply hate the new habit on Wikipedia of forcing "page previews" to popup everywhere, where my pointer happens to accidently touch one of the countless links on a wikipedia page, thus completely blocking my view to the page and making it impossible to read. For preventing these horrible popups as a non-loged-in user I *have* to disallow scripts on Wikipedia (fine with me - I generally like to disallow scripts if they are not needed for good reason; it also makes the pages faster)
 * with scripting disallowed I do not get any of your fancy added extra-buttons scattered over the page as for full-width, etc. for partly restoring the usability of the page for me.

All the above was not any problem with any of the previous designs!!!

Please refrain from unilaterally forcing this horrible new design on Millions of Wikipedia-users which are very happy with the excellent, fully funktional and beautiful classic design and just love Wikipedia with its well-kown characteristic wonderful face. 77.12.135.231 07:48, 7 February 2023 (UTC)

New sidebar terrible, not tested properly
I don’t usually use Vector 2022 so I didn’t notice this until a couple of days ago when I happened to land on the English Wikipedia, but the new sidebar is terrible; and it was not tested properly.

On portrait monitors (very common in editorial circles) the content area is now so narrow that on a 1080p monitor, the first screenful of en:Xhosa language has measures that are only about 25 characters wide. The measure is so narrow it feels like reading a newspaper.

On portrait monitors, Vector 2022 was already borderline unusable for some languages; with this new sidebar it’s unusable even for English. I’d suggest developers dedicate a monitor to portrait orientation to make sure their designs still work when hardware screen width is only 1080px.

More generally, I’d suggest developers not use the latest and greatest hardware; normal users don’t have super-wide screens. Al12si (talk) 00:59, 10 February 2023 (UTC)

Large margins and gaps on 1280x1024
I have 1280x1024 monitor and I can say gaps and margins are too big. While I personally can agree that on a widescreen it is better to have narrow centered content, on a "box" screen this feels less readable. With the old design on my monitor I get the best reading experience - content is not wide and is not narrow. I tested the new design on widescreen (with Firefox Devtools help) and the article width is perfectly good for me as the old design on my real monitor. Though I can make a userstyle for it I'd like the new design by default get rid of (or make smaller) these unnecessary gaps (1, 2, 3 on a screenshot - https://imgur.com/a/2lju5cJ ). 188.168.117.1 05:09, 10 February 2023 (UTC)

When will the blue pulsing dot under the Preview tab on the source editor be removed?
When will the Wikimedia Foundation remove the pulsing blue dot that appears under the Preview tab when editing a page's source? As an IP editor, I honestly find the pulsing animation annoying, and I hate how it appears every time I edit and how I have to click twice in order for it to stop. I'm sure many people already know about the existence of the feature, so why continue to display the distracting animation? I honestly hate it more than I hate Vector 2022, and that's saying something. When will the dot be removed completely? 2001:4453:565:1C00:EC96:CEBD:68FD:9AB 11:06, 10 February 2023 (UTC)


 * This is not related to Desktop Improvements. I've replied on the original thread at w:Wikipedia:Village pump (technical) the wub "?!"  11:58, 10 February 2023 (UTC)

Nochmal Vector 2022
Lieber Programmierer, der Du diesen Zirkus verbockt hast, möglicherweise bist Du Mitte zwanzig und mit Schmiertelefonen aufgewachsen. Das wäre alleine kein Problem, aber versuche doch endlich einzusehen, dass es längst nicht jedem so geht und das alle, die einen klassischen Rechner mit echter Tastatur und Monitor in Querformat nutzen, von dieser platzverschwendenden Oberflächenmissgeburt genervt sind. Ist es so schwer, zu akzeptieren, dass hier der Neuerungsgaul durchgegangen ist? Ich bitte darum, die penetrante Bannerwerbung, die nicht einmal pro Woche, sondern täglich mehrfach auftaucht, auf Dauer einzustellen. Stell Deine seltsame Kreation auf derselben Ebene wie die anderen Oberflächen zur Auswahl, aber versuche nicht mehr, sie mit Gewalt durchzusetzen. Die, denen das Ding gefällt, haben es. Die anderen bekommen davon nur Hypertonie.

Solltest Du Dich langweilen, dann kümmere Dich darum, dass das Aufrufen eines anderen Wikis durch einen angemeldeten Nutzer dazu führt, dass das neue in der Sprache und Ansicht des Aufrufenden erscheint. Spätestens seit Donald T. finden nämlich viele US-englisch gar nicht mehr toll. Insbesondere das hier und Wikidata sind davon betroffen und es ist keine Schande, über den Tellerrand zwischen Maine und Kalifornien zu gucken. Der Nabel der Welt befindet sich dort nicht. –Falk2 (talk) 11:43, 10 February 2023 (UTC)
 * This deserves a response via TikTok ;) —Th e DJ (Not WMF) (talk • contribs) 10:55, 13 February 2023 (UTC)

New Design absolute trash
This new design is so horrible it made me create an account to complain. When I think about it the only possible reason to destroy the website like this is to force people to create an account so that they can use the old layout. What they hope to accomplish through this I don't know since everyone who has to do this will use a 10minutemail like me and also never use wikipedia again unless forced so there's not going to be any way to sell user data regardless. Absolutely trash choice both from a commercial perspective (Not supposed to be wikipedia's goal anyway) and especially a user perspective. Who the fuck is ever going to want to donate to wikipedia ever again if the money goes to destroying the website. BringBackOldWiki1 (talk) 19:42, 10 February 2023 (UTC)

Creating links to other projects is not given as an option
At the old skin, if an article is not connected to other wikipedias via wikidata, there is an option to "add links" At the new skin, if an article is not connected to other wikipedias via wikidata, there is an option to "add languages" giving the option to translate, but no option to add links at wikidata. This has to be corrected. FocalPoint (talk) 21:46, 10 February 2023 (UTC)


 * Hello @FocalPoint. At the page tools (now located at the right of the page) you may find an option called "Edit interlanguage links" to connect the article via Wikidata. Thank you. Zapipedia (WMF) (talk) 09:50, 11 February 2023 (UTC)
 * @Zapipedia (WMF), yes, I found it, thank you. Still... why not keep it in the Languages box? Just change for change's sake? Isn't it a Language issue? Think about it. FocalPoint (talk) 14:02, 11 February 2023 (UTC)
 * Hello @FocalPoint. As said in our FAQs, the Wikidata links will be eventually closer to the list of language links. Thank you. Zapipedia (WMF) (talk) 19:47, 12 February 2023 (UTC)
 * Many thanks for the answer. It is all clear. FocalPoint (talk) 19:52, 12 February 2023 (UTC)
 * @Zapipedia (WMF), I want to add that it works fine in the language menu if there is at least one interlaguage link. If you click on "add languages", an option appears with the same name "Edit interlanguage links". However, this option does not come up if there is no interlanguage link in the first place. FocalPoint (talk) 16:22, 11 February 2023 (UTC)
 * Hi again @FocalPoint, could you point to any articles where this problem occurs? It would help us to investigate it. Thank you. Zapipedia (WMF) (talk) 09:08, 13 February 2023 (UTC)
 * @Zapipedia (WMF), see one example where things work:
 * wikt:Category:el:Arithmetic. Go to "1 language". See at the bottom of the box. You can see the option "+Add languages". If you click on it, the option "Edit Interlanguage Links". Same in Pericles. In articles with existing links, the option to Edit Interlanguage Links is given. Well done.
 * And here an example where things do not work:
 * wikt:Category:el:Cleaning. Go to "add languages". See at the bottom of the box. You can see the message "No languages yet, No languages available for now". No option for interlanguage links within the language box. So, even if I could find the relevant category in another language, you would need to click to the left menu the "Add interlanguage links". Same in Place d'Arménie (Clermont-Ferrand). In articles without links to other wikipedias, there is option to Edit Interlanguage Links. To be corrected, I hope.
 * . FocalPoint (talk) 17:32, 13 February 2023 (UTC)
 * Thank you for the explanation @FocalPoint. Just to be sure that I am understanding it, the difference that I see between wikt:Category:el:Arithmetic and wikt:Category:el:Cleaning is that the first one is linked to a Wikidata item Q116765545 and the second one is not linked to anyone. Interlanguage links need to be added under a Wikidata item, so that is the reason why the message "add interlanguage links" is not shown in wikt:Category:el:Cleaning. Does this make sense to you? Or maybe I am getting anything wrong. I hope this helps. Thank you. Zapipedia (WMF) (talk) 18:13, 14 February 2023 (UTC)
 * @Zapipedia (WMF), it does not make sense to me. Let me try to explain this in practice, with another example (I could not find the equivalent of wikt:Category:el:Cleaning in elwikt, so I found something better):
 * Please see
 * wikt:en:Category:egy:Egyptian mythology (no language links whatsoever)
 * and
 * wikt:el:Κατηγορία:Αιγυπτιακή μυθολογία (αρχαία αιγυπτιακά) (no language links whatsoever)
 * These categories are the same, and should be linked by interlanguage link.
 * Try to do it yourself - let it be your contribution.
 * Of course we can do it via the menu on the left. I accept it - but please do not do it with this method yet.
 * Note that we have a huge " Add languages " button on the right upper hand that does not allow you to add any languages. Does that make sense to you?
 * It does not make sense to me, at all. I would expect the " Add languages " button to actually allow me to add languages. Does that make sense to you? Am I asking too much or am I asking the obvious ? :) :) FocalPoint (talk) 18:53, 14 February 2023 (UTC)
 * Also, @Zapipedia (WMF), thank you for your patience. I see that you are really trying so that we both understand each other. I appreciate it and I honestly hope that we might achieve it. FocalPoint (talk) 19:42, 14 February 2023 (UTC)

Read My username
Read it and understand IOnlyMadeThisAccountSoICanRevertToTheOldLook (talk) 03:20, 11 February 2023 (UTC)


 * You can easily revert it for yourself.
 * This is no proper way to communicate. I suggest that this paragraph is deleted. FocalPoint (talk) 16:24, 11 February 2023 (UTC)


 * , I consider IOnlyChangedMyUsernameToSupportAnonymousIPsToRevertToOldLook.
 * , Congratulations on your first edit Sarri.greek (talk) 17:12, 13 February 2023 (UTC)

Why on earth did wikipedia attempt to use a rigorous scientific method for the development of a UI
Honestly reading the FAQ (Reading/Web/Desktop Improvements/Frequently asked questions) for why they decided to make this change only makes me more angry and confused as to why this change went through. I do not know how far somebody's head needs to be up their own ass in order for them to think that spending 3 years making iterative improvements to a UI that already works and is liked makes sense. There is no need to be so rigorous and scientific about the method of designing a UI, the only question should be "does it look good". When you instead decide to go with the moronic decision of relying on pseudo-pop-science like "when reading short lines, readers don't move their eyes too much, use the eye's muscles less intensively, thus avoiding eye strain" or "white space is used for the eyes' resting spots. It helps readers over the age of 60 focus on content and increases content comprehension by 20%" then you end up with a result that is 'technically' better but that looks and feels so so much worse. They also make nonsense arguments like "The overwhelming number of major websites have similar limitations on content width. For example: academic journals like Nature, news websites like The New York Times, government and intergovernmental websites like the United Nations, academic documents like LaTeX, and word processors like Google Docs and Etherpad" which is also stupid given that just because other websites (which have different purposes and uses) utilize this style does not mean that Wikipedia should either. I just cancelled my monthly donations and I do not expect that they should ever resume, especially considering the thought that my money was contributing towards funding some pseud's "research" about how an obviously uglier UI "is secretly better just trust me because this poorly conducted study says that reading retention went up by 42069% with more white space so that means that it's obviously better!!!1!11!" Canbyacontributor (talk) 20:53, 11 February 2023 (UTC)

Search bar doesn't work at the top on Amazon Kindle
For some reason I can't type anything in the search bar at the top in the new skin... 80.6.36.48 20:05, 12 February 2023 (UTC)


 * Hi @80.6.36.48, it is still happening? To be sure to exclude some causes: this answer helps you? If you are already filling the search box with a text and nothing happens: can you give us more details and describe your configuration (browser, browser version, OS) with an example of text you are searching for, and in what wiki it is happening, please? This is happening also when adding  at the end of the URL? This may be useful to reproduce the bug. Patafisik (WMF) (talk) 12:29, 27 February 2023 (UTC) modified--Patafisik (WMF) (talk) 08:54, 28 February 2023 (UTC)

Search box issue with mouse cursor on desktop
So if I place my mouse cursor near (specifically, a little below) the search box and then type a result in and press enter, instead of going to the main topic / main result or whatever, it goes straight to the item my mouse cursor was over on. This is quite annoying, as I have been brought to the wrong result numerous times this way, and I have to be careful and put my mouse cursor significantly away from the search box for it to not interfere.

Make it so that when the user is only using keyboard to use the search box, no matter where you put the mouse cursor, e.g. over the second result, it always goes to the main result for the terms entered. Additionally, even if you hover over a search item with the mouse cursor, pressing enter on the keyboard should still result in the search going to the main topic and not over what the mouse cursor was hovered on. Keyboard and mouse navigation should be made separate, and should not interfere with each other.

AP 499D25 (talk) 05:03, 14 February 2023 (UTC)


 * Hi @AP 499D25, thanks for yor feedback, this task is open on Phabricator. Patafisik (WMF) (talk) 15:13, 14 February 2023 (UTC)

Multiple languages UX/UI
I am writing to make a suggestion/feedback about the language options in the new UI of English language Wikipedia. While I appreciate the aesthetics, and believe things look nice, slick, and up-to-date, I would like to suggest a more straightforward way to lay out the languages options (e.g., English, 中文，日本語, etc). In the old UI, languages are laid out on the bottom left side of the page, if you need to switch between languages, the options are 1) visible, 2) only one click away. As a bilingual user of Wikipedia who need to switch between languages, I find it very helpful. The new version of UI still allows switching between languages, but it is not as easy: you will need to click on the langauge menu to see if there is a Chinese version of the entry. If yes, you click one more time to get to the page, but if no, you just wasted a click that could have been saved. I am not saying rolling back the old UI, it is just that the old language module was more friendly to users who actually use it frequently and I wish the up-to-date UI can perserve that. 146.151.105.184 05:55, 14 February 2023 (UTC)


 * Thank you for your feedback. This is being explore in this task to find a way to help users who switch languages frequently. Zapipedia (WMF) (talk) 09:35, 15 February 2023 (UTC)

Is it possible to change the default skin for a wiki if the community wants to?
Hi! Recently I was reading a Village pump discussion in Armenian Wikipedia and the community wanted to change the default skin for Armenian Wikipedia. Is it even possible assuming we create a separate discussion/poll and there is an overwhelming support for the change? Ashot (talk) 06:46, 14 February 2023 (UTC)


 * Hi @ԱշոտՏՆՂ, thank you for your report, can you add a link to this discussion? Patafisik (WMF) (talk) 07:27, 15 February 2023 (UTC)
 * HI @Patafisik (WMF). The discussion is here: Special:PermaLink/8613606. It wasn't actually about changing the default design but rather a general survey if people like it. 23artashes asked if it is even possible to change it and I couldn't answer the question :). If it is possible, we will open a new discussion and probably a poll. If the change isn't possible in a Wikimedia project, I would rather avoid the trouble because I'm sure there will be a lot of disagreement :) Ashot (talk) 07:57, 15 February 2023 (UTC)
 * Hi @Ashot, thank you for letting us know. I think in less than two weeks we'll be able to start a discussion with your community on your wiki. In general, we'd like to learn what's not working for those who join the discussion, and why. Perhaps something could be fixed or clarified. Restoring the old skin is not the first option we would like to discuss (of course, we'll give our arguments why). I'm sorry that I wrote "in less than two weeks" - we're working a bit more slowly right now. SGrabarczuk (WMF) (talk) 02:26, 18 February 2023 (UTC)

Why is the sidebar on the right side of the page?
Everything was fine in the beginning, but now I'm considering returning to the old vector. Please, PLEASE STOP FIXING THINGS THAT AREN'T BROKEN. Bageense (talk) 03:26, 15 February 2023 (UTC)


 * That's it. I quit. I was a big fan of the new vector. I was one of only TWO editors [sic] who where using it in the Portuguese Wikipedia. I was there since the very beginning, but now I quit. Bageense (talk) 03:32, 15 February 2023 (UTC)
 * Hello @Bageense. Here you can find more information about the Page tools and the reasons to move them to the right side of the page. Thank you. Zapipedia (WMF) (talk) 08:48, 15 February 2023 (UTC)
 * I've got a quick JavaScript hack that I'm hopefully going to be working on over the weekend. To get this to work you'll want to do the following steps:
 * On your home wiki, open your common.js page and insert the following lines of JavaScript
 * Save the page and go to an article or talk page that has a table of contents
 * If your Tools menu is currently on the right hand side of the page, click the Hide button on it
 * And that's it, your tools menu should now appear immediately below the floating table of contents
 * Couple of important things to note.
 * This might only work on enwiki at the moment if the CSS IDs that the JavaScript relies on is localised on each wiki. If that's the case, reach out to me at home wiki talk page, and I'll try and make it work for your wiki.
 * Right now it also only works on pages that have a table of contents. If you open a page, like the edit view, which does not have a table of contents, the tools bar will return to the tools menu dropdown near the top of the page. I'm hopefully going to work on this over the weekend as I've got an idea that should make it appear on any page, but I've not had the time to make the change yet.
 * Any scrolling in a page's main content area, which causes the floating table of contents to jump to the current section you are reading as you scroll up or down through the main content area, will cause the tools menu to move back to the bottom of the floating area on the left side of the page. This is also something I'm going to try and work on over the weekend, if I can figure out the bit of JavaScript that's causing it to do this and figure out how to disable it without breaking everything else.
 * At the moment this is super basic, and just five lines you add to your common.js file. Once I've worked out the major bugs I'll figure out how to make it work with  or   so that I can share and update it if it breaks more easily for anyone who wants it.
 * Otherwise, happy to answer any questions about this here (please ping me if you do as I don't check this wiki often), at my home wiki talk page, or on the Wikimedia Community Discord where you can find me under the username "Sideswipe (she/her)". Hope this helps. Sideswipe9th (talk) 05:23, 18 February 2023 (UTC)
 * P.S. If the WMF want to take my solution once I get the bugs fixed, and maybe roll it into Vector2022 as a customisable user option, I'm totally down for that. Reach out to me at my home wiki talk page, Discord, or my enwiki email address and I'll happy chat about what I'm doing and what issues I've run into while making it :) Sideswipe9th (talk) 05:25, 18 February 2023 (UTC)
 * Thanks. But the problem is that the new skin is being constantly modified, so that code can be rendered useless eventually. Once I could disable the sticky header with a code; later, I was no longer able to do that, and I was forced to stick with the header. Bageense (talk) 07:54, 18 February 2023 (UTC)
 * Perhaps, however I also cannot stand the Tools menu on the right hand side of the page while still otherwise generally liking Vector2022. So I will be maintaining a version of this on my home wiki for as long as I can, as any time that a breaking change happens to the HTML or CSS, I'll be fixing it for at least my own sanity and editing convenience. Sideswipe9th (talk) 19:31, 18 February 2023 (UTC)
 * Perhaps, however I also cannot stand the Tools menu on the right hand side of the page while still otherwise generally liking Vector2022. So I will be maintaining a version of this on my home wiki for as long as I can, as any time that a breaking change happens to the HTML or CSS, I'll be fixing it for at least my own sanity and editing convenience. Sideswipe9th (talk) 19:31, 18 February 2023 (UTC)

No search suggestions just in Vector-2022
Nothing drops down, as I type. What could be a problem (and solution)? Атомный трамвай (talk) 13:51, 15 February 2023 (UTC)


 * Hi @Атомный трамвай, thanks for your feedback. First of all and to be sure to exclude some causes: this answer helps you? If you are already filling the search box with a text and nothing happens: can you give us more details about your configuration (operating system, browser and browser version, screen resolution), and an example of text you are searching for to reproduce the bug, please? This is happening also when adding  at the end of the URL? Patafisik (WMF) (talk) 08:45, 28 February 2023 (UTC)
 * Thank you for attention.
 * The issue you've mentioned doesn't help me at all, because a user there experienced replacing search field with button, and I don't.
 * Firefox 110.0, macOS High Sierra, 1280×800. Also, you can check out it by yourself — https://jantanoo.info, if it reproduced at your env (I sure, it does).
 * Whatever I type in search field, I ain't see a suggestion menu. As it should be shown regardless any text one type, so, I think, no need to mention any specific text I tried to type. And this issue is just about modern Vector — in classic Vector, in Minerva Neue, in all built-in skins there is the dropdown suggestion menu. I wouldn't be surprised if it is because of some incorrect setup — I am not so experienced admin and, for example, I've got a concept of MW's Gadgets just recently (and one of damaged gadget made a huge mess for my wiki and I haven't found a problem too long). And I remember, before I upgraded from MW 1.34.1, there was no this dropdown menu in classic Vector, too. On the other hand, I've made a serious re-install of MW and now it works on classic Vector… Атомный трамвай (talk) 12:39, 28 February 2023 (UTC)
 * I can reproduce it (Firefox version 110, Windows 10). When I type "т" in the search form on the top, suggestions do not appear. But if I click on the button "search" ("Найти") I arrive on this page. However, using the second search form under "Search results" ("Результаты поиска"), typing "т" I have the search suggest drop-down list. I report this issue and waiting for an answer. The new search functionality is described here. Patafisik (WMF) (talk) 14:59, 28 February 2023 (UTC)
 * Thanks a lot, I hope we are able to develop this more perfect way (together)! Атомный трамвай (talk) 07:10, 1 March 2023 (UTC)
 * Please look at the reply here. An additional information: if I'm not wrong, the first form is using Vue.js while the second one is using CirrusSearch. Patafisik (WMF) (talk) 07:27, 1 March 2023 (UTC)

Why is there no table of contents?
Why? Red Slash (talk) 18:58, 15 February 2023 (UTC)


 * Hello @Red Slash. Where do you fail to notice the table of contents? Have you checked perhaps if on the page you're referring to, there's a ToC when using other skins? SGrabarczuk (WMF) (talk) 02:15, 18 February 2023 (UTC)

Menu again - Tools-Menu on the right...
doesn't do what it probably should for me. Too big a font and the sections are not discernable enough. I was hoping that this would help the new menu structure, but it doesn't for me.

This page (here, the talk page) is the perfect example for everything I see wrong with the new menu: It's simply a bunch of too narrow text, which is not helpful at all! The "Main Menu" blocks the TOC initially (or is hidden), most of the TOC-Headings have line breaks and show additional information (which seems to be a total overload), scroll bars are partly out of bounds, one doesn't know where the mouse wheel is working right now.

I really doubt, that the usability of the new menu is better than in legacy vector. It doesn't look better (at least not for me), it needs more klicks, it needs more time for reading, everything is gliding/changing/sliding/hiding/autohiding with no distinguishable idea.

Yes I know, all this is probably not a thing while displaying and/or reading encyclopedic content. I think nothing mentioned here is a bug, because I think everything is intended. I just don't see why. Regards HirnSpuk (talk) 15:42, 16 February 2023 (UTC)

PS: As a side note: I just tried to see if I'm liking it better when playing with page zoom and browser-font-size. Spoiler: I don't :-D. I was hoping "just the text" will get smaller (hence at least mitigate the page-break problem), but the whole website did. Well not everything... I don't get it. HirnSpuk (talk) 15:55, 16 February 2023 (UTC)

Keyboard shortcut needed to 'User contributions' in Tools menu
I would add that now the 'Tools' menu is to be found in one of two optional positions, and also of variable length across different pages, I find the lack of a keyboard shortcut to view another User's Contributions is most frustrating. It should be a simple fix. For active editors, being able to easily view another users' edits is often more important than seeing one's own. We do have a shortcut for that, and many other less well-used Tools. I also agree with other commenters above that the order of Tool links been very bad for a long time. Not only that, but the lack of visual difference between both the 'Actions' and 'General' headings and the actual Tools links themselves makes the experience of using the tools menu much worse than it needs to be. Nick Moyes (talk) 12:42, 17 February 2023 (UTC)

Tools-Menu only disappeared from ARwiki
Tools-Menu only disappeared from ARwiki, I just hide it but later I find no trace, or how can I appear Nehaoua (talk) 13:47, 17 February 2023 (UTC)


 * Hi @Nehaoua, when the Tool menu is closed, you can open it under the Language button (article pages), on the right of the watchlist icon (the star) see below:

I don't know if it matches your issue. I've notice that styling should be improved locally on arwiki (ex. there is a lack of an icon here, the Page tool shows a scroll bar), it is write different from the layout on frwiki or on itwiki, for exemple. The layour is not bugging with safemode, it should be fixed by an admin on arwiki, or equivalent. Patafisik (WMF) (talk) 16:17, 17 February 2023 (UTC) Modified -Patafisik (WMF) (talk) 16:40, 17 February 2023 (UTC)


 * @Nehaoua Page Tools feature is now available on all wikis for logged-in users (T302073). Logged-out users still have tools within the sidebar at the left of the page. Patafisik (WMF) (talk) 16:30, 17 February 2023 (UTC)
 * Thank you, @Patafisik (WMF) when I click in (masquer=أخف) I can't rpere the buton for show again (i find finally this in top of (Outils=أدوات) menu) cordially Nehaoua (talk) 19:06, 17 February 2023 (UTC)
 * Hi @Nehaoua, sorry for not naming links in Arabic last time. I updated the screenshots, now they may be more clear. S'il y a quelques choses que je peux faire encore n'hésitez pas à me notifier. Patafisik (WMF) (talk) 09:42, 20 February 2023 (UTC)
 * @Patafisik (WMF) merci infiniment, maintenant il est très claire Nehaoua (talk) 14:35, 20 February 2023 (UTC)

Different looks in different Situations
I would have expected, that the look is consistent between Legacy and V22. It seems not to be. The pages all look different, depending, if you are logged in/out, which "project" you are on and what "dynamic buttons" you have clicked (width, hide, pin...). Is this really intended behaviour? The biggest issue I'm startled by is the different behaviour of the same skin while logged in and out (different menu, different font-size, different behaviour, different spacing). HirnSpuk (talk) 16:11, 17 February 2023 (UTC)

Tewiki:User menu drop down
This is about Tewiki The User menu drop down has the following issues: __Chaduvari (talk) 01:37, 18 February 2023 (UTC)
 * 1) When page is not scrolled, when the mouse hovers on Contributions menu item, a sub-menu list appears with three links - contribs, translations, uploaded media. When I move the mouse to click any of these three sub-menus, the mouse moves over the tool tip (User menu) and this sub-menu list disappears. It is impossible to click these three sub-menus. When I move the mouse around the tool tip, then, the sub-menu list does not disappear.
 * 2) In the sticky drop down (when the page scrolled down), the sub-menu is not shown at all.


 * Forgot to mention an important point: The behaviour mentioned at point #1 above, is not noticed in enwiki. __Chaduvari (talk) 01:43, 18 February 2023 (UTC)
 * Hello @Chaduvari. I was trying to reproduce #1 issue at teewiki, but I was not able to do so (in my case, I can select the sub-menu items). Are you still experiencing it? Thank you. Zapipedia (WMF) (talk) 00:21, 21 February 2023 (UTC)
 * @Chaduvari, indeed I found this related task. Thank you. Zapipedia (WMF) (talk) 01:12, 21 February 2023 (UTC)
 * @Zapipedia (WMF) Okay, thanks for the link. __Chaduvari (talk) 05:08, 21 February 2023 (UTC)

Fresh from Tewiki
Noticed this in Tewiki - the link to add inter-language links disappeared. The drop down list has only two links- "Translate this page" and "Open language settings". __Chaduvari (talk) 01:58, 19 February 2023 (UTC)


 * Hello @Chaduvari. Could you please share a page in which this issue is happening? Does it happen in all the pages? Thank you. Zapipedia (WMF) (talk) 21:29, 19 February 2023 (UTC)
 * Hi @Zapipedia (WMF),
 * Tewiki_Langlinks_screenshot_Vector2022-21Feb2023.png You can see this issue on సిపాయి సుబ్రమణ్యం page. The issue is also noticed in Wikipedia:, Template:, Module: and Category: namepaces too (didn't check the other namespaces). In these namespace pages, only "Open language settings" link is there; "Translate this page" link is not shown. The adjacent screenshot shows the Main space page. Thanks. __Chaduvari (talk) 05:06, 21 February 2023 (UTC)

Custom CSS for the Vector 2022 skin is not working for me!
Hi, Unfortunately, I was trying to edit the Vector 2022 CSS MediaWiki page on Meowpedia (miraheze wiki btw) but it sadly doesn't work. How do I fix it? My Miraheze username is 'BlahBlahBlah666' btw. 2A02:C7C:BD2C:B500:2023:D2C3:A0D2:B5E6 12:28, 19 February 2023 (UTC)


 * Are you trying to edit site-wide or user-wide? I don't see a https://meowpedia.miraheze.org/wiki/User:BlahBlahBlah666/vector-2022.css or https://meowpedia.miraheze.org/wiki/MediaWiki:Vector-2022.css page. That's where your user styles should be loading from.
 * Note currently both https://meowpedia.miraheze.org/wiki/MediaWiki:Vector.css and https://meowpedia.miraheze.org/wiki/User:BlahBlahBlah666/vector.css should apply to both Vector skins (Seems like the former is working?)
 * For security reasons, user styles/scripts are disabled by default. You'll have to talk to the admin of your miraheze instance to fix that if that's the problem. See mw:Manual:$wgAllowUserJs and mw:Manual:$wgAllowUserCss for more information. Jdlrobson (talk) 20:35, 27 February 2023 (UTC)

Space inserted in page title
Greetings, When I visit commons:User talk:Elizium23 I see the page title listed as "User talk: Elizium23". That is, a space is inserted after the namespace and before my username. This is not part of the page title, and it will mess you up if you copy-paste it. If I "View history" on the same page, no space is inserted. Other wikis, no space. Safe mode, still a space.

This may have occurred on other pages, because I recall being surprised by a copy-paste failure; it's subtle, so I'll have to continue watching for it. Elizium23 (talk) 13:53, 19 February 2023 (UTC)


 * In fact, the same effect happens with Vector Legacy, so this is not a function of the skin... why just on Commons? Elizium23 (talk) 13:55, 19 February 2023 (UTC)
 * This space is not added by this or any skin. It is added by DiscussionTools extension as part of Talk pages project. – Ammarpad (talk) 21:25, 24 February 2023 (UTC)

Bug - Cursor changes from I-beam pointer to arrow over page title

 * When a page doesn't have a toc or the main menu on the left, you have the arrow when hovering the title with the mouse, so you have to left-click, hold and move the cursor to mark the title.
 * When there is something on the left, like the toc or the expanded main menu you have the I-beam pointer, so you can just triple-click to mark the whole title.
 * Please fix this so users can still quickly copy and paste page titles.
 * Thank you for your work!
 * --KleinerKorrektor (talk) 19:25, 19 February 2023 (UTC)
 * Thank you @KleinerKorrektor. I reported it in this task. Zapipedia (WMF) (talk) 01:18, 21 February 2023 (UTC)

Custom CSS is not working for the Vector 2022 skin.
I tried editing the Vector 2022 CSS page on Meowpedia (which is currently private due to some technical stuff) but it doesn’t work. How do I get it to work? 2A02:C7C:BD2C:B500:940:A9B3:53AC:5EBC 08:33, 20 February 2023 (UTC)


 * Hi, thank you for your feedback, can you give more details, please? What custom CSS are you trying to use, with a link if available? Patafisik (WMF) (talk) 11:15, 22 February 2023 (UTC)
 * And what page are you editing.... —Th e DJ (Not WMF) (talk • contribs) 13:45, 22 February 2023 (UTC)
 * Sorry for replying 1 day late. The link is right here. Btw, it's a Miraheze wiki despite... UH... yeah. The background behind the article background should be the CSS colour 'papayawhip' on Vector 2022, but sadly I deleted it because it didn't work. 2A02:C7C:BD2C:B500:F5B0:6716:1368:719A 14:20, 23 February 2023 (UTC)
 * Reply is here. Patafisik (WMF) (talk) 09:49, 28 February 2023 (UTC)

Bug? Content jumping around
While reading up on Special:Permanentlink/5784366, and wondering, why the communities wish does not seem to be accepted, I found another issue with the toc: The content is "jumping around" because of toc/notoc funcionality. See: w:sw:Wikipedia:Mwongozo, w:sw:Wikipedia:Mwongozo_(Kuhariri) and the other "subpages". To replicate: open the links and narrow the page until content and toc is more or less within window-bounds. Then, when switching the pages, the content "jumps around". HirnSpuk (talk) 18:55, 20 February 2023 (UTC)


 * I think the user means:
 * If you are on a pretty narrow page (sub 1200px but over 700px)
 * If the main menu is collapsed
 * AND the toc is not collapsed
 * AND you are on a page with a ToC
 * AND you navigate to a page without a ToC
 * THEN the content on the page (visually) jumps from being indented ( by toc-width ) to being not indented at all.
 * This might be be unexpected and jarring and messes with your navigation expectations as a user. —Th e DJ (Not WMF) (talk • contribs) 13:43, 22 February 2023 (UTC)

"Reply" button in User talk
Hello. I know that this isn't exactly an issue of skin, but I don't know better place to ask, so: it is possible to turn off a "Reply" button in User talk pages? Once it was seen as default to reply on interlocutor page bcs of notifications, now many new users just click reply on their own talk without even a ping. It disturbs a fluent discussion between editors. --Wojsław Brożyna (talk) 08:05, 21 February 2023 (UTC)


 * I reported your answer here. Patafisik (WMF) (talk) 11:37, 27 February 2023 (UTC)
 * It isn't possible to turn it off for other users on your comments. Instead, I would suggest turning on "Automatically subscribe to topics" ("Automatycznie subskrybuj wątki"), so that you will get notifications about replies to your comments even if the other user doesn't add a ping. Or if you really want, you can turn off "Enable quick replying" on the same preferences page, but this will only change how the pages look like to yourself. You can read more about these features at Help:DiscussionTools. Matma Rex (talk) 17:59, 27 February 2023 (UTC)
 * --Patafisik (WMF) (talk) 13:48, 28 February 2023 (UTC)

Links on whitespace (table of contents, etc.)
I'm using the new layout for quite some time now and I like it. Great work, thanks!

One thing I absolutely hate, though: In the left-side nav bar, all the links seem to cover the full width of the bar, even if the link text is much smaller. So e.g. if there is a table of contents with the two chapters "Some very long text" and "Short", the white space right of "Short" will link to the "Short" chapter as well. It's effectively a link like "Short _____________", where the underscore line is invisible, but anyway linked. While I personally don't see any usecase for this (if I want to open the link, I would click on the link text and not just somewhere around it, would I?), I see a disadavantage of this multiple times every day: When I want to scroll through a long page, I habitually middle-mouse click some white space on the page to enter the browser's fast scroll mode. Works in any browser and almost all websites (the only common exception: ads), just on Wikipedia I now have to be very careful where to do this, and frequently end up in opening a new background tab instead of scrolling. Karotte Zwo (talk) 09:13, 22 February 2023 (UTC)

Edit source to Tools
Request: Please add "Edit source" to the Tools sidebar. This avoids scrolling. Thanks. Grimes2 (talk) 07:41, 23 February 2023 (UTC)


 * Editing button in the Vector 2022 sticky header.png Hi @Grimes2, what wiki are you trying to edit? On the English Wikipedia, the edit button is available on the sticky header which appears when you scroll down the page, you just have to click on the pencil icon to edit the wikicode. Patafisik (WMF) (talk) 09:52, 23 February 2023 (UTC)
 * Thanks, problem solved! Can be closed. Grimes2 (talk) 10:12, 23 February 2023 (UTC)

Can we have different font sizes? Because: zooming in firefox makes the toc highlighting not fit to the text

 * In the Wikipedia App such option already exists.


 * On the desktop I use firefox as a webbrowser with a zoom of 120% for all Wikimedia projects.
 * When you scroll inside the text (not the toc) between the section of two headlines, it is like that: the toc highlighting switches, when the section of a headline is at the lower border of that new dynamic bar at the top.
 * But when you zoom with firefox, it does not match.
 * Native implemented font size changing would do the trick I guess.


 * Best Regards --KleinerKorrektor (talk) 10:09, 23 February 2023 (UTC)
 * Hi @KleinerKorrektor, thanks for your feedback. OVasileva (WMF)'s answer: "In the near future, we're hoping to explore some of this in the new skin - specifically allowing users to configure their font size for the site". A task for increasing the base font-size for article text from 14px to 16px is open too.
 * I will open a new task on Phabricator about your issue, please can you describe your configuration (OS and screen resolution)? It may be useful. Patafisik (WMF) (talk) 11:06, 27 February 2023 (UTC)


 * Hey Patafisik. Thank you for your reply. My screen resolution is 1920x1200. Webbrowser is firefox-esr 102.8.0esr. I'm on Debian 11 here. Best Regards --KleinerKorrektor (talk) 11:13, 27 February 2023 (UTC)
 * Hi @KleinerKorrektor, are you still experimenting the mismatch between the text title and the table of content title when you zoom? If yes, can you give us an example of page where it is happening? Thank you! Patafisik (WMF) (talk) 08:00, 3 March 2023 (UTC)

Jump to top
Request: Please add "Jump to top" (up arrow) to the top bar, that is displayed by scrolling down. Grimes2 (talk) 11:58, 27 February 2023 (UTC)


 * Hi @Grimes2, what are you calling "top bar", do you mean the sticky header? By clicking "beginning" on the ToC you should scroll back to the top of the page. Did you try with the keyboard shortcut (e.g. CTRL + Home, or Command + up-arrow key, or similar)? I also have keyboard keys Begin and End on my keyboard, but I know not all keyboards have. A lot of browser allow an extension like Scroll to Top too. Patafisik (WMF) (talk) 13:40, 27 February 2023 (UTC)
 * Pos1 (up)/Ende (down) works. Thanks Grimes2 (talk) 13:51, 27 February 2023 (UTC)
 * Glad to have helped. I open a task however with a suggestion for a feature. Patafisik (WMF) (talk) 14:34, 27 February 2023 (UTC)