Talk:Reading/Web/Desktop Improvements/Archive3

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


 * You will need to use the ```

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

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

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

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


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

Night mode clash
Hi

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

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


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

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


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


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

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


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

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

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

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

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

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


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

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

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

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


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

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

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


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

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


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


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

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

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

I have some ideas about how the sidebar moves:


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

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


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

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


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

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


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


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

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

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


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


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


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

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


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

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


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

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

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

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

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

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

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


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

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


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

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

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


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

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

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

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

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

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

Thank you very very much! incredibly helpful.

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

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


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


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

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

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


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

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

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


 * @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)
 * @SGrabarczuk (WMF) но мне не нужна тема «Устаревший Вектор», я как раз хочу пользоваться актуальной темой, и при этом иметь удобный список языков. По кнопкам «наиболее часто используемых языков» — они будут настраиваться один раз для всех языков, или мне нужно будет в каждом языковом разделе настраивать любимые языки отдельно? Кроме того, очень неудобным остаётся случай 3 (прощёлкать все языки подряд): нужно открывать список языков и искать среди них те, в которых ещё не побывал. Поиск тут не поможет, без прокрутки тут не обойтись, что делает список неудобным. Сначала нужно прицельно ткнуть в список языков, чтобы открыть его, потом перевести курсор на список, чтобы прокручивался он, а не вся страница, затем прокрутить, чтобы найти очередной непосещённый язык, и только после этого ткнуть в нужный язык. В старой версии достаточно было двух последних действий. --Tucvbif (talk) 12:14, 14 July 2021 (UTC)
 * И ещё вопрос: как будут добавляться интервики? Сейчас это неочевидно. --Tucvbif (talk) 12:27, 14 July 2021 (UTC)
 * Hey @Tucvbif.
 * Я думаю, что у нас будет более удобный список языков, когда языковая команда закончит свою работу.
 * «Oни будут настраиваться один раз для всех языков, или мне нужно будет в каждом языковом разделе настраивать любимые языки отдельно» — У каждой вики будут свои настройки. В дополнение к этому, кнопки будут настраиваться пользователем на основе индивидуального выбора.
 * «Поиск тут не поможет, без прокрутки тут не обойтись, что делает список неудобным» — Что ты имеешь в виду? Когда поиск не работает?
 * «Как будут добавляться интервики? Сейчас это неочевидно» — Команда обсуждает временное восстановление ссылки на Викиданные. Когда языковая команда сделает свое дело, ссылки на Викиданные будут добавлены по-новому.
 * English:
 * I think we will have a more convenient list of languages when the Language team finishes their job.
 * "Will they be configured once for all languages, or will I need to configure my favorite languages ​​separately in each language section?"—Each wiki will have its own setting. In addition to that, the buttons will be configurable by user based on individual choices.
 * "Searching will not help here, you cannot do without scrolling here, which makes the list inconvenient."—What do you mean? When doesn't the search work?
 * "How will interwiki be added? It is not obvious now"—The team is discussing to restore the link to Wikidata temporarily. When the Language team does their part, Wikidata links will be added in a new way.
 * SGrabarczuk (WMF) (talk) 19:11, 19 July 2021 (UTC)
 * SGrabarczuk (WMF) (talk) 19:11, 19 July 2021 (UTC)

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

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


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

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


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

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

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

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

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


 * 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)
 * Sure it’s based on the modern Vector skin, not the legacy one. 🐱💬 02:46, 2 July 2021 (UTC)

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

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


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

Language Selector misunderstandable
Hello everyone,

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

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

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


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

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)


 * Hello @Tmv, apologies for the late reply. Could you write more about the thing looking wrong? I didn't understand what you mean by the "vector-menu-content-list". SGrabarczuk (WMF) (talk) 17:39, 19 July 2021 (UTC)
 * @SGrabarczuk (WMF) The problem is happening on the special page. Using Preferences page as an example, a tab above the title "Preferences" is in the wrong place (in using English). The tab is where it says "Special page". Tmv  ( talk ) 09:34, 20 July 2021 (UTC)
 * @Tmv, do you mean you are confused because the Preferences page is wider than article pages? This is because of the setting of the limited width. On special pages, history pages, etc., the width is different because these pages have different type of content. But indeed, on English Wikivoyage, the Preferences page has a width of an article page. I'll investigate that. SGrabarczuk (WMF) (talk) 16:01, 20 July 2021 (UTC)

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

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

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

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

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

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

I hope this improvement will be considered.
 * There's an option to add  or   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)

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 for an important precedent. Sdkb (talk) 17:05, 12 June 2021 (UTC)


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

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)
 * Salut Patafisik, it will probably be fixed this week. --Thibaut120094 (talk) 16:34, 24 June 2021 (UTC)
 * Thank you!--Patafisik (WMF) (talk) 17:19, 24 June 2021 (UTC)

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 : (Firefox) et  (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 avec les pages .css et .js vides (0 script) ;
 * Bug persiste sur le compte 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)
 * 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)
 * 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))

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 , 25 June 2021

Language switching : Geographic coordinates under the line of the title of an article
(original message on fr.wiki by ) 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)

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.


 * Bonjour 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)

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 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)
 * 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 ).
 * 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).

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)


 * 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)
 * New discussion here.--Patafisik (WMF) (talk) 11:03, 11 July 2021 (UTC)

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)
 * I agree with this request. Regards, --Warp3 (talk) 05:40, 1 July 2021 (UTC).
 * 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)
 * 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)

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)

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)


 * 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)
 * 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)
 * 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)
 * 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)
 * And same issue with Opera 77.0.4054.203 on the same machine. — Vincent Lefèvre (talk) 00:08, 12 July 2021 (UTC)
 * I think this is a bug, but please check "Use a compact language list, with languages relevant to you." on Special:Preferences to restore it in the mean time. Jdlrobson (talk) 03:43, 12 July 2021 (UTC)
 * I've just seen that this has now apparently been fixed. — Vincent Lefèvre (talk) 15:35, 24 July 2021 (UTC)

Language switching button on French Wikipedia : text bold vs. normal and text black vs. blue
(original message on fr.wiki by, published here by --Patafisik (WMF) (talk) 09:52, 4 July 2021 (UTC))

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)

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)
 * 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):  (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)
 * 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)
 * Thanks for explanations. 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)
 * Screenshot exemple of icon - Featured articles - Language switching 4.png
 * Compact-language-links-preference.png
 * 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érences → Apparence 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)
 * 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)
 * 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)
 * Thanks for all the informations!--Patafisik (WMF) (talk) 08:06, 12 July 2021 (UTC)
 * "However, my point about the JavaScript-less experience still stands: users without JS get the one-column version" - this is a very small subset of our users. Right now our main focus in the majority of users who do have JS enabled.
 * This style could be shipped in a common CSS or site CSS for those users to rectify that in the interim:
 * Jdlrobson (talk) 16:34, 13 July 2021 (UTC)
 * The question here is not whether users without JS see one or three columns, but whether they see the badges for featured articles/good articles/etc., or don’t see them. Compatibility promises that in Grade C browsers (the most notable browsers without JS) content is presented in a readable manner . Badges cut off breaks this promise, since quality assessment is an important part of the content, and something that’s not visible isn’t readable either. And it takes literally three lines of CSS to fix it. —Tacsipacsi (talk) 18:35, 13 July 2021 (UTC)
 * I did a bit of digging and the badges are provided by the WikimediaBadges extension which is making some assumptions that are no longer true in modern Vector.
 * I've created T286612 and added a temporary workaround (feel free to revise/remove): https://fr.wikipedia.org/w/index.php?title=MediaWiki%3AVector.css&type=revision&diff=184622499&oldid=183232069 Jdlrobson (talk) 20:48, 13 July 2021 (UTC)

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)


 * 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  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)
 * Many thanks,, 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)
 * Hello @Eric.LEWIN. After the deployment of almost each feature, we run the A/B test. Tacsipacsi is correct. This does vary by wiki, and depends on your user ID (all who have even numbers can see one version, and those with odd numbers can see the other version). Usually, the A/B tests take two weeks. However, we may set up these again if something goes wrong. For instance, one time, we learned that the test wasn't set up precisely enough, and we didn't receive answers for questions we wanted to ask. Anyway, I expect the results to show up this week. SGrabarczuk (WMF) (talk) 16:59, 19 July 2021 (UTC)
 * Thanks for these infos. I was mainly offline since the 14th ; when I connected back this morning, it appears to me that I was now benefiting the language menu, whatever the reason or cause. And I still have taken advantage of it. Really a great feature, a major improvement from my point of view. I keep being attentive to it, and eventually I'll report in case I meet an ISA ("Incident, Surprise or Anomaly"). Best regards. -- Eric.LEWIN (talk) 18:28, 20 July 2021 (UTC)

Please move it up, again
I just would like to say that I like the new language selector, but I disapprove of it being placed at the bottom of the main page of a wiki. I am used to switching between language versions and I am sorry to say this, but it is a nuisance when you have to scroll to the very bottom of the main page in order to find the selector. You wonder, is there any selector at all? So, could you please move it up again to the top of the main page? Thanks! Aschmidt (talk) 19:48, 28 July 2021 (UTC)

Concrete suggestions for improvement
Hi, a year ago I submitted a critique and mockup for improvements. You could not fully take them into account because the links for some of the image files had expired. Because most of them are still relevant, I have uploaded them to Commons.

M!dgard (talk) 11:27, 22 July 2021 (UTC)


 * Thank you @M!dgard for the screenshots. I appreciate the effort. We take your opinion into account.
 * You are right about some elements, and these will be fixed. When will we do that, and why these imperfections exist? It's because our changes are gradual, and we'll be fixing these gradually.
 * The lack of alignment between the content and the user menu will be not relevant when we deploy the user menu.
 * The symetry of article tabs will be not relevant when we deploy the sticky header.
 * The selection and sequence of links in the sidebar are, for the most part, decided by the local communities. The Tools section will be put to the header as part of the article tools improvement.
 * The grey area on both sides of the screen will be a subject of discussion closer to the general aesthetic refinements phase (see the related Phabricator account).
 * I'm not able to answer to some of your points yet, sorry! Some are strictly related to the design and technical limitations (e.g. the "return" button by the sidebar, or the "page weight".) I'll discuss this with other members of our team. SGrabarczuk (WMF) (talk) 17:35, 27 July 2021 (UTC)
 * I'm not able to answer to some of your points yet, sorry! Some are strictly related to the design and technical limitations (e.g. the "return" button by the sidebar, or the "page weight".) I'll discuss this with other members of our team. SGrabarczuk (WMF) (talk) 17:35, 27 July 2021 (UTC)

Purging issue: swapping old and new look without switching
Sometimes when I go to any page, like a page using a non-main namespace, I saw an old look. However, I refreshed the page by clicking the refresh icon and pressing  +   keys, so the page automatically switches back to the newer look. Is there a purging issue or something like that? George Ho (talk) 23:04, 25 July 2021 (UTC)


 * Hi George, this is usually a sign that the page hasn't been visited recently and that a new feature was recently rolled out (usually within the 1 week). It's a known issue that corrects itself as you've pointed out, but we accept it as it reduces a lot of risk to our operations team who keep the site running. Jdlrobson (talk) 02:43, 11 August 2021 (UTC)

New vector language switching selector : title icons are no longer on the title line
Hello. On french wikipédia, icons created using the template   are no longer on the same line than the title but inside the page, and they occupy a full line. It is the case for example for the page protection indicator (example on article fr:Jules Verne). It is also the case for the numerous title icons used on user pages, where the rendering is no more what the user expected, although there is no language selector on user pages. It concerns a huge number of pages. Best regards Csar62 (talk) 17:20, 29 July 2021 (UTC)
 * At least on user pages, or more generally on pages without language selector, title icons should always stay on the title line
 * On pages with language selector, it is maybe questionable where the icons should be, but they should  not  use a full line just for the icons.
 * Ping Patafisik (WMF) . Jules* (talk) 10:40, 30 July 2021 (UTC)
 * Hello, two tasks are opened about this subject (and the coordinates display): T282027 and T281974. See also the answer below. --Patafisik (WMF) (talk) 16:53, 5 August 2021 (UTC)

Assessment icons and the upper right corner in the new display
I just came across the language switching feature that you have in development. Overall, I like it—collapsing makes sense, it's nice to see the total language count, and the positioning may make it easier for people to find. However, I anticipate an area of concern for the community (at least at en-WP) will be that this area is already currently used for other icons, particularly protection icons and good article/featured icons. When testing, these icons are currently pushed down below the bar underscoring the title, which in turn pushes anything normally right below the bar (namely coordinates) down another line. As you can see in the screenshot, this can cause overlap with the article content, and looks awkward even when it doesn't.

Moving the assessment icons somewhere else will be essential if we want to clear up that space. This brings me to a proposal we considered a few months ago to move the good/featured icons next to the article title, which I think you may find it very useful to read. The proposed placement is something that the Danish Wikipedia does and that has the potential to make the icons a lot more noticeable (something crucial for media-literate readers). However, the discussion reached a no consensus result, in large part because of uncertainty about how aware readers are of the GA/FA icons in their current placement. Other recent discussion about redesigning the icons' appearance has touched on similar themes. It would be extremely helpful if you could look into how the GA/FA icons are handled as part of your work, perhaps do some user research to determine if there are indeed issues with awareness (as I suspect), and incorporate the results into your improvements package. Would this be possible? &#123;{u&#124; Sdkb  }&#125;  talk 17:35, 3 August 2021 (UTC)


 * While moving assessment icons to a more discoverable position may be a good idea, doing so with all indicators (category pages’ help links, user pages’ random icons, and so on) isn’t. Using the current infrastructure, it’s possible to do so in Vector.js (for example that’s done on huwiki, although we put the icon before the title, not after, as dawiki). If you want to get it done without JS, the categorization system I proposed in T75299 may help to do it on server side. And not only in case of the GA/FA icons, but also for positioning the coordinates. —Tacsipacsi (talk) 00:41, 4 August 2021 (UTC)
 * Yeah, I wouldn't want to see all icons currently in the upper right moved to directly after the title. The protection icons in particular are quite common. The designers will have to figure out what to do with those if they want to put the language list where they are currently. &#123;{u&#124; Sdkb  }&#125;  talk 17:53, 5 August 2021 (UTC)
 * They have figured it out: what currently happens, i.e. indicators below the language link dropdown, and coordinates broken as long as the community doesn’t fix them. —Tacsipacsi (talk) 23:31, 5 August 2021 (UTC)

Renommage de la page "Brouillon" ?

 * copied from Topic:Wdygruogtnv10t42

(Pas sûr qu'ici soit le meilleur endroit pour cette discussion ; si vous voyez mieux, notamment plus visible mais tout autant approprié, merci de déplacer cette discussion, ou d'y mettre un mot et un lien).

Je trouve que le terme "brouillon" n'est pas le meilleur choix pour désigner cette page et sa fonction. J'utilise plus volontiers dans les discussions avec les nouveaux, les expressions de « zone d'ébauche », « page d'ébauchage », bref « ébauche », non pas que le sens soit fortement différent, mais parce qu'il est plus gratifiant quand on débute. C'est donc plus un choix psychologique, ou pédagogique, que sémantique. Qu'en pensez-vous ? -- Eric.LEWIN (talk) 19:50, 3 August 2021 (UTC)
 * Bonjour ! Chaque communauté peut choisir le meilleur mot pour décrire cela. C'est une question de décision locale. La Fondation ne change pas le libellé. SGrabarczuk (WMF) (talk) 01:22, 11 August 2021 (UTC)

New sidebar design
I think the sidebar is not user-friendly (i.e.: font too small, words too crowded, help link is not enough noticeable). Could you propose some ideas about it? --Daniele Pugliesi (talk) 17:29, 4 August 2021 (UTC)


 * Hello @Daniele Pugliesi! Thank you for asking. You are correct, the sidebar could be improved. We might at some point increase the font. (That increase would apply to everything, not just sidebar.) About the specific words though, we don't change those because this part is completely on the community's side. SGrabarczuk (WMF) (talk) 12:17, 5 August 2021 (UTC)
 * In my opinion words are fine, but what is more important for new and/old users could to be more evident and intuitive, for example adding some icon, coloured boxes, etc. In other words, a different and more complex layout/graphics, better if with some possibility to customize it, for example in order to have a basic sidebar for readers and new users (with more emphasis on links to rules pages and support pages) and another version for experienced users (with more emphasis on links to editing tools and patrolling tools). --Daniele Pugliesi (talk) 12:58, 5 August 2021 (UTC)
 * Icons and stuff - that sounds interesting. In the early days of the project, when the team was just imagining what could be done, a sketch with a sidebar with icons was created. Maybe we will think about that again when we will be closer to the "general aesthetic refinements". And yes, we have thought about making the interface tailored for specific groups, so one version for readers, and a different one for power users. Sadly, we are not able to do that now because of the limitations of the infrastructure. SGrabarczuk (WMF) (talk) 15:36, 5 August 2021 (UTC)

The width limitation of the wikitext source editor
The source editor uses monospace font which is wider than the default one. This means that every line of text in the source edit view consists of smaller number of words than on the article page. While I'm generally for the width limitation, I feel like the editor is too narrow. Msz2001 (talk) 06:00, 7 August 2021 (UTC)


 * Hi @Msz2001, fair request. We'll create a Phabricator task and examine how exactly how that could be done. SGrabarczuk (WMF) (talk) 01:12, 11 August 2021 (UTC)

Deskop/mobile key
Premise: I don't speak English well so excuse me for error. Considering the fact that you are changing the interface, I ask that the "desktop/mobile" and "mobile/desktop" button be repositioned in a more visible way and above all higher, because especially with small touchscreen displays as smartphone, sometimes the "warning" or "privacy" button is often pressed. My idea is to put it in the sidebar near wiki language link or at the top near the "edit" and "history" buttons--5.11.114.150 10:29, 10 August 2021 (UTC)


 * Thank you! That's an interesting thought. This will be possible closer to the end of the year when we will be working on the "general refinements," and then we will possibly change the footer. SGrabarczuk (WMF) (talk) 01:03, 11 August 2021 (UTC)

Mauvais liens de page d'aide sur le nouveau menu utilisateur
Bonjour, en allant sur Wikipédia en français, en étant déconnecté, nous avons, avec la nouvelle interface, un nouveau bouton Créer un compte puis les trois points menant au sous-menu où apparaît ceci :

« Pages pour les éditeurs déconnectés (en savoir plus) », ce qui mène à un mauvais lien, c'est dû à une mauvaise "traduction" de la page d'aide de WP anglophone Help:Introduction. Cette dernière a en effet w:fr:aide:premiers pas comme équivalent, cf Wikidata.

En résumé, serait ce possible de modifier le lien de Aide:Introduction vers Aide:Premiers pas ? Merci d'avance et bonne continuation pour le dévelopement du projet! --  Nemo  Discuter 20:51, 14 August 2021 (UTC)
 * Solution technique temporaire trouvée sur WP en français (changement de redirection, Aide:Introduction menait auparavant à w:fr:Wikipédia:Résumé introductif). À mon avis, il faut que le lien (en savoir plus) mène à la page correspondante de Help:Introduction pour chaque wiki, indiquée sur l'item wikidata et ce peut importe les futurs évolution de l'interface, un mauvais lien aussi visible n'est pas tolérable. Bonne continuation, --  Nemo   Discuter 09:46, 15 August 2021 (UTC)
 * Similar issue: T288293.--Patafisik (talk) 19:09, 19 August 2021 (UTC)

Ability to link to other language articles missing in new version of language selector
Previously before the rollout of the new language selector (the one that move it onto the header bar), I was able to link English Wikipedia articles to other languages Wikipedia articles by clicking the "edit links" link under the languages panel on the sidebar. However with the new version, this link is nowhere to be found, even in Edit mode. Would like to have this function added back else it will become very tedious process of linking to other languages Wikipedia articles, I would need to go to wikidata, find the correct item, and add the newly created article onto the language list. Another alternative I can/have done before, is switching back to legacy mode, add it onto the list, and then switch back, which sounds ridiculous as this isn't improvement. Both methods are very inefficient when compared to former design of ease of access and usage.

Sorry about the rant, if the feature is already there, please advise where to find it else would like to request this feature to be added back. Paper9oll 10:46, 15 August 2021 (UTC)
 * There’s an Edit/Add interlanguage links in the left-hand sidebar’s toolbox (a bit higher up than where the language links were). The plan is to have it next to the language links again, but that needs quite some work (T265996); the toolbox is a temporary solution (T287206). The popup to link the articles without ever going to Wikidata doesn’t work reliably in new Vector yet, but hopefully next week it will. —Tacsipacsi (talk) 13:01, 15 August 2021 (UTC)
 * @Tacsipacsi Oh great, thanks for the reply. Will make do with the "Edit/Add interlanguage links" for the time being. Glad to see the function being worked on. Paper9oll 13:12, 15 August 2021 (UTC)

Ordre des boutons dans le nouveau menu utilisateur
Bonjour, je pense que l'ordre des boutons dans le nouveau menu utilisateur devrait être changé. L'actuel est inspiré des anciens liens utilisateur du vieux Vector (Discussion - Brouillon - Préférences - Bêta-Liste de suivi - Contributions - Se déconnecter), qui se trouvaient horizontalement. Mais verticalement, Liste de suivi et Contirbutions sont plus difficile à atteindre alors que ce sont deux liens plus utilisés que Bêta et Préférence. Je propose donc un nouvel ordre dans le menu vertical :
 * Discussion
 * Brouillon
 * Liste de suivi
 * Contributions
 * Préférences
 * Bêta

--  Nemo  Discuter 12:58, 15 August 2021 (UTC)
 * Hi,
 * I agree with a list where "Préférences (Preferences)" and "Bêta (Beta)" came after "Liste de suivi (Watchlist)" and "Contributions (Contributions)". The list in the user menu that I can see is actually this one:


 * Discussion (Talk)
 * Brouillon (Sandbox)
 * Préférences (Preferences)
 * Bêta (Beta)
 * Liste de suivi (Watchlist)
 * Contributions (Contributions)
 * Traductions (Translations)
 * Fichiers téléversés (Uploaded media)
 * Log-out
 * can you add in your suggested list to order the links also "Uploaded media" and "Translations" ?--37.103.9.224 10:26, 18 August 2021 (UTC)
 * Effectivement, certains wiki ont d'autres boutons ! Pour moi, Preference et Gadget devraient systématiquement se trouver à la fin de tous les autres boutons. Cela donnerait ici :
 * Discussion (Talk)
 * Brouillon (Sandbox)
 * Liste de suivi (Watchlist)
 * Contributions (Contributions)
 * Traductions (Translations)
 * Fichiers téléversés (Uploaded media)
 * Préférences (Preferences)
 * Bêta (Beta)
 * Log-out --  Nemo  Discuter 21:08, 19 August 2021 (UTC)
 * I agree.--37.103.9.224 13:38, 26 August 2021 (UTC)

Clock
The clock is very helpful and I use it constantly. I don't like having to use a pulldown menu to look at the UTC time on the new Vector skin. Thanks, Diannaa (talk) 01:22, 18 August 2021 (UTC)


 * Hey @Diannaa, thank you for your opinion. Any links added via gadgets to the user menu are displayed in the new dropdown. The clock is added via such a gadget. Since these lie within the realm of community/volunteer editing, our engineers provide help for the gadget maintainers, but don't edit gadgets if possible. You may find another thread on this issue on the gadget's talk page. SGrabarczuk (WMF) (talk) 16:31, 19 August 2021 (UTC)

Login button is under a ··· icon
Hello! When logged out, there are two options [Create account] and [···]. The login button should be visible at all time, and should also have an icon. -Theklan (talk) 17:11, 19 August 2021 (UTC)
 * Hello, others users agree with this proposal, e.g. asked the same here. In my opinion, if the team want to conserve the login button under the icon, the icon more appropriate should be the account icon (the same of logged-in editors), instead of three points button which is not "self explanatory" of a user link to login inside. Logged in or logged out, the user icon is easy to understand and universal for "the person visiting this website". The ··· icon is not so clear : it means "see also" and not "see the link to log-in".--37.103.9.224 13:36, 26 August 2021 (UTC)

Suggestion to redesign the Language button
Hi, with how the Language button is designed and placed onto the article right now, it also moves the articles' symbols (such as stars, locks, GA...) to a new place. I think the new place of these symbols is not visually reasonable because it feels quite out of place. So the Vietnamese community has a suggestion to redesign and replace the button like this, where we will drop the word "Languages" (as in XX languages) and then combine the articles' symbols and the Language symbol onto one single place. Can you guys consider it?

Also, the moving articles' symbols to a new place means that we have to move coordination to a new place, and consequently make the coordination overlaps with Xtool (See this Phab task I just created.) Thanks! Bluetpp (WMF) (talk) 14:14, 16 August 2021 (UTC)

Overlapping content when coordinates template is present
Here is a screen shot of what I am seeing with the new Vector version on the article Calgary. The output of the Coord template is overlapping with other content on the page. Same on other articles such as en:Division of Batman but not on en:Edmonton, where the Good Article icon apparently pushes it downward to a nice location. I am using an Acer Chromebook, but I tested it also on an Acer desktop running Windows and got the same mess. Thanks, Diannaa (talk) 01:19, 18 August 2021 (UTC)

The second screen shot shows the box "Skip to TOC - Skip to bottom" unhelpfully overlapping with other text on the en.wiki page Wikipedia:Contributor copyright investigations. Thanks,Diannaa (talk) 01:33, 18 August 2021 (UTC)
 * For the coords at least, it's a known issue; see above. Cheers, &#123;{u&#124; Sdkb  }&#125;  talk 18:45, 18 August 2021 (UTC)