Talk:Reading/Web/Desktop Improvements

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)
 * @OVasileva (WMF), I noticed some other weird behavior. When jumping to a specific Heading via special:permanentlink I'm not getting to the paragraph but somewhere below that. Might be related. Compare: b:de:Spezial:Permanentlink/1008062 or b:de:Spezial:Permanentlink/1003322
 * Regards --HirnSpuk (talk) 14:20, 4 January 2023 (UTC)
 * I am getting this too. Any time a redirect points to a section, the sticky header bar obscures the first line or two of text at the target page, so one has to scroll up to see if it is the right place (uncover the header). It looks like the page is opened at the right place, and then the sticky header is opened on top of it, covering the top text. This must be compensated somehow to correct for the reduced space at the top of the page for visible content but it is nor immediately obvious how it should be done. I am using Firefox latest version on windows 10 on desktop, and windows 11 on laptop. Effect seems to be consistent and repeatable. I notice that this effect does not occur when using the ToC, so it should be fixable by using a similar procedure. I would guess that for the ToC case, the content frame (whatever it is called), is already defined taking the presence of the sticky header frame into account, so the content is rendered after the header is already in place, so the top is not obscured.Pbsouthwood (talk) 05:52, 10 January 2023 (UTC)

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)

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)
 * Dear, the confusion is in place because you changed the skin without asking for approval from us. If you would kindly take a bit of time and look thru our help pages you will see that help pages must refer to the way items are arranged on the screen. if you do not write Swahili I do not see how you will help us. As you know German wikipedia took a vote to keep the "old" skin as default. And of course, because that is a large an influential community, you have not done anything without their approval. (I guess in enwiki the situation is similar). So if you can live with dewiki for the time being, I do not see any argument why you cannot live with swwiki and old skin default as well. So kindly just tell me what hinders you from reverting? (Except the fact that you do not like it and we are a small and unimportant wikipedia?) And kindly tell me since when community decisions can be just ignored? Kipala (talk) 22:24, 29 December 2022 (UTC)
 * Hi @Kipala -  Our sincere apologies for the delay in response here.  Our intention is not to ignore the consensus of the Swahili community.  We do believe the merits of the new skin for readers of Swahili and want to ensure that we are giving them the best possible experience.  We have discussed internally and have prepared a few options for moving forward.  We've written up these options for next steps and plan on sharing them with the Swahili community on the Swahili Wikipedia Village Pump as well as scheduling a meeting with the community where we can make a plan on moving forward together.  How does this sound?  Thank you and apologies again for the delayed response. OVasileva (WMF) (talk) 20:47, 16 January 2023 (UTC)

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)

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)

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)

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


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

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

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


 * Hey, thanks for reporting this. There are a few different issues, I don't have all the answers yet, so I'll get back to you when I know more.
 * A quick direct to your last thought is that there are other gadgets adding the purge as menu items, for example MoreMenu. Another one is mentioned here: w:Wikipedia:Purge. SGrabarczuk (WMF) (talk) 13:50, 9 December 2022 (UTC)
 * I posted a feature request at the talk page for the clock gadget. Jonesey95 (talk) 01:46, 15 December 2022 (UTC)


 * I don't see any clock in the dropdown usermenu at all, how does one switch it on? I wish we could have more control over the usermenu and what displays without dropdown TBH. Ain92 (talk) 10:42, 19 January 2023 (UTC)

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

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)
 * Boooooo. 👎👎 172.58.174.193 18:44, 18 January 2023 (UTC)
 * Hello @Sarri.greek. This is unfortunately not possible, the same way it's not possible for logged-out users to use Monobook instead of Vector legacy. You can read more in our FAQ (Why is the opt-out link not available for logged-out users?). SGrabarczuk (WMF) (talk) 21:43, 13 December 2022 (UTC)


 * Thank you @SGrabarczuk (WMF). Thankfully, all wiktionaries are in classic style except the French, which we avoid. For wikipedias, we may try to find equivalent projects. Sarri.greek (talk) 10:23, 14 December 2022 (UTC)
 * @SGrabarczuk (WMF), why not add a permanent global little banner line with
 * For Classic Style, log in and click Classic2010 here
 * Sarri.greek (talk) 11:51, 14 December 2022 (UTC)

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


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

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)
 * Hey @Wojsław Brożyna — are you referring to the "Add interlanguage links" link? If so, it will soon be available in the page tools menu on the right-side of the page (show in the image below, with the orange arrow). You will be able to have this menu "pinned", so it is always visible. Let me know if that solves your issue or not. Thanks,
 * [[File:Vector_2022,_work_in_progress_showing_"Add_interlanguage_links"_in_page_tools_menu_to_right_of_article.png|none|thumb|530x530px|Vector 2022, work in progress showing "Add interlanguage links" in page tools menu to right of article]]
 * AHollender (WMF) (talk) 14:06, 5 January 2023 (UTC)
 * @AHollender (WMF) yes, it is that function (but it is visible for me as "Edit interlanguage links") :) Thank you! Wojsław Brożyna (talk) 14:13, 5 January 2023 (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)
 * Thanks for this feedback @Sdkb. Just commenting to let you know that we've taken note of it. Some issues have already been fixed, and the others we're working on. AHollender (WMF) (talk) 14:12, 5 January 2023 (UTC)

2022 is BAD.


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

What ARE thouse gaps?

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


 * Thanks @Jiira for reaching out to us. I guess you added this comment soon after you saw the skin for the first time. Am I correct? Have you maybe had a chance to read our documentation about the white space and the goals for this project? SGrabarczuk (WMF) (talk) 18:29, 15 December 2022 (UTC)
 * Hi @SGrabarczuk (WMF) . I had the same initial white space concerns after checking out Vector 2022 on 16:9 desktop. New format may be better for mobile users, and unification of experience across platforms is admirable, but I will be sticking to 2010 as I am primarily a desktop user. Seldom on mobile, but does this change affect the (android) app (or other apps)?
 * Also, I (probably like Jiira) was brought to this page directly from my account preferences - can that link be updated? Preferences > Appearance > Vector (2022) > Discussion.
 * If you are here like me looking for further information, I suggest https://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Deployment_of_Vector_(2022)#Discussion
 * or
 * Reading/Web/Desktop Improvements
 * Thank you Grabarczuk. MC the MD (talk) 00:22, 14 January 2023 (UTC)
 * I completely agree with the first post here and just look at the screenshots. The new website needs a manual switch to make text fill the whole display width in 2023?! Is this a joke? A manual switch for something which is now automatic on all modern websites made in the last decade??? The switch is not even visible on low resolution displays and we have to zoom out the browser to even see the switch-did someone even test this thing?
 * The first thing that should be done right away is to make the text fill the whole display automatically without any need for user actions and it should work on all widescreen resolutions on modern displays. No one needs so much white space-a little is ok but not the current amount. The users without account are not given any choice-this sucks too. To me it looks we are forced as readers to make an account just to make the site usable. If we do not make an account we have no option to use the page layout we like, no one offers anything to avoid the weird new design. Very bad design overall, I will stop my reading sessions here if this is the only option, sorry but this goes way too much in the wrong direction. I even try to edit some small mistakes but now the motivation to even read will be severely killed. 94.26.15.134 14:18, 17 January 2023 (UTC)
 * Kudos. Absolutely describes my sentiment. I had to browse through dozens of proxy lists for hours just to find a free working residential proxy to comment here. As an avid wikipedia reader who uses a VPN and thus cannot register an account, this new change just handicapped at least 5% of all wikipedia users who must use VPNS in order to access the website because of their country. The new design is so ugly I can't even concentrate on reading anything here anymore. 172.58.174.193 18:37, 18 January 2023 (UTC)

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


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

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

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

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

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


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

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)


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

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

I think this should be the default behavior (anyone else?), but if it can't be, can we at least get a magic word to set that behavior on a page-by-page basis? Or failing that, could we get some vertical lines to emphasize the level of indentation? Swpb (talk) 15:34, 19 December 2022 (UTC)
 * I agree that this behavior is contrary to how TOC UIs have always worked. They should open one level at a time, with a key-press option to allow opening of all levels (on Mac OS, this has always been the Option key). As for the visual distinction between levels, I have found that the best way to get that is to restore numbering. See for the feature request and https://en.wikipedia.org/wiki/User:Jonesey95/common.css for implementation. Jonesey95 (talk) 19:34, 27 December 2022 (UTC)
 * @Swpb thanks for this feedback. Firstly I want to acknowledge that the new TOC is probably the most complex feature within Vector 2022, and I anticipate that we (community & WMF together) will continue to iterate on it for the foreseeable future. We've been hearing a lot of feedback, and it seems like some additional configurability, magic words, or other such things might be valuable (such as T317818, and more high-level things likeT318186). You can see the current collection of tasks here: T325064
 * Regarding your point: should we show all of the sub-sections (h3, h4, h5, etc.) when expanding an h2, or only show the next-level down (e.g. h3)?
 * I think this is probably an 80/20 thing — 80% of the time (or maybe even more) it makes sense to expand all sub-sections at once (because if there are sections beyond h3s, there will not be many of them, so if we have expandable headings at each level it will require a lot of extra clicking), and 20% of the time (or maybe even less) it makes sense to have collapsable arrows/parent sections for each level.
 * In general, headings below h2s don't seem to be used in a very consistent way across articles. There is not always a clear difference between an h3, an h4, and an h5. Often times it seems to be an editorial/stylistic choice. However h2s do seem to be significantly different than other headings (both in terms of how they are used, and how they are styled). Therefore I think there's an argument to be made that we can draw a line between h2 and h3/h4/h5/etc., and say that h2s are special, and therefore can be treated differently (with this unique "parent" quality, with an expandable arrow), in the table of contents.
 * In specific cases, like disambiguation pages which you bring up, the use of headings might be a bit more systematic/formalized. I agree that in these cases it might make more sense to have a magic-word or something similar to allow that configurability.
 * A few years ago we collected data regarding the frequency of h2s, h3s, h4s, etc. I'm not exactly sure how this data might be helpful in making decisions here, but it seems relevant. Link to data: https://phabricator.wikimedia.org/T18691#5027417
 * Thanks, AHollender (WMF) (talk) 15:44, 5 January 2023 (UTC)
 * Thanks, AHollender (WMF) (talk) 15:44, 5 January 2023 (UTC)
 * Thanks, AHollender (WMF) (talk) 15:44, 5 January 2023 (UTC)
 * Thanks, AHollender (WMF) (talk) 15:44, 5 January 2023 (UTC)
 * Thanks, AHollender (WMF) (talk) 15:44, 5 January 2023 (UTC)
 * Thanks, AHollender (WMF) (talk) 15:44, 5 January 2023 (UTC)
 * Thanks, AHollender (WMF) (talk) 15:44, 5 January 2023 (UTC)
 * Thanks, AHollender (WMF) (talk) 15:44, 5 January 2023 (UTC)
 * Thanks, AHollender (WMF) (talk) 15:44, 5 January 2023 (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?


 * Hey @Elizium23, thanks for this feedback. I would just like to note that the behavior of dialogs is not directly related to Vector 2022, so this might not be the best place to discuss improvements to them. Probably what would be best is reaching out to the Design Systems Team. I see they have a task regarding adding dialogs to Codex (the design system), so you could probably add your feedback there: https://phabricator.wikimedia.org/T313773. AHollender (WMF) (talk) 15:48, 5 January 2023 (UTC)

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


 * This problem has been raised multiple times both here and on en.wiki. Many users have expressed their preference for the old style TOC. However, this has been completely ignored by the developers, both here and on en.wiki. Moreover, in the general request for comment on en.wiki a majority of users expressed themselves AGAINST the implementation of Vector 2022; it has been completely ignored, and the result has even been sold as an endorsement. 37.161.248.115 05:42, 28 December 2022 (UTC)
 * Basically I do like Vector 2022 except TOC style. I like how it is done in MW 1.38.x - there is a refreshed Vector skin, but with old TOC style. And I have couple wiki websites and just because of this fact I don't have desire to update to 1.39 ... if so I will have to change skin (Timeless as an example). Fokebox (talk) 07:38, 28 December 2022 (UTC)
 * I agree, the new horrible TOC and the white spaces and width are the main problems of Vector 2022. But the complaints have been ignored by the developers. 37.161.248.115 09:34, 28 December 2022 (UTC)
 * Very strange position ... I don't think it takes a lot of efforts for developers two make TOC view optional (old / new TOC style at vector-2022) for users and for those who has wiki websites!!! Fokebox (talk) 10:43, 28 December 2022 (UTC)
 * I 1000% agree. I had to go back to the 2010 version of the skin just so I could navigate the page. This change is complete trash. This should have had a toggle to go back immediately. 24.42.211.97 22:47, 31 December 2022 (UTC)
 * Hey @Fokebox and other folks in this discussion: I just want to acknowledge that the requests for the old style of the table of contents have not been ignored. We've read and responded to all of these comments, and we've written extensive documentation as to why we think the current implementation is a better approach. I understand it is frustrating: you want a certain change made, you think your idea is better than what is currently implemented, and you think we are ignoring you. However in this case your opinion represents a very small minority. It's not that we're ignoring you, instead it's that we've gotten more positive feedback than negative feedback, plus the extensive consideration of the 12+ designers at the WMF, so we've concluded to stick with the current implementation. Thankfully MediaWiki software is configurable, so you still have options. AHollender (WMF) (talk) 15:55, 5 January 2023 (UTC)
 * "We've gotten more positive feedback than negative feedback". Where? On en.wiki a majority of users (165 vs 154) voted AGAINST Vector 2022, and many doubted the source and reliability of the data you presented in support on your choices. 37.161.68.229 15:59, 6 January 2023 (UTC)
 * That would be this round of community feedback: Reading/Web/Desktop Improvements/Third prototype testing/Feedback
 * Positive: 110, neutral: 38, negative: 23
 * You can read more here if you are interested: Reading/Web/Desktop Improvements/Features/Table of contents AHollender (WMF) (talk) 03:15, 11 January 2023 (UTC)
 * Also, your summary of the RfC is misleading in this context. Around 70% of the people who opposed Vector 2022 specifically opposed the limited width (which is now optional). Maybe 3 or 4 people objected to the table of contents. Every day, here and on Phabricator, we engage in fact-based conversations about the layout and various configurations/tradeoffs with community members, and are grateful for the engagement and feedback. If your goal is to make a case that the skin is poorly designed, and the WMF is not responsive to community feedback, I am confident you will not find evidence to support that. AHollender (WMF) (talk) 03:20, 11 January 2023 (UTC)
 * My Personal concern as a Mediawiki website owner. I do like new Vector style except the placement of TOC. And I do know that my website visitors also will be against of that. So that all I ask to make an option - to have new style TOC and have the old style TOC. Fokebox (talk) 09:26, 19 January 2023 (UTC)

I haven't tried the instructions, but this FAQ entry is entitled "How to restore the old table of contents". Jonesey95 (talk) 00:55, 11 January 2023 (UTC)
 * I tried by adding the script to my 2022 Vector javascript, but I saw no change in behaviour. I did not get the old TOC back. Jay (talk) 04:59, 19 January 2023 (UTC)
 * As I said, I haven't tried it. It looks like that text was added by, who is usually pretty good at communicating on talk pages. Jonesey95 (talk) 06:51, 19 January 2023 (UTC)

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)


 * Hi @Comfr. None of us was working on Dec 26, so we couldn't answer quickly. We didn't make any changes back then either :) Has the look changed since then? SGrabarczuk (WMF) (talk) 21:56, 9 January 2023 (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)


 * Hello @Jonesey95. Thanks for flagging this. You should be seeing the sticky header on the user talk pages - let's perhaps add ?safemode=1 to the URL and see if the header appears.
 * As for the special pages, our way of thinking has been that the goal for the sticky header is to provide access to functionalities like Edit, Talk, Watch, or History, and these happen not to be available on special pages. What do you think about that? SGrabarczuk (WMF) (talk) 21:54, 9 January 2023 (UTC)
 * I tried safemode, and the sticky header displayed on my User talk page. I then went back to my User talk page without safemode, and the sticky header still displayed. Hmm, maybe this was a temporary problem. Edited to add: I just went to https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Oregon?safemode=1 and I do not get a sticky header no matter what combination of reloading and scrolling I do.
 * As for Special pages like my Watchlist, it is still very useful to have access to links like my user page, my talk page, my contributions, and especially my notifications (which are coming to the sticky header at some point, I hope!) if I have scrolled partway down a page. One of the potentially nice things about Vector 2022's sticky header is that it could compensate for the addition, over the years, of various bits and bobs (options, notices, buttons, white space) to the top of the Watchlist page that have made it so that my actual watchlist starts halfway down my screen. If I could see my notifications *and* most of my watchlist at the same time, that would be excellent. Jonesey95 (talk) 02:27, 10 January 2023 (UTC)
 * As for Special pages like my Watchlist, it is still very useful to have access to links like my user page, my talk page, my contributions, and especially my notifications (which are coming to the sticky header at some point, I hope!) if I have scrolled partway down a page. One of the potentially nice things about Vector 2022's sticky header is that it could compensate for the addition, over the years, of various bits and bobs (options, notices, buttons, white space) to the top of the Watchlist page that have made it so that my actual watchlist starts halfway down my screen. If I could see my notifications *and* most of my watchlist at the same time, that would be excellent. Jonesey95 (talk) 02:27, 10 January 2023 (UTC)

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


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


 * Pages that do show this behaviour:
 * en:User:DePiep/current/test-2023
 * Pages that do not show this behaviour (that is: show & behave as expected wrt this):
 * en:User:DePiep/chembox/test-2023
 * note: linter errors on the faulty page (&lt;i&gt; unbalanced). I will have to remove them first.
 * I'm sorry for delaying this reply. I hope to be able do some more tests shortly (like, test by page content).
 * -DePiep (talk) 07:04, 16 January 2023 (UTC)

Anchors imprecise
I've been encountering a problem that I think may be caused by New Vector. When I click on the table of contents links at a long page, the place it scrolls to often isn't exactly the thread I clicked on, but rather one or two above or below. Is this a known issue? &#123;{u&#124; Sdkb  }&#125;  talk 22:36, 9 January 2023 (UTC)
 * , Is this on talk pages? Pbsouthwood (talk) 06:30, 10 January 2023 (UTC)
 * Yes, or project pages that consist of discussions like w:WP:VPR. &#123;{u&#124; Sdkb  }&#125;  talk 06:43, 10 January 2023 (UTC)
 * I'm not yet able to reproduce this on w:WP:VPR. What section are you clicking on, and what section is appearing on your screen? Can you provide links to other pages you're seeing this issue on? Also can you provide other potentially relevant details (operating system, browser, browser width, etc.). Also can you check if you can reproduce this in an incognito/private window (append  to the URL). Thanks,  AHollender (WMF) (talk) 05:06, 11 January 2023 (UTC)
 * I tried to replicate it in an Incognito window with Vector and couldn't, so maybe it's an extension I'm using. I'll do some further testing and see if I can isolate the issue. &#123;{u&#124; Sdkb  }&#125;  talk 16:37, 11 January 2023 (UTC)
 * Having paid attention for a few days, the issue seems to occur when I click on notifications from conversations I'm subscribed to, not when I click on a table of contents. I'll follow up with the talk pages project. &#123;{u&#124; Sdkb  }&#125;  talk 16:32, 16 January 2023 (UTC)

General feedback from a multiple portrait monitor power user
I'm one of those long-term editors who has never switched from Monobook. I groused about one of the new skin preview efforts not long ago, when comments were solicited, but this edition of Vector I mostly like. I mainly view Wikipedia on 23" monitors in portrait mode, with the window full-screened. The old-fashioned embedded TOC is not a problem with this much vertical real estate. The new TOC is kind of nice in some ways, but for me, I always want it fully expanded. It's a quick way to judge the complexity of the article. There's also too much "air" in the new TOC, it wraps longer section titles (ugh), and I lose the birds' eye view.

My second problem mainly concerns use of my landscape screen. As I increase the font size on my wide screen, the page switches off the navigation side bar before I have the large font size I desire, and now the text lines are too long for comfortable reading (100 characters is nutty), and I've lost visible navigation. (The inline TOC does not reappear.) I sit further away from my screens than most people. Perhaps because I have three, perhaps because it reduces back pain. At certain sizings on my landscape screen, I get a TOC too narrow to give me a proper overview, while simultaneously the text beside the TOC has lines too long for me to comfortably read. Probably all that can be hand customized in the CSS or somewhere, if I cared enough about Vector to make it work.

The third problem seems to be a paper cut. On my portrait screen, with larger font sizes, the search bar disappears, even when room remains to fit a short one. Commonly the search bar is a target for drag and drop from an article I'm reading on another screen. More than half the time my right screen is open to Wikipedia. I'm reading on my middle screen, I see an unfamiliar term (e.g. the German tank type "Marder") and I reflexively double-click to word select, then grab the word to drop on the Wikipedia search bar on my right screen—but wait!—that control is stupidly excised because the nanny state thought that a search bar too small would — what exactly? ... cause brain problems in the common user?

Even a small target for drag and drop would permit this interaction to work seamlessly, and the search bar could pop into large mode on a responsive basis to having text input (by keyboard or by drag and drop). I like drag because it doesn't interfere with my clipboard. I have a spectacularly powerful clipboard manager, but not because I want to drive it all day to recover recent items. Even no visible search bar target would work, if it responded to text drop events as if it were really there (where it ought to be anyway, so far as I'm concerned). Make that region automatically expand the search bar—if concealed—on drag hover! Also, if you're going to leave that dotted hamburger hovering over my page all the time anyway, why can't it serve as a drop target for search text?

The search interaction could pop up in place of the TOC sidebar when activated in this way, and people wouldn't have to loose their place running to the top of the page to conduct a search query. I actually use the search bar's auto suggestion mode quite often, to explore possible resolutions, without any intent to visit a searched term. When I'm using search in that way, I'd highly prefer not to lose my place in the current article. Just now I typed "Marder" in the search bar on my old Monobook skin. The list of suggestions pops up rapidly. The second one says "Marder (infantry fighting vehicle)" and I'm done. Because I was trying to remember whether it was a real tank, or just a tankino (it's the latter). Why do we only give the Ukrainians tankinos? But so it goes.

I briefly wondered if the new design was clever enough to detect alt-shift-f to bring up a floating search control over top of my current page position. But in my test page for Vector, alt-shift-f now does nothing at all. Wow. That's a step backwards if I've ever seen one. I have to say, I frequently don't understand the priorities of today's design generation.

Sigh. Monobook is far from perfect, but there's nothing so wrong with it that I need these new hassles. Reverted to Monobook. Again. And, most likely, not for the last time, given general trends in design priority. MaxEnt (talk) 21:45, 13 January 2023 (UTC)


 * Hey @MaxEnt, to clarify one point: when pressing alt+shift+F are you expecting the brower's Find in page function to appear? If so, for me that appears just with alt+F (and also is outside of the control of the website). I'm not seeing anything appear in Monobook or Legacy Vector with alt+shift+F.
 * Interesting workflow regarding dragging a word into the search box — I've never heard of that before (also I can't figure out how to do it, how do you drag the word without it becoming unselected?).
 * We are working to keep the search bar visible at more narrow screen widths, so that should improve in time. We're also looking into zooming, and increasing the font-size via browser settings, to make sure all of that works as well as it possibly can.
 * The skin definitely has a ways to go, but from feedback, data, research, etc. it seems to be substantially better than Legacy Vector to warrant the switch over. AHollender (WMF) (talk) 15:06, 16 January 2023 (UTC)

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


 * Hey @The Discoverer, thanks for reporting this. To clarify: does this only happen on the Main page, or on other pages as well? AHollender (WMF) (talk) 14:10, 16 January 2023 (UTC)
 * @AHollender (WMF), It only happens on the main page, because the main page is the only one that is explicitly formatted to be on two lines. On all other pages the headings are shortened using ellipses (...) and do not wrap. The Discoverer (talk) 15:52, 16 January 2023 (UTC)

Not showing interlanguage links for other Namespaces

 * This issue is noticed in Tewiki
 * This is noticed in Vector 2022 skin only. There was no problem in default Vector skin
 * This is noticed in Template, Help, Wikipedia and Module Namespaces. Not noticed in Main namespace. Not checked for other namespaces.
 * This problem appeared on 14 Jan 2023
 * This problem is observed on Windows 11, Chrome 109. Not checked in any other environment.

The interlanguage links are not shown. When clicked the languages drop down, it shows the message "Page contents not supported in other languages." See image 1 When the page is scrolled down, the sticky link shows "so many languages" (e.g. 186 languages) See image 2 When the link is clicked the drop down shows - "No languages yet No languages are available for now" See image 3 Chaduvari (talk) 15:29, 15 January 2023 (UTC)


 * [EDITED] Hey, this is expected. Please see an unintended consequence of https://phabricator.wikimedia.org/T316559. For more information please see the task linked in the comment below. Our apologies for this inconvenience. AHollender (WMF) (talk) 14:09, 16 January 2023 (UTC)
 * Expected??? The quoted ticket mentions the simplification of messages only for pages that that should not be associated with interlanguages links, e.g. talk pages. Meanwhile, in vector-2022 you turned off the visibility of links in all namespaces except main(!), which was considered a very serious bug and is "patched" in emergency mode (see: https://phabricator.wikimedia.org/T326788). Zdzislaw (talk) 18:06, 16 January 2023 (UTC)
 * @Zdzislaw, @AHollender (WMF)- Great, it is working now. Thanks for fixing it. __ Chaduvari (talk) 07:02, 17 January 2023 (UTC)

Issue with User menu drop down
This is noticed in Tewiki. This has been there ever since I started using the skin in October 2022. Sorry if I am repeating an old, well reported issue. __Chaduvari (talk) 07:23, 16 January 2023 (UTC)
 * With the page scrolled down, when the User menu is accessed, the drop down list does not show the "purge" link. I suppose it is a deliberate feature.
 * But when the page is scrolled up to the top, and when the User menu drop down is pressed, the drop down does not appear. In stead, the User Talk page appears.
 * After going back, the drop down works normally.


 * Hey, thanks for reporting this. Would it be possible for you to include screenshots of this issue? I am not sure I am entirely clear on what is happening. AHollender (WMF) (talk) 14:08, 16 January 2023 (UTC)
 * Tool tip shows User menu and the menu list is shown.png
 * Tool tip shows your talk page.png
 * Sorry for not being clear about the issue. The issue is -
 * When I scroll down a page, the "" (In Telugu it is "") drop down list shows underlying links normally. See Fig 1.
 * Then I scroll up the page to the top. Now, this drop down's toll tip shows "" (In Telugu it is ""). When it is clicked, I expected to see the drop down list items. instead, it takes me to my User talk page. See Fig 2
 * When I come back or when I refresh the previous page, then its tool tip shows the usual "" (In Telugu it is ""), and on-click it shows the drop down list.
 * this is noticed in Windows 11 and Chrome 109. Not checked in other environments.
 * I hope I am clear now. Thanks. __Chaduvari (talk) 06:59, 17 January 2023 (UTC)
 * Chiming in to mention that it's been happening to me too. TerraCodes (talk) 09:24, 19 January 2023 (UTC)
 * Ended up debugging this since I found a thing about it while doing something else. It seems that if you scroll down and open the sticky nav user dropdown, and then scroll back up so the sticky nav disappears without closing the sticky nav user dropdown, the sticky nav user dropdown still is open, but invisible. If you scroll back down you can see the sticky nav user dropdown still open. Closing it "fixes" the issue, but this should be properly fixed in the codebase. TerraCodes (talk) 09:57, 19 January 2023 (UTC)

Repeating an old, pending issue
Please look into an important issue at Tewiki, which was reported here on Oct 2, 2022. Posting it again here, just to ensure that it wont get buried in archives. Sorry for that. __ Chaduvari (talk) 07:31, 16 January 2023 (UTC)


 * @Chaduvari thanks for the reminder. I've created a task on Phabricator (T327070) and have tagged several members of the Codex team, who we have been collaborating with on the search feature. I am hoping they will be able to provide a solution. AHollender (WMF) (talk) 14:07, 16 January 2023 (UTC)

Further release plans
Very cool that English-language WP will switch this week! I was wondering if there already are concrete plans on how to make Vector 2022 default in even more language versions. I see that you write We hope to get to all the Wikipedias by the end of February 2023, but at least on dewiki I have not had the impression that there was much communication and discussion about it so far. It would be difficult to reach a community consensus in such a short time. Or are further switches delayed until the page tools update is ready? Would be nice to have some more input, I just started an initial discussion on de:Wikipedia:Technik/Werkstatt. XanonymusX (talk) 19:16, 16 January 2023 (UTC)


 * Thanks @XanonymusX for your interest in this project. That's a good question. Right now, we're focusing on the deployment on English Wikipedia (apart from handling bugs and deploying the page tools). I'm grateful that you've initiated the discussion on the Werkstatt. It looks very good!
 * That said, we aren't able to be talking to two large communities at the same time. After some (hopefully short) time following the deployment on English Wikipedia, we will form a plan for the German-language community and reach out to this group. Definitely, we don't want to rush or confuse people.
 * In principle, though, is the skin stable and mature enough? Yes. We believe that if it's ready for deployment on English (and it is) it's also ready for German. Is the deployment on English Wikipedia a game-changer in terms of the gadgets and user scripts? Will the deployment on English make it significantly better? No, not really, because the technical English-speaking community has been familiar with the skin for a long time. A large portion of volunteer-maintained code was adjusted long ago. But who knows, perhaps something on dewiki still needs to be updated.
 * So... before we focus on German, we will continue running banners there, incentivizing people to opt-in individually. In parallel, you're most welcome to advocate for it wherever you deem appropriate. Writing on the Werkstatt was a great move!
 * Thanks, SGrabarczuk (WMF) (talk) 03:32, 17 January 2023 (UTC)
 * Thanks, sounds good! My feeling says that waiting for the page tools might be a good idea, so I’ll be following that development closely. For now, we will prepare the info pages on dewiki. The post on Diff tomorrow will also be in German, so sharing that one might help increase awareness. Success with deployment, looking forward to it! XanonymusX (talk) 10:07, 17 January 2023 (UTC)
 * In any case, we have de:Hilfe:Skin/Vector 2022 now, will try to keep it up-to-date! XanonymusX (talk) 17:41, 17 January 2023 (UTC)

Vector 2022
Wäre es möglich, die wirklich nervige Bannerwerbung für diese misslungene Oberfläche dauerhaft einzustellen? Ich glaube gerne, dass es Nutzer gibt, für die Schmiertelefone und Hochformat das Einzig Wahre sind. Für die gibt es aber schon die Mobilansicht. Was soll es bringen, allen anderen, die klassische Rechner mit üblicherweise im Querformat stehenden Monitoren benutzen, mit einem zusätzlichen weißen Streifen auf der rechten Seite zu nerven? Wer den Humbug möchte, der hat ihn. Wer ihn nicht will (und eher springe ich aus dem Fenster), der will ihn nicht und sollte der Schwachsinn mit Gewalt durchgedrückt werden, dann bin ich weg.

Bitte, macht damit Schluss. Als Option kann diese Ansicht gerne weiterbestehen, aber nicht als Voreinstellung. Schon, dass man das Anmeldemenü erst suchen muss, ist ein Schuss in den Ofen. Der Kram ist ein Fall von »gewollt und nicht gekonnt«. Das Versprechen, dass das Banner nur alle sieben Tage auftaucht, hat nie funktioniert. Zumindest bei mir werden die Cookies beim Schließen jedes Browsers gelöscht – und das ist nicht verhandelbar. Es gibt schon viel zu viele Schnüffler und in dieser Reihe möchte ich Wikimedia nicht sehen. –Falk2 (talk) 23:05, 16 January 2023 (UTC)


 * Die Banner werden naturgemäß so lange laufen, bis die Oberfläche Standard ist. Wie wir eins weiter oben gerade besprechen, wird das für deWP demnächst angegangen, dauert aber sicher noch. Interessant finde ich, dass ich gefühlt noch nie ein solches Banner gesehen habe, aber das wird wohl daran liegen, dass ich den alten Vector schon lange nicht mehr verwende. Du kannst Banner übrigens generell in den Einstellungen deaktivieren (auch nach Typ). Gruß XanonymusX (talk) 10:02, 17 January 2023 (UTC)

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

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

Can we either (a) stick with one implementation or the other all the time, or (b) put the GTW icon in both places all the time to accommodate all editors? Thanks for listening, Fourthords (talk) 22:13, 17 January 2023 (UTC)


 * Looks like it's already in the page (as it seems that the skin hide/shows based on screen width) so you could hide the one outside the dropdown and show the one in the dropdown, as I'm planning on doing. TerraCodes (talk) 09:34, 19 January 2023 (UTC)

Typographie des sous-sections
Bonjour,

Comme on peut le constater sur n'importe quelle page du Wikipédia français, les sections apparaissent visuellement comme en « Times New Roman 16 » alors que les sous-sections ressemblent à de l'« Arial 12 Bold ». Dès lors, bien que d'une taille soit petite, cette dernière attire davantage l’œil car elle est en gras (voir n'importe quelle page comme celle-ci avec le paragraphe « Systématique » et le sous-paragraphe « Publication originale ». Il serait sans doute bon de corriger cela pour avoir une mise en valeur plus claire de la hiérarchisation des paragraphes.

D'avance merci.

Givet (talk) 08:16, 18 January 2023 (UTC)


 * Bonjour @Givet, cela apparemment n'est pas dû à Vector 2022, il se produit aussi avec d'autres habillages. Cette page de discussion est dédiée au projet des améliorations du bureau qui s'occupe de Vector 2022, avez-vous demandé au Questions techniques ? Patafisik (WMF) (talk) 15:24, 18 January 2023 (UTC)
 * Non, en fait je ne sais pas très bien à qui m'adresser. Peux-tu le faire pour moi ou veux-tu que je transfère ma demande ? En tout cas merci pour ta réponse. Givet (talk) 15:32, 18 January 2023 (UTC)
 * @Givet J'ai vu qu'il y a une discussion en cours au Bistro par rapport à la police des sous-sections où des pistes sont données. Aujourd'hui se passe le deployment sur la Wikipédia en anglais de la nouvelle interface, donc à mon avis il y aura moins de monde pour répondre à cette question dans les prochaines heures hors frwiki. Patafisik (WMF) (talk) 15:34, 18 January 2023 (UTC)
 * Oui, c'est moi qui est lancé cette discussion, mais pour être franc cela fait des lustres que ça me gène. Alors on peut attendre un peu, pas de souci. Encore merci, je reviendrai plus tard. Bonne soirée :-) 2A01:CB05:83ED:8500:1590:B514:5B26:56D7 15:39, 18 January 2023 (UTC)
 * Désolé je venais de me déconnecter... C'est bien moi qui est rédigé le commentaire ci-dessus. Givet (talk) 15:40, 18 January 2023 (UTC)
 * @Givet pas de soucis. :) Comme disait TomT0m vous pouvez déjà lancer une nouvelle discussion au Bistro pour voir si d'autres wikipédiens sont d'accord pour modifier le MediaWiki:common.css global. Mais à mon avis avant vous pourriez en discuter au projet Charte graphique. N'oubliez pas que tout changement devrait prendre en compte l'accessibilité, voir par ici. Bien cordialement, Patafisik (WMF) (talk) 15:51, 18 January 2023 (UTC)

Table borders
It looks like the new skin has affected the borders on some tables. More specifically, the toccolours class no longer has borders:

generates:

Is this a known change and intended? Pbrks (talk) 15:49, 18 January 2023 (UTC)


 * Hi @Pbrks, thank you for your report. Can you give us screenshot, please? Patafisik (WMF) (talk) 17:14, 18 January 2023 (UTC)

Vector 2022
This skin is horrible, it reduces the horizontal display space for the article quite considerably which leads to a lot of sandwiching and will make articles difficult to read on mobile devices. Murgatroyd49 (talk) 16:38, 18 January 2023 (UTC)
 * I associate myself with these comments. Strange choices were made in developing this. Spelf (talk) 17:02, 18 January 2023 (UTC)
 * Hi thank you for your feedback. The Web Team has been working on Vector 2022 for 3 years, identifying problems through research with both readers and editors, and building and testing prototypes with communities. These changes are created specifically for desktop interfaces. All research and testing done for this project has been focused on desktop users only. We have, however, considered the experiences of people who use desktop in narrower screens (for example, if you have two tabs open side by side). For further information please look at this FAQ. --Patafisik (WMF) (talk) 17:47, 18 January 2023 (UTC)
 * Thanks for the response, for the record, I still don't like but that's my problem! Murgatroyd49 (talk) 17:49, 18 January 2023 (UTC)
 * I support the original post. The narrow text is horrible to look at on a desktop browser too. The full width text should be the default and the narrow text should be an option. This is a reading-heavy website and we need to see much content on our display. The old Vector skin got it right, but the new Vector 2022 fails with this task. Full width text was nice, bring it back for us. The location of the 'full width text' button is very poor and some browsers on desktop do not show the button at all. The 'full width text' button needs better placement, this function will be very important for a lot of readers! 94.26.15.134 19:53, 18 January 2023 (UTC)
 * I agree; the narrow width and wasted white space is very inefficient and makes it hard to read. I've reverted back to the 2010 theme. Steepleman (talk) 23:47, 18 January 2023 (UTC)

....
Awful decision to force this as default for me with no warning. Awful. I have a 2k monitor, I don't need this sandwiching bullshit. 24.235.56.110 16:40, 18 January 2023 (UTC)


 * Hi @24.235.56.110, I understand you fell frustrated. We have communicated a lot with the community, discussed and made changes only after a RfC. Please look at our FAQ and consider to personalize your experience restoring the full width. We have built a toggle for logged-in and logged-out users. The toggle is available on every page if the monitor is 1600 pixels or wider. Selecting the toggle increases the width of the page. Patafisik (WMF) (talk) 17:32, 18 January 2023 (UTC)
 * Where is this toggle? I can't find it, and why only 1600 pixels and wider? Why not just add a toggle that turns off the new layout completely: For all users even without an account? 172.58.174.193 18:28, 18 January 2023 (UTC)
 * I too can confirm that the visibility and placement of this toggle is very poor. 94.26.15.134 20:00, 18 January 2023 (UTC)
 * Can I get a direct link to the RFC? Not really sure where to find it. Skarmory (talk) 03:35, 19 January 2023 (UTC)
 * The RFC was at en:Wikipedia:Requests for comment/Deployment of Vector (2022), where opposition to the excessive white space was overwhelming. Jonesey95 (talk) 06:29, 19 January 2023 (UTC)

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


 * Wow. Absolutely describes my sentiment. Hope they don't just remove your topic just because it uses slur words. This new layout is absolutely disgusting—and to force it on non logged-in users instead of making it an option? Incredibly stupid and unthoughtful 172.58.174.193 18:24, 18 January 2023 (UTC)

Space unutilization
With the new look, there is lot of empty space at the left and right sides of the page. All content is restricted to the middle, and this may be suitable for mobile devices. What should I do to let the content span the entire width of the page for desktop usage? Jay (talk) 17:11, 18 January 2023 (UTC)
 * Oh never mind! I found the toggle button on the right side bottom corner. Jay (talk) 17:15, 18 January 2023 (UTC)
 * Hi @Jay, thank you for your feedback. Please look at our FAQ, yes, you can personalize it. Patafisik (WMF) (talk) 17:16, 18 January 2023 (UTC)
 * And I'm now able to fold the left frame also. This is awesome! Jay (talk) 17:21, 18 January 2023 (UTC)

Not pixel aligned, leading to grayscale text rendering/fuzzy text on Windows Chrome
Hi, when the content does not take up the full width (e.g. with sidebar) there must be an element that is not pixel aligned. On a 1x Windows display with Chrome, this causes the text to appear fuzzy, rendered using grayscale antialiasing: https://i.imgur.com/Yju4XKA.png

The old version of wikipedia, and also the resized version removing the sidebar does not exhibit this problem, and is correctly rendered using subpixels, looking much crisper. Zebracanevra (talk) 17:12, 18 January 2023 (UTC)


 * Hi @Zebracanevra thank you for reporting this. Can you confirm me if your problem is described in this task? Patafisik (WMF) (talk) 17:19, 18 January 2023 (UTC)
 * Hah I've been encountering that bug for a while now, happens on Youtube as well. It could be related, though I don't think it is the same issue.
 * Maybe if the Chrome team fixes the bug in that task it will resolve my issue.
 * I believe the GPU rendering in Chrome Windows uses grayscale AA and otherwise it uses subpixel AA, and using some CSS properties/widths can induce Chrome to render using the GPU. See for example any page on Cloudflare's Docs, where if you open a dropdown, they use "will-change", hinting to use the GPU: https://i.imgur.com/ut0sTo5.png same result. Zebracanevra (talk) 17:41, 18 January 2023 (UTC)
 * Maybe just ignore everything I said about the cause being "pixel aligned". Maybe I don't know what I am talking about.
 * I do have a fix for what I am seeing, though:
 * Removing the position property from  makes Chrome want to do subpixel rendering for the body. Zebracanevra (talk) 17:55, 18 January 2023 (UTC)

TOC level
Earlier the TOC at en:Wikipedia:Redirects_for_discussion used to show only the dates and not every discussion for that day. Now it is showing all, which will go to hundreds and is not practical. I want to see only the dates like before. How can I make the TOC show the top-level heading only, and not all of them? Jay (talk) 17:32, 18 January 2023 (UTC)
 * The TOC needs to have the same width of the main content, or at least 50% of the main content. Having it as a sidebar which is narrow makes it hard to use. Can I have the TOC permanently as part of the main content? Jay (talk) 18:08, 18 January 2023 (UTC)
 * @Jay - one thing that might help with this is collapsing the ToC, then opening it using the button on the left side of the title. This allows it to show as an overlay which gives more space for the ToC on pages or namespaces where headings are generally longer.  Hope this is helpful!  OVasileva (WMF) (talk) 19:06, 18 January 2023 (UTC)
 * @OVasileva (WMF): If I may interject, it seems the primary issue is that the ToC only collapses top-level headings (marked with ), but not lower level headings (marked with   and so on). On the linked page, when "Current list" is uncollapsed in the ToC, all of its subheadings are displayed—not just the subheadings directly beneath it in the hierarchy. I think it would be ideal if every heading with any subheadings (even if it's a subheading itself) could be collapsed/uncollapsed in the ToC display. Shells-shells (talk) 20:04, 18 January 2023 (UTC)
 * I collapsed the TOC (by clicking Hide), clicked the (TOC) button on the left side of the title, and it is still the same as I observed before. It shows ALL the discussions from all the dates. So this did not help. Jay (talk) 04:53, 19 January 2023 (UTC)
 * I see that your suggestion was for my spacing concern. Yes, for that, it helps. Thanks! Jay (talk) 04:57, 19 January 2023 (UTC)
 * I also tried How to restore the old table of contents by adding the script to my Vector 2022 javascript, and there is no change in behaviour. I did not get the old TOC back. Jay (talk) 04:53, 19 January 2023 (UTC)

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

Make the text fit the page
I haven't read anything and I shouldn't need to. There is no justification for not making the articles take up the whole page width on desktop.

Make the pages fit, get rid of these ridiculous side margins. VanillaSeagull (talk) 18:27, 18 January 2023 (UTC)


 * Or maybe just stop making it the default layout entirely. The whole thing seems like an excuse for their design team to have done something significant to the site. 172.58.174.193 18:30, 18 January 2023 (UTC)
 * I definitely agree. I don't see any practical use to making a rather wide portion of space on each side of the page always empty. It's ultimately wasted space -- what does it add? What benefit is there is having a large chunk of every page contain no content of any sort? The text should be full-page again, it's just efficient use of page space. Theriocephalus (talk) 19:54, 18 January 2023 (UTC)
 * Even when switching to full-width mode (either via the toggle at the bottom right or via user preferences) the layout is wasteful.
 * Can the grid column width for the sticky ToC be reduced to  and the extra padding added by the   directives be removed when full-width mode has been requested? A user that doesn't want wasteful whitespace doesn't want wasteful whitespace. Growfybruce (talk) 03:29, 19 January 2023 (UTC)
 * A user setting to default the ToC to hidden would be nice too. Growfybruce (talk) 03:33, 19 January 2023 (UTC)
 * On that same note, it also hides a ton of menus behind drop down menus. That's fine for most people, but if you edit on wikipedia, it's super annoying to have to open more menus when you used to just have to click a button UpdateWindows (talk) 03:39, 19 January 2023 (UTC)

Blurry text after scrolling down on Microsoft edge
After the new skin went live I noticed that pages started becoming blurry for a second before fixing themselves. The effect only comes again if the page is reloaded with Ctrl + F5 though. I'm not experienced enough in web design to know what the problem might actually be though. The effect is not present on the old vector skin. The problem can be seen here https://imgur.com/a/WvAJdlu Carvor (talk) 18:31, 18 January 2023 (UTC)


 * Hi @Carvor - thanks for your question. This is an upstream issue with the Chromium browser (which Microsoft edge uses).  We've reached out to the Chromium team and they're currently working on a fix.  Progress can be tracked here.  OVasileva (WMF) (talk) 19:00, 18 January 2023 (UTC)

Missing links in diff blogpost
Reported an issue on page https://meta.wikimedia.org/wiki/Talk:Diff_(blog)#Missing_links_in_diff_blogpost_about_new_skin 185.79.217.61 18:32, 18 January 2023 (UTC)


 * Thanks for your question! The section on that page is for learning more about the project through our blog posts. Above that section, you will see links to the mediawiki project page and this talk page for leaving general feedback.   OVasileva (WMF) (talk) 19:08, 18 January 2023 (UTC)

Vector 2022 seems to be using legacy custom CSS file
A warning that people who are using custom CSS for legacy Vector may get that legacy CSS when they are automatically switched to Vector 2022 which can seriously break the page UI. When I went to Wikipedia earlier today, I had a broken UI, links and menus not showing or working, no TOC, etc, because Vector 2022 seemed to still be using Legacy Vector user custom CSS instead of its own user custom CSS. It took a while to figure out a way to interact with Wikipedia so I could switch back to Legacy and make Wikipedia usable. Others with custom CSS may be experiencing this same problem. If you switch people to the new Vector 2022, it should not use the old custom CSS at all for this reason (their old CSS may break their UI under the new 2022 layout). For just a visual example of Legacy vs 2022 with a Legacy custom CSS : Screencaps for comparison (lack of links/menus not working obviously not depicted). Imeriki al-Shimoni (talk) 18:38, 18 January 2023 (UTC)


 * Tracked in T301212. Jdlrobson (talk) 22:24, 18 January 2023 (UTC)

List articles with photographs are broken
Noticed this mostly on List of Manchester United F.C. players. The photos are on top of the table with the list below, instead of the photographs beside the table. It's odd, because on other articles, the photos can be beside the list. I'm trying to figure out how to fix it on this article. MAINEiac4434 (talk) 18:44, 18 January 2023 (UTC)
 * Okay, it works when I toggle the wider layout, but it should also work the default layout as well.MAINEiac4434 (talk) 18:46, 18 January 2023 (UTC)

ToC [hide] toggle state not saved
I have had a mostly unobjectionable Vector 2022 experience for several months now. One issue I've noticed is that the toggle state of the table of contents (whether it's hidden next to the page title or displayed in the sidebar) is not saved over page changes or even page reloads. Its state should, I think, be saved just like the collapsed/uncollapsed state of the sidebar controlled by the top left hamburger button. Shells-shells (talk) 19:06, 18 January 2023 (UTC)


 * Thanks @Shells-shells for your question! This is coming up soon. Adding this persistence is on our list for updates to the new skin.  First, we are planning on adding an indicator that will make it easier for people to know where the ToC has collapsed to.  Once this indicator is in place, we will go ahead and make the collapsing persistent across pages.   OVasileva (WMF) (talk) 19:12, 18 January 2023 (UTC)
 * (Tracked in https://phabricator.wikimedia.org/T316060) Jdlrobson (talk) 22:27, 18 January 2023 (UTC)

Customizing button shortcuts in top-right menu area?
I'm giving the new skin a college try but one thing that's non-negotiable is removing the direct link to My Contributions in the top-right corner. I used that as a quick way to reach my active/recent discussions so hiding it in the sub-menu is an extra click for no reason. Is there any way to customize which buttons appear directly (currently, it's Userpage, alerts, notices, watchlist) and which ones get hidden in the sub-menu? Slightly less important but still annoying is that I have the UTCLiveClock gadget active (Preferences > Gadgets > Appearance, 2nd one in the list) and that's getting hidden in the sub-menu as well. Is there any way to change this? I don't mind having extra buttons on the top-right of my screen. Axem Titanium (talk) 19:49, 18 January 2023 (UTC)
 * You're most likely going to have to fiddle with CSS to get a button for it, but a quick way to get to your contributions is to use the hotkey combo Alt. Tenryuu (talk) 02:42, 19 January 2023 (UTC)

Easier switching between my languages
I often browse the wiki in both English and Hungarian. With the old design, switching to a page's Hungarian version was just 1 click. (As it always displayed it among the suggested languages.)

With the new design it's a click on the dropdown, scroll down or search for Magyar, then click again. It's a minor, but noticeably more hassle than it was before.

Seeing that most people probably don't speak more than 1-2 languages, could we add a customisable shortcut to the user's selected languages? I don't need to see a list of 60+ languages I don't even speak. --Kazerniel (talk) 19:55, 18 January 2023 (UTC)

Absolutely awful
Stop forcing mobile interfaces on desktop users. Completely inexcusable and unusable. Kuinor (talk) 20:02, 18 January 2023 (UTC)


 * I wholeheartedly agree. This is a bullshit decision and the web design team should feel ashamed of themselves. I've used this site every day since I was a child and I have only just now made an account to switch back to the proper interface. If it ain't broke, don't try to fucking fix it. AngryAtlantan3000 (talk) 00:34, 19 January 2023 (UTC)
 * I don't get it. If you have the screen space, use it. Force collapsing some of the most useful parts of the UI makes no sense to me. It's only intuitive when you are limited in space, otherwise people do not look for the hamburger menu, they simply get lost.
 * I subscribe to the school of thought that web design should be focused on enabling ANY user to find what they are looking for quickly. Hiding necessary pages like "about wikipedia" or "contact us" behind a hamburger essentially locks out many people who aren't trained to look for these things.
 * The left pane is empty and unused by default. I like the language dropdown, but then a box "educating" users on where to look for their language makes NO sense to me. They can't read English, but the sidebar used to show the language options in their native language, which it doesn't anymore. Why could you not do both? Asukite (talk) 05:25, 19 January 2023 (UTC)

Can you create a version that combines some ideas of 2022 with the 2010 Vector?
I think it is a good idea for the Table of Contents being moved off the article space and imbedded toward the right-side of the webpage. I also like that the page is more centered with both left and right spaces being empty.

Unfortunately, there is a flaw in 2022 Vector that cannot be ignored. The current design has no defined space for what is article and what isn't. For example, the spacing between the TOC and the Article seems ambiguous and unclear. It's so distracting that my brain is trying to figure out where in the webpage does the TOC ends and the Article begins. It looks even worse when a TOC has a bar to scroll and the letters just start to erase through an invisible white line.

This gives Wikipedia a less deliberate design. And In my humble opinion, it makes Wikipedia look more like it came from 1990s than it does in current year. If accessibility is so important, why is it such an adjustment for every article? 2010 Vector great because almost every section of the webpage was defined by borders. Is there a way to make a version of 2022 where the borders of 2010 are reimplemented?

Blue Pumpkin Pie (talk) 20:06, 18 January 2023 (UTC)


 * Here's Custom CSS for a compact theme, so the space between the TOC and main article isn't so noticeable:

.mw-page-container { padding-left: 1em; padding-right: 1em; }	padding-top: 0 !important; margin-top: 0 !important; } .vector-toc { margin-left: 0 !important; width: initial !important; } .mw-content-container { max-width: 82em !important; }
 * 1) vector-toc-pinned-container {
 * Wing gundam (talk) 22:13, 18 January 2023 (UTC)

Worse for reading, more scrolling, more wasted space, less information.
Since the new layout wastes so much space i have to scroll way more. Thanks for making it a worse experience.

You present less information.

It is harder to read.

So much wasted space. Especially on an ultrawide screen. 50% of my page is white. Why do i even have a larger monitor if you just fill it with white.

Congratz, you made the one thing this site was good at bad. 2A01:C23:6033:BD00:302E:8B1A:582E:AD8F 20:08, 18 January 2023 (UTC)

edit: Here is an image of how it looks on a modern monitor that isn't a mobile device: https://i.imgur.com/uwDD5ss.png The same page on the old design shows me 2 additional sections. So on the old design i see more, have to scroll less, can comprehend more at once, and am generally not assaulted by a literally 62.5% white space. Why not make the next design be just a white page, would be a good approximation of how it looks now.


 * I actually like the max-width limit on wide displays, although a toggle would be preferred. If you don't like it and want full ultra-wide, put this in your Vector (2022) Custom CSS (found in your Preferences):

.mw-page-container { max-width: initial !important; } .mw-content-container { max-width: initial !important; }


 * Custom CSS fixes most pet peeves. Wing gundam (talk) 21:41, 18 January 2023 (UTC)


 * There's a toggle in the bottom right corner of your screen. Jdlrobson (talk) 22:22, 18 January 2023 (UTC)
 * Bad tested. In my 1920×1080, 17" laptop screen, I cannot see the toggle button by default. I must set Chrome's zoom to 80% to see it and click, then revert zoom to 100% again.
 * I was tempted for a while to donate to Wikipedia, but now I'm happy not to donate a single nickel, seeing how you spent donator's money. Boo. Thump-down. 37.134.90.176 08:40, 19 January 2023 (UTC)

Why would i do any of that. Nothing like that was necessary before. Me having to manually go change stuff to get a worse version of what was already there before is bad design. Also the only reason i created a wikipedia account was so i can use the old better design. Also i have no toggle bottom in the bottom right of my screen, i have whitespace: https://i.imgur.com/T15bQMU.png

User contributions
Is there no easy way to look up user contributions? You used to be able to do it from the user's page and talk page. 2603:3005:42DF:4000:D5A:FD7F:5960:C34 20:13, 18 January 2023 (UTC)


 * Never mind, I found it through the hamburger menu. Not very intuitive though. 2603:3005:42DF:4000:D5A:FD7F:5960:C34 20:17, 18 January 2023 (UTC)

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

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

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


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

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

Forcing new UI on non account users is trash design
i wont be donating this year if this remains the default. i dont want to sign into wikipedia everytime i google cholera just to change the shitty ass template. if it isnt broken dont fix it, simple. and definitely dont make it a default change you cannot edit without an account when the majority of your users dont use accounts. all this does is make me not want to use or donate wiki for like the first time in my life. im not giving you my money to play around with graphics packages. 2404:4404:1758:400:E9A4:FEEC:61D6:A7AA 20:43, 18 January 2023 (UTC)


 * Why do you keep signing out to re-google cholera? Wing gundam (talk) 21:25, 18 January 2023 (UTC)

[BUG] Vector (2022) imports Vector legacy's Custom CSS
If you have Custom CSS for both Vector-legacy and Vector-2022, then Vector-2022 imports two custom CSS:

The first one loads Vector-2022's Custom CSS. However, the second one is wrong, and results in the import of Vector-legacy's Custom CSS. The correct URL would be, but that's redundant as the first one already loads Vector-2022's Custom CSS. Not sure if the bug affects JS too. Wing gundam (talk) 21:17, 18 January 2023 (UTC)
 * This likely explains the issue I commented on in an earlier section above. In my case, importing the legacy user custom CSS broke the new 2022 layout making it non-functional. I didn't investigate further on the actual mechanism like you did, but I agree with you that this is Bug level issue that needs to be fixed. Imeriki al-Shimoni (talk) 21:48, 18 January 2023 (UTC)
 * Do you know where we report bugs/issues? Wing gundam (talk) 22:20, 18 January 2023 (UTC)
 * This is not a bug but intentional behaviour to support people transfering to the new skin. The behaviour will be removed with T301212. Jdlrobson (talk) 22:20, 18 January 2023 (UTC)
 * (you can update the selectors in enwiki:User:Imeriki_al-Shimoni/vector.css to use the .skin-vector-legacy class if you only want it to apply to the old skin. Jdlrobson (talk) 22:21, 18 January 2023 (UTC)

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

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

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

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


 * Hello! Thank you for writing to us. We've briefly explained our motivation in the FAQ, and on this page, there's a longer essay. Many individuals may have different preferences and answers to the question "what settings provide you with the best reading experience", and it's possible to customize our interface. SGrabarczuk (WMF) (talk) 22:59, 18 January 2023 (UTC)
 * No, actually, if you are not logged into an account, you cannot customize your interface. Because generating one single cookie would just be too hard. 142.162.17.231 02:06, 19 January 2023 (UTC)
 * +1 on the matter of logged-out users being unable to change theme. For such a significant change, a cookie is the least that should be done to respect users who don't have or want an account for any reason they may have. MajorArchitect (talk) 03:16, 19 January 2023 (UTC)

Limited Content Width default on PCs
Hi Team,

I assume that the change to the limited width content is a result of the increasing prevalence of mobile phone based browsers to view the site (although why one wouldn't use the app on a phone is beyond me). However, if you are using a PC, Mac or *nix workstation that has a 'proper' monitor with a landscape aspect ratio it's purely a waste of real estate. I know you can toggle between views but I would suggest that it would be an improvement if, rather than default to limited width in all cases, the skin were intelligent to the aspect ratio and adopted full width when it's landscape, limited when portrait.

Regards,

Graham Grl570810 (talk) 23:11, 18 January 2023 (UTC)
 * It isn't. The reasons for the limited width are explained in the FAQ: Reading/Web/Desktop Improvements/Frequently asked questions.  Fourthords (talk) 02:32, 19 January 2023 (UTC)
 * The designers are apparently confused about the difference between a website and a book. One of the nice things about websites is that we can set our browsers to view them as we'd like rather than getting them in a fixed format. Growfybruce (talk) 03:35, 19 January 2023 (UTC)

Bad design
This design update is not very good. It has many problems.


 * 1) The width of the text is far too     narrow, leading to wasted room. There is too much padding everywhere. It     makes the page look broken. Also things need borders. The borderless     design looks bad when all of the tables and boxes in the contents of the     page have borders.
 * 2) The sidebar is very confusing as     it doesn't appear until you click on the top button.
 * 3) This is relation to my next     criticism, which is that icons or images are used instead of text. I could     not figure out how to find the sidebar without clicking randomly across     the page.
 * 4) Why are the links to the talk     page, sandbox &c. hidden in yet another menu? There is plenty of     space. Also the talk page icon is very immature. It needn’t a smiley-face     on it.
 * 5) Why are the language links at the     top of the page when most people would have no reason ever to use them?

Overall, while Vector could do with some modernisation, it does not need a change in layout or arrangement. Please get rid of all of these unneccesary “interactive” menus and just present the links as they are. The style of the page contents clashes with the new stuff. Steepleman (talk) 23:58, 18 January 2023 (UTC)


 * Whoever thought that Vector needed a design change needs to be fired. Immediately.
 * I'm not against making updates to make the website more readable, but I searched an article today and was greeted with the new design change which wastes 2/3rds of my monitor space. From what it looks like all they did was slap the mobile design into the desktop mode for no damn reason. Why on earth would anyone think it's a good idea to have the content of an encyclopedia page take up the middle third of a computer monitor while the sides are just completely blank for no reason? This may be the dumbest style update I've ever seen to a website since the 2010 Digg redesign which effectively killed the site. Sunjester1979 (talk) 00:27, 19 January 2023 (UTC)
 * I was reading an article and I clicked a redirect. I thought Wikipedia broke because there was a solid 1 1/2 inches of dead space on either side. The search bar sits near the center of the screen, occluding a massive portion of the text if you dare use it. The Vector 2022 Experience is awkward, claustrophobic, and it doesn't offer any improvements over classic Vector.
 * I might revisit this design after it's gone through some drafting, but for now I'm sticking with what I know. Sayer2681 (talk) 01:24, 19 January 2023 (UTC)

Desktop layouts need to be for the Desktop, not for a phone
The design update is very frustrating and follows a terrible trend of other sites doing similar things. In lieu of writing a pile of words about usability, accessibility, and general UX, I'd rather make a quick set of bullet points here.

• The abysmal width is the worst offender here. There is so little space for content that you are forced to scroll more frequently.

• There is no room for content. Pages with more media content exacerbate the problem above a great deal.

• The floating topic list is advertised as a feature to 'Scroll Less', but it's working against that goal. It's consume so much of the now very finite horizontal space that you are forced to spend more time interacting with a scroll bar...again.

• Even if you expand it with the feature in the bottom right, it doesn't remember that option, so every new page view must be manually expanded.

• This attempt is clearly a design for a phone, not for a desktop. Good software needs to have two views built for two radically different form factors. Keep your views simple, your features light, and just do the work.

• There are so many other valid complaints here that I'll avoid echoing in text, but would like to +1 in spirit.

The new design is a UX disaster. It's fixing none of the actual problems of the old design, while introducing a huge pile of new ones... And stop letting front end designers make decisions about the web - they are collectively awful at their job. Kadecgos (talk) 00:26, 19 January 2023 (UTC)

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


 * Just... change back to Vector 2010? It's not that hard, just Preferences > Appearance > Vector 2010. Skarmory (talk) 03:49, 19 January 2023 (UTC)
 * It might be easy for people with accounts, but what about those without who have this layout forced on them? DolimiccanDragon (talk) 05:08, 19 January 2023 (UTC)

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

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

New UI forces massive amounts of whitespace upon users
This new UI that was unexpectedly rolled out (to people like me who didn't have accounts before now) forces an unreasonable amount of wasted whitespace upon people using high-resolution monitors. My main work system is a 4k UHD monitor, and the new layout reduces the amount of space used in a full-screen browser window to less than half of the window. It's ridiculous and makes the site much harder to use now. From looking at the FAQ and discussions, it appears this is intentional. I would urge the Wikipedia team to do some additional design testing on users with high res monitors, since the example screenshots shown elsewhere indicate that the bulk of testing may have been done on lower-res (1080p perhaps), which doesn't have nearly the same problem. Trynn (talk) 02:23, 19 January 2023 (UTC)


 * Agreed, looks very tacky on my 1440p monitor and makes the site feel cramped. We already have a mobile UI that takes advantage of vertical space, so I'm baffled on why this was greenlit for desktop users. If anyone from Wikimedia is reading this, please stop forcing mobile or mobile adjacent UI on desktop users. Theangrygrunt (talk) 03:05, 19 January 2023 (UTC)
 * I can not stand the new layout. I actually thought something was wrong with my browser at first. It looks completely out of place on desktop. My first guess was that I was seeing the mobile site for some reason, only to look it up and find out that this is how it's supposed to look now.
 * It feels incredibly cramped. The previous layout allows the content to take up a majority of the screen space, as it well should, while the Vector 2022 squashes the content only into the central third or so of the screen. Worse yet, the expanded margins aren't even used for anything. They're literally just completely empty. It would have been much more tolerable if the site at least used the full width available to it.
 * If the intent is to accommodate users with ultra-wide monitors, then why not implement a responsive element that limits the width of the content beyond a certain aspect ratio? Seems like a much better option than picking a fixed ration that's *lower* than a typical user's monitor.
 * And worse yet, changing the setting on Wikipedia does not apply it to all Wikimedia sites. Even this very talk page opened up with the Vector 2022 layout after switching my preference to Vector Legacy on Wikipedia. The9thBit (talk) 06:49, 19 January 2023 (UTC)

Paternalistic decision-making and breach of trust
One of the reasons I have appreciated the old design, especially for Wikipedia, is that unlike many other websites, it doesn't try to appeal to some hypothetical "needs of internet users today", and simply provides all the desired information on the screen, with little formatting or other manipulation of the text to achieve any particular goal or express a style. It is minimalist, but for a functional purpose; perfect for an encyclopedia. It is honest and sincere, and respects the user's competence to make decisions regarding how they would like to read that text. If I think that the lines of text are too long, I will reduce the width of my browser. Just because "most users don't" isn't a reason to force it upon people. Perhaps they don't reduce their browser width because they don't want to, for any reason they might have. I see this as an insult to the intelligence of your users. I see in the FAQ that "We [the designers] want it to be default". It doesn't matter what you want. A few people, who I suspect have spent a bit too much time in their own heads, are making sweeping decisions with regard to how a great many other people are to experience a service, the whole mantra of which is to provide various freedoms to people. I do not just find this to be ironic, but also worrying. Wikipedia is a public service, not just the plaything of egotistical front-end designers.

I understand that another reason for making these changes is to increase trust in wikis. I fail to see how a visual redesign can do anything but decrease trust if not leave trust just where it was beforehand. You may say that this design process has been through a great deal of community consultation and I'm sure it has, but the community is not the public. I use Wikipedia every day and have not known of these years-in-the-making changes until this morning, and there are certainly lots of other ordinary people, without Wikimedia accounts (I had to dig up my years-old barely-used account to switch the theme back and make this comment, and users should not be expected to create accounts to do the same) who would have never been aware of such a change, let alone been involved in the discussions surrounding the design or its necessity. I think that a change like this is a breach of their trust, and my personal feeling now is that I can not trust the powers that be to not make unpopular changes in the future such as this one, but that actually affect core principles of Wikipedia. I recently donated to the Wikimedia foundation and am now regretting that small amount, seeing as this is what it is being spent on.

I am hoping that whoever is responsible for making these changes and pushing it to the public see the error in their ways and revert the decision. MajorArchitect (talk) 03:11, 19 January 2023 (UTC)


 * Hear, hear. Well said MajorArchitect Sarri.greek (talk) 07:11, 19 January 2023 (UTC)
 * I agree whole heartedly with @MajorArchitect - the big problem for me isn't the ghastly redesign, it's the fact that though I am a daily user of Wikipedia and have been for years, this has been seemingly sprung on the general community. Xx78900 (talk) 08:46, 19 January 2023 (UTC)

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

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

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

The new language list location is so dumb.
Why do web developers love to move stuff to asinine places and then leave little "This has moved!" notes in their place? You clearly know how stupid this change is, so why do it? 181.43.109.79 05:52, 19 January 2023 (UTC)

Wide mode button not appearing
I got the new design today and I'm noticing that at my computer's resolution of 1440x900, the floating button at the bottom right to widen the whole page does not display. I assume that someone decided it wouldn't be necessary at my resolution, but it really does make a difference. I zoomed out to 90%, then the button appeared, so I clicked it, then zoomed back in to 100%. The difference is extremely obvious: Before vs After. Please allow the "wide mode" button to display at this resolution. Thanks! Numbermaniac (talk) 07:10, 19 January 2023 (UTC)


 * I'm in the same boat and agree completely, Numbermaniac.
 * Although it looks like you have to click the button *in every single page*, so I question its usefulness at all. 187.180.169.255 08:32, 19 January 2023 (UTC)
 * Hey @Numbermaniac, thanks for your feedback. We will be updating this soon. Here is the Phabricator task: https://phabricator.wikimedia.org/T326887. Cheers, AHollender (WMF) (talk) 10:36, 19 January 2023 (UTC)

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

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

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

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

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

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


 * I agree and I had to make an account to change back to the old one. Vector2022makesmesad (talk) 09:27, 19 January 2023 (UTC)
 * 10/10 name 90.145.57.18 10:46, 19 January 2023 (UTC)

An example of why this was a bad idea
So here i have created an example as to why its bad, firstly, for over a decade i have been using the wikis (plural as i have been active in a 100 or so wikis) zoomed out to either 80% or 67%, now this was done when you guys enforced Vector 2010, since the change also messed up a lot of scripts for the previous 'monobook' version, we had NO CHOICE but to move to Vector 2010 but because it was clunky and you had to scroll for days to read an article, i realized zooming out helped even if it meant i could barely read it, now after this new change, it seems like you have made it worse, its feels more like 'facebook' than a wiki where you end up scrolling a lot and the sidebars  are all either drop down menu's meaning every time you go to any article you have to click the drop down thing or click the  three lines on top to  get the previous sidebar menu which IMO is a bit irritating.. Now i have used a page i frequent here as an example in Wikipedia:In the news/Candidates, here are 2 examples https://imgur.com/a/HhKEiRM, the image on top is how that page is supposed to look in the old vector and you can see how perfectly aligned and informative it is, the image below is how it looks like now, all cluttered which poor spacing and worst of all, the date sections are now drop-down meaning someone trying to read this would have to manually do one date at a time to see what has been added, if anything, this change has made browsing harder and not simpler, infact its all cluttered in the middle with a lot of space on the sides for what "Enforced Adverts"? coming soon in 2023?.....I have 2 ideas you can try:


 * 1.) Create a poll on the main page so when people visit the site, they can vote Yes or No to keep the new format and if more than 50% vote no,  You remove this enforced skin after 7 days and only ad it as an option for logged-in users
 * 2.) Find a way that this enforced change only affects the 'article' namespace only, sounds like a bit of  work but whatever this thing you people have created will not work for all namespaces on this wiki or any wiki, infact before i could navigate farsi wiki but now i cannot because of the new skin, It also means to restore the  sidebar and cross-wikilinks section for all and also it has been mentioned before but the font colouring is poor as i can barely read stuff, needs more sharpening

Please don't tell me to to disable it via preference, some of us can no longer access certain wikis due to blocks but still USE IT, if anything, all this new skin has done is forced people blocked who did not want to create an account be forced to create one  just to make the wiki readable, and that socking is on you! ... lol... Stemoc (talk) 10:27, 19 January 2023 (UTC)