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)

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)