If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for five days.
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
So. That notice at the top of my pages here...[edit]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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?
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
@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)[reply]
@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)[reply]
@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)[reply]
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)[reply]
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)[reply]
@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)[reply]
Three dots does not tell me that's where login is hiding[edit]
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)[reply]
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)[reply]
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)[reply]
Template:Resolved
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)[reply]
@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)[reply]
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)[reply]
@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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Adjusting the new Vector 2022 skin to reduce white space[edit]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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' )
:::::
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
A JS solution would be less prone to future breakage:
Toggle for expanding screen width not visible on Wikipedia, but visible on Mediawiki[edit]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
A suggestion to add to your "Lessons Learned" review[edit]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
"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)[reply]
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)[reply]
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)[reply]
Font rendering bug related to scrolling on new vector style[edit]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
Disabling "Enable limited width mode" as the default?[edit]
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)[reply]
@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)[reply]
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)[reply]
I can't make it appear, even in safemode, logged out. I have submitted T327368. 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)[reply]
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)[reply]
This is terrible! Bring back the old website design now![edit]
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)[reply]
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)[reply]
Put this template on your userpage if you don't like the new look[edit]
I'm giving the new skin a college try but one thing that's non-negotiable is removing the direct link to My Contributions in the top-right corner. I used that as a quick way to reach my active/recent discussions so hiding it in the sub-menu is an extra click for no reason. Is there any way to customize which buttons appear directly (currently, it's Userpage, alerts, notices, watchlist) and which ones get hidden in the sub-menu? Slightly less important but still annoying is that I have the UTCLiveClock gadget active (Preferences > Gadgets > Appearance, 2nd one in the list) and that's getting hidden in the sub-menu as well. Is there any way to change this? I don't mind having extra buttons on the top-right of my screen. Axem Titanium (talk) 01:36, 19 January 2023 (UTC)[reply]
Thanks xaosflux for pointing me to those two threads. Since it seems there's no option to change it at the moment and quick access to contribs is too important for my UX, I'll be switching back to Vector 2010 for now. I look forward to trying the new Vector 2022 when these two features are (re)implemented. Axem Titanium (talk) 04:01, 19 January 2023 (UTC)[reply]
Projectspace categories like Category:Lists based on Wikidata, Category:CSS image crop using invalid parameters or Category:Chem-molar-mass both hardcoded and calculated are automatically generated by maintenance templates, meaning that they're impossible to empty of draft or userspace pages that are using those maintenance templates -- so to avoid the database reports for categories with draft or userspace pages in them becoming cluttered up with permanent kludge that was impossible to resolve, Wikipedia has long had the {{polluted category}} template to flag certain categories as not of concern to category cleanup projects so that they would not get detected or listed by the cleanup reports.
However, something seems to have happened, and some categories that are tagged as "polluted category" are getting detected and listed at Wikipedia:Database reports/Polluted categories (2)despite the tag. All three of the categories I listed above, for example, are tagged as "polluted" categories, yet are listed in the current run. Could somebody investigate why this is happening, and apply whatever fixes are necessary to get these categories out of the way? Thanks. Bearcat (talk) 03:25, 12 January 2023 (UTC)[reply]
Just a quick note so y'all can apportion blame properly:
The Editing team is planning some changes. These will only be visible to people who have enabled the "DiscussionTools" Beta Feature. If you see them, and don't like them, they can all be turned off in Special:Preferences#mw-prefsection-editing-discussion (last item, "Show discussion activity").
The upcoming changes that you should blame on the Editing team, rather than on the Web team, are:
The discussion activity items that are currently visible in Talk: and User_talk: namespaces only will finally be enabled in other talk namespaces, but not in any even-numbered namespaces (e.g., the namespace this page is in).
The old [reply] button will become a Reply button. This is because it's easier for brand-new editors to figure out what a button is. You'll still be able to re-style it, but if you're using the old script to change it, it'll probably need to be updated.
[Later] They're going to add an extra "Add topic" button, so you don't have to scroll all the way back up to the top of the page to start a new section. For Vector 2022 only, this will be in its sticky header. (For all the other skins, I believe it will be at the very bottom of the page, which I guess doesn't help much if you're exactly in the middle.)
[Later] They're going to add a line at the top of the page, under the =Page title=, that says how long it's been since the last signed comment ("Yesterday, in the kitchen with the knife, by WhatamIdoing"). This may not be helpful on this page (and won't appear here), but it should make it easier to spot whether there are any recent conversations on a more average talk page.
Pretty much all the other visible changes this month should be blamed on my teammate Szymon. ;-)
What might be useful for Editing to hear from this group in particular is:
How should the software detect whether a talk page in a non-talk namespace (e.g., Help: or Wikipedia:) is the right sort of place for a discussion? If you have ideas about a reliable heuristic, I'm sure that they would be happy to hear them.
Is it just me or is the way that this message is worded crazy? It reads a bit like something I might post and I had to read it twice. First time I was being overwhelmed by who is blaming who? And then once to realise that this is just an annoucement of changes being made as part of mw:Talk pages project... Bit of a wild message and not the most constructive way to ask for feedback if you ask me. Terasail[✉️]13:00, 12 January 2023 (UTC)[reply]
WMF accounts should avoid inserting humour into valid updates for communities. It will often miss and come off as some "in joke" between staff. Being clear and concise is the best way to inform people of changes but insering humour both extends the message making it less concise as well as making it less clear what the goal of posting the message is. Terasail[✉️]15:42, 12 January 2023 (UTC)[reply]
Template:Replyto It's about an upcoming interface change. Such changes always provoke posts on this (and other) pages along the lines of "I don't like it, change it back at once. Then fire the developers who foisted this on us without asking first." --Redrose64 🌹 (talk) 14:43, 12 January 2023 (UTC)[reply]
@Redrose64 While true, I run into the issue that this reads more like a "Go ahead and start complaining now at the editing team but just make sure you don't towards the web team" rather than anything particularly constructive. If the message trimmed all this finger pointing (Insert spiderman meme) that would be one thing, but it just doesn't read well for me. This would also be better if the message linked to the actual mediawiki pages which contain the explanations of each feature rather than giving long descriptions here along with coordinating some update through tech news. Terasail[✉️]15:40, 12 January 2023 (UTC)[reply]
Unfortunately for Whatamidoing (WMF), most of us view the WMF as one big entity and do not distinguish among the teams. I can't remember ever singling out one person at WMF for criticism (if I have done so, I was probably wrong to do it), but I have leveled plenty of criticism at the organization as a whole. I know from working in large bureaucracies that many well-meaning, helpful, intelligent, and dedicated individuals can exist within an organization that often makes large errors on a regular basis. Although I think the above inter-departmental jabs were intended as humor, WMF employees would do well to remember that when the WMF does something, the WMF as a whole gets the credit or the blame, and Wikipedians generally don't care about the internal politics. – Jonesey95 (talk) 16:01, 12 January 2023 (UTC)[reply]
The regulars on this page usually care about getting their feedback, in the most efficient manner possible, to the people who can fix the problems. These are the upcoming changes that folks should complain to the Editing team about (or ping me). If it's not on this list, you probably need to contact the Web team (or ping Szymon).
I'd hoped that these changes would go out last month, to avoid this potential for confusion, but there were delays on our end, so here we are. This is your cheatsheet for which team is causing which change.
And Redrose is right, at least about someone disliking any given change and someone saying that nobody was ever asked (e.g., in the multi-month massive consultation that started this project) or informed (e.g., in Tech/News and here). There are 945 registered editors here at the moment. Of course some people aren't going to see these announcements. (In 2013, my team ran high-volume CentralNotice banners for two weeks about the deployment of the visual editor, and I remember someone saying that they'd missed all the banners due to being on holiday for those exact 14 days.) Of course someone's going to dislike some of these changes. Of course someone's going to dislike all of these changes. It would be patently unreasonable of me to expect that many people to agree on any UI or design point. This is normal and expected. Whatamidoing (WMF) (talk) 18:46, 12 January 2023 (UTC)[reply]
Try using the direct link. The error is with the file served by the server, so it's reproducible on every Wikimedia site. I haven't asked at Commons VP as I believe it's less frequented. But if no one here knows what's going I guess it'd need to be reported at Phabricator. --Paul_012 (talk) 14:31, 14 January 2023 (UTC)[reply]
I still see the difference here and also via the direct link (but not via a 320px direct link, for example). The middle image is showing more-saturated colors, i.e. the previous version of the file. The file was updated on 28 November 2022 and again on 29 November 2022. Is there something that can be done to purge a cache somewhere? – Jonesey95 (talk) 21:53, 13 January 2023 (UTC)[reply]
I see the correct image in all three examples now as well, and in the direct link. It looks like some sort of cache was cleared, either by an automated process, or by a gnome who read this discussion. – Jonesey95 (talk) 16:31, 17 January 2023 (UTC)[reply]
In all my years of editing Wikipedia, I am still not sure how to produce tables. I have been to the help pages for table construction, and that says that to produce a table, one needs to go to the Edit toolbar and select "Insert Table". This does say that this is available on Google Chrome, the search engine that got me here, but I am not sure where the Edit toolbar is. Would someone like to explain to me where one can find it? Many thanks in advance for any help. YTKJ (talk) 18:13, 13 January 2023 (UTC)[reply]
@YTKJ: We have several help pages mentioning tables and several toolbars. Please link pages you refer to. See Help:Table for general help about making tables in the source editor. In the desktop version of the site, the default toolbar for the source editor is right above the edit area and has an "Advanced" option. You can click it and then a table icon to the right to insert a table. You can also copy an existing table and modify it, or write the table code from scratch. PrimeHunter (talk) 18:44, 13 January 2023 (UTC)[reply]
There's a button on the far side of the toolbars that looks like a pencil, and that will let you switch back and forth between wikitext and visual editing (unless you've disabled that in your prefs). Whatamidoing (WMF) (talk) 20:47, 16 January 2023 (UTC)[reply]
Cannot find interlanguage for links for Categories[edit]
@Jona This is a bug that seems to affect the language selection button on non-article (category, template, project...) pages on wikis using the Vector 2022 style - so English works OK but French is broken, German works OK but Danish is broken, etc. It was reported as phab:T326788; there has been a patch put out and so hopefully it should be fixed soon. Andrew Gray (talk) 18:31, 13 January 2023 (UTC)[reply]
Wikidata interlanguage linked templates not working[edit]
There are 3 other language equivalent templates linked with Template:Diplomatic missions of Norway on Wikidata, but from en Wikipedia I get an error when selecting the language menu on top right (Vector skin 2020) Page contents not supported in other languages.. Any idea why? ~ 🦝 Shushugah (he/him • talk) 02:52, 14 January 2023 (UTC)[reply]
This is from a decision to make language switching unavailable for anything other than article space. See the phab ticket for more info. Terasail[✉️]02:58, 14 January 2023 (UTC)[reply]
Since yesterday, section edit links in mobile web has disappeared from File namespace. Issue exists even when logged out and tried in Opera and Chrome browser Android 10 OS smartphone. I did not find this problem in other namespaces and in desktop view. The only edit button visible is the one at the top of page, which for most part is useless since it only opens the "lead section" which will be empty for most files. This has made editing file pages impossible in mobile web. The button is visible in commons and other language Wikipedias, so this seems to be something specific to English Wikipedia. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 06:47, 14 January 2023 (UTC)[reply]
@ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ: When you click the edit button at top, the end of url contains #/editor/0. Change that to #/editor/all. This will open the entire page in editing views. A long process for a much smaller task, but until fixed, this is the workaround. —CX Zoom[he/him](let's talk • {C•X})08:22, 14 January 2023 (UTC)[reply]
Right now, if you happen to click "log out", it does just that. It was also like that quite some time ago (not sure when), when I came here (I believe) to ask about a delay of some sort. I was given a solution that made it so when you clicked on "log out", a small pop-up would appear asking: "confirm you want to log out" (or something like that). It was just what I was looking for and it worked well. But I noticed today that it no longer seems to be working. I inadvertantly clicked "log out" and was immediatetly booted out. Did something change? Is it possible to still have this... fix, in place? If so, pleaae let me know what I need to do. Thank you - wolf07:07, 14 January 2023 (UTC)[reply]
Nah as a screen reader user, I prefer the prompt type that WK's script uses. A screen reader doesn't automatically focus on the confirmation prompt in the script by @Guywan:; there may well be ways to fix that on the JavaScript end but I don't know what they might be. Graham8710:25, 14 January 2023 (UTC)[reply]
Thanks for the replies so far guys. I'll keep an eye on this thread to see if a solution comes along. Cheers - wolf10:30, 14 January 2023 (UTC)[reply]
I expect there will be a lot of issues like this moving forward with Vector 2022, and updates will be needed. I'll be looking at my own; I'm always looking at my own; updating code is a constant and often tiresome need. Can we have a show of hands for folks in this thread currently using Vector 2022? Fred Gandt · talk · contribs15:00, 14 January 2023 (UTC)[reply]
I can confirm (no pun intended) that my script is working as expected with both the Vector legacy and 2022 skins. Mine works by literally replacing the html element containing the "log out" link rather than trying to change the original's behaviour and that's what it's doing. Clicking the default link should take the user to a confirmation page anyway (something that didn't happen when I built the script back in the dark ages), so users should never get booted out by an accidental click even if they're not using one of these scripts. All that previously striked-through is rubbish. Fred Gandt · talk · contribs15:19, 14 January 2023 (UTC)[reply]
Seems I'm using the same skin and the same script, but it stopped working for me. 🤷 Don't know what to say. (Except that I do appreciate you writing that script in the first place, as well as the help it provided me for the last couple years. Thank you for that). Other than that, I hope a fix comes along soon. Cheers - wolf15:55, 14 January 2023 (UTC)[reply]
I just rewrote the script to use the default confirmation of Special:UserLogout. By default, Wikipedia has code in place to ignore the normal confirmation process and blast users straight out the door with a hardly noticeable wave. The way I solved this problem was to completely scrap the bizarre code by replacing the log out link, then offer the "Are you sure?" confirmation. I just removed the need for the confirmation since it's already built into the default interface thus removing a step for users who actually want to log out. You should see, with my script active, when clicking the log out link, that you land on Special:UserLogout and are asked to confirm. If you don't want to log out, just go back a page in your browser history and it's like it never happened; if you want to log out, hit the big blue button and you're gone. Fred Gandt · talk · contribs16:09, 14 January 2023 (UTC)[reply]
@Thewolfchild: you may not be aware that user scripts are not loaded on user preference pages and as such, any user script (including these log out jammers) will not function on those pages. Please confirm if User:Fred Gandt/confirmLogout.js is not functioning as described in my previous comment on non Special:Preferences pages. Cheers Fred Gandt · talk · contribs16:27, 14 January 2023 (UTC)[reply]
When I first got booted out, I was on an article page. But anyway, I just clicked "log out" from my talk page and it worked just as you described. Thank you Fred, it's appreciated. Cheers - wolf16:46, 14 January 2023 (UTC)[reply]
In re logging yourself out: One of the things I'm liking about Vector 2022 is that the logout button is hidden in a dropdown menu. I have not ever (yet?) accidentally logged myself out while using that skin. Usually, for me, it happens when I'm clicking on Special:MyContributions just as the UTC clock gadget loads, but this isn't a problem in the new design. Whatamidoing (WMF) (talk) 20:53, 16 January 2023 (UTC)[reply]
I use a completely different method. I remove the logout link entirely (add #p-personal li#pt-logout {display: none;} to your common.css). Then, if you want to logout, you can go to your preferences and use the link there. (What I actually do is add a logout link to my toolbox. I used to frequently accidentally logout when the link was in the default location, but in many years, I've never done so from my toolbox link. And there's a confirmation dialog if I ever do misclick.) MANdARAX • XAЯAbИAM17:14, 14 January 2023 (UTC)[reply]
@Graham87 et al.: Sorry, I've known that my logout confirm script hasn't been working for a while, but just haven't gotten around to look into it. It should be fixed now! Writ Keeper⚇♔17:23, 14 January 2023 (UTC)[reply]
I'm not sure what to do with the history section at Ingleside, Texas. It is completely unsourced, and is nearly identical to the history on the city website. The section was added by an IP back in 2010, and the original edit included a promo for a book. I'm not sure if the section needs to be removed and nuked. Thanks! Magnolia677 (talk) 12:44, 14 January 2023 (UTC)[reply]
I have to apologise. I see I was using the wrong url. Or maybe not, running the url again through Wayback now says "Saved 5 times between June 28, 2022 and January 14, 2023." which is NOT what it said the first time I ran it. This is worrying as we often depend upon Wayback for copyvio issues. Doug Wellertalk08:41, 18 January 2023 (UTC)[reply]
Editing window using Safari on iPad obscured[edit]
Hey @Doug Weller, thanks for reporting this. Could you add &safemode=1 to the URL in the editing mode, and write back if you still see this issue? For me, Safari on iPad works fine but I see we're using different gadgets. SGrabarczuk (WMF) (talk) 21:36, 16 January 2023 (UTC)[reply]
iOS 15.6 is supported at both Modern and Basic levels in mw:Compatibility#Browser support matrix. At a minimum, it shouldn't look like that, so if it's still an issue in safe mode, it's something for WMF to look into. :) I'd have guessed it was display: grid that was the issue, but that looks more or less supported since iOS 10.3, so it is apparently Something Else. Izno (talk) 02:20, 17 January 2023 (UTC)[reply]
You said it wasn't an issue with safe mode. You will need to troubleshoot the scripts and CSS you have. You can either disable/remove everything out of your CSS/JS and then re-add this content until the issue resurfaces, or do a binary search with the same process, where you do half, and if it's not in that half it's in the other half, etc. Izno (talk) 21:56, 17 January 2023 (UTC)[reply]
I worded that badly perhaps. Sometimes safemode works, but then sometimes it works without safemode. But it's not a change caused by anything I did, so I think I'll wait a bit to see if it goes away with some other change. Binary search sounds a great idea if I decide to go that way. Thanks for that. Doug Wellertalk09:13, 18 January 2023 (UTC)[reply]
Does it work reliably when safe mode is activated? If so and it sometimes works without safe mode, then it sounds like there is one or more race conditions with some of your customizations that causes the problem to manifest some of the time without safe mode. isaacl (talk) 17:22, 18 January 2023 (UTC)[reply]
Articles created not appearing in search results[edit]
I think this is a bigger issue than just your articles. Articles that I've created after the first week in December don't show up in search results via autocomplete, until I type the complete name. – Muboshgu (talk) 20:35, 15 January 2023 (UTC)[reply]
The internal search provider. From my experience, if you type out the full name of the article, it will appear below the search bar, however, if you even subtract or add a character, said article disappears from the search bar. Knightoftheswords281 (talk) 21:51, 15 January 2023 (UTC)[reply]
In the past, I've seen a delay for even autopatrolled articles to appear in the search bar, but it seems to be much longer now - Macks Creek Law was created in December, and Steele's Greenville expedition at the very beginning of this month, and neither is showing up for me in the autocomplete, and both would have been autopatrolled. Hog FarmTalk22:05, 15 January 2023 (UTC)[reply]
The above screenshots are taken from page Talk:Sharad Yadav in mobile web view, Opera browser, Android 10 OS. There are two WikiProject banners between {{Talk header}} and {{ITN talk}}. They are broken when viewing it as a normal wiki page and appear as two thick lines. However they render fine in the preview window. It is strange that we have software that works fine in preview but is broken in the actual page. I know there was some work on talk page banners recently before which they were completely hidden in mobile web, can something be done to fix this? ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 04:39, 16 January 2023 (UTC)[reply]
Thanks for the bug report, this is interesting. The issue also happens on other pages with other templates (e.g. Talk:Search coil magnetometer is another example).
I tracked down this behavior to the code that displays the "About this page" section on mobile. It (unintentionally I think) also removes some content from the "Read as wiki page" view. This happens in the code here: [3]. That's definitely a bug. I filed phab:T327047 about this.
However, that code hasn't changed in a couple of months, and I am pretty sure the templates displayed correctly before. I suspect some recent change in the templates broke some assumptions in the mobile code.
There was recent work on talk page banners, but those changes are not enabled on English Wikipedia yet. I am hoping we'll do that within a few weeks (I'm one of the developers). You can preview how the page will appear after these changes here: [4] – it doesn't suffer from this issue. Matma Rextalk06:14, 16 January 2023 (UTC)[reply]
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Problems
The URLs in "prev" links on page history now contain diff=prev&oldid=[revision ID] in place of diff=[revision ID]&oldid=[revision ID]. This is to fix a problem with links pointing to incorrect diffs when history was filtered by a tag. Some user scripts may break as a result of this change. [5]
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 17 January. It will be on non-Wikipedia wikis and some Wikipedias from 18 January. It will be on all wikis from 19 January (calendar).
Some changes to the appearance of talk pages have only been available on Talk: and User talk: namespaces. These will be extended to other talk namespaces, such as Wikipedia talk:. They will continue to be unavailable in non-talk namespaces, including Wikipedia: pages (e.g., at the Village Pump). You can change your preferences (beta feature). [6]
On Wikisources, when an image is zoomed or panned in the Page: namespace, the same zoom and pan settings will be remembered for all Page: namespace pages that are linked to a particular Index: namespace page. [7]
The Vector 2022 skin will become the default for the English Wikipedia desktop users. The change will take place on January 18 at 15:00 UTC. Learn more.
Future changes
The 2023 edition of the Community Wishlist Survey, which invites contributors to make technical proposals and vote for tools and improvements, starts next week on 23 January 2023 at 18:00 UTC. You can start drafting your proposals in the CWS sandbox.
Within the last hour, both of the browsers on which I'm logged in (as User:Naraht) (Chrome & FF) are giving errors that look like
MediaWiki internal error.
Original exception: [bde13a11-c59e-4e46-8642-640488f9c898] 2023-01-17 18:35:14: Fatal exception of type "ConfigException"
Exception caught inside exception handler.
Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.
.
It isn't doing it on my Edge browser, but I'm not logged in there. I can't even get to the button on Chrome and FF to log out, so I'm guessing it is logged in vs. logged out, but I'm not sure.161.107.18.136 (talk) 18:44, 17 January 2023 (UTC)[reply]
I tried it incognito, same deal. Not sure what's causing it. Not sure why wikimediastatus.net insists we're still fully up, despite there being 2600 errors per second in the last few minutes. But as we can see it seems to be fixed now? --Golbez (talk) 18:45, 17 January 2023 (UTC)[reply]
I can confirm this was happening to me until just a minute ago, I could view special pages, lists of deleted revisions, and article histories, but couldn't view pages in any namespaces. I'm on Safari for iPhone. The Blade of the Northern Lights (話して下さい) 18:45, 17 January 2023 (UTC)[reply]
(ec) Have been having same problem both on desktop and mobile, and have confirmation from other users (off wiki communication) that they are also having it . Seems to be resolved atm. DuncanHill (talk) 18:48, 17 January 2023 (UTC)[reply]
Same, I was getting it intermittently for the last ~10 minutes. If I refresh a few times I get the page to load successfully. Firefox. Just tried refreshing a few pages 10 times to recapitulate the issue, but now it seems to be working for me all the time. Ajpolino (talk) 18:46, 17 January 2023 (UTC)[reply]
I mean.. people can fake DownDetector as evidenced when Elon Musk took over Twitter and the reports there went up even tho Twitter was just fine. ― Blaze WolfTalkBlaze Wolf#654518:56, 17 January 2023 (UTC)[reply]
if this was geared towards the many vandals on Wikipedia, then we could just have a long awaited break from rvv's. This seemed to last ~5 mins, as i was refreshing the page. The error msg's original exception would change each reload. Wesoree (Talk) 19:23, 17 January 2023 (UTC)[reply]
Apologies to all the affected people. There is an explanation at phab:T327196#8532474. Basically, the Editing team deployed two related changes, and the servers didn't process them in the logical order. The length of time that this was visible depended on which server you were reaching. It appears to all be fixed now. Whatamidoing (WMF) (talk) 21:03, 17 January 2023 (UTC)[reply]
@Interstellarity to answer your question, no - you would have to click reset on each project. You can get a list of all the projects you are attached to here: Special:CentralAuth/Interstellarity. You may not have ever changed preferences at some of the projects you never edited on, so you may only need to look at the ones with edits (you can sort that output). — xaosfluxTalk14:34, 18 January 2023 (UTC)[reply]
Template:Resolved
Here's a trivial, but mysterious problem. Yesterday, with no warning, my desktop computer and 34-inch monitor decreased the size of the print on the display of all wikipedia pages from approximately 14 point print to 10 point. All other webpages remained unchanged. On my second computer, the size of the print displayed also remained unchanged. So, given that this sudden change occurred on only one computer and only on wikipedia, what do you think the problem is? My old and tired eyes don't like small print. How do I increase the size of the display of print for wikipedia pages? Smallchief (talk) 13:35, 18 January 2023 (UTC)[reply]
@Smallchief: I guess you accidentally changed zoom in your browser and the browser treats it as your preference for the website you were on at the time. In most Windows browsers: Ctrl++ for larger, Ctrl+- for smaller, Ctrl+0 for default size. Holding Ctrl while scrolling your mouse wheel may also change size and is easier to do by accident. If this doesn't help then name your browser. PrimeHunter (talk) 13:52, 18 January 2023 (UTC)[reply]
@Blaze Wolf That is only for clue bot, you are using lowecasesigma bot in this case. Also you set up the bot with a counter of 8, so I moved the archive from /Archive 8 to /Archive 1 Terasail[✉️]16:39, 18 January 2023 (UTC)[reply]
Somehow I got signed out (on private browsing) but when I click on "Talk" it has a "Welcome to this talk page" message. I never saw that before. I don't even remember what happened when I was signed out when I went to that page, but with any other talk page that has not been created, when signed in, I am told to create it.
And this is probably for one of the above topics: I got to the talk page from an article I already saw in private browsing when signed out. When I went to a new article, I didn't even get a link to "Talk".— Vchimpanzee • talk • contributions • 00:15, 19 January 2023 (UTC)[reply]
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)[reply]
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)[reply]
Add interlanguage link for userspace "articles"[edit]
I noticed that User:UBX has interlanguage links. Is there a way to add these on other users such as me? I couldn't find wikidata entries for users Aaron Liu (talk) 02:33, 19 January 2023 (UTC)[reply]
That means adding [[zh:User:Aaron Liu]] to User:Aaron Liu, and also adding [[en:User:Aaron Liu]] to zh:User:Aaron Liu if you want a link the other way. If you want n wikis to link eachother then all n must add n−1 links to the others. Wikidata isn't always popular but it was good to get rid of that system for articles. PrimeHunter (talk) 03:47, 19 January 2023 (UTC)[reply]
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)
The URLs in "prev" links on page history now contain 
The new version of MediaWiki will be on test wikis and MediaWiki.org from 17 January. It will be on non-Wikipedia wikis and some Wikipedias from 18 January. It will be on all wikis from 19 January (calendar).