Talk:Reading/Web/Desktop Improvements

Too narrow (again)
Why waste all that space? I have a nice wide screen so I want to take advantage of it. Those who want to have it narrow can just reduce their window sizes? Overall, not a great look. Not exciting. Quite boring.--Xania (talk) 11:23, 22 December 2021 (UTC)


 * Hello @Xania, you can read about our goals and motivation for limiting the width. Also, we are working on a solution to use the empty space. Could you take a look at our fourth prototype and write more on what you think about arranging the space as it is presented there? Thank you in advance! SGrabarczuk (WMF) (talk) 14:59, 26 April 2022 (UTC)
 * Oh my dear God, why don't you give an option to unrestrict the width?? It's beyond ridiculous how absolutely tiny is the page content on my monitor horizontally! I have to scroll all the time to read! Don't ruin Wikipedia the same way Fandom was ruined! 90.188.46.13 04:38, 13 May 2022 (UTC)
 * We have given this option. This can be done with the gadget one of our engineers made. SGrabarczuk (WMF) (talk) 03:39, 14 May 2022 (UTC)
 * Thanks, but maybe we should have an easy plug-in system for ordinary users or, at least, the instructions how to apply it and a place where to find those customisations. By default it is really narrow to read and it feels like a news site rather than an encyclopedia article. Krnl0138 (talk) 09:55, 15 May 2022 (UTC)
 * I agree, the toggle option should be there by default! By the way, that script does not work well currently, so I updated it here. — Arthurfragoso (talk) 13:28, 21 May 2022 (UTC)
 * I'm aware this reply is quite late but I feel this comment may be helpful:
 * What if there were options for multiple skins? For example, users could choose between the new and classic variants and possibly a dark mode for both?
 * In giving users freedom of choice, they could simply choose which one suits them best. Maybe a skin with a 'Bionic Reading' font can be used to assist users with ADHD or other conditions (seeing as some pages can be lengthy to read)? Grebles (talk) 06:06, 11 September 2022 (UTC)
 * Bionic reading has been experimentally tested to be largely ineffective and seems to be a VC cash grab, convincing people of a problem that is not real. Glenohumeral13 (talk) 19:48, 15 October 2022 (UTC)
 * I have the same problem. Only half the page is filled. And, as I get older, I would appreciate being able to increase the font size (without resorting to Chrome's Ctrl-+) 80.56.112.145 14:16, 8 November 2022 (UTC)
 * Why should actually using the space require a special gadget?? ☸ Moilleadóir ☎ 05:59, 16 October 2022 (UTC)
 * I don't understand why you are still pushing on us that bad design choice. It still is time to pull the plug and start to work on a plain page design. You are convincing no one here. Please, please, really, please stop this nonsense. Forcing bad choices on your users because you are the only product on the market is never a good thing.
 * Since it has been forced without asking anyone on the French Wikipedia I had to register just to come back to the normal and good design. That's something, as a simple reader, I should never have had to do in the first place.
 * So one last time, please come back to reason and stop hurting your user base foolishly. DerpFox (talk) 21:33, 13 May 2022 (UTC)
 * Hello @DerpFox, thanks for your comment. Have you maybe followed the links I've shared in my answer to Xania? SGrabarczuk (WMF) (talk) 03:42, 14 May 2022 (UTC)
 * Ditto Tim bates (talk) 16:32, 30 August 2022 (UTC)
 * The lines in the fourth prototype seem to be slightly wider to me on 1080p display than in the current version of 2022 vector design, but those empty strips on the sides, each of which are almost the size of the old navigation mv-panel, constantly remind about the space wasted.
 * If the only reason of this thinning is the recommended line lengths in symbols and you want to keep it for any price, I would suggest using a dynamic font size, so, for example, starting from some resolution the symbols just grow larger. This might also reduce the eye strain connected to focusing on the small text.
 * Kageneko (talk) 13:51, 17 May 2022 (UTC)
 * Please no. I don't want 28px text on a 1440p screen. Yes, it should be increased to 16px, but no dynamic size. Gugalcrom123 (talk) 16:33, 1 November 2022 (UTC)
 * I had a browse over the reasons for the change, but I still don't like or agree with the main justification more or less boiling down to "everyone else is doing it so we should too". Even in the linked examples, the page still feels a lot more "full" despite having a dedicated deadspace on the site, due to the way the page has been very carefully designed in a mixture of different kinds of block contents (images, text interactive eliments, etc).
 * Accepted Webpage standards used to be against having blank, unused and waisted deadspace, but at some point in the last 10 years there seems to have been a weird shift to the opposite where deadspace is all the rage, though it's not one I've personally ever liked or agreed with.
 * While I'm sure there are good uses of limiting page width, I'm not sure if Wikipedia, being a site that is mainly made up of text would really benefit from it as it's likely just going to squash pages and increase the amount of vertical scrolling required to navigate. Dave247 (talk) 07:32, 18 May 2022 (UTC)
 * Yeah it's too narrow otherwise. the look is very nice, it's not boring as you tell. Crater bug (talk) 15:28, 28 May 2022 (UTC)
 * I love the smaller margins. Works really well. Much cleaner. Thank you! 202.53.37.158 08:31, 16 August 2022 (UTC)
 * I'll buck the trend and note that on my 2560x1440 monitor, I very much appreciate the shorter line widths. Trying to read 12" or wider lines starts to get extremely exhausting, and vector makes it a lot easier to keep reading. I think that was the right move, matches best design practices, and is best for most users. ThatsNoMoon343 (talk) 22:25, 27 August 2022 (UTC)
 * Agree. Gugalcrom123 (talk) 16:34, 1 November 2022 (UTC)
 * I'm sorry but I have to agree with some of comments here - I have a widescreen monitor on desktop and the new format is very disappointing as a whole lot of white space is wasted, and the page is too narrow. Unskathd (talk) 02:53, 26 September 2022 (UTC)
 * Hey, just joining in to say that conceptually, the 4th prototype is super nice, however only actually displaying anything on 37.5% of a screen & leaving 62.5% blank is not an effective use of space...
 * On "The popular recommendation is that there should be between 40 and 75 characters per line." - I have measured, and on my display the new version shows 125-150 characters per line, whereas the old version shows 350-400. I zoomed in to the point where it displayed around 50 characters per line, and found it near impossible to read as either the letters had to be too big to read quickly or the width had to be so narrow that it was jarring. This seems like a great idea for mobile, however there is already a good enough interface on mobile, so why turn the pc version into it?
 * I also think pushing for a "common reading experience" is unwise also - it does help in a few rare situations, however enforcing a system on users because people don't check their formatting correctly is a move in the complete wrong direction. Why not add a preview rendering different screen sizes and resolutions instead? 1rre (talk) 21:44, 13 October 2022 (UTC)
 * If you created white side areas in order to place ethical advertising (or something similar), this is fine for me.
 * But please, avoid such foolish justification. 🤦‍♂️
 * In order to achieve an "optimal line length in reading", I act on my own hardware: first of all, I avoid buying a screen too wide for my own needs; then, I'm going to adjust settings on that hardware (like eye-screen distance and font size). DKDIB (talk) 09:53, 22 November 2022 (UTC)
 * I totally agree! I dislike the vector skin because how small it is. OverAWallOfMetaKnight (talk) 15:55, 15 May 2022 (UTC)
 * Agreed. I use a 3440x1440 screen (usually with a tiled layout), and this new layout forces all the content to occupy a comically narrow strip, instead of allowing me to choose the width myself. Emptyflask (talk) 13:47, 17 May 2022 (UTC)
 * I agree, there is simply too much space wasted that could be used for more article space and a button specifically for those who want to edit wikipedia Techny3000 (talk) 02:52, 28 May 2022 (UTC)
 * hard to read I'm glad I stayed the same as before No changes required 240B:11:E7E0:5E00:6005:3399:E6C:2B48 14:06, 2 July 2022 (UTC)
 * Strongly agree. I want to decide the readable width for me. In the old skin and most websites, I can do it by adjusting the width of window. I definitely don't want to care about "CORRECT READABLE WIDTH FOR EVERYONE" decided by someone somewhere, even if they are great scholars. Kyoku (talk) 08:32, 10 July 2022 (UTC)
 * Maybe make the article resizeable and save it using cookies? Gugalcrom123 (talk) 16:35, 1 November 2022 (UTC)
 * Agreed wholeheartedly. By the way, the design is even worse on a low DPI widescreen display, like 1366x768, 1280x800/720, etc. Try it out with Device Rendering options in your browser, usually somewhere in Dev Tools. I just got hit with Vector 2022 after coming here from wikipedia where I've had Vector 2010 enabled for a while and I forgot how bad it was!
 * Wikimedia Foundation, do not forget that people all around the world use your service. People who might have a budget/old device with a low resolution display, or schoolchildren with a Chromebook or something! No default layout should ever create this much dead space and padding in a desktop environment. NONE. Nor should it ever consume nearly 1/3 of screen real estate that can never ever be used by the main content.
 * The floating ToC looks like absolute garbage at 720p. I have WUXGA and 4K devices and it isn't any better there either. I'm not sure who the design is aimed at, other than the designers pushing the modern scourge of padding and white space onto the rest of the Internet. -αβοοδ (talk) 17:41, 29 July 2022 (UTC)
 * Totally agree. Has anyone ever made a poll among the users to figure out whether they want this narrow thing? WolfRAMM (talk) 18:13, 29 August 2022 (UTC)
 * Agreed, it looks terrible on desktop. As usual, a design choice with only mobile users in mind and no one else. Jotamide (talk) 12:53, 9 September 2022 (UTC)
 * I disagree with the comment and agree with the change to make it narrower. I find that I read more slowly and have more eyestrain on excessively wide layouts. That being said, I think a toggle (like what Notion.so has) could work well. Phsource (talk) 20:26, 9 September 2022 (UTC)
 * I agree. I feel like I am wasting space. If I want a narrow reading view, then the way I previously could do that is by *resizing my window* to make the view that I want. Sometimes I do want a wide view, and when I do I make my wikipedia window full screen. And when I want a narrow view I use my desktop's built-in split-view functionality by dragging a window to either side of the screen.  But with this new narrow-only skin, readers don't have an easy way to have a wide view when they want it.  Also I don't feel like wikipedia should jump on the bandwagon of having narrow view because that is the current fad that other websites do. Em3rgent0rdr (talk) 03:13, 10 September 2022 (UTC)
 * Yet another website caving in to the forced mobilefication of the web for desktop users. I don't understand this insistence on hiding everything in drop-down menus either. I really hope someone makes a userscript or something to revert this change when it inevitably becomes site-wide because otherwise I might just start using old Wayback Machine captures to view Wikipedia pages for non-time-sensitive things. Noxian16 (talk) 21:54, 25 September 2022 (UTC)
 * Strongly agree. Why artificially constrain the width of an encyclopedia, the primary purpose of which is to have high information density? There is nothing wrong with Vector 2010, at least the issues with it are not fixed by Vector 2022. What is the purpose of a floating TOC? Why have so much excessive padding on the navigation menu? The only reason in my opinion is mindless, poorly thought out copying of current design trends in other sites, all of which are not encyclopedias. This is perpetuating a worrying trend on the Web of boxing everything up into little divs with big padding.
 * I also find the appeal to different studies on reading line length dubious for the reason that they are for newspapers. When reading a newspaper, you want to be led quickly through the story and get on with your day. News writing is supposedly to be clear, snappy, yet still with enough narration/quotes/context that a reader understands the story. Encyclopedia writing is quite different, with an emphasis on completeness and objectivity. Especially since articles can get quite long, limiting the width seems like it could actually make navigating articles more difficult, since they will lengthen considerably.
 * I really hate to see the entire site essentially waste a giant 4em of padding just for the supposed sake of "readability" (and for the real motivation copying existing UI trends). Who is complaining that Wikipedia is not readable? No one, to my knowledge. This seems to fix something which is not broken. Fixing readability on WP is 99% fixing articles, not UI. Glenohumeral13 (talk) 19:46, 15 October 2022 (UTC)
 * Also, when did we decide that reading time is even a metric we are optimizing for? No one is trying to speed read Wikipedia. Let readers read slowly and at their own pace without trying to constantly "improve" a dubious metric.
 * I can only speak for myself but on an internet that is continually trending towards increasing "engagement" and advertising and this and that, I love coming back to Wikipedia (almost daily) to just browse and read something not being fed to me. The "increasing reading time" goal seems to me the first step in ruining this quality. Glenohumeral13 (talk) 19:53, 15 October 2022 (UTC)
 * At the end of the day, it’s my computer, it’s my browser. If I choose to read lines 10,000 words long that’s none of your business.  Unnecessarily restrictive or prescriptive designs are a bad idea.  I also can’t escape the feeling that the main motivation here is fashion.  This is the default for Facebook, Twitter and even Joomla!, but it fails being truly responsive.  It probably makes it easier to downsize the content for a phone, but it makes really poor use of a modern widescreen monitor (as do default font sizes).  And suggesting ‘something’ will go in the right column is not a justification for having one.
 * This just feels still not ready for the real world.
 * Curious how the “Suggested languages” (translated as “Common languages” in Irish) are decided. When not logged in it offers me Chinese, Irish/English and Italian.  I did a very little Chinese many years ago and might be able to follow some Italian, but where’s the French?  It’s so random & totally unrelated to my browser settings.  Why are you suggesting languages in the first place?  Let me choose some, sure, but suggest? ⚜ Moilleadóir ✍ 06:44, 16 October 2022 (UTC)
 * Without even reading the justification, I can tell you from my personal web site experience of years yonder, every usability study out there tells you text is more readable if the line length is limited. At my I went with *precisely* the idea that the user would just adjust their screen. Then out of principle I did that too. But only for a while. Eventually I found myself looking at my own site at the full screen width, and so struggling to find the starting point of the next line while reading my *own* text.
 * I haven't gotten around to changing that, but I really should, and it's nice to see Wikipedia doing that already. Too wide a paragraph, anywhere, really is a usability nightmare.
 * As for how the pages ought to scale, and look, after that restriction, it's a different matter. Most of the pages on Wikipedia have in fact been written in a fashion which was guided by the old Vector style. They don't look quite right under Vector 2022. Especially, paragraphs now seem overly long, and that's even exacerbated in the intro ones. The TOC is pushed further down the page on the desktop, sometimes making it really difficult to get a hold of an article as a whole.
 * But I'd say this is an issue of technical debt, which we'll have to just address in the coming years. We just have to rewrite a whole bunch of stuff, to suit a standard which perhaps wasn't there in the early years, or which wasn't followed, as it should have. Decoy (talk) 17:55, 17 October 2022 (UTC)
 * The problem is not that paragraphs are now the wrong shape (actually with the new theme paragraphs are still somewhat too wide), but that all other content is forced into the same narrow column. A significantly better solution is to limit the width of paragraphs (or other body copy) while allowing data tables to be wider and leaving diagrams/figures in the right-hand margin. –jacobolus (talk) 18:21, 17 October 2022 (UTC)
 * Totally agree.
 * I've 20-20 on both eyes but, EVEN WITH THE OLD LAYOUT was already using 125% zoom from desktop for comfort. With this new design there is too much wasted space from desktop.
 * While consulting wikipedia happens mostly from mobile, when I edit a page or write a new one I always do it from desktop, and the new design is not comfortable both from editor and viewer POV. Dreamaker (talk) 11:00, 18 November 2022 (UTC)

After reviewing the posted defense of the narrowing and the feedback listed here, this feature belongs entirely as an optional setting. It most certainly should not be the website's default. RightQuark (talk) 01:29, 24 May 2022 (UTC)
 * The defence of the narrowing seems to have little real-world bonuses. It may be theoretically good but makes it bad to read because Wikipedia articles can be long Torqueing (talk) 17:10, 24 May 2022 (UTC)

I also have a wide screen monitor. I do not like this forced width shrinkage in the Vector 2022 skin.  OhanaUnited  Talk page  17:24, 9 June 2022 (UTC)

In current form without a toggle for width this layout is unacceptable on large monitors. Even my old 14'' monitor. For now I am reverting to avoid having in forced horizontal white-space. phatom87 (talk) 14:32, 20 June 2022 (UTC)


 * Absolutely unacceptable, too narrow, an unjustified waste of space. Loupeter (talk) 10:39, 24 June 2022 (UTC)


 * It sounds like the fixed-max-width (assuming one's window is wide enough, and regardless of how much wider it might be) is a compromise between the needs of two different types of reading activities. I have both habits (skim vs detail-read), and felt especially the concern that the text doesn't obey what *I* do with my window. A reason I might widen my window is exactly because I want wider content. A comprimse necessarily isn't ideal for either one side. A better solution is to make it easy and discoverable how to get the *best* feel for whatever one is trying to do, rather than forcing so many to have a sub-par experience. A third-party gadget isn't discoverable and is surely more fragile than a first-class toggle feature of the skin itself. DMacks (talk) 15:16, 29 June 2022 (UTC)

In my opinion, Skin:Timeless does a much better job at restricting article space to improve readability. This is because the UI is not entirely positioned on the left-hand side of the screen, and the background colour is not blindingly bright. If the intention is to create whitespace, please don't use bright colours. Timeless also has more space for pictures. For the past 20 years, articles have been written with the understanding that 80%+ of the screen will be for content. There are width and upright tags all over the place that, once viewed with this narrow a perspective, become overwhelming.

A skin should not change the fundamental readability of the page. Compare this with this. In Timeless, when the content ends, grey begins. In Vector 2022, it looks like the HTML was corrupted and failed to load because it continues with white for no discernable reason. Vector also artificially makes articles look longer than they are, which may actually dissuade people from reading. For instance, using a 27" 16:9 monitor, on the article for Barack Obama, Vector just about lets me see the entire lead on my screen at once. Timeless allows me to see the whole lead quite easily, as well as part of the ToC. Line length may be a thing, but you must take into account the total amount of text on the screen at once, too. There's no use having the perfect 50 character line if you need 100 of them all bunched up together. Anarchyte (talk) 13:18, 13 July 2022 (UTC)


 * Quick update and aside: I just learned about wide-vector-2022. This is fantastic. I actually like the ToC being placed where it is when using that gadget. If the plan was to make the wide skin the default, I would be less hesitant. For comparison with the links in my previous message, here is Barack Obama with wide-vector-2022. Anarchyte (talk) 13:25, 13 July 2022 (UTC)
 * This "wide-vector-2022" version should be the default IMO. Some1 (talk) 02:50, 17 July 2022 (UTC)
 * It's definitely an improvement, but Vector 2010 is still better. I agree with @Anarchyte - Timeless does a better job of restricting article space than Vector 2022 does. When you look at how much of the left third of the screen is blocked off from article content, Vector 2010 restricts it the least, followed by Timeless, and then finally by Vector 2022 consuming nearly an entire 1/3 of the screen. At low DPI, it's hilariously ugly, and arguably makes readability worse, not better. Vector 2022 sure would be nice though, if the ToC was collapsible! -αβοοδ (talk) 17:48, 29 July 2022 (UTC)
 * > For the past 20 years, articles have been written with the understanding that 80%+ of the screen will be for content.
 * I'll just note that for the past 10 years that means you've written things that just do not work that way on mobile. :)
 * > A skin should not change the fundamental readability of the page. [..] In Vector 2022, it looks like the HTML was corrupted and failed to load because it continues with white for no discernable reason.
 * This seems like a lot of assumptions to me personally. Do we have wider evidence for this ?
 * > There's no use having the perfect 50 character line if you need 100 of them all bunched up together.
 * Literally every mobile user on the Barack Obama page, the majority of the readers. Screens and screens till you hit the end of the lead... —Th e DJ (Not WMF) (talk • contribs) 20:20, 14 July 2022 (UTC)
 * I'll just note that for the past 10 years that means you've written things that just do not work that way on mobile. :)
 * MinervaNeue, when viewed on normal phone screens, ignores width tags. The only difference between writing for desktop screens and mobile screens is file placement.
 * This seems like a lot of assumptions to me personally. Do we have wider evidence for this ?
 * I don't need to provide evidence to state my opinion. The page looks unfinished with the extra whitespace on the right hand side. If you do want more than just my opinion, CNTRL+F for "whitespace" on this page. 12 other posts mention it.
 * Literally every mobile user on the Barack Obama page, the majority of the readers. Screens and screens till you hit the end of the lead...
 * Difference is that my phone is in my hand. I'm not getting overloaded with line after line if the screen is only 15cm long. I can see a whole paragraph on at once and then scroll when necessary. Anarchyte (talk) 13:10, 15 July 2022 (UTC)
 * Yes, I would like some grey or light blue background, and maybe even a soft page shadow. Gugalcrom123 (talk) 16:40, 1 November 2022 (UTC)

I'll just leave my disappointed note as well, purely for adding the length to this discussion (especially we are operating on what seems to be 500 px wide area [apparently it's 1200, so 46% of my current screen]). I tried to convince myselft to new vector at least four times now as I find most of it's designs quite pleasing. But this width thing is riddiculous. Any article starting with an infobox look like a comic strip. So much space is wasted. I'm still using a gadget hiding menu to get MORE WIDTH on the old Vector for example to use new preview mode in code editor. The most I can get from new Vecor is 2 × 740 px (if I close the menu). And then I still have 2 × 475 px of emptyness. Terrible idea. Arvedui89 (talk) 12:20, 23 August 2022 (UTC)

Hello! I feel the menu section, on the left side of the screen, is too wide. (Leaving the article page too narrow) Thanks!
 * Agreed: too narrow - Aboudaqn (talk) 17:50, 11 September 2022 (UTC)

Too narrow, that's a blocker for me, switching back, thanks. Others detailed above pretty well. --Grin (talk) 19:13, 11 September 2022 (UTC)

I've made a quick stylus script to set the container width at 100% and I'll sure be keeping that way. Having that much leftover whitespace on the right side without having it on the left really messes with the balance of the page. InvalidCards (talk) 19:51, 11 September 2022 (UTC)


 * Too narrow. How could I configure it? JOAN (talk) 03:23, 18 September 2022 (UTC)
 * The new skin is an anorexia of older one to be similar to mobile version. Ed1974LT (talk) 17:37, 26 October 2022 (UTC)


 * What a weird idea to make the text not use the full space... reverted back and hope this crazy skin will never show up again. 2003:D3:7F40:A500:8821:B2F5:7ABA:7E7C 00:24, 20 November 2022 (UTC)

Alternate options that preserve the primary goal
The reasoning makes sense, and the team working on this would know better than I about their merits. But are there not alternate options that preserve the primary goal (limiting character count per line) while not resulting in a too-narrow page?

The text can be enlarged on wider displays/windows. Images could be moved from in-line to the side. The information boxes could be made wider. Other options that I can't think of. I don't know how trivial this is to navigate with the multitude of screen sizes that exist out there.

I have to agree with others that the pages feel too narrow, even if the reasoning is perfectly logical. The prototype 4 you link looks "right" if I zoom in by 20% in my browser... Geistbar (talk) 00:26, 28 August 2022 (UTC)


 * Hello. Thank you @Geistbar for your kind comment. I appreciate that you have thought about our reasoning.
 * We are aiming at something that wouldn't be too wide - experience which would be different than (and better from) Vector legacy or Monobook. Then, the threshold for the content area being too narrow depends on both individual user's favorite settings and the type of content on a given page. We have tried to find the optimal width.
 * Would it be possible to increase the font size? Yes, we're considering that, and if we do that, we'll make the content area proportionally wider. When it comes to moving images, infoboxes, other type of content (footnotes, for example), it doesn't appear to be possible. I mean, I think we can't move the content outside of the content area. There's a strict line of purely technical nature between the interface (provided by us, developed in collaboration with the community) and content (which we don't touch).
 * Instead, we'll be able to put other things there that would belong to the interface, be set up by the communities, but wouldn't be regular part of content. The "related pages" is more or less this kind of thing. SGrabarczuk (WMF) (talk) 23:05, 1 September 2022 (UTC)
 * PLEASE DON'T INCREASE THE TEXT. I can't read 28px. Gugalcrom123 (talk) 16:41, 1 November 2022 (UTC)
 * Isn’t the simplist ‘alternate’ idea perhaps also the most straightforward:
 * Don’t restrict line length at all, and let users, when they choose, invoke the ‘reading mode’ included in most recent web browsers on both computers and mobile devices?
 * Most (all?) skins likely support this already.
 * (I believe browsers generally use the  HTML5 tag, when present, to identify which content to display.)
 * (If meddling ~is~ desired, perhaps only limit line length when the user is using certain text zoom levels, if that can be ascertained using Javascript.)
 * Why re-invent the wheel, especially when there is so much disagreement on ‘preferred line length’?
 * - Jim Grisham (talk) 19:02, 19 September 2022 (UTC)
 * The “reader view” in web browsers is a clumsy workaround which serves as a last resort for reading terrible (especially ad-infested) websites that have no respect for their readers, not an excuse for websites to intentionally make their pages illegible. –jacobolus (talk) 19:35, 19 September 2022 (UTC)

Surprising to see the first thing here is a complaint about not using wide screens adequately. I came to complain about the exact opposite issue. When browser window is narrow enough that I can have 2 browser windows open side by side, the left menu takes over the whole upper part of the page and creates this unwanted situation where all the content is a whole screen down.98.30.137.144 18:17, 10 September 2022 (UTC)

For anyone interested in this kind of thing, I use a very mildly customized version of the 'monobook' theme which has been working great for me for many years. All I do is limit the max-width of paragraphs and a few other elements, while letting images float all the way to the right (and also letting multi-column appendices do their normal thing). In my opinion this works much better than trying to squeeze the whole page into a smaller width including floating images and other marginalia:

This works great, allowing me to see images floating to the side out of the way of the text while the text itself doesn't get to be outrageously long. I am sure my CSS is not correctly handling rare exceptional cases, and there are probably other improvements that could be made. But the basic idea seems right. Cheers! –jacobolus (talk) 18:54, 10 September 2022 (UTC)


 * The smaller width was the first thing I noticed and I like it. It feels like less work to read the page. I recently changed my Emacs configuration to change the width because it's easier to read this way. Agree that an option for users with different opinions should be there, but tightening up the page is not universally loathed. I don't like changing my window size because I always have my windows maximized and it bothers me to see something different on the other half of my monitor.

--Skyvine (talk) 19:55, 13 September 2022 (UTC)

Just learned of this update when I went to en.wikipedia this morning. The narrow content area was a bit of a shock, but seems mostly readable (depending on page layout like infoboxes and inline images). However, the area to the right of the content is wasted screen space. Why not put the TOC there instead of below the tools? --Theodore Kloba (talk) 13:37, 22 September 2022 (UTC)


 * What a good idea. Gugalcrom123 (talk) 16:42, 1 November 2022 (UTC)

I use an old fashioned CRT monitor. The new vesrion os edit is hadr to read because of small letters in the screen. 31.46.247.19 15:49, 22 September 2022 (UTC)


 * I have just switched back. It was too narrow. Hard to work with it on a wide screen. --130.255.159.66 16:39, 25 September 2022 (UTC)
 * I agree, it is just too narrow. Long articles look even longer which may discourage readers from actually reading it (it is really just psychology, like the case of water glasses that have the same volume but different glass shapes make people think one is larger than the other). Please do not waste such a big space on the sides.... Xia (talk) 07:44, 18 October 2022 (UTC)


 * I hate being that guy to pile on but it really does seem too narrow on a wide-screen monitor. My only thought is that maybe the font should be bigger and the space on both sides is smaller. That said, I know everyone involved is doing amazing work with a really difficult set of requirements. --Wwahammy (talk) 17:43, 18 October 2022 (UTC)
 * Completely agree. I was interested in the new design for about 0.5 seconds until I saw how much space was being completely wasted. Until this is resolved, I (and it sounds like many other people), have no intention of downgrading to the new skin. Avereo (talk) 05:10, 20 October 2022 (UTC)
 * Xania is 100% right and I see several similar comments. Mr SGrabarczuk is tone deaf to the criticism he receives, and implemented it on the Afrikaans wiki, for instance, despite a majority of negative replies beforehand. Neither do I believe in his claimed research. It looks and feels like a skin for preschoolers, intended to dumb it down (in the negative sense) for users. Ridiculous waste of space, and interference with the way we work and read, drop down menu that goes over the bottom of my page, juvenescent terminology, and messy, poorly organised and not very visible language links. JMK (talk) 12:19, 22 November 2022 (UTC)

Trouble With Zooming In
My vision is poor so I usually zoom to 200% on my browser and it is no problem. With the new skin that same magnification causes the sidebar to take up the top of my screen and I can't see the title of the article and know what page I'm on without scrolling. 19:30, 29 May 2022 (UTC)
 * Moving article tools.jpg
 * Hello, thank you for your comment. I'm sorry it took so long for us to notice it! We have changed how the sidebar works on smaller screens (and, I presume, on any screen with a large zoom set up). I hope it works better now. Soon, we'll also move some links from the sidebar to the other side of the screen. This will make the sidebar shorter. I'm curious what you think. SGrabarczuk (WMF) (talk) 21:37, 9 December 2022 (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)
 * @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)

Article overview
Having some experience with software redesign and the resistance of the old guard, I decided to challenge my own conditioning. I have to say I can live with the new interface. I would however have liked the article overview (section headings) to come up higher (perhaps in a scrollable box of fixed height so that other links are in predictable and constant positions). Shyamal (talk) 09:06, 14 September 2022 (UTC)
 * I found two issues that affect me (a minority user no doubt) (1) using the reader view of Mozilla Firefox (on Windows) - some long articles on en.wiki with the new vector skin do not produce a clean uncluttered page as before (see for instance en:Allan_Octavian_Hume). (2) the Firefox add-on Who Wrote That which I use as a convenient tool does not work with the vector 2022 skin. Shyamal (talk) 15:36, 17 September 2022 (UTC)
 * Hey @Shyamal, sorry for replying late. Thanks for the positive comment!
 * About Who Wrote That?, I've informed the Community Tech team who has developed that tool. Hopefully, they'd be able to update the code. (Unless something has changed and it's working now?)
 * The Reader view, this problem is tracked on Phabricator here: T318099.
 * Regarding the table of contents, does it work for you now?
 * SGrabarczuk (WMF) (talk) 21:18, 9 December 2022 (UTC)
 * I just switched back to Vector 2022 - yes, I see Who-Wrote-That now working and TOC looks better than it was before. Look forward to seeing the Reader View fix as well. I really know how sometimes one just has to go away from some older underlying library dependencies and problems which are sometimes hard to explain to end users. Shyamal (talk) 07:24, 10 December 2022 (UTC)

Graphic frame of the page looks unclear
The graphic frame of the page outline is broken,

The connection between the text and the image is unclear, bad.

Return the last version, please!

Thanks Dobroš (talk) 04:41, 22 September 2022 (UTC)


 * Hello @Dobroš. Sincere apologies for such a delay, I don't know how this section got lost ://
 * Can you tell us more what you're referring to as the graphic frame? You may be interested in reading our FAQ section about the limited width and the detailed feature page about the limited width to learn why we've made this change.
 * If you like, you may also reply in Czech. I could ask @Martin Urbanec (WMF) for help if I don't understand something. SGrabarczuk (WMF) (talk) 01:13, 7 December 2022 (UTC)

Give more time to allow discussion in Spanish Wikivoyage
Give more time to allow discussion in Spanish Wikivoyage before deploying the new skin. This topic has not been commented yet and the community thoughts and improvement suggestions could be useful. --Onwa (talk) 14:26, 3 October 2022 (UTC)


 * The first comments from the discussion showed up that the new skin forces the project to make redesign fixes to the Main Page. Some other visual templates (pagebanner, EstáEn, Routebox, Lista de regiones, ...) are still being evaluated, but some of them does not have major issues. We'll keep you informed. Onwa (talk) 00:34, 15 October 2022 (UTC)
 * Hola @Onwa. Muchas gracias por tu mensaje. Te respondo en español, pero si prefieres que nos comuniquemos en inglés, solo házmelo saber. Te informo que Vector 2022 no será activado en Wikiviajes de manera inmediata, probablemente será en torno a febrero de 2023 cuando se convierta en la skin predeterminada en es.wikivoyage. Daremos aviso a la comunidad cuando tengamos una fecha más cerrada. Por tanto, hay tiempo para seguir discutiendo y evaluando aquello que sea necesario. Por favor, si hay algo con lo que podamos ayudar o que quieras hacer llegar al equipo, o si tienes cualquier duda, puedes responder en esta página (en el idioma que prefieras) o contactar directamente conmigo (y yo me encargo de trasladar el mensaje a la persona indicada dentro de la WMF). Muchas gracias. Un saludo. Zapipedia (WMF) (talk) 18:15, 7 December 2022 (UTC)

Contribution button
There is a Watchlist button but not a contribution button. I use the contribution page way more often then the watchlist. बडा काजी (talk) 00:29, 20 October 2022 (UTC)


 * Jdlrobson (talk) 22:43, 28 October 2022 (UTC)
 * I'd really like direct access to my Special:Contributions page, and have heard similar from a few colleagues & peers.
 * Use-cases: It's the easiest way to access "What was I doing yesterday?" or "How did I implement that related fix a few days ago?" or "I need to add something else at that page I just edited a few moments ago". Some editors use it as their general reminder list. I access it multiple times every day.
 * I tried to hack it together with user.js, which half-works, but I can't determine how to use the icon instead of text (screenshot). How do I do that? Or…
 * Ideally, I could do it in pure CSS, so that it can be part of my Vector-2022-condensed.css, but I'm not sure if that's possible?
 * Advice appreciated. –Quiddity (talk) 01:21, 5 December 2022 (UTC)
 * Hi @बडा काजी - thanks for your feedback. The current user menu is based on the usage of different navigation elements across logged out and logged-in users.  The contributions link is now available in the user menu, immediately next to the watchlist button.   OVasileva (WMF) (talk) 16:17, 31 October 2022 (UTC)

Creation of new template - issue
Hi, I tried new vector (2022) on mk.wiki, and when I want to create new template, I cannot insert any data in the open window. How is that possible? I did not have any problem with old vector. --Ehrlich91 (talk) 08:33, 25 October 2022 (UTC)


 * Hello @Ehrlich91, my apologies, we must have not noticed your question somehow! :( Is this still happening? I doubt if this is about the skin (and no one else reported any similar problems) but if you still face this, we'll try to help. SGrabarczuk (WMF) (talk) 19:37, 9 December 2022 (UTC)
 * @SGrabarczuk (WMF) Now, it is completely fine. Probably, you are right, in that moment it was something else, not connected with the new skin. --Ehrlich91 (talk) 08:25, 10 December 2022 (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)

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)

Giant borders
Hi, I noticed that Wikipedia is advertising the Vector 2022 skin as the "new look", I'm not sure I like it though since the borders are almost twice the size as the legacy skin, making it difficult to find screen items, since less of them appear onscreen at a time. It resembles something I would see on a mobile phone. Zooming out partially fixes this, but as a side effect it makes the text/images on said border shrink as well. Just my two cents. - Coolman2917 (talk) 12:22, 8 November 2022 (UTC)


 * Hey @Coolman2917, thanks for your feedback. You might be interested in the conversation here: https://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Deployment_of_Vector_(2022)#Update_on_the_fixed_width_and_white_space, and some of our documentation here: Reading/Web/Desktop Improvements/Features/Limiting content width. AHollender (WMF) (talk) 22:46, 8 November 2022 (UTC)
 * Oh ok. Thanks! -Coolman2917 (talk) 01:45, 9 November 2022 (UTC)
 * I'm using it on an 21' Imac Retina display. I know, you discussed this already but still: it just looks like wasting space for nothing and I'm not able to get the overview I would need, to feel myself outside the message, I'm given. I feel like being just thrown right into it, and can't get a Point of view from above (like a neutral one should be). Sorry, I feel very unhappy with it. very POV. Please, please keep the old one. Louise d&#39;Épinay (talk) 22:49, 17 November 2022 (UTC)

Log-in button missing when anonymous editing is disabled
When anonymous editing is disabled, Vector 2022 doesn't show the log-in button. Is that a bug or a feature?

MediaWiki: 1.39.0-rc.1

Cheers, Devaroo (talk) 15:50, 17 November 2022 (UTC)


 * Hi @Devaroo, thank you for your question and apologies for the late reply! Are you still experiencing this issue and on which wikis?  I believe we solved this in this ticket. OVasileva (WMF) (talk) 20:33, 13 December 2022 (UTC)


 * @OVasileva (WNF), I just upgraded to 1.39.0, and I'm having this issue on my wiki. I cannot figure out how to fix it, and any help would be appreciated. —Grlucas (talk) 14:37, 15 December 2022 (UTC)


 * OK, I downloaded the current version of the skin, and that fixed it. Apparently the fix is not included in the 1.39.0 tarball yet. —Grlucas (talk) 15:19, 15 December 2022 (UTC)

Sandbox icon
Where I can find at Commons the sandbox icon from the user menu? P.S. I like T314727. -- NGC 54  ( talk |  contribs ) 15:58, 17 November 2022 (UTC)


 * Hey @NGC 54, all interface icons can be found on the Codex website: https://doc.wikimedia.org/codex/v0.2.1/icons/all-icons.html AHollender (WMF) (talk) 20:57, 13 December 2022 (UTC)
 * @AHollender (WMF): These icons are no located at Commons, too? I want to use the icon on ro:Utilizator:NGC 54/Bară de navigare. -- NGC 54  ( talk |  contribs ) 00:04, 14 December 2022 (UTC)
 * @Volker E. (WMF) @Sarai Sánchez (WMDE) do we have a process in place for uploading all Codex icons to Commons?
 * @NGC 54 if it's helpful for now, here is the SVG code:
 * AHollender (WMF) (talk) 16:02, 14 December 2022 (UTC)
 * @AHollender (WMF) No, we sadly don't have one. There was a similar request in the past for OOUI, but it got deprioritized for technical issue reasons and lack of urgency. 52.119.124.223 06:05, 15 December 2022 (UTC)

Black Friday
Hi. Is it really a good idea to change stars color on every page page in watchlist from blue to black? IKhitron (talk) 12:15, 18 November 2022 (UTC)


 * Hi User:Ikhitron, why is it not a good idea from your perspective? Your thoughts around the value of colored icons is welcomed on T317710. Jdlrobson (talk) 18:39, 22 November 2022 (UTC)
 * Because for me it looks very unintuitive. IKhitron (talk) 20:03, 22 November 2022 (UTC)

Amazing work
The new redesign makes Wikipedia far more modern and usable. Thanks all of the developers for your work! CactiStaccingCrane (talk) 07:52, 20 November 2022 (UTC)


 * i like it, too. Dnvuma (talk) 16:50, 20 November 2022 (UTC)
 * Thank you, @CactiStaccingCrane and @Dnvuma. I'm very glad to read your comments! SGrabarczuk (WMF) (talk) 02:31, 23 November 2022 (UTC)

Review layout breakpoints
You did a great job with the redesign. I really like the content overview on the left, and the fact that it's convergent (no separation between m.wikipedia.org).

But on my 16:10 laptop screen, with a browser sidebar opened (I use tree style tabs to organise my tabs), the side bar already collapses to a hamburger menu. This is really annoying, the whole page feels like an oversized mobile page and uncomfortable to navigate. I can't really take advantage of the contents overview this way. It would be nice if you could re-eveluate the layout break points and make sure that the sidebar only gets collapsed when it's really necessary because of the screen size.

Janopae (talk) 11:53, 21 November 2022 (UTC)


 * Hey there! I am personally working on a fix for this problem as we speak T317899. The current state is only interim, as the main focus has been on desktop breakpoints. Hope this is helpful! Jdlrobson (talk) 18:28, 22 November 2022 (UTC)
 * @Janopae thanks for your feedback. To clarify your comment, and make sure that we're understanding it correctly, could you add a few screenshots, preferably annotated (either directly on this page, or a link to a screenshot hosted elsewhere if that's easier)? AHollender (WMF) (talk) 21:31, 13 December 2022 (UTC)
 * Thanks a lot for working on this issue. Have break points been modified since I posted this? As currently, it looks fine on my screen, even with a sidebar opened. Maybe I had the page zoomed when making the request.
 * Screenshot_Vector_brakboint_at_110%25_zoom.png
 * As with 110 % zoom, the sidebar is collapsed, while I think showing the sidebar would still be appropriate with this layout.
 * Screenshot Vector sidebar expanded at 110 % zoom.png
 * It feels especially inappropriate when the sidebar is opened an covers the whole screen.
 * Janopae (talk) 18:06, 23 December 2022 (UTC)
 * Janopae (talk) 18:06, 23 December 2022 (UTC)

Sticky header
Overall, I like the sticky header. But I would like acces to sticky header while editing (I often use the search widget while editing) and while viewing special pages like Recent changes and histories (while looking in the history, I often want to edit the page or switch to another language). The lack of access to alerts and notices (notifications) and sidebar in the sticky header is annoying. I have a access Beta in the sticky header, but not to the notifications? I use the notifications daily, while the Beta link almost never. -- NGC 54  ( talk |  contribs ) 15:07, 21 November 2022 (UTC)


 * @NGC 54 I agree that it would be useful to have notifications in the sticky header. Regarding the sticky header in editing mode, ping @PPelberg (WMF) @ESanders (WMF). AHollender (WMF) (talk) 21:33, 13 December 2022 (UTC)

Adaptacion a lo ancho de pantalla
Hala, en general me parece bonito el diseño de interfaz vector 2022 pero deberian adaptarlo a lo ancho de las pantallas anchas, si una pantalla es de 16:9 (estandar actual) hagan la pagina en 16:9, si la pantalla es 4:3 (actualmente descontinuado) haganlo en 4:3, les recomendaria que pusieran un pluguin o un detector en el codigo de la página a la hora de que se cargue para que la propia pagina (en funcion de la resolucion) pueda elegir el formato correcto / resolución correcta para el equipo cliente que solicita acceso a wikipedia.

Por lo demas está bien, interfaz sencilla, lineas clásicas, iconos remodelados, etc... en general un buen trabajo en el rediseño de la UI, a excepción de lo comentado anteriormente que si lo solucionan podria ser incluso hasta mejor. Daniel Borrajo fernández (talk) 22:04, 21 November 2022 (UTC)


 * Hola @Daniel Borrajo fernández, disculpa la tardanza en responder. Lo primero, queremos agradecer tu mensaje y la valoración positiva del trabajo realizado con Vector 2022. Respecto a tu comentario, nuestra interfaz ha sido concebida para diferentes proporciones y no de manera específica para 16:9 o 4:3. Por eso, nos gustaría entender mejor por qué consideras que se trata de la proporción de aspecto, ¿tal vez sea una cuestión del tamaño o la resolución de pantalla? Cualquier comentario adicional que quieras hacernos llegar, estamos a tu disposición. Muchas gracias. Saludos. Zapipedia (WMF) (talk) 17:48, 7 December 2022 (UTC)
 * @Daniel Borrajo fernández it would also be helpful if you could include screenshots, so we know specifically what you are referring to. Thank you : ) AHollender (WMF) (talk) 21:34, 13 December 2022 (UTC)

Page tools deployment
When do the new menu for page tools (Reading/Web/Desktop Improvements/Features/Page tools) will be deployed? From this edit I understand that sometime after 12 January 2023. Why? I hate to open the sidebar anytime when I want to acces the page info, the contributions list, the user logs... -- NGC 54  ( talk |  contribs ) 15:18, 22 November 2022 (UTC)


 * We have only just begun building this feature and need time to build it first :-). Note, there are limited deployments in December (see recent wikitech-l thread) so this also contributes to the projected date of January. Jdlrobson (talk) 18:25, 22 November 2022 (UTC)

Logging-out via sticky header
When I try to log-out via sticky header, I always have to click twice: once on the log-out button, then on the blue button from Special:UserLogout. This is annoying. -- NGC 54  ( talk |  contribs ) 13:15, 23 November 2022 (UTC)
 * Hey @NGC 54. I don't know, this may just as well be a solution to the problem of too many misclicks... I've reported on Phabricator, let's maybe continue the discussion there. SGrabarczuk (WMF) (talk) 01:37, 7 December 2022 (UTC)

Link to edit the lead is above the link to edit the whole article
I switched over to the 2022 Vector skin temporarily to test something (WMF still hasn't fixed the width problems? Yikes!), and I noticed that the [ edit ] link that allows editing of the lead section (this may be a gadget?) is aligned on the right side of the line containing the article title, while the link to edit the entire article is below that, on a link with Read/Talk/etc. The [ edit ] link to edit the lead should be below the whole-article Edit link, at the top of the lead section. Jonesey95 (talk) 17:15, 24 November 2022 (UTC)


 * @Jonesey95, what width problems are you referring to? If you mean the ability to switch between the limited and full width, there's been a preference for some time now, and ~1-2 weeks ago we added a toggle placed in the bottom right corner of your screen if the screen is wider than 1600px.
 * Regarding the [ edit ] link, I'll talk to my colleagues and see what's possible. And yes, this is a gadget. SGrabarczuk (WMF) (talk) 14:41, 25 November 2022 (UTC)
 * The width problem is that the body of the article is much too narrow by default, as hundreds of editors have told the WMF for months. Logged-out readers won't have access to preferences, and 1600px is too wide for a minimum "show a toggle" setting; my 1280px screen is fine in every other skin, but 2022 Vector makes a hash of article layout. I just ran into a problem this week at en.WP (see this discussion) where, because the 2022 Vector body width is so narrow, a batch of articles might have to be manually modified to avoid poor content flow in the articles for the vast majority of readers (i.e. logged-out non-editors using what will no doubt become the default skin). The affected articles look fine in every skin except one. It reminds me of the browser wars, where pages had to be tweaked manually so that they displayed properly for different classes of viewers. I thought those days were gone. Jonesey95 (talk) 18:30, 25 November 2022 (UTC)
 * Same issue here (that is: section title not the width deviation): unexpectedly, the [edit] order for Article and Top section is in illogical order. Using Vec2022 for a month or so, still not "used" to it (of course, the swap is a mental trick to "learn" by Pavlov not a new feature). DePiep (talk) 15:56, 1 December 2022 (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)

Visual improvements
I love them! My general preference is for option 1 for most of the improvements, but personally option 5 for the TOC is compelling. I feel that it's a fresh look that emphasizes the level 2 sections when navigating subsections well. Cheers! EpicPupper (talk) 02:40, 29 November 2022 (UTC)

The proposed design at phab:T314727 looks better than the current one. -- NGC 54  ( talk |  contribs ) 22:33, 7 December 2022 (UTC)
 * Thanks @EpicPupper. I'm glad you like it. It looks like we've made all (?) of the planned visual refinements except for the font size increase, but that's because we've decided to make it a topic for a different discussion later, after the deployments. Talk to you soon on English Wikipedia! SGrabarczuk (WMF) (talk) 01:40, 7 December 2022 (UTC)
 * "It looks like we've made all (?) of the planned visual refinements except for the font size increase"

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)

Font is too small by default for a 24-inch monitor, compared to Timeless
It’s more difficult to read an article because the font is simply too small (24-inch monitor; approximately 218 pixels per inch).

Is the font size adjustable without editing CSS?

Or can the developers simply change the font size to be the same as Timeless, which is readable on a 24-inch monitor? Stephenamills (talk) 03:18, 2 December 2022 (UTC)


 * Hello @Stephenamills! Thanks, that's a good point. Yes, it is possible to increase the font size. In the future, we will perhaps talk to the communities about doing that and making the content area a bit wider. Here you can read more about why we would like to do that.
 * In my personal CSS, I've got this:
 * I wouldn't recommend everyone to copy this or make it the default on any wiki, but this should be working for individual users. SGrabarczuk (WMF) (talk) 00:44, 7 December 2022 (UTC)
 * I wouldn't recommend everyone to copy this or make it the default on any wiki, but this should be working for individual users. SGrabarczuk (WMF) (talk) 00:44, 7 December 2022 (UTC)

عدم ظهور جدول المحتويات في بعض الصفحات
مرحبًا بالجميع وشكرًا على العمل الجبار الذي تقومون به، لاحظت أن بعض الصفحات لا تحتوي على جدول المحتويات مثل و  في حين أنها تظهر في باقي الصفحات المماثلة مثل  و

en:Hello everyone and thanks for the great work you are doing, I noticed that some pages do not contain the table of contents such as and  while they appear on the rest of the similar pages such as  and  Cordially Nehaoua (talk) 21:51, 2 December 2022 (UTC)


 * @Nehaoua In all skins, the table of contents only appears when there are 4 or more ==headings==. See m:Help:Section for details. (Or m:Help:Section/ar). –Quiddity (talk) 00:55, 5 December 2022 (UTC)
 * @Quiddity thanks, I understood cordially Nehaoua (talk) 10:05, 5 December 2022 (UTC)
 * @Nehaoua if you are interested in following along, we are hoping to eventually change this behavior in https://phabricator.wikimedia.org/T318186 AHollender (WMF) (talk) 21:44, 13 December 2022 (UTC)

Custom language switcher
Hello. Is the a way to create a new language switcher intentionally? Something as  that will create another language swicher, at the transclusion place, for the parameter Wikidata item, not relevant at all to the regular page switcher, based on this page's item. Thank you. IKhitron (talk) 02:31, 8 December 2022 (UTC)


 * Hi @IKhitron, that's interesting. This seems like a question to Language team though because we only decide about the location of the button, and they decide how it works. I've informed them about your question. SGrabarczuk (WMF) (talk) 14:11, 9 December 2022 (UTC)
 * This is not an official answer from the Language team :)
 * @IKhitron, it may be technically possible using some JS and CSS tricks, but what exactly do you want this language selector to do? It's called universal because it provides the selection interface, but what selection means is totally custom and up to the developer. Amir E. Aharoni &#123;{🌎🌍🌏}} 09:13, 11 December 2022 (UTC)
 * Great, how? While we have interwiki for redirects now, I'd like to have a way to navigate from a section connected to an article. IKhitron (talk) 13:19, 11 December 2022 (UTC)

My username overlaps with the notifications buttons
My username is rather long, so I can understand why this was not caught earlier. But my username overlaps with the notifications buttons on the top right. There is ample space available so it’d be great if the language switcher could move to the left to accommodate my longer name or if it could be truncated (preferably with “…”)

Here’s a screenshot. The offending layout is in the top right.

https://imgur.com/a/HJ53rs2 Theanswertolifetheuniverseandeverything (talk) 14:50, 9 December 2022 (UTC)


 * Hi @Theanswertolifetheuniverseandeverything - thank you for flagging this! This is a bug. I've filed a ticket to track this.   OVasileva (WMF) (talk) 20:20, 13 December 2022 (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)
 * 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)

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)

Watchlist notice covered up buttons
Sometimes when I accidentally click on the watchlist button, the notice can cover up the button itself and history tabs as well, and the only way that I can get rid of the notice is to refresh the page. CactiStaccingCrane (talk) 07:03, 11 December 2022 (UTC)


 * Hello @CactiStaccingCrane. Thanks for reporting this. Have you tried clicking the notice? It should disappear - this is a quick way of getting rid of it. This method should be working on any skin.
 * As of now, the issue you're reporting is unavoidable on some screens. We hope that we'd be able to work more on the tabs when we'll be working on our next project, but it'll take us months to make any changes. SGrabarczuk (WMF) (talk) 21:41, 13 December 2022 (UTC)

Less functional article language switcher
Hello. In old skin I can simple add an new language version of particular article – in those new I didn't notice such an option. Also, an old version have link to wikidata under article's languages (as "Edit links") – again, I can't find it. So would I every time have to go to wikidata and find a requested page on myself? It is strongly uncomfortable for persons who work in few languages. --~ Wojsław Brożyna (talk) 09:59, 11 December 2022 (UTC)


 * Here is some related discussion and a link to a Phabricator task: Talk:Reading/Web/Desktop_Improvements/Archive6. AllyD (talk) 09:40, 12 December 2022 (UTC)

Page tools move
Thank you for moving the page tools to the righthand side in a dropdown. Accessing things like "what links here" was my number one reason for uncollapsing the menu, so being able to hover and click on the page tools without doing that will be a lot easier to use. Steven Walling (talk) 17:22, 13 December 2022 (UTC)


 * Thanks @Steven Walling! Yeah, that's the point of making this change.
 * On a side note, did you know that there are also keyboard shortcuts for a few links, incl. "what links here"? SGrabarczuk (WMF) (talk) 21:31, 13 December 2022 (UTC)

Page tools move, the default should be sidebar
I highly suggest keeping the default as sidebar (not as a tab), being more visible is vital in getting more editors, checking random pages, donating, checking recent changes and so on. Emphasizing on those links I think it's important. One big reason is that the tab is quite hidden. I spent quite some time trying to find it Ladsgroup (talk) 19:15, 13 December 2022 (UTC)


 * @Ladsgroup - thanks for the feedback! For logged-in users, the default is going to be open. For logged-out we're planning on the default to be closed.  There is generally very low usage of these links by logged-out users right now, and our research showed that most folks who are logged-out do not understand what these links are or what they do.  That said, we are moving towards building out more context for readers on how wikis work.  The plan here is to have fewer entrypoints into editing, but to have each entrypoint be a bit clearer and more intuitive. OVasileva (WMF) (talk) 21:00, 13 December 2022 (UTC)
 * Makes sense. As long as it's in your radar, I'm happy Ladsgroup (talk) 21:23, 13 December 2022 (UTC)

Page tools move breaks user scripts
Please see T325097 for details. Could you please fix the issue described there, or postpone deployment until the issue has been fixed? CC @SGrabarczuk (WMF). Thanks in advance. Regards, Aschmidt (talk) 20:26, 13 December 2022 (UTC)


 * Thanks for the report @Aschmidt - we will look into this! Currently, the page tools feature is not quite finished so more fixes and changes are to be expected between now and deployment.  We are doing a review of popular gadgets and scripts as a part of development, tracked in this ticket.  However, for some gadgets and scripts, it is possible that the fixes will need to be made on-wiki by anyone maintaining or working on the gadget or script. OVasileva (WMF) (talk) 20:57, 13 December 2022 (UTC)

Page tools move initial thoughts
Hi @SGrabarczuk (WMF) and @OVasileva (WMF)! I just tested out the move of the page tools to the right side of the page per the instructions in the recent newsletter. Overall, the approach looks good, and the rough edges I'll mention below are likely things you'll address before the full rollout, but I wanted to offer my initial feedback while it's still early: That's all for now. Feel free to lmk when there's a newer version to test! Cheers, &#123;{u&#124; Sdkb  }&#125;  talk 23:04, 13 December 2022 (UTC)
 * Twinkle isn't currently merged to the new tools menu, but I think it would be good to do so. Fundamentally, Twinkle tools are tools the same as WMF tools, and from the user angle it makes sense to clump them together.
 * The menu headings could use some work. There's currently some redundancy, with "Tools [move to sidebar]" and then "Tools" again right below it, which is confusing.
 * The "Edit interlanguage links" option that is showing up displays weirdly, in a small font. I'm also a bit confused why it's there at all — there's already a link to the Wikidata item, where the interlanguage info is stored, and changing the interlanguage links is a very rare task that shouldn't use up menu space.
 * I try to limit the number of gadgets I install, but even with my relatively modest package, the menu goes off the bottom of the screen (and would go off the screen even farther if the Twinkle merge above is implemented). This requires me to scroll to get to some items, which is annoying. To fix this, I'd suggest considering having the different sections of the menu show up beside each other rather than above/below each other.
 * Related to the Twinkle menu suggestion: My combined Tools/More menu requires vertical scrolling as well, which is undesirable. I could probably reduce the excessive vertical white space with CSS, but I came here to suggest that Tools be its own menu: Tools / More / TW. There is tons of space available. I love the idea of having this menu at the upper right, which is where I go to do that sort of gnome/administrative stuff anyway. Popping out the left sidebar for the occasional "What Links Here" query and then popping it back in is a lot of hassle. (And yes, I know about the What Links Here keyboard shortcut, but it doesn't appear to work with the Mac's Command key to pop up in a new tab, which is always what I need.) Jonesey95 (talk) 02:07, 15 December 2022 (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)

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)

Better insight about the "Feedback summary" section
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) 14:12, 15 December 2022 (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)

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)

Dismissing ephemeral dialogs
I adopted Vector 2022 early on, and I'm coming to know its new features. I see that it's making more use of ephemeral dialog notifications. A major one I deal with is the watchlist addition. Now, this dialog has a clickable link and a dropdown option, so I was reluctant to click it. But I found that while it obscures some other interface elements I want it to go away more quickly. I recently discovered that it is clickable, so clicking an ephemeral dialog causes it to disappear on command. Unfortunately this behavior is not orthogonal to typical mobile UIs where dialogs can be swiped out of the way, or clicking outside of them causes them to disappear. Elizium23 (talk) 04:58, 21 December 2022 (UTC)
 * Is this intentional behavior and does it apply to all ephemeral dialogs?
 * Is it guaranteed to work going forward, i.e. is it working by design and accepted by the userbase?
 * Is it possible that an enhancement will allow dismissal by clicking outside, like on mobile, or is this infeasible?

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)

Has vector changed in the last 36 hours?
My window looks a lot different today than it did yesterday. His anything changed? Comfr (talk) 07:59, 26 December 2022 (UTC)

Sticky header not working on many en.WP pages
I don't know if this is a new thing or not, or if it is just me or not, since I just started using Vector 2022 a week or two ago, and I have many customizations. When I go to any article on en.WP article and scroll down, the sticky header is visible. When I go to https://en.wikipedia.org/w/index.php?title=Special:Watchlist or https://en.wikipedia.org/wiki/User_talk:Jonesey95 and scroll down, the sticky header does not appear. I would expect the sticky header to work on all, or nearly all, pages. I looked through the list of phab requests and did not see a matching feature request or bug report. Using Firefox 108 for Mac OS. Jonesey95 (talk) 19:26, 27 December 2022 (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)