The public domain archive is now fully moved out of wmf and the tool is empty now and deactivated.

I think in order to get resolved https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/1081067 should be merged? See also https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/skin-Minerva.php#L52

First of all, thanks for bringing up the issue in this friendly tone, it's completely understandable and @Ladsgroup and I were thinking about it also.

Is it possible someone to either move https://commons.wikimedia.org/wiki/File:Ettelaat13130918.pdf to the already deleted https://commons.wikimedia.org/wiki/File:Ettelaat13130911.pdf or, restore Ettelaat13130911.pdf and delete File:Ettelaat13130918.pdf anyway, (the correct date per the document is 11 and the files were duplicates at the source) I am constantly getting error as a sysop and am instructed to get help here.

Words starting with ئ (which none exist in Persian and this word is just incorrect and imaginary) are categorized under ء also in Persian Wikipedia,

Thank you so much for giving me the roadmap @Jdlrobson-WMF

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

You are adding those tags everywhere anyway, see for instance https://en.wikipedia.org/wiki/Special:Contributions/Stjn

That makes every message in need of <bdi> because this isn't needed just for RTL locales but also for LTR locales that need to display registered usernames with RTL text. As a rule of thumb, <bdi> is needed whenever UI text is mixed with user generated text, more on it here T375975#10199315

"Gender cannot be used here at this time (January 2022)" apparently was added by @Eihel in https://translatewiki.net/w/i.php?title=MediaWiki:Contributions-title/qqq&diff=prev&oldid=10477492 guess at the time it didn't work either, not sure what happened in MediaWiki to make it work, hopefully a solution like https://gerrit.wikimedia.org/r/1123410 can make it work again.

This has caused the regression and the solution is to send gender template input separately from what it should show like 'contributions-subtitle' which isn't the case with 'contributions-title', and it interestingly it specifically says Gender cannot be used here at this time (January 2022 https://github.com/wikimedia/mediawiki/blob/b4550953ff13d11e47c3cef17d0140a46b793065/languages/i18n/qqq.json#L2790

You probably mean T385876 I guess, last change here is for months ago

Thank you so much for your answer Jon, please feel free to point out to the specific accessibility issues to me so I can check if I can be helpful and am able to resolve easier ones maybe and while I surely understand beforehand many important issues already exists, I just wish initially just my local wiki (fa‍‍wiki) that I surf everyday using the dark mode and am improving different bits of it with dark mode can get this following OS option as the default option specially as I believe it's expected for whose that have the OS setting for dark mode to see websites per the OS settings (say like e.g. https://www.instagram.com that gets dark mode based on OS setting just right from the start) but that's just a wish and I understand your concern as well.

(Added recent editors of LabelService.java though I'd guess this isn't from the particular file, I just hope someone would have a clue on where this sort of normalization can come from)

Code wise this is resolved but we need a new CSS Sanitizer release to happen so this and T322482 can be deployed.

(ReleaseTaggerBot has given two different deployments date, hopefully we don't endup with one part in one deployment the other on the next)

Fix will be on 2024-10-29's deployment.

Fix will be on the next deployment.

Fix uploaded as soon as I saw your message here @Izno, my mistake.

Fix will be on the next deployment.

Fix will be on the next deployment.

I also am getting it here https://en.wikipedia.org/wiki/Cameroon#/media/File:Paul_Biya_with_Obamas_2014.jpg after some tries now. I see what @Jdlrobson also have described, .cdx-button.mw-mmv-button is not enough to always win over either of .cdx-button:enabled and .cdx-button.cdx-button--fake-button--enabled so I felt the lower risk and future proof solution can be to increase the specificity only by repeating .mw-mmv-button again. I first went with just adding :enabled but that alone wasn't enough and cdx-button--fake-button--enabled also needed to be on some of the buttons that's why I thought just repeating .mw-mmv-button can be a lower risk solution here.

Apparently I even have tested it and filed T376889 for it's lack of night mode support but forgot to click that button once... Fix uploaded and tested locally

In T376814#10239188, @Titore wrote:

In T376814#10239083, @Ebrahim wrote:

I can't see the issue locally so guess I need help for reproducing this

This happens when you enable showing pages being added or removed from categories.
[..]

I can't see the issue locally so guess I need help for reproducing this

I can't reproduce this, not locally, or in prod. Not in Safari or in Firefox.

I just checked this happens only in Firefox and Safari but not in Chrome (sorry for not checking that earlier) so have filed bug against the two also,

Thanks Od1n, very appreciated, I should do that for my local wiki also sometime. There are still some remaining extensions and I've got busy with some other things but overall this went well I think. Thanks

I second what Tacsipacsi said, it's specially gives bad feeling when one enables the dark mode and it goes from dark to light in matter of navigation in single site. FWIW I've enabled the dark mode in Wikimedia's Phabricator, it has some shortcomings and bugs but I already can't use the Phabricator without it anymore and have the same feeling about Wikidata also. I for myself have fixed dark mode issues on different extensions (e.g. ProofreadPage) but Wikibase was a little hard to setup for me, otherwise, I liked to go for fixing it myself also.

Locally reproducing both issues (search box going from light to dark and arrows) using Firefox and it's 'Disable Cache' option,

@Fomafix as you first noticed this issue, can you please try to fill this communication gap also?

In T375975#10228675, @stjn wrote:

What I don’t understand in that instance with .autocomment is why → isn’t part of the tag contents, not why the browser bug happens.

In T375975#10227259, @stjn wrote:

Adding <bdi> tags to edit section summaries seems to have affected how focus outlines are now rendered (before/after) in Firefox:

<span class="autocomment"><a href="/wiki/Википедия:Кандидаты_в_избранные_списки_и_порталы#Доска_почёта" title="Википедия:Кандидаты в избранные списки и порталы">→<bdi dir="ltr">Доска почёта</bdi></a>: </span>

Part of the issue that I'm bringing back a dir mark call there even though it doesn't have to be dir mark, a nbsp, zwj, zwnj could do the trick also, one surprising thing I'm seeing with HTML but I guess it has something to do with whitespace collapsing.

Actually reviewing stackoverflow again I thought this can have much less painful alternative solution like this also https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1079488

WIP fix can be seen in https://patchdemo.wmcloud.org/wikis/fc32db7fae

The post https://www.alwaystwisted.com/articles/css-logical-properties-and-sass that I just saw has something related, it differs from our approach though

Based on your comments I uploaded a patch, it follows Minerva on the way it's applied rather than Vector (applied to <body> rather than <html> and simple use of $ instead of manual use of DOMContentLoaded) as the Vector one was almost unused before the works here and Minerva one is older it seems.

@Ebrahim: Do you think that there could be a connection to the problem with "strange white squares" in this thread?

This isn't solved though, we still need a generic class to be implemented, one that Codex team also agrees with, so we can fix all the similar issues in CategoryTree, Codex and the different skins. Someone from Codex team can have a look at the suggestion of Fomafix? Thanks

The fix can be seen in this patch demo http://patchdemo.wmcloud.org/wikis/59799e23e1/w/

Watch star on mobile interface still has an animation, filed as T376872

https://gerrit.wikimedia.org/r/1079146 should fix this as locally it turns

A fix uploaded at https://gerrit.wikimedia.org/r/1079146 and here is the screenshots https://phabricator.wikimedia.org/T376814#10216430

I reproduced the issue on testwiki. As markup there are too different from regular use and the page is doing things too differently I think the revert is inevitable albeit being painful.

https://github.com/wikimedia/operations-mediawiki-config/blob/64b31d9/wmf-config/skin-Minerva.php#L56-L65 needs to be removed if this ever happens.

There is also one in watch animation which is in Vector skin code so can use Vector's own style right now, https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/1078106

I wrote the following at https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1077705 and am writing again here,

It has turned from