T411834 seems to be describing some pretty outlandish concepts with an unclear roadmap to ever being completed. The reality on the ground right now is that shared Lua modules get unsynchonised fairly quickly because either of conflicting changes, not having a shared repository and not propagating changes between them. There are some tools to help with that but I see no issue with @PerfektesChaos’s opinion that this new magic word should validate ISBNs in some way (I don’t have a problem with it being an extension) if it exists. The problem with a shared Lua module approach is that eventually you’ll run into the same problem as T343131: Commons database is growing way too fast, in the case of a module, both for the module itself and for the wrapping template (since most wikis are not bad enough to include modules without a template). ISBNs are highly used on multiple wikis so that’s a real possibility.

Either way, the notion that this styling should only be present depending on whether a page has a signature on it or not is simply misguided. Either that should be the default style everywhere or nowhere. The weird inconsistencies only highlight this. (Personally I also don’t think that what DiscussionTools is doing with <h2>-level headings, making them Arial and bolded even though we moved away from that style in 2014, is motivated by anything reasonable either.)

I don’t have a strong opinion on the change in general, but I think both hiding the comment and requiring the user to hover over it to actually see it once it’s not hidden is a weird overkill that I don’t see any motivation for. If there is a (fairly prominent) UI part that shows the comment, then it should show the comment, not show the blurred version of it.

That was already always possible both via CSS (body.ns-special .mw-userlink) or via JS:

• mw.config.get( 'wgNamespaceNumber' ) === -1
• mw.config.get( 'wgCanonicalSpecialPageName' ) !== false
• mw.config.get( 'wgCanonicalNamespace' ) === 'Special'

I think it is quite unfortunate that this ended up limited just to temp account links. Complicated heuristics to tell where user links are on the discussion pages etc. are a constant in a number of MediaWiki user scripts like Gadget-markadmins.js or Gadget-markblocked.js, so it would’ve been very nice to have this class-based indication instead of having to rely on parsing all links and sifting through titles in tooltips. A much better solution would’ve been fixing the scripts that are misbehaving (or, maybe, introducing these classes in a different convention?) rather than removing a perfect solution to a long-standing problem with user links on content pages.

FWIW to Go/пщ problem: there are current examples of this right now, for example php/зрз returns first one potentially relevant result in Cyrillic and then a bunch of results related to PHP. I think this is actually how this redirect thing should/would function too in that case, so returning a full match title somewhere in the list of suggestions (maybe even always as a last one out of potential ones if it’s too generic, but always the first one out of the ones added by the algorithm) doesn’t seem all that problematic.

Is there any plan to make it so that search pages like https://ru.wikipedia.org/wiki/Special:Search/,fhfr_j,fvf («Барак Обама», Barack Obama) display relevant results as well?

Sorry for misinforming in earlier comment. It is not exactly related because the unstrip post-expand size (UPES) increase happens in the size of the original stylesheet, not in the size of a <link> tag generated by deduplication. So if someone adds some more CSS to the styles page (let’s say 100 bytes), every instance ends up contributing 100 bytes to UPES, 400 for 4 template calls, 800 for 8 template calls, etc.

Would’ve been good to find a way to do this change without affecting Special:RecentChangesLinked (since usually 1 day isn’t enough on that special page) but it’s a really small nitpick.

In T361934#11274958, @cscott wrote:

It might be possible to address this by allowing a single var as a special case to these rules, while disallowing the general case, which is I think what @zdev is suggesting.

This was suggested by many people over the years, as can be seen in T364685: CSS sanitizer refuses TemplateStyles variable assignment to border-color but does permit background-color. No one just picked up on it, even though it’s the most rationale way to set the border colour.

Yes, thanks. This does seem like a flaw, since any extensive use of one template, no matter how small it is, would eventually break the page once a certain number of elements get present. Although it didn’t yet appear in the WMF wikis, there might be a point where it ends up happening, as more and more templates get converted to TS model.

I think the second security requirement is not really necessary if the variable name would enforce what values it might have and TemplateStyles would only accept CSS variables of a particular type. As you yourself say, it’s not a particularly strong protection anyway, so unless it would be required by TS to validate the variable values, it doesn’t seem useful to have.

IMO it might be better to not mention it at all or mention it a week later: category will not become empty immediately after the patch gets deployed, so for a while admins should not delete it because that would make a category red link appear on all those pages where the page is still cached in that version. Any note on this would be better to have once the category actually becomes empty across wikis, and then it can be said something like ‘Administrators can remove the tracking category previously added by JsonConfig, see Wikidata item.’

While it would be better than nothing, it is not really a ‘compromise approach’ since one of the best uses for CSS variables is to simplify colour assignment. I don’t think there’s anything wrong with the idea, though.

…And for messages like (hidetoc) and (echo-badge-count) in most skins you cannot copy their name at all. (This is now solved by Translator Buddy, as well.)

TS could add any random prefix to all defined variables in its output. But I think the task description was never meant to display the required specification in regards to variable safety (and it’s unclear whether this will be implemented at all, unfortunately).

Only because .mw-logevent-actionlink a, .mw-logevent-tool a, .mw-diff-tool a, .mw-pager-tools a is now assigned a link colour. There are other places where this might still fail the same way.

I think you misunderstood what I wrote. I don’t need toggle buttons for elements I am trying to uncollapse (forms on history page etc., certain collapsed elements on wiki pages). I just want to see them uncollapsed. Before, it took a simple CSS declaration to do so. I get that it is more so a problem of CSS specification you’ve used, but still, the resulting reset styles on these elements are pretty annoying to deal with. Having simply all: initial or something would be an improvement, indeed.

It originated from T189316: Developer review of changes to Hindi Wikipedia Main_page [3 hours] which was done with the involvement of then Web team. Then, considering this was a generalised solution at the time, I used it in the Russian Wikipedia main page design as well, and from there it probably spread to various wikis. (I don’t think it is a far representation to say that this was ‘never officially supported by the Minerva skin’ when it was part of Minerva source code for 6 years and was done with skin-specific prefix.)

No, it’s actually great because then people who know a special page by a certain name would be able to find it even if they don’t know the new name. Though there is an unresolved problem with that where canonical English name of the special page isn’t included in the searchable terms (personally I don’t know how to fix it so I haven’t tried).

@DTorsani-WMF could we get feedback on the new patch considering on Gerrit your opinion was used to sort of ‘block’ its merge?

This isn’t a task about starting visual editor with a keyboard shortcut (and such opportunity already exists, Alt+(Shift)+V). This is a task about having a consistent set of keyboard shortcuts being supported across all editors (such as Ctrl+2 for inserting a 2nd level heading). Your objection fundamentally misunderstands the task.

These changes basically broke the entire way you could uncollapse collapsible elements via CSS. Instead of the previous way of assigning the display value to hidden CSS, now you need to override all of these properties or to manipulate those elements entirely via JS (which makes FOUC happen):

.mw-collapsible[hidden="until-found"], .mw-collapsible [hidden="until-found"] {
	display: block;
	position: absolute;
	width: 0 !important;
	height: 0 !important;
	overflow: hidden !important;
	padding: 0 !important;
	margin: 0 !important;
	border: 0 !important;
}

@matmarex I don’t think this was necessarily a duplicate because it was about the specific issue of blockquotes having too little space due to margins around them. But since there was nothing done about it for years since the task was submitted, I guess it doesn’t matter.

Addendum: I think that while action buttons seem like a good idea to you as English speakers, they are not good idea for all languages, and would eat up space unnecessarily on desktop. For example, English Edit, used in example, can be Редактировать in Russian (Undo is Отменить), leaving very little space. If there is a necessity to describe those in the spec, it would be much better if mobile behaviour was what was happening on desktop as well (i.e., if there is little text, show button on the same line, if there is a lot of text, show it on another line), as you cannot reasonably predict the button length in translations. Right now Codex ‘deals’ with it by enforcing hyphenation, but that won’t help if you have a max-width of 512px.

I think the close button should be seriously considered to be a default, if not required. Currently mw.notification-style popups are a bit of a minefield: you can have links in them, but you have to be very careful to click on them and not on the surrounding space, because that closes the notification. Ultimately, this is very inaccessible, especially if someone has motor issues. I understand that adding a button is going to eat some space there but if that’s the concern, then the useless icon on the left/right that is now required should be removed instead.

In https://ru.wikipedia.org/wiki/Википедия:Форум/Технический#Метк|a_и_imgur it is reported that this also affects elements that should not be broken apart, like regular words like Tags. Could this problem be solved in a more gracious way, without affecting interface elements like tag lists and ideally using hyphens: auto instead of hardcore word-break: break-all?

Special pages link was moved to sidebar instead of Tools menu in Vector 2022 (and other skins by extension), but that’s unrelated to this task. See T333211: Reconsider position of special pages link, currently in the page tools

The second option seems better than the first one, since not wrapping at all is hard to achieve and is unlikely to be responsive. But to your broader point, that button row already doesn’t entirely relate to filters: ‘Mark all changes as seen’ button relates to the watchlist itself AFAIK, and marks all changes in the entire watchlist, not just changes shown in the current filter screen.

It seems like it’s not working then. The issue might be that only canonical Latin names are entirely in lowercase in those data parameters, but Cyrillic ones aren’t. (Ideally, as I wrote above, newfiles should also be there though.) As to the amount of such special pages, I don't know how to count that, but probably many depending on the language. Visible page titles are more verbose than their internal names quite frequently.

If all users without an email would be automatically removed from autoconfirmed group, that is a huge user-facing change that would be impossible to understand for many of them. Given that receiving captcha is both annoying and bad for accessibility (see T6845: CAPTCHA doesn't work for people with visual impairments), if this gets implemented, there needs to be some sort of banner for users to explain that they need to add email to their account to stop captcha from happening. It might, however, defeat the purpose of stopping single-use accounts, since they would also know that, but it is the right thing to do nonetheless.

In T219543#10855157, @Ladsgroup wrote:

That's a different issue. We just changed to UI, no logic change has occurred. In long-term, I think we should split into three categories: Public, Users, Restricted. But yeah, out of scope of the frontend change.

Can you give any estimate on when that sort of work (as well as fixing other issues highlighted above) would be done? Because tbqh while some of the changes were an improvement, there is still a lot to do to make the page actually usable. The biggest issue being that you cannot even search for special page names in the wiki language if they do not match the visible label for the page in the list (on Russian Special:SpecialPages, the new files list is called Галерея новых файлов but the special page name is Новые файлы for New files, but you cannot search for the name, never mind the canonical special page name).

This seems caused by Codex message boxes lacking any margins, not by FlaggedRevs itself, so yeah, not really related to the extension directly.

In the case of Russian Wikipedia, this issue is present on many pages such as https://ru.wikipedia.org/wiki/Feltria
On the tech forum a user writes that it works fine if in the HTML source code it doesn’t say Rendering was triggered because: unknown but works incorrectly if it does.

Same issue in Russian:

Same issue reported at https://ru.wikipedia.org/wiki/Википедия:Форум/Технический#Ссылка_на_элемент_Викиданных
Seems like neither {{GRAMMAR:}} keyword is no longer working when it comes to translations of Wikidata into different languages, and Wikidata is now untranslated.

You are talking about the different problem that was described in T5324: On redirect pages, "article" tab in top bar should lead to nonredirected page (&redirect=no). That problem is (almost) resolved and shouldn’t be an issue any more, unless you are viewing the redirect page itself. This is about VE-specific thing where it modifies URL incorrectly for redirects.

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

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. Currently it seems like even the special pages in the current language name are not used when they don’t match the visible label (in Russian, that can be tested with entering Письмо участнику, which is Служебная:Письмо участнику, translation for Special:EmailUser)
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).

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.