Talk:Reading/Web/Desktop Improvements

Bug? Footer engulfes content
I've seen this from time to time. Examples (with activated new skin of course): Regards (PS: Sorry if it's the wrong verb in the header, I wasn't sure how to describe the effect, feel free to change to sth appropriate) --HirnSpuk (talk) 23:23, 4 March 2021 (UTC)
 * Die_Rennmaus/_Haltung/_Käfigstandort
 * b:de:Computerhardware:_RAM:_Geschwindigkeit


 * You will need to use the ```

``` template here. This user-content error was previously taken care of in the older skins, but in this new skin is the responsibility of the editor. Jdlrobson (talk) 20:09, 10 March 2021 (UTC)
 * So you’re breaking something that worked for 15+ years just for the sake of breaking it? I don’t think there’s a single valid use case where content should get out of the content area. And it’s pretty easy to fix centrally instead of individually on hundreds of wikis, or, even worse, on probably tens or hundreds of thousands of pages as you advise. Simply  needs to be placed in whatever CSS/LESS file it belongs to. —Tacsipacsi (talk) 00:07, 11 March 2021 (UTC)
 * Where did I say I was breaking something " just for the sake of breaking it" ? My intention was to explain why it's happening.
 * Vector is essentially a new skin, so things can and will break, but the idea is that when they're fixed they are better defined and less fragile. New Vector has only been around approx 1 year and while it is based off of old Vector, and we're trying to keep it aligned with it, its not the same thing, so 15+ years comment here is a little misguided. It uses a completely different stylesheet.
 * " And it’s pretty easy to fix centrally instead of individually on hundreds of wikis" - I don't know, but you are probably right, but then that doesn't sound like a responsibility of Vector but of the skins code inside mediawiki core. The `mediawiki.skinning` module https://github.com/wikimedia/mediawiki/tree/master/resources/src/mediawiki.skinning was set up to define rules that are common to all skins and is where such styles should live and there is currently no such rule for clearing user generated content, so this issue likely impacts other skins (most likely ones not deployed on Wikimedia wikis. I've created T277218 to document the problem. Jdlrobson (talk) 19:40, 11 March 2021 (UTC)
 * The “you” was plural—silly English doesn’t differentiate between singular and plural here. :( Some developer broke it. I don’t care who was, but that person seemingly didn’t have any good reason to do so.
 * The 15+ years is relevant because editors have been designing pages for 15+ years with the assumption that content will remain within the content area. Breaking such assumptions needs very good reasons, which are not here.
 * I also don’t care what piece of software it’s fixed in, so if you think it’s better fixed in core rather than in Vector, feel free to do so, just fix it in software rather than forcing folks to fix it on-wiki. Anyways, thanks for opening the ticket! —Tacsipacsi (talk) 23:39, 11 March 2021 (UTC)

We are on the same page. I just want to make sure any assumptions are defined and clear to all stakeholders whether editor or mediawiki developer rather than implied :) Jdlrobson (talk) 03:05, 12 March 2021 (UTC)

Integrated Dark Mode color scheme
Dark themes are nowadays ubiquitous due to how easy on the eyes and optimized for displays they are. While there's also "hacky" ways (like browser extensions and scripts), they're community efforts at implementing this missing feature from outside, and it's hard to make them work perfectly fine and responsive for everyone. Please, consider implementing a native setting for it. --CapoFantasma97 (talk) 17:04, 5 March 2021 (UTC)

(See the rest in my answer to the "Night mode clash" below.) SGrabarczuk (WMF) (talk) 23:55, 10 March 2021 (UTC)
 * @CapoFantasma97, thank you for this suggestion. The concept of a native MediaWiki dark mode has got a long history now. Just take a look at the Community Wishlist Survey 2019 wish and 2017 wish. Our designers agree with you and would love to build the dark mode, but... ;)


 * Yep, at the very least prefers-color-scheme should definitely be incorporated, with a legible colour scheme to match. HughLilly (talk) 23:56, 12 April 2021 (UTC)

Night mode clash
Hi

The status update from the Community Tech team indicated that they'd started working on this but were not able to proceed because their work would clash with this team, and therefore a night mode would ultimately need to come from another WMF tech team, either this or another.

Could you clarify what prohibited that effort, or what prevents night mode being scoped in as part of this project - it is a rare change that is overwhelmingly requested by both the editing community and a constant avalanche of reader requests. I've no doubt that WMF employees would also like it, or at least think its a good option, so it's more finding "what are the sticking points preventing resources being allocated to it" and then "what can we do about those"? Nosebagbear (talk) 17:14, 7 March 2021 (UTC)


 * @Nosebagbear, great question! Both teams are well aware that the dark mode is desired by many. It was decided that Web would take care of that because it was going to work on related improvements anyway.
 * Why the dark mode is not in the scope of the current project? It's a mix of reasons. Some of them are of technical nature and I'm not familiar with that part. So my apologies, but it's not going to be a full answer :/
 * First and foremost, we're all interested in something better than a smart replacement. It appears that such a feature requires more investment than you or I suspect. More than a year ago, there was a decision to make: either the team would build most of the features currently being on the list, or it'd pick the dark mode and a few other improvements. We know what the decision was, but I don't know the factors involved.
 * Now, the dark mode is a strong candidate on top of a list of potential future tasks. SGrabarczuk (WMF) (talk) 23:45, 10 March 2021 (UTC)
 * Update and correction: the dark mode has been a candidate for a long time, BUT first, we would need to have more servers. Physically. Then we would be able to develop how we cache. At the end, we would be able to build things like the dark mode. If we did a dark mode now, users would have to turn it on each and every page they would visit individually. SGrabarczuk (WMF) (talk) 13:56, 11 March 2021 (UTC)

Opinion (that most likely will be ignored)
It is true that reading a text written along the entire Great Wall of China is hard. But is also true that it is hard to read a text written on a flea wing. Reading/Web/Desktop Improvements/Repository/First Prototype Feedback Report: The size of characters was took into consideration? And Wikimedia wikis also contain images, infoboxes, tables and other things that need space. And stop saying that I will can return to the original Vector; I want a good skin for editors and readers. -- NGC 54  ( talk |  contribs ) 10:51, 8 March 2021 (UTC)


 * @NGC 54, you know your opinion would not be ignored! :) Yes, the size of characters as well as the size of the screens were both taken into consideration. We have made one step in this direction and we're not saying we won't make next steps. Watch the updates from the team and keep your fingers crossed for our plans after the already planned improvements! ;) SGrabarczuk (WMF) (talk) 00:03, 11 March 2021 (UTC)
 * @SGrabarczuk (WMF): "you know your opinion would not be ignored!": How so? I repeat: the width is too small. -- NGC 54  ( talk |  contribs ) 11:36, 11 March 2021 (UTC)
 * @NGC 54, first, I do read each comment posted on this talk page. Secondly, I see that some volunteers from various wikis raise a fair point: on large screens, the width does feel small. I loyally pass this information to the Web team. The team does recognize this issue, and we will talk about this with due respect to all Wikimedians who ask us to adjust the limited width to their needs. SGrabarczuk (WMF) (talk) 12:11, 11 March 2021 (UTC)


 * That's a very good argument I didn't even think about: Wikipedia contains images, infoboxed and tables, and it's gonna be a big mess if this doesn't get any space. Edit: I've ready about this in the FAQ and the argument is given that "people with smaller screens have had the issue before". The most common monitor screen size is between 21-24 inch, and screens are even getting bigger/wider. Maybe some research has to been done about that. It's impossible to give literally everyone the best experience, but it is about giving the best experience to as many people as possible, in this case that group is people with a larger screen size. Lots and lots of Wikipedia articles revolve around tables and images, if we take that away (or even position them on the side, and they are not in their right section), the reading experience gets worse for lots of people. Just like a few others, the design on the right is best for me personally: a collapsible side bar on the left is fine, but keep the content through the rest of the page including infoboxes, tables, images, etc. Coldbolt (talk) 19:39, 9 March 2021 (UTC)
 * @Coldbolt, you are absolutely right. People buy larger and larger monitors, there are panoramic monitors, etc. When we will be planning the next fiscal year (which will happen soon because the fiscal year begins in July and the plans have to be ready earlier than that) we will be considering how to improve the experience of users with large screens. SGrabarczuk (WMF) (talk) 00:45, 11 March 2021 (UTC)

How to localize logo when legacy vector turned off
Hello, I have recently started using the new Vector Skin in Assamese language Wikipedia. However, I see that the logo is not localized. Can you let me know how to do that? Does local interface admin will have to take care of that? --SlowPhoton (talk) 10:54, 10 March 2021 (UTC)


 * This is tracked in https://phabricator.wikimedia.org/T244486 and https://phabricator.wikimedia.org/T142426. In the latter you can help provide the wordmark if you want and are able to help. Jdlrobson (talk) 20:02, 10 March 2021 (UTC)
 * Generally speaking, the Web team will eventually provide the logos. Volunteers are welcome to help. Specific permissions (like local interface adminship) or local edits aren't required. SGrabarczuk (WMF) (talk) 22:19, 10 March 2021 (UTC)

Option to keep Legacy Vector as default
I don't accept a limit of content width. Users have the right to resize the window to achieve a proper width, and you shouldn't be opinionated.

Content width same limited, the new Vector looks full of disorder just compared with Skin:Timeless.

Hope my sites can keep Legacy Vector as default finally, otherwise we may have to add CSS rules to revert such "improvement". Lt2818 (talk) 07:00, 11 March 2021 (UTC)

I am one of the users that like the direction the new Vector is taking, and I disabled the Legacy mode on my side. A proper page layout greatly helps in readability, as the human eye can focus only on a small area, while peripheral vision is not useful to make out details, which is required for reading (otherwise we'd use smartphones only in landscape mode...). The website is still well responsive to window/screen size, it just has a maximum width. Filling a 16:9 screen side to side with text isn't "proper" width (nor is it on 21:9!) and makes it less comfortable to read.

Some people might not like space, but it's not a bad practice at all in typography; instead, it's a good thing when properly used. As such, it makes no sense to regard it as "wasted space" because it's not, it's helpful to format the page, and it could be used in the future for extra content like side panels; also, some modules and page sections could be moved there (imagine notes and references next to the paragraph they refer to!). --CapoFantasma97 (talk) 12:18, 11 March 2021 (UTC)


 * You can't find another website which has an empty right column. I see Winter put infoboxes and Timeless put related links there, both better than the new Vector. Also, other skins try to align elements to their best positions, but this one is a disaster.
 * Vertical writing systems are also ignored. The new Vector is obviously not going to support site-wide vertical writing of Classical Chinese. Don't say you can limit content height instead. Lt2818 (talk) 09:58, 17 March 2021 (UTC)

Max width fix for logged out users
I've released a new max-width fix. Apologies for waiting so long, I've been making time to write it as a CSS user style, but it seems to be outside my web design abilities, so I've written it as a JavaScript user script. This one shouldn't break on future updates to Vector 2.0.

You can download it from https://pastebin.com/3KY1QmzU and install it with any user script addon. The most commonly used are GreaseMonkey, TamperMonkey and VioletMonkey, and they are available for pretty all commonly used browsers (Firefox and forks, Chrome and forks, Edge, Safari, Opera...).

Please report any errors here or on my talk page. Happy browsing! Vectorman007 (talk) 11:28, 11 March 2021 (UTC)


 * Hello, maybe this is more or less the topic I would like to address. I very much dislike the fixed max width for the text in the new skin. That is the reason why I have opted out.
 * The problem: On my PC screen, I usually don't have the window/tab with Wikipedia on full screen. I find that too wide, there are too many words in a line. Also, usually I have other windows open, and I place them next to the window with Wikipedia.
 * So my Wikipedia window usually covers only half or two thirds of the screen. But then, with the new skin, a side bar appears, and I have to scroll the text horizontally in order to read it. Very annoying, of course.
 * That is the reason why I will opt out of every new skin with a fixed max width. Could the fixed max width become a separate feature instead? Ziko (talk) 15:04, 6 April 2021 (UTC)

Vector is just fine as it is
>It has been 10 years since the current default Wikimedia skin (Vector) was deployed It has been 10 years of a damn fine interface is what it has been. It ain't broke, it works well, don't fix it, and for the sake of all that is holy, DON'T impose it on everyone. There is no logical reason, none whatsoever, under the sun, why you should remove the existing interface as an option. And there is no reason why PC users, who must surely make up the majority of editors, should have the use of half of their screen taking away by this thieving gang of cadres, eager to do something even when nothing needs to be done. Lord have mercy. Beaneater00 (talk) 01:51, 12 March 2021 (UTC)
 * I completely agree. If you are going to move on with this hideous project, at least let us who don't like it opt out. --PastelKos (talk) 22:38, 3 April 2021 (UTC)
 * @PastelKos, I encourage you to read the main page of the project as well as sub-pages dedicated for each feature. You will learn why and how the change is performed. SGrabarczuk (WMF) (talk) 11:14, 13 April 2021 (UTC)

New location of search bar now available on all wikis
Please could you add details of how this is enabled — GhostInTheMachine talk to me 00:07, 13 March 2021 (UTC)


 * @GhostInTheMachine, go to your preferences, second tab. Find "Skin preferences". Uncheck "Use Legacy Vector" (= don't use Legacy Vector), go to any other page, and the new location should be displaying. Does that answer your question? You can also set a global preference to see the new Vector on all wikis. SGrabarczuk (WMF) (talk) 13:20, 15 March 2021 (UTC)
 * Sadly, that does answer my question. Having the search bar moved in Vector would have been somewhat better. Perhaps the main page could also make this clearer? — GhostInTheMachine talk to me 14:31, 15 March 2021 (UTC)
 * @GhostInTheMachine, my apologies, I don't know what is your expectation. Are you asking about the code or Vue.js, things documented on Phabricator and Gerrit, that is, how have our engineers moved the search widget? Maybe you've got ideas how the design of the widget could be improved? SGrabarczuk (WMF) (talk) 16:43, 15 March 2021 (UTC)

Too much wasted space in desktop (sorry for bad english)
When connected from desktop with a resolution of 1920 × 1080, there are 1000 pixels of wasted space left and right. This is too hard to read and inefficient. --소언예 (talk) 22:54, 13 March 2021 (UTC)


 * Thank you @소언예! Have you read our documentation: the FAQ and/or Limiting content width? What do you think about the arguments mentioned there? SGrabarczuk (WMF) (talk) 14:02, 15 March 2021 (UTC)


 * If what I understood is correct, did you intentionally narrow it down for readability? --소언예 (talk) 13:14, 16 March 2021 (UTC)
 * @소언예, yes, this is correct. SGrabarczuk (WMF) (talk) 13:09, 19 March 2021 (UTC)

Maybe my complaint is just because it's unfamiliar. Thank you! --소언예 (talk) 17:59, 19 March 2021 (UTC)

About how the sidebar moves
Hello, I'm Kyosu-tanni.

I have some ideas about how the sidebar moves:


 * the button which shows/hides the sidebar is presently shown at the top of the page, but it seems better to shown in the area the user is seeing - sometimes want to let the hidden sidebar be shown even if the page is scrolled down.
 * The scrolling of the sidebar and that of the main content is better to be independent of each other - the reason being same as above, often want to see the content of the sidebar even if the page is scrolled down.

Thank you! Kyosu-tanni (talk) 11:45, 16 March 2021 (UTC)


 * I have an : to make the sidebar customizable.
 * How about:
 * moving the button to show/hide the sidebar, to the left side
 * change the icon of the button to one that signifies sidebar as a pictogram
 * allow users to add some kinds of sidebar - e.g. one that shows watchlist as one of sidebars even in a non-watchlist page
 * sidebar-type TOC may be also good.
 * It is difficult to explain this by text... At the point of view of copyright, is it allowed to upload videos that is made by exporting on Microsoft PowerPoint?
 * Thank you! Kyosu-tanni (talk) 11:44, 19 March 2021 (UTC)

The original language list will no longer appear on the sidebar
Some questions


 * 1) In Reading/Web/Desktop Improvements/Features/Language switching page you are writing that the original language list will no longer appear on the sidebar. However, it doesn't say if users could still select the the old list from preferences like they can full language list now from  preferences (Special:Preferences and m:Special:GlobalPreferences)?
 * 2) If the old list with full languagelinks cannot be selected via preferences then will it be possible to enable it using user javascripts or gadgets? (ie. how the We will have a non-JavaScript fallback which will display the full list of all languages for users that do not have JS access. will be implemented?)

Br, --Zache (talk) 12:21, 16 March 2021 (UTC)


 * Captured in T277517 Jdlrobson (talk) 00:18, 18 March 2021 (UTC)


 * Thanks, I am not sure that we are talking on same thing though. However I was able to browse through phab tickets to Betawiki and found and example article for the (prototype?) of a new language selector which give a look and feel of it. --Zache (talk) 10:31, 18 March 2021 (UTC)

Max-width_gadget
Talk:Reading/Web/Desktop_Improvements/Archive2#Max-width_gadget or the anything based on skin-vector-max-width CSS class doesnt seem to work anymore. What is proper way to remove the width limit using gadget/javascript/css currently?

Also link to the documentation for the used CSS-classes would be nice if you have it somewhere. --Zache (talk) 03:11, 17 March 2021 (UTC)


 * I was able to solve this. My version of the full-screen gadget is in w:fi:mediawiki:Gadget-FullWidthVector.css and w:fi:mediawiki:Gadget-FullWidthVector.js. --Zache (talk) 07:05, 17 March 2021 (UTC)


 * Just some thoughs. The ability to limit the width of the page is awesome and useful. However making it as mandatory is not and it would be a good idea to make it as an toggleable feature like the side bar is. This can be done using gadgets, but there is couple problems with this approach. One is that if the feature relies to javascript to initialize it then the gadget or user javascript will be loaded after page is loaded and page will render itself first using the narrow page width and then re-renders it to full width. This will be visible to user. Another approach would do it using purely using CSS which will be loaded before page is rendered but you actually overwrite CSS values set by Vector skin and not just to add new CSS-rules which you can toggle on/off.


 * It would be a lot better if the option would be directly supported in the skin itself. Ie, mediawiki would read the wanted state from user settings and then set the css class which would define if the content is in full-width or narrow mode. In this way the re-rendering could be skipped and you could also collect data on if users are using narrow/widescreen settings --Zache (talk) 07:30, 17 March 2021 (UTC)

Changing language on the main page
Old version can change language on the main page, but new version can't. The process of searching through another language wikis is too long. Are there any plans to make it? --소언예 (talk) 18:38, 19 March 2021 (UTC)


 * Thanks! This looks like a bug, not a feature. I've submitted a task on Phabricator. SGrabarczuk (WMF) (talk) 12:07, 22 March 2021 (UTC)

How to pre-opt for an entire community (fr. wikiquote) ?
I asked on the "Salon" of the French Wikiquote wether people would be interested in pre-opting, as a community, for these desktop improvements, and [https://fr.wikiquote.org/wiki/Wikiquote:Le_Salon/mars_2021#La_Wikiquote_en_fran%C3%A7ais_est-elle_int%C3%A9ress%C3%A9e_pour_tester_les_ajustements_de_l'interface_? people are interested] (only three answers, but French Wikiquote currently has a very small regular, active community). So, how can we pre-opt ? The "Participage" page says "contact us", but who are "us" and how do we contact them ? (That should be added on the page for clarity's sake, in my opinion.)--Eunostos (talk) 12:30, 20 March 2021 (UTC)


 * @Eunostos, thank you! Just as this page explains, you can contact me. And you have, so we'll have you on our radar. SGrabarczuk (WMF) (talk) 11:56, 22 March 2021 (UTC)

Wide tables benefit from using the full width of the screen
Certain Wikipedia articles contain really wide tables. The reasoning for a narrower page doesn't apply to those, you would never want padding when viewing an Excel spreadsheet. For example, not having the rightmost column on List of ISO 639-1 codes go to the edge of the screen only makes the table harder to read.

Another issue: List of Nvidia graphics processing units has tables that go past the width of the page, but the background abruptly changes from white to gray on the right. Akeosnhaoe (talk) 04:01, 26 March 2021 (UTC)

This is tracked in https://phabricator.wikimedia.org/T267161. Thanks for reporting! Jdlrobson (talk) 14:48, 26 March 2021 (UTC)
 * For me, the ISO table looks way better when limited to 960px. Some comments in the rightmost column get wrapped into two, sometimes three lines, and it is totally fine. And, since you brought up Excel, it has an option to wrap text in column, not have it in one endless line to the right of your table, for a reason. Cheers! SSneg (talk) 14:47, 5 April 2021 (UTC)

The new search field is too narrow
When I start typing in the new search field, a Search button appears in addition to the magnifier icon. It takes up too much space; with a 1024px wide viewport the useful part of the search field is only 192px wide on the French Wikipedia, as opposed to legacy Vector’s 231px on the Hungarian Wikipedia (17% width loss). Even on my larger screen, although it’s actually a few pixels wider, it still feels narrower (probably because its vicinity is too crowded). You should also take into account that not all languages have such short words as Search; French is Rechercher (10 letters instead of 6), while the Bavarian translation is Suach Boarisch oda Deutsch (okay, that literally means “Search in Bavarian or in German”, but it’s still what would be shown with Bavarian interface). —Tacsipacsi (talk) 00:39, 28 March 2021 (UTC)

The logo should be reworked completely for the small resolution
While we in the Russian Wikipedia were preparing a 1 April logo (our annual tradition), we happened to notice that the new Vector has a critical flaw which, I think, many have overlooked before. The problem is that, in the new Vector, you can't see individual letters on the Wikipedia's logo, given that it's made very small. That kind of defeats the purpose of the logo.

Generally, in design, when you create a logo for small resolutions, you remove details or make them larger. This hasn't been done in this case. The puzzle pieces have not been made larger, they have the same size as in the big resolution variant. Jack who built the house (talk) 22:12, 31 March 2021 (UTC)


 * Wikipedia affiliative mark.png Long ago I saw an redesign proposal that featured a simpler version of the logo, namely Wikipedia affiliative mark.png. I always thought it was a beautiful idea and would solve the issue you're pointing out. However I bet many will complain that it removes the multilingual aspect of the current logo, and in any case changing the logo would be a massive enterprise on itself. Sophivorus (talk) 12:22, 3 April 2021 (UTC)
 * Totally agree. The logo needs a redesign to improve legibility of the the smaller variant. Whether it should be radically changed from a globe to a piece of puzzle, I'm not sure. SSneg (talk) 14:50, 5 April 2021 (UTC)
 * I also agree that this redesign requires a smaller logo, and think Wikipedia affiliative mark.png is perfect. This is what it would look like at 70px; I don't even know if it needs File:Wikipedia-wordmark-en.svg and File:Wikipedia-tagline-en.svg next to it. Edit: Per a previous discussion, I also think the tagine ought to go, even if the wordmark stays. HughLilly (talk) 23:48, 12 April 2021 (UTC)
 * This is an interesting discussion, and I encourage you to continue. However, the Web team has neither the intention nor mandate to make any changes to the brand, and are not the addressee of these ideas. Meanwhile, I'll inform my colleagues in the Communications department who are more familiar with the brand aspect than we are. SGrabarczuk (WMF) (talk) 13:07, 13 April 2021 (UTC)
 * Smaller logos for larger screens? It is a desktop change, not a mobile one. The mobile interface is independent from the desktop one... And a single piece of puzzle instead of a puzzle-globe? Why? Wikipedia is more incomplete than before? -- NGC 54  ( talk |  contribs ) 13:19, 13 April 2021 (UTC)
 * Well, my thoughts are just a suggestion. The current logo is an incomplete puzzle of a globe, and is 50px square (at least on my computer). A single puzzle piece, on which the "W" is more legible, could imply—on an article page at least—that the user is viewing just one 'piece of the puzzle,' so to speak.HughLilly (talk) 01:29, 14 April 2021 (UTC)

Is there any reason(s) why Wikipedia is not presenting texts with right justification by default ?
(when languages read from left to right) I think that's this would improve presentation, and participate to easier reading. --Hc balestrieri (talk) 20:25, 2 April 2021 (UTC)


 * @Hc balestrieri, thank you, this is a good question. Sadly, justification is more complex than it could appear. Ideally, such changes should be made independently on each individual wiki.
 * There are various counterarguments to a justification turned on across the wikis. Two random examples:
 * Justification works if hyphenation is turned on. Otherwise, the spaces are too large, and a distracting river effect appears. However, not all browsers support the hyphenation.
 * Various languages and scripts have different hyphenation rules. It'd be difficult to ensure proper behavior across the language versions of Wikimedia projects.
 * SGrabarczuk (WMF) (talk) 13:34, 13 April 2021 (UTC)
 * SGrabarczuk (WMF) (talk) 13:34, 13 April 2021 (UTC)
 * SGrabarczuk (WMF) (talk) 13:34, 13 April 2021 (UTC)

I truly dislike the limited content width on Serbian Wikipedia (this is an under-statement)
The limited content width that recently appeared on Serbian Wikipedia really bothers me to that extent that I always end up going to read Wikipedia in another language. The amount of text that you can read on the screen is terribly limited, and this is particularly true for Wikipedias written in Cyrillic script where the letters are wider. The other thing of huge concern is that anonymous readers are not given the ability to choose their display. Remember that Wikipedia exists for billions of anonymous readers around the world. And also, that they do not have the right to vote or express their opinion. I truly hope that an option for every reader to choose their display will be allowed. Thank you. - Emilijaknezevic (talk) 02:47, 6 April 2021 (UTC)

No moving/changing elements on page
Hello, in general I appreciate the efforts to improve our wiki skin. I would like to ask you, though, not to put changing elements on a wiki page. On the page I see now elements change constantly for the A/B illustration. It is very annoying for me when something is moving on a page, because I cannot concentrate then on the text. It would be better for me if I had to click on a button in order to start/pause a changing element. Kind regards Ziko (talk) 15:10, 6 April 2021 (UTC)


 * @Ziko, would you be able to specify which elements are changing? Thank you! SGrabarczuk (WMF) (talk) 13:36, 13 April 2021 (UTC)

New Search Widget Complaint.
I was enjoying the vector improvements very much until the most recent changes to the search widget. Currently images for similar searchs are visable alongside their articles, although this initially seems helpful, it makes it near impossible to avoid viewing sexual or violent images, for example upon entering the two letters "an" you are immediately greeted with a graphic depiction of anal sex.

I am aware wikipedia is not censored but surely there should be a skin option to turn off images in the widget so such imagery is not effectively mandatory to view for users even if their respective pages are not read the by the user.

I think this especially important, as this the default skin and introduction the majority of readers get to wikipedia, And as a large amount of the world have obections to such content, it is not an excellent introduction to potential wikipedians.

Several other skins also have this issue, and it would be nice to at least have the option to disable unavoidable images in the searchbar especially as the  page on "options to hide images" does not resolve the problem. — Preceding unsigned comment added by Transcendent Presence (User talk:Transcendent Presence • Special:Contributions/Transcendent Presence) 05:24, 11 April 2021‎ (UTC)
 * It is possible to turn off the images in the search results by editing common.css and adding a rule to not display background images for spans of the class .wvui-typeahead-suggestion__thumbnail . Something like span.wvui-typeahead-suggestion__thumbnail {

background-image:none !important; }
 * Vexations (talk) 21:35, 13 April 2021 (UTC)

Thank you very very much! incredibly helpful.

Are the Main page sections meant to be numbered?
I'm seeing the secitons on the Main page 'numbered'. Is this by design on this new version of Vector? HughLilly (talk) 01:38, 14 April 2021 (UTC)
 * Heading numbering is a feature that can be enabled and disabled from your preferences in the Appearance section and has always been a feature. —Th e DJ (Not WMF) (talk • contribs) 10:47, 14 April 2021 (UTC)
 * Hi @HughLilly, TheDJ is right, this feature is independent from the skin choice. We don't have any plan or even intention to make it a part of the new Vector. SGrabarczuk (WMF) (talk) 12:40, 14 April 2021 (UTC)
 * Oh, thanks; I must've turned it on without realising. Thank you. HughLilly (talk) 23:07, 14 April 2021 (UTC)

image collage problems with limited content width and voting question
As we can see in (https://di-collapsible-sidebar-2.firebaseapp.com/Lute) there's a big problem with image collages etc. in the limited content width version of this project. How is this going the be solved? And is there going to be some sort of voting from the community whether changes get implemented? Just "opting out" from a combination of different features and getting that number below 40% is not the way this is supposed to be handled in my opinion. I would like to know when changes get final. And when are we going to see solutions/discussions about my first question and solutions for people with large monitors? Because I'm truly afraid of this content width change. Coldbolt (talk) 22:41, 18 April 2021 (UTC)


 * Hi @Coldbolt! I understand the width issue is important for you, and I remember you've got a large screen. Unfortunately, we haven't formed an answer to your first question posted earlier on this page yet. I assure you, this isn't because we don't consider the point you're raising as important. We just need to conclude other topics first to get to that point. When we have and answer about the large screen support, we'll definitely let you know.
 * What you've found is a collapsible sidebar prototype. Templates, CSS classes and styles etc. are not related to the collapsible sidebar, and may not work properly in the prototype. When you check how that article looks with our changes, you will notice that there is no problem with image collages.
 * Now, we are working just with the communities who have volunteered (or accepted our offer) to get our features first. We've got, if I recall correctly, something like 8-10% opt-out rate in average across those wikis. So it's clearly way below 40%.
 * Before the changes get final (this should happen by the end of the calendar year) we will begin communicating why we are introducing the changes, how these are working, where our data come from, where to share feedback, etc. A post on the Foundation blog will appear soon. This will be a series of blog posts, really. Last but not least, Olga (the manager) and I will personally put a lot of effort to make this collaborative, and the current state is far from the final look. SGrabarczuk (WMF) (talk) 11:09, 19 April 2021 (UTC)


 * This really was the answer I was looking for, thanks! Thanks for listening, doing so much research, and being so clear on what to expect. I'm looking forward to the blog posts, results and more. Coldbolt (talk) 11:22, 19 April 2021 (UTC)

No content above the fold in narrow view
In web design, it’s a basic thing how much content appears “above the fold”, i.e. without scrolling. Well, if the viewport width is at most 720px, it’s zero. The page title appears around 1420px below the top of the page in my 665×705px slightly portrayish browser window on MediaWiki, i.e. it’s not even that no content appears above the fold, but I scrolled a full viewport height, and there’s still no content, only interwiki links and namespace tabs! I know that the sidebar is collapsed by default for logged-out readers, but this is not okay at all for logged-in editors either. I don’t know how to solve this, but something should definitely be done about it. —Tacsipacsi (talk) 19:56, 19 April 2021 (UTC)

indentation lists with Microsoft Edge
Hello, I wanted to inform you that the indentation of bulleted and numbered lists on Microsoft Edge in vec.wiki are without indentation, while on Chrome the indentation is correct. is it my problem or has the problem already been found? -- ꜰɪᴇʀᴏᴅᴇʟᴠᴇɴᴇᴛᴏ (Talk)-(Contributions) 11:39, 4 May 2021 (UTC)


 * Hello @Fierodelveneto. Would you be able to share some screenshots? I've checked Edge and Firefox, and haven't noticed any difference between vec and any other wiki. I'm afraid this might be due to your personal settings. Thank you! SGrabarczuk (WMF) (talk) 22:23, 6 May 2021 (UTC)

Мне кажется, что новый список языков — плохая идея
Плюсы — появился поиск в списке языков, но это очень маленький плюс. Но лично по моему опыту список языков используется в основном так: Теперь приходится делать дополнительные прицельные клики там, где раньше можно было обойтись прокруткой или даже она не требовалась. Плюс выпадающее окошко имеет свою полосу прокрутки. В некоторых трудноуловимых случаях браузер вместо того, чтобы прокручивать текст в окошке, начинает прокручивать всю страницу. Это, конечно, проблема браузера, но это тоже раздражает и усложняет взаимодействие со списком языков. Плюс группировка языков только мешает, когда нужно пройтись по всем языкам: уже просмотренные никак не выделяются, а в список они попадают несколько раз.
 * Есть два-три «любимых» языка (обычно те, которые сам немножечко знаешь), которые нужны чаще всего;
 * Нужно узнать, есть ли статья на одном из языков, чаще всего — из списка «любимых», либо имеющем отношение к теме статьи;
 * Нужно прощёлкать все языки подряд, например, например, в надежде найти авторитетные источники на другом языке.

В общем, если ваши инженеры по UI/UX считают, что новый список языков — это хорошо, то пусть они хотя бы сделают возможность переключиться на старый вид.--Tucvbif (talk) 08:45, 6 May 2021 (UTC)

Adding Interwikis / Wikidata element and hover of quality badges
I just realised that with having the language links moved to the top spot, also the old link for adding the Wikidata connection / other language versions to an article has apparently vanished. How is that supposed to work in the future? Another thing I noticed in that context is that the star icons for good/featured articles next to the language links do not show good/featured on hover anymore, which makes them less helpful. Regards --XanonymusX (talk) 20:15, 7 May 2021 (UTC)
 * Removing the link for adding the Wikidata connection / other language versions to an article seems like a bad idea. Related to this you can't start the translation tool through-out a speciic article anymore. (When using the drop down link near "contributions" you must specify the article you want to translate.) –—2003:E5:1F28:59F6:946F:EBCE:2900:60D3 09:53, 10 May 2021 (UTC)
 * @XanonymusX - Thanks for the feedback. Could you give some more info on what you're seeing on the on-hover behavior?  I'm currently seeing the tooltips as before when hovering: "This is a featured article.  Click here for more information".  In terms of the links for adding Wikidata items and other language versions - these will be available again later on within a new version of the Universal Language Selector (the selector that appears once you click the button) that the Language team is currently working on.   OVasileva (WMF) (talk) 14:03, 10 May 2021 (UTC)
 * IMO, it's en.m with the bottom headers re-added and a hamburger menu that doesn't actually save much space. And just like en.m, the Categories bar is still missing. If I wanted en.m, I'd use en.m. --Dogcow (talk) 22:45, 10 May 2021 (UTC)
 * @OVasileva (WMF): Sure! I just did the direct comparison. In the language menu of Vector Legacy, every li.interlanguage-link.badge-goodarticle has lesenswerter Artikel (good article) added as its title, which then appears as tooltip when hovering over the marker containing the badge. In the new Vector, the title attribute contains the name of the language instead (which is unnecessary, since the language link has its own title attribute with language and article name), so there is no way to find out what the star/badge is supposed to mean on hover. The title attribute should be used the same way as in the old language menu.--XanonymusX (talk) 12:22, 11 May 2021 (UTC)

The new language selector ignores my preferences
The new language selector ignores my language preferences, instead of showing the language versions I prefer first I need to search for them. The language selector also gives me quick access to my language preferences which makes it even odder that it ignores them. I can imagine this is a known issue but I had to revert to old Vector which is sad as your improvements are great. Abbe98 (talk) 11:52, 9 May 2021 (UTC)


 * @Abbe98 - thank you for the feedback and apologies for this issue. We are aware of the bug and are currently tracking this in phabricator (Suggested language list not available for ULS version in new language button). We hope to have a fix ready this week or next week.   OVasileva (WMF) (talk) 14:05, 10 May 2021 (UTC)
 * Thank you! I subscribed to the ticket so that I can turn this on once it has been deployed. Abbe98 (talk) 15:09, 10 May 2021 (UTC)

Minor optimisation on readability
Some friends and I thought Vector has become too white that reduces readability, so I did some minor CSS tweaks just for experiments.


 * Bright grey background colour for the outer space
 * Slightly larger font size
 * Borderlines and box shadows for the body and sidebar

The values are largely influenced by Skin:Timeless since the author (Isarra et al.) did make an effort on readability.

My CSS files (on English & Chinese Wikipedias) also fix some minor bugs regarding to undefined More button (not available for some people), the language menu at the bottom of the main page, and the colour of search bar.

They are simply my experiments for my personal taste so they may not satisfy every one. Feel free to comment or try it yourself by adding the following to your custom Vector CSS file:

🐱💬 03:59, 19 May 2021 (UTC)

Die Monitorbreite
… sollte bitte weiterhin ausgenutzt werden. Die Inhalte zusammenquetschen entspricht möglicherweise den Wünschen der nur-Schmiertelefon-Nutzern, doch für alle, die einen echten Rechner benutzen, ist ein zusammengequetschtes Layout mit weißen Streifen rechts und links nicht nur nervig, es behindert auch das Einbinden von Bildern.

In diesem Zusammenhang wäre auch eine globale und geräteübergreifende Abschaltmöglichkeit der Mobilansicht wünschenswert. Schmiertelefone lassen sich im Querformat benutzen und bei Tablets ist die Mobilansicht ebenfalls verzichtbar. –Falk2 (talk) 16:14, 25 May 2021 (UTC)

Language Selector misunderstandable
Hello everyone,

I'd like to raise an issue on the language Selector: As it's presented now, it might let you think: "Well I'm going to see THIS TEXT in another language!" aka reading in mother-tongue. We all know, this is not the case. Even worse, the pages and content can differ significantly. This is not only true for project pages, but also for content pages. As an example see Q788553.

I think this is a big problem, because the Wikimedia-Projects do not work like that. I do see the idea behind placing the option more prominently. But I think that the underlying mechanism should be "really" clear! The Problem probably is: keeping the "Option" short ("languages") collides with a more identifiable explanation. Maybe the best Option is a short explanation when opening the language selector? Something like: "Visit the same page of another language project"? idk...

Best regards --HirnSpuk (talk) 16:03, 26 May 2021 (UTC)

Content display width
Hello! I just tried this new skin a few minutes ago. I am wondering about one thing. Please compare Preferences and an article. Doesn't the vector-menu-content-list look wrong? In Preferences, the content is protruding to the left of the tabs. This problem occurs in jawikivoyage, dewikivoyage, frwikipedia... but not in enwikivoyage. -- Tmv ( talk ) 09:32, 2 June 2021 (UTC)

Idea: “persist_skin” URL parameter to retain skin preference in browser cookie, inspired by YouTube
I would like to share an idea from YouTube's website, which has both a desktop and a mobile front end. For temporarily recalling either version, one uses the  URL parameter, with   or   respectively. But that is just for one page load.

But YouTube also has allows retaining the skin preference in a browser cookie using the  URL parameter;   also works. As a side note, YouTube also stores the light/dark theme preference in a browser cookie.

Until 2020, there was also a  URL parameter, where one could recall the pre-2017 YouTube theme, which is HTML-based instead of AJAX-based, which was, as far as I can remember, retained in the URL to keep using the non-polymer version. I am generally against AJAX-loaded pages, as it demolishes accessibility and increases loading times for the sake of looking more like a mobile app.

Sure, one could just create an account for choosing a preferred skin, but many MediaWiki-based wikis on the Internet are read-only, lacking the support for account creation. Also, when accessing from a public computer, logging in for this purpose is inconvenient.

Furthermore, the ability to retain the desktop or mobile front end setting without login already exists, so it should also exist for skins themselves.

As soon as the new Vector skin becomes default, I suggest renaming its legacy version to "vector2010", "vector10", or similar, so that those who prefer it can keep using it by appending, which applies the skin preference to a browser cookie. One could also use monobook with.

I hope this improvement will be considered.