Talk:Reading/Web/Desktop Improvements/Archive9

Search box issue with mouse cursor on desktop
So if I place my mouse cursor near (specifically, a little below) the search box and then type a result in and press enter, instead of going to the main topic / main result or whatever, it goes straight to the item my mouse cursor was over on. This is quite annoying, as I have been brought to the wrong result numerous times this way, and I have to be careful and put my mouse cursor significantly away from the search box for it to not interfere.

Make it so that when the user is only using keyboard to use the search box, no matter where you put the mouse cursor, e.g. over the second result, it always goes to the main result for the terms entered. Additionally, even if you hover over a search item with the mouse cursor, pressing enter on the keyboard should still result in the search going to the main topic and not over what the mouse cursor was hovered on. Keyboard and mouse navigation should be made separate, and should not interfere with each other.

AP 499D25 (talk) 05:03, 14 February 2023 (UTC)


 * Hi @AP 499D25, thanks for yor feedback, this task is open on Phabricator. Patafisik (WMF) (talk) 15:13, 14 February 2023 (UTC)

"Missing in norsk" is nonsensical
All pages with a full Norwegian translation are missing a Norwegian translation according to the language dropdown. Norwegian has two variants, including on Wikipedia, Bokmål (common) and Nynorsk (rare), there's no other thing when both variants are covered.

Right now, it is like complaining that a page with both a British variant and an American variant isn't available in English. KristofferR (talk) 02:21, 19 January 2023 (UTC)


 * Hi @KristofferR, perhaps your problem should be the same of this task? I will notify the Language Team about your feedback in the Talk page of the Universal Language Selector, I think there are decisions that are better suited for other teams. Thank you for reporting this issue. Patafisik (WMF) (talk) 13:26, 19 January 2023 (UTC)
 * I tried reproducing this but could not. Can you give an example on which page on which wiki are you seeing this? Nikerabbit (talk) 09:14, 24 January 2023 (UTC)
 * CC @KristofferR Patafisik (WMF) (talk) 17:09, 26 January 2023 (UTC)
 * I'm seeing it on all English articles. https://en.wikipedia.org/wiki/Buckwheat for example, is missing Norsk, while being available in Norsk Bokmål and Norsk Nynorsk. KristofferR (talk) 14:33, 27 January 2023 (UTC)
 * Video demo @Patafisik (WMF):
 * https://i.imgur.com/zQOJVTD.mp4 KristofferR (talk) 14:37, 27 January 2023 (UTC)
 * I have a guess. Can you open a developer/javascript console of your browser and write  in there, press enter and paste the output here.
 * I guess you have  in the list there for some reason. Nikerabbit (talk) 13:49, 30 January 2023 (UTC)
 * Yup, I do. Array(5) [ "en", "se", "nb", "no", "nn" ].
 * I also wonder why I have the microlanguage Davvisámegiella (se) in that array, I only clicked on it after I wondered what the hell it was. However, I am interested in Swedish articles, and read them all the time, so that seems like an additional bug that should also be fixed.
 * I wonder if the code has a bug where it uses both ISO 3166-1 and ISO 639-1, despite the same words meaning different things, like se. KristofferR (talk) 17:48, 30 January 2023 (UTC)
 * Thanks for the info. We are tracking the suggestion issue in Phabricator: https://phabricator.wikimedia.org/T328435 Nikerabbit (talk) 12:08, 1 February 2023 (UTC)
 * Thanks, good luck figuring it out!
 * BTW, is there any way for me to set the FrequentLanguageList manually? That would be helpful. KristofferR (talk) 08:58, 12 February 2023 (UTC)
 * No easy way. It's stored in browser local storage under key . There is also   in JavaScript. Nikerabbit (talk) 13:34, 15 February 2023 (UTC)

Why is the log in button hidden behind the three dots symbol?
Currently, on Vector 2022, the top right corner shows the button "Create Account", as well as a symbol of three dots. The log in button is hidden behind these three buttons. Why is that? This means that users need unnecessary amount of clicks to log in. The corner has plenty of empty space, so the log in button would fit well next to the "Create Account" button.

If the white space in the top right corner is for some reason important, why isn't the log in button visible and account creation behind the three dots symbol? After all, users usually only need to create an account once, but they need to log in many times. Valtaisa varpunen (talk) 12:34, 21 January 2023 (UTC)


 * I'm happy to see that the log-in button is no longer hidden in Vector 2022. Thank you! Valtaisa varpunen (talk) 15:49, 15 February 2023 (UTC)

Multiple languages UX/UI
I am writing to make a suggestion/feedback about the language options in the new UI of English language Wikipedia. While I appreciate the aesthetics, and believe things look nice, slick, and up-to-date, I would like to suggest a more straightforward way to lay out the languages options (e.g., English, 中文，日本語, etc). In the old UI, languages are laid out on the bottom left side of the page, if you need to switch between languages, the options are 1) visible, 2) only one click away. As a bilingual user of Wikipedia who need to switch between languages, I find it very helpful. The new version of UI still allows switching between languages, but it is not as easy: you will need to click on the langauge menu to see if there is a Chinese version of the entry. If yes, you click one more time to get to the page, but if no, you just wasted a click that could have been saved. I am not saying rolling back the old UI, it is just that the old language module was more friendly to users who actually use it frequently and I wish the up-to-date UI can perserve that. 146.151.105.184 05:55, 14 February 2023 (UTC)


 * Thank you for your feedback. This is being explore in this task to find a way to help users who switch languages frequently. Zapipedia (WMF) (talk) 09:35, 15 February 2023 (UTC)

Don't fix what ain't broke
Oh come on Wikimedia, you know better than that! What was wrong with the old layout? What problem did you solve?

For me, everything was right! It was clear, it worked in old browsers, and it allowed me to quickly switch between languages by a simple click. Is someone suffering from "new is always better" syndrome over at Wikimedia? ;) There was no better way to spend the money I send you every year?  If we all sent you less, would such "upgrades" be out-of-budget in the future? :) I fear that Wikimedia got infected by Parkinson's Law, project managers looking for some raison d'etre, wasting resources. I hope I'm wrong.

If you must have this new "better" layout, please, at least give people an easy way to go back to the one they prefer. Without logging in of course - such nonsense! Write a flag in a cookie, problem solved.

Thank you for the otherwise awesome and free encyclopiedia! I use it daily, can't imagine internet without it! 5.173.48.145 (talk) 03:19, 23 January 2023 (UTC)

Start of redirect targets hidden by top horizontal bar
See, e.g., en:WP:RELATED: the first line of text visible reads "intended to link to topics that are simply...". In other skins, the first line of text visible is the section title: "Linking to articles that are related to the topic". Fgnievinski (talk) 03:00, 14 September 2022 (UTC)


 * Hi @Fgnievinski, I unfortunately can't replicate - I checked on two browsers (Chrome and Firefox) and three widths (full, which is 2,5k px, ~1000 px, and ~400 px, and every time, the section title is the first line of visible text for me. What browser and display resolution do you use? Do you use any additional browser zoom? SGrabarczuk (WMF) (talk) 14:44, 14 September 2022 (UTC)
 * here's a screenshot: https://pasteboard.co/v1lMc2Q1Hjn9.png
 * my screen resolution is 1280x720 and zoom level is 100%.
 * I'm using Chrome in incognito mode to avoid add-ons.
 * the problem only appears after I login into Wikipedia.
 * Here are some of my preferences:
 * - Skin: Vector (2022)
 * - Skin preferences: Enable responsive mode (Adapt layout to screen size on mobile.)
 * - Beta: New wikitext mode
 * Thanks for your support. Fgnievinski (talk) 19:18, 14 September 2022 (UTC)
 * I can replicate the Problem, though my first line is "Disambiguation...". I sometimes have the same Problem while using the new TOC. It seems to have something to do with the sticky Header. At first the Heading is visible for a blink of an eye, than the sticky Header pops up and the Text is blocked. HirnSpuk (talk) 07:10, 22 September 2022 (UTC)
 * @HirnSpuk, @Fgnievinski - could you tell me what browser version and device you were using? Thank you!  OVasileva (WMF) (talk) 22:37, 9 December 2022 (UTC)
 * I'm using Google Chrome on a PC running Windows 10. Fgnievinski (talk) 22:46, 9 December 2022 (UTC)
 * @OVasileva (WMF), I'm sorry, I don't remember anymore. Might have probably been Desktop-Firefox under Linux which I use mostly. I just tested in Win/Edge. The Problem is there. Standard Configuration, no zoom, middle font. Tested in Chrome, standard-configuration, problem is there. When clicking the given Link, the heading is there for a split second, than the "sticky-header" kicks in and moves over the heading. HirnSpuk (talk) 15:06, 15 December 2022 (UTC)
 * @OVasileva (WMF), I noticed some other weird behavior. When jumping to a specific Heading via special:permanentlink I'm not getting to the paragraph but somewhere below that. Might be related. Compare: b:de:Spezial:Permanentlink/1008062 or b:de:Spezial:Permanentlink/1003322
 * Regards --HirnSpuk (talk) 14:20, 4 January 2023 (UTC)
 * I am getting this too. Any time a redirect points to a section, the sticky header bar obscures the first line or two of text at the target page, so one has to scroll up to see if it is the right place (uncover the header). It looks like the page is opened at the right place, and then the sticky header is opened on top of it, covering the top text. This must be compensated somehow to correct for the reduced space at the top of the page for visible content but it is nor immediately obvious how it should be done. I am using Firefox latest version on windows 10 on desktop, and windows 11 on laptop. Effect seems to be consistent and repeatable. I notice that this effect does not occur when using the ToC, so it should be fixable by using a similar procedure. I would guess that for the ToC case, the content frame (whatever it is called), is already defined taking the presence of the sticky header frame into account, so the content is rendered after the header is already in place, so the top is not obscured.Pbsouthwood (talk) 05:52, 10 January 2023 (UTC)

This Problem seem to be still there! Does anyone know, if there's already a bug report? HirnSpuk (talk) 15:48, 17 February 2023 (UTC)


 * Confusing: I just tried a second time logged in, with full-width and hidden tools-menu, and it worked for once. Then I popped open the tools menu and switched back to narrow view... After that I logged out. Now it works in every case... Maybe I'll try again and will keep you posted in which configurations it works and in which it doesn't. HirnSpuk (talk) 16:01, 17 February 2023 (UTC)

Menu again - Tools-Menu on the right...
doesn't do what it probably should for me. Too big a font and the sections are not discernable enough. I was hoping that this would help the new menu structure, but it doesn't for me.

This page (here, the talk page) is the perfect example for everything I see wrong with the new menu: It's simply a bunch of too narrow text, which is not helpful at all! The "Main Menu" blocks the TOC initially (or is hidden), most of the TOC-Headings have line breaks and show additional information (which seems to be a total overload), scroll bars are partly out of bounds, one doesn't know where the mouse wheel is working right now.

I really doubt, that the usability of the new menu is better than in legacy vector. It doesn't look better (at least not for me), it needs more klicks, it needs more time for reading, everything is gliding/changing/sliding/hiding/autohiding with no distinguishable idea.

Yes I know, all this is probably not a thing while displaying and/or reading encyclopedic content. I think nothing mentioned here is a bug, because I think everything is intended. I just don't see why. Regards HirnSpuk (talk) 15:42, 16 February 2023 (UTC)

PS: As a side note: I just tried to see if I'm liking it better when playing with page zoom and browser-font-size. Spoiler: I don't :-D. I was hoping "just the text" will get smaller (hence at least mitigate the page-break problem), but the whole website did. Well not everything... I don't get it. HirnSpuk (talk) 15:55, 16 February 2023 (UTC)

Keyboard shortcut needed to 'User contributions' in Tools menu
I would add that now the 'Tools' menu is to be found in one of two optional positions, and also of variable length across different pages, I find the lack of a keyboard shortcut to view another User's Contributions is most frustrating. It should be a simple fix. For active editors, being able to easily view another users' edits is often more important than seeing one's own. We do have a shortcut for that, and many other less well-used Tools. I also agree with other commenters above that the order of Tool links been very bad for a long time. Not only that, but the lack of visual difference between both the 'Actions' and 'General' headings and the actual Tools links themselves makes the experience of using the tools menu much worse than it needs to be. Nick Moyes (talk) 12:42, 17 February 2023 (UTC)