Talk:Reading/Web/Desktop Improvements/Archive5

Feedback on ToC functionality
Hello,

I’m not sure how far you are in the development of the new table of content functionality, but I was looking at this prototype and noticed a potential problem. Here the ToC is on the side and that’s a good thing, but the ToC in the text have also been deleted and that’s not much a good thing. When there is a big infobox, the in-text ToC compensate partly or totally for it, hence the page arrangement take it into consideration for the position of the images. Now if you delete it, all the text will go up, along with the images, but the images can’t always follow, because the infobox, so the right-aligned images are going to pile under it, while the left-aligned will reduce the text to a very small column between them and the infobox. On fr:wp, infoboxes are very widely used, so deleting the in-text ToC is going to break the page layout of most articles (and rather probably upset the community). So I’d suggest that, whatever you do with the ToC, to not delete the in-text ToC until there is also a functionality to move the infobox outside the text too (that would be great by the way, as infoboxes always cause difficulties with page layout). --Runi Gerardsen (talk) 09:30, 7 February 2022 (UTC)
 * I would like to add myself as having this same concern about images. At present, image placement in many articles was determined by this factor of the TOC being inline, sometimes offsetting the issues of long infoboxes and allowing the first image in the first section to be right-justified (like anyone with any experience in professional publishing, I really hate left-justified lead images as they break up the flow of the text by interposing themselves between heds and text. Similarly, I try to maintain alternation in the justification of images since that mirrors the sweep of our vision and makes text with images easier to read (but of course you don't do this when it creates other layout issues). When this is deployed, a lot of articles are going to suddenly have image placement issues at the top that didn't previously. And this will probably make a lot of people very angry. I can see the need for the sticky TOC but I think it would still be better as something that could be toggled there from its current position while reading depending on how the user prefers it in an individual article. Daniel Case (talk) 05:50, 29 April 2022 (UTC)
 * What if we kept both the inline/in-text ToC and the sticky/sidebar ToC, but only display the latter when the user's scrolled past the former? A user preference could be added that forces the latter to always (or never) be displayed. I agree that the situation with images is a PITFA, but I really don't want to give up the sticky ToC either… OmenBreeze (talk) 00:43, 6 July 2022 (UTC)

I'm not sure, but until I manually switched back to "Vector legacy (2010)", then again to "Vector (2022)", ToC section was absent completely (neither new-style nor old-style). Also maybe, like with the language switcher, there should be [temporary] notice about ToC having moved to the left where it was previously? _Vi (talk) 17:57, 20 May 2022 (UTC)

About Google Docs and Zoom
Thank you for the invitation I received for tomorrow's videcall since I was an interface admin and a developer! but sadly I cannot participate since I don't use Google Docs or Zoom for security reasons (partially related: ).

I don't know if it could be useful but maybe in the future you may consider to land the doc on the wiki itself, or using Etherpad when realtime is needed.

To drop Zoom, maybe I can propose Jitsi Meeting that is gratis and libre and supports streaming on social network to support large audience. (Also Wikimedia Meet deserves a try and some feedback). Valerio Bozzolan (talk) 15:38, 28 April 2022 (UTC)


 * Hello @Valerio Bozzolan. I understand your concerns and thank you for the language you use. I do appreciate that. As you may have realized, it isn't without a reason why we use these particular tools/platforms.
 * Google Docs are used by the Foundation as the default tool for making internal notes and docs. We might, for the purposes of the office hours, replace it with Etherpad. There's a problem with the translations, though. Asking translators to update just one word, and waiting until they've done that, could be troublesome. This is why I can only commit to replace this if we make more changes to the announcement. (By the way, the announcement is fully standardized and translated into 16 languages, some of which use declination or are not written in the Latin script.)
 * We need our office hours to be technically (platform-wise) predictable. Although Jitsi is open source and Zoom is not, the latter is more effective. It has been widely used for online meetings in the movement. It's been used by the WMF for office hours with the CEO, Maryana; it's been used by affiliates. There are hundreds of Wikimedians who at least once have participated in a Wikimedia meeting on Zoom. We know how to provide live translations there. Jitsi, on the other hand, is less popular, and we'd have to learn how to support live translations, including more trainings organized specifically for our meetings.
 * We may consider having office hours on IRC. Frankly, I have a feeling that since the migration from Freenode, IRC has been more and more marginalized, but we could give it a try.
 * I'm curious what other Wikimedians watching this page think. Add your comments! SGrabarczuk (WMF) (talk) 22:15, 5 May 2022 (UTC)
 * Just asking for an understanding that Google Form and Zoom are a bug, not a feature, to participate in a Wikimedia project. A bug that deserves a long-term fix. Valerio Bozzolan (talk) 15:57, 7 May 2022 (UTC)
 * I appreciate these are standard across parts of the Foundation. And agree w/ Valerio this is a bug, not a feature. Perhaps it's time to revisit this across the org. :)  We should be using tools that can be constantly used and deployed by communities for events, workshops, office hours, talks without sending traffic through commercial servers.
 * Text: Google makes some very wiki-spirited tools (they did absorb JotSpot back in 2006) so it's stayed around for a while. But we simply must stop using it as a crutch that keeps us from using and being delighted by notetaking on our own platform. Our collaborative platform for drafting and discussing documents. Our versioned, searchable platform.
 * Video: I too have to use Zoom sometime, but I'm always surprised and a bit dismayed when a Wikimedia meeting uses it! Jitsi is stable, widely used + repackaged, easily modded and forked, and we host a lovely instance on the WM cloud. [We also regularly use BigBlueButton for larger audiences.] It makes it easy to name a persistent rooms, embed it it in other places or tools (see Jitsi-as-a-service + Brave Talk these days), &c. We should be thinking about how to better use video streams in our projects, and using this framework as we do so. Sj (talk) 12:54, 14 May 2022 (UTC)
 * Thanks @Sj and @Valerio Bozzolan.
 * First of all, I really hear what you're saying. Perhaps you're right, Google and Zoom may be bugs - it's definitely not up to me to decide. "Perhaps it's time to revisit this across the org. :)" - I'm grateful that you specifically used the words "across the org". That's way wider than just Olga and me (people who organize our office hours), or Community Relations ("technical liaisons" so to speak), or Movement Communications alone. If it's about the standard, then it needs a broad agreement.
 * @SJ, do Jitsi or any open-source alternatives provide the speech-to-text functionality and parallel voice tracks for live translators (interpreters)? I'm asking because each time we have a meeting, there are people who need the speech-to-text functionality . Unfortunately, we haven't been able to provide the live translation support yet. We're still working on it, and it seems we may have found a solution.
 * SGrabarczuk (WMF) (talk) 15:55, 6 July 2022 (UTC)
 * SGrabarczuk:
 * 1. We should change the standard [though there seem to be many even within one org!], but I only mentioned that to suggest that none are set in stone. :) As this thread is about these particular discussions, I hope we can try a different standard for these sessions, or understand what prevents such a change.  If it is purely a matter of accessibility features, that would make a phabulous ticket even if it is not yet known who could set them up.
 * 2. Yes they do! Other collaborative orgs w/ similar issues of language equity use jitsi regularly. There are solutions or workarounds for both. [also, to the point of "supporting essential infrastructure for free knowledge", our engagement would certainly help make them better for all.]
 * speech to text: Google Voice integration seems to be there, and a number of open-source s2t services that are not quite comparable. You can see the range of Summer of Code projects + community submissions scratching their own itches in the jigasi repo.
 * remote simultaneous interpretation: the most recent solution (for a single language, letting you tune in or out of the raw audio and into a translator's audio channel) is use by May First (which we should work more closely with on choosing technology stacks, frankly) and is maintained here. There are improvements, and pushes to integrate into jitsi core, both of which could be facilitated by small technical bounties or large expressions of interest [like Wikimedia indicating this is a crucial feature for us]. Sj (talk) 02:37, 7 July 2022 (UTC)


 * @SGrabarczuk (WMF), I will not participate in any forum that is not public. Why the wmf foundation wants to share information via Zoom, a for-profit corporation which provides no guarantee of privacy, is anyone's guess. We have been using wiki-code for discussion since 2001, why this change?
 * I apologize if you find my message above irrespecutful, but this represents the views of many. Ottawahitech (talk) 18:26, 13 June 2022 (UTC)
 * @Ottawahitech, above, you can find explanations on why we (the Web team) are using Zoom now. Are you also asking why we have any voice online meetings in general? SGrabarczuk (WMF) (talk) 15:57, 6 July 2022 (UTC)

Wikistories
Will Vector 2022 be influenced by Wikistories? -- NGC 54  ( talk |  contribs ) 10:09, 6 June 2022 (UTC)


 * @NGC 54, what do you mean by influenced? SGrabarczuk (WMF) (talk) 22:18, 14 June 2022 (UTC)
 * @SGrabarczuk (WMF): If Vector 2022 will be adapted for (compatible from a design perspective with) Wikistories. -- NGC 54  ( talk |  contribs ) 19:06, 15 June 2022 (UTC)
 * @NGC 54, definitely. All the projects that currently are being built are compatible with or neutral to Vector 2022. SGrabarczuk (WMF) (talk) 16:47, 30 June 2022 (UTC)

Irish language Wikipedia and Vector 2022


Hi there. I'm w:ga:User:Alison - admin and bureaucrat on the Irish language Wikipedia. I'd be remiss in not providing feedback, I think, so here goes.


 * I see other folks pointing out the massive amount of whitespace / padding in the left side navbar which is squeezing out the actual article text on the right. On our wiki, it really seems significant. IMO, article is all, and we seem to be sacrificing actual content real-estate for ... what, exactly? Yes, it looks 'less cluttered', but there's actually less content - especially for those of us who both browse and edit on laptop screens.


 * On the top tab section (which is otherwise quite nice), you can see the Plé (Talk) and Léigh (Read) are scrunched together with no separation. I18n bug, maybe?


 * The main image and title have lost their localization and now show "Wikipedia" instead of "Vicipéid" - this could just be an image localization / config issue. Could someone point me in the right direction, maybe? I did the original, later-font localization for our wiki, some years back, so happy to dip in and fix :)

Le gach dea-ghuí (best regards),

-- Allie Alis o n  ❤ 16:17, 22 June 2022 (UTC)


 * multilingual Wikipedians: during redesigh include current non-english desighs for evaluation, including spanish, french and german. They have good ideas and bad ideas... 0mtwb9gd5wx (talk) 01:10, 23 June 2022 (UTC)
 * The "PléLéigh" issue looks like it's T309223, a known issue. Until it is fixed in MediaWiki, try updating your browser(s) – the issue occurs if your browser doesn't support a certain relatively new feature. Rummskartoffel (talk) 21:59, 23 June 2022 (UTC)
 * Hey there! Regarding logos https://phabricator.wikimedia.org/T244486 is what you are looking for - basically every logo needs to be recreated. You can request one on that ticket to be prioritized higher or find information about creating new ones.
 * Regarding sidebar whitespace I am not sure I understand. The extra padding is for the table of contents underneath the sidebar. You say it's squeezing article text on the right but in your screenshots the Vector 2022 screenshot shows more of the article text. I can see the description section heading for example.
 * I can confirm the PléLéigh issue is a bug and will hopefully be fixed soon.
 * Hope this is helpful. Jdlrobson (talk) 01:02, 1 July 2022 (UTC)

wordmark no longer appears after upgrading to MediaWiki 1.38.1, style bugs
After upgrading to MediaWiki 1.38.1 from 1.36.1, the wordmark no longer appears next to the icon in the upper left. If the window is wide enough, the 150px space for the wordmark is reserved but is empty. When you make the window wider past a certain width, the coloring behind the sidebar also vanishes. This happens with Vector 2010 in both legacy and non-legacy mode and in Vector 2022. The wordmark image is an svg that has not moved and still has correct permissions Queernix1028 (talk) 19:43, 22 June 2022 (UTC)


 * What is the value of wgLogos in your LocalSettings.php? Jdlrobson (talk) 14:22, 29 June 2022 (UTC)

$wgLogos = [ 'icon' => "$wgScriptPath/images/arcc/logo.svg", '1x' => "$wgScriptPath/images/arcc/logo.png", 'wordmark' => [ 'src' => "$wgScriptPath/images/arcc/wordmark.png", '1x' => "$wgScriptPath/images/arcc/wordmark.svg", 'width' => 150, ], ];
 * It previously worked with wordmark src set to the svg file, but now neither that configuration nor the one above work. Queernix1028 (talk) 14:32, 29 June 2022 (UTC)


 * I believe you need to set a height on the wordmark. Jdlrobson (talk) 00:55, 1 July 2022 (UTC)

Language links on Wikidata are right at the bottom of the page
I've enabled the new theme (Vector 2022) globally on all wikis. I generally like the new interface. However when I am on wikidata, previously the interlanguage links were on the right. (Where an infobox usually goes on a wikipedia page) Now they are right at the bottom of the page! Some wikidata pages are massive, and having to scroll all the way down to the bottom of the screen to do the thing I do most frequently on wikidata (add new language links) is a real pain. Please can you move the language links on wikidata back to the top (top right) of the page? - Rooiratel (talk) 14:25, 23 June 2022 (UTC)


 * Hello @Rooiratel. Thanks for your opinion. Are you talking about the desktop view? What's the resolution of your screen? I've tried to narrow my window down and change its width, and it seems that the width thresholds when the interwiki links go from the bottom to the right are the same. Is there any setting you use that may make your experience different? SGrabarczuk (WMF) (talk) 23:50, 27 June 2022 (UTC)
 * Hi this is for the desktop view. I am seeing this behaviour on my 1080p laptop screen and my 1440p desktop screen. I haven't used the mobile view, so can't comment on that. - Rooiratel (talk) 06:32, 28 June 2022 (UTC)

Infobox element alignment is mangled in mobile view
Maybe I'm doing something wrong, but when I click on "Mobile view" with Vector 2022, many of the infobox elements are misaligned. Many elements that should be centered are left-aligned, and many elements that should be left-aligned are centered. At least that's what it looks like for me in Chrome for Mac OS at this page. Jonesey95 (talk) 02:57, 24 June 2022 (UTC)


 * Wow, that looks odd. Thanks @Jonesey95 for reporting this. Right now, I only have one question - why do you use the mobile view and Vector 2022 mixed together? Minerva is dedicated for mobile, and Vector 2022 is dedicated for desktop. Having these two at the same time is bold and original :) SGrabarczuk (WMF) (talk) 23:08, 27 June 2022 (UTC)
 * I was just doing some very beginner-level QA testing. Editors do all sorts of ridiculous things, so I try to do some QA testing by doing ridiculous things. If you want editors to use Vector 2022 for desktop-only and Minerva for mobile-only, then make the "Mobile view"/"Desktop view" link at the bottom of the screen switch between the skins. Meanwhile, I'll be over here in legacy Vector where I can fill my browser window with content.... Jonesey95 (talk) 01:15, 28 June 2022 (UTC)

Using the mobile domain with the Vector skin invokes a special mode with lots of odd behaviour. It's not part of this project but will hopefully get fixed some day. Jdlrobson (talk) 02:30, 28 June 2022 (UTC)

"Related articles" appear to be missing
I do not see the "Related articles" section at the bottom of the mobile view. I don't really care, but since the "Principles" section of this page says "We do not remove any functionality", I thought I'd mention it. It makes me wonder what other functionality has been removed, and whether this principle is really being followed in a systematic way. Jonesey95 (talk) 03:02, 24 June 2022 (UTC)

RelatedArticles appears to be working fine to me. I see it on Minerva. What do you mean by "at the bottom of mobile view"? The scope of this project is the desktop site so no changes to the mobile domain have been made.

RelatedArticles does not show on the skins of certain websites and has not shown on Vector or Vector 2022 unless the community has explicitly requested. See T144812, T181242 and T278611 for example. Jdlrobson (talk) 14:59, 24 June 2022 (UTC)
 * I think this is my mistake. I was comparing this (default mobile view on en.WP) with this (Vector 2022 mobile view) and assuming that the default mobile view used some version of the Vector skin, but I think that is not correct. Jonesey95 (talk) 16:38, 24 June 2022 (UTC)

Ah okay. This mode is only accessible by a special URL and is not being worked on as part of this project. Thanks for taking the time to explain! Jdlrobson (talk) 02:28, 28 June 2022 (UTC)

Please evaluate CJK characters' font size in Vector 2022
For your infomation, the Chinese Wikipedia already has a gadget that increases the font size for a better Chinese reading experience. Japanese and classical Chinese Wikipedia also have such kinds of gadgets. Diskdance (talk) 08:19, 25 June 2022 (UTC)


 * It would be nice if we could integrate these gadgets into new Vector skin directly. This would benefit other CJK and multilingual wikis. Diskdance (talk) 08:20, 25 June 2022 (UTC)
 * Thanks @Diskdance! @AHollender (WMF) FYI :) SGrabarczuk (WMF) (talk) 23:03, 27 June 2022 (UTC)

I think we should create a phabricator ticket for this one. Jdlrobson (talk) 02:29, 28 June 2022 (UTC)

Merge notification block in the header: notifications and alerts
For me, it has always been a strange decision that notifications were divided into two unrelated blocks and icons with incomprehensible categorization. I forgot about it, but now I'm paying attention again.

Given that we removed the text from all menus, there are now a lot of icons at the top that do not understand what they do. Different blocks of notifications do not help this at all. Maybe it's time to put them in one menu and break it there already? Filters, tabs, whatever :) But at least you won't get confused in the icons.

I personally still (6 years!) do not know what their fundamental difference is. I asked my friends and they don't know either. Iniquity (talk) 17:29, 27 June 2022 (UTC)


 * . The notices are the notifications that are not very important/urgent, unlike the alerts. Merging them would make me unable to found out at a glance if I have any important/urgent notification, and would also overload the notification box, as I receive many notifications. -- NGC 54  ( talk |  contribs ) 22:19, 27 June 2022 (UTC)
 * It seems to me that it is possible to do this with filters and colored marker icons. Or a separate setting for users who really need it. Iniquity (talk) 09:47, 28 June 2022 (UTC)


 * . I agree that the distinction could be clearer, but don't necessarily agree that there should be only one button. Presently, when both are empty the only difference between them is the header text and icon. Both share the exact same two buttons, which link to the same destinations. The text in the box doesn't even distinguish, reading "There are no notifications" instead of "There are no alerts". There isn't even a "help" or "about" link unique to each of them to explain the difference or what gets sent where. If you follow the links to the special page or preferences, it's still not clear which notifications are sent where.


 * Based on the names, I would've assumed the difference would be that alerts are specifically for subscriptions to article alerts, whereas notifications would be for everything else. It makes sense to split them, since alerts would be activity that's less personal to the receiver. "Alerts" would be like a daily newspaper, but "notifications" are more like personal mail. Except this isn't how the system actually functions; messages to the receiver's talk page are placed under "Alerts" rather "Notices", for example.


 * I understand that it may be helpful to filter urgent notifications from less urgent ones, but what counts as urgent or important? Shouldn't that be decided by the user's preferences? It would make more sense to have something like tabs, as Iniquity suggested, to filter types of notifications; this would let that user decide what is important. Scyrme (talk) 22:33, 27 June 2022 (UTC)

Table of contents: Bold format for active section
I really appreciate the new skin and layout. In the beta, the active/current section of the article was formatted bold in the table of contents on the left side. But in the live version, it's regular and black. I find it really, really hard to differentiate between the normal blue titles and the active title, because the only difference is the black vs. blue color. Could you please make the active titles bold again? Thank you! Lhennen (talk) 21:11, 29 June 2022 (UTC)


 * +1 Bold and black would be best imo. L.xschlag (talk) 11:43, 1 July 2022 (UTC)
 * @Lhennen, @L.xschlag - thank you for your feedback! Not sure if you've seen, but we are  currently in the middle of testing some prototypes related to this question.  You're welcome to give us more detailed feedback on the prototype page.  One of the things we're testing on these is the way links should appear within the table of contents (see https://di-visual-design-toc-active.web.app/Otter) for an example.  Currently, our feedback is showing us that people are leaning towards option 2: bold and black so we will most likely be continuing with that option and making the titles bold.   OVasileva (WMF) (talk) 10:08, 4 July 2022 (UTC)

Jawiki has NOT reached consensus on implementing Vector 2022 yet
Jawiki has NOT reached consensus on implementing Vector 2022 yet. Why was it implemented without our consent? AppleRingo777 (talk) 22:01, 29 June 2022 (UTC)


 * Hi @AppleRingo777 - we apologize for the confusion that the deployment process has caused and the lack of clarity from our side.  We are currently working on reading back through our previous communications and clarifying the process and what happened with individual members of the community.  We will to get back to the community with more detailed thoughts and a process for next steps by tomorrow July 1st.   OVasileva (WMF) (talk) 12:04, 30 June 2022 (UTC)

MediaWiki:Sidebar
Hello! I asked a question at the meeting, but I would like to duplicate it here. Will it be possible to control the location of blocks (right or left) through MediaWiki:Sidebar? Iniquity (talk) 15:34, 30 June 2022 (UTC)


 * Hey! We are still thinking through how this would work. Input valued in T306519 ! Jdlrobson (talk) 14:27, 6 July 2022 (UTC)
 * Thanks! :) Iniquity (talk) 16:16, 6 July 2022 (UTC)

Keep the TOC under the main menu as long as possible (Vector 2022)
When the window gets narrower the TOC is moved into a "Hamburger button". But the main menu stays where it is until the window get's quite a bit more narrower. I think as long as the main menu fits, the TOC should stay at its original place. Especially since the TOC behind the "Hamburger button" is quite easy to miss. L.xschlag (talk) 11:30, 1 July 2022 (UTC)


 * This was a bug. I believe it should be fixed by the end of the week. Jdlrobson (talk) 14:28, 6 July 2022 (UTC)

"Move" is the only in the "More" drop down menu (Vector 2022)
I think it's quite odd that the "More" drop down menu most of the time contains only "move". Is it on purpose to make it harder to find for the average user? L.xschlag (talk) 11:35, 1 July 2022 (UTC)
 * , I have two items - the other is an add-on via preferences/gadgets. Unfortunately, I cannot use drop-down menues easily, so getting there in V-2022 is quite a nuisance. Retired electrician (talk) 21:31, 3 July 2022 (UTC)
 * Isn't the behaviour the same here on the other skins?
 * I agree it's not great having one item in a menu, but I think this case is quite rare since on most wikis move privilege is added along with page protection and deletion. There is a trade off here between the complexity of maintaining multiple variants of the skin in different circumstances and what looks best. Here we could add special treatment for the one item menu but we'd need to add additional code complexity and tests to cover it. Hope this insight is helpful. Jdlrobson (talk) 14:32, 6 July 2022 (UTC)

Language mix in the interface
Pardon me if this had already been discussed here. It seems that the language of the interface (as set in preferences) mixes up with local-language elements where it shouldn't.
 * 1) My preferences are always "interface=en", and thus I always see "Contents Beginning" in the TOC section - be it Chinese, Russian or Spanish wiki.
 * 2) The pink box above TOC in ru-wiki says "On this Википедия[sic!] the language links are at the top of the page across from the article title. Go to top." In zh-wiki, however, the message is correctly "On this Wikipedia the language links ..." Retired electrician (talk) 21:23, 3 July 2022 (UTC)


 * Thank you @Retired electrician for reporting this. That's odd. 🤔 The source code is:  On this the language links ... - so apparently, something about  isn't working here. But I don't know what yet. SGrabarczuk (WMF) (talk) 16:20, 6 July 2022 (UTC)

Where are the categories?
Hi this is my first time looking at the prototype, so apologies if this question has been answered elsewhere - where are the categories? MassiveEartha (talk) 04:15, 5 July 2022 (UTC)


 * Hello @MassiveEartha. I'm sorry that you felt confused. We don't touch elements such as categories. These prototypes were only created for editors to help us decide on the visual design matters. If the categories aren't displayed in any of the prototypes, then it's definitely unintentional and also irrelevant to what we do. SGrabarczuk (WMF) (talk) 16:02, 6 July 2022 (UTC)

開発者集団は日本語版を軽視していると思われるThe group of developers seems to downplay the Japanese version
日本語版の利用者の一人としては、開発者の集団は日本語版を軽視していると考える. 一つの証拠として開発者からの意見を求めるメッセージが英語だけで書かれていたことを挙げておく. 機械翻訳があるのだから英語と共に日本語を添えることは簡単なことのはずである. それすらせずにVectorからVector2022への変更を強行したことは、一種の文化帝国主義であると評さざるを得ない. As one of the users of the Japanese version, I think that the group of developers disregards the Japanese version. One proof is that the message for the developer's opinion was written in English only. Since there is machine translation, it should be easy to add Japanese along with English. It must be said that forcing the change from Vector to Vector 2022 without doing so is a kind of cultural imperialism.--27.85.205.84 07:17, 5 July 2022 (UTC)


 * Hello 27.85.205.84. Do you maybe know good open-source machine translators working for Japanese and English? I've noticed that Google Translate doesn't work for these languages well. Sometimes it changes words, meanings, and the tone of entire sentences completely. I could write in Polish, my first language, but I'm sure that would be even more difficult. SGrabarczuk (WMF) (talk) 16:15, 6 July 2022 (UTC)

Listed coordinates overlapping with header weirdly
for an example of this, see wp's london article (screenshot) LarstonMarston (talk) 20:00, 5 July 2022 (UTC)


 * Thank you @LarstonMarston. In this case, we need to fix the bug together with the communities - some code should be changed by editors on each wiki with this bug separately. We can help (and we're working on it). SGrabarczuk (WMF) (talk) 16:11, 6 July 2022 (UTC)
 * thanks, good to hear LarstonMarston (talk) 20:06, 6 July 2022 (UTC)

Replace the "new section" tab text with "+" gadget not working.
On the English Wikipedia upon switching to Modern Vector the aforementioned gadget ceases to function as intended.

Nathanielcwm (talk) 13:14, 6 July 2022 (UTC)


 * Looks like the gadget is setup to only work on Vector and Monobook. I have updated it to also apply to Vector 2022 skin (https://en.wikipedia.org/w/index.php?title=MediaWiki%3AGadget-addsection-plus.js&type=revision&diff=1096783301&oldid=1047498910) Jdlrobson (talk) 15:59, 6 July 2022 (UTC)

July
@SGrabarczuk (WMF): Does Vector 2022 will be deployed (as default) at all Wikimedia wikis until the end of July, as it is written here? I am asking this because I see that there is still some work to do and the deadline written there changed several times. -- NGC 54  ( talk |  contribs ) 21:56, 6 July 2022 (UTC)


 * Hello @NGC 54, thanks for this question. This information is already outdated. It will not be deployed in July. We hope to send an update to the village pumps next week. We're working on the announcement right now. SGrabarczuk (WMF) (talk) 16:01, 7 July 2022 (UTC)

Merge [ca-view] and [ca-nstab-main] in the article toolbar
Currently, in the article toolbar, we have two links (Read and Article) that lead to the same location. One of them is located in the left and the other one is located in the right navigation. This can be confusing to readers, and also adds unnecessary weight to the toolbar. Current look.

It would be good if we could merge these two tabs into one. Ideally, the best solution, in my opinion, would be to merge the right and left navigation and center the items, like this. Please tell me what you think about this. Thank you! — Aca (talk) 11:18, 9 July 2022 (UTC)


 * . Now, the tabs are clear. You have 2 pages: the article and the talk page. You can select 1 action at a time for each of them: reading, visual editing, source editing, and viewing the history. Form the proposed design, you can understand that the tabs led to different types of pages. The watch is something not related to the article? And if now you are on article tabs, if you would press on the editing source tab, you would arrive on a page not related to the article (this is a possible confusion)? And so on. "This can be confusing to readers," - how so? Are there any data? And if there are, are there any data that the proposed design is better? P.S. I also dislike the proposed design, due to visual reasons. -- NGC 54  ( talk |  contribs ) 19:00, 9 July 2022 (UTC)