Talk:Reading/Web/Desktop Improvements

From mediawiki.org

Discussions: Desktop ImprovementsAccessibility for reading. If you would like to follow our technical work closely, this is what we're doing now.


You can comment in any language. We are especially interested in:

  • Feedback on the functionalities we have already deployed,
  • Expanding the list of existing gadgets and user scripts that are related to providing a better desktop experience.

We are discussing with many volunteers and communities at the same time. It may take some time for us to reply here. We apologize for that.

Thank you!

(Translate this page)

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)Reply

You will need to use the ```{{clear}}``` 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)Reply
@Jdlrobson: 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
main::after {
	content: "";
	display: block;
	clear: both;
}
needs to be placed in whatever CSS/LESS file it belongs to. —Tacsipacsi (talk) 00:07, 11 March 2021 (UTC)Reply
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 phab:T277218 to document the problem. Jdlrobson (talk) 19:40, 11 March 2021 (UTC)Reply
@Jdlrobson: 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)Reply

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)Reply

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)Reply

@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... ;)
(See the rest in my answer to the "Night mode clash" below.) SGrabarczuk (WMF) (talk) 23:55, 10 March 2021 (UTC)Reply
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)Reply

Night mode clash

Hi @SGrabarczuk (WMF):

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)Reply

@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)Reply
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)Reply

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#1. Readability: 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)Reply

@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)Reply
@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)Reply
@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)Reply
Best design!
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)Reply
@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)Reply

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)Reply

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)Reply
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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply
@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)Reply

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)Reply

@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)Reply
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)Reply
@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)Reply

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)Reply

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

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

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)Reply

I have an  additional idea: 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)Reply

The original language list will no longer appear on the sidebar

@SGrabarczuk (WMF): 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#mw-prefsection-rendering and m:Special:GlobalPreferences#mw-prefsection-rendering)?
  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)Reply

Captured in phab:T277517 Jdlrobson (talk) 00:18, 18 March 2021 (UTC)Reply
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)Reply

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)Reply

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)Reply
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)Reply

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)Reply

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)Reply

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 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)Reply

@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)Reply

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 w:List of ISO 639-1 codes go to the edge of the screen only makes the table harder to read.

Another issue: w: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)Reply

This is tracked in https://phabricator.wikimedia.org/T267161. Thanks for reporting! Jdlrobson (talk) 14:48, 26 March 2021 (UTC)Reply

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)Reply

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)Reply

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)Reply

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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply

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)Reply

@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:
  1. 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.
  2. 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)Reply

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)Reply

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)Reply

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

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 (talkcontribs) 05:24, 11 April 2021‎ (UTC)Reply

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)Reply

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)Reply

@HughLilly: Heading numbering is a feature that can be enabled and disabled from your preferences in the Appearance section and has always been a feature. —TheDJ (Not WMF) (talkcontribs) 10:47, 14 April 2021 (UTC)Reply
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)Reply
Oh, thanks; I must've turned it on without realising. Thank you. HughLilly (talk) 23:07, 14 April 2021 (UTC)Reply

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)Reply

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)Reply
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)Reply

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)Reply

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)Reply

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)Reply

Мне кажется, что новый список языков — плохая идея

Плюсы — появился поиск в списке языков, но это очень маленький плюс. Но лично по моему опыту список языков используется в основном так:

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

Теперь приходится делать дополнительные прицельные клики там, где раньше можно было обойтись прокруткой или даже она не требовалась. Плюс выпадающее окошко имеет свою полосу прокрутки. В некоторых трудноуловимых случаях браузер вместо того, чтобы прокручивать текст в окошке, начинает прокручивать всю страницу. Это, конечно, проблема браузера, но это тоже раздражает и усложняет взаимодействие со списком языков. Плюс группировка языков только мешает, когда нужно пройтись по всем языкам: уже просмотренные никак не выделяются, а в список они попадают несколько раз.

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

@Tucvbif, спасибо за ваши наблюдения. Я думаю, что некоторые из них нуждаются в пояснении. Скорее всего, мы добавим дополнительные кнопки к наиболее часто используемым языкам. Кроме того, вы можете искать по списку. Вам не нужно прокручивать. В этом году языковая группа внесет улучшения в сам список языков. Если по какой-то причине вас все еще не устраивает, вы сможете переключиться на «Устаревший» вектор. Мы предусмотрели эту возможность в самом начале наших изменений. (Thank you for your observations. I think some of these need clarification. Most probably, we will put additional buttons to the most used languages. Apart from that, you are able to search the list. You don't have to scroll. This year, the Language team will deploy improvements to the language list itself. If for some reason you are still not satisfied, you'll be able to switch to the "Legacy" Vector. We provided this option at the very beginning of our changes.) SGrabarczuk (WMF) (talk) 20:38, 1 July 2021 (UTC)Reply

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)Reply

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)Reply
@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)Reply
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)Reply
@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)Reply

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)Reply

@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)Reply
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)Reply

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:

@import url(https://en.wikipedia.org/w/load.php?lang=en&modules=user.styles&only=styles&skin=vector&user=Meow);

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

Thanks @Meow! Just for clarification, you have you modified the version after our changes (the "modern" Vector), haven't you? Also @AHollender (WMF), you may find that interesting. SGrabarczuk (WMF) (talk) 20:15, 1 July 2021 (UTC)Reply
Sure it’s based on the modern Vector skin, not the legacy one. 🐱💬 02:46, 2 July 2021 (UTC)Reply

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)Reply

Danke @Falk2. Hast du unsere FAQ gelesen? Auf dieser Seite erklären wir diese Änderung. Außerdem wissen wir, dass diejenigen, die große Monitore haben, andere Lösungen bevorzugen. (Thank you. Have you read our FAQ? On that page, we are explaining this change. Also, we know that those who have large monitors prefer different solutions.) SGrabarczuk (WMF) (talk) 20:03, 1 July 2021 (UTC)Reply

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 wikidata: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)Reply

Thanks @HirnSpuk, that's an interesting perspective. Actually, this is worth discussing across the Wikimedia Foundation teams. Our team is only moving the language link list to the new button, while the Language team is working on improving the language list itself. SGrabarczuk (WMF) (talk) 19:59, 1 July 2021 (UTC)Reply

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)Reply

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 app= URL parameter, with app=desktop or app=m respectively. But that is just for one page load.

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

Until 2020, there was also a disable_polymer= 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 ?useskin=vector2010&persist_skin=1, which applies the skin preference to a browser cookie. One could also use monobook with ?useskin=monobook&persist_skin=1.

I hope this improvement will be considered.

There's an option to add ?useskinversion=1 or ?useskinversion=2 already. The first forces the Legacy Vector and may be useful on wikis with the modern as default, the latter works inversely. But those only work for each individual loading of a page. In order to have the same non-standard skin loaded each time, one needs to be logged-in and set their preferences. SGrabarczuk (WMF) (talk) 20:44, 1 July 2021 (UTC)Reply

Article tools prototype

I came across this prototype, and just wanted to say that I like it quite a bit! Collapsing the tools is needed to make the sidebar more accessible, and the more menu is a great place to put it. I'm not sure how eager the rest of the community will be about it, though; see w:Wikipedia:Requests for comment/2020 left sidebar update#Autocollapsing for an important precedent. Sdkb (talk) 17:05, 12 June 2021 (UTC)Reply

Hey, thanks for your opinion and the link to the RfC! Our plan is to integrate article tools and put these aside from site-wide tools. Now, some article tools are on top (such as Move) some are in the sidebar (Wikidata item) where site-wide tools are as well (Recent changes, etc.) We will be working on this later this year. Just as usual, we'll measure the communities' reception. After each deployment, we run an A/B test on all early adopter wikis and check if the change is actually an improvement. SGrabarczuk (WMF) (talk) 19:35, 1 July 2021 (UTC)Reply

I love the new width of the page

Please don't change it, or let others convince you to change it. The narrower width makes the reading much more comfortable, it looks more modern, and the eye can find the next line with ease. Blank space is not a problem, and who complains about it just needs to get used to it; the strangeness will go away eventually. If blank space were a problem, you should tell that to Facebook. Its feed also has lots of empty space around it. What's the problem?

The new Vector is the best skin in the history of Wikipedia. Congrats from a Portuguese Wikipedia editor. Bageense (talk) 18:38, 20 June 2021 (UTC)Reply

Thank you @Bageense, this is very kind! All team members were really glad to hear that. While we can't promise we wouldn't listen to volunteers with various perspectives, we do hope that the limited width will be considered as an improvement. SGrabarczuk (WMF) (talk) 19:22, 1 July 2021 (UTC)Reply

Impact of Language switching on the "Download as PDF"

Hi, on French Wikipedia someone notice that the Language switching has a negative impact when you download an article with a lot of language versions (for exemple, try with Grenoble): PDF begins with the list of languages (2 pages for my exemple), but those pages are not desired by the user.--Patafisik (WMF) (talk) 15:54, 24 June 2021 (UTC)Reply

Salut Patafisik, it will probably be fixed this week. --Thibaut120094 (talk) 16:34, 24 June 2021 (UTC)Reply
Thank you!--Patafisik (WMF) (talk) 17:19, 24 June 2021 (UTC)Reply

Bug : absence de basculement des liens interlangues

Bonjour,

Bug déjà signalé sur WP-fr, mais je le signale ici.

Problème : les liens interlangues s'affichent toujours à leur ancien emplacement (menu latéral gauche), le nouveau bouton n'apparaît pas.

Circonstances :

  • Comptes enregistrés sur lequel le bug est reproduit : Jules* (Firefox) et Bot de pluie (Google Chrome) ;
  • Comptes avec la nouvelle version de Vector activée (case des préférences pour revenir à l'ancienne version désactivée) ;
  • Cache purgé ;
  • Bug persiste sur le compte Jules* avec les pages .css et .js vides (0 script) ;
  • Bug persiste sur le compte Bot de pluie avec les pages .css et .js vides (0 script) et tous les gadgets désactivés dans les préférences ;
  • Sous IP (Firefox et Chrome), RAS, pas de bug.

Cdlt, Jules* (talk) 10:02, 25 June 2021 (UTC)Reply

Bonjour, même problème pour moi, les liens apparaissent au nouvel emplacement sous IP (Firefox et Edge). nouvelle version de Vector activée, Cache purgé. Pas testé de désactiver les gadgets et vider les pages .css et .js. Bon courage. - AvatarFR (talk) 11:11, 25 June 2021 (UTC)Reply
C'est mon cas : interlangues à l'emplacement habituel quand je suis connecté, au nouvel emplacement quand déconnecté. Je n'ai pas de CSS ou JS personnalisé. Jean-Christophe BENOIST (discuter) 25 juin 2021 à 13:39 (CEST)
en béta : Nouveau lecteur vidéo, Différences visuelles, Outils de discussion, Traduction de contenu. En gadget : ArchiveLinks, LastContrib, Réduction d'URL, EditZeroth, OngletPurge, PublierBrouillon, ResumeDeluxe, WikiEd, ProveIt, MonobookToolbarStandard , ContribsRange, WatchlistNotice, RevertDiff, Wdsearch, OptimizedShort, CarRename. Jean-Christophe BENOIST (discuter) 25 juin 2021 à 13:54 (CEST) (original message on fr.wiki --Patafisik (WMF) (talk) 12:11, 25 June 2021 (UTC))Reply

link to other languages

Hi, the french wikipedia is experimenting the improvement for languages: the links to other languages are now hidden behind a button (in the main page the button is at the bottom-> very hard to see). It s annoying , my feedback: better before. Anonymous — Preceding unsigned comment added by 145.242.20.121 (talkcontribs) , 25 June 2021

Impact of Language switching on the Main page (fr.wikipedia)

Hi, the Main page of the French Wikipedia shows the button of the Language switching at the end of the page. Some users don't find languages, some others say that this location is uncomfortable, some users answer to have languages on the top or at the left, like in others pages. See here, here, here and here. Thank you.--Patafisik (WMF) (talk) 08:25, 26 June 2021 (UTC)Reply

See also a topic on Reddit, where some readers express their confusion about this change [1]--Yodaspirine (talk) 13:15, 27 June 2021 (UTC)Reply
This. The original version of Vector was clear, simple, legible, and mastered by all. I have yet to find one real world user that enjoys the new version. Absolutely nobody asked for any of the currently proposed changes on the French version. Since the first introduction of those changes I found myself switching to the english versions of the articles more often than not because the centered content makes the page needlessly long and way less legible. Now you're turning this action from easy and intuitive to something convoluted, on purpose? Please consult users/visitors before unilaterally changing a design that wasn't broken and introduce confusing and misleading modifications. That only serves to satisfy someone's need for change while making browsing unnecessarily more complex and confusing for millions (billions?) of people. --Eskaps (talk) 19:40, 27 June 2021 (UTC)Reply
Hi, I understand that the reason why the language button were moved was to make sure they're always visible from the top of the page. While this is a legitimate concern the current solution is creating much more problem than it is fixing. Quickly changing the language of the article is probably the feature that I use the most on Wikipedia, in fact I use multiple time a day. And the people who responded to the reddit post linked previously shared the same experience. Perhaps this is not something than the current tools used to evaluate how the user navigate on Wikipedia was highlighting but this is clearly an overview and I really urge the developer to take into account these returns.--JllllllV (talk) 18:33, 27 June 2021 (UTC)Reply
Bonjour @Eskaps and JllllllV: , merci pour votre retour, je prends note de vos remarques. Je comprends que ce changement vous affecte beaucoup.
SGrabarczuk (WMF) a présenté la novelle fonctionnalité le 22 mai et a donné des réponses qui pourraient vous intéresser, notamment par rapport à la collecte des avis des utilisateurs avant le déploiement de la fonctionnalité et les tests A/B. Le 22 juin la fonctionnalité a été à nouveau annoncée au Bistro. J'ai cherché d'ajouter d'autres détails dans ma présentation au Bistro le 24 juin.
Vous pouvez toujours garder votre interface préférée et basculer vers l'ancien habillage : le lien est dans la barre à gauche, ou dans Préférences > Apparence > en cochant la case "Utiliser l'ancienne version de Vector".
Cordialement,--Patafisik (WMF) (talk) 09:22, 28 June 2021 (UTC)Reply
@Patafisik: , I'm not interested using the old layout, I find most of the change to be positive. As I said the habitability to quickly switch between languages is an integral part of the way I use Wikipedia everyday. And given the reaction a simple reddit post received in a few hours I am not the only one. As I already said, I read what motivated the changes and I understand why the dev team felt they needed to do something. But the solution is worse than the problem. There are already testimonies from people telling that using the new layout, when they arrive on an article available in multiple language they didn't even realize it was available in another language. And when they did, they did not know how to switch to the new language. And this is coming from people who are familiar with Wikipedia. What can be done to help the team do better on that topic? --JllllllV (talk) 11:26, 28 June 2021 (UTC)Reply

@JllllllV: and @alls: Thank you for writing. When you report problems and comment a new feature in this page, if you don't know, you are precisely helping us to understand if we are going in the right direction or not, if community like it or not, if the usability of the new feature is good or not, and it helps us to correct the direction if needed and fix bugs ! :) You can see the progress on Phabricator, the progress is due to your feedback.

Feedbacks from users and readers where already collected and analysed for create the prototype before the deployement on the pilots wikis (see here and here). I'm currently collecting all users' feedbacks and I have explained the topic to SGrabarczuk of the Web Team, they are discussing about the better way to act, considering all the variables. My goal is also to improve our ability as Web Team to collect feedbacks from / to give feedbacks to the French community, to communicate news but also understand to better way to communicate about the development process.

When a new feature is deployed, a period of transition is necessary: I understand the confusion of a lot of users and the impact of the Language switching mostly on experienced contributors. Some users like you are proposing solutions to make it easier for all to understand how and when new features are deployed, and I'm presenting your suggestions to the Web Team and staying tuned.

About the Language switching, tests A/B are presently in progress, this will be the case for two weeks : it means that we are collecting informations about the real use of the feature, what are the problems of users to find the button of languages or to understand what it is, if they prefer the old interface etc. At the same time, bugs are being fixed. Those data will be analysed and major decisions will be made based on your feedback. Transition takes time, and I'm sorry that the feature is not still perfect and that this period should be uncomfortable for experienced users like you and others*, but it is a temporary disease, we need to collect data and we are doing our best to reduce this disease. When you say « the solution is worse than the problem », I hope to have offered to you the reasons why for some of you this should be only a temporary unconfortable period, in the short term, and how we are really trying to prepare a better feature for the medium and long term.--Patafisik (WMF) (talk) 14:56, 28 June 2021 (UTC)Reply

* But some users loves the changes.

About the impact of Language switching on the Main page: I have found this task T276140 on Phabricator which could explain why the Main page doesn't shows the link of language switching at the top.--Patafisik (WMF) (talk) 14:56, 28 June 2021 (UTC)Reply

Language switching : Geographic coordinates under the line of the title of an article

(original message on fr.wiki by @Daehan: ) e.g. in the article Musée de Rimini: with the new Language switching button, the geographic coordinates are under the line of the title of the article. Between the line and the beginnig of the article there is now a lot of space.--Patafisik (WMF) (talk) 10:24, 26 June 2021 (UTC)Reply

Nouveau menu des langue sur Wikipédia/Wikitionnaire français

Bonjour, le nouveau menu pour choisir la langue est pratique et permet de se rapprocher de l'application smartphone. En revanche il y a un point embêtant, c'est que l'ancien menu a disparu partout, même sur la page d'accueil où il n'y a pas ce nouveau menu. Hors je me servais souvent de ce menu pour aller sur une autre version de Wikipédia/Wikitionnaire, à partir de la page d'accueil. Ainsi j'avais juste à cliquer sur mon favoris pour Wikipédia Français, et ensuite cliquer sur la langue. Là je suis soit obligé de chercher la langue sur Google, soit d'aller sur l'article français (s'il existe), puis sur la langue.

Si vous pouviez le remettre sur la page d'accueil, ça serait super :)

Merci d'avance. — Preceding unsigned comment added by 28 juin 2021 à 07:35‎ Quarante-quatre (talkcontribs)

Bonjour @Quarante-quatre: merci pour ce retour constructif. La remarque sur la page d'accueil de fr.wiki a été faite par plusieurs utilisateurs et je l'ai signalé ci-dessus, les langues se trouvent actuellement tout au fond de la page d'accueil sur la droite. Cordialement,--Patafisik (WMF) (talk) 09:04, 28 June 2021 (UTC)Reply

Language switching (Desktop Improvements): mouse hover pop-up ?

(original on fr.wiki) Actually, you need to click on the button of language to see others versions of an article. Some users don't understand what is the funcion of the button. In this case, the suggestion of @Warp3: could be useful: to have a pop-up when the pointer moves on the button with written "see this article in others languages".--Patafisik (WMF) (talk) 08:17, 29 June 2021 (UTC)Reply

Bonjour. En plus de ma suggestion, je trouve qu'il serait bien d'ajouter le code de la langue avec chaque nom de langue affiché (par exemple : recherche de “Code pays” donnerait entre autres : → Ländercode - allemand - de ).
English:
Hello. In addition to my suggestion, I think it would be nice to add the “language code” with each language item (eg: search for "Country code" would give among others : → Ländercode - German - de ).
--Warp3 (talk) 05:29, 1 July 2021 (UTC).Reply

Language switching (Desktop Improvements): search field of language

(original messagge on fr.wiki) Hi, when you search "fr" in the Language switching search field of fr.wiki, some articles (but not all) who exist in fr.wiki shows "This article doesn't exist in the language you are searching for" (Cette page n'est pas disponible dans la langue que vous recherchez). It is a search of the article we are reading. Instead, it should be displayed something like "You are already reading this article in this language."

--Patafisik (WMF) (talk) 10:12, 29 June 2021 (UTC)Reply

Thanks for flagging this. I was to create a task on Phabricator, but I think this might actually be up to the Language team as part of their improved Universal Language Selector. SGrabarczuk (WMF) (talk) 19:17, 1 July 2021 (UTC)Reply
New discussion here.--Patafisik (WMF) (talk) 11:03, 11 July 2021 (UTC)Reply

Opt-out of new design for logged-out users?

Why is the option to opt-out of the new design not made available to logged-out users?

I am a frequent reader of Wikipedia in its many languages, and I am almost always logged out due to proxy and security reasons. After being frustrated for many months at the amount that I had to scroll when looking through articles in the French and Korean wikis (due to the max-width change), and now recently having had the language links seemingly disappear in these wikis, I finally decided to look up what was going on, and I've just found out yesterday that the deployment of these desktop improvements was the cause. I've now logged in for the sole purpose of being able to opt-out of these changes (and secondarily to ask this question here).

As a related question, how are the perspectives of logged-out users (which, I presume, are the vast majority of readers of Wikipedia) taken into account when rolling out these features? I sometimes encounter a survey-type question that asks whether a page loaded quickly enough for me, which I can answer in a few seconds. Could a similar feature be used to collect quick, large-scale feedback from all users, including those not logged-in, on the new layout changes (for example, a prompt which asks "Is this page too long/wide/narrow?", which could perhaps be followed up by an option to switch layouts and give feedback on the other layout if the user answers yes)?

--Protocactus (talk) 22:42, 30 June 2021 (UTC)Reply

I agree with this request. Regards, --Warp3 (talk) 05:40, 1 July 2021 (UTC).Reply
Hello @Protocactus. Both of your questions are related to our technical limitations. We are not able to offer our readers (logged-out users) the opportunity to change the layout. This is because of the limited capability of our servers. We know these functionalities would be useful, though. SGrabarczuk (WMF) (talk) 18:28, 1 July 2021 (UTC)Reply
Certain things can be done with browser extensions if you care for them, with no or negligible impact on server resources. For example, content can be made wider with a simple extension (I don’t have accounts on Mozilla Add-Ons, Chrome Web Store or the like, so you need to build it yourself, or get someone who publishes it); it would be even better if the content action tabs were on the far right, not the same place as in the width-constrained version, and if it was actually full width, not just 1256px instead of 960px (both of these fixes should happen in Vector code to ensure it doesn’t break suddenly with other changes). Others, like the position of the language list, are not that easy to do in an extension, and even if done, almost certainly lead to flash of unstyled content. —Tacsipacsi (talk) 23:08, 1 July 2021 (UTC)Reply

Laguage switching not available in editing mode

(original messages here and here)

Desktop Improvement for editors : on French wikipedia, when you are in editing mode (logged-in or logged-out), the button of laguage switching doesn't appear. Editors ask for languages switching availables when they edit.--Patafisik (WMF) (talk) 16:00, 1 July 2021 (UTC)Reply

Language switching no longer available on wikidata and mediawiki

On wikidata, it was possible to change the language by clicking on the left of the displayed language. This is no longer possible: this just adds a "#" to the URL. One now needs to change the language in the preferences, which takes more time. I don't understand why such a useful feature has been removed. And the mediawiki pages seem to be affected too. — Vincent Lefèvre (talk) 23:50, 2 July 2021 (UTC)Reply

@Vincent Lefèvre: The language selector in the top right toolbar (next to my user name) works for me on this very page (with both the new and the old version of the Vector skin). If you have any JavaScript error messages, they’ll certainly help developers investigate the issue. —Tacsipacsi (talk) 01:46, 4 July 2021 (UTC)Reply
@Tacsipacsi: It is on the left of my user name, but it does nothing except adding a "#" to the URL. This does not trigger any JavaScript error. — Vincent Lefèvre (talk) 11:16, 4 July 2021 (UTC)Reply
@Vincent Lefèvre: Sorry for the late reply. Please also see point 5 on the linked page—without knowing what you use, it’s nearly impossible to reproduce the issue, and without reproducing or having error messages, it’s nearly impossible to fix it. —Tacsipacsi (talk) 12:56, 11 July 2021 (UTC)Reply
@Tacsipacsi: Skin: Vector (this is the default). Browser: Firefox 88.0.1 under Linux (Debian/unstable). I've also tested with a new profile: still the same issue, and still no errors in the console. — Vincent Lefèvre (talk) 00:04, 12 July 2021 (UTC)Reply
And same issue with Opera 77.0.4054.203 on the same machine. — Vincent Lefèvre (talk) 00:08, 12 July 2021 (UTC)Reply
I think this is a bug, but please check "Use a compact language list, with languages relevant to you." on Special:Preferences#mw-prefsection-rendering to restore it in the mean time. Jdlrobson (talk) 03:43, 12 July 2021 (UTC)Reply

Language switching button on French Wikipedia : text bold vs. normal and text black vs. blue

(original message on fr.wiki by @LPLT: , published here by --Patafisik (WMF) (talk) 09:52, 4 July 2021 (UTC))Reply

Pour ce qui est de la charte graphique, deux éléments à mon avis ne sont pas optimaux : 1/ l'usage du gras pour l'affichage (le gras est déconseillé sur WP) 2/ la police en noir, alors qu'instinctivement et pratiquement, tous les liens hypertexte sont en bleu. L'appel en noir est contre productif visuellement pour le clicage. LPLT [discu] 3 juillet 2021 à 20:21 (CEST)

New Vector theme does not span entire border

This is what I see

--Tyw7 (🗣️ Talk) — If (reply) then (ping me on en Wikipedia) 00:34, 6 July 2021 (UTC)Reply

Impact of Language switching on fr.wiki : badges are no longer shown next to interwiki links

(original message on fr.wiki)

Hi, star icons for good/featured articles are not shown next to interwiki links for connected users on fr.wiki (and there is no hover message to advise on articles or good/featured ones). Is there any possibility to fix it? Thanks.--Patafisik (WMF) (talk) 09:09, 11 July 2021 (UTC)Reply

@Patafisik (WMF): It doesn’t depend on whether the user is logged in, but on whether the language switcher uses JavaScript. Normally it should for both logged-in and logged-out users, but it could fail for various reasons (JS explicitly disabled in the browser, too old browser, conflicting other gadgets or user scripts etc.). If it fails, the one-column list shown on the third screenshot appears.
Even though this one-column list technically also contains the badges, they’re cut off. However, since everything is there in the HTML source code, they can be restored with a simple CSS snippet (it should ideally go to Vector’s source code, but as a hotfix, you can put it in a user stylesheet (e.g. fr:Special:MyPage/vector.css) or in a sitewide stylesheet (e.g. fr:MediaWiki:Vector.css) or gadget):
#p-lang-btn ul {
	margin-left: 1.6em;
}
(Please note that when put in user or sitewide stylesheets/gadgets, this may not work in right-to-left languages like Hebrew. When put in the Vector source code, however, it should automatically be rewritten appropriately to accommodate to RTL.) —Tacsipacsi (talk) 12:50, 11 July 2021 (UTC)Reply
Also, I didn’t test this much, so there may be edge cases where this doesn’t work, or kicks in even though it shouldn’t. —Tacsipacsi (talk) 12:53, 11 July 2021 (UTC)Reply
@Tacsipacsi: Thanks for explanations. @HB: j'espère que cela te permettra de résoudre le problème, s'il te faut une traduction du message je peux la faire, notifie-moi dans ce cas. :)--Patafisik (WMF) (talk) 13:08, 11 July 2021 (UTC)Reply
4. Logged-in, with Vector.css
Compact language links preference
@HB: Usefull information to all: I've tried to find the gadget or beta feature responsable of the problem but I've not found it. No scripts, JS available in the browser, last version of all browsers. So I'm using the suggested vector.css, this is the result (screenshot n. 4). It's fine for the badges. But the list is still different from the list of screenshot n. 1 (2 columns, suggested languages, "Paramètres d’affichage" and "Paramètres de saisie" in the box of the button, etc.). To fix it: Allez dans PréférencesApparence et descendez dans la page jusqu'à la section Langues. Vous trouverez une case à cocher, avec le texte « Utiliser une liste compacte de langues, avec seules celles qui vous conviennent. ». (voir Liens de langues compacts)
Best regards, --Patafisik (talk) 14:32, 11 July 2021 (UTC) Modified --Patafisik (talk) 14:58, 11 July 2021 (UTC)Reply
Still testing the feature, I've discovered that with the Compact Language Links activated the vector.css is not necessary, badges are presents.--Patafisik (talk) 15:07, 11 July 2021 (UTC)Reply
I didn’t know about this side effect of turning off compact language links (I’d consider it a bug, by the way, since at the new location, the list is neither longer nor shorter with either option). However, my point about the JavaScript-less experience still stands: users without JS get the one-column version even if they have compact language links enabled. —Tacsipacsi (talk) 16:02, 11 July 2021 (UTC)Reply
Thanks for all the informations!--Patafisik (WMF) (talk) 08:06, 12 July 2021 (UTC)Reply

Language switching (Desktop Improvements): not available (gadget conflict ?)

Though my fr.Wikipedia account is with standard vector, I do NOT benefit the new language menu in this fr.WP. Instead, I still have a (reduced) list of languages in the left column. I remind having, some years ago, "installed"… a, I guess: gadget (what else ; I have a slightly modified "Common.js", but not related to languages), so, gadget which permits to show only a tenth of languages, among which the ones I switch to the most (in my case : english, esperanto and picard are most frequently present there if the article is available). On the contrary, when in eo.Wikipedia, which did install the language menu, I do have it ; and by the way, I did very little if not none, specific customisations in my eo.WP preferences. Question : do you have a suggestion how I could track the "faulty gadget" ? (I use a bunch of these, and am not very happy about testing each one individually) Thanks in advance. -- Eric.LEWIN (talk) 12:49, 12 July 2021 (UTC)Reply

@Eric.LEWIN: The position of the language links doesn’t depend on any gadgets or other preferences. There’s currently an A/B test, so it’s decided at random whether you get the language links in the header, and apparently this random setting varies by wiki. You can force the new version on individual pages by appending ?languageinheader=1 to the article title (e.g. https://fr.wikipedia.org/wiki/Test_A/B?languageinheader=1), but that’s just for testing as manually appending it to all URLs is quite inconvenient. The only thing you can do is waiting until it becomes the default (or at least a preference; I don’t know whether making it a preference is planned). By the way, this reduced language list you mention is Compact Language Links, but it has nothing to do with whether you get the language links in the header (except for turning it off breaks the links if you get them in the header, see the previous section). —Tacsipacsi (talk) 21:59, 12 July 2021 (UTC)Reply
Many thanks, @Tacsipacsi: , for your clear explanations. I saw the expression "Test A/B", but did not know, and catch, its meaning, and in fact did not bother :-(. Effectively, your forcing recipe did work well. I'll let the test going on, hoping for a quick setting, whatever the choice, default or preference. And thanks for the ULS/CLL reminding. Minden köszönetemmel és üdvözletemmel a Francia Alpoktól (Google Translator). Best regards, cordialement. -- Eric.LEWIN (talk) 23:33, 12 July 2021 (UTC)Reply