Yeah, but at that point that should be maybe something that is looked into by Vector 2022 developers. I would also note that there is a skip link at the start of the page that leads to the same place your wrongfully placed skip link leads to.

As I said in T358792, these links should not be added to places where they would be announced to screen reader users unnecessarily. I assume some of these use cases are useful, but others would just duplicate existing screen reader functionality: for example, screen reader users have an ability to skip through landmarks like those navigation templates you mention if they are marked up appropriately. That doesn’t mean that the skip links are completely useless, but they might be more of a nuisance when it comes to adding a skip link for every image like suggest.

Yes, I was talking about that gap (caused by the skin).

I see. I assumed the size isn’t adjusted there because it is much bigger than the rest of the skin. Ultimately, I always thought that it would be better if Monobook got adjusted to 14px/0.875rem baseline that other skins use for consistency and reducing such differences (so then people could just use zoom to adjust the entire interface), but I understand no one taking that communication work up.

While Vector 2010 is obviously the most important skin, I hope you folks also look at other skins and adjust that variable in them, since the issue is exactly the same in Monobook.

Following the conversation with @putnik about this, I submitted changes that make the gadget work like this instead:

In T358792#9855482, @Jdrewniak wrote:

Alternatively, plwiki has this kind of gadget enabled by default. In that implementation, the edit link appears beside the title of the page:

Even without the gadget, there is clearly an issue here with the breadcrumbs on the left being on a whole separate row from the indicators on the right. So yes, the gadget work can be discussed, but this issue is broader than that even if @Iniquity did not explain it fully enough.

Codex now defines font sizes everywhere as var(--font-size-medium, 1rem) but many skins do not have CSS variable defined so it falls back to that size. Clear regression that shouldn’t have happened with whatever the intention was. I suppose it is caused by https://www.mediawiki.org/wiki/Codex/Release_Timeline/2.0/Breaking_changes

Tagline space issue is a separate one and seems to be from the fact that the current version of the tagline is 120×11, while the new version of the tagline is 135×15, but the top margin for the tagline is hard-coded to be 5px no matter what height it is.

I don't think (plural) you’ve necessarily understood my comment. The problem isn’t that the height of the logo should be bigger, the problem is that in the new version, the dimensions of the wordmark are 135×20, while in the current one, they are 120×20. So in all three mockups the dimensions look wrong in the new version. It might’ve been a bug with configuration? If I manually switch the wordmark to the previous width, it looks better (though there is still too much space between the wordmark and the tagline).

Some additional suggestions:

1. Testing it at https://ru.wikipedia.beta.wmflabs.org/wiki/Служебная:Спецстраницы with Russian version, it would be good if the search actually supported entering Version (canonical special page name) to find Special:Version.
2. Also, might be a good idea to support entering Special:Version (or Служебная:Версия) even if it is a bit redundant. In that case, Special: prefix could just be removed from the query. I think that is how a lot of people think about special page names, so this might reduce friction from the new search for power users.
3. It would be good if you could filter things in the table to a specific category by clicking on its name. It could just involve entering the name into search field programmatically, as far as I can tell.

Search field should probably have a bigger width, as the current one makes sense for English but would probably not display complete label in other languages (Search special pages is something like Найти служебную страницу in Russian, for instance).

My suggestion is that both should start either with Gadget- or Gadgets- (Gadget- being preferable due to being an older convention and not requiring much changes). Right now it seems unsynchronised between the two despite the messages being related (one is section header and another is section description).

The message name ended up to be a bit confusing since gadget section headers use Gadget-section- convention but these new messages use Gadgets-section-info convention. Personally I think this needs to be fixed before it gets too prevalent. (I tried creating the section description by going to header description from Special:Gadgets and adding -info- and that’s how I spotted the issue.) @SD0001 @Novem_Linguae, what do you think?

Yeah, I understand that part. As far as breaking tools or gadgets goes, the plan was always to keep the legacy classes, so any disruption should be minimal unless they explicitly were relying on ul.redirectMsg etc. (which I doubt anyone really does).

I don’t think it should’ve been rescoped, since adding the link tag was only part of the task intended to unblock further work on its original description. (Thanks for pushing it forward, btw!) The task description still is primarily about unnecessary list markup, so it makes more sense to restore the previous name (or a similar one, like Improve redirect HTML markup semantics).

After looking into T390437, IMO before enabling this the email that gets sent out should at least be made to look more presentable. If you want the least amount of friction, the login code should be on its own line and bigger so it doesn’t take much effort to copy it. Other than that, my only thought relating to this is that it is fine and even good to enable this by default but people should be able to opt out of it if they wanted to.

Thanks for providing the link. Current logo for comparison: https://ru.wikipedia.org/wiki/Заглавная_страница?useskin=vector-2022
On my device, the 3rd option looks the most legible. However, all three options don’t seem to be displaying as well as either the current Russian logo or English logo does because they have a wide gap between the wordmark and the tagline and the wordmark seems squished in comparison to the pre-Vector 2022 logo:

Well, yeah, but since the target is still known to the interface, the proper way to fix this would be to pass the proper context to the variable, not to hack around it. If it is possible at Special:ExpandTemplates, presumably a similar thing is also possible for the Special:MovePage.

Also, this issue could’ve been completely avoided if there was clear documentation on such avoidable localisation issues that people could point to so patch authors have to introduce new variables instead of breaking the old ones, as happened here with previously working $1, and left the grace period for others to voice their concerns over the direction of their proposed patches. Alas, Wikimedia movement is at many times imperfect.

This task was and is not a duplicate of a newer task that just documents an issue created while (incorrectly) fixing this task. I marked this task with Gender-Support tag which is what it is the most related to. As it says in I18n, it is a gargantuan non-specific mega tag so forgive me for not marking this task up with that. I’ll try not to forget in the future. Opening to re-close without a false duplicate connection.

https://translatewiki.net/w/i.php?title=MediaWiki:Contributions-title/ru&action=history shows that manual changes in the patch did not actually merge into translatewiki.net code and did not end up in the localisation two weeks later. That needs fixing, but I’m not sure how. Seems to be the case for most languages: https://translatewiki.net/w/i.php?title=Special:Translations&message=MediaWiki%3AContributions-title

Given previous 93.5% opposition to enabling Vector 2022 in Russian Wikipedia [1] and the current community discussion at tech forum [2] uniformly rejecting the newly proposed deployment a year later, adding the proper tag to denote how anti-community this task is. The new vote at https://ru.wikipedia.org/wiki/Википедия:Голосования/Срочное_включение_Вектора-2022_(2025) to be run from 20th to 30th March would probably show similar opposition level, given that nothing was fundamentally changed since a year ago.

Self-plug: people interested in having the ability to go from uselang=qqx to individual pages can now use https://www.mediawiki.org/wiki/Translator_Buddy user script, which shows the tooltips with links to messages (local and on translatewiki.net) on right/left click.

Reason for parent removal: this is not a subtask of T314620: The Language selector appears on pages where it is not used and it ends up bloating T375046 with completely unrelated tasks in the relation tree. Next time please mention related tasks, if necessary, in the task description.

The smarter way to go around this already would be to introduce a variable to the extension like $wgSyntaxHighlightSupportDeprecatedTag that is false by default and then turn it on in Wikimedia production. Then on a reasonable timeframe this support could be removed either from individual wikis that want it or from all of them in its entirety. This limbo state where the tag is simultaneously there but also constantly working and causing to populate a maintenance category isn’t the best. If the tag is truly deprecated, then it should not be supported by default. AFAIK currently that’s not the case.

<source> was bad not because it is a shorter name or an alias but because it conflicts with an HTML tag. Most people are currently typing out things keystroke by keystroke on many wikis if MediaWiki:Edittools or similar doesn’t contain all the needed syntax combinations. While I don’t think <sh> / <shi> / <shit> are the way to go here, having syntax highlighting with a shorter syntax that wouldn’t conflict with any HTML is a normal idea. Half of the solutions you describe aren’t.

It was temporarily broken in T387468 and then fixed. The fix did not get deployed yet. Anyhow, a task that was resolved 4 years ago should not be reopened because of newer bugs in the future. New tasks should be opened instead.

Also got reported a lot on DiscordWikiBot’s side. I’ve done changes to not post anything stale, but if I had a nickel for how often this happened with EventStreams infrastructure not just in this past week, I’d probably have at least a dozen by now.

I would note that this is by no means an endorsement of the extension which comes woefully short of addressing the actual needs of Russian Wikipedia community when it comes to graphs, the arch-problem to its usefulness being https://www.mediawiki.org/wiki/Extension_talk:Chart/Project#Data_source

No reason to close this task as a duplicate of what is pretty much an Epic in terms of work which seemingly would never get done. @DannyS712, in the future, please do not close tasks this way unless the issue described actually gets resolved.

Currently it is still pretty hard to read through the changes as described in the original task:

As I mentioned above, not a duplicate of that task. Here it was about visual ideas of improvement, in T369466 about wording.

Anyway. Functionally fixed, even though I disagree with ‘move fast and break things’ approach displayed by @Ladsgroup and @Ebrahim here and them not listening to the substantive feedback I’ve had on the way the fix for the issue was implemented. I regret asking them to look into this after this but that’s my own fault. Hopefully future <bdi>-related improvements also take in account the needs of message translators to understand the message properly and, more importantly, take time to test for features in other languages, which also have ‘hundreds of millions’ of users and are also important enough to consider here.

Could you maybe also add a panel to the home page like we have here (‘Welcome to Wikimedia Phabricator’ one) with some short text basically saying it is a test instance, and linking to phabricator.wikimedia.org? I think if you do, this task can be marked as resolved.

In T387468#10588368, @Ladsgroup wrote:

You rely on LTR languages only, we and hundreds of millions of others write in RTL languages daily and it adds benefit to us. If it doesn't add benefit to you, it doesn't mean it shouldn't be done.

You keep making it seem like I do not see a benefit to <bdi> tags. Once again, I do not disagree with their addition. I am saying that it should’ve been done in the message text, not in a separate unexplained variable that broke the way the $1 variable worked before. I am not against <bdi> tags. Please stop misunderstanding me.

In T387468#10588289, @Ebrahim wrote:

Before that it was invisible characters all around, and they could end up in clipboard when user copied text from pages and that was worse user experience e.g. T27277 and W3 also suggests against that T375975.

My point isn’t that I don’t understand <bdi> tags. My point is that there is no functional benefit to having a breaking change <bdi> variable when those tags are not added conditionally.

In T387468#10588267, @Ladsgroup wrote:

and IMO, it's a tabs vs spaces discussion, it's not nice to push your style on others). Feel free to make a separate patch to do it "your way"

That’s pretty disrespectful to say when you already merged a patch that complicates that work because now every single message needs to be edited back to the way it was before.

To explain it better, previously the message was straightforward: $1 denotes a username in plain text form. It gets passed into GENDER and that’s also not hard to understand. Now, instead of that, we have $1 which denotes ‘username in HTML form’? and $2 which is also the username but in plain text form. Maybe that sort of complication is warranted sometimes, but here I completely don’t understand why that’s preferable: <bdi> isn’t inserted conditionally, it gets inserted everywhere. Translatewiki already ensures that any HTML tags etc. in the message are required to be present in the translation. So what’s the point to the second variable, especially the one that doesn’t match how the message behaved previously? Looking slightly more clean?

You are adding those tags everywhere anyway, see for instance https://en.wikipedia.org/wiki/Special:Contributions/Stjn
So what’s exactly the problem with adding them in the localised messages? Not that there’s any point in giving feedback any more considering the patch was merged in 15 minutes despite my objections.

Well, there’s at least 24 messages doing that elsewhere so there is clearly precedent: https://translatewiki.net/w/i.php?title=Special:SearchTranslations&query=bdi&language=en

A better solution might be to put <bdi> tags in the message text, as is done usually in such instances. I don’t think your proposed solution is good as it complicates the translation for no reason.

Ah. Different task but the same authors/principle. You are probably right.

On a more structural level, I do not understand why instead of making the link point to Meta, the team decided that the best thing they could do was to make the special page a 301 redirect. It would’ve been faster for end-users if the link just pointed to Meta in the first place.

Please investigate whether the changes here caused T387468: GENDER keyword is no longer recognised in Special:Contributions title. If that’s the case, better language support for RTL languages inadvertently broke language support for many languages.

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 in the commit message 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 (but obviously that parameter would not be allowed on Wikimedia sites).

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. 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 use 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 in a new tab, 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