This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
Thank you all for your ongoing feedback - it has helped us make the skin better for everyone! As we previously discussed, we are preparing for the deployment of the Vector 2022 skin to all logged-out desktop users of English Wikipedia and those logged-in desktop users of English Wikipedia who both are using Vector legacy and haven't chosen Vector legacy in their global preferences. The change will take place on January 18 around 1415:00 UTC.
We want to make the transition smooth, avoid breaking workflows, and limit confusion and post-deployment issues. We're sharing some details and useful links below to explain how the transition will be performed.
This week and early next week, we'll make sure that the software version next week will be free from any easily noticeable imperfections.
This week and early next week, there will be banners incentivising logged-in users to switch to Vector 2022.
This week, we are also going to update affiliates such as WMCA, WMDC, WMNGA and WMUK.
Shortly after the deployment, logged-out and logged-in users will see banners informing them about the change.
As always, it will take at most three days for most of the cache to be updated. Before that, Vector legacy will load on some pages. After that, readers will see the new skin on any page.
Before and after the deployment, we will be hosting office hours. At those meetings, we will be answering questions on the skin itself, on updating any necessary gadgets and scripts, as well as receiving feedback on future improvements to the new skin. Please, feel free to join us at the following times:
As a reminder, logged-in users can opt out at any time. Those of you using a non-default skin (Timeless, Monobook, etc) will not see any changes. If you'd like to customize the skin, here's a dedicated FAQ section.
@OVasileva (WMF) and SGrabarczuk (WMF): I missed your original update I think, but I just want to clarify with regards to icons in the sticky header: which changes were made? I see the update mentions tooltips, but I think tooltips were already there pre-RfC? Were any further changes made to these after the RfC was started? ProcrastinatingReader (talk) 13:08, 14 January 2023 (UTC)
Hey @ProcrastinatingReader, thanks for your question! We did a couple of things after the RfC to improve the sticky header:
Reviewed our original sticky header research on icon recognizability, specifically around the sticky header icons to confirm if there was sufficient understanding in what each icon leads to. Users reported they were comfortable with most icons with the exception of beta features, preferences/gadgets, and contributions, all of which have labels within the user menu.
Worked on making the sticky header significantly more useful overall by adding a link to edit the page (which will be available in the deployment on Wednesday). Our A/B test showed that using this new link made it more likely for people to complete the edits they start using the sticky header and that edits people initiated and published using the sticky header were less likely to be reverted.
Prior to the RfC we also collaborated with the Editing team on improving the sticky header on talk pages, where the icon to add a new talk page topic also contains a label “Add topic” for clarity. (For details, see the #Talk page appearance section below.)
Does that answer your question? Did you have anything specific in mind which the answer above doesn't address? Thanks,
Sort of. Some of these seem to be pre-RfC, so I expect editors took these points and research into account when commenting with concerns. I'm wondering if anything specific has been changed or researched since that RfC, not including anything done or presented prior to that RfC starting. ProcrastinatingReader (talk) 15:23, 18 January 2023 (UTC)
@SGrabarczuk (WMF) I don't understand this phrase: "...and those logged-in desktop users of English Wikipedia who both are using Vector legacy and haven't chosen Vector legacy in their global preferences". I must be missing something, but how can someone be using Vector legacy if it's not chosen in global preferences? Can it be chosen in local preferences, maybe? (I'm not up on how all of the preferences work.) That phrase describes one group of users, right, who are "using but haven't chosen" vector legacy? Maybe I just need more coffee, but I am confused as to what this means. David10244 (talk) 10:51, 18 January 2023 (UTC)
Hey @David10244, thanks for this question. The preferences work the following way: when you go to the local preferences page, you'll see the default settings selected/activated for you. You may change them by selecting (choosing) anything different than the default. The global preferences are not active, though - by the default, there's no global skin selected. So in order to see the same skin across all the wikis, you need to activate it via the global preferences. Unless you do that, with each local change (such as the change of the skin here today), you'll experience this change. SGrabarczuk (WMF) (talk) 14:53, 18 January 2023 (UTC)
Oh, this is not good, not good at all. I'm glad we're allowed to choose our own layout, but I worry about how long we'll be able to keep the Vector 2010 version. If I wanted Wikipedia to look like the mobile version I'd access it on my mobile device. It looks terrible on desktop. Criticalthinker (talk) 10:33, 19 January 2023 (UTC)
@Criticalthinker I expect Vector 2010 to remain available basically forever, just like MonoBook is still available in spite of being replaced by (now legacy) Vector as the default skin in 2010. Matma Rextalk01:48, 20 January 2023 (UTC)
I'm a never-logged-in multiple times donator to the WMF and absolutely hate the change and the fact none of the preferences like widening the pages are saved as cookies. Until the new theme is either removed or allowed to be opted out for logged-out users I will not donate a single cent to wikipedia. 31.178.125.94 (talk) 14:09, 19 January 2023 (UTC)
The new skin is horrible. Tried reading a longish aricle last evening and had to stop after 5 minutes because I got severe eyestrain due to the very narrow text and way too much white space. It has effectively made wikipedia unsuable for me and as a result I will no longer be donating to the foundation unless you provide an option for users to switch back to the old theme. Thank you and have a good day. 82.78.21.194 (talk) 13:26, 20 January 2023 (UTC)
The new skin is really horrible on so many dimensions, and while I understand the reasons why some editors and specialized users appreciate vector 2022, the fundamental flaw in the rollout was making it the default without an easy, straightforward and persistent way to opt-out without forcing people to log-in against their will. Many of the "features" (and in my view huge drawbacks) of the new skin appeal to editors who are usually logged in and can thus easily pick their own skin. But the essentially obligatory default decision for rest of us should be based on a poll of those people who don't log in (and are overwhelmingly non-editors) given that the preferences of editors don't fairly represent the much larger non-editor reader community who are the ones negatively impacted by the non-logged in default. And until then, please undo those horrible forced changes until it's possible to straightforwardly and persistently opt out of the new skin WITHOUT FORCING READERS TO LOG-IN! 2601:14A:502:460:8899:6053:6A84:4191 (talk) 18:36, 21 January 2023 (UTC)
I understand this is some clique's pet project and some of you probably spent a lot of time on this "upgrade," but it is horrible and jarring. Why have you decided to gate the menu behind a click bar for unlogged in accounts? I hardly ever log in, and now I have to to access Random Article (a common hobby of mine and I'm sure others). I figured so long as I was logged in, I might as well add my voice to the chorus of (likely ignored) discontent.
When you are considering a change, you must realize that the change has to bring significant benefits just to overcome the loss of familiarity and inconvenience. Maybe your new mobile-esque view helps on the tech side, and if so that's great as I'm sure the technical aspect of wikipedia is very demanding. But the user experience is awful, and forcing everyone onto your "update" without allowing them to select the old view is short-sighted at best.
I get that you are not going to roll back this horrible skin. But at least please allow people to access the menu without an additional click, even if they aren't logged in. LeperColony (talk) 01:34, 25 January 2023 (UTC)
Sorry that a part of the intensity of the blowback is probably from other recent and current high-handedness issues with WMF and loss of perspective by them. But you showed a bit of that when, regarding feedback you led with / emphasized going by feedback derived from elsewhere and your interpretation of it. And I understand it takes some cleverness / can be challenging to get useful feedback from crowds. At this point I think that it would be good to derive feedback on specific items from the discussions HERE regarding things to change with the new format. And be guided by and acknowledge that feedback, especially where the changes are doable. Sincerely, North8000 (talk) 18:37, 20 January 2023 (UTC)
But you showed a bit of that when, regarding feedback you led with / emphasized going by feedback derived from elsewhere and your interpretation of it. And I understand it takes some cleverness / can be challenging to get useful feedback from crowds I want to echo what North8000 has said here. If I have learned anything in my education in public health and messaging, it is that the #1 quality you need to convince a lot of people that something is good for them is their trust. And that should have been at the forefront of your mind when deciding how, if at all, to implement this drastic of a change. All the t's should have been crossed and i's dotted, given the sentiment wrt the WMF on en.wiki. It should have been done as slowly as possible. Incorporate RFC#1 feedback, propose revised Vector 2022, create second RFC. Re-tool, and eventually implement Vector 2023. As they say, slow is smooth and smooth is fast. This was neither. — Shibbolethink(♔♕)18:43, 20 January 2023 (UTC)
So. That notice at the top of my pages here...
The one that says
Try out the new interface improvements
Search, language switching, sticky toolbar, table of contents, and more
I have my editing all fixed-up the way I like it, so I have some questions about these changes (or "improvements"). I don't want anything about my editing to change and I don't know if I even have a choice, I just keep my head down and edit stuff around here. So do I have a choice? Is it possible to disable these "improvements" and keep editing tools/style/appearance the same as they presently are? And if editors 'can disable these upcoming changes, how do we do that? Thanks, Shearonink (talk) 16:24, 11 January 2023 (UTC)
How to avoid this change: From reading the above, you should be able to opt out of this by setting your global skin preference to "Vector legacy (2010)" and ensuring that you do not have a "local exception on this wiki". This should mean that when the default changes, your skin will not (That is if I understand correctly). Terasail[✉️]16:50, 11 January 2023 (UTC)
Hi @Shearonink - thanks for your question and for trying out the new interface! Have you tried out the new skin for a couple of days? We've noticed that it can take a few days for folks to get used to the new skin and the new locations of the features. That said, you can disable it at any time. There's two ways to do this - the first is the link in the left sidebar that says "Switch to old look" and the second is from the appearance section of your preferences as mentioned above. OVasileva (WMF) (talk) 16:52, 11 January 2023 (UTC)
Lol, well, actually, no I haven't tried it out, I really don't want to. Oh I know it's wonderful and whatever but what I have now *works* fine for me. And I'm going to keep it. Shearonink (talk) 17:16, 11 January 2023 (UTC)
Good to hear. When the appearance of the editing window changes I find that confusing and off-putting. I like to know where things are and am an editing creature of habit. Shearonink (talk) 17:16, 11 January 2023 (UTC)
A side question: how is this banner scheduled to pop up? Is it still going to appear after the skin is deployed? There is no way to disable this banner in the preferences. I didn't want to adblock these banners, because I would hope they are supposed to be for important announcements. But now I am seeing it 4th time already despite having dismissed it. And I have toggled to the skin and back before and I have set my preferences - why does it still show up for me at all? Where is the "don't show again" option? — HELLKNOWZ∣TALK20:02, 11 January 2023 (UTC)
Hey @Hellknowz. Thanks for this comment. Sorry for making this a bit too annoying. I've decreased the number of times the banner appears from four to three. In many cases, it's five, for example in the case of the Community Wishlist Survey or the Wikimania scholarships season. (But for the call for nominations in the steward elections, it would be three.)
These banners will not appear after the skin is deployed. We will run different banners with a different target link. Those would appear three times per user at most, I think.
@Redrose64: Thanks for the suggestion. Unfortunately, the reply said "We will run different banners with a different target link" and didn't address being able to switch these off, so that won't help when something else pops up again later. — HELLKNOWZ∣TALK10:49, 15 January 2023 (UTC)
New Interface
Hi, So I decided to click the "New Interface" banner and now I regret it, Hate the new interface - it looks like the mobile version but just with more features, Is there anyway I can undo this new interface malarky ?, Thanks –Davey2010Talk02:16, 12 January 2023 (UTC)
Took me a while but eventually found it out, I don't know why anyone thought moving the Watchlist and Contribs to the "account" icon was a fantastic idea as it wasn't. My huge dislike is the reduced page size - I don't know why things couldn't stay relatively the same as now but just upgraded but then again Facebook, Twitter and YouTube like to "improve" their designs too and ironically I never liked those redesigns either but I live with it, .Anyway not for me I'm afraid. –Davey2010Talk02:31, 12 January 2023 (UTC)
There is a toggle width button in the right lower corner of your screen and you can change it in preferences. That way you have the new skin but the same width. Coldbolt (talk) 10:38, 14 January 2023 (UTC)
Hi @David Gerard - sorry for the double ping! Just wanted to note that last week, we made some updates to the toggle so that it will show on smaller screens and also remember the width selected across pages for logged-out users. More details are available in the update below. OVasileva (WMF) (talk) 23:42, 31 January 2023 (UTC)
The fact that the banner changes your skin if you click on it anywhere, but the ability to change it back is obscured by that very skin, underlines that the core feature of Scalar 2022 is coercion. It is an attempt to take away the reader's control over key aspects of their experience in favour of what the WMF have internally decided is best for them, especially article width, forcing the user into a linear reading experience. All this serves to do is to assert the primacy of corporate identity and power over freedom and respect for the user. This isn't anything new though: the aesthetics of power and linearisation have been festering in social media app design for years (recently reaching a new height of evil in things like instagram stories) but it's sad that it's finally infecting Wikipedia. –small jarstc11:13, 14 January 2023 (UTC)
The most similar case might be the old vs. new Reddit interface. I have the browser extension that auto-redirects to the old version, of course, but things are predictably starting to break and not get fixed over time (most egregiously and recently in the form of random backslashes appearing in some pasted URLs). Sooner or later, this will also happen to Vector 2010. And that's not even touching on the trend of platforms deliberately wrecking their mobile websites to goad users into using the official apps instead, which make for a much more convenient data collection and shoving-ads-down-one's-throat environment. Of course, you do need a somewhat serviceable app for that, so it probably can't become a thing for Wikipedia for at least another decade or so...Dr. Duh🩺 (talk) 13:16, 14 January 2023 (UTC)
Well I'm using MonoBook right now without any problems, so I don't think Vector proper is ever going to stop working. The problem is that most readers have no idea that there is a way to change the skin, and the page width toggle is worthless for logged out users because it resets every time you move to a new page. If that was fixed (and it could be with session storage and common.js) I would be a little bit happier, but Scalar gets in the way of readers' control over their experience in a bunch of other ways, and editors are going to have to do a lot of work reformatting articles so they don’t look terrible in the new skin.–small jarstc14:42, 14 January 2023 (UTC)
Hi @NGC 54 - Thank you for bringing this up! We've been keeping a close eye on this issue as well. The bug itself is not within the Mediawiki software but is an upstream bug in Chromium browsers (affecting browsers such as Chrome , Opera, and other Chromium-based browsers). We have reached out to the Chromium team who were able to put up a couple of patches to fix the issue late last week. Progress can be tracked here. OVasileva (WMF) (talk) 15:32, 16 January 2023 (UTC)
Opinion of a reader on this design change
Hello, I just read the RfC about (way too late unfortunately).
I'm French and a reader. Today I feel frustrated, not listened and betrayed by the WMF. I've been trying to voice my opinion on the Vector 2022 ever since it was forced on the French Wikipedia.
I'm normally a logged-out user. Here is what I have to say, I HATE IT. I deeply feel it's one of the dumbest changes of design I've ever seen. I created an account specifically to disable that disaster when it landed on the French Wikipedia. I still remember on the French Wikipedia how there was a lot of new account that just came to know how to disable or remove it. NO ONE LIKED IT or understood why it was forced on them, but the WMF is still pushing for it, not listening, no matter what. I voiced my opinion a number of time on the discussion page, but the WMF team NEVER listen to any of the negative criticism they were given. Each time someone tried to voice a negative opinion, someone from came gave as an answer "Have read this study and our blog that explain why did that?" (yes we did thank you, and we are still not convinced) and right after that we were ignored. Since then, I have lost any trust I had in the WMF to manage Wikipedia properly. And honestly, I have the feeling some higher up at the WMF is forcing this design on everyone else and everyone is afraid to say them no. Just look at the strategy they used to push the design, first targeting a non-English-speaking Wikipedia, so people can't complain but big enough to get feedback from the few English speakers who liked it and ignoring negative feed back (like mine). Then extending to other smaller non-English-speaking Wikipedias using the same strategy, then hitting small WMF services that barely anyone uses. See how the purposefully got around their biggest Wikipedia? Now they can push this disaster on it telling you "But look a majority of the other Wikipedia use it and are happy. Sorry, but the majority has spoken." And you'll see as much as in the discussion page all negative comments will be ignored, they will impose this on the English Wikipedia as they did to the French. DerpFox (talk) 23:50, 15 January 2023 (UTC)
Hello! This page exists for people to get technical help with Wikipedia. The technical workaround for your problem, for you, is to switch to a different skin in your Preferences. It sounds like you are upset with the process; I think a page like Wikipedia:Village pump (WMF) might be a better place to address those concerns. – Jonesey95 (talk) 01:30, 16 January 2023 (UTC)
Hi. The page you are pointing me to say to come here to talk about that subject. I know I'm not really in the right place. But there don't seem to be a right place for that anywhere I look, every time I posted somewhere I've been told "no this is not the place go look at *other page name*". The WMF have made it really difficult if not impossible to voice a negative option about that new design they are forcing on every one and the way they are operating that change. DerpFox (talk) 01:57, 16 January 2023 (UTC)
The WMF is hell-bent on imposing Vector 2022 and will never listen to the community on this one. The best we can do is change skins. For logged-in registered editors, this is an easy preference change, at least for now. When logged out, I intend to use User:Alexis Jazz/SkinEnforcer. Certes (talk) 12:00, 16 January 2023 (UTC)
Indeed. Having just checked it again, I have to say I totally don't get why they changed the old "menus at top and to the left, title plus article on remainder" to "menus at top and to the left, then a title, then a new line of menu items (underlined to make it look like a subtitle), and then the remainder of the article". It's a completely counterintuitive layout. Fram (talk) 15:28, 16 January 2023 (UTC)
This is on purpose?? I was trying to figure out where to report that it's giving me the mobile site. The new design is absolutely terrible. Thanks to Jonesey95 for pointing out the expand button in the lower right, which fixes most the problem, and is extremely easy to miss on a 4k monitor.
As a logged-out user, I shouldn't have to install some kind of script in order to have a readable site. I expect designs like this from social media apps that show contempt for anyone in a desktop browser, but not from Wikipedia. To reiterate: the new design is so bad I thought it was a bug.2600:8800:619D:1200:1154:5DC4:1C57:4C8C (talk) 16:37, 18 January 2023 (UTC)
Oppose, I really dislike this Vector variant ever since they introduced in my local-language wiki. It wastes lots of space on the side which should have been something useful (i.e. article text) or having some readily-accessible navigation there (like languages, permalinks, etc). Now various things only have cute "icons" and require click to actually see what the darn thing was, like how the dreaded social-control media sites are designed these days. And since these navigation elements are image now, have you ever tried to log in with images disabled? (I disable images a lot when I'm on GPRS connection with 6 KiB/sec download billed by megabyte, and Wikipedia had always been one of the sites usable in that condition)
I suspect you people at WMF haven't: you can't log in in that condition. (Spoiler: you will also have to disable CSS to see the login link, or you will have to enter the URL of Special:Login page manually)
At various points in beta-test (which I have not ever willing to participate), Vector 202x even killed navigability on my not-so-modern browser that I run without JS: language button died completely, user menu on the top went duds (prevented me from logging in to "opt-out"), left pane (when opened) end up pushing the article down into oblivion. The last one (including no-image bug above) still happen in this "iteration".
Also, my use of Wikipedia was 99.5% done in anonymous fashion; I'm not even given a choice to opt out in these cases, and had to manually append "?useskin=vector" (or "&useskin=vector") to the URL every single page load like a pleb because the damn thing doesn't record this preference in cookie when the session is not a logged-in one.
Overall, this is basically the same thing as shoehorning mobile web into desktop; and I condemn WMF for this.
Where did people vote to not have this Vector-202x as default again?
...Are you serious? The majority voted not to implement the new design, but you guys did it anyways? The old design was perfectly fine - there was no need whatsoever to change it (especially since no one was complaining about it, maybe except for you powerful few who had the ability to change it), and you should listen to the people who really don't like the new design. As an anon, I especially don't like the fact that the only way to change it back... (bar an extension or script that would almost certainly break) ...is to register an account. Yes, very clever, you implemented a new design that most people are opposed to just so you can get thousands of new people to register. Tell me, does it actually expend too many resources to allow anons to toggle on and off the new design? You could still cache the page and implement the reversion clientside afterwards - Nothing seems to have been added or removed since the update, just switched around, maybe except for the little button that toggles full width on and off. On that topic, why is full width not the default? Why do anons have to toggle full width on every time they click to a new article/page?
This won't happen because the people who could hold that vote already wanted the new skin and wouldn't want to face potential dissent. The most we can hope for is that the legacy skin is not rendered broken from lack of maintenance or outright removed. Vector2022IsAbsolutelyTerrible (talk) 18:39, 19 January 2023 (UTC)
The sheer volume of vitriolic opposition to this, the sentiment that people would rather spend money elsewhere if this is what wikipedia does with their donations, people asking for alternative options -- you would really think such a highly literate group of people would be able to see the writing on the wall. AtomicFi (talk) 19:35, 19 January 2023 (UTC)
Going live and opting out
It seems from the above discussion that the new skin may go live on 18 January at 15:00. Is that the case? Whenever it happens, many (perhaps most) editors and readers will want to opt out of this change. Should we be more proactive in informing them of why Wikipedia looks different and how they can reverse the change if they wish? I think this needs at least a watchlist notice and possibly even a banner on the main page for the benefit of unregistered readers who have no watchlist. Certes (talk) 15:26, 16 January 2023 (UTC)
Readers won't be able to opt-out officially, but DerpFox's comments above suggest that publicity for tools such as User:Alexis Jazz/SkinEnforcer would be very helpful. It might reduce the loss of readers to forks and mirrors which continue to use their preferred skin. Certes (talk) 19:37, 16 January 2023 (UTC)
The justification is that they wanted the change and ignored user and editor input that in any way opposed their goal.
Or the goal was to create a larger number of users with accounts, by irritating them into signing up.
I'm leaning toward "someone important liked this" and then unilaterally decided. Just look at the non-answers on the discussion page for vector 2022. All of the "Opposes" are just thanked for their opinion or they receive the same explanation as everyone else, regardless of the actual content of the issue they had with the design. It's bizarre. AtomicFi (talk) 19:40, 19 January 2023 (UTC)
How about instead of information about an "upgrade" nobody wants, you come up with a way to allow people to opt out without logging in or creating an account? LeperColony (talk) 01:36, 25 January 2023 (UTC)
Images and infoboxes competing for space
I'm not sure where to ask this question, perhaps if there's already a discussion, some more knowledgeable editor can link it for me here. Obviously Vector 2022 removes the table of contents from within the prose between the introduction and the first section, and this has a noticeable side effect which, similar to hiding the TOC on Vector legacy, brings the first section up, often to left of the infobox. Apparently over 3.1 million English language articles have an infobox. Many of these infoboxes are long, too long in my opinion, but that's another discussion. The end result however is, even when the "limited content width" box in the lower right is toggled on, that any images in the first section, say "History" or similar, get stacked up down the page, further and further away from their relevant prose. I work on several U.S. state articles, I'll point to Maryland, one I don't work on, as an example of this.
Help:Pictures#Avoiding stack-ups still advises me that stacking is a "problem" and gives several solutions to avoid it. I know users at WP:GAN or WP:FAC will frequently ding articles for this issue. Is stacking at the start of articles just an accepted byproduct, now that Vector 2022 will be the default? On my articles, should I do anything? Like should I avoid early images in the first sections? Should I use right-aligned tables to sit them next to infoboxes? Is there some new code coming to reduce the impact of long infoboxes? Or is all of this a moot point because desktop web browsing is dying and we should focus on how a page appears on mobile? Help, I'm very unsure here!-- Patrick Neil, oѺ∞/Talk15:49, 16 January 2023 (UTC)
Hi @Patrickneil: Two things: On Year in xxxCountry" lists - usually with very long vertical TOC, I've changed TOC to {{horizontal TOC|nonum=yes|align=center}}. This results in the beginning content much higher on the display, even with very long right-side infobox. With that horizontal TOC there can be limit 2 or 3 to condense the TOC even more. A while back I switched (under Preferences/Appearance) to MonoBook Skin, and have not looked back to either Vector. There seem to be zero problems with MonoBook & it's quick. Second, for Avoiding stack-ups, I've seen some articles with Gallery at bottom of that section, to place 3, or 4 or 5 smaller bio images. An example is here. Also, using "right" parameter for a single image to keep the picture floating within a specific content section may be helpful. JoeNMLC (talk) 16:49, 16 January 2023 (UTC)
I raised stacking/sandwiching early on as a potential issue with removing the table of contents, and @Blaze Wolf/@Styyx raised it again during the RfC here. As far as I can tell, the developers have not weighed in.
This leaves us with basically two options. We can either decide that some sandwiching in the first section is tolerable and we can align images there to the left, or we can embark on a massive campaign to remove them. I lean toward the first option, even given that we're now working with a narrower default width, since I've never seen sandwiching as the greatest evil, and the thought of losing thousands of good images (the first section is often History, with cool historical photos) just because of this is too much to bear. I'll ping @SandyGeorgia for your thoughts, as I know sandwiching is something that comes up all the time in your FAC/FAR work. {{u|Sdkb}}talk16:50, 16 January 2023 (UTC)
Was basically ignored because the example we gave also had a very small sandwich on the old skin, completely missing the point of the complaint. ~StyyxTalk?16:53, 16 January 2023 (UTC)
Sdkb A third option is to limit the (now miserably ridiculous) length of infoboxes, as that would eliminate most of the first section sandwich issues. SandyGeorgia (Talk) 21:40, 19 January 2023 (UTC)
@Blaze Wolf: Because of the MOS:SANDWICH issues related to the ToC you discussed here, as mentioned above by Skdb. The same set of problems are being discussed once again and I opened the linked section to collect specifically the opinions about the ToC. Æo (talk) 15:26, 1 February 2023 (UTC)
Maybe also reconsider if anyone really benefits from having a huge list of ‘state symbols’ at such a prominent spot in an article like Maryland, pushing stuff even further down. This boyscout-level collecting of meaningless symbols, is something that few outside a subset of the USA will truly care about or need to know. ;) —TheDJ (talk • contribs) 20:31, 16 January 2023 (UTC)
Thanks Sdkb et al, glad to know that at least this was pointed out earlier. I agree that for my personal browsing, I'm unlikely to stick with Vector 2022, but I feel like I need to know how articles might display to the general public, given that the majority of their readers won't be logged in or have a vintage skin selected. I know, for example, I've been making an effort to ensure my SVGs have transparent backgrounds and colors that also work on the Wikipedia app's dark mode for Android and iOS. But after staring at this skin all day, I can't help but think that, gee, there's this big block of wasted white space on the right side of the page. The TOC and/or Wikipedia menu takes up this block on the left side, but the symmetrical space on the right is empty. So I have to ask, has anyone suggested filling that space with the page's infobox? Again, there's 6.6 million articles, and 3.1 million of them have infoboxes. Below the infobox, it can just be white space, as it is on Vector 2022 now anyways. I made myself a little animation, since I can unsee this missed opportunity now. And yep, TheDJ, I am well aware of the utter trivial-ness of that Template:Infobox U.S. state symbols, it survived a merge attempt in 2020, but if anyone was to bring it to TfD, I would surely support that!-- Patrick Neil, oѺ∞/Talk02:05, 17 January 2023 (UTC)
Moving infoboxes to the right is non-trivial since infoboxes are an editor construct today and not a construct that the system knows about. There have been prototypes in the past that play with this positioning like mw:Winter, and I think today the responsive content gadget does some playing with some of the other elements that naturally float inline with the content on a wide resolution.
And ultimately, we would still have the problem of decreasing resolutions which would need to allow for the infobox being inline with the content or having some other way to 'dismiss' the infobox. Izno (talk) 02:40, 17 January 2023 (UTC)
Absolutely, I hear you about how tighter resolutions would bring the infobox into the prose anyways. Perhaps, like the app though, it could collapse the infobox in line after the first paragraph on narrow resolutions. I do think though that something with this omnipresence on Wikipedia should get considered in the sites future functionality, and not just be left as an "editor construct". But that's interesting about the tools, I'm certainly learning a lot about this process now, thanks!-- Patrick Neil, oѺ∞/Talk03:18, 17 January 2023 (UTC)
I have turned off the "show me tons of white space" option in Preferences and adjusted my own common.css to make pages display better. If there is a massive outcry about the WMF imposing all of this white space on readers and editors, perhaps we could set our default site CSS to make page content use more space. – Jonesey95 (talk) 16:26, 17 January 2023 (UTC)
Visited link color
I switched over to the the new Vector for a few days. Overall, I can adjust to just about everything with it, save one thing. The shade of purple used for visited links just seems too... soft... for lack of a better word. I'd like to switch back to the darker color used in the legacy Vector. I know I could add some custom CSS to switch the color. Can someone help me out? Imzadi 1979→20:39, 16 January 2023 (UTC)
Are there CS attributes for visited interwiki and external links as well? I'm getting the new purple in those cases instead of the older #0b0080. Imzadi 1979→23:56, 17 January 2023 (UTC)
There is a closed task phab:T213778 which implemented the change but has had meaningful discussion since implementation was done that I think the team should readdress, potentially with a new task. I would guess that Femke would have some amount to say. Izno (talk) 02:34, 17 January 2023 (UTC)
I found both link colors to be unreadably light, despite them apparently passing contrast tests. I added these customized colors to my common.css file, which worked for me:
a{color:#0645ad}a:visited{color:#58219a;
The colors came from me testing colors on a color wheel until they felt right, not from any scientific or precedent-based process. – Jonesey95 (talk) 16:28, 17 January 2023 (UTC)
My unscientific analysis of accessibility issues (using data that may under- or overestimate this easily by a factor of 2), indicated that almost a quarter of people had some accessibility issue with the new colours, which is likely less than the old colours. There is a follow-up discussion on the phab on my talk.
I still hope a further iteration is done, as it should be feasible to at least make the link colours distinguishable for colourblind people. I think that – rather than trying to solve this ourselves – we should look for precedents and ask WebAIM if they have example colours that work. —Femke 🐦 (talk) 17:22, 17 January 2023 (UTC)
I'm appreciative of the intent behind the new colors, but they're just too light. I applied the CSS above to Wikisource, which fixed a problem where new shade of purple for visited links just didn't stand out very well from the page status backgrounds on a page like Index:America's Highways 1776–1976.djvu. Imzadi 1979→23:59, 17 January 2023 (UTC)
The switch
It's now 15:00 UTC on January 18. As we can see the new Vector is being deployed on some pages after clicking links but mostly the old Vector styles still persists. Thingofme (talk) 15:54, 18 January 2023 (UTC)
There are problems here – I have manually switched back to Vector 2010 twice in my preferences (which FTR I strongly prefer, starting with the left-sidebar being far too wide (and not adjustable AFAICT) in Vector 2022), but pages keep defaulting back to 2022 layout against my fill. Please FIX THIS. I don't want to be forced to use Vector 2022. --IJBall (contribs • talk) 16:01, 18 January 2023 (UTC)
Same for me.
Articles are always displayed in Vector 2010 but talk-pages and project-pages revert to Vector 2022 at random. A couple of refreshes bring back V2010 but another additional refresh can revert to V2022. So, strange. How does these flaws make into live?! TrangaBellam (talk) 16:06, 18 January 2023 (UTC)
@IJBall: Came here to complain about that. According to the WMF staffer's post above, we have to change it back in our global preferences, otherwise the new skin will just override it again. If someone could explain to me why they have decided to make the local preferences unresponsive, I would be grateful. —Compassionate727(T·C)16:06, 18 January 2023 (UTC)
I have manually reset twice – it still does what User:TrangaBellam is referring to – randomly switching back and forth between 2022 and 2010. And, FTR, clearing my browser cache does not help. --IJBall (contribs • talk) 16:08, 18 January 2023 (UTC)
There are random switches, sometimes a page is shown Vector 2022 but sometimes the legacy styles were shown when I visit a page. Thingofme (talk) 16:13, 18 January 2023 (UTC)
When I purged the cache the style immediately changed to Vector 2022 but after coming back again it reverts back to Vector 2010. Thingofme (talk) 16:17, 18 January 2023 (UTC)
@IJBall and Thingofme: Like I said, you have to do in your global preferences. When you go into your preferences, you have to scroll down to the manage global preferences link, then change your appearance over there. See the screenshot. —Compassionate727(T·C)16:20, 18 January 2023 (UTC)
OK, that is seeming to work – thanks for the detailed explanation of doing it in Global settings Compassionate727!!
@IJBall - thank you for raising this and apologies for this situation. Since we are currently rolling out in stages in order to minimize server load, we are updating the skin default in four stages, which is affecting local preferences. Local preferences will work once as expected once again once the deployment is completed, in about 20 minutes. OVasileva (WMF) (talk) 16:18, 18 January 2023 (UTC)
OMG, how do I get my old display back? This is awful. It's like looking at the mobile version of the website. The menus at the top of the page are so tiny and sometimes they disappear completely. And there is all of this white space, there is actually less room for the content of the page. It doesn't make the page more readable but less readable. This website is all about the content, not having 30+% of the page be white space. And the links on the left-hand side are sometimes replaced by a table of contents. Is there an alternative to this view? I don't remember ever "choosing" this display. Help! LizRead!Talk!16:38, 18 January 2023 (UTC)
Once I found the Preferences link (which you have to hunt for), I was able to change my Display to Vector Legacy which resolved the problems with these new changes. I can't see, in any way, how these changes are an improvement. Some options you need, like an upper menu, are too small. The options/content you need is less visible and options you don't need are more prominent. I am just so grateful that there is the ability to go back to the more functional older version of the display. LizRead!Talk!17:04, 18 January 2023 (UTC)
@Liz:: OMG, how do I get my old display back? This is awful. I couldn't agree with you more. I get that maybe I don't follow things closely enough. I probably missed the super-obvious notification, I guess? I had no goddamn idea what was going on, or why the page rendered so weird. I thought the same "Did I follow a mobile link?".
This website is all about the content, not having 30+% of the page be white space. I couldn't have said it better.
Once I found the Preferences link (which you have to hunt for), I was able to change my Display to Vector Legacy which resolved the problems with these new changes. Same. Took me a moment to figure out what was going on, and where I needed to go to undo the changes that were selected for me without my input.
Why on earth was this unilaterally imposed on the community as the default after all?? An RFC was held to gauge the support to make this new skin the default and it ended with nothing close to a consensus in favor of Vector 2022, yet you just go ahead and ignore it and impose this on a community that clearly doesn't want it?? And what's worst is that none of the issued raised during the RFC have been addressed in any way. This is one of the worst cases of ignoring your community I have witnessed in the history of Wikipedia. Please roll back the switch of default as soon as possible.Tvx1 16:48, 18 January 2023 (UTC)
If this is the worst case of ignoring the community that you've seen, you've lived a gilded wiki-life. See WP:FRAMGATE as an example. Anyway, if you've been ported to the new Vector and you want to switch back, there's a bolded link in the left sidebar that will take you right to the setting in your preferences. Ivanvector (Talk/Edits) 17:07, 18 January 2023 (UTC)
@Ivanvector: agreed this isn't the worst WMF action ever but it's certainly not the best. Has there already been a well-attended discussion about whether this should be made opt-in rather than opt-out on WP? VQuakr (talk) 17:32, 18 January 2023 (UTC)
@Qwerfjkl: there clearly isn't consensus there to roll this out as default on WP. Is mousewheel scrolling in the skin broken for anyone else or is that just me? VQuakr (talk) 19:26, 18 January 2023 (UTC)
@VQuakr, hardly. From the closure of the RfC: If all the concerns outlined above are satisfactorily addressed then we see community support to roll out the change, and in our view no further RfC would be required, although the Web team is free to hold one if they wish. The concerns were addressed through the page width toggle and changes to the ToC. — Qwerfjkltalk20:26, 18 January 2023 (UTC)
Agreed. Reeks of the WMF becoming detached from WP's userbase. The fact that non-signed in users (e.g. non-editors, e.g. the entire point of this website's existence) can't opt out, period, is REALLY over-the-top obstructiveness. If it was a simple toggle and not a self-congratulatory Corporate Memphis banner explaining nothing, there would be no issue. Lucksash (talk) 20:37, 19 January 2023 (UTC)
agree as well, this is awful decision, but I expect that this will be brushed as a few vocal oponents voicing their negative opinions and no revert or any button/switch/ability to change skin to more appropriate desktop interface will come. IJustCreatedAccountBecauseOfThis1diocy (talk) 14:10, 20 January 2023 (UTC)
I'm looking at the main page now while logged out and it's popping up Vector2022. There's a plainly visible "create account button", but I have to click through an elipsis to find the link to actually log in. If I click on "create account", I'm taken to Special:CreateAccount, but that page also has the link to actually log in to an existing account hidden behind a menu. This seems like a glaring usability issue for those with more limited computer skills, since they can't ctrl+f "log" anymore to find the link to log in. — Red-tailed hawk(nest)17:44, 18 January 2023 (UTC)
It would be better than the current situation, yes. But it would still be less user-friendly than having text that says "log in" to the left of the text that says "create account". The contributions page and the talk page are a bit less important and can be safely hidden; logged out people get a giant orange warning when they have a new talk message, and there aren't really communication issues that would result from not being able to directly access one's contributions. — Red-tailed hawk(nest)21:35, 18 January 2023 (UTC)
@Red-tailed hawk, thank you for your comment. We'll definitely discuss this. The reason for this change is because a lot of potential future editors were not aware they could create an account. We wanted to direct their attention to the account creation workflow. The reason we collapsed the logged-in link is because people rarely log out, so it's an action that is not taken too often. We'll look at the data. If logins go down, that will be the strongest argument. But we'll try to explore different solutions anyway. SGrabarczuk (WMF) (talk) 00:18, 19 January 2023 (UTC)
@SGrabarczuk (WMF) People rarely log out???? No, I don't keep my computer on 24/7. And even when I do leave it on, Wikipedia logs me out automatically after a while. We genuine PEOPLE who simply USE computers as tools in our LIVES need to start standing up and not being dictated to by a bunch of computer troglodytes who can't wipe their own noses, but now find themselves on a power trip, giving us what THEY know WE want--whether we think we want it of not. To restate a thought put here by others, I expect that sort of thing from Google, Facebook, Twitter, TikTok--NOT from Wikipedia! — Preceding unsigned comment added by AzseicsoK (talk • contribs) 20:23, 28 January 2023 (UTC)
Wikipedia is configured to leave you logged in for a whole year. If you're getting logged out more frequently, then that's not normal for Wikipedia. Do you, perhaps, have your web browser set to clear all cookies when you quit the browser? Whatamidoing (WMF) (talk) 00:02, 1 February 2023 (UTC)
@Red-tailed hawk, @Xaosflux - thanks for the conversation on this. Just wanted to follow-up from office hours that we've flagged this as a potential concern with the team and will review the data early next week. We'll update with some ideas next week or the week after. OVasileva (WMF) (talk) 17:43, 20 January 2023 (UTC)
Three dots does not tell me that's where login is hiding
I mean, I guessed, because that's where the button used to be, but it's not intuitive, and I thought the idea was for Vector 2022 to be friendlier to new people. Red Fiona (talk) 21:02, 18 January 2023 (UTC)
I think so (I've been having to talk my Mum through working with her new phone so I have had "that is not obvious" drummed into me this week). Red Fiona (talk) 21:23, 18 January 2023 (UTC)
Will leave this open for a bit, we should first have a showing of support for it (or at least lack of objection after a reasonable time). — xaosfluxTalk21:25, 18 January 2023 (UTC)
Still not obvious: if the idea is to be friendlier to new people, do they even know what tooltips are, much less to seek them out? I don't know if my mom does. Can we assume they're in the habit of clicking or mouseovering symbols on the screen to see what those do? No. Just put the "log in" button nex to the "create account" button instead of actively making this part of the UI worse for all current and future users. --Kizor09:58, 19 January 2023 (UTC)
Note: I've updated the tooltip to say "Log in and more options" so now the three dots do tell you that log in is in there. I don't love this as a final state, but don't see any downsides as an intermediary step. — xaosfluxTalk13:48, 20 January 2023 (UTC)
The problem with sites being made "friendlier" is that they are designed by--thus friendly for--geeks and troglodytes whose lives are at their keyboards (I'll leave out the "Mom's basement" stereotype). THEY know where these things are hidden. What? There are people whose lives revolve around something other than computers? After a long history of being misfits, they are suddenly on a power trip, running things. They're deciding for us what we want--and they might or might not let us know. So they'll give us what they know we want--from the absolutely basic functions (like "on" or "off") being hidden behind an ellipsis to who we "want" to be the next President of the United States. Uporządnicki (talk) 13:59, 20 January 2023 (UTC)
And the Phabricator people don't seem interested to act on the request. Different approach required. Tvx1 17:03, 20 January 2023 (UTC)
Being a "keyboard" person, on the "Logged out" screen, I just do Alt+⇧ Shift+o (that's a lower-case letter o) to sign in. JoeNMLC (talk) 17:15, 20 January 2023 (UTC)
Just tried on an incognito window and the key combination works for me (as it is described on the tooltip upon hover). The combination might be overriden by something else on your browser? —Tenryuu 🐲 ( 💬 • 📝 ) 00:53, 21 January 2023 (UTC)
Or maybe this operating system-specific. On a hunch I restarded my dual-OS computer in Windows and in that system it does work. But far from everyone uses Windows, so it's not something we can rely on. Tvx1 20:34, 21 January 2023 (UTC)
If it's Apple it's probably something along the lines of ⌘ Cmd+⇧ Shift+O. The tooltip on hover usually gives the appropriate hotkey combination. —Tenryuu 🐲 ( 💬 • 📝 ) 20:46, 21 January 2023 (UTC)
Even so. There are many users who don’t use devices with keyboards to access Wikipedia. Thus access keys is not something to rely on to circumvent the ellipsis. Just move the log in button from behind that ellipsis, will you.Tvx1 17:42, 22 January 2023 (UTC)
Login button now to appear outside of menu for logged-out users
Hello everyone. Thank you for your continued feedback! We wanted to update you all on another change the team is currently working on based on what we've been hearing.
Since the deployment, based on your feedback, we have changed the threshold for the width of the pages at which the toggle is available on and made the toggle persistent across pages to all logged-out users (read more), deployed the new page tools menu and made post-deployment fixes and concerns (read more), and addressed some smaller bugs and issues.
In a few days, we will be updating with some suggestions for changes to the table of contents styling and behavior, as well as continuing the conversation on the visual separation between menus and sidebars, and the page content. We will also publish some of our initial data on skin usage and opt-outs.
Since the rollout of the new skin, we have read a lot of comments about the new location of the login button. Initially, we had placed the login button behind a menu so that we can draw attention to the account creation workflow, and because logging in is a fairly infrequent action. However, due to current issues with the global authentication system (which requires people to log in more frequently than expected), as well as the number of concerns we're heard here and on the ongoing RfC, we've revisited this and moved the log-in button outside of the collapsed menu and as a link on the page itself, as in the Vector legacy skin.
This means that now the login button will return to being accessible with just one click.
A before and after comparison of the login button change
We hope to have the button available across wikis next week, which means we plan to have the change here on English Wikipedia available by next Thursday, February 9.
– Sliding is by-design, but should respect browser directive; a userscript is provided below to disable only this specific animation. — xaosfluxTalk19:34, 18 January 2023 (UTC)
I can see how having a sticky-header on pages can be useful. But is there a way to avoid the slow animation of it appearing when I scroll down? It seems to have become a popular GUI feature, but I find it distracting. I move quickly, and it feels sluggish when the GUI has to "catch up" to what I'm doing. It also breaks by concentration by having so much motion at the top of the screen if I'm reading further down. MSOffice added that sort of thing a decade or so ago, and included a "disable animation" option. Could we have such a simple overall option, or is there a CSS trick for it? DMacks (talk) 16:13, 18 January 2023 (UTC)
@DMacks maybe it's my computer, but I'm not seeing this as an "animation" at all, it seems to be a "snap" overlay - tried with firefox and chrome; are you seeing this as a moving (rolling down?) header? — xaosfluxTalk16:37, 18 January 2023 (UTC)
If I am reading this correctly, this is more of a visual preference rather than anything broken. So I provided some css below that should remove the animation and make the sticky header "just appear". Terasail[✉️]16:55, 18 January 2023 (UTC)
@Xaosflux To be clear, I tested the sticky header with and without the reduce motion setting, and it worked as expected for me. The snippet is probably useful though if anyone wants to disable this particular animation without affecting everything else on their system. the wub"?!"17:43, 18 January 2023 (UTC)
When I am looking at a diff, the full article is below the two-column diff panes. The entries in the side-bar table of contents link to the sections in the full article pane. Except the "(Top)" table-of-contents entry, which takes me to the top of the diff panes rather than the start of the article in the article pane. DMacks (talk) 16:22, 18 January 2023 (UTC)
@DMacks making sure we got this, when looking at a diff such as this one, scroll down. Clicking on (Top) goes to the "#' (top most) section of the current page, but you would rather it scroll you to the top of the article text for section-0; correct? — xaosfluxTalk16:41, 18 January 2023 (UTC)
Bingo. It's inconsistent with the rest of the TOC. No objection to a "scroll to top of diff" link, but that's just as easy to do using my browser 'home' key. DMacks (talk) 16:44, 18 January 2023 (UTC)
I haven't changed anything. TOCs have disappeared. Makes it hopeless trying to find sections of articles to edit, especially in long articles. Same for talk pages, Wikiproject talk space etc. Put the TOCs back as they were!!!! Mjroots (talk) 16:52, 18 January 2023 (UTC)
I've gone back to the previous skin. New one is crap. There was nothing marked "tools" on the left of any page that I was on, so that comment was not useful for me. Mjroots (talk) 17:00, 18 January 2023 (UTC)
OMG User:Qwerfjkl THANK YOU for the Global Preferences setting stuff...all the white space & having to hunt for my tools...I know the next time I went into another section of the Wiki-Universe, I would have been utterly and completely lost as to how to get things fixed. Shearonink (talk) 17:43, 18 January 2023 (UTC)
@Transcleanupgal, there is not current support to store this sort of setting client-side and as an IP may be simultaneously in use by multiple people having one person be able to change things for someone else is not useful (also someone's IP can change as they browse, also breaking such a preference from being stored server-side). — xaosfluxTalk19:48, 18 January 2023 (UTC)
for the record, simply "registering an account" isn't enough, one also needs to be actively using it. Secondly, why would you consider having settings for "IP" ueers stored server-side? There are plenty of session-based storage systems. -- 188.26.86.68 (talk) 19:57, 18 January 2023 (UTC)
Ironically, this section doesn't show up in the new ToC. Also, if you hide the Contents there doesn't appear to be any way to get it back. Praemonitus (talk) 15:32, 19 January 2023 (UTC)
I fully agree. The ToC by definition should be an essential part of the article, below the lede, introducing and giving an overview of the text body and its subsections. The new ToC is completely useless and confusing; and, yes, it is indeed ironic that subsections like this one ("TOCs") are completely hidden and unreachable without scrolling the page and reading through the myriads of section titles and comments. Also cfr. my RfC comment about it. Æo (talk) 19:31, 19 January 2023 (UTC)
@Izno:, I'm seeing greater-than signs, not triangles. I suppose they work like triangles in expandable lists, but it wasn't intuitively obvious. Praemonitus (talk) 01:26, 20 January 2023 (UTC)
The Vector 2022 skin is now the default across English Wikipedia, which means that all logged-out readers and editors will see this skin, and that all logged-in readers and editors who had Vector 2010 as their skin were switched to the new one. Thank you for all of your questions, feedback, and time dedicated to this project - it has helped us make the skin better for all readers and editors!
This is a big change for a lot of users, and today's deployment has been a major technical undertaking involving many staff. If you see any issues with the deployment, or are hearing about problems or confusion from others, please reply here and let us know so that we can pursue and fix them as soon as possible.
If you are new to the skin, we (the Web team at the WMF) encourage you to explore our landing page for information on configuration, gadget compatibility, bug reports, and the deployment and consensus-building process here on English Wikipedia. For general questions, you can refer to our FAQ or ask us directly here or on the talk page of the project.
If you would like to turn the skin off or switch to a different skin, you can do so from the "switch to old look" button in the main menu (left sidebar), or from the "Appearance" section in your preferences.
For those of you looking forward to the new page tools menu - we've experienced some last-minute issues in the release of the feature and will wait for this week's deployment train to ensure all changes are as expected. We will release the new page tools menu on Monday, Jan 23.
Though today's deployment is a major milestone, we are definitely planning to continue to improve and adjust the new skin. We'll be fixing bugs and thinking about and discussing how else the skin can improve for editors and readers. Therefore, we're looking forward to your continued feedback on the new skin. If you decide to try it out, we, the Web team, suggest trying it for at least one week prior to deciding whether to switch to one of our older skins. It usually takes a few days to begin feeling comfortable with the new interface. That said, if you are unsatisfied, you may switch to any of the other skins at any time.
Once again, we would like to thank all of you for your help over the last three years of development - from giving us constant feedback to helping us draft and run the RfC, to constantly keeping us accountable for our decisions and their impacts on readers, editors, and communities. There are more of you than we can count, but to name just a few: the closers of the RfC who did a lot of work analyzing and summarizing the RfC (ProcrastinatingReader and ScottishFinnishRadish), and also: Andre, Awesome Aasim, Barkeep49, Bilorv, Blaze Wolf, Enterprisey, Femke, Ganesha811, Izno, JCW555, Jonesey95, L235, Lectrician1, Levivich, Pelagic, RoySmith, Sdkb, Sj, Steven Walling, Terasail, TheDJ, Qwerfjkl, WhatamIdoing, xaosflux, and Xeno - thank you, and let's keep the conversation going!
I got forced to the new skin, and all TOCs everywhere dissapeared. PUT THE TOCs BACK!!!! Apparently there was supposed to be "tools" on the left hand sidebar, but I never saw anything saying "tools". Fortunately, I was able to go back to the previous skin. Mjroots (talk) 17:24, 18 January 2023 (UTC)
@Mjroots - thanks for your feedback. The new ToC should be visible on the left hand side of the page. It does collapse at low resolutions to allow for more content to appear on the page. It can be opened by using the button available immediately to the left of the page title. OVasileva (WMF) (talk) 17:27, 18 January 2023 (UTC)
I understand that there are limited resources to develop a proper desktop skin as well as a mobile one. However imo the desktop experience of the new skin is not optimal. It is highly likely that most editors would use the desktop view to do serious editing. One thing I liked in the old interface is that it allowed me to go to the main page immediately. Now this is a two-step process. 67.243.247.14 (talk) 17:29, 18 January 2023 (UTC)
67.243.247.14, One thing I liked in the old interface is that it allowed me to go to the main page immediately. Now this is a two-step process - how so? Clicking on the big Wikipedia logo on the top works for me. — Qwerfjkltalk17:32, 18 January 2023 (UTC)
That is not on you. This confusion is rather because important navigation elements changed from descriptive words with explicit meaning, into icons (or in this case, logo) with no distinctive clue about clickability and user have to guess about where to click or what clicking it actually meant. (Also see @Mjroots comment about table of content "button" above) This is the same sort of dark patterns that lure users to do things on the web that they didn't mean to do; "UX devs" (I mean this in pejorative way) like to do this a lot these days. And even when looked at in the most optimistic way, this is a decline in usability.
I oppose this Vector 2022 deployment; mobile site and its obfuscated icon-avigation has no place on desktop. WMF applied this site-wide change without having a big side-wide announcement/notification about the vote; and still carry on (and weasel out the "consensus" to support themselves) in spite of more users voted against that in such stealthy vote anyway. I hadn't even got a chance to vote. This is just cowardice.
@OVasileva (WMF) / @SGrabarczuk (WMF) I mean this in the nicest possible way, as constructive feedback. Please don't ever do this to a project without an overwhelming consensus to do so, and appropriate very-obvious-over-the-top-annoying-level messaging (including detailed instructions on how to switch back) ahead of time again. SQLQuery Me!01:17, 19 January 2023 (UTC)
And don't make people create an account just to avoid this awful waste of screen real estate. See my username. Browser cookies are simple, long-established, stable technology with very low overhead. This should be very simple to remedy. If the powers that be can't undo this awful new design and bring back the perfectly excellent old one, at least make it so we don't have to create an account on here to do so! I haven't made a single edit in years despite being an *incredibly* heavy user of this site as an audodidact, independent researcher, and amateur historian. Most people won't even bother, or won't realize that making an account will let them opt out of this mess, and will just suffer through it or take their web surfing elsewhere. IWantTheOldInterfaceBack (talk) 04:52, 19 January 2023 (UTC)
Kill it! It’s evil! —GLaDOS on the new vector skin. But seriously folks, if I wanted a mobile view on my computer… I don’t know what I’d do, but I don’t want a mobile view on my computer, or on my tablet, and yet this is exactly what this new skin looks like. I’m extremely glad I was at least able to switch it back to the classic look, which was perfectly fine and did not need to be ”improved”. Who approved of this New Coke-for-wikipedia crap? Dronebogus (talk) 17:50, 20 January 2023 (UTC)
Adjusting the new Vector 2022 skin to reduce white space
Vector 2022 with customizations via User:Jonesey95/common.cssVector 2022 without customizations in the same browser window (usable space is 1,230 pixels wide). Broken infobox formatting, with centered items failing to center. No full-width toggle. No article prose is visible. TOC is not visible yet. Empty sitenotice using 24px. Left sidebar much wider than necessary.
I am normally a crotchety old person who avoids new stuff, but for some reason, I decided to give Vector 2022 a real try. After using the Vector 2010 skin for over a decade, I started using Vector 2022 a few weeks ago, and I ran into a lot of the same problems that people are discovering today. The primary problem is that there is way too much white space in the new skin, despite zillions of people complaining about it to the WMF for months (years?). Some of the white space is by design, and some of it is caused by a variety of bugs and unfinished polishing of code. While waiting for the developers to fix the Vector 2022 bugs, I have hacked my common.css file to eliminate most of the problems. With these hacks in place, I have found Vector 2022 to display quite nicely.
If you are interested in trying to adapt Vector 2022 to make it usable from a white-space perspective, you could give my hacks a try.
The first step is to go to your preferences, choose the Vector 2022 skin, uncheck "Enable limited width mode", and click Save. That will make page content somewhat wider.
Then go to Special:MyPage/common.css, which will open your personal CSS file. If you are bold, I recommend copying the entire "white space issues" section of User:Jonesey95/common.css (up to about line 66) to your common.css file. Save it, and then reload the page.
If you like those changes, you might consider adding the Table of Contents hacks as well. The modifications farther down the page are of more questionable value, and I can't recommend them unless you are more comfortable with weirdness.
YMMV, and caveat emptor, and all that. Please report back here with comments and potential improvements. If something goes wrong, you can go back to your common.css file, select all of the text that you added, and delete it. That will return you to the default Vector 2022 interface. – Jonesey95 (talk) 17:51, 18 January 2023 (UTC)
Update: I have added a few more customizations, including continuing to reduce large amounts of (IMO) excessive padding, and hiding sets of links that I have never used in ten years of editing, and I've gotten Vector 2022 to look a lot closer to Vector 2010 while keeping the left-side TOC (in view on page load!) and some of the other updates that I see as helpful. This dense version of Vector (see first screenshot) will not be everyone's cup of tea, but if you are intrigued, feel free to copy items from User:Jonesey95/common.css. – Jonesey95 (talk) 03:09, 23 January 2023 (UTC)
Gadget updates?
I see in the original comment that there was a commitment to update necessary gadgets. Where do these things stand? For instance I am very much missing the gadget that allows me to view the UTC clock. Best, Barkeep49 (talk) 18:35, 18 January 2023 (UTC)
Hi @Barkeep49 - thanks for your question! In terms of gadgets, we've worked with gadget maintainers to have as many gadgets as possible be compatible with the new skin before deployment. After deployment, we're on the lookout for reports on issues with gadgets and scripts and can advise and help with fixes. The clock gadget in particular is now available in the dropdown user menu at the top of the page. We could look into whether it's possible to have it display outside the menu as well. OVasileva (WMF) (talk) 18:55, 18 January 2023 (UTC)
Thanks for that update @OVasileva (WMF) but it's not working consistently. For instance if I click when at the top of this page the time appears. When I clicked on it just now before replying, or on other pages where I've scrolled down a fair amount, it doesn't. And to be honest the gadget loses a fair amount of utility being buried there. Given that I've updated into this change - just as I did in old Vector - I'd like it to be prominent otherwise I might as well just pin a tab with a UTC clock because at least that tab would work no matter how far down a page I am. Best, Barkeep49 (talk) 19:16, 18 January 2023 (UTC)
Barkeep49 and others: You have noticed that the two menus labeled "User menu" with a tooltip and represented by an identical icon of a human torso are not, in fact, the same menu. This seemed like a basic user interface error to me, but when I brought it up at T325124, I was told that it was intentional that the two identical-looking menu-activation icons popped up different contents depending on whether the icon was in the top-of-page header or in the "sticky" header. I haven't found a workaround yet. – Jonesey95 (talk) 22:36, 18 January 2023 (UTC)
Thanks Jonsey for that link and explanation. It's genuinely helpful. I am completely surprised that their UX testing suggested that it wasn't an issue to have identical icons doing different behaviors. Best, Barkeep49 (talk) 22:41, 18 January 2023 (UTC)
Barkeep99, I'd rather not single that person out, but my sense was it was a gut reaction to change and starting an RFC won't be a problem here. They are pretty respectful of enwiki process from what I can see.
The two menus are different, indeed. If the clock wants to add itself to the sticky menu, it can call mw.util.addPortlet like so:
:::::// add gadget outside menu
:::::mw.util.addPortletLink('p-vector-user-menu-overflow', '#', 'test outside dropdown' )
:::::// add link to dropdown
:::::mw.util.addPortletLink('p-personal', '#', 'test link in dropdown' )
:::::// in sticky header dropdown
:::::mw.util.addPortletLink('p-personal-sticky-header', '#', 'test link in sticky header dropdown' )
:::::
I've reached the point where enough stuff that I depend on wasn't working (much of which like WP:SUPERLINKS I wouldn't expect someone else to fix for me) that I've switched back to classic Vector so I won't be starting any RfC. If you or someone else does start please do let me know as I'd like ot be a part of that discussion and consensus finding. Best, Barkeep49 (talk) 21:13, 19 January 2023 (UTC)
In Firefox, there is an option to create a user stylesheet (not to be confused with custom stylesheets on Wikipedia) which can reformat all webpages. How can I, before I log in, use this to make the Vector 2022 have the user menu stuck open without me having to click on the menu button? I would also like the menu to be wider, with items "inline" (in a horizontal row). I know this will require some white space above the heading in order not to hide the coordinates and other content in articles, but I don't care about the extra white space I will have to scroll through.
I mean the three dots next to "Create account" in the top right corner of the screen. The menu I must use in order to log in. Utfor (talk) 18:35, 18 January 2023 (UTC)
@Utfor while not what you are really looking for, if your main goal is just to have a login link because that is what you are always wanting there, you could script to change the create account button to a logon button. (Still peeking at your original request, but it may require js not just css). — xaosfluxTalk18:46, 18 January 2023 (UTC)
User:Xaosflux Clicking the three dots is an extra step I must take to get to the login page. I would like a login link I can click directly. I know that I can create a bookmark in the browser, but this is not what I am looking for because it does not return me to the page to which I have navigated. Utfor (talk) 19:02, 18 January 2023 (UTC)
I am not totally certain how to make that apply only while logged out. I see no useful selectors on the body element. Izno (talk) 19:36, 18 January 2023 (UTC)
User:Izno Thank you very much! This is great! You have saved me for many wasted log-in clicks! It does not matter if it does not apply only when logged out. Utfor (talk) 20:26, 18 January 2023 (UTC)
A JS solution would be less prone to future breakage:
Toggle for expanding screen width not visible on Wikipedia, but visible on Mediawiki
Also Mediawiki displays at an almost illegible tiny text size on my desktop, while the size of Wikipedia text is larger on my desktop than on my laptop. Is this how it is supposed to work? · · · Peter Southwood(talk): 18:41, 18 January 2023 (UTC)
@Pbsouthwood - thanks for your report. Could you share some screenshots if possible? The toggle should be visible across all pages and projects once your screen is wide enough for it to not overlap the content (around 1600px). OVasileva (WMF) (talk) 18:49, 18 January 2023 (UTC)
Xaosflux, OVasileva (WMF) I am not sure how to check current zoom level, bu it is affected by zoom. When I zoom out it appears along with grey margins, when I zoom in it disappears along with the grey margins. So probably not a bug so much as not being able to see something I was told would be there. An explanation in the FAQ should suffice. · · · Peter Southwood(talk): 07:18, 19 January 2023 (UTC)
Xaosflux I am using Firefox on windows 10 on dektop, Firefox on Windows 11 on laptop, so pretty average OS and browser. Firefox is automatically updated on both, so probably latest version, · · · Peter Southwood(talk): 18:16, 26 January 2023 (UTC)
English: Screenshot of the English Wikipedia showing a bug that adds a scroll bar. Chrome 109 on W10
When on the Main Page, if you turn off limited content width with the bottom right button a scroll bar will appear across the bottom of the browser window. You can only scroll side to side ~6px and this issue doesn't appear on any other page while using Vector 2022. StereoTypo (talk) 18:55, 18 January 2023 (UTC)
Previously when I hovered on the star at the top of a page, it would pop a tooltip "Add this page to your watchlist" or "Remove this page from your watchlist". Now, when a page is scrolled down so that the star is in the persistent header, that is still the behavior. But if I am scrolled to the top of the page, hovering on the star in the full header instead gives me the usual popup-pageview as for a regular bluelink. DMacks (talk) 19:07, 18 January 2023 (UTC)
Yes, this is a navpopups problem. I vaguely remember that nav popups has a list of elements that it ignores generally and this likely wasn't updated yet for navpopups. —TheDJ (talk • contribs) 21:57, 18 January 2023 (UTC)
Between the overshoot on whitespace, article layout issues, and broken navigation it seems like a no-brainer that Vector 2022 shouldn't be the default on enWP yet, if ever. Thoughts on rolling this back until the skin is fully cooked? VQuakr (talk) 19:38, 18 January 2023 (UTC)
Rolling it out in this advanced beta form is probably the only way to get enough eyeballs on it to get the remaining obvious bugs fixed. I am certain that the WMF development teams cleared their calendars in advance and will be working feverishly on the dozens of bugs that are submitted this week in order to show that they are committed to the success of this product. That is the only sensible way to manage a product rollout of this type. It will be a refreshing experience to see a beta product rolled out and then have a bunch of little annoyances polished off in a few weeks. – Jonesey95 (talk) 22:43, 18 January 2023 (UTC)
So I have troubles finding a solution in which I want to move table of content (TOC) back to the top as it was in the old skin. Any suggestions as how to do this if this is possible? Otherwise, skin seem to be adequate for me personally, so far. --Legion (talk) 20:06, 18 January 2023 (UTC)
@Chief of Staff if by "the old skin" you mean Vector legacy, the TOC wasn't "at the top" it was "in the content" (by default at the bottom of section-0) - is that what you mean? — xaosfluxTalk20:22, 18 January 2023 (UTC)
Sorry, I should clarify that I was asking for desktop version. The TOC was always at the top of the article in desktop version. Not the top of the overall page itself. My apologies for the potential confusion. Legion (talk) 20:45, 18 January 2023 (UTC)
A suggestion to add to your "Lessons Learned" review
I won't add to the abundance of complaints about this new skin (although I could if the representatives from the Foundation wish), but I'll suggest something that should be discussed in your postmortem on this rollout. Like many, I was surprised to find the new skin when I opened Wikipedia this morning (PST time), & wondered why I had not seen any announcement that it was coming. I see from your comment above that you did publicize this rollout -- you announced on this page, probably on some of the communication channels -- but in the banners announcing beta tests for this new skin, I didn't see any announcement that a rollout was planned.
Like many on Wikipedia, I tend to focus on the content, & not so much on bulletin boards or other announcement pages: I make my edits, look at updates on my Talk page, or any pings, then return to my off-Wiki life. While I did see the banners about beta testing the new skin, I assumed these were not part of any immediate rollout, but requests for feedback on proposed changes, & since I had no strong opinions about the interface I ignored them. Now had I known this was part of a planned update with a specific date, I might have participated in the beta test, but I definitely would have known the default skin was going to be changed. To make my point clear, next time the Foundation plans a major change like this it would help if the banners were also used to announce this, & not just depend on announcement on the relevant bulletin boards. -- llywrch (talk) 19:50, 18 January 2023 (UTC)
Thanks for this feedback @Llywrch - this is a good idea. We will definitely be compiling a list of lessons learned that we can use for future releases. We did run banners to all logged-in users announcing that the change is happening this week. Unfortunately, it seems that because these banners came right after the general banners for people to try out the skin and the banner design was quite similar, the change in the banner content wasn't as obvious as we had hoped. OVasileva (WMF) (talk) 19:57, 18 January 2023 (UTC)
Hmm. If there was an announcement, then I didn't see it. And since this caught more than me by surprise, I'm guessing that announcement wasn't visible enough. -- llywrch (talk) 21:11, 18 January 2023 (UTC)
As I always say: Ppl will always complain about lack of announcements. It doesn't matter how much communication is done. if ppl don't care about it, hide it or simply skim over because they work on other things, no notification other than blocking them from achieving their goal (ie. by blanking the entire page) will make them notice. Ppl are not here for caring about the skin, they are here to build the wiki. There is no fixing this problem and its already part of every "lessons learned". —TheDJ (talk • contribs) 21:12, 18 January 2023 (UTC)
Some people noticed, others didn't. That is pretty much a universal constant. If the notices are made unmissable there will be other complaints about them being obtrusive. Someone will always complain. Many of us have learned how to not see advertising because of all the clickbait we get spammed with on the internet, so we also miss notifications. It is a defence mechanism. Has there not been a study on how best to notify the community while annoying the lowest number? Is it up to date? · · · Peter Southwood(talk): 07:35, 19 January 2023 (UTC)
Only it was in reality "a few people noticed, almost everyone didn't. And there's not just some complaining. Almost everyone is complaining and requesting the changed back. Time to accept reality and do so!!Tvx1 17:34, 20 January 2023 (UTC)
Heavily used menu items
The heavily used choices should be available as words and direct choices, as they were before. "Watchlist" is hidden behind an icon and introduces a big delay to what used to be fast. Other heavily used choices were not only moved to sub-menu items but the menu that they are buried in is itself hidden behind an icon. Also page curation choice disappeared. North8000 (talk) 21:30, 18 January 2023 (UTC)
"page curation choice" what is that ? Doesn't sound like a default part of the software, maybe its a gadget that you installed which needs updating ? —TheDJ (talk • contribs) 21:55, 18 January 2023 (UTC)
I don't know the IT side, but it's the entry into the New Page Patrol universe and toolbox, a large and important part of the Wikipedia system. I think that the overall system/ toolbox is called page curation. Sincerely, North8000 (talk) 22:45, 18 January 2023 (UTC)
I think you're referring to User:Lourdes/PageCuration.js, a user script which you have installed. I tested it just now and the link still appears, it is just hiding in the top right dropdown menu. Try clicking on the person icon and see if that reveals the link for you. Hope this helps. –Novem Linguae (talk) 23:14, 18 January 2023 (UTC)
@Novem Linguae: Thanks but I don't see it there. BTW whatever it is, my intentions were to just use the main official toolbox for NPP. North8000 (talk) 14:40, 19 January 2023 (UTC)
@Novem Linguae: Thanks. That's where I looked and it wasn't there. Then after I saw your post I went to my user page and looked at that menu and it was there. Maybe that "woke it up" because now it is always there, e.g. when at other articles. Thanks. North8000 (talk) 16:53, 19 January 2023 (UTC)
Font rendering bug related to scrolling on new vector style
I'm noticing a new transient error on multiple pages since the new vector theme was released. Sometimes after scrolling the page up/down and stopping rapidly, the text font will appear "doubled", as if two versions of it are laid over each other, causing the text to appear bolder/deeper black, and have much higher contrast, which is ugly and causes slight artefacting around character edges. This will then resolve after scrolling away/reloading/switch the tab away and then back.
The most reliable way I have found to induce this is to scroll down on a long page and then hold the mouse wheel to scroll up to the top very rapidly, making the top of the page stop the rapid scroll instantaneously. This will semi-reliably produce the bug after a few attempts. I am using Chrome on Win10. This never happened to me previously on Wikipedia before the new theme was released, as far as I can recall.
The issue looks like this (top is with the bug, bottom is without).
Obviously not a major issue, but I am lukewarm enough about the new theme without there also being irritating technical glitches with it that were not caught during testing. BlackholeWA (talk) 21:28, 18 January 2023 (UTC)
Ah, thanks for the heads up. It might be worth noting for the Vector 2022 developers that in the context of Wikipedia something in the new theme has induced it to occur, though. BlackholeWA (talk) 22:27, 18 January 2023 (UTC)
Hello @BlackholeWA. Thank you for raising this issue. I'm not sure if "something in the new skin is inducing this to occur" is the best expression (I'm not an English native speaker) but from the perspective of our team, the problem is solely on the side of the browser, and it's up to them to fix it. Our code is OK, this is what I take at least. Although yes, this issue exists in Vector 2022, and doesn't in legacy.
Where should reader feedback be directed? There's been feedback on article talk pages (ex. [1]), the Teahouse and Helpdesk. I also also suggest the WMF and other interested editors to keep an eye on the Teahouse and Helpdesk to gauge the response. Apologies if this has already been discussed above but if so, I did not easily find it. S0091 (talk) 21:52, 18 January 2023 (UTC)
If I am signed out, or signed in with an alternate account I use to thank people or see how things are for new people (normally this is only with private browsing), I have been shown a link to "Explore Wikipedia's new look". They show different ways Wikipedia has looked over the years and of course I prefer what was shown for 2011 and have my preferences set for that. If there is not already a topic for this, I just want to be assured all this will not mean changing what I want to see.— Vchimpanzee • talk • contributions • 21:34, 18 January 2023 (UTC)
Hello @Vchimpanzee. If you're satisfied with the 2011 look, then you're referring to what's now called "Vector legacy". Technically, it's a frozen version of the skin which since 2020, has evolved into the new default, Vector 2022. Unless I'm mistaken, Vector (legacy) is what you want. Correct me if I'm wrong :) SGrabarczuk (WMF) (talk) 23:31, 18 January 2023 (UTC)
Correction. If you go to the link I posted and scroll down and watch the look of Wikipedia change, it is the 2005 look that I want. I did notice differences in the 2011 look but it does have the right fonts.— Vchimpanzee • talk • contributions • 23:50, 18 January 2023 (UTC)
@Vchimpanzee note in private browsing/logged out mode - some pages may be displaying in vector, some in vector-2022 due to caching. Eventually the cache will clear the old ones. — xaosfluxTalk01:31, 19 January 2023 (UTC)
The Vector 2022 page pointed me here to file a bug report. I'm not totally convinced this is actually the right place, so please redirect me if there's somewhere this is more likely to be acted on.
The sticky ToC is programmed to indicate the current section by detecting that section going off the top of the screen. When the sticky top bar is present, it is smart about scrolling the header to the correct position below the bar when you click a section title, but this logic is not reflected in the indicated section as you scroll, such that you frequently end up with zero lines of text from the indicated section visible on the screen (because they are behind the top bar). Personman (talk) 21:49, 18 January 2023 (UTC)
I briefly thought this might be impacted by my browser zoom, which was at 150% in that screenshot. But no, it happens at every zoom level: https://i.imgur.com/CEh2w1t.png.
While exploring this, I also repeatedly encountered another bug, where the indicated section gets totally stuck or is totally absent: https://i.imgur.com/PiQNGM1.png. This doesn't seem to be easily reproducible, but it happened three different times, after some combination of zoom changes, scrolls, and clicking Reply and then cancelling.
Thanks for the screenshots @Personman - this helped us identify the issue. I believe this can be resolved by the following tweaks to the ToC. First, we can increase the threshold for when a section is active so that the section which is on the screen appears first. You can track progress on this in this ticket. We will also be increasing the offset for when you click a link from the ToC so the title of the section selected has a little bit of space above it when selected. That should help with how close the ToC and sticky header are to one another. Progress on the second issue can be tracked in this ticket. Thanks again for the bug reports! OVasileva (WMF) (talk) 23:50, 18 January 2023 (UTC)
Also to note: we do have some known (but not yet documented) bugs with the table of contents on Talk pages. Are you experiencing these issues on article pages as well? AHollender (WMF) (talk) 23:49, 18 January 2023 (UTC)
Disabling "Enable limited width mode" as the default?
As many of us tried (and failed) to explain to the WMF developers, the huge amount of white space on the right side of the page continues to be the primary complaint among people complaining about this change. The developers allowed for a checkbox in the Preferences that reduces some of the white space, but that checkbox is not available to logged-out readers, and it is not the default here at en.WP. Should we consider an RFC (not at VPT, but at an appropriate location) to disable "limited width mode" by default for logged out readers, for people who are selecting Vector 2022 for the first time, and for those who have not expressed a preference? – Jonesey95 (talk) 23:08, 18 January 2023 (UTC)
@Jonesey95 there is a "toggle limited content width" button for readers. But (a) it is hidden at the very bottom of the page, (b) it is not persistent across anything, even following links or reloading the page. — xaosfluxTalk23:14, 18 January 2023 (UTC)
I have never seen such a toggle, though I have heard rumors of its existence. Everything I have seen has said that it exists for windows 1000px wide or wider. My (Brave, Mac OS, latest version) browser window has 1,236 pixels of space between the left side of the window and the left side of the scroll bar, but I do not see a toggle (logged out or logged in). A toggle does not appear, even if I hide the left-side TOC and menu. Is this a bug, or do I misunderstand the repeated references to a toggle? Maybe I just don't know what it looks like. – Jonesey95 (talk) 23:27, 18 January 2023 (UTC)
Why is so much Wikipedia functionality now hidden (maybe even obscured?) behind icons in Vector 2022?...if you don't know what three dots or the "person icon" or what the toggle icon means, too bad. A lot of people, IP-readers and editors, experienced named accounts have been posting here and elsewhere on Wikipedia, like on Talk:Vector 2022 about "where do I find [a previous clearly-seen function]?". Shearonink (talk) 14:46, 20 January 2023 (UTC)
I can't make it appear, even in safemode, logged out. I have submitted T327368(ETA: Already existed at T326887). Maybe I just misunderstand when this thing is supposed to appear, but you can see from the screen shot at the bug page that there are huge white margins that need to go away for the page to display correctly. – Jonesey95 (talk) 03:57, 19 January 2023 (UTC)
I would support this. "Enable limited width mode" should be disabled as the default for all readers, logged in or not. Some1 (talk) 04:18, 19 January 2023 (UTC)
Just a personal preference, or have you done a survey with the readers for whom this feature was designed to support this request? My personal preference is larger font size as a default, because it is difficult to increase the font size if you cant read the instructions because the font is too small. · · · Peter Southwood(talk): 07:50, 19 January 2023 (UTC)
Just a personal preference and after seeing all the IPs (who I assume are general readers and not editors) complaining about the excess white space of the new skin. About the font size (and you may already know this), see if holding down the CTRL button then tapping on the + (plus sign button) helps; it should increase the font size of webpages including Wikipedia (CTRL+[minus sign] if you want to make it smaller). I don't think font sizes are adjustable in the User preferences; maybe you could add a proposal to https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2023 (which apparently is open for submissions in just a couple of days). Some1 (talk) 12:57, 19 January 2023 (UTC)
I'm probably one of the many people asking questions about the new skin. First of all, I would like to say how excited I am to be using this new skin. I am aware that I can change the skin back to old Vector if need be. I would like to know if there is a way for the search suggestions to display redirects alongside articles without having to change back to the old skin. Interstellarity (talk) 00:51, 19 January 2023 (UTC)
Sure, here is an example: when you type in wp:vp or john paul ii in the search box without hitting enter in the search suggestions, it shows where the page redirects to rather than the page that is in the form of a redirect. Hope I clarified. Interstellarity (talk) 01:33, 19 January 2023 (UTC)
The hiding of the left hand bar is no good. I don't use a log in and I don't want to have to set one up or have to log into Wikipedia wherever I may be browsing it in order to stop the control panel disappearing every time I click a link.
This is rapidly becoming a vexing repetitive task that is reducing the enjoyment I get from using this website and the ease of its operation. 123.200.143.83 (talk) 04:32, 19 January 2023 (UTC)
Hello Anonymous user, thanks for commenting here. Could you tell us why you need to use the left hand bar? Do you need access to any specific links? SGrabarczuk (WMF) (talk) 15:47, 19 January 2023 (UTC)
This is terrible! Bring back the old website design now!
This seems to be the place to report technical issues. I don't even have a particularly large laptop and even still 60% of my screen is useless white space. And if I use my big desktop monitor that I got specifically to see more information at once, probably would be over 80%. If I want to see less at once I narrow my browser window. When I first saw this I thought that I had somehow accidentally been routed onto the mobile website from my laptop.
I urge you all to undo this and bring back the old version. Or at least make it so people don't have to make an account (see my username) to fix this. 99% of people won't bother and will just suffer through the new unreadable interface. That is not a good thing!
Even if this won't happen, I urge you to at least make it so you don't need to make an account. Surely a simple browser cookie storing design preference for a user is reasonably straightforward to implement?
Addendum: apparently the FAQ for this new design says best practice is only 35 to 100 characters per line, and that it is recommended to be on the lower end of this range. What now?!?!?!
@IWantTheOldInterfaceBack: I completely and wholeheartedly agree. While logging in allows us to retain the legacy format, it's still pretty big for logged-out browsing. I dislike the new look as much as you, but unfortunately, if we're to be realistic, Vector 2022 is probably here to stay. Skippy2520 (talk) 04:53, 19 January 2023 (UTC)
You miss all the shots you don't take. It's been many years since I attempted to dip a toe into Wikipedia editing, and I don't remember any of the processes involved except that they were needlessly convoluted, but surely it's better to try and get whoever did this to reverse it, than to just lie down and accept it. IWantTheOldInterfaceBack (talk) 04:54, 19 January 2023 (UTC)
There you go, Have you made a survey of all the people who are not complaining? do you have any idea of the relative numbers? Have you even counted the number of people who have demanded the old skin back as a default because they just don't like the new one? You do know that you can still use the old skins if you just take the trouble to set your preferences? · · · Peter Southwood(talk): 09:47, 19 January 2023 (UTC)
Many people made accounts or dug up ancient ones to get around the changes because without an account the scale setting and other features don't work.
Forcing people to make accounts for simple accessibility features seems counterproductive or even hypocritical of the ideals of the update. Deadoon (talk) 10:07, 19 January 2023 (UTC)
Forcing people to log into accounts they haven't used for over 10 years just to be able to read the wiki without having to visit an eye-doctor afterwards is both counter-productive, extremely daft and against the principles of the foundation Peter. But you will see that when the donations stop rolling in. I for one am going to start withholding mine until you give non-users the option to switch to the old theme. 82.78.21.194 (talk) 13:34, 20 January 2023 (UTC)
Gen. Quon You are free to change back to the old skin in your account preferences. This skin has been in the works for years and has included community input opportunities along the way. The changeover was announced in advance as well. Please offer comments at the talk page of Vector 2022. 331dot (talk) 16:16, 19 January 2023 (UTC)
"You are free to change back to the old skin in your account preferences." I never said I couldn't. I'm voicing my opinion and adding to the chorus so that editors will see that there is dissatisfaction.
"This skin has been in the works for years and has included community input opportunities along the way." Aesthetics aside, this is another reason why I'm ticked: I did offer comment during the hilarious show trial "period of community input" (when 165 opposition votes were largely written off for being too concerned with "specific and narrowly-scoped [issues], rather than wholesale objections to Vector 2022", whereas the 154 "positive" and "enthusiastic" supporters were described in terms that made them sound like they formed a resounding huge majority). I feel like my input was totally written off so that this design could be rubber-stamped.
"The changeover was announced in advance as well." Why don't you tell that to the many IPs, etc. who were blind-sided and see what they have to say, hmmm? Today, I've had two coworkers who don't really edit come up to me and say, "Yo, what's up with Wikipedia?"
Gen. Quon If you have ideas on how to communicate a change in a website design to all 7 billion humans on this planet, something which is difficult for any piece of information, please offer those ideas to the Foundation. 331dot (talk) 16:43, 19 January 2023 (UTC)
Communicating a change to 7 billion humans is not feasible. A better plan would be to listen to the criticism and revert the change. The best plan would have been to listen to the warnings, of which we gave plenty, and simply not make such an unpopular change. There are many other features which we actually want crying out for developers' time. Certes (talk) 17:33, 19 January 2023 (UTC)
Certes What change do you want that will please everyone? Do you have studies and testing to support that? Because the Foundation does. 331dot (talk) 20:08, 19 January 2023 (UTC)
One glance at pages like WP:VPT and WT:Vector 2022 shows that there is no consensus for the changes. Of course, people complain more readily than they praise, but in 30 years' professional computing experience I've never seen any reaction remotely approaching the breadth of hostility generated by Vector 2022. And to answer the comment which just arrived below: yes, communication would have been helpful. Not 7 billion personally addressed letters, but some sort of warning beyond the technical pages read only by a few hundred regular editors. However, I doubt that the release could have gone ahead if this response had occurred in public and in advance. I will be very interested to read what the technical press say once they wake up to the story. Certes (talk) 20:16, 19 January 2023 (UTC)
And communicating with everyone is what people seem to be asking for; "I wasn't told! I didn't know! My two buddies in the office didn't know!" What should the Foundation have done? Asked every worldwide media outlet to run a story? You don't need to answer me, tell them. 331dot (talk) 20:12, 19 January 2023 (UTC)
The same goes for if you have ideas as to how to change a website in such a way that no person on this planet will be upset with it. 331dot (talk) 16:44, 19 January 2023 (UTC)
331dot I get your defensiveness, but please do not be condescending to me. I'm mad not simply because I dislike the changes: I'm mad because the RfC was perhaps the worst example of "consensus-making" I've seen on this site and because the rollout was done in such a sloppy, haphazard way.--Gen. Quon[Talk]17:08, 19 January 2023 (UTC)
You keep quoting the number of people on the planet (incorrectly), but is that accurate regarding the number of pageviews and active users the site has? The actual data regarding user opinion seems to have been ignored. AtomicFi (talk) 20:03, 19 January 2023 (UTC)
AtomicFi That couldn't be more wrong. I get that change is hard for people, but at least get the facts right. They tested it. They asked for input. They studied it. They can't please everyone. To expect that is unreasonable. 331dot (talk) 20:16, 19 January 2023 (UTC)
Gen. Quon It's not my intention to be condescending, I apologize. Nor am I defensive. I am frustrated at the general vitriol by people about this. All I want to see is a little understanding from people. I don't want people to like it if they don't like it, but there are constructive ways to offer suggestions. They don't need to say the developers are idiots or worse(not saying you have).
I was serious- if you have ideas as to how the change in this website could be better communicated to the population of this planet, please offer them. 331dot (talk)°
I completely agree. I don't follow technical developments so there may be a deeper rationale for the update that I'm missing, but from a purely user experience perspective this is a change for the worse. And while we can switch to the old interface in account settings, I'm sure this option will be removed at some point. Litawor (talk) 09:10, 20 January 2023 (UTC)
Hi @Litawor - thanks for your feedback. Just wanted to confirm that we have committed to maintenance and bug fixes for the legacy Vector skin into the future. User preferences on Wikipedia allow you the option to choose between all available skins. This option will not be removed in the future. OVasileva (WMF) (talk) 20:33, 20 January 2023 (UTC)
YES!
This is shining example of the "design" decision done for very dubious reasons. Mobification of desktop version for the purpose of what? - Wasting way more space on the user's monitor, being more way more white (pun intended), lowering the information density on the page.
This user prefers the Legacy version of the Vector skin to the 2022 version.
{{User Vector skin legacy}}
This is a barebones template so, for people confused about how to position it properly, remember to use {{right}} around it or some equivalent. — LlywelynII08:14, 19 January 2023 (UTC)
The call to {{Userbox}} could have a parameter such as |usercategory=Wikipedians who prefer Vector 2010. That might be a subcategory of Category:Wikipedians who use Vector (though technically one could prefer V2010 to V2022 and still use, e.g., Timeless.) If not, there's always WhatLinksHere. By the way, our preferred skin might survive longer if the template name and content refer to it as "2010" rather than "legacy". The latter carries overtones of deprecation, suggesting that Vector 2022 makes it obsolete. Certes (talk) 19:31, 19 January 2023 (UTC)
Let the readers choose new styles
Please, let the readers choose a different skin, not the designers, not the editors. Protect Classic skin, and add a please try out our new style button. At least for some trial years. Please, allow new styles to develop and get accepted naturally, step by step.
Keep adding options and comments at https://www.mediawiki.org/wiki/Talk:Reading/Web/Desktop_Improvements
Thank you, from el.wiktionary Sarri.greek (talk) 05:36, 19 January 2023 (UTC)
I was referring to the public, 331dot not to the editors. I am not an editor of any wikipedia, I am an en. and el. wiktionary editor (where we vote for the slightest changes). If I am not wrong, the past months, there was no warning to the public (I have not seen one)? It is a matter of good manners to allow them to approach new styles by their own choice, and not force them to log in.
PS, for example, I have Microsoft Edge, and I cannot see Contents. Because I study unlogged very often, I shall try to find different options, with older versions of pages found elsewhere. Thank you. Sarri.greek (talk) 21:03, 19 January 2023 (UTC)
@Sarri.greek, if the Contents is hidden (the default display says "Contents [hide]"), then look for an icon at the top by the page title. It looks little bit like a bullet list with three items. That's where the Table of Contents ends up if you hide it. If you have a narrow screen, you'll see the same icon in the upper corner. Click on it to see the Table of Contents. Whatamidoing (WMF) (talk) 22:33, 19 January 2023 (UTC)
Thank you ma'am, I am too old to keep clicking things around. I shall seek a different solution for viewing wikipedia lemmata. @User:Whatamidoing (WMF), I understand your difficult position, but the Public Relations team (if there is one), has not prepared unlogged readers in the previous year for this change (I have not seen any notice: try out a new style and tell us... It feels like an attack. I wonder if anyone from the WMF staff resigned about this... Farewell. Sarri.greek (talk) 22:53, 19 January 2023 (UTC)
Sarri.greek That you didn't see it doesn't mean it wasn't done. This was studied and tested for years with community input. Please understand it is difficult to communicate with everyone on this planet about a change to a website. 331dot (talk) 23:02, 19 January 2023 (UTC)
I did not mean for internal community, 331dot. Why not one little galant gesture: Give a button for switching to Classic Style, clearly visible on top of pages. Why is it so difficult? This discussion is endless because it is also a subjective matter of aesthetics and courtesy. Thank you. Sarri.greek (talk) 23:08, 19 January 2023 (UTC)
According to the information about the skin, there are privacy issues with allowing IPs to choose a skin; it would require storing that information somewhere. 331dot (talk) 23:18, 19 January 2023 (UTC)
A cookie on the user's device which simply records the choice of skin would not report any personal information. It's less identifying than screen size, browser version, etc. which we and every other website provider already gather. The only downside I can see is marking someone as having visited Wikipedia, which might be a problem in a few draconian jurisdictions, but they already have easier ways to log that. It would not remove the need to cache each page in each skin, but that's equally a problem if people use ?useskin= either manually or by script. Certes (talk) 10:29, 20 January 2023 (UTC)
@Certes I think this is more of issue of page caching and performance; having to dynamically change what is served on every page read based on local client storage isn't cheap. — xaosfluxTalk14:41, 20 January 2023 (UTC)
Yes, there are apparently serious WP:PERFORMANCE issues involved in customizing things for logged-out users. This is one of the reasons why large-scale A/B testing is complicated on this wiki. Theoretically, the problem could be solved, but not quickly and not cheaply. My impression (which could be wrong, of course) is that this would cost something multiple tens of millions of dollars to get started (e.g., hardware, necessary software changes) plus ongoing staff costs of at least ten million per year. Whatamidoing (WMF) (talk) 21:12, 20 January 2023 (UTC)
I think that if I went to a website that I use casually, and there were a banner telling me that they were planning to change the appearance next year, I might feel more frustrated than helped. I'm sure that the people involved in planning a major change are interested in it and think that it's very important, but why should I care, especially months in advance?
My bank changed its website last year. Thinking back on it: I would not have appreciated notice of the change very far in advance. I might have slightly appreciated a note one/a few days in advance, saying something like "Starting Monday, our website will look different". I did appreciate them posting a note when I first saw the changes. The notice they posted said something like "We have updated our website", but as far as I was concerned, the main message they needed to communicate was "No, you haven't been hacked; we changed the website".
If we assume, for the sake of round numbers, that websites get overhauled an average of every 10 years, and if we assume that I use 100 websites frequently, then I'm probably dealing with noticeable changes to 10 websites every year. I don't think I want to have 10 websites telling me about their upcoming changes all year long. I suspect that I'm fairly typical in this regard. Whatamidoing (WMF) (talk) 06:46, 22 January 2023 (UTC)
@User:Whatamidoing (WMF): With all that said, I think some pre-warning and an orientation would have been helpful for the transition (there'd be some cookies deposited on user devices, but it shouldn't be much of a privacy concern). —Tenryuu 🐲 ( 💬 • 📝 ) 07:05, 22 January 2023 (UTC)
@User:Whatamidoing (WMF) and Tenryuu Thanks:) I meant that they would be able to try it for a year = a transition period. As it is done during switches at public services, channels etc. And PS When my bank changed to an ultra modern style (All my instruction notes about what to click were useless), plus because they never bothered to warn me, I took my money and went to another bank. Now, I have saved a ClassicVector page, i emptied the bodytext, and i copypaste in there texts from wikiwand or wikipedias, and view them. Old people like me, have trouble writing down new instructions: to do this and that, go to top, right hand, and click the little blue round thing...:):) Sarri.greek (talk) 09:58, 22 January 2023 (UTC)
Logged-out users (i.e., most readers) don't have that option for technical reasons. Logged-in users have been invited to try it out for months, with big banners at the top of the page. The first set had a pink background. The last set had a light blue background.
As for how long they've been running... I asked my teammate Szymon to make a CentralNotice banner about Wikipedia:DiscussionTools in August, and that was probably inspired by a banner he was running, so they're probably at least that old. They haven't run continuously, though. In terms of efficacy, as of mid-November, more people opted-in via those banners and other on-wiki announcements than were using MonoBook, so it seemed to be effective. (I don't have any more recent numbers.) Whatamidoing (WMF) (talk) 22:06, 23 January 2023 (UTC)
New skin has large whitespace gutters on the sides
The new Vector-2022 has a large amount of whitespace gutters at the sides of the display, padding the sidebar on its left and main display area on its right (and a disconcertingly large whitespace alley between the sidebar and main area). Additionally, there seems to be a whitespace sidebar to the right of the main area before the whitespace gutter on the right, that is completely unused except for the top menu area, that extends to the right beyond the main area? This wastes a lot of screenspace, as compared with old Vector or Monobook. I would say this is a bad bug in the new skin. Can someone add a ticket for this issue to the bugtracker?
-- 64.229.90.199 (talk) 06:11, 19 January 2023 (UTC)
I know there's the gadget and scripts to do this and I know it's not a problem with Vector 2022 specifically, but the fact that MediaWiki still doesn't have a native dark mode option is just mind-boggling. ♠JCW555(talk)♠ 08:56, 19 January 2023 (UTC)
Hi @JCW555. I'm not sure if this has been documented somewhere, but from what I know, a technical side-effect of the new skin is that it will be easier (somewhere between "less impossible" and "easy" :D) to build the dark mode now. SGrabarczuk (WMF) (talk) 15:54, 19 January 2023 (UTC)
The new format is godawful
I mean, obviously, I'm in the minority but to the extent anyone on this end of the project cares about functionality or feedback,
1) There is nothing at all improved in functionality hiding the alternative languages behind a slowly loading partial submenu on the top right instead of quickly loading full text list in the otherwise useless left gutter. The only possible improvement is for people who don't plan to ever use other languages at all.
2) Users who don't want to use interlanguage links should be the ones opting out of the side format, not the other way around.
3) When they opt out, I'm sure they'd prefer a less obnoxious format on the top right. The large cartoonish format you're using as a default has been around a while. That doesn't make it appropriate: people who want quick access to other languages hate it. People who don't want access to other languages hate it. It's too unhelpful for the first group and too large and obnoxious for the second.
4) I shouldn't have to completely nix all other changes to fix that ridiculous mistake. Currently, I need to use a special (uglier) skin in Commons so the code will load that correctly provides the zoom feature for most image commenting. I shouldn't need one here on the main project at all. I certainly don't want to have to switch between them to make the separate projects work. There should be a way to disable this awful aspect of the formatting without having to just default to the full older system. I'm sure there were some nonharmful changes or even improvements in the latest version of the skin.
5) That disabling should be FAR easier to find. It should be available instantly and prominently in the new ugly dropdown menu itself or in its settings. It's currently available in neither and I was forced to hunt here and then scroll down this textwall to find how to fix this eyesore. I'm sure most visitors to Wikipedia don't know this place even exists and are just lost and (for the 12 of us not on mobile) as annoyed as I am.
6) If this is only about mobile functionality and if it is more mobile friendly, fine but have it ONLY activate for m... versions of the pages and leave those of us who still own laptops alone.
Thanks for your attempted work and good luck fixing the mess you've made of things or at least making it easier for the rest of us to get around it. — LlywelynII07:40, 19 January 2023 (UTC)
@Llywelyn: mobiles still use the old mobile version, which is frankly a lot worse than Vector 2022, with its sections that have to be opened (but don't close again) and weird star that looks like the FA icon but is actually a favourites toggle. Vector 2022 doesn't work well on desktop, although I'm sticking with it for a while to see if I can get used to it... but it might have been leveraged to work well on mobile, except it seemingly wasn't Ah well. — Amakuru (talk) 09:37, 19 January 2023 (UTC)
@331dot: Yes, and the majority opposed it then! So why was this all implemented? Why consult with editors if their opinion isn't even weighed? ~ HAL33316:07, 19 January 2023 (UTC)
HAL333 Nothing on Wikipedia is done by a majority vote. How do you know that opinions were not weighed? You aren't in the minds of the people who worked on this to know what they did and did not consider. That they didn't do 100% of what you or others might want doesn't mean it wasn't considered. There are 7 billion humans on this planet who can potentially access Wikipedia, all with differing views. It's tough to accomodate everyone. You are free to continue using the prior skin. Can you at least understand that no matter what they did or did not do, some group of people was going to be unhappy or upset. Seeing the vitriol directed at people by others is disturbing. 331dot (talk) 16:11, 19 January 2023 (UTC)
It seems a select group of people decided that they love their new UI baby they worked on and are unwilling to accept outside opinion or criticism. Please listen to the users. A massive, poorly implemented change to the UI after nigh-on 20 years of similarity in layout seems bizarre. Your defensive tone illustrates the struggle you're all having against actually listening to the users quite well. In this case "Some group of people" seems to be a majority of your userbase.
@331dot:Nothing on Wikipedia is done by a majority vote Yeah, it's done by consensus. And there was no consensus for vector 2022. The onus was on them and they failed. So they unilaterally force their poorly designed UI on 7 billion people. That's what's disturbing here. ~ HAL33318:06, 19 January 2023 (UTC)
I mean, it's not like the WMF has a long history of producing bright and shiny things that don't work properly, whilst ignoring their communities' requests for things that would actually make their workflow easier, but don't get done because they're boring and not bright and shiny. Black Kite (talk)18:03, 19 January 2023 (UTC)
The hostility displayed is due to what's seen as (and what I agree to be) a pointless change that disrupts work. If a new RFC was drafted and was widely visible to share thoughts with, I can foresee less personal attacks being conducted. Lucksash (talk) 20:45, 19 January 2023 (UTC)
All of this. I almost exclusively use Wikipedia on desktop, and this does absolutely nothing positive for desktop viewing. It feels like perhaps the changes are almost exclusively related to the mobile version at the expense of the desktop version, which is not acceptable. Still, I can't even understand why you'd f%ck around with the desktop version of the site, in that case. Criticalthinker (talk) 10:39, 19 January 2023 (UTC)
@Muboshgu: It's not simply a matter of fearing change, it is simply less useful than Vector 2010. There is less text displayed at any given moment, more blank space, more links have been hidden in menus that are collapsed by default (so I have to click more to do things like navigate to my contributions or talk page). I'll grant that from a reader's perspective, it might be an improvement (although it really bothers me, and probably most readers, that the sidebar is wider and therefore the body text is much further from centered). But it definitely isn't an improvement for editors. I could get used to it if I must, but why would I? —Compassionate727(T·C)17:55, 19 January 2023 (UTC)
People have been pointing out various things that are objectively bad. The kinds of thing that happen when you design inside of an ivory tower. They should not be insulted by saying that their main motivation is "fearing change". North8000 (talk) 18:07, 19 January 2023 (UTC)
It was one that wasn't though out at all and didn't take into account anything the community complained about. Tvx1 20:42, 20 January 2023 (UTC)
Change being inevitable is not an argument for any particular change to happen. At best it's a consolation of someone who was powerless to stop it and at worst it is a way to dismiss another person's opinions as stuck in the past. The idea that something like this would just happen obfuscates that it happened because certain people had the ability to impose it without asking. Vector2022IsAbsolutelyTerrible (talk) 18:59, 19 January 2023 (UTC)
You really need to stop dismissing and minimizing the complaints of almost the entire community. Sure no one expects this website to stay the same forever. That doesn't mean however that changes should be made for the sake of it and that any change is good per definition. Many people complained just how poorly designed Vector 2022 actually is. This new skin isn't a step forward in any possible way. But most importantly, there was nothing whatsoever that suggested a change was warranted in any way. At no point did the community give any indication whatsoever that original vector had become unusable to the point of a new skin being required. This is nothing but a change for the sake of it by a bunch of rogue developers who unilaterally imposed their personal desire on the wikipedia community and still refuse to show any intention of actually minding of their community's desires in any way. People aren't complaining just because something changed, but because this new imposed skin is an abysmally poorly design. It's high time you finally accept that. Tvx1 20:41, 20 January 2023 (UTC)
I concur that this is a significant step back in desktop viewing. I spent about an hour figuring out how I ended up in mobile view before discovering that this wasn't mobile view. Goose2000 (talk) 19:42, 20 January 2023 (UTC)
Reminder of Vector 2022 team office hours today
Just putting in a reminder to the Vector team's office hours this evening. The specific discord in question is the one accessed through WP:DISCORD. [Note: Am a mod of that Discord, but have no organisational role in the call]. Nosebagbear (talk) 15:42, 19 January 2023 (UTC)
@Xaosflux - the links to the Discord are occasionally updated, and I didn't want to give a link that for anyone who is not a Discord member might end up broken and confusing. The wikipedia discord page will have the most recent public link, so felt like the best place to point people to.
Hi, I've just created User:Dr. Blofeld/vector-2022.js to accompany the new skin but for some reason the more panel is displaying GB (google books link) and "Translate" twice which I obviously don't want. I also want to remove the GB ref link which I can't even see in the vector 2022 coding. Is one of my past coding pages interfering with this or something? How can I fix it? ♦ Dr. Blofeld11:08, 19 January 2023 (UTC)
The new Vector skin currently loads vector-2022.js and vector.js. There is a phabricator bug about it that is approaching its first birthday, T301212. I don't understand why it was not resolved before the public rollout. – Jonesey95 (talk) 14:49, 19 January 2023 (UTC)
Position of language links button
On regular pages with the new appearance such as these few currently linked from the Main Page
the button concealing the language links is in the top right corner of the page, as is correct according to the description.
However, for the Main Page, this button is in the bottom right corner. This is ... confusing.
It's the same whether logged in and not logged in, except, of course, for the extra language links button on your personal menu following you down the page when you're logged in. Philh-591 (talk) 16:17, 19 January 2023 (UTC)
@Philh-591 This is by choice (And is the same on all languages I know of). I would assume that it is placed at the bottom on the main page is so that it appears after the "Wikipedia languages" section, and the list of 1mil+, 250k+, 50k+ article lists. Terasail[✉️]16:53, 19 January 2023 (UTC)
Not sure this is the best place to propose actual new ideas/improvement (as opposed to bugs and propagated breakage) for V2022, so feel free to tell me a better place for this sort of thing. But anyway...
The main menu is a modal/collapsible part of the sidebar, controlled by an icon in the header of each page and whose expand/collapse status persists across all pages. I generally don't care about it and instead prefer to see the table-of-contents, so I keep it collapsed. However, there are times I do want something from it, like a quick jump to wikidata/commons or one of the Special: tools. So first I have to scroll to the top, then expand the menu, then select what I want. And then collapse it again so reset the default behavior I want. Having the main-menu link even available from the condensed sticky header would save a lot of scrolling. And having it be a transient popup menu rather than a permanent toggle would save me time and annoyance when I want to generally retain its collapsed state. DMacks (talk) 17:53, 19 January 2023 (UTC)
The best places for feature suggestions are probably Wikipedia talk:Vector 2022 (on en wiki) or mw:Talk:Reading/Web/Desktop Improvements (project page on mediawiki) however I think that the web team are currently following this page aswell. @DMacks Most of the features you list here Page tools, project links (Com/WD) will be moving into a "Page tools menu" which will appear on the right side of the screen. It has been delayed and should be coming soon. So you would have to access the left side menu less. See MW:Page Tools / phab:T317898 / phab:T302073. Terasail[✉️]19:02, 19 January 2023 (UTC)
Thanks for your suggestions @DMacks! You have some good ideas here that I'll bring to the team to discuss (specifically thinking about potentially adding some more commonly used tools in the sticky header). One change we're making next week that aligns with some of your suggestions here is the introduction of the page tools menu which will move a lot of those tools to the left-hand side of the page. This will let you keep the main menu collapsed while having the ToC and page-specific tools open. OVasileva (WMF) (talk) 21:01, 20 January 2023 (UTC)
Vector 2022 text uses the exact same color as old Vector, #202122.
However, in Vector 2022 the text does not use subpixel anti-aliasing (at least on my device), which can make it look less crisp / more blurry. I don't think this is an intentional change, it's just that many CSS properties disable it as a side-effect, and all the developers use high-resolution screens (I'm guilty as well) where this problem is not visible. I filed T327460 about this. Matma Rextalk01:43, 20 January 2023 (UTC)
There's a lot of good stuff in this new skin, but regardless of what the research may show for users in *general*, for *this* user, the fixed width makes Wikipedia unpleasant to use. If I could use the width toggle to persistently opt out of fixed width, I'd be reasonably happy. But the fact that 1) the toggle exists and 2) it doesn't persist makes it, legitimately, an insult. It makes me frustrated every time I click a link or reload a page, because my experience is degraded every single time. I don't know how to interpret having a toggle *and* making it utterly useless, other than as a "f*** you" to users like me. It would be better to not have the toggle at all--at least that way I would have to either adapt, or decide to stop spending as much time on wikipedia, without the temptation of a nice interface being "so close yet so far." Of course, much better would be to simply *make the damn setting persistent*!
I realize that I could have this be persistent by making an account and logging in, but I have no interest in doing so, and forcing a change like this on users to incentivize them to log in is the definition of a dark pattern. — Preceding unsigned comment added by 2620:10D:C090:400:0:0:5:B5ED (talk) 20:26, 19 January 2023 (UTC)
I wouldn't use that a strong language to describe it, but I share the feeling. The button (which I only found after searching Wikipedia news and being directed to the Wikipedia:Vector 2022 from the community portal) is just useless if it doesn't persist the setting. I like browsing around Wikipedia a lot, but this is simply jarring the user experience.
@HAL333: In my opinion the launch of the RfC was a bit rushed. It would have been better to plan carefully how to advertise it to all users, both registered and unregistered. Also, while RfCs are not polls, I think that it would have been better if the comments were split into two sections, support and oppose, and numbered as it was in the previous RfC. Æo (talk) 14:04, 20 January 2023 (UTC)
Logo/Wordmark
Is there an easy way with Vector (2022) to keep the logo/wordmark from being overwritten with the title of the article? I am using BrandonXLF's javascripts with Vector (2010) to keep the side/top bars floating. I usually have multiple WikiProjects open at the same time. Seeing the site logo is an important reminder of where I am. Thanks! — WILDSTARTALK22:50, 19 January 2023 (UTC)
I assume you mean within the "sticky header" and in that case, not unless you (or someone) creates custom javascript to insert the wikipedia logo into the header. Terasail[✉️]00:54, 20 January 2023 (UTC)
In that screen shot, if you measure the number of pixels from the center of the bell icon to the center of the inbox, then from the center of the inbox to the center of the watchlist icon, then from the center of the watchlist icon to the center of the torso, you should see that the icons are equidistant from one another. Have you considered either reading your notifications or marking them as read? If you do not want to receive notifications, you can disable them at Special:Preferences#mw-prefsection-echo. – Jonesey95 (talk) 01:16, 20 January 2023 (UTC)
Vector 2022 deployment - part 3
Vector 2022 Post-Deployment Update from WMF team
Hi everyone,
Thank you all for your continued feedback on this project over the past four years, throughout long discussions in summer 2022, then the RfC and consensus building process, and over the past few days overall.
As some of you have mentioned, large changes and new interfaces can often generate negative reactions. We've seen that this is the norm when a major website switches to a new interface. Immediate pushback to redesigns can often be strong, but changes in the following days and weeks. We at the Wikimedia Foundation are monitoring the reception of the skin. We know there is negative feedback coming in, and we are looking at it as one part of forming a full picture of how users are feeling about the rollout. In this message, we want to tell you how we're thinking about the rollout now and going forward.
Our research and data leading up to this deployment shows that the changes make it easier to read Wikipedia and to get started with editing. As one example, we found that the sticky Table of Contents made editors 53% more likely and readers 46% more likely to navigate across multiple sections of a page, which saves time and encourages exploration. We developed these learnings as we deployed the skin to over 300 other language Wikipedias, where it is currently the default. The RfC process here on English Wikipedia, one of the largest in recent years, and the changes we made to the interface as a result of community thoughts in the RfC, increased our confidence that we were proceeding in the best interest and with the support of the English Wikipedia community. Many of you have spent countless hours participating in the conversations to help make the skin better – thank you!
We're sorry to hear that some of you were surprised by the change. We used many channels to spread the word and invite people to weigh in, while also trying not to annoy people with too much communication: we used Central Notice banners to all users (displayed for weeks between May 2022 and January 2023), watchlist notices, TechNews, and the English Wikipedia Village pump. In addition to on-wiki communications, we have also hosted bi-monthly office hours for community members on Zoom as well as on Discord, and reached out through Wikimedia groups on Telegram, Facebook, and Discord. Before that, there were Village Pump discussions that started last July, and the first notes on the change were part of the Signpost issues in spring 2022. Are there other places and forms of communication you think would have been helpful in this case?
Next steps
The main way we can determine the success of the new skin is with metrics. We are also watching the negative reactions on the wiki and in other parts of the internet, and it is tough to see, but we also understand that this is not the full picture. Millions of people are experiencing the new changes now but, of course, are not posting any public feedback, and it's important for us to get a sense of everyone's experience as we decide what, if any, changes to make going forward. As a clear next step, we plan on continuing to monitor key metrics to ensure the redesign is meeting its goals. If they are not, we will take action. Specifically, we are looking for:
No measurable decreases in pageviews, edit rates, or account creation due to these changes
An opt-out rate for active editors which is less than 40%
A 10% increase to search across the site, promoting exploration of Wikipedia's content
An increase to in-page navigation due to the new table of contents
A decrease in scrolling to the top of the page with the purpose of using specific tools
We will be tracking these metrics weekly, and writing reports on them monthly. We expect the first full report to be available in one month, but will probably update sooner than that with any key insights.
Besides the metrics, the incoming feedback we're seeing now is definitely important, and we're paying close attention to try to identify improvements we can make next. We will reach out early next week with a list for you to review of quick changes we would like to make to the skin. Changes that are already in progress include:
A new menu with important tools in the currently-empty right column.
Lowering the width at which the toggle to expand the width appears. This will allow more people to see the toggle, even on smaller monitors and devices
We have also heard a request from many of you for persistence of the width toggle for logged-out users. As we've mentioned before, this is a significant technical challenge from our side, but we have some ideas on how to make this happen. We will update you on our progress next week.
We also commit to continuing work on the desktop experience after this change is made, and into the future. This will include new feature development on the Vector 2022 skin and maintenance of the legacy Vector skin.
Please continue bringing us your thoughts and ideas on making the skin better. You can report the issues you encountered and your suggestions for improvements at the project talk page, and we will continue to compile, analyze, and plan using it.
We also ask you to keep testing the new skin. We recommend that you try it out for at least a few days and give us your feedback. That said, if you prefer the old experience, you can switch back to legacy Vector or to any of our other skins at any time.
So, wait a minute...the WMF is citing the statistic of * An opt-out rate for active editors which is less than 40% as being a POSITIVE?!? What you're actually saying is that (slightly less than)or(almost) 2 out of every 5 active editors or 4 out of every 10 active editors are rejecting Vector 2022. Shearonink (talk) 04:36, 21 January 2023 (UTC)
Sometimes statistics mean the opposite of what we think they mean. "No measurable decreases in pageviews, edit rates, or account creation due to these changes". Plenty of us have created accounts in the past day merely to be able to change the design back to the old one. Of course those will add to the account creation rate! Mark Twain once said "there are lies, damned lies, and statistics". Statistics can be massaged to create almost any narrative. For example, are you tracking the amount of scrolling? It's very possible that the reason for increased TOC clicks is because there's now so much damned scrolling required to move down the page so people are just clicking on sections instead. This is not an improvement! (edit: and it just took me 4 edits to figure out how to insert and properly size an image, itself contributing to the latest edit counts :p) I suggest, instead of these surveys, popping up a feedback request form on, let's say, 1 out of 100 pageviews whether logged in or not. This can be much more useful than statistics that can be used as arguments for anything. IWantTheOldInterfaceBack (talk) 01:43, 20 January 2023 (UTC)
Hey @IWantTheOldInterfaceBack - thanks for your question. We actually tracked the amount of scrolling as part of our A/B test on the sticky header. We found that adding the sticky header decreases scrolling to the top of the page in order to use any of the tools there by 15%. I like your idea about the survey - we’re also planning on doing a similar survey a few weeks after the deployment, once people have the opportunity to get used to the new skin. OVasileva (WMF) (talk) 02:13, 20 January 2023 (UTC)
Can you please actually start listening to what your community says about the importance of these statistics? Tvx1 02:17, 20 January 2023 (UTC)
This is not the sort of scrolling I am talking about. On a large monitor such as mine, about half the width is now taken up by whitespace. This means twice as much scrolling is required to traverse the page. Say I am on section A and it takes up my whole screen. I may now just click on the link to section B instead of scrolling all the way down to bring its start from the bottom of my screen to the top. This does not fix the core problem: that information density is half what it was before, and so more scrolling and/or clicking is required. IWantTheOldInterfaceBack (talk) 02:17, 20 January 2023 (UTC)
@IWantTheOldInterfaceBack Interesting that you are talking about scrolling speed. If you want to go to a specific section you can use the ToC. Which is great that it is more accessible.
For me the point of reading is to scroll slowly and I (and most people) read faster when I don't have to move my head left-right, left-right, left-right... The text SHOULD NOT take all of the screen it should be visible all at once (full width), without moving your head. Long text makes things hard to read.
@Nux: Some of us bought wide monitors for a good reason - we want to see more at once. If we want shorter lines, there's an easy solution - de-maximise the window and drag the left or right border to get the desired line length. The line length that suits me is not necessarily the same as the WMF's preferred line length, so don't assume that it is. --Redrose64 🌹 (talk) 18:54, 23 January 2023 (UTC)
@Redrose64 I actually have 3 monitors, so ;)... I wasn't convinced at first, but found that this is easier to read. And if you are one of those special roses of the world that prefer very long lines then you can always switch with few clicks. The option set by default is "Enable limited width mode". Studies show most of the people prefer limited width. Links for studies are above.
Take any book to your hand and note how much paper is "wasted" for margins. Do you really think publishers wouldn't want to literally cut costs by reducing margins?? Nux (talk) 19:08, 23 January 2023 (UTC)
@Nux:, of course you are right! But, there are many reasons and ways to view a page: I have 3 ways. Huge lemmata (who readds them..?) : I just 'fly' over them, check images, style, some words, headgings (need wide and short). Read carefully selected paragraphs: Your style! narrow, plus zoom 150%. And a medium style. Also, depends on the kind of page: huge appendices, lists etc. Wikipedia and all wikimedia projects became famous for the simplest possible design intervention. Isn't this true? Thank you Sarri.greek (talk) 19:21, 23 January 2023 (UTC)
That is an invalid comparison. Books are produced in a variety of widths, and the line length is not a consequence of "we think that our readers cannot read lines longer than X" but of how much space is available once the margins have been deducted. Margins exist for at least two reasons: one is for the bookbinder, who needs space on one side for the actual binding (you don't want text right into the fold where it cannot be read) and on the other three sides for trimming (you don't want text to be cut off by a misplaced guillotine); a second is wear and tear - in use, the edges of pages do become damaged, and the existence of margins on three sides guards against damage to the actual text. --Redrose64 🌹 (talk) 23:06, 23 January 2023 (UTC)
@Redrose64 sorry, but what you said about margins is just not true. I mean yes you need to connect (glue, saw) and cut the paper, but final margins far exceeds those needs. In a good book there is at least 1-1.5 cm extra on each side and often more. With most extreme margins and white-space in poetry (mostly for aesthetic reasons, but still).
But let me quote studies: "McMullin et al. (2002) measured the effects of surrounding information and line length on text comprehension. They found that participants got distracted by the additional column or paragraph of information and performed slightly less well on comprehension questions than when information was surrounded by white space. They favored the use of white spaces over multiple columns, as white spaces helped prevent the influence of distracting and unimportant information and decreased the need to scan across the entire screen, which could be tiring for the viewer's eye span".
Not sure if going all-white was a good idea on WMF side. Studies do say that too much white areas is bad too. "Glare had also been reported as a problem in a comparison of different CRT displays by Gould et al. (1987). As a follow up experiment of the same study Dyson and Kipping (1998) had hypothesized that by reducing the glare from the screen using a gray background, shorter lines were read at similar rates to longer lines." Nux (talk) 17:13, 25 January 2023 (UTC)
We recommend that you try it out for at least a few days and give us your feedback. That said, if you prefer the old experience, you can switch back to legacy Vector or to any of our other skins at any time. except you've told us that our feedback doesn't matter because it's not any kind of key metric you are looking at. If we want to give feedback you'll actually observed we need to do something on the key metrics. I want to like Vector 2022 and think it's entirely possible that it will be better for our readers and new editors won't know what they're missing so it will work for them and in that sense making Vector 2022 the default will be the right decision. But it seems clear from this post that all our feedback does is make things tough for you to see. Best, Barkeep49 (talk) 01:54, 20 January 2023 (UTC)
Hi @Barkeep49 -- thanks for reading our post. I just want to underscore that the feedback definitely does matter to us. It's a key input to our work (we just didn't list it as a "metric", because it's different than a pure number that we pull from our database). As an example, the engineers are already working on a quick change to the fixed-width toggle that we heard about in many of the comments that got posted in the last two days. I'm sure you've already listed and posted it in other places, but would you mind linking me to (or re-typing) your own thoughts about the skin? I would also be interested in your thoughts on how we can best take in the specific feedback as well as get a sense of the experience of the many readers who we won't be hearing from directly. MMiller (WMF) (talk) 02:13, 20 January 2023 (UTC)
Thanks for engaging @Marhsall. I'll start by saying I have a great deal of respect for you and have enjoyed the places we've worked together in the past. My thoughts about the skin are:
I believe the research and stats from other wikis that say it will improve your key metrics for unregistered users
I had committed to myself I would try it for two weeks beacuse I want to work in the environment that our readers do. And then I found tool after tool that I rely on every day wasn't going to work and even the ones that I would have thought stood some chance of getting fixed - gadgets - likely won't. So I switched back after less than a day. I've left it on for a private wiki I use because I really want to like it. But I absolutely found it unworkable for now.
I find a UX where the same icon has different behaviors depending on where you scroll utterly bewildering.
Thank you for the specifics, @Barkeep49. I hope to continue to merit your respect! You had mentioned the question of how we use feedback as part of decision-making. One thing the Web team is doing now is scanning through all the comments here on VPT and on the RfC to get a more quantitative sense of how many people are talking about the different issues. Fixed-width is obviously the big one, but there are several others that are coming up a lot.
MMiller (WMF): To give one example, the torso (User menu) icon has different behavior depending on whether it is in the top header or the sticky header. I reported this as T325124, but it was closed as "works as designed". I find this UX design decision baffling. – Jonesey95 (talk) 02:27, 24 January 2023 (UTC)
Well it appears you've elicited feedback. I've had to sign up with an account and hand you my personal information to get a usable desktop site again.
You aren't required to provide an email address to create an account yourself(though you would be unable to recover your password without one). If you requested an account, yes, that requires an email address, it is possible to create a throwaway email address. Browsers can be set to erase cookies after every use. 331dot (talk) 10:50, 21 January 2023 (UTC)
Really?? The “our research” nonsense again??? All of that was already debunked in the RFC, but you just keep sticking your heads in the ground? When will you actually start listening to your community?? Tvx1 02:00, 20 January 2023 (UTC)
This is a classic example of misleading statistics.
The fact that people are still participating in reading/editing Wikipedia is not an endorsement of these changes and should not be interpreted as such.
Opt-out rate in isolation means nothing; how many users would opt-in to Vector 2022? That's the number you'd need to compare it to in order to gauge support. If you bury the "I don't want to use this" button, then you can't point to the fact that not many users are pressing the button as proof of success.
Searching more means nothing; it could just as easily be that users are having more trouble finding things. Without additional information, we don't know. You also just said that there's "No measurable decreases in pageviews", implying there hasn't been a significant increase either.
I also haven't seen any case made that these are even significantly desirable statistics. I don't really care how many times readers are searching or clicking on navigation tools, I care about whether the information on a given topic is presented adequately. This lack of transparency and this "we know best" attitude is much more of a bother than most of the technical changes, especially when presented to a community where the bedrock is user input and consensus. The changes aren't even that bad, it just needs some more work. As I've said, this was very predictable and very preventable. Village Pump and watchlists are only used by hardcore editors, which makes up a very small proportion of the users affected. Also, fix the reduced width issue. I want to see more on my screen, not less. Thebiguglyalien (talk) 02:02, 20 January 2023 (UTC)
If you bury the "I don't want to use this" button, then you can't point to the fact that not many users are pressing the button as proof of success.This 100%. WMF, if you want to stand behind opt-out rate as an actually useful measure of this being a good change, then put a button at the top of every page which clearly says "would you like to switch back to the old skin? Click here!" You do it for Jimmy's funding pleas, so it's clearly not a technical limitation. If, after you have that button clearly available, people still prefer the new skin, then I'll believe it's actually a good change for our users. — Shibbolethink(♔♕)17:50, 20 January 2023 (UTC)
Exactly! I tried to switch back to the old design almost immediately, but I had to use Google and click through a ton of menus to actually find the option to opt-out. That taints any stats about the supposed number of people who don't opt out. HappyWith (talk) 22:52, 20 January 2023 (UTC)
It's interesting that despite all the incessant talk from the design team about usability, accessibility, welcoming design, etc, a prominent feature of the redesign is the use of mystery meat navigation. Avoiding mystery meat navigation is one of the most well-established and longest standing lessons of web design usability. I suspect that there is a combination of unacknowledged desire to keep up with the latest "trendy" design (in this case "flat" design, and the mystery meat icons provide an opportunity to showcase such design), combined with an instance of Goodhart's Law in which the statistic becomes the end in itself, forgetting that the measures exist for man, not man for the measures.
Anyway, I have a few comments on particular items that have been listed as posing technical problems.
"We have also heard a request from many of you for persistence of the width toggle for logged-out users. As we've mentioned before, this is a significant technical challenge from our side..." How is this a challenge? All it should take is a simple cookie and a few lines of javascript. Toggling unlimited width creates a cookie. JS on each page during loading checks for the existence of such a cookie. If it exists, set body to fill the screen. If it doesn't exist, limit width to however many pixels. This can surely be done in a single-digit number of lines of code. This should not require any sort of caching at all.
I have seen arguments that allowing non-logged-in users to select a preference for the old format is non-feasible because it would increase caching by 50%. This need not be the case. The article text itself should be the same independent of the design choice for a given pageload. Thus the article text can be cached in common for all designs. The only thing that would need to be cached separately is the non-article content and the CSS. And since, aside from the TOC side bar, this is the same for any given page, you can just cache all the non-TOC non-article content once in one common place for all pages. The only new stuff that would have to be cached is the new TOC sidebars for each page and that should only increase cache load on the order of 2 or 3 percent, not 50 percent. Conceivably, even the need to cache that 2-3% could be eliminated by including a bit of javascript in the redesign code which would, client-side, parse the page's heading structure to build a TOC from scratch. IWantTheOldInterfaceBack (talk) 02:31, 20 January 2023 (UTC)
Yes, all of this! ^
This is clearly just going to be rammed down our throats... There is no "feedback" that will be acted on, this is all a PR show to distract us long enough that they can just claim it is now a fate accompli situation, 82.9.90.69 (talk) 10:45, 20 January 2023 (UTC)
The way those acceptable metric categories are worded seem quite suspicious. Increased user registration to fix problems is a good thing(dark pattern design philosophy?), a highly divisive design is still acceptable(40% is a VERY high number and easy to reach through apathy alone), having to actively search for solutions to it would be an affirmation, people should use the table of contents(?), and people not scrolling to the top. Seems those metrics were intentionally chosen to be easy to obtain or easily gamed. Deadoon (talk) 03:55, 20 January 2023 (UTC)
Here the thoughts from a web developer experienced with usability and accesibility, including for blind, impaired and disabled people. I'm displeased with the change, as a regular enWiki reader and IP (non-logged) editor, but I'll try to keep calm in order to be positively critical.
First, today English Wikipedia is not a mere website: it is an institution. Worlwide. Many of us fell this change to be surprising: readers and IP editors never heard of your intentions. It was as a "Trumpist-alike assault to Congress", sorry to say. Even if all changes were good and fully debugged, which not.
Second, have in mind: every improvement implies a change, but not every change implies an improvement. I'm not against changes when they carry objetive improvements and enhancements, but this is not the case, and you know.
Third, many of you on WMF are sad with the strong words you received from many. Well, in light how you managed all the case, Didn't you expect it, really? By things like these, any outsider feel on you as in your ivory tower. Yes, it's your Wikipedia, so you do whatever you want. This way are you viewed. Studies, RFC, consensus... void words to us, if you do things this way.
This said, the main strong point of the previous UI is not aestetics: it is its solid and consistent layout. Every page in Wikipedia has the same distribution of heading, left panel and content, no matter what content: main page, articles, view history, talk, editing, templates... everything. So it is very comfortable to use. "Show preview" while editing shows exactly what you get when changes are saved. Simple, comfortable and efficent.
Now you've broken that experience: main page items are distributed centered by default (leading to the wasted space issue, in a page in which the maximum line length has no sense, it's not an article), but if you click the "three bars" button, all moves when the left side bar appears. Collapse the menu, and all moves again to be re-centered. Not a good impression, raw cooked-alike. One wonder if you really use your own product.
Open an article with TOC and you see one thing. Open an article without TOC (example: Mystery meat navigation), and you see other thing. Not consistent layout. Smells like poor tested.
About the TOC in itself, I'm not opposed it to be permanently at hand, but it should have light grey background to clear visual differentiation, and being now a tree, it has lost its numbering scheme, being hard to know at a glance where you are in the article. It tracking you all time where are you reading is an annoying flickering. Have you ever read about peripheral vision? And bad layout also, in my screen TOC does not occupy the full height, more white at left-bottom. Did you tested it in a wide range of screen sizes and resolution, really? Hard to believe.
Edit a page section, and there is no space at left (What happened with the maximum line length rule?) Write something, include some images and/or tables, etc. and "Show preview": you see one thing. Save changes and... you see a different thing. Inconsistent again, and therefore not good.
The search bar now tries to "read your mind" offering you the guessed suggestions. Before, it was a simple, quick and efficient search by title, with an "Advanced search" option. Now the search is slower, and offers less choices when the intended page starts with very common words, like "national" or "electron", lets say. As far as I tried, no "Advanced search" option (or not obvious if it has, so not a good design anyway).
The toggle button issue it's been addressing now, I know, but, Why a toggle button in first instance? It sounds as if it was a "quick-and-bugged" patch to give some kind of compromised solution to the "wasted space" issue criticism, only in order to go ahead with the maximum line width paradigm yes-or-yes. Not in your ivory tower, really, really? Plus, if you are unable to correcly put a single button on screen, May we trust in your technical skills? Please, be serious.
And incidentally, if you solved this issue with a toggle, Why not more toggles to switch between, lets say, the search bar behaviour, or any others? This would lead to make a toggle-drived Wikipedia experience, which not seems to be a good idea, I think.
And finally, the wasted space issue. The maximum line width is very objetable, even as an option, much more as the default. Personal preferences is no a matter of discussion: every one has their favourite way to enjoy the Wikipedia, and undoubtly there are people who likes more the maximum line length rule for articles but, How many? For decades I've never heard about people complain about this. People have searched, read, studied and learned with Wikipedia for years in the past, and I hope in the years to come.
I dislike that empty, blank, void space, maybe in my monitor there are more white than text, but for sure many people have 16:9 high resolution screens out there, so complains must to come. If you want to implement the maximum line width, at least limit it to the article frame, not all the page. And if you want to make it more book-alike, at least draw some borders and put a grey background, like a document in MS Word, lets say. Now, all it is a white bed sheet. Many people has visual problems with light backgrounds. Screens emits light, by now they are not ink-on-paper (reflective). RGB white light emits more high-frequency (blue) than other warm hues, and it is known it hurts the eyes. Why do you think there are people asking you a dark theme?
Yes, I'm critic. Yes, I point you issues, technical and procedural. Yes, I want a better Wikipedia. Yes, now it is no better Wikipedia. And, by now, I won't donate, sorry.
Your statistic metrics for "success" are meaningless and seem rigged to guarantee a positive result. There is virtually no scenario in where those metrics will not return a positive result given that Wikipedia has no competition. Where else are people to go? Do you really think people will just stop using Wikipedia even if they hate these changes?
This is classic lying with statistics. It doesn't at all mean that people are happy with the changes.
The best way to measure users' reactions is to ask them. Post a front page poll as a header on all pages served for the next week asking if users approve of the changes or don't approve of the changes. Obviously some effort will have to be made to prevent ballot stuffing, but it otherwise seems the best way to measure user opinion on the matter. 2600:1700:1471:2550:4102:7C99:2804:8FC3 (talk) 20:30, 20 January 2023 (UTC)
In the nicest way possible, I don't think it matters what your research and data show. Wikipedia is a public service, and as such, significant changes like this one (which isn't on the same scale as page edits or changes to editing rules and policy) really should be put to public consideration. The public here is not just editors who might be slightly inconvenienced by a couple of extra clicks, or developers who think they know best, but rather ordinary users, most of whom don't use or have accounts, and many of whom will not get accounts for one reason or another. It is wrong to say to all these people "Oh well if you don't like it then make an account and change it back", because people shouldn't need an account to use this service the same way they have been using it for 12 years when there was never a mandate to change it in the first place. I am personally not a fan of the changes, but I will accept it and stop complaining if there was an approval survey asking users at large which layout they prefer. There are many conflicting opinions within the small group of people who know their way around the village pump and even know what MediaWiki is, but I highly doubt that they are representative of the opinions of the general public, who are really the ones who should be catered for here. MajorArchitect (talk) 00:50, 21 January 2023 (UTC)
Collapsing quite a long post
problem identified - Too much information density
most complaints are about too little information density
opt-out vs opt-in is a strategy to force people into things they dont want to use. as many already know.
if you really care about what people really wanted, you would had made a landing page that that gives visitor just 2 options, use vector"2010" design (current) or use vector"2022" design (new)
we all know what the results of that would have been.
You know what the metrics will show, right?
most people DIDNT NEED a change, most people didnt want the change, most people will go back after seeing what the new one look like, if they even care to look at the new one at all.
The option to "opt-out" to vector2022 default to vector "2010", will have more than 70% (as conservative number) among the traffic of visitors staying with the good one (and you will need to measure not just loged-in traffic as the current UX dark pathern forcing the ones that are not too lazzy to create an account do, under the disguise of "sorry technical dificulties" excuse, real, but still excuse, if you really cared about the old UI that the people prefer, you will have posponed the deployment of a new UI until after the technical limitation was enginiered out.
the lower than 40% opt-out only makes sense if loged out users THE VAST MAJORITY OF ENGLISH WIKIPEDIA visitors and traffic, could even opt-out.
also, my (anecdotal but real) experience over almost 30 years "surfing" the worldwideweb. have teached me that.
UI/UX changes made to websites will almost never revert to previous, no mather what. and that line "just try it"/"give it a try", its just to contain the uproar, that is also already sufocated because this design change to wikipedia is made 1 language at a time. and will keep going like this. maybe it may be avoided on some specific small language. or on a language that is spoken almost on a single country that has a very powerfull government oposing it.
the design will not be reverted, but the web team will promise that the feedback regarding problems will be addressed by fixing the new UI, (not really, only a few real technical problems, but they will promise and show it as if they are really trying to please as manny as posible, but the core design render of the page will remain the same, we dont want "whistespace to be filled with filler, we want it to be filled with content of the specific Article that is open not generic tools that apear on every single page.)
most internet users, as me are lazzy, they prefer to do less clic. and do less actions/activism. and by then, the new design will become old really fast and you will even launch a new "new" ui. then the old will become a new legacy and current new will become the new old. making everything more complex, and at a point you will not even allow to use the one we actually want to bring back now, because will be no longer compatible with something because is too much work for the tech to keep it compatible you to . and "users should give a try the new NEW ui".
so, in my "anedgotical" experience, the battle is already over. the best case scenario will be if the end wiki keep the option to have the old UI, (as reddit does), now wikipedia gives an opt-out for loged-in accounts, but in the future that has a very high chance of been removed because some real compatibility issue with the new something technical problem... that they didnt bother to make better in the first place so it is compatible with everything.
no mather how many times you eat something bad, it will still be bad, you may guess that it is bad at first sitgh, but after getting a bit closer or trying it 1 second you already know how bad it is.
people more versed on debates, on sociology or psicology applied to communities/groups and changes. may have their theories, but the reallity is not fear of the unkown, but changing the most informative website in the world, on the largest language used as the neutral language (instead of esperanto, because trade and tech, were internet was a big force of it, has english and the "go to" language when you want to reach knowledge on the internet.
so the change on the English version of wikipedia, is the biggest change on wikipedia, not just to native english speakers, but for most people in the world that know english as a second language.
also the intentionally very very short notice to visitors regarding the discussions that also hidden on the backstage of wikipedia where most visitors dont dare, and dont know to move around, not even most loged-in users go there. not even logged in users that reach the "active users" criteria of the goals.
The very low participation is not because this ui mutation dont affect them, not because this ui mutation dont interest them, not because they are fine with the "vector 2022" ui.
but because the bureaucracy on wikipedia, with its really large amount of rules, policies and procedures, even with just to normal article editing and creation. can get you in too much trouble. with higher ups telling you too many procedures need to be done because you did something wrong, (even if with good faith, on not controversial articles or topics. wikipedia and its articles are controled by users that main job is to make wikipedia like they want it to be. and use all the legalese terminology and bureaucracy they will trow at any one that trys to "go to the side instead of diagonally".)
"the unhappy will rise their voce the loudest" well... that is not really true if they dont know where they need to raise it, "does a tree in a forest make noice if nobody is there to listen?".
I mean not even on the "backstage of wikipedia" there is a single place to voice opinion, its very hard to decypher where it should be done. lots of techsavvy are already creating or using plugins/extensions or lifehacks to keep the vector 2010, ?useskin=vector is already poping up all around. scripts for plugins like redirector, or even Revert Wikipedia Layout extension, or tampermonkey things too.
there is plenty, for the ones that care, those will not counts against your goals statistics.
we all know that you only care about pushing for critical mass amount of users. you will fix problems generated with the new ui, do some very minor aestetic touches that you are willing to concede to reach that critical mass you need.
we all know all other is just corporate babbling.
there is no hope of another youtube comments replacement with google+ rollback, those are 1 in a lifetime, no mather how many complaints even as creative as Emma Blackery thoughts on google plus. they just keep the change is good for the sake of change, need to make changes find what to change.
if its "a problem" of info density you want to solve. then its already solved, the article intro is all the info those that seek to avoid info as much as they can.
this trend of reducing users choise, and offering less info/characters on screen. "because users are used to mobile experience" i mean. go and search statistics on desktop users only. remember maybe unlike on web design, most ppl dont like apple products outside mobile/gadgets. wasted space is wasted space. no mather the designers trends designers impose upon users.
metrics and statistics can be biased by design. same as polls are. sample size mathers a lot when pooling or getting feedback for MASIVE change as this was on this ginourmous giga popular site with so many pageloads (even more when the very bast majority are log-out ones.
i can feel lucky that my native language wiki is still with the vector2010. i did a search on it and lucky me it didnt even show a single use of the vector2022 therm. not vector2023 or incremental numeration not even with space between vector and year number. but I KNOW it will fall victim of the english wikipedia push too.
BTW: only 26 users voted to SHUTDOWN/blackout wikipedia on spanish. and you could not use it when users from spain protested over Article 13 EU policy. as remainder, that policy only affected spain out of all the spanish speaking countries, or countries where there are spanish speaking people. 20 countries have spanish as official language. and also there is 41 million that speak it as native language on the US. yet those 26 users decided that it was ok to shutdown the entire wiki on a language. to make a protest regarding something that affected a single country, even if all the other users COULD DO NOTHING TO "HELP"
so the problem that shutdown the spanish speaking wiki was a problem with spain, where 25% of people speak other languages daily as main language. so because a protest against some legislation that "COULD" affect 47 million at spain (of with 26% speak other language as native language daily. because of that about 8% of world population, the ones that speak spanish, could not use spanish speaking wikipedia) this new UI its the same, a few, very few, decided there sould be a new design, then they made the "research" to see how to justify it.
i oposse this new ui, but not because i am afraid to changes, or to new things, or about nostalgia, or because i am used to previous.
but because you tok functionality from me, you stole screen real state from me and put nothing there in return. you wasted MY screen space, you with excuses try to force me to use/create an account with your call to action dark pathern. or your fake we listen to feedback when you only listen to error reporting and metrics. maybe a change or two with things that make sense to you or ideas to add modify your UI idea on a way that you like and stay as close as your design style as you can.
this is "uproar" my voice doing as much noice as my tree falling on the woods, but there instead of "no one to hear it" ,sadly, there are people but only people around there are doing Logging jobs.
not very happy tree as you can guess.
good luck with the new UI, you will be sucessfull, but because of the wrong reasons.
and because i am a crybaby, i will not even use my account.
i never saw a problem, on previous ui versions.
yeah i dont like material design either.
i will not write again here. because now you know i know. so no need to make any more fuzz even if that may help my cause. to chose to be silent does not mean that one concede to the other viewpoint. only means we chose to not to tell what we think. and since i already did. there is no point going any further than my already long wall of text.
if you reach here i thank you, and i hope you are happy scrolling it down. i have been
happy new year.
and if you allow me, i give you a sugestion, move to mobile UI, you seem to have talent for that one.
my comment was intended as reply to wmf UI web ppl in this case OVasileva (WMF), SGrabarczuk (WMF) or anyone that could care at WMF.
but got comments in between after i started writing. sorry for the mistakenly palced comment. and also my self tought english skills. 191.97.250.27 (talk) 06:40, 20 January 2023 (UTC)
As a regular reader who found the updated site design less readable with important navigational tools hidden, I was offered only the remedy of making an account to return wikipedia to a more usable state. Please don't consider account creation metrics as a vote of support in favor of this redesign. Iwant2010vector (talk) 09:42, 20 January 2023 (UTC)
There are a few things not to like at the moment:
the default to a narrow view, for example, although that can be altered.
the lack of user links in the top right - having talk, sandbox and contributions hidden in a dropdown is a backwards step for editors (although readers won't worry about it too much). If there is an option for users to decide what links can appear in the top right (and what to consign to a drop down), that would be a step forward.
Having those links as words, rather than icons would also be a benefit: pictures mean different things to different people, while the words Talk, Sandbox, Watchlist and Contributions are much easier to identify.
The 'drifting header' feature is also a pain - click from another page onto a section and the drifting header covers both the title of the section and the edit button, so on talk pages users have to scroll slightly to get the section name and edit link. This is something that should be fixed asap.
What can also be removed from the top of an article (one scrolling down the page), is the block of links to other languages. That's a dropdown that should be on the left (it's English WP: people are here because they speak English and don't need a link to all other languages follow them down the page. It's particularly notable given this is the only bit on the top right that appears in words (big and bold), so acts as a distraction to reading the text.
The bolding of sections in the left hand menu while reading an article is a complete distraction. When I'm reading and scrolling down, the bolding moves and my eye automatically looks over at it, disturbing my reading - that's very poor.
While I'm trying to like the new version (and there are some advantages to it), I'm struggling to get over the obvious downsides built into it. I can see myself reverting to the previous version shortly if this isn't improved. - SchroCat (talk) 11:43, 20 January 2023 (UTC)
I very much agree with point 5, languages. (Although I'd like to see it on the right.) It makes no sense to have the languages "follow you". If you are reading it in English, you don't suddenly feel the need to change the language.
Also the drop-down menu is kinda slow to load and it makes little sense – it's weirdly shaped like an oblong rectangle and doesn't show many languages. — Jetro (talk) 22:45, 23 January 2023 (UTC)
Hello OVasileva (WMF) & SGrabarczuk (WMF)! I'm generally a fan of Vector 2022 and appreciate your posting here to let us know what you're thinking. My major suggestion: work on TOC improvements as a priority. The table of contents for every page is different for a reason, and Vector 2022 automatically limits it to top-level headers only and requires the reader to click in to find lower-level section headings. This is not a good choice. We already have a template, TOC limit, that makes a human-picked, sensible choice for how many TOC levels should display. Find a way to incorporate TOC limit into Vector 2022, as it was for Vector 2010, and use that to display the "correct" number of headings in the TOC. If TOC-limit is not used on a page, display all section headings automatically, as in Vector 2010. This would be a big improvement. —Ganesha811 (talk) 12:39, 20 January 2023 (UTC)
I agree incorporating TOC limit would be a big help. Other than that I have no complaints about the new skin and find it easier to use and better laid out on phone, tablet and desktop. Mike Christie (talk - contribs - library) 12:55, 20 January 2023 (UTC)
The post from WMF people at the top of this section is typical of the condescending, patronising, arrogant comments that usually come from the WMF. "We've heard what you say, and we're sorry that you feel that what we have done isn't helpful to you, but we know better than you what will be helpful to you." Posts in response may encourage them to make some changes in detail, but there's little chance of getting them to substantially revert the changes that they have done, because experience suggests that no matter what we say, they will never admit they were wrong and revert their changes. I don't specifically know about the people who did this, but many, and I suspect most, WMF employees do very little or no editing of Wikipedia, and it never seems to occur to them that people who have significant experience of editing just possibly might know better than people who don't. JBW (talk) 13:57, 20 January 2023 (UTC)
I'm kinda disappointed by this. Vector 2010 worked just fine, and yet the WMF felt that they needed to change it. Sure I've given it a chance, and yes there are some changes that I Do appreciate (mainly the "visited links" being purple), however there are some things that were completely unnecessary. The people clearly do not want it, and what do you do? You force it down our throats and basically tell us to suck it up and slam a "research" filled door in our face. We don't want this change, so stop trying to make us like it. When will you start listening to the community and doing what they want, rather than what you want? And don't just reply to this comment with something like "Oh but our research shows this is a good change." cause I'm tired of hearing that. ― Blaze WolfTalkBlaze Wolf#654514:13, 20 January 2023 (UTC)
I think the failure to include unregistered readers in the "we" who need to be considered and explicit rejection of methods to consider their needs and feedback (though research) does a disservice to a large part of our community - our readers. Best, Barkeep49 (talk) 16:04, 20 January 2023 (UTC)
I completely agree with this point. There does seem to be a gaslighting campaign going on to try and convince people not to trust their own judgement. "You just have to give it more time. It will be fine. You'll like it in time." Etc. No, I won't. I don't like it. And I'm quite capable of making that judgement. Stop trying to gaslight me. 2600:1700:1471:2550:9D6:DF7A:C8DB:4F14 (talk) 16:33, 21 January 2023 (UTC)
I'm trying to think of more than a handful of sites that ever improved after a "redesign". Instead of improving, every site seems to get worse so they can cram more ads and blank whitespace down our throats & remove all borders. Reddit, dropbox, twitter, youtube, and now Wikipedia. Revert it! Macktheknifeau (talk) 00:28, 24 January 2023 (UTC)
Unfortunately, I can't think of any feedback I could possibly offer that hasn't already been offered either more eloquently or more competently. I've been using the skin (obviously - little choice on my end) and right now the main irritation is having to click 1-2 times per page to achieve what I consider a readable state. I'm not terribly thrilled to hear that next week I may be clicking 2-3 times instead (vamoosing various side menus, then width toggling). If persistence isn't possible, then... ¯\_ (ツ)_/¯ Poor mouse, poor clicking finger. 199.208.172.35 (talk) 15:30, 20 January 2023 (UTC)
I believe there are also add-ons to chrome and firefox which can add this to the end of every page that begins with "wiki.riteme.site". See for example: URL Auto Redirector (for a more simple fix) and Tampermonkey (for more complexity), both on chrome but similar exists for Firefox.I used to use this to make sure I always went to "smile.amazon.org" instead of "www.amazon" but that's soon to be useless. Corporations are not good to us. — Shibbolethink(♔♕)19:02, 20 January 2023 (UTC)
Thank you for this update. It's depressing that it takes a pitchfork mob on the English Wikipedia for the Wikimedia Foundation to answer an obvious question which previously went unanswered for a year: what are you trying to achieve here? How will we know that a certain version of the skin helps with the goals? Unfortunately, this collection of cherry-picked statistics cannot tell us much, because we still have no idea what the strategy is behind this entire exercise. I could comment on the individual statistics but it would be pointless. I do notice there's nothing about onboarding new users, making editing more effective or "cross-project and cross-language functionalities" (recommended by WMF's own supposed strategy). Because interfaces are a trade-off, changing things for the sake of improving some metric will inevitably worsen some other metric, so I can only assume that overall strategic goals are affected negatively by the changes. Nemo10:39, 22 January 2023 (UTC)
I think there are good arguments for the redesign - all the legibility research is that line widths being too wide makes text hard to read. There's a reason newspapers use columns. But I'd like to keep the tools on the screen constantly-having them is very good for discoverability and making it easier for people to get to know how everything works. Also, I like the hierarchy of the main article column in white and the tools off to the side in grey, I think it aids focus and could be made to work with a flat design aesthetic. (I do hear the people saying they prefer wider widths, it would be nice to have that as a custom option for people who want it, but I'm on board with the idea that a narrower column is easier to read.) Blythwood (talk) 16:58, 23 January 2023 (UTC)
There seems to be some inconsistency with the rendering of the font size in various elements on the editing page. For instance, if you go to red link example, the red "this page is protected" box and the edit summary section below the editing window have larger font sizes than anything else on the page. The same issue occurs on deleted pages, where the red "this page has been deleted" box has a larger font. Try viewing Adam Cella or any other unsalted deleted page. Anarchyte (talk) 09:35, 20 January 2023 (UTC)
It seems that 'parsed wikitext' elements have 14px base font size and normal parts of the UI have 16px base font size. In the old vector this happens to be the same. And those specific areas have parsed wikitext messages which then get a different size.... I'm not sure that is as expected... Will probably have to be discussed in a ticket what the best approach is here. Thx for noticing and reporting ! —TheDJ (talk • contribs) 11:53, 20 January 2023 (UTC)
According to a report at WP:EF/FP, users who receive a warning from an edit filter cannot save their changes afterward due to the "publish changes" button not being displayed in Vector 2022. I've not verified this myself, but it would be a serious accessibility issue if true, so I'm mentioning it here. —Compassionate727(T·C)01:54, 21 January 2023 (UTC)
Warnings from edit filters seem to be working fine, and I'm having trouble understanding that report. Probably the buttons the user needed were there, they just needed to scroll down to see them or something.
However, it's true that edit filter messages like MediaWiki:Abusefilter-warning refer to the "Publish changes" button, and there may not be such button – for example, if you got an edit filter warning while using the reply tool on a talk page like this one (there's only a "Reply" button), or if you get one while editing in visual editor (it shows a popup with two buttons, "Continue" and "Dismiss"). There are almost 50 problematic messages like this: [2]. It would be nice to rephrase them… Matma Rextalk07:40, 21 January 2023 (UTC)
Given that they mentioned the "continue" and "dismiss" buttons and later made the edit using VisualEditor, I'm guessing that was related to the problem. Then again, they claimed the "continue" and "dismiss" buttons were missing. @R. S. Shaw: can you provide more details about what you experienced? —Compassionate727(T·C)15:37, 21 January 2023 (UTC)
What I saw after hitting "Publish" and triggering the filter was a dialog-like box appear over the editing screen, about centered, and only filling about half the available vertical space and horizontal space. Inside the boundaries of that box was another box with heavy red outline with text from the filter. That was all that was presented (at first impression). After starting to follow the box instructions by starting creation of a False Positive report, I went back to the tab with the dialog box display and then noticed that the outer dialog box border was different on the right from the left side in that it was actually a gray scroll bar. Scrolling up, the "continue" and "dismiss" buttons appeared; this was the first I knew about them. So, the initial impression was of a double-bordered box, outer gray, inner heavy red outline with the entire message, and nothing more. If I had been aware that such buttons existed, I quite possibly would have used one of them instead of filing a FP report (although I do consider it a false positive, so I still might have). ETA: I believe a "Publish" button was present in the background, but grayed out because the dialog box had monopolized the focus. -- R. S. Shaw (talk) 19:15, 21 January 2023 (UTC)
Some things that should be absolute minimum requirements if the default skin is not reverted to Vector 2010
Make the "log in" button visible on every pageview without having to click another button first.
Move the full-width toggle to the top of the page. Make it persistent across multiple page loads. (the argument that persistence is technically infeasible is an obvious red herring. WMF has a $100 million endowment. You can figure out a way to make this possible. Come on.)
In all honostly, regarding 2, non-fixed width should be made default again. Let readers scale their browser windows and/or screen resolutions as they wish. Tvx1 22:42, 21 January 2023 (UTC)
Yes, that's why I made question 2 in the RFC. I'm trying to establish consensus around fallback options so we get something instead of nothing if the new skin is (unfortunately) not rolled back entirely. IWantTheOldInterfaceBack (talk) 02:08, 22 January 2023 (UTC)
Correction, found it hidden (i.e. had to scroll down) in the page top drop down menu and for some reason the deployment of Vector-2022 autodisabled the script. Nthep (talk) 15:15, 21 January 2023 (UTC)
Hidden? Functionality hidden in an out-of-the-way place? and not behind a new mysterious/inscrutable icon... Say it ain't so. Shearonink (talk) 14:39, 22 January 2023 (UTC)
I can understand the feedback that is being shared here and why that might seem harsh. In some sense you folks have a bit of a thankless job in this exercise. So, you have my respect for that. But, that said, this does feel like a suboptimal roll-out.
The Positives.
For the most part, if you forget page-to-page interaction, and just focus on a single article at a time -- There is a bit of freshness in the article pages, and the whitespace feedback notwithstanding, I think that is a positive. To be fair, there is an argument to be made that most of our visitors land at an article page from a link from a search engine and to them, this might not be a terrible experience at all.
The Negatives:
The mainpage is an absolute mess. The four box format that has been the homepage for over two decades now just does not fit into this modern layout at all. I wonder how that never came up in any of your design reviews. The main page should be fully redesigned to fit this new skin / visual template.
Lack of consistency between pages. Do this simple exercise -- start from the main page and click on a few links and see how the top margin and the left and right margins just jump around willy-nilly. That is absolutely amateurish experience that should be remedied ASAP. I had provided this feedback in one of the earlier threads and this does not seem to have been acted upon in its entirety.
xx Languages as the most prominent link on a page. Do this simple exercise here again -- click on a few articles and click on a few languages and see your end-to-end design experience. Absolutely broken from a design standpoint. Some go to the new skin, some go to some weird old skin -- no consistency at all. This is alright if the link is some embedded link -- but, your most prominent link throwing this broken experience is absolutely not acceptable. What drove us to include languages -- did any study indicate that readers want to read the same article on different language wikis? Does not seem so, but, if studies overwhelmingly indicate so, maybe there is an argument to be made. Also, what is the thinking behind enabling "languages" for pages in the "Wikipedia" namespace. This should be removed. I can at least understand the "languages" link for pages in the "Article" namespace. Anyway, the one positive to be had from this is -- maybe we will have editors translating more articles into the other languages.
The above three negatives should be fixed ASAP. Please pardon my saying this -- this has been a suboptimal roll-out. Let's fix this. Tagging some of the WMF users driving this project Ktin (talk) 20:45, 21 January 2023 (UTC)
1. this is up to the local community, not to the software maintainers and/or designers
2. this has to do with wether or not a table of contents is needed for a page or not. I do feel there is a point for improvement here, though I'm not sure how...
3. "Some go to the new skin, some go to some weird old skin" This is mostly a temporary thing. It takes a while to get everything switched over. "What drove us to include languages " mostly a desire to promote the wikis of other languages. This has been a consistent point throughout feedback over the last couple of years. —TheDJ (talk • contribs) 20:55, 21 January 2023 (UTC)
Thank you for your response.
Re: #1 -- The end reader does not differentiate between WMF and the "local community". They would want a consistent design experience. Period. The mainpage as it stands right now is not of the same design framework as the skin / new design template and that needs to be fixed ASAP.
Re: #2 -- Not sure if we are speaking two different things. Do a simple exercise. Start from the main page and visually track the top margin of the article page and the left and right margins. See how they bounce around. A simple fix should be there should be no bouncing around of margins as you click between pages. I am not as worried about the whitespace.
Re: #3 -- Desire to promote wikis of other languages -- is absolutely fine. That's what I have noted as the positive impact of this change. But, the experience right now is broken visually. Also, a simple fix is to remove the languages link from non article pages. For e.g. Do you really want to go to Wikipedia:Village pump (technical) in 74 languages? Ktin (talk) 21:01, 21 January 2023 (UTC)
Your number one is puzzling. We have had a 4 box structure on the main page since 800x600 was the resolution used for monitors. It was explicitly designed by English Wikipedians for the size at which it now displays (which is actually larger, at 960px). Izno (talk) 20:59, 21 January 2023 (UTC)
I am saying that the four box structure is not consistent with the new Vector 2022 design. Take that for what it is. If you disagree, that is perfectly fine. Ktin (talk) 21:03, 21 January 2023 (UTC)
Ok, so I think then your complaint is that it's got boxes that are pastel colors. That's true, and I agree with the complaint :), but that's a complaint that's got nothing to do with Vector 2022. It wasn't any better under Monobook or Vector 2010. Izno (talk) 21:07, 21 January 2023 (UTC)
If it is only the color palette, I think that might be an easier fix. I think the problem is that we have moved away from the notion of "boxes" as a design element (which has been the case in all prior WP design iterations) to one which does not have boxes but just horizontal lines as demarcations and plain whitespace. While this is definitely fresh -- the main page view of four boxes is not consistent with that design view. Ktin (talk) 21:23, 21 January 2023 (UTC)
all? :) I use Timeless and there is a distinct lack of borders for boxes, and then there is also Minerva, which also is largely "borderless" and which serves our mobile community since a decade ago. Even Modern has a lack of distinctly colored borders, and that's nearly as old as Monobook. Anyway, yes, the skins do have differing opinions on how much border to serve a human.
But in the rest of our wiki, we do have many other things that retain their borders, such as standard wikitable as well as {{infobox}}es, {{navbox}}es, and myriad other "content structure" items. The main page is thus not really inconsistent with the wider design of editor-driven content (besides the pastels).
Otherwise, I agree with TheDJ that the main page is not something that upstream can or will or should attempt to fix. It's solely in the realm of editors. I've already had to reiterate to upstream just this week about how sensitive English Wikipedia is to main page design changes. Izno (talk) 21:32, 21 January 2023 (UTC)
Now, that this passage has been moved into the middle of this wall of text, I hold no hope that this passage would get any visibility among those that matter (and I do not mean that as disrespect to you). Fwiw -- I still strongly believe that the mainpage four box layout does not fit Vector2022 since we have gone away from boxes as means to structure an article page between the legacy vector and Vector 2022. Your point on Monobook or Minerva etc might be correct, but, I am going to stick my neck out and make a claim that most readers were on legacy Vector (not on Monobook or Minerva)[citation needed] and now moving to this skin presents a differing experience between the main page and the articles, which is not good. Agree with the point on colors as well, but, this is more than that. I think we can agree to disagree here. Let's leave it at that. Re: Mainpage design being the realm of the community vs WMF (or upstream as you call it), I think that is perfectly alright. But, if upstream does a change, downstream needs to reflect appropriately and the two should move together. Else, we will have a fractured experience.
@Ktin, mobile serves 63% of our page views, which means the vast majority of readers see Minerva. It is hard for me to see that as the minority of readers. ;) Izno (talk) 00:15, 22 January 2023 (UTC)
How can I remove suggested languages?
On the top right corner, I have some kind of language selector. How can I remove suggested languages or change the order of languages? For some reason, the first language suggested is Russian, which I don't understand. How do you remove that and some other languages from the list of suggested languages? In English wikipedia, the first suggested language should be my first language whatever that is (e.g. Swedish, Norwegian, Japanese).
Even better would be that I could choose myself which languages are important to me. That list would be short, perhaps 3 or 4 languages. Currect list of suggested languages seems to be about 10 languages and that is too much. 2001:14BA:2BF7:F700:A3E7:1EC2:AD07:5BA1 (talk) 22:32, 21 January 2023 (UTC)
At one point, at least if you were logged in, the list of suggested languages kept track of things like which languages you've used most recently. I don't recall hearing that this had been disabled, so it probably still works.
.... also by logging in you can choose what languages the system prefers to serve you with the WP:Babel series of user boxes, as far as I understand.
My understanding is that if you don't explicitly opt in in that way, the system tries to guess based on your IP. Since your IP geolocates to Helsinki, Finland, I would guess that's why Russian is showing up. That seems like a miss either way since while Finnish is Baltic, it's not Russian, so there's maybe a valid bug in that regard. (I know that the education system in Finland has emphasized Swedish and English most recently for other languages.) Izno (talk) 00:22, 22 January 2023 (UTC)
The system should not suggest languages based on location unless the language is an official language in the region. English can be suggested always, because it is probably the largest wikipedia. In Finland (when using English Wikipedia), the system should suggest Finnish and Swedish and perhaps Sami languages. If the reader has used any other languages often, those can be added to the suggested languages. 2001:14BA:2BF7:F700:115C:F0A2:E963:C9D2 (talk) 15:40, 22 January 2023 (UTC)
Swedish is not on “other” language in Finland. Finland is a bilingual country with Swedish being one of its two official languages. Tvx1 16:38, 22 January 2023 (UTC)
Take out buttons from top left and slightly dimming side space
This new skin is nice. But problem I have is that all buttons like sandbox, watchlist, user talk etc need an extra click then previous skin. How to add that buttons on right side. and one more thing how to make that side space slight yellowish-white. Parnaval (talk) 20:21, 23 January 2023 (UTC)
I agree, last day, while editing on 2010 Wikitext editor, I was clicking on white area at the bottom of all wikitext, to add content there. It turns out that that particular area was beyond the editing box, and I should've clicked a little above to bring the cursor there. There should be a subtle color difference and/or border between article-text/wikitext area and the rest of whitespace to demarcate them. —CX Zoom[he/him](let's talk • {C•X})20:33, 23 January 2023 (UTC)
Calling a value from main function in another function in lua
Hi all, I've another question about Lua. Let's say, I got values a & b from the main function. Now, I want that a separate function A & B be created whose sole job is to extract the values a & b respectively from the main function and return them. I don't want to repeat the entire code of main function twice in order to achieve this. Thanks! —CX Zoom[he/him](let's talk • {C•X})12:23, 30 January 2023 (UTC)
Not that actually. At Module:Sandbox/CX Zoom/TestPage3, some calculations within the main function, I've found values for outputRank & outputCount. Now, I want that outputRank be returned when I use {{#invoke:Sandbox/CX Zoom/TestPage3|rank|foo}} and outputCount be returned when I use {{#invoke:Sandbox/CX Zoom/TestPage3|count|foo}}. To @Anomie or anyone else, feel free to edit the module if you need. Thanks! —CX Zoom[he/him](let's talk • {C•X})14:20, 30 January 2023 (UTC)
To make the query happen, just click on the "do this" link above to enter PetScan with a query set up ready to run, then click "Do it!" to run the query. "0 rows" means all listed articles are GAs; otherwise you'll get a list of non-GAs. Certes (talk) 20:11, 30 January 2023 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Problems
Last week, for ~15 minutes, some users were unable to log in or edit pages. This was caused by a problem with session storage. [3]
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 31 January. It will be on non-Wikipedia wikis and some Wikipedias from 1 February. It will be on all wikis from 2 February (calendar).
Future changes
Wikis that use localized numbering schemes for references need to add new CSS. This will help to show citation numbers the same way in all reading and editing modes. If your wiki would prefer to do it yourselves, please see the details and example CSS to copy from, and also add your wiki to the list. Otherwise, the developers will directly help out starting the week of February 5.
Explain this to me. I just went to https://meta.wikimedia.org/wiki/WikiLearn/Out_of_beta. I don't look at meta much; it's quite possible this is the first time I've been there since switching to a new browser (I'm trying out Firefox). The page header shows me as "Not logged in", but I also have a popup saying, "Central Login: You are centrally logged in as RoySmith. Reload the page to apply your user settings". How does it have enough state to know that I'm logged in on CA, but can't just apply that automatically to meta? -- RoySmith(talk)17:26, 30 January 2023 (UTC)
@RoySmith: this is phab:T217519 - when you hit a domain you haven't gone to in a while it happens, and it can be due to many different things - you may also see that if hitting commons, or mediawikiwiki, outreachwiki, etc. — xaosfluxTalk17:40, 30 January 2023 (UTC)
Or if it's not that, it's the fact that when the page loads you're not logged in yet, then some JavaScript runs that manages to log you in. But we don't want the JS to just reload the page on you as it might interrupt your reading or editing, hence the popup letting you know that you can reload. Anomie⚔13:08, 31 January 2023 (UTC)
Bug in ctime
There is a problem with {{ctime:x}}. For example {{ctime:x|2024|1|1}} == 2024-02-10, but should be 2024-02-10. This is causing a lot of problems in many articles with incorrect dates, such as the Chinese New Year in this example. Any ideas? -- GreenC15:31, 26 January 2023 (UTC)
Step 1 would be to create a testcases page with a bunch of examples, including some farther into the future and the past, to see if the problem occurs for a range of years. – Jonesey95 (talk) 17:34, 26 January 2023 (UTC)
It seems to me the massive table that is {{ctime:info}} is likely defining the start of the year according to a metonic cycle, and the values for 2024 and 2025 are wrong. But I don't dare touch it without understanding it.
When I first noticed this problem myself, last August, I was looking at Qixi/Chilseok and Mid-Autumn festivals. It became apparent that all 2024 Lunar dates were wrong by 10 days. Earlier years I checked were accurate. I just spot-checked 2025 and ctime:x seems to report 1 day late. For reference, I use the Hong Kong observatory Gregorian-lunar calendar equivalence documents. 2026 seems OK. -- M.boli (talk) 18:47, 26 January 2023 (UTC)
The HK source agrees with 29 Jan 2025 and 10 Feb 2024 but seems to specify 11 Jan 2024. (Forecasts can be a day out if the new moon is close to midnight, but I don't think 2024 is such a case.){{ctime:L}} has hard-coded exceptions for a few years, but not for the cases we're questioning. {{Ctime:l}} (lower case L: a different template) has a number for each year; changing those numbers (to what?) may fix the problem. Certes (talk) 19:12, 26 January 2023 (UTC) Corrected, as I misread the table. Certes (talk) 22:36, 26 January 2023 (UTC)
11 Jan 2024 is the first day of the 12th lunar month. New year = 10 Feb 2024, 1st lunar month. The table has small print. -- M.boli (talk) 21:30, 26 January 2023 (UTC)
I checked years 1990 - 2030 against the Hong Kong observatory tables. The years 2005 and 2006 have similar discrepancies as 2024 and 2025. This is consistent with the 19-year metonic cycle. I will play with the constants for the errant years in {{ctime:info}} and maybe {{ctime:l}}. I think the main idea is that these constants encode the alignment between the Georgian calendar and the 6939.6 days in a Lunar calendar cycle. But absent the equation for the the calculation I will be fiddling to get the numbers right and I won't trust it. -- M.boli (talk) 13:36, 31 January 2023 (UTC)
Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "/mathoid/local/v1/":): d
Per IAbot's page on Meta, "InternetArchiveBot is currently not available due to operational issues." I don't like how vague that is, however I guess we just have to wait for an update. ― Blaze WolfTalkBlaze Wolf#654521:08, 31 January 2023 (UTC)
Recently I've been discovering that when I'm editing in source on rather long pages (namespace doesn't seem to be a relevant factor), the screen jumps down, far away from where the caret is. I've tried it in safe mode and at different zoom levels and the problem still persists. Is this a known issue?
Does this also happen in the visual editor, or only in the 2017 wikitext editor? Does it happen in ConvenientDiscussions or any other tools you use? Do you have the colorful syntax highlighter enabled? Whatamidoing (WMF) (talk) 18:53, 26 January 2023 (UTC)
@User:Whatamidoing (WMF): Doesn't appear to be. The caret stays in the position that I click, and the code scrolls downward. Just to confirm, when I'm clicking roughly the bottom quadrant in source mode it's supposed to jump up a few lines for ease of editing, correct? I'm seeing that happen in articlespace while Wikipediaspace is the big issue. I'm not sure if it's a size issue, given how big the RfC for Vector 2022 and this page are, which is what I've been testing this bug on. Does this also happen in the visual editor, or only in the 2017 wikitext editor? It only happens in the 2017 wikitext editor. Does it happen in ConvenientDiscussions or any other tools you use? It does not. Do you have the colorful syntax highlighter enabled? I'm not sure if you're referring to the gadget, in which case it's not enabled. —Tenryuu 🐲 ( 💬 • 📝 ) 19:47, 26 January 2023 (UTC)
There are multiple syntax highlighters, but I was thinking of the built-in one ("CodeMirror").
From a quick look, it appears to me that the issue stems from the "Tools sidebar" update. The page layout was changed to a grid, which has shifted where #bodyContent loads by 8px. And since logged out users are still served with the previous layout it doesn't show there. Overall: Fantastic that logged out users see a different page so the coordinates positioning overlaps when logged in but not when logged out. No easy fix I see since a fix for one will probably look broken for the other. Terasail[✉️]03:05, 1 February 2023 (UTC)
This is because editors couldn't agree on how this English Wikipedia content should be displayed, and Izno and I said we wouldn't touch it until ppl decide what they want. So please figure that out and it can easily be fixed/improved. —TheDJ (talk • contribs) 10:29, 1 February 2023 (UTC)
What's the most efficient way to get a list of all GA subpages -- that is, all pages of the form "Talk:<article name>/GAn" where n is 0-9. (I suppose there may be a GA10 or GA11 somewhere.) I can run pywikibot but I don't know of a category that will give me everything. I've pulled every GA page created by reviewers listed at User:GA bot/Stats, but anyone who created the GA and passed it between bot runs isn't on that list, so I missed Talk:Electric fire engine/GA1 that way. I can also go through Category:Good Articles, but I'll miss anything that has been delisted or never passed. The DelistGA and FailedGA templates are not reliably on the talk pages of their articles. So I think I need to do a pattern match on the talk namespace. Is there a way to do that? Mike Christie (talk - contribs - library) 22:54, 31 January 2023 (UTC)
It looks like this change tries to enforce a max image size, but the use of |imagesize= in the template overrides it. I changed {{AuEduNewbie}} to work around the problem for now, but I don't know if other transclusions are affected. – Jonesey95 (talk) 19:33, 1 February 2023 (UTC)
Never mind. I found a better fix. Note that this change will enforce a maxsize on all images used by this template, which has 134,000 transclusions, so if the images are too small now, both of the maximums (maxima?) should be increased in Template:Ivory messagebox. – Jonesey95 (talk) 19:36, 1 February 2023 (UTC)
Yeah, I was trying not to do it that way. The issue is indeed that images will flow out of their containers in some skins; in other skins, get to a certain resolution and the images start disappearing.
Is there a tool to make usertalk more like an inbox?
Is there a tool for collapsing topics? Or marking an individual topic for archive or deletion?
And similarly is there a way of collapsing all templates? Wakelamp d[@-@]b (talk) 13:54, 30 January 2023 (UTC)
Marking an individual topic for archive or deletion, there is again no tool. There are some scripts like User:Evad37/OneClickArchiver and User:Σ/Testing facility/Archiver you can use for archiving. If you want to add some wikitext, you can set up User:ClueBot III archiving and then add some keywords in |archivenow= that you would like, and then add those keywords in the specific section's text to make it archive.
By collapsed, I meant aaking the screen less cluttered by just showing the wiki code withut the braces (I think DE (??) have them collapsed or maybe they are all just one line long
@Izno When it says one click, does that mean I just click on the section heading? Or is there a way to add to the
Toxicity and Abuse Reduucion
I was wonering if giving the editors more control/allowed closure/shortcuts (see Ben Shneiderman#Designing the User Interface by saying archive that/delete tha might reduce the aggravation
@Xaosflux Yep the flow tools was what I was thinking of, Are thye dead?/ It is apity we don't have them available even as a preference :-(
With archiving, is there a flag that allow you to store each topic stored as a seperate individual records( . (I want to start creating issues lists, and user stories for poor behaviour reasons.).Wakelamp d[@-@]b (talk) 03:02, 2 February 2023 (UTC)
Is it somehow possible to re-enable, get it to work again, the Tournamen draw generator tool, that now-retired user:Renamed user qoTkZBdUBiU (previously User:Somnifuguist, had created? I am planning on creating around 30+ tennis draws articles and it would be really useful to use the tool to speed up things instead of wasting hours to make one draw. Here is a relevant discussion listing the steps on how to use said tool. Any input from Python-adept admins or any other editors would be much appreciated.
@Qwerfjkl, when I insert [4], an ITF-generated tennis tournament draw link, in the "Tournament link" query on Tournament draw generator and click "Request" it gives the error message: "The program has encountered an error. Please go back and check that all inputs are correct. If the error persists, please contact Somnifuguist see if you can find the same draw on the other site." The tool's creator has since retired and the tool associated with it, does not work as intended, it doesn't give out any results except for the error message. Any idea on how to get the tool to work again? Qwerty284651 (talk) 17:21, 31 January 2023 (UTC)
The ones I am looking for are WTA draws, women's tennis draws. The "other site", the tool is referring to, is ATP, which are men's draws. ITF contains draws for both men and women and is the only site that has the women's draws. WTA does not provide any such draws, at least not for the early 1990s, the ones I require. Qwerty284651 (talk) 18:59, 31 January 2023 (UTC)
I just receive the welcome to wikipedia template on my talk page. At the end of it, there is a "reply" button, that doesn't do anything. I believe it should add a new "reply" section at the end of the template, but that doesn't work. This bug has been tested on MacOs, Windows11, and Arch Linux (but always using Chrome) with the same result. Vincent-vst🚀 (talk) 07:33, 2 February 2023 (UTC)
Having had a look in my sandbox, the issue is the fact that the template is using the h2 tags within the div so the reply tool cant find the section to edit (Also causing issues with discussion tools loading information). Although when replying, the reply is placed within the signature div. I will post on the templates talk, and might boldly update this template to stop this behaviour. Terasail[✉️]13:06, 2 February 2023 (UTC)
I'm not sure this is the right place, but my google books link was disallowed a few minutes ago; I routinely add google books links, so not sure what's going on here. Assistance would be appreciated. The link in question is books.google.com/books?id=XAT4AgAAQBAJ&pg=PT79, add the https:// in front to make it work. Vanamonde (Talk)17:26, 2 February 2023 (UTC)
I was wondering if somebody could modify the {{GAR/link}} template and related templates now that there is just a single GAR process per this close. Rather than two processes, we'd only need the sentence:
Follow this link to create the good article reassessment page for the article
Hi everyone! Does any tool exist that allows us to split one page (let's say an article) into 2 or more pages while preserving history, contributions, etc.? Something like the Move command. What about the reverse, merging? Is there any feature, native or not, that allows us to do this beside manually copy-pasting text around?
Extra: What about moving sections around in different pages? — Preceding unsigned comment added by Klein Muçi (talk • contribs) 2023-02-02T14:25:39 (UTC)
Special:MergeHistory is for combining pages. It is very difficult to "split" histories, if the edits are purely distinct selective deletion/restoration/move could be done, but it is messy. Another hack would be to import the page to another page, duplicating the history - generally none of this is needed. When splitting a page, indicate the split source in the edit summary. See Wikipedia:Merging and Wikipedia:Splitting for more on this. — xaosfluxTalk14:32, 2 February 2023 (UTC)
Xaosflux, thank you for providing the links! Pretty informative. Since were in the spirit of the technical wishlist these days, do you think it would be sensible to ask for an overall easier process tech-wise for this? Maybe just asking for the option to easily move sections between pages same as we do with pages themselves? Most likely that would be considered a big change but... What do you think? Am I overlooking a lot of drawbacks in this? — Klein Muçi (talk) 20:26, 2 February 2023 (UTC)
@Klein Muçi you can ask for anything, but that sounds like a "hard" thing because of maintaining attribution. A single edit to a page can touch every section of a page. — xaosfluxTalk20:30, 2 February 2023 (UTC)
Xaosflux, ah! I keep forgetting you can edit a whole page. It's been a while I've had the chance to do something like that. As always your insight is valuable. — Klein Muçi (talk) 20:41, 2 February 2023 (UTC)
It's currently being used as a navbox on several of the pages on which it is placed, its issue is that that's not how it's being used on the Weather of 2022 page. You'll have to decide, probably at the relevant WikiProject talk page since it impacts many pages, how to best deal with it, either by removal or moving to the bottom on the weather of 2022 page, or converting it to a table and then moving it on the other pages so that its location makes sense on those pages/removing it on those pages. Izno (talk) 19:59, 2 February 2023 (UTC)
Right, but there's nothing in that template that would cause the issue described in this section. There is a limited set of classes that will disappear things and that template does not have any of the 3 or 4, so I would need to know where that template is being used that had a "couldn't see it on mobile" response to know where to attempt to fix it. Izno (talk) 02:44, 3 February 2023 (UTC)
Wanted: template to convert four special characters to their HTML entity equivalents
Help:Template#Problems and workarounds, first bullet, explains that when a template parameter value starts with :, ;, *, or #, undesired newlines can be emitted by the template. This problem can be observed at Template:Talk_quote_inline/testcases#quote, where I have been attempting to fix the problem in the sandbox via a variety of invisible characters, to no avail.
It occurred to me that it might be useful to have a template that took arbitrary input, tested to see whether the first character was one of the problem four, and swapped it out for its equivalent HTML entity. Before I try to hack such a template from scratch, is there one that exists? Will it work for this case? I suspect that it might come in handy elsewhere. Any coders want to take a crack at it? – Jonesey95 (talk) 03:13, 3 February 2023 (UTC)
This makes the new add topic editor so much hassle that it is worse than useless to me. If I try to put a question mark at the end of a sentence, it jumps back to the top left of the window. I have to cut and paste to get it to the end of the sentence. If I switch to legacy halfway through the edit the whole edit is lost. Firefox on Windows 10 and 11. Cheers, · · · Peter Southwood(talk): 10:09, 24 January 2023 (UTC)
Even worse now, as the option to shift to legacy seems to have disappeared, so now I have no option but to use the broken new topic editor to start a new talk page section. · · · Peter Southwood(talk): 14:31, 26 January 2023 (UTC)
If anyone else experiences this problem with the cursor jumping around, I would really appreciate it if you'd speak up (here or at the second Phab task). The devs can't figure out how to trigger this on purpose, which means that they can't figure out how to fix it, or even if they thought they fixed it, how to find out whether the fix actually worked.
Built-in opt-out button
I think the "switch to legacy" bar in DiscussionTools disappears after you've used it. The built-in button for switching back to the old skin (or any style you prefer) is still there, as you can see in this picture.
If the sidebar's collapsed, then click the Hamburger button by the logo to open it. Click "Switch to old look", which will take you to the exact section of Special:Preferences that you need to be in. The "preview" option for each item will let you find the style that you like best.
If you definitely want to go back to last month's default appearance, then this link will do it automagically for any logged-in editor: https://wiki.riteme.site/wiki/Special:Random?setskin=vectorDo not click this link unless you want to change your preferences automatically. This one link combines all the normal/manual steps, including saving the change to your prefs, into a single click. We normally use a slightly different link on this page, ?useskin=, so that people can see something in a skin on just one page, without changing their prefs long term. This ?setskin= approach will make a long-term change ("permanent", except that you can go back to Special:Preferences to change it afterwards). Whatamidoing (WMF) (talk) 15:38, 26 January 2023 (UTC)
Xaosflux, Whatamidoing (WMF), Thanks for your replies, but that is not the legacy functionality I was referring to. Up to some time between my first post of this thread on the 24th January and before my post on the 26th, if I clicked on the blue add topic button in the sticky header, an edit window would open, and above it there was a notice to the effect "click here for legacy experience" or something similar, which would let me edit the old way. It was a bit tedious but it worked. Suddenly the notice and the place to click was no longer there, and I am stuck with the jumping cursor, which is not even obviously consistent in its jumping, except it always goes back to home position in the edit box when it jumps, and is always triggered by the shift key, but not, it would appear, every instance of using the shift key. My current workaround is to cut and paste all the scattered bits back to where they should have been, which I am sure you can imagine is not conducive to efficiency, particularly when using a touchpad. I do not actually want to go back to Vector 2010. Most of Vector 2023 is to my liking, except for the infestation of bugs. Speaking of bugs, when I zoom in a bit to get more legible text, the edit window gets narrower relative to text size, and instead of wrapping the text to fit, as one would expect, it has sprouted a horizontal scroll-bar at the bottom and the text goes hidden at the left or right side, making it look like typos all the time when I proof read. This does not improve my productivity, or my peace of mind, but I feel it is fixable, hopefully within a reasonable timespan. The side by side preview, on the other hand, seems to manage to wrap quite well as far as I can see, but it would be more useful if I could see the text I am working on at the time without having to jump over to the right (preview) window and scroll down all the time. While on the topic of the edit window this side by side realish time preview is nice, but the roughly 20% of screen width whitespace on the right side below the tool sidebar is really wasted. It is prime editing real estate, let us use it to edit. Edit and realish time preview windows together should be full width. The tool menu sidebar can stop scrolling at the top of the editing area (when they get it to scroll). Cheers, · · · Peter Southwood(talk): 19:11, 26 January 2023 (UTC)
I leave it as an exercise for the reader to work out what I was trying to report here, and the actual order in which it was written. I am getting the same problem with this reply using the [reply] button. I have turned the New Topic Tool off. Thanks @Whatamidoing (WMF) · · · Peter Southwood(talk): 15:08, 3 February 2023 (UTC)
Page jumps past requested subsection
On my Android phone, when loading a link that points to a subsection, the page often loads past the section.
I don't know if it is switching to Vector 2022, or my custom CSS, or some gadget that I have enabled, but on a complex page like this one, my page jumps about four times before coming to rest, usually at the wrong place. It has become much worse in the last month or so. – Jonesey95 (talk) 08:32, 1 February 2023 (UTC)
@Jonesey95 Android and mobile in general is using the Minerva skin. Not related to Vector 2022. If you are talking about PC use then you should open a private tab/window to check if any of your Gadgets or Add-ons are a factor for you. Seems fine for me on a PC. Nux (talk) 18:05, 3 February 2023 (UTC)
Similar to CX Zoom, I'm also facing the same issue since using Vector 2022. RoySmithnotified me that there's a phab ticket about this (see: T327350)... Apparently the people at WMF closed the bug ticket as "invalid" and are claiming that it's "standard browser behavior for refreshing the page with an anchor in the URL"? Some1 (talk) 12:34, 1 February 2023 (UTC)
We probably need to submit a screen capture video to phab of one of us experiencing this. It would be helpful if it happened for logged-out readers as well as editors with lots of scripts installed. – Jonesey95 (talk) 15:05, 1 February 2023 (UTC)
There's two issues here. T327350 is not describing the same issue here that User:A bit iffy has raised.
I believe this issue occurs if you have any gadget that modify the content or the title area - this causes the article to reflow after the hash fragment has been processed, meaning the article is in the wrong location (such changes are also bad for performance). On mobile the page flow is much more sensitive to these types of changes.
There are various gadgets that are adding HTML to the top of the page (for example "A C-class article from Wikipedia, the free encyclopedia" appears at the top, or "415 revisions since 2001-08-21..." or Wikidata description editor and really they should be firing some kind of hook informing MediaWiki that the page has changed and the hash fragment should be processed again. In the short term we could add a gadget handling this e.g.
If there is a quick fix, that would be great. What is happening now, which does not seem like a few pixels of adjustment for some top-of-page material, is that if I load up this VPT section in a new tab, the page initially renders with the section showing, then does four or five little vertical jumps (this could be the top-of-page stuff), then jumps up the page. I have to page down five full screens to get to the desired section. The effect is much less when I am logged out, but it still happens a little. – Jonesey95 (talk) 19:45, 1 February 2023 (UTC)
Wikipedia:Long-term abuse/Best known for IP has been using mobile phone IPs to avoid detection and blocks. They are actively removing the word "famously" from Wikipedia. I'm not sure how to track removals of the word, except when they show up in my watchlist. Any suggestions? -- GreenC17:26, 3 February 2023 (UTC)
I wonder why they're not supposed to be used. THe MOS guideline just says they shouldn't be used without giving any reason why or any link to a discussion that led to that. ― Blaze WolfTalkBlaze Wolf#654517:36, 2 February 2023 (UTC)
Geez RFCs in 2015 were much different than now. I'm having a hard time following that RFC and am struggling to see the reasoning behind the decision to not use them. ― Blaze WolfTalkBlaze Wolf#654518:01, 2 February 2023 (UTC)
That RFC was to update the text as it was presented then, which was "don't use because it breaks browsers". Now it's simply "don't use". I would guess the overall rationale is that English Wikipedia shouldn't be used as a transliteration aid, since it's not a dictionary. Further substantive discussion can/should be there if you wish to pursue it. Izno (talk) 18:05, 2 February 2023 (UTC)
Fair enough. I would say that ruby text should be fine if it would normally be used in the kanji in the context (or maybe ruby text can always be used and I just don't know that because I Don't fully understand how the heck Japanese works). But that's not something to discuss here. ― Blaze WolfTalkBlaze Wolf#654518:36, 3 February 2023 (UTC)
Apostrophes display as square boxes
Today, running Windows 10 with a generic desktop monitor, suddenly all apostrophes display as undisplayable square boxes. I trust this will eventually get fixed. I tried Switch to old look, accepting all defaults, but the Save button is grayed out. I noticed somewhere near the top of this present page that another user had aptly compared this current disaster at Wikipedia to the disastrous experiment with New Coke -- but this is far worse; millions of people rely on Wikipedia. "If it ain't broke, don't fix it." (Funny, here my apostrophes are displaying correctly. But still not at the page I was looking up, Marion Clinch Calkins, with a reload.) How could a ' display correctly on this page but not in an article? Milkunderwood (talk) 01:25, 28 January 2023 (UTC)
Oh for G*d's sake, Edit takes you to the top of page, instead of to your own section to be edited! And, it won't display-as-you-type like a new section does now. "Show preview" also jumps to top of page, and will NOT show a preview!! Instead of messing with everything at once, how about testing one step a time? Milkunderwood (talk) 01:48, 28 January 2023 (UTC)
Thank you again -- I originally chose the highlighted "Switch to old look" from the menu in the left column of my display, but once there, my Save button is still grayed out and inoperative. Milkunderwood (talk) 02:23, 28 January 2023 (UTC)
That is, I had originally chosen from the menu, but then used your "Special", where Save was still grayed out again. -- Oh, and now I do get a Preview. All very weird. Milkunderwood (talk) 02:32, 28 January 2023 (UTC)
Trying your empty #13, Edit took me there rather than to top-of-page. I don't know if it's relevant, but following xaosflux's instructions (where discussion moved to his talkpage) I've reverted to the old skin, and haven't had a top-of-page problem since. And it happened only here on this page, but consistently, in a few tries. Thanks for asking. Milkunderwood (talk) 00:11, 2 February 2023 (UTC)
Yes, that's what it's supposed to do, and had always done -- until on this one Village Pump (Technical) page it kept insisting on jumping to the page top, so that I had to keep scrolling manually back down to this section. Presumably fixed since then. Or at least it's been working properly. Milkunderwood (talk) 23:39, 3 February 2023 (UTC)
Thanks, although I don't recall enabling that or even what it means, but turning it off solved the problem so I appreciate the response. S Philbrick(Talk)00:43, 4 February 2023 (UTC)
Terasail. Thanks! And I noticed that the change is remembered on edit windows in subsequent articles and talk pages. And it is easy to switch back and forth. That makes it useful to me for a quicker preview if I don't have to do too much scrolling on the right side. Sometimes I prefer the wider edit window. So the choice is nice. And tables will often need the wider edit window. But it is really nice to be able to see table previews in real time while using source mode. I am liking this a lot.
That's the right way to do it. Some of the other entries use {{sortname}} inappropriately on book titles. It's for people and generates hCard data which doesn't make sense for books. PrimeHunter (talk) 21:40, 4 February 2023 (UTC)
The teleseries for "1923 (teleseries)" has no Infobox image in English wikipedia, however, the Russian version does have a good image. When I try to copy the cyrillic file name on Wiki-commons from the Russia wikipedia version to the English version, then nothing is recognized. Is there a simple fix to get cyrillic files recognized on English wikipedia? ErnestKrause (talk) 16:19, 3 February 2023 (UTC)
PrimeHunter: That is fully correct; I was looking at this article and the Wednesday teleseries article, which were in the same situation about Infobox images. The Wednesday teleseries article image is now taken care of, and if someone could transfer the image from the Russian '1923' teleseries article via Interwiki to the English version, then it would help the viewers of the series which re-starts tonight on Sunday. ErnestKrause (talk) 16:19, 5 February 2023 (UTC)
Find pages matching string in pywikibot
I used the answer above to get a list of all GA subpages; that worked, and I uploaded the file to ToolForge and processed it there. I'd like to reprocess that list periodically. Since I have a record of the pages already processed, it would suffice to have a way to get pages matching a string with a creation date after a given date. Is there a way to get to such a list from within Python? Mike Christie (talk - contribs - library) 14:15, 5 February 2023 (UTC)
Modify the SQL to join with the revision table on page id, filter for rev_parent_id = 0 and put the necessary condition on rev_timestamp. – SD0001 (talk) 16:56, 5 February 2023 (UTC)
Hi. I was looking over Administrator of the Environmental Protection Agency and noticed that the thumbnail image of Bob Perciasepe was distorted, making his face look fat. I am puzzled why, and I'm not sure if this is a bug or a problem with the image metadata or both or what. I hope this problem is not browser-specific, although I fear it may be, but I see the problem in both Chrome and Firefox on a MacOS machine with a retina (high-dpi) display. The image was inserted with this syntax:
[[File:EPA Deputy Admin Bob Perciasepe.jpg|100px]]
Just like all the other images on that page.
But that's wrong, his head is too wide (on my display). It should look like this:
[[File:EPA Deputy Admin Bob Perciasepe.jpg|96px]]
We also get the wrong thing if we scale using the recommended instructions from WP:EIS:
[[File:EPA Deputy Admin Bob Perciasepe.jpg|frameless|upright=0.44]]
which takes a 200x300px image and scales it to 100x125px. But obviously it should scale to 100px150px, if it's dividing the 200px by half.
I hope this is the right place for the question, but please let me know if it's better placed at the Village Pump (or somewhere else). I'm an experienced editor but it's my first time seeking help in this way. As a temporary fix, I used the 96px version in the article. Thank you. jhawkinson (talk) 17:11, 4 February 2023 (UTC)
Weird. For me (Chrome on MacOS) the first one is distorted as you say, but the second and third look OK. Probably best to ask the technical folks over at WP:VPT? —Kusma (talk) 17:22, 4 February 2023 (UTC)
I figured out why I see something different from you: the third image doesn't have fixed px size, and my thumbnail preferences are set to a nonstandard value. If I am not logged in, I can confirm the behaviour you mention above for all images. —Kusma (talk) 17:37, 4 February 2023 (UTC)
Seems the problem is we are seeing an old version of the image (uploaded in 2013, five years before the other version). This must be a caching issue. No idea how to force the Commons to recreate the cached thumbnails. —Kusma (talk) 21:02, 4 February 2023 (UTC)
@Kusma Sorry for the delay. I do not think this is a caching issue — which resource would you think was being cached incorrectly? Or which metadata? (Is metadata cached?) Like which particular URL? As noted above, this is the image that is used, and it is properly being retrieved. I'll wait until tomorrow and then raise it at VPT. (I out-dented your last reply to make the reply blocking seems more reasonable). jhawkinson (talk) 23:41, 4 February 2023 (UTC)
The note above about a 100 by 150 image seems to refer to the old version of the image, which shows just seven stars on the flag. The current image shows ten stars, or at least partial stars, in it. I see ten stars in all of the above images. The current image is 2400 by 3000 pixels, for a ratio of 1:1.25. All of the images above are displaying (for me) at 1:1.25. Hmm.
All of that said, this is not the first time I have seen outdated images, or images that display incorrectly only at specific sizes. It would be helpful to have known good instructions for clearing out those outdated caches. Maybe Kusma's c:Help:Purge worked but took a few minutes to take effect. – Jonesey95 (talk) 05:50, 5 February 2023 (UTC)
No, it didn't work yet. An additional oddity is that the misbehaving 100px wide image above uses the (four years out of date) 200px thumbnail. I didn't manage to get a new thumbnail for 200px. —Kusma (talk) 06:59, 5 February 2023 (UTC)
I see this on my iOS devices. Whatever it is, it is interesting that the old picture is loaded when the old size is specified (100px width). Terasail[✉️]08:02, 5 February 2023 (UTC)
The problem is not resolved. To avoid browser/OS differences and confusion, it is probably best to focus on the 200px thumbnail and whether it is cropped (bad), showing 7 partial stars, or uncropped (good), showing 10 partial stars and nearly the full shoulder. That is, https://upload.wikimedia.org/wikipedia/commons/thumb/5/5d/EPA_Deputy_Admin_Bob_Perciasepe.jpg/200px-EPA_Deputy_Admin_Bob_Perciasepe.jpg (I don't think there is a way for me to inline that image in MediaWiki without generating a srcset that may render differently for different DPI displays). (At first I dismissed the caching concerns as cropping of the current image, but of course that's not right, since there's no reason the image should get cropped if it is getting stretched.)
But I still think the focus on caching is misplaced — although caches don't have expiration dates, the higher resolution image replaced the lower resolution image in 2018, 4+ years ago, that's an awful long time for a caching concern. And more significantly, the metadata used to generate the HTML that specifies the height and width are inconsistent with the image, and that is not something that is cached, as far as I know. No amount of messing with https://commons.wikimedia.org/w/thumb.php?f=EPA_Deputy_Admin_Bob_Perciasepe.jpg&w=200&action=purge nor c:Template:Regenerate thumbnail seems to be effective, see c:User:Jhawkinson/Sandbox.
It seems plausible to me that there is a bug in image selection here, that relates to the request for an explicit 100px image finding the 100px version of the image from 2013, rather than the resampling the 2400px image from 2018. Although I guess it's interesting that the problem occurs with the 200px thumbnail given that the request is for a 100px image, presumably this is a high-dpi issue and the logic gets a bit more complicated there. Although I'm not sure where that code is and how to debug it.
I suspect we could work around the problem by editing the image, but I think that would paper over the bug and prevent us from finding and fixing it, and this is surely not the only instance where this is happening, so that would be an unhelpful result. What's the right way to engage whoever understands the image selection code? I don't think I'm quite ready to file a Phabricator ticket? jhawkinson (talk) 13:05, 5 February 2023 (UTC)
When I click on both of those 200px direct links, I see 10 stars, i.e. the correct image. If you are seeing something different, either your computer has cached the image (maybe test it in a different web browser?) or something subtle is wrong on the server end, maybe one mirror server with an outdated cached image. Can you take a screen shot of the bad image that includes the full URL that your browser is accessing? – Jonesey95 (talk) 16:27, 5 February 2023 (UTC)
@Jonesey95: Definitely not a browser cache. When you say 'both' of the 200px links, which do you mean? I think there was only one, https://upload.wikimedia.org/wikipedia/commons/thumb/5/5d/EPA_Deputy_Admin_Bob_Perciasepe.jpg/200px-EPA_Deputy_Admin_Bob_Perciasepe.jpg. I'm confident it's not a browser cache issue, I've tested in multiple browsers. Anyhow, here are screenshots in both FF and Chrome: https://imgur.com/a/m0HOmSB Note that this is of the older image and show the cropped 7 stars, but the aspect ratio is fine, because that problem results from MediaWiki's misunderstanding of the image dimensions and you don't see that when a browser retrieves the bare image without a size= override. I also retrieved a copy by hand without a browser, it came from 208.80.154.240 and has a sha256 of 0c513efce857393aa97bb79296757529d375df27be03f9cf371e0c959d2a416b. Do you see something different?
Frustrating and mysterious. I don't have wget on my Mac, but I ran curl -0 'https://upload.wikimedia.org/wikipedia/commons/thumb/5/5d/EPA_Deputy_Admin_Bob_Perciasepe.jpg/200px-EPA_Deputy_Admin_Bob_Perciasepe.jpg' -k > bob.jpg and when I look at the resulting image, I see 10 stars and nice proportions. I tried to tell curl to show me the remote IP address, but my man-reading skills are too crusty. – Jonesey95 (talk) 18:47, 5 February 2023 (UTC)
I have filed a ticket, as this is pretty strange. A server must have gotten confused somehow, or accidently cached the old image under the key for the new image or something vauge like that. —TheDJ (talk • contribs) 19:33, 5 February 2023 (UTC)
Resolved Okay, it's clear from the Phabricator ticket that indeed there is disagreement among multiple load-balanced servers as to which image to use, so I think this VPT topic is effectively resolved (well, kicked up to a different resolution mechanism). Thanks, all. jhawkinson (talk) 22:51, 5 February 2023 (UTC)
Bug Report: Minerva theme disables links from { { ran } } references
I initially posted this to Phineas Gage and was advised to re-post it here.
The {{ran}} template which creates a manually anchored/named superscript has a bug on the Minerva theme used by the mobile site. You can see it if you use these links:
In each link try clicking the superscript callout links with both {{refn}} numbers[1] and {{ran}} strings[M]. In the first link, the desktop site has a tooltip and a functional link to References. The second and third links show the bug.
On the second link, the mobile site callouts for {{ran}} do nothing when clicked. The superscript callouts created by {{r}} and {{refn}} on this page will cause a popup with the reference. The popup is the expected behavior. The links from < ref >, {{efn}}, and {{sfn}} all create popups. The {{citeref}} template is slightly different and works on mobile the same way that it works on the desktop site (visible in the Notes section on: https://en.m.wikipedia.org/wiki/Computer_mouse ); the superscript works as an in-page anchor link with {{citeref}}.
In the third link, the mobile skin (Minerva) is used on the desktop site. The tooltip still works, but something in Minerva breaks the link regardless of the desktop or mobile version.
In my browser (Firefox for Mac OS), clicking on the [M] and other capital-letter links does nothing in any of the three screens. Have you tried asking at Template talk:Rma, the talk page for {{ran}}? – Jonesey95 (talk) 05:13, 6 February 2023 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
In the Vector 2022 skin, logged-out users using the full-width toggle will be able to see the setting of their choice even after refreshing pages or opening new ones. This only applies to wikis where Vector 2022 is the default. [6]
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 7 February. It will be on non-Wikipedia wikis and some Wikipedias from 8 February. It will be on all wikis from 9 February (calendar).
Previously, we announced when some wikis would be in read-only for a few minutes because of a switch of their main database. These switches will not be announced any more, as the read-only time has become non-significant. Switches will continue to happen at 7AM UTC on Tuesdays and Thursdays. [7]
Across all the wikis, in the Vector 2022 skin, logged-in users will see the page-related links such as "What links here" in a new side menu. It will be displayed on the other side of the screen. This change had previously been made on Czech, English, and Vietnamese Wikipedias. [8]
Gadgets and user scripts will be changing to load on desktop and mobile sites. Previously they would only load on the desktop site. It is recommended that wiki administrators audit the gadget definitions prior to this change, and add skins=… for any gadgets which should not load on mobile. More details are available.
Internal error whenever I use pending changes revert
I noticed that I recieve an internal error message whenever I use pending changes revert. I've never really understood why this happens or if it's just a me thing, but it happens consistently. However, despite it telling me that I can't revert the content in question, the page history always indicates that I reverted it successfully and that I was the one to do so. I can provide screenshots if nessecary but specifically it's if you click "revert changes" instead of "accept revision" on pages listed here. This doesn't happen if you use the more traditional methods of undo or rollback. Clovermoss🍀(talk)04:04, 6 February 2023 (UTC)
I'll keep you updated. The next time it happens I'll provide a screenshot. Literally the one time I think to screenshot the situation as it's happening it doesn't happen? I've seen the error message dozens of times before though so I'll likely see it again. Clovermoss🍀(talk)04:45, 6 February 2023 (UTC)
Yes, actually. That was the most recent time it happened. I haven't had it since but I've experienced it a lot before. I just usually don't do pending changes much so it was a typically "oh yeah, this happens when I do this" thing each time it happened. Did you figure that out by looking at timestamps or is there something weird about that page that caused the suspicion? Clovermoss🍀(talk)18:05, 6 February 2023 (UTC)
I just figured that out by looking at timestamps — I've also had a little look at the logs and there's nothing to suggest an internal error occurred... please do take a screenshot/copy the error message if/when it happens again! — TheresNoTime-WMF (talk • they/them) 18:13, 6 February 2023 (UTC)
Huh. Alright then. Well at least that explains it. Some of the DYKs should probably be reviewed and moved off of the page to fix the issue. ― Blaze WolfTalkBlaze Wolf#654520:19, 6 February 2023 (UTC)
Everyone with the Beta Feature enabled will see a small change to the top of talk pages (i.e., pages in talk/odd-numbered namespaces) to add information about the most recent comment.
If you're using the new Vector 2022, this will also change the new Table of Contents (to add a count of how many comments are in each section).
I think this is the penultimate update to the Beta Feature before general deployments can begin. They're still working on an extra "Add topic" button, so it won't be necessary to scroll all the way back up to the top to find that button.
I would find the "User's Contributions" facility more useful if it only showed the latest edit to any article. In fact, I can't think of a reason to see a list of 300 edits to a pet project. There must be a button somewhere but it doesn't jump out at me. Doug butler (talk) 21:16, 29 January 2023 (UTC)
On the contributions page, click "Search for contributions", check the box for "Only show edits that are latest revisions" (located under the Tag filter field), and click Search. MANdARAX • XAЯAbИAM22:23, 29 January 2023 (UTC)
I think that only shows the most recent edit, when nobody else has edited the article since then. I don't believe we have a way to show an editor's most recent edit to an article, even if another person/bot has edited the page since then. Whatamidoing (WMF) (talk) 00:55, 1 February 2023 (UTC)
I know this is going to turn out to be something trivially simple, but I can't see it... in the DATAPAC article I used sfn's for citations, and one of them is coming out "Erskine 197, p. 31" while the input text is "sfn|Erskine|1977|p=31". Why is 1977 turning into 197? Maury Markowitz (talk) 21:04, 6 February 2023 (UTC)
It seems AU was correcting them as I was looking at the page, so by the time I clicked "edit" it was already fixed. But I was still seeing the redlinks, presumably on a cached page. Amazing this works at all. Maury Markowitz (talk) 23:45, 6 February 2023 (UTC)
Template-generated redlinked categories, yet again
I've come across more than one incident in the past couple of weeks where the use of the complex wikicode
[[Category:Wikipedia April Fools' Day {{#if:
|{{#iferror:{{#time:Y|1 January }}
|{{#iferror:{{#time:Y| }}
|{{#ifeq:|{{{2}}}|error|{{error|Error}}}}
|{{#time:Y| }} }}
|{{#time:Y|1 January }} }}
|{{CURRENTYEAR}}}}]]
on old content that has existed for a few years without incident has suddenly turned into the automated generation of a redlinked Category:Wikipedia April Fools' Day 2023 that obviously shouldn't already exist in February, and even when the category does become justifiable because April Fools has arrived, it still shouldn't be containing old pre-2023 content anyway. In all cases to date I've resolved this by converting the complex if-coding to the actual year in which the content was created — but since it's obviously a silly and unproductive waste of time to even have such a thing come up in the first place, I wanted to know if there's any way to prevent this from happening at all. Bearcat (talk) 14:51, 7 February 2023 (UTC)
There are none now, because I've already cleaned up the pages that were in the category each time it reappeared at WantedCategories — but User:Tanker4390/sandbox is the most recent example I had to clean up this morning. (The others were a few weeks ago, so I'm not sure how to track them down now, but today definitely wasn't the first time the problem has appeared.) But it shouldn't even be possible for a template to generate the category before it exists (and even once it does exist, it still shouldn't become possible for the template to misfile stuff that wasn't from 2023 in it), so it really shouldn't be showing up at WantedCategories at all. Bearcat (talk) 15:05, 7 February 2023 (UTC)
@Bearcat: that page doesn't seem to have a template making that at all as you noted, it has this hardcoded wikitext:
[[Category:Wikipedia April Fools' Day {{#if: |{{#iferror:{{#time:Y|1 January }} |{{#iferror:{{#time:Y| }} |{{#ifeq:|{{{2}}}|error|{{error|Error}}}} |{{#time:Y| }} }} |{{#time:Y|1 January }} }}|{{CURRENTYEAR}}}}]]
Wikitext gets reevaluated periodically when it contains dynamic content such as "CURRENTYEAR". That text is indeed poor to leave on a page as is, as this should have no reason to be dynamically updating. It looks like after this template was substed in your example it was improved to make this better (see Template:April Fools AfD history). — xaosfluxTalk15:17, 7 February 2023 (UTC)
The condition in the code has the form {{#if:|...something which is always skipped because the if test is empty...|{{CURRENTYEAR}}}}. It always just evaluates to {{CURRENTYEAR}} so the code is pointless, maybe a remnant of a bad substitution of some template. It was made by Tanker4390[9] who hasn't edited since 2021. There is no way to prevent such red categories unless they use the same code and an edit filter is created to target it. That would only prevent future additions and would only be considered for a recurring ongoing issue which is hard to stop in other ways like just asking a user to stop, or block them if they are abusive. @Bearcat: You said "more than one incident in the past couple of weeks" but in that time I only see your one example by watching categorization. I did track down a month old removal [10] which is too old to find that way. It was also added by Tanker4390 in 2021 so I guess there is nothing more to do here. PrimeHunter (talk) 16:42, 7 February 2023 (UTC)
I'm dropped into an editor creating a new section ("Editing User:RoySmith/sandbox (new section)"). That's exactly what I would expect. https://www.mediawiki.org/wiki/API:Edit implies I can also use text= to pre-load some content but that don't seem to work. For instance:
doesn't pre-load "blah" into the editing window. Likewise sectiontitle= and summary= don't seem to do anything. What am I doing wrong? -- RoySmith(talk)16:23, 7 February 2023 (UTC)
Here is an example preload that we use on BRFA (https://wiki.riteme.site/w/index.php?action=edit&create=Create+request+page&editintro=Wikipedia%3ABots%2FRequests+for+approval%2FEditintro&preload=Wikipedia%3ABots%2FRequests+for+approval%2FInputInit&title=Wikipedia%3ABots%2FRequests+for+approval%2Ftest) — xaosfluxTalk16:34, 7 February 2023 (UTC)
Oh, my, that's an odd way to do things. I need to create a page and use that as the preload? I can see how that would be useful for boilerplate forms, but I want to generate the preload content on the fly for each request. I could use the API, but I was hoping there was a clickable link I could generate to do it all in one step. -- RoySmith(talk)16:46, 7 February 2023 (UTC)
I use WP:AutoEd for that sort of thing, adding parameters to the URL which a script called by AutoEd can parse. For example, User:Certes/replace.js does replacements, such as ...&re1from=2022&re1to=2023. It does involve an extra step of invoking More→AutoEd by hand once the page has loaded. Certes (talk) 18:01, 7 February 2023 (UTC)
This is a hacky solution, but it seems like you can use the preloadparams[] url parameter along with a preload page that just echoes out the variables in the params.
If the link is made with wikitext then fullurl: and urlencode: is cleaner and more portable with the same result.
[{{fullurl:User:RoySmith/sandbox|action=edit§ion=new&preloadtitle=Title&preload=User:DVRTed/sandbox/PreloadParam&preloadparams%5b%5d={{urlencode:Your text here}}}} Preload link]
Pretty simple proposal here, and this is my first ever interaction with the Village Pump believe it or not, so please ping me with important/relevant responses, I am seldom, if ever here.
I revert a lot of vandalism, and have advanced tools for that, such as AntiVandal created by user:Ingenuity and Rollback etc. etc.
All my proposal would be though would to change when an "undo" button appears on a page. I would suggest that the undo button NOT be displayed if/when intervening edits have already been made, instead, a button might say "manually edit" or something. This would indicate to any editor that an edit has already either been reverted, or the more likely event in many cases, that other subsequent edits have been made by the same or another editor—in which case a manual revert might be necessary, or manual edits instead of the simple clicking of the button that says "undo." I think that it would be really nice to know before clicking that an edit has already been undone, or followed by other edits. Either of those cases don't matter, all that matters is that if you click "undo" you have just wasted a few seconds when you then need to actually manually edit. Not a big deal once, but added up, this collectively must amount to thousands and maybe millions of seconds, which in turn is lots of hours of our editors time.
Please let me know if the above makes sense. I am hoping my proposal is clear and non-controversial. TY —Moops⋠T⋡21:26, 7 February 2023 (UTC)
@Moops This is not the place to make proposals, this is for technical help. WP:Village pump (idea lab) and WP:Village pump (proposals) (VPR) are the places for proposing changes. Idea lab is for brainstorming ideas and proposals is for actually proposing a change. However instead of WP:VPR, Phabricator might be a better place to request this, as a feature request. Just to note, the undo button is available on multiple revisions and not just the most recent one since if there are no conflicting intermediate revisions, then edits made previously can also be undone (People do use this feature). Terasail[✉️]21:38, 7 February 2023 (UTC)
My apologies. As I said, my first time here at the village pump. Any way that I could have me question plopped in the right place? I would not object to you moving it if that is easier? Also, if there are no conflicting intermediate revisions then the undo button is fine and available, I am really mostly interested in removing only when that is not the case, and thus when you would get a red text error message upon when you would hit the undo button. TY —Moops⋠T⋡21:41, 7 February 2023 (UTC)
@Moops: It would require changes in the MediaWiki software used by thousands of wikis so it could not be decided or done here at the English Wikipedia. It might be possible to build support to try to convince MediaWiki developers to make a new feature but this one was declined at phab:T34779 as too expensive. Every diff in the page history would have to be analyzed in comparison to the current revision to determine which of them can be undone. We did get the "reverted" tag in 2020 but it has a much simpler task of finding identical revisions, not analyze diffs. See Wikipedia:Bug reports and feature requests for making MediaWiki requests. PrimeHunter (talk) 22:19, 7 February 2023 (UTC)
Interesting. Can my question be cut and dropped there then? It does seem like it might be an effort to implement to be sure, but my hope is that the Wikimedia foundation would be able to help fund that sort of thing, no? They seem to have a lot of funds, but most all of us are just volunteer editors, and it would be nice to not see undo... when an edit cannot be undone. :) —Moops⋠T⋡22:22, 7 February 2023 (UTC)
@Moops: It's not just about implementing the feature but using resources on all servers with MediaWiki every time a page is edited. MediaWiki is developed by the Wikimedia Foundation but used by lots of unaffiliated organizations and people. The feature was declined in 2011 and computers do get faster but I doubt this would be considered worth the resources. The annual meta:Community Wishlist Survey is the ultimate method to convince MediaWiki developers to implement something but it requires a lot of support and the 2023 submission window has just closed. PrimeHunter (talk) 22:43, 7 February 2023 (UTC)
An efficient partial solution is a bit of local JavaScript to blank the Undo link when the Reverted tag appears on the same edit. There will still be situations where Undo appears but doesn't work, but it'll catch simple recent changes. Certes (talk) 22:51, 7 February 2023 (UTC)
"Can't import file because at least one of its file revisions is hidden."
This is "technical" to me, but I don't know if this is the correct place for this issue.
I get this message- "Can't import file because at least one of its file revisions is hidden." If possible, can someone help import this image to Commons. It is a file from the late Wikipedian, User:Ronhjones which may be more useful as it is now in the Public Domain. Thanks, -- Ooligan (talk) 21:56, 7 February 2023 (UTC)
@Ooligan previous version restored. You should be able to import to Commons now. Information needs re-adding as that was lost when the NFCR template was removed. Nthep (talk) 22:11, 7 February 2023 (UTC)
I have imported this file into Commons and added categories. Thank you for your quick help. With appreciation, -- Ooligan (talk) 23:13, 7 February 2023 (UTC)
Huge blankspace below edit interface by CX Zoom 20230203
As can be seen in the image, something happened recently, that added a huge blankspace below the editing interface on 2017 Wikitext editor with syntax highlight enabled. No issue with sytax highlight disabled. As I type this, the blinking insertion point is auto-adjusted on the top of the page, which means that you can't see the line just above. It is impossible to select a piece of text because as soon as you click any point on page, the page the insertion point jumps 17 below and selects whatever is there. In case you're trying to select something less than 17 lines from the end of page, it just goes into the blankspace where nothing else is visible. As usual, I'm on MS edge on Windows 11. —CX Zoom[he/him](let's talk • {C•X})21:52, 3 February 2023 (UTC)
Never mind, I see from the URL in the screenshot that you were in safemode.
I can't reproduce this in Chrome on my Mac. Is this happening on every page, or just this one? (I assume that it's all the pages, but I thought I'd check.) Can you scroll up? Whatamidoing (WMF) (talk) 20:34, 6 February 2023 (UTC)
To force source editor you should be able to use '&action=submit' which should guarantee the source editor. (Info from here). The use of '&veaction=edit' is for overriding source editor and forcing the visual editor. Terasail[✉️]20:07, 7 February 2023 (UTC)
&action=submit forces one of the older wikitext editors. You won't get the 2017WTE with that code. &veaction=editsource opens the 2017WTE when you have VisualEditor's two-tab mode set and the 2017WTE enabled instead of the default 2010WTE. Whatamidoing (WMF) (talk) 01:17, 8 February 2023 (UTC)
Thanks. When I can get it to load without an empty space for the TOC, then I have fewer problems, but I don't seem to have a reliable way to make that happen. I've filed a bug report, and you're of course welcome to change what's there and/or add your own comments. Whatamidoing (WMF) (talk) 01:19, 8 February 2023 (UTC)
Asking for help from volunteer programmers for TOC
Hello from el.wiktionary. For some time now, I thought that the ToC (Table of Contents) does not have parameters needed to serve better the needs of dictionaries. I know nothing about computers, so, I am asking for help of volunteer programmers.
My understanding of a ToC, whether it may some day also appear at a side menu (as we learn, by WMF) or not, is that it is under the responsibility and discretion of editors to formate, not the 'typographer' (the skin) who may add it also somewhere outside. That is: it belongs to the body of the page. Which is why, there is a toclimit choice, a choice to place it right (TOC right or left, at some projects, etc). We assume that full numbering (1.2.1, 1.2.2.,...) is in place, and no hidden titles, as certain wiktionaries use under + or arrows.
There are thousands of wikt.pages, where a horizontal presentation by language would be more suitable than vertical. Pages with 2-5 languages, or as the editor or administrators see fit. Also, when toclimit2, a horizontal presentation (example). Note, that in wiktionaries the names of h3, h4... headings are standard and repetitive (WT#ListHeadings).
In my naïveté and "pure ignorance" I tried to see how it might look at wikt:el:Template:test-ol - compare vertical with vector), and wrote the way i think of it at a plan-test. I do not know how to ask a module to 'read' the page, find the titles, and put them in a row (arrary is the word?). A module, because we do not have 'interface administrators' to edit common CSSes and place gadgets. But if possible, a standalone way to do it.
If you know someone, from any project, that might help us, it would be great! Thank you so much, for your much appreciated support to small wiktionaries. —(Central)Sarri.greek (talk) 08:30, 8 February 2023 (UTC)
Thank you, Jts1882, these are alphabetical or numeral Content templates, it's ok, we know how to make them. It is a module equivalent to _ _TOC__ that we do not see anywhere. Sarri.greek (talk) 10:58, 8 February 2023 (UTC)
Translation tool removing references
Hi, I was referred here. Ever since I used the new Wikipedia translation tool in an effort to help, I keep getting alerts regarding the page Phoenixx (now Draft:Phoenixx). The tool removed all of the reliable, third party, independent (albeit mainly print, which the reviewer apparently didn't like) citations that were in the Japanese version of the article. While I'm sure I can find more to add next time I have time, I do not like that this page that I translated on a whim is becoming a burden to me, and it makes me not want to use the tool (or even really put any effort into the page) again as a result. It's also become a lot harder to find the link to connect alternate language versions of pages for manual translations since this tool was added. Can someone please fix this issue with citations in the tool? In case anyone isn't sure what tool I mean, here is an example:
https://ja.wikipedia.org/w/index.php?title=Special:ContentTranslation&from=ja&to=en&page=STOLEN_SONG#suggestions
Yes, it removed the citations that were in the original article. They were not ones that I added, but I had no reason to expect they would disappear. Re: alternate language versions, yes it does. What I am saying is that I prefer the old way of manually making the new translated page and then using the link that was once in plain view on the sidebar before to connect the two. The new tool is a hassle, and I don't like that it is being pushed as the new way to handle page translations. Londonbeat41692 (talk) 00:02, 8 February 2023 (UTC)
The content translation tool has the advantage of always getting the license attribution right, and it seems to be pretty popular. Of course, if any individual doesn't like it, then there's no requirement for that individual person to use it.
Looking at the edit history, the problem is that he translated sentances which had an named reference, without defining the source itself, that is elsewhere. So, the request is that the reference with the source gets moved to the named ref.
Example, the lazy dog sentance gets translated, not lorem ipsum, lorem ipsum ref should be copied over (nowiki added for clarity):
The quick brown fox jumps over the lazy dog.<ref name='example' />
In the new skin it is impossible to select a few characters from the first unspaced term in the title (H1) of a page, on pages in Template and Category namespaces. This is not the case with the old skin.
For instance, on the page Category:Star Trek television series
If one wants to select "Star Trek" by click-and-drag over selection, this is impossible. The entire "Category:Star Trek" would be selected instead. This makes select and search with your default browser search engine somewhat annoying, as to having to search twice, by deleting the extraneous term on the second pass. Or even plugging it back in to Wikipedia's search box, as you'd need to remove whatever extra characters were forcibly included in the selection.
Hmm, I can't replicate this problem. I have plenty of other problems with Vector 2022, but not this one. We need more information about your browser and operating system. – Jonesey95 (talk) 06:11, 8 February 2023 (UTC)
I can replicate this problem, on Firefox and Chrome, logged out as well. Only on vector-2022. As an immediate workaround select the text from right to left. It looks like there may be an overlap on what element is being presented only on base Category pages? Note: this has nothing to do with DISPLAYTITLE. — xaosfluxTalk11:24, 8 February 2023 (UTC)
This could have something to do with the fact that logged out users are served with differet page than logged in users. As I have previously mentioned at phab:T328509, it can cause minor differences with pages which are hard to catch. The difference is that "mw-body" is display:grid for logged in users and display:block for logged out users as well as other minor differences related to this. I assume that this error is related to this difference aswell but I haven't checked fully.Terasail[✉️]12:38, 8 February 2023 (UTC)
Answer: This is caused because there is an invisible nav element (#mw-panel-toc) which means that you can't select text underneath it properly. Do with this information as you like. Terasail[✉️]12:49, 8 February 2023 (UTC)
I was wrong, this is an issue for both logged in and logged out users, the issue is the empty toc box though. (I had my side panel open and didn't see it) Terasail[✉️]13:25, 8 February 2023 (UTC)
I'm seeing it on Star Trek Star Fleet Technical Manual while logged out. When I am logged in, this custom CSS seems to prevent the problem (I needed to insert this because the background color I assigned to the TOC sidebar was overwriting the title, even when there was no TOC on the page):
This is the default behavior when the JavaScript that makes Thanks go fails to load in time for when you click "Thank". Izno (talk) 16:51, 8 February 2023 (UTC)
Nothing? If there's reasonable content on the page, and the target of the redirect doesn't closely match the scope of the redirect (as in this case), you just leave the talk page alone. You can/should remove article assessments that are no longer true, but that's about it. Izno (talk) 16:52, 8 February 2023 (UTC)
(edit conflict) "It depends". You could move it, merge it, redirect it, leave it, link to it, etc. What is best to do depends on what the discussion is about. All of those have different technical mechanisms. — xaosfluxTalk16:55, 8 February 2023 (UTC)
Hadn't thought of some of those, thanks. If there's no relevance to the redirect, as User:Izno, who's cleaned it up, points out, it's pretty useless. I keep running into them on my Watchlist so now I know what to do! Doug Wellertalk17:03, 8 February 2023 (UTC)
Red underlines search bar
Apologies if this is already been mentioned somewhere else. Today, I've begun seeing red underlines under words in the searchbar ala spellcheck when on desktop. For instance, when trying to search for something outside of mainspace, it freaks out because of the presence of the colon between words. Is this something with my browser, or is this a new "feature"? Hog FarmTalk17:01, 8 February 2023 (UTC)
In Vector 2022, if you press Alt+F to bring up the Search bar, type a query, and press Enter, instead of being directed to the typed title as desired, you are taken to the suggestion that happened to be under the pointer and became highlighted, even if the pointer was never activated during the search. Has this been reported as a bug? (Sorry but I still can't make sense of Phabricator.) --Paul_012 (talk) 08:17, 9 February 2023 (UTC)
I just opened T329299 about a problem with reply tool losing data which looks like it started happening this morning. Has anybody else seen this? I'm not 100% sure I know how to reproduce it, so if you've got any better ideas, please update the phab ticket. -- RoySmith(talk)15:54, 9 February 2023 (UTC)
Wow. So it turns out the root cause is User:DaxServer/Mark-locked.js. An extra special thank you to @TheDJ for tracking that down. If you run Mark-locked.js, you'll want to read the phab ticket and possibly disable the script before you get bitten like I did. -- RoySmith(talk)21:25, 9 February 2023 (UTC)
woah, hold on. I didn't say it was the root cause. I can't 100% determine that. But it definitely contributes to a problem like this and should be fixed. —TheDJ (talk • contribs) 21:31, 9 February 2023 (UTC)
I don't see that, the only issues I have with the tools sidebar is the Atom link is over the icon and the edit interlanguage links link isn't well formatted. Terasail[✉️]21:38, 23 January 2023 (UTC)
I wondered if it is some script doing these, but then I used safemode and it still shows up like this. Idk somethingis wrong with whatever they did. It was all fine 1 hour ago. —CX Zoom[he/him](let's talk • {C•X})21:41, 23 January 2023 (UTC)
I was just working on Jane Austen and it suddenly shrunk down to nothing!! Now the infobox and the two columns w/ tools appear wider than the lead text. This is 100% (not zoomed), 13 inch screen, set at 1280. Not an improvement. Victoria (tk) 21:50, 23 January 2023 (UTC)
Some options until the WMF cleans up a variety of whitespace and font size problems are to switch back to Vector 2010 (Preferences -> Appearance -> Vector 2010 -> Save), hide the Tools sidebar (which will make it move to a menu at the upper left), or customize your vector-2022.css file (scary if you are not a geek). – Jonesey95 (talk) 22:08, 23 January 2023 (UTC)
Thanks, Jonesey95, I've hidden the tool bar but it seems to need hiding w/ every page refresh, plus the other issues mentioned in this thread. I know I can change back, but have been giving V22 a test drive. There are some things I like about it and I've spent the past few days trying to get my eyes used to it. I posted the screenshot so the devs can see what a random laptop user who doesn't have access to prefs etc sees. It's not great. Pinging AHollender (WMF). Is this what you all have in mind for MacBook users? Victoria (tk) 22:21, 23 January 2023 (UTC)
If you collapse any menu, then it should save when you refresh the page. If your connection is being slow or you are expanding it in another tab there's a chance it's not working as expected. Can you try collapsing it, waiting 5 seconds then hard refresh the page? If this is still happening let me know and I'll look into this more first thing tomorrow. Jdlrobson (talk) 01:33, 24 January 2023 (UTC)
Hi Jdlrobson, thanks for the reply. Yes, it's more persistent now than it was. But it seems to depend on namespace. I.e if I have everything collapsed (including TOC) to get a decently sized text column, that doesn't persist from article to article. Furthermore, edit mode is full width (which is really really nice!), but preview isn't persistently in full width - I just ran into that on Maxfield Parrish where I was moving around images - some of the previews were in full width w/out TOC, others w/ TOC and w/ the narrow text column.But all that aside, the biggest concern is that on a laptop the text column is absurdly small (I've since changed screen res to 1440, but w/out much effect); the infoboxes are huge and images are squashing out text. I have the luxury to set preferences, to fiddle, and to play with to get it right. A casual reader logged out reader won't. Victoria (tk) 01:50, 24 January 2023 (UTC)
Adding, in this edit the edit window was the size of the small text column, though TOC and tools were collapsed. As I'm typing this the edit window is the width of the screen. So the sizing isn't persistent. Victoria (tk) 02:10, 24 January 2023 (UTC)
Now the opposite is happening. In article space the edit window is about 150% or more too long - about one to two pages long w/ only a portion visible. I zoomed out to 50% and still couldn't see the entire edit window. The same behavior is not happening here on this page. Seems to be only be this section on this page. Weird. Victoria (tk) 22:07, 26 January 2023 (UTC)
The icon next to the atom link overlaps with the link itself. This happens on pages that have feeds, like user contribution pages etc. —TheDJ (talk • contribs) 21:51, 23 January 2023 (UTC)
A bit more details, as well as more upcoming changes are available in this post on the RfC page.
Hey everyone,
Thank you all for continuing the conversation on the new skin and reporting thoughts, issues, and bugs as you come across them. Today, the new page tools menu was deployed to the Vector 2022 skin for logged-in users. This menu allows for a separation between navigation that is related to the entire wiki (Main page, random page, etc) and tools that are related to a specific page (what links here, related changes, cite this page, etc). It also collects all page-specific tools in a single menu, rather than splitting them between the main menu and the more menu. More information is available on the project page. Moving this menu to the right side of the page has the benefit of showing the table of contents further up the page without requiring people to scroll down to see the table of contents. We’ve noticed that this is one of the concerns we’ve been hearing over the last couple of days and hope this addresses it.
Let us know if you have any questions or experience issues with the tools menu. Thank you @CX Zoom, TheDJ, and Terasail: for reporting the menu doesn’t work with the Content Translation beta feature on the Contributions page - a quick fix for this will be available tomorrow morning. In a few weeks, we also plan to make the pinned menu sticky, just as the Table of Contents and the left menu.
The new tools menu appears to be creating a bug for me on some disambiguation pages, eg. ¿Dónde está Elisa?, where a large black space appears matching the vertical space taken up by the "Actions" tools. It does not appear on incognito, which suggests it relates to the tools. It also does not appear for every disambiguation page, as far as I can tell it appears on shorter disambiguation pages, pages like French are unaffected. CMD (talk) 05:05, 24 January 2023 (UTC)
Preview is currently broken when editing using 2017 wikitext editor (I don't edit using 2010 wikitext editor because it lacks keyboard shortcuts which is required for my day-to-day editing of which I got so used to using keyboard shortcuts (embed into my mind) that I can no longer move away from). I have tested with or without safemode on various namespace (main, talk, template), both yields the same results where the entire page content would be flushed entirely to the right side of the screen, leaving a huge chunk of whitespace on the left. — 🍊 Paper9oll 🍊 (🔔 • 📝)07:13, 24 January 2023 (UTC)
Update: This issue is caused due to the coding changing to use rubbish CSS grid instead. Forcing .mw-body to use display: block!important fixed it but is rather a makeshift fix only which of course requires editor that uses 2017 wikitext editor to add the css styling to their common.css. — 🍊 Paper9oll 🍊 (🔔 • 📝)12:20, 24 January 2023 (UTC)
@Modern primat, how were you previously finding the village pumps here at the English Wikipedia? Commons has a link in the sidebar for both Vector 2010 and Vector 2022, but the English Wikipedia doesn't, and hasn't for many years. Whatamidoing (WMF) (talk) 18:55, 25 January 2023 (UTC)
There's a link on the Main Page, in the section "Other areas of Wikipedia", and similar links on other high-traffic pages. I think most experienced editors just search for the name in the search bar. Whatamidoing (WMF) (talk) 19:28, 25 January 2023 (UTC)
Hidden code in Vector showing when a Wikipedia page is linked in the Discourse app
Since the transfer to Vector, a hidden code about « not-logged-in editors » is showing up when a link to a Wikipedia article is linked in the Discourse message board app.
See the discussion here on the Straight Dope Message Board:
The vector-2022 menu ("..." menu in the top right corner) does contain that label, and the rendered page does include:
<divclass="vector-user-menu-anon-editor"><p>
Pages for logged out editors <adata-mw="interface"href="/wiki/Help:Introduction"aria-label="Learn more about editing"><span>learn more</span></a></p></div>
I prefer to keep the table of contents hidden when using Vector 2022, but I have to hide it every time I load a new page. Is there a way to have it hidden by default? If not, is this planned in the near future? Thebiguglyalien (talk) 19:16, 26 January 2023 (UTC)
horizontal scroll bar in diff view with vector2022 when there is a long word
When viewing this diff with the vector2022 skin, the page width is extended to accommodate more of the lengthy URL that was added in the edit, resulting in a horizontal scrollbar. This happens for me in both the visual diffmode and the source diffmode. Viewing the diff with the vector skin, the page width is kept to the browser width and so no horizontal scrollbar is added. When I edited the section to hide the long URL, the edit screen was also wider than my browser width, including the edit box. To the vector2022 development team: can the page width be limited in this scenario to not exceed the browser window width? isaacl (talk) 23:11, 26 January 2023 (UTC)
@Isaacl I don't seem to be getting that problem on a logged out account - any chance you have something else pushing it over? If you do scroll to the right, what is over there? — xaosfluxTalk23:18, 26 January 2023 (UTC)
I'm not seeing this issue either in an anonymous browser window. Do you see it when logged into your account? I see the rest of the page when scrolling to the right: the Wikipedia page is being rendered across the entire extended width of the page, making it hard to read the page or see the diff. I'm not using any gadgets or features that add widgets to the page, as far as I recall. I have the main sidebar collapsed and the table of contents sidebar enabled, but toggling those doesn't change the overflowing page width. isaacl (talk) 23:58, 26 January 2023 (UTC)
A discussion on SGrabarczuk's talk page revealed that the problem should be resolved, and when I checked the diffs again, I no longer see a difference in the behaviour between Vector 2022 and the original Vector skin. Thanks to the design team for fixing the issue. isaacl (talk) 21:43, 6 February 2023 (UTC)
Vector 2022: CSS: RSS feed icon overlapping text due to 0px left padding
Have a look at my contributions page Vector 2022 and Vector skin, notice that in Vector 2022, the RSS feed icon overlaps with the text "Atom", which is not the case for the original Vector skin. (You can see the comparison here if you just want a quick look)
Cause
Vector 2022 does have a left padding styling of 16px for the feed link as shown in the CSS:
However, this padding is not taken into effect (confirmed by my browser developer tools) due to this styling with more specificity than a.feedlink (specifically, this selector applies: .vector-pinned-container .vector-pinnable-element .mw-list-item a):
No, that's completely unacceptable. (a) If you need to mark the format in the URL to keep the anon readers happy, it should just be a new format replacing the /wiki/: /w2/, /ow/, /wbetter/ &c. (b) Even if you need to keep the index.php cruft and put the oldformat marker on the tail end, it shouldn't be in the middle of the page name. Editors need to be able to quickly copy/paste the page names with the section tags to create links.
Was anyone on this redesign ever involved in actually editing Wikipedia? If not, can we scrap them and get them replaced by people who know how this works and why it's been so successful for decades? — LlywelynII15:25, 29 January 2023 (UTC)
Vector 2022 only showing red links someplaces blue links elsewhere
Some time ago I had User:Stuartyeates deleted. When Vector 2022 was launched, I discovered that some links to User:Stuartyeates are red and some are blue. The two links circled in red in the attached screenshot go to the same place, but one is red and one blue. The appears to be consistent behavour for me for weeks. Do I have some odd setting enabled or is this a bug? Stuartyeates (talk) 03:58, 31 January 2023 (UTC)
@Stuartyeates: It's a deliberate feature of Vector 2022 that your userpage link at top of pages is always blue. phab:T312157#8132005 says: "IIRC the thought process was the user page and red link for contributions might be discouraging as red is associated with error and doing something wrong and both of these pages have information of value." PrimeHunter (talk) 05:48, 31 January 2023 (UTC)
@Stuartyeates for what it's worth unless you are really just trying to make a point that redlinked userpages are super cool, making your userpage a redirect to your user talk page is generally better for many things - including communicating with newer editors. — xaosfluxTalk14:48, 31 January 2023 (UTC)
@User:Xaosflux The point is not that consistency is an important part of design (including web design) because it is one of the key factors that make it easy to understand a design (make it 'intuitive'). Stuartyeates (talk) 18:07, 31 January 2023 (UTC)
I've just discovered that this (or a similar issue) also impacts whether links in the 'tools' menu ('What links here', 'Wikidata item', etc) change colour once visited, deliberately undermining uswful browser functionality. Three times I've been tripped up by this. Stuartyeates (talk) 18:58, 6 February 2023 (UTC)
That's pretty normal, as elements like a and a:visited are commonplace in browsers. If you want to make both of the same colour even when the page has been visited, just set the color parameter to the same colour in your personal CSS. —Tenryuu 🐲 ( 💬 • 📝 ) 20:08, 6 February 2023 (UTC)
Why does the tools column on the right not keep position while scrolling like the TOC? Every time I scroll down I get a return of the massive blank space. ~~ AirshipJungleman29 (talk) 16:42, 31 January 2023 (UTC)
Persistence for fixed width for all users coming this week
Hey everyone,
the Vector 2022 skin's fullscreen toggle
TIt’s now been almost two weeks since the Vector 2022 skin has been live as the default on English Wikipedia. Since implementing the change, the Web team has been focused on identifying issues, fixing bugs, and replying to community concerns. The most commonly heard concerns so far were around the availability of the fixed width toggle. Last week, we made a change that allows the toggle to show at the lowest possible width where it can have an effect (1400px). This means that more users will have the options to toggle the width on more pages.
This week, we will be adding persistence for the toggle for logged-out users, starting this Thursday, February 2. This means that all users will see the width setting of their choice despite refreshing pages or opening new ones. For those of you interested in testing the change ahead of time, it is already available in our testing environment.
More details on the change and its technical implications for the future are available on the RfC page. We also encourage you to bring your thoughts to our next office hours: Thursday, February 2 at 20:00 UTC (click here to join / dial by your location). We will be reviewing and discussing different community requests so far, and answering general questions about the skin.
Thank you. This problem is being dealt with much more quickly than I was expecting, and I have hope that the pace won't slow in responding to other concerns. Still, this should have been fixed before the skin was pushed upon readers. small jarstc22:44, 31 January 2023 (UTC)
True. Please see T326887, where I commented on January 19 that I did some experimenting with my window width, and without the sidebar or TOC showing, the toggle would remain useful down to about 1100 pixels, at which point the (IMO still excessive) left and right padding CSS becomes the only white space that matters. I uploaded screen shots. Feel free to upload some of your own; maybe you will be more persuasive than I was. – Jonesey95 (talk) 06:14, 1 February 2023 (UTC)
These two changes are/will be awesome and fix pretty much all my issues with the new skin. I'll get used to a little increased white space around the margins. Thank you! 199.208.172.35 (talk) 19:58, 1 February 2023 (UTC)
On some pages the infobox can obscure the tools menu
On Bipyramid the main info box overlaps the tools menu. I think this is caused by another overwide table below changing the width of the main text. I did quite like tools window on the left.--Salix alba (talk): 05:27, 1 February 2023 (UTC)
Hi @Salix alba - thanks for the report. Could you let me know what browser and operating system you are using? Also, could you let us know if adding the ?safemode=1 parameter (this link) removes the issue for you? This will help us know whether it's an issue with the setup, or potentially with a gadget you're currently using. OVasileva (WMF) (talk) 14:49, 2 February 2023 (UTC)
I have notice that the Wikipedia has changed its look. The main change I am concerned with is that the Table of Content is on the side. If you wish to print a page using the print/export tool, the table of content (TOC) is not included. Is there a way to include the TOC in the print/pdf? Theophilius (talk) 14:42, 5 February 2023 (UTC)
Apparently, this is a deliberate non-feature. My bug submission was closed as a duplicate of T306719, entitled "Hide TOC in print mode (Vector 2022)". Here's a link to a brief discussion in which a few editors said "it depends" and one editor explained how it is helpful. It looks like you may have to enable User:TheDJ/Print options. – Jonesey95 (talk) 00:34, 6 February 2023 (UTC)
Vector 2022 not designed for those with advanced privileges
Since the rollout of the new skin, we have read a lot of comments about the new location of the login button. Initially, we had placed the login button behind a menu so that we can draw attention to the account creation workflow, and because logging in is a fairly infrequent action. However, due to current issues with the global authentication system (which requires people to log in more frequently than expected), as well as the number of concerns we're heard here and on the Technical Village Pump, we've revisited this and moved the log-in button outside of the collapsed menu and as a link on the page itself, as in the Vector legacy skin.
This means that now the login button will return to being accessible with just one click.
I saw this the other day and it struck me as so extraordinarily insulting that I feel compelled to write a very honest piece on how little thought you and yours apparently put into this decision, particularly in light of the above comment(s).
I am an 18-year veteran of the site. I have earned the privilege of leading one of the most innovated WikiProjects on the English Wikipedia, started several initiatives which have since been copied by other projects, introduced the first version of the now site wide standard issue ship template for both class and individual vessels, standardized the format for A-class reviews which have increased the likelihood of our project articles clearing FAC with minimal opposition, and along the way earned a position as Coordinator Emeritus due to the respect and innovation I have engendered among my project's members - both readers and coordinators.
In the course of earning this respect I also earned from the Wikipedia community a set of higher privileges: I am an administrator. One of only a few hundred on this site who are active. One of a shrinking number of people who are entrusted with closing reviews, blocking users, promoting consensus, deleting articles, and protecting pages from would be vandals and our more overzealous contributors. For me, logging in is NOT a "fairly infrequent action", its a daily or weekly action (depending on work schedules). I have been told in no uncertain terms by both the foundation AND the Arbitration Committee that I need to be especially cautious with this account because of the admin rights granted to it. I need a strong password. I am encouraged to use two factor authentication. And part of the responsibility that comes with this account is ensuring that when I'm not parked in front the computer others who may have more nefarious designs for pages can not access admin tools from my account and reek havoc across this site. I, therefore, am one of hundreds of people who do not have the ostensible luxury of leaving their account logged in on a 24/7 basis, and for you to assume this speaks very poorly to your understanding of and respect for the responsibility that come with an account that holds a higher set of privileges on this site.
I therefore deeply resent the notion of the double standard inherent to the above comment, that after being barked at by both the Arbitration Committee AND the Wikimedia Foundation at large you would turn around and ispo facto presume that removing easy access to the login button would not be a big deal to contributors like me "...because logging in is a fairly infrequent action". On the contrary, responsibility dictates that I NEED to log out when I am done on here to ensure the admin tools remain mine and mine alone, and I do not want to spend hours and hours looking for a button I've never had to look for before because some short sighted fool thought hiding it would be better so as to "...draw attention to the account creation workflow...". Not withstanding this obvious insult, I don't want to have to relearn where everything is all over again while logged out in order to catch the attention of my fellow admins or to do the admin assistance work I do on site (checking copyvio complaints, looking at URL references, assessing notability issues, etc) without immediately logging in. Your claim in rolling this monstrosity out was that it was done "...by the Wikimedia Foundation Web team with the goal of making the interface more welcoming and usable for readers and maintaining utility for existing editors." It hasn't done any of that, and if I have to look for something that was once so easy to find then obviously you've missed the marked by a very wide margin. Google, the #1 website in the world, hasn't changed its format at all in the 30 or so years its been running, and its getting rave reviews for exactly that reason. If they can do it, so can we - if you have courage to take a hands off approach. TomStar81 (Talk) 17:18, 5 February 2023 (UTC)
Acceskeys for own talk page and contributions in Firefox
MediaWiki provides keyboard shortcuts in the form of accesskeys. For example, "N" is the accesskey for the user's talk page, and "Y" is the accesskey for contributions Special:MyContributions. These two accesskeys do not work in Vector 2022 in Firefox. It seems to be caused by the fact that they are hidden under the menu. They work in Chromium, though. —andrybak (talk) 19:58, 5 February 2023 (UTC)
I think that should be worked around somehow – having accesskeys is rather pointless when you first need to click to open a menu in order to use them. I've created phab:T329318 for this. Rummskartoffel17:46, 9 February 2023 (UTC)
Problematic new "features"
@OVasileva (WMF), SGrabarczuk (WMF), and Patafisik (WMF):
I've been trying out the new vector, both logged in editing and logged out as a reader, and there are a few things not to like at the moment. I'm trying very hard to use the new skin, but its deficiencies at the moment outweigh the benefits in a few key areas. These are not things that should be fixable with a script, but points that affect both editors and readers that should be looked into more closely and hopefully changed:
the default to a narrow view is problematic. Studies may show shorter lines are easier to read, but people have their monitors or windows set to what they personally like, and the WMF shouldn't try to double guess that: let the article flow to 100% of page width, because people will have already adjusted their window to what they want – not you.
the lack of user links in the top right is a huge mistake – having talk, sandbox and contributions hidden in a dropdown is a backwards step. Why should anyone need to now have to double click for simple links when previously it was available on the page?
Having those top-right links as words, rather than icons would also be a huge benefit: icons mean different things to different people, while the words Talk, Sandbox, Watchlist and Contributions are much easier to identify. I have two degrees, run two companies and am a member of Mensa International, but I still have actively think about which icon means which link: that's poor design.
The 'drifting header' feature is a partial pain – click from another page onto a section and the drifting header covers both the title of the section and the edit button, so on talk pages, users have to scroll slightly to get the section name and edit link. This is something that should be fixed asap.
At the top of an article (one scrolling down the page), the block of links to other languages is dominant and unnecessary. That's a dropdown that should be on the left-hand menu. This is English WP: people are here because they speak English and don't need a link to all other languages to follow them down the page. It's particularly notable given this is the only bit on the top right that appears in words (big and bold), so acts as a distraction to reading the text: bad for readers, so get rid of it.
The bolding of sections in the left hand menu while reading an article is a complete distraction. When I'm reading and scrolling down, the bolding moves and my eye automatically flicks over at it, disturbing my reading – that's very poor.
These are not just issues to be faced by logged in editors (although you really need to take that into consideration), but for logged out readers too. While I'm trying to like the new version (and there are some advantages to it), I'm struggling to get over the obvious downsides built into it. I can see myself reverting to the previous version shortly if this isn't improved. – SchroCat (talk) 21:12, 7 February 2023 (UTC)
So you think—for example—that a floating headline should cover the title end edit button of the section it’s supposed to highlight? It’s an interesting stance. You prefer to do two clicks of a mouse to see your sandbox or contributions? You honestly think that it’s advantageous to have a language tab following people down the page? Really? I’d like to hear your rationales on each of the advantages to the queries I’ve raised. SchroCat (talk) 00:54, 8 February 2023 (UTC)
@SchroCat, can you explain what you mean with #4? I assume that you mean you're clicking on a direct link to a section like Cancer#Epidemiology. When I click that link (Safari/macOS), I see the floating header followed immediately by the ==Epidemiology== section heading, with the usual section editing buttons. After that I see Main and See also templates, and then the image and the first paragraph of the section. It sounded like you're not seeing the section heading. Is that right? Whatamidoing (WMF) (talk) 01:04, 8 February 2023 (UTC)
Thanks @SchroCat. I'm glad to read that you've tried to test the skin. I also appreciate the effort it took to write all that. It's interesting that you're pointing at these very issues. I understand that these are your personal preferences, and I'm sure you may configure some bits. Have you perhaps tried to explore our documentation about Vector 2022? I encourage you to take a look! Here's like everything important in a nutshell you may skim through.
Regarding #3, we've announced this here on VPT in November: "In our user testing, users did not experience issues with any of the available icons with the exception of the contributions icon in the user menu, which is accompanied by a text label. A/B testing of the sticky header further showed that the icons in the header are recognizable. (Use of the sticky header decreases scrolling by 15%. Edits from the edit icon have higher completion rates and lower revert rates than edits started with any other edit link or button on the page, even though the edit icon isn't accompanied by a text label.)" I'm not sure if we can add anything to that.
Regarding #4, this should not be happening, and does not happen to me. But perhaps this is because of your settings or software? Add ?safemode=1 to the URL, then go to a section, and see if the sticky header covers the heading. If it does, I'll be grateful for information about your browser and your OS.
About #6, in our user testing, we learned that bolding the current section helps users with their orientation on the page. I guess this may be relatively easily configurable via the personal CSS pages, but I don't have the code handy right now. Would you like us (or any other tech-savvy Wikipedians) to write something un-bolding the section for you?
I've already been over the pages where you justify the changes, and while they may work for small west-coast US focus groups, they don't necessarily work for the rest of us.
1. People already have their browsers set to their preferred width before they ever get here. WP is not the only site they ever visit, and most people will have their browsers aligned how they want them. To then have a width fixed by the WMF to something they don't want is a bit arrogant. (There are several comments on this page from IP readers about the bad width and this is repeated in the already archived threads and on other pages where people talk about the new skin. Your comment that people "may, but most of them just don't" isn't confirmation that it's right: it's an indication they don't know how to.
2. The claim that "the links are not presented cohesively as a unit" is relatively meaningless. They were all next to each other – that is presenting them cohesively as a unit. It's now two clicks to get to commonly used links. Why are you making it more difficult for people to navigate?
3. This isn't about the sticky header: this is about the icons at the top of the page: if you want icons on the sticky header, that's not a problem – but at the top of the page it is not an intuitive set of images. Icons mean different things to different people, the words don't. Why are you making it more difficult for people to navigate to regularly used pages?
4. This seems to have resolved itself from when I first started using it
5. You've explained that you have done it, but it doesn't stop it being a bad idea. It's the only word you have in the sticky header (if the WMF have an obsession with icons in the menu, the least you can do is have one for this too). It's odd but I've never felt the need, half way down an article, to decide to read the remainder of the article in French, Finnish or Farsi. People will make the choice before they start reading. I don't know the stats on this, but I cannot imagine we are dealing with a significant number of people who switch between languages frequently, and even less who do so mid article. I don't mind it at the top of the page, but the big bold word following me down the page is distracting – and if it takes my eye off the text, it's bad design.
6. Extra code isn't an answer. When I read WP (as opposed to editing), I do so logged out, so code on my account is pointless.
Among the many definite advantages to the new skin, you've spent a lot of money changing things that didn't need changing, and taken some things backwards in the process. I'm guessing that none of what I've written is going to make a blind bit of difference - the WMF tend to dig their heels in and be inflexible after they've spent big money, and I don't see this will be any different. Hey ho - back to the old skin for me: its disadvantages are myriad, but it's less painful than trying to use the new one. - SchroCat (talk) 08:39, 8 February 2023 (UTC)
When will the blue pulsing dot under the Preview tab on the source editor be removed?
Apologies if this isn't the best place to ask this, but I don't know where else to put it. As the title says, when will the Wikimedia Foundation remove the pulsing blue dot that appears under the Preview tab when editing a page's source? As an IP editor, I honestly find the pulsing animation annoying, and I hate how it appears every time I edit and how I have to click twice in order for it to stop. I'm sure many people already know about the existence of the feature, so why continue to display the distracting animation? I honestly hate it more than I hate Vector 2022, and that's saying something. When will the dot be removed completely? 2001:4453:565:1C00:577:4A:AC06:F616 (talk) 08:56, 10 February 2023 (UTC)
No, the Realtime Preview feature is a response to a wishlist request, and completely separate from Desktop Improvements / Vector 2022. It looks like the blue dot should go away after the first time you click the Preview tab, and then click "Okay" on the introductory message: it sets a flag in localstorage WikiEditor-RealtimePreview-onboarding-dismissed: true. Does that not work for you? the wub"?!"11:56, 10 February 2023 (UTC)
You know, I noticed that blue, pulsing dot. I've just ignored it because it so obviously serves no useful purpose. No, no, no, I stand by that; it doesn't serve a useful purpose if we don't know what its purpose is. And its purpose can only be clear to the people who designed it. And it was designed by computer people for whom computers are not tools, but the be-all and end-all of existence--losers now on a power trip figuring out for us what we want, whether we know it or not, and giving us what they know we want, whether we want it or not.
@AzseicsoK Have you ... tried clicking it? The button it's highlighting clearly says "Preview", I promise you nothing horrible will happen if you try it out. Is there another method you suggest for signposting new features to users? For the record, this feature wasn't a tool created by "losers now on a power trip figuring out for us what we want", it was created by the Community Tech team in response to a request made by 119 editors. Sam Walton (talk) 14:09, 10 February 2023 (UTC)
When you look at the logo in the infobox of WoodmenLife does it look squished or normal? I uploaded a cropped version to Commons, and it looks like it's trying to squeeze the old versions into the size of the new version. I'm on mono book if that matters. –DMartin20:38, 9 February 2023 (UTC)
Hi, I don't know if here is an appropriate place to ask this question, but I noticed something very odd about the display of U+A7A4 (Latin Capital Letter N With Oblique Stroke) on my iPhone. It appears to be displayed as a cursive version of the lowercase "l", which is very strange because to my knowledge, there is no correlation between the letters N, N with oblique stroke, or L. Most characters in Latin Extended-D are unable to be displayed (rectangle), few are displayed correctly, but this incorrect display is extremely rare and I don't know how to explain it. Does this have to do with some computer bug, or is there a historical reason behind this? Because I personally don't see what good there is to have it displayed as something incorrect over being displayed as a rectangle.
What I see for U+A7A4 on my iPhone. I personally think it should be displayed like U+A7A5, if U+A7A4 can't be displayed correctly. Displaying it as a cursive l makes no sense at all.
I do a lot of iOS and Mac OS troubleshooting, and there was surprisingly little on the web about adding missing fonts to iOS. I checked on my brand new, latest-OS iPhone (first new one in six years!), and I also see boxes. The best advice appears to be to install an app like AnyFont, then use it to add a font that will display these characters. Mac OS and Windows are the same way when it comes to displaying many Asian-language scripts; they just make it easier to add a font. – Jonesey95 (talk) 06:17, 9 February 2023 (UTC)
Thanks for the advice! The character being displayed incorrectly on iPhone isn't that much of a concern for me, since I use my computer instead. I'm just curious as to why an uppercase N with an oblique stroke is being displayed as a lowercase cursive L, since there seems to be no correlation between the two characters. Do you or anyone else know the answer? Thanks! Cmnpt (talk) 03:58, 10 February 2023 (UTC)
With this being a "Some browsers don't display some unicode characters" problem, I don't think there is anything for us to do. On a very limited page such as Ꞥ itself, including an image of the character could be beneficial to some readers, and anyone is welcome to do that. — xaosfluxTalk13:38, 10 February 2023 (UTC)
businessweek.com often redirects to a crufty url at bloomberg.com, (insource) 10,682 pages with links. They have bot detection software making it difficult to determine if it's a 200, 404 or soft-404. Any suggestions appreciated at WP:URLREQ. -- GreenC16:02, 11 February 2023 (UTC)
PressReader.com titles
This is probably not the right place to ask, but if someone could redirect to a more appropriate place great.
Currently we have 409 articles using
"PressReader.com - Digital Newspaper & Magazine Subscriptions" as the title of a reference rather than the actual title of the article being referenced. Is there any tool that can convert the title?
As an example [13] that I have done manually. Keith D (talk) 22:12, 11 February 2023 (UTC)
@Keith D: "PressReader.com - Digital Newspaper & Magazine Subscriptions" is the html title of the page. The title of the displayed article isn't even in the html of the original page. I guess somebody would have to code a bot for this particular site. You could try Wikipedia:Bot requests. PrimeHunter (talk) 22:26, 11 February 2023 (UTC)
I noticed something odd today. When you hold the cursor over a wikilink to Campaign Against Antisemitism to open the pop-up preview, the page title appears blue, as if it were a wikilink itself. I checked a couple dozen other wikilinks and found that it only appears to happen when linking to this specific article. I tried to delve into why this happened but couldn't find anything of note in the lead or short summary. It's also unrelated to the page protection. Although this isn't particularly disruptive, it got me curious. Is this a bug or a feature I don't know about? What could be causing it? Prinsgezinde (talk) 21:38, 11 February 2023 (UTC)
Curiously, I discovered that the same does not happen in incognito mode, so the cache is still most likely responsible. I can't imagine why this might happen (and to only that article in particular) but it's probably near impossible to reproduce, so I'd say that instead of a bug it's merely a minor anomaly. Prinsgezinde (talk) 22:00, 11 February 2023 (UTC)
@PrimeHunter: it does not. Upon logging back in, however, it occurs again. I will note that I'm using dark mode and so the text is typically white for me, but that is unlikely to be related. Prinsgezinde (talk) 22:39, 11 February 2023 (UTC)
Another thing: in my previous post I meant that it does not occur when I use incognito and log in. That's why I mentioned that it is most likely a cache issue after all. Prinsgezinde (talk) 22:40, 11 February 2023 (UTC)
@Prinsgezinde: Assuming by dark mode you mean the "Dark mode toggle" in your Preferences > Appearance, this "bug" is fairly easy to reproduce: step 1. enable the aforementioned toggle, 2. go to a random page and enable dark mode, 3. hover over a wikilink and click on the page title on navigation popups, 4. come back to the page and observe the popup for the same wikilink again. This happens because the dark mode gadget explicitly sets color #6b4ba1 for "visited" links, i.e. URLs you've previously clicked on. (Relevant CSS: MediaWiki:Gadget-dark-mode.css#L-138) — DVRTed (Talk) 23:20, 11 February 2023 (UTC)
@DVRTed: If I understand correctly you're referring to the colour of links changing from blue to purple once you visit the page, but that's not what I meant. For me the title of the page in the pop-up window review is blue instead of the (dark mode) standard white, which piqued my curiosity because it is something I have never seen before. It's the exact same shade of blue that an unvisited wikilink would appear in. Prinsgezinde (talk) 23:44, 11 February 2023 (UTC)
@Prinsgezinde: Always say if you have color-changing features when you report color issues. I can reproduce the purple color mentioned by DVRTed with dark mode enabled and clicking the link inside the popup. What happens with other pages like The Example if you click the link inside the popup and not merely the wikilink? It becomes the same purple in the popup for me. PrimeHunter (talk) 23:59, 11 February 2023 (UTC)
Apologies, you're right. I guess I figured those were the standard settings because I haven't messed with the options a lot. I also missed that part of DVRTed's explanation. Clicking inside the popup box indeed reproduces the 'issue'. Case solved. Prinsgezinde (talk) 10:22, 12 February 2023 (UTC)
new hidden category
Hello. Similar to other hidden categories, would it be possible to create a hidden category for the articles that have more than 800 unique references? This category would also be helpful for WP:MOSTREFS. They are currently doing this completely manually. —usernamekiran (talk)06:06, 8 February 2023 (UTC)
@Usernamekiran: Tracking categories like Category:CS1 errors: invisible characters are added by a single citation template based on parameters in that citation. A category for number of references would have to be added and removed in edits by bots or users. I don't think that's worth the effort. You could instead suggest an addition to Wikipedia:Database reports at Wikipedia talk:Database reports. Something similar to WP:MOSTREFS but updated regularly by a bot scanning the whole database of articles. You would probably have to explain why such a report is useful and you may not get a "Type" column if somebody is willing to code the report. PrimeHunter (talk) 16:44, 12 February 2023 (UTC)
@PrimeHunter: Hi. I have already created a bot for that task successfully (User:KiranBOT/MOSTREFS). I did a lot of test runs, and in the end I did some test runs from toolforge using large number of pages to be scanned. My code was very efficient on server (did not consume resources), but it would take something like 15 to 18 days to scan ~4-5 million pages (redirects, disambs, stubs, articles with refimprove and similar templates are excluded). So I was looking for some other way to achieve the results. I thought this could be done by editing the reflist template, but the discussion at Template talk:Reflist says otherwise. —usernamekiran (talk)16:56, 12 February 2023 (UTC)
This is basically not possible to do in Lua or template language, as those do not have access to the output of the <references> tag. You would need to change Extension:Cite to do what you want. That seems like needless processing.
Operating over the replicas or database dumps is appropriate in this scenario. Doing so with the HTML versions might be best since it would be trivial to get the quantity of items in the references list. 15-18 days honestly sounds about right for what you're trying to do if you choose a slow language, but even a fast one operating on HTML would take a while. I do not anticipate this kind of reporting needing to be done more than once a month at most, and I honestly don't see the value to doing so even that often. Izno (talk) 18:46, 12 February 2023 (UTC)
There is currently a discussion at MediaWiki talk:Createacct-username-help regarding whether or not to add a link to the login page atop the Special:CreateAccount page. The thread is Proposal: add a link to log into an existing account.. Thank you. — Red-tailed hawk (nest) 16:24, 19 January 2023 (UTC)
Resolved
Works for me @Mjroots did you change to vector-2022? If so the TOC is now in the left sidebar, under the tools. — xaosflux Talk 16:48, 18 January 2023 (UTC)
the wub "?!" 17:34, 18 January 2023 (UTC)
and should appear in the bottom right of the screen. the wub "?!" 00:09, 19 January 2023 (UTC)
199.208.172.35 (talk) 15:30, 20 January 2023 (UTC)
The new version of MediaWiki will be on test wikis and MediaWiki.org from 31 January. It will be on non-Wikipedia wikis and some Wikipedias from 1 February. It will be on all wikis from 2 February (calendar).
Wikis that use localized numbering schemes for references need to add new CSS. This will help to show citation numbers the same way in all reading and editing modes. If your wiki would prefer to do it yourselves, please see the details and example CSS to copy from, and also add your wiki to the list. Otherwise, the developers will directly help out starting the week of February 5.
Hamburger button by the logo to open it. Click "Switch to old look", which will take you to the exact section of Special:Preferences that you need to be in. The "preview" option for each item will let you find the style that you like best.
Moved from WP:Help desk
Resolved Okay, it's clear from the Phabricator ticket that indeed there is disagreement among multiple load-balanced servers as to which image to use, so I think this VPT topic is effectively resolved (well, kicked up to a different resolution mechanism). Thanks, all. jhawkinson (talk) 22:51, 5 February 2023 (UTC)
— TheresNoTime-WMF (talk • they/them) 04:22, 6 February 2023 (UTC)
Enable limited width mode and it seems to be okay for now. —Tenryuu 🐲 ( 💬 • 📝 ) 00:07, 27 January 2023 (UTC)
)_with_new_Vector_2022_skin.png)
