In T368221#10531099, @Diskdance wrote:

The <select> dropdown seems not to be dark, reproduceable on Chrome and Firefox:

There is a CSS property https://developer.mozilla.org/en-US/docs/Web/CSS/color-scheme that should fix it but my tests didn’t confirm if setting it would fix the issue.

@KSruthi-Vel you can write down a line Bug: T363726 instead so that a bot announces both the upload and the merge of this patch. You don’t need to announce that yourself.

Yeah, I also think that the proper way to deal with this is to pass the uniform user agent for all requests that would just output WOFF2 fonts and nothing else. Having fonts is a progressive enhancement, so exposing UA data for that is not really necessary. If someone wants to do that nonetheless for whatever reason, you could leave an opt-in parameter for doing that, like senduseragent=1.

Since this ended up being deployed anyway, I’m not sure there is much benefit to removing ruWP unless there would be enough opposition to it locally (which I don’t see yet) unless you somehow manage to do it extremely quickly. I think most people would just not notice the change since it (unfortunately) does not affect any forums and community discussion pages.

Even not considering that, if this restriction on who can see this data is useless, then it should be dropped entirely, not just in RC filters. But for that, I think, asking the community first would be needed. So I am not a fan of doing the same by proxy, given that this restriction clearly exists for some reason and it should not be chipped away in one component while being present in the rest of MW (most notably, on action=info page).

This is too verbose without an increase in understandability (‘a change has been made to pages’? redirect page change should make it easier for editors who work a lot with redirects?). ‘Redirect’ and ‘history pages’ should not be capitalised mid-sentence. ‘The interface tab’ is something that would probably be harder to translate, if anything. Suggestion on alternative wording:

You can now navigate to view the redirect pages from their action pages, such as history page. Previously you were forced to go first to redirect target. This change should help redirect editors. Thanks to user stjn for this improvement.

In T313581#10543490, @Samwalton9-WMF wrote:

After we merge T20790 it will be very easy to write some data queries to assess what % of RecentChanges entries, on various projects, have fewer than X watchers. I think that will help us decide where this threshold should be, and how that threshold might vary by wiki, if needed.

Does that also mean that this data would be available via Quarry etc.? Because in that case, it is a definite no-go. If this data is generally not available in APIs unless you have permissions, it should not be available in data replicas.

As mentioned in now closed T192581: All skins should use WikimediaUI OOUI theme, it also makes Monobook users confused about whether desktop design uses OOUI/Codex styling. This was the feedback I’ve heard when redesigning the main page to OOUI-based design in 2018. For consistency’s sake, it would be better if power users were aware that this is the design all kinds of users see, not just mobile users.

Given T216703: Use WikimediaUI OOUI theme in MonoBook I guess it’s fine to close this task, since it was initially about Wikimedia-deployed skins and that task, which was spun off this one, is still open (and hopefully won’t be closed). Hopefully you don’t plan to close it as well, since I would object to that.

Strange to see the ping-pong between the tasks but I don’t think any ideas from this task were implemented in T369466: Improve logentry-rights-rights message so it is not necessarily a duplicate.

Since T333211: Reconsider position of special pages link, currently in the page tools is currently being done, this also needs to be part of this update.

I missed the counterintuitive part where these links need to be present on the user page itself to work. Disregard.

Checking https://en.wikipedia.org/w/index.php?search=Rice+and+Lentils+(Mejadra)&title=Special:Search&profile=advanced&fulltext=1&ns0=1 for https://en.wikibooks.org/wiki/Cookbook:Rice_and_Lentils_(Mejadra) it seems like the search algorithm is maybe more dumb and just checks pages in 0 namespace only, no matter the configuration. Compare to https://en.wikipedia.org/w/index.php?search=Raisin+Oatmeal+Muffins&title=Special%3ASearch&ns0=1 which has a result from Wikibooks (but also not a recipe).

I would assume that search requests uses content namespaces from Russian Wikibooks itself, and recipe namespace might not be marked as a content namespace. If my assumption is correct, this is the only way this can get fixed.

Improving JS-based filters seems like in scope for T328706 instead (I do think they are very slow and hard to use, and both issues you’ve raised are why I disabled them, as well as unasked for URL changes). Having edit links is a good idea (though adding them in a way that makes sense would still require a visual rework which you oppose). For (2), there is an option to enable rollback confirmation in the settings, though it is also imperfect.

In T378352#10389154, @Nemoralis wrote:

@Frostly what is the source for your last change on the task description? ("The tracking category is planned to be removed in 1.44 unless there are objections.")

@cscott said so in the Gerrit patch in the link:

At least one user mistakenly went to phabricator.wmcloud.org from https://www.mediawiki.org/wiki/Phabricator and did not notice it is a separate website. I feel like that should be easy to add at least on the homepage, preferably in big enough letters.

In T336863#9571315, @thiemowmde wrote:

for not much benefit (only no-JS users)

To clarify: it is not just no-JS users, it would improve the workflow of all kinds of rollbackers since they could go to rollback, see what the diff is, and make a more informed decision.

I don’t think this task should’ve been closed as a duplicate. @Pginer-WMF, you have spent 1.5 years working on that task. The chances are, you are going to spend another 1.5 years working on it. In the meantime, Russian Wikipedia community is going to have to wait while existing, actually visible interface gets fixed, even though that fix is as simple as adding another interface message and allowing people to localise it. Unless you commit to achieving this work faster, this is just kicking the can down a very, very long road.

@Agabi10: first off, I think you misunderstood my point about responsive design. This layout can be made responsive since it is built using CSS grid, I just focused on structure for desktop for initial mockup. My main focus was to think about how elements could be placed in a sensible, more consistent way, not on what the complete look should be (in regards to your points on style of tag/marker pills).

Made a mockup: https://test.wikipedia.org/wiki/User:Stjn/sandbox

I thought my initial commentary was constructive. I said that a mockup like that would not be agreed upon by a majority of users because it is too large in comparison. I should’ve clarified more that I was basing this on feedback to previous OOUI/Codex conversions of forms. I also mentioned a specific issue with the layout: eyes have to go back and forth to read the most important information. I could’ve expanded it more but I meant no ill will (and I apologise to Hex if it read that way), and I agree that the layout should be improved. I’ll try to do a mockup myself so that others can constructively criticise it.

Wikimedia way is about doing improvements that improve the life of volunteers, not about saying ‘if you don't like it, go somewhere else’. If you look, for example, at community-developed tools like https://meta.wikimedia.org/wiki/SWViewer, they try not to waste space unnecessarily but still help the user. RC/watchlist in particular are pages that are used by many people for labour-intensive edit monitoring, so having a lot of info presented there is a benefit to that work and not a hindrance. Of course, that info still has ways to go in terms of presentation.

Yeah, just encountered that, if this is supposed to work, it does not for https://kargormaslihat.gov.kz/ru/ispolvlast/ which was archived 43 times: https://web.archive.org/web/*/https://kargormaslihat.gov.kz/ru/ispolvlast/
You can still put in archive URL directly but this feature would be so good if it was implemented fully.

Not to shutdown the enthusiasm, but that mockup is exactly what should not be done if we want widespread adoption of new interface instead of it being opt-in forever. Previously compact interface became thrice as large while readability in fact decreased in some ways because the eyes have to travel more to read essential information about the edit.

Thank you for swiftly fixing the issue :-)

In T380530#10489119, @cscott wrote:

I'd like to tag this 'won't fix' for the legacy parser.

Also, this would prevent further fixes to redirect page HTML down the line, like T385340, so I really don’t think this should be tied to Parsoid switchover, especially since 1) tests currently do not depend on Parsoid and 2) Parsoid as it seems does not have any special handling for redirect pages apart from what is present in legacy parser. So I’ll try to instead add <link rel="mw:PageProp/redirect" href="./Water" id="mwAg">-style markup to non-Parsoid HTML and rewrite tests so that, when the time comes, Parsoid team can transition to using whatever markup is desirable.

I also think that ‘this is intentional’ rationale is not enough to override a very specific MediaWiki custom for no single reason. End users should not be forced to add back something that should work by default. Red links are a custom for denoting that the link leads to a non-existing page, and it should be mandatory to have that sort of marker there, not optional, especially on mobile where users cannot even hover over the link to know if it leads to a 404 page. Therefore, I would re-open this task and submit a patch to remove the code in question.

The best way to solve this would be to always provide #catlinks on the page, even if there are no category links. It would also help gadgets like HotCat to avoid having to generate categories list on their own. Then VE could modify always-present list instead of trying to generate its own list.

The code for most use cases already includes a redirect=no assignment here: L508. It checks for $row->rd_from but it seems like that check currently does not work for some reason, so this might be a Regression. It is probably not an easy task to solve, though, you’re right, given that you need more than an entry level to know why that check does not work in those cases.

To explain the token: I don’t think there is anything wrong with making it so .jpg/.png/.svg part of the name is static and is tied to what the media type is. I do think the original proposal to make it so there are file links like [[File:Map of Europe]] is a very destructive one for zero actual benefit, and would require a lot of useless work from resolving collisions. I do agree that the extension names should just be standardised and there should be no difference between .JPG, .jpg, .JPEG, .jpeg on MediaWiki’s end.

I guess that’s also a way to solve this task, sure, if anyone decides to buy into making that one a reality. (Though I don’t think italics from a redirect page should be removed, they are a pretty universal marker of redirects in MediaWiki.)

Something like this:

When a user is doing any actions on a redirect page, the tabs linking back to viewing it would no longer go to a redirect target.

Thanks for sharing that code. Yeah, definitely can be done as part of this task.

In T333211#10514211, @aliu wrote:

Given this task's previous supporters, I'd say this position is quite subjective. I think it makes sense because it's a non–page-specific link to navigate to, just like n-recentchanges.

Yeah, but n-recentchanges is not actually in Navigation menu for many wikis. Checking top 10 Wikipedias apart from bot-aided messes, 1) en: Contribute menu, 2) de: Participate, 3) fr: Contribute, 4) ru: Participation, 5) pl: For Wikipedians. That’s what I mean: if it gets added to navigation with no explanation and no way to trace it back from the edit history, the communities might be more confused on how to move it to somewhere more sensible for them. Making it an actual edit would avoid that.

No idea, but it is much better than the solution currently considered: to rely on every project 1) noticing the tech news item, and 2) fixing the sidebar in time for hard deprecation. To be frank, this whole thing looks like a Vector 2022 problem first and foremost, so if this change is necessary, the transition should be swift and mostly automatic.

While I do not disagree with the spirit of the change, I guess, the way this needs to be done needs to be far more end-user-friendly. Currently the link would just get moved without any indication why that happened unless you read Tech News. Instead, an update script should add the link to navigation submenu if that’s the default placement, then this change could be actually seen by local admins and adjusted without going through hoops. That script shouldn’t be hard to write and should be the expectation if you are doing something like this, given that in many bigger projects, this link explicitly does not, at all, belong in Navigation.

FWIW the results of the new special page https://meta.wikimedia.org/wiki/Special:GlobalContributions/Babel_AutoCreate seem to show the same problem at plwiki and frwiktionary

As I’ve said above, I do not have an opinion that it is not an important use case, I just don’t agree that it should be solved long-term via page tabs. You are welcome to modify the patch so that action=view on the current version of the page leads to the redirect target, if we add a FIXME comment that this link should eventually be moved on the page itself. I would do this myself but I’d probably spend too much time figuring out how to add that condition.

Then this can be marked as declined given that it is very unlikely that Russian Wikipedia community would agree to enabling Vector 2022 as the default skin in the next 2 years.

At least in Russian Wikipedia, a number of erroneous categories were created by Babel AutoCreate after this change: https://ru.wikipedia.org/wiki/Служебная:Вклад/Babel_AutoCreate (you might need to look at deleted contribs in case they get deleted)

Most of the stuff in T373204#10477439 wasn’t fixed and (3) and (5) (and to the lesser extent (4)) represent pretty big accessibility problems with new design :-/

Already resolved in T373204.

Confirmed as working at en.wikipedia.beta.wmflabs.org, added to Tech News, so resolving.

Confirmed as working at en.wikipedia.beta.wmflabs.org, added to Tech News, so resolving.

Yes, I am making a judgment based on what Vector currently does which is the latest skin out of ones developed by the WMF (i. e. by more qualified developers). Timeless might’ve put these in HTML because it uses float: right for positioning, not because there was much thought about HTML structure. Monobook is ancient.

From the tests on Patch Demo and in beta cluster (https://en.wikipedia.beta.wmflabs.org/wiki/Sandbox), it seems like something got broken by the time of merging (and does not work in Firefox for me at all). Maybe it was actually related to the regex change that was discussed in the patch discussion, since PS3 version worked fine. Either way, before resolving this we need to do a follow-up patch to fix this.

Sad to see that instead of something that would work for everyone at no cost, problematic Wikimedia-specific hacks are introduced for no explained reason. Also, mockup still places buttons in the incorrect place, they should not be before more specific site links.

The list part was explained by @matmarex already: previously wikitext supported defining multiple redirect targets so list made sense before. Checking for <link> tag is fine, though then it needs to be added into HTML for legacy parser without duplication for Parsoid. If you know a way to do this, please tell me.

In T373208#10487209, @stjn wrote:

Like, on a related topic, I never got why footer links differ between mobile website and desktop one. If a link is important enough for desktop version, it should be important enough on mobile as well.

This also prevents people from adding their own links to the footer, which some scripts do (including my own https://www.mediawiki.org/wiki/Translator_Buddy which I have to fix now since mw.util.addPortletLink does not add anything on Minerva). (Update: ah, no, that is instead because Minerva CSS hides most of the links via CSS and any user-generated links get hidden, too.)

I tested it a bit while logged in and didn’t see any major issues other than the main page being displayed at 200% width, but that seems intentional. As I’ve said above, I adapted most templates, if not all of them, while doing night mode fixes. Stuff like Special:Translate is a bit problematic since it is not responsive at all (though maybe it is doable to make it have basic responsive support at least for making two-column layout display nicely on mobile) but on wiki pages themselves it should be fine. Worst case scenario, this can always be reverted.

Looked into it, apparently CSS support is defined in https://gerrit.wikimedia.org/r/plugins/gitiles/wikimedia/portals/+/refs/heads/master/gulpfile.js/postcss.js
It has IE6-8 support since 2016 (067ca2bcce7e16f2e829bf86ce33c4b7065a25d4, result of T125566). Pretty sure only IE 10+ can even open Wikipedia pages for a while now. Not directly related to this task, but seems like something to look into. The full string is [ 'last 5 versions', 'ie 6-8', 'Firefox >= 3.5', 'iOS >= 4', 'Android >= 2.3' ], unchanged since 2016. Grade C support does not include most of these.

In T373208#10486010, @Jdlrobson-WMF wrote:

@Ladsgroup given the icon is different for different resolutions, I think this will require an architectural change.

Can you clarify what’s the benefit for doing a more over-engineered solution? Is it just because the buttons would look too big on mobile or something? I feel like footer is one place where you can get away with it. Like, on a related topic, I never got why footer links differ between mobile website and desktop one. If a link is important enough for desktop version, it should be important enough on mobile as well.

I feel like the best way to solve this particular issue would be to split one input field into two and show them depending on what is selected. Then the code can just show one kind of suggestions to one type and the other kind to another. The labels etc. do not need changes, of course.

AFAIK it is not something to do with WikiEditor (2010): this is how JavaScript regular expressions usually work. \b only works as a word boundary for Latin symbols. Test it out at https://regexr.com by adding a Greek word or even Cyrillic word like пример and using a regex to find it. It will do so with Latin but won’t with Cyrillic/Greek/any other Unicode. That can’t be fixed by WikiEditor (or any other extension that supports regex), it can only be fixed by browser vendors.

In T377043#10240541, @Izno wrote:

Less commonly, the template extends beyond the reference list to its container: setting the section title and style, and suppressing the edit links. This will be left out of scope for now.

This is a discussion point in T364830, but probably deserves its own task. I'm not personally a fan of it in the slightest.

Just to clarify: that task was created because of a problem I was solving, namely, subpages with dynamic content sometimes including references in their output and those references not being displayed nicely. The code there removed a whole bunch of worse solutions to this problem from editors (like putting a References template for a reference not in the page and then that references list becoming empty if it gets deleted, or hiding references on every subpage individually), at no cost to anyone but mobile app users. AFAIK Dutch Wikipedia also uses a template for showing all of their references in a box: https://nl.wikipedia.org/wiki/Sjabloon:Appendix It is also something that could be used in a template like https://en.wikipedia.org/wiki/Template:Reflist-talk
(But personally, I was fine with solving that task by not showing an empty references list in Parsoid read view output.)

As I’ve said earlier, this also impacts mobile experience on all Wikipedias, so I think this should be solved earlier than ‘Parsoid rollout’. Are there any stopgaps now to adding some code to check if there is one section on the page to the code on MF level?

In T308286#9522573, @Jdlrobson wrote:

The current brand guidelines of taglines in Italics in standard font do not seem compatible with Cyrillic text for example. Who would be the best person in your team to talk about this?

FWIW I feel like Cyrillic is the only script that actually uses italic for taglines. Apart from Russian:

• https://be.wikipedia.org/wiki/Дэналі (particularly unreadable example)
• https://be-tarask.wikipedia.org/wiki/Аляска_(штат)
• https://bg.wikipedia.org/wiki/Денали (in lowercase for some reason?)
• https://uk.wikipedia.org/wiki/Деналі
• https://sr.wikipedia.org/wiki/Денали

Another example without quotes: https://ru.wikipedia.org/w/index.php?search=Туркменистан&prefix=Википедия%3AК+переименованию&title=Служебная:Поиск&profile=advanced&fulltext=1&ns4=1

That’s usually because of not applying correct https://developer.mozilla.org/en-US/docs/Web/HTML/Viewport_meta_tag

This isn’t TemplateStyles-specific. Anything that is not written in Less that needs to use Codex tokens would need CSS to be structured in the same way for maximum compatibility: var(--example, FallbackValue). Without the fallback value, skins that do not provide Codex tokens would experience the loss of styles. The dropdown that is proposed in T374487 is actually a much more complicated solution to the more general problem of being unable to copy Codex tokens as CSS correctly, since it requires the user to 1) notice the dropdown is there, and 2) choose a non-default version (as I assume CSS would never be default there), 3) if they are in automatic/night mode, also know that the colour value displayed is not the actual colour value needed for light mode.

Some other feedback:

1. Noticing that this page has a lot of prefixes for older browsers that are no longer in https://www.mediawiki.org/wiki/Browser_support Is that added by some automatic tool like Autoprefixer? If so, it could probably be reconfigured so less CSS has to be shipped.
2. Despite using flexbox, the page currently sets a bunch of widths (also duplicated in px and rem despite rem having widespread support) in fixed sizes, but flexbox can be leveraged to make it depend on the current page width. There is also modern gap property that can be used for margins between elements. This is probably why the project list displays like this currently and not in 4 columns:
   
3. <a><button> is not valid HTML semantically. While it is OK to style a link as a button, both elements should not be present there, especially since any button without a type is treated as a submit button.
4. Currently the page has no accessibility tree since no headings (<h1>, <h2> etc.) are defined. While this is a relatively small page, it is still better to define headings. I suggest that Wikimedia text should be <h1>, Our projects, Donate and Contact <h2> and project list headers <h3>.
5. Decorative images currently have no alt attribute, which means that their URLs would be read out in screen readers. All <img> tags on the page need an empty alt="" to be defined (since I don’t think I see a non-decorative image anywhere).

Currently the page has a horizontal scrollbar on desktop resolutions at least in Firefox, I assume because of the strange styles with margin-left. Instead of those, the page should just define a maximum width on container blocks and centre them with margin-left: auto; margin-right: auto; (I would’ve tested if it removes the scrollbar but CSS has a lot of duplication for every single block instead of defining centring styles as a separate class.)