We've discovered a lack of defaultsort's on the Dutch Wikipedia recently, some are from the ContentTranslation extension and were never resolved till recently (years to fix). Is there any update on this issue?

Most thumbnails are giving the following error:

Now it thinks it's a input field to login or create an account:

Seems to be a deliberate local change, see https://en.wikipedia.org/w/index.php?title=MediaWiki:Sharedupload-desc-here&action=history

My updated iPad does want to enter my credit card into it (giving me the option above the keyboard), my iPhone running iOS 18 only suggests me to add a credit card by scanning it. Both aren't blocking me like the macOS behaviour. I feel Apple did broaden the scope of what they see as a credit card field in the new version, probably due to low correct autocomplete value adoption.

In T401066#11150347, @Pppery wrote:

This isn't good:

Can each individual entry on a list be forced to stick to one column please?

The above patch fixes unexpected behaviour, like the parser profiling data table being broken in columns. I also made use of the less mixins instead.

Once again I had to correct a sitelink as the user never visited Wikidata. This should have been solved from the start of Wikidata, it's shocking this task still hasn't been solved.

Does the language used in the apps fall under policies of one specific wiki? It used to have an lower f for two years (it seems?), the F has been capitalised in 2017. Perhaps clear consensus about the sentence is needed.

I also wonder if they should use shorter texts, the contributions dropdown on the top-right also doesn't contain "Edit my preferences" in full.

All the inputboxes on https://commons.wikimedia.org/wiki/Commons:Bots/Requests, including the one to create a request, seem to point to MediaSearch now, any idea why that happens? Doesn't happen on for example https://commons.wikimedia.org/wiki/Commons:Oversighters

I feel the suggestions are now too narrow, especially with the last option being on two lines in multiple languages:

It seems the most recent Minerva change cut the bullet points on pages in half:

It's always up to a volunteer to make the current script more configurable, I don't think this needs to be declined. If it creates noise on the specific board just take it off the project.

What is the status of this task? Vector 2022 will be the default skin from next week.

Possible duplicate of T383047?

Still happening today:

This is breaking the workflow of tons of people and should get a higher priority or commits should be reverted as I don't see this fixed over the weekend.

Unknown date is an option I use frequently as it's hard to tell for logo's for example, would love a quicker way for experienced editors to indicate that.

Translators/scripts had almost no time to catch up with these changes, causing texts like "[⧼discussiontools-replywidget-reply-link⧽ Reageerfunctie]" to show up on group0 wiki's.

In T372702#10353445, @doctaxon wrote:

@Tgr: Wouldn't it be easier to recode the login and authentication routines or to revert to backups of the pre-August 2024 version? What is your opinion on that?

In T372702#10329040, @RoySmith wrote:

1506 UTC, I just had it happen to me on the fly. I was logged in, went to respond to a comment using the "[reply]" link, and found myself logged out when I went to save my edit.

Nikki has been so nice to add the assert token to this gadget and other gadgets.

Perhaps you had the main page open, held the keyboard combination for delete page by accident and pressed enter?

I just had the weird behaviour where my account is still logged in but did perform an edit logged out, see T378413.

I fully agree with the comments on the linked Gerrit-task. This discussion comes too late, zero communication towards the technical community. The most important thing is to have guidelines on how to prevent cases like this in the future.

Yes please, this has been long overdue. I've added several properrties to the refine script since the last time it got updated, which will also hopefully have a big impact on the quality of suggestions.

I did some testing on both pages that have been used on this task. It seems the behaviour of the hyphens attribute differs per browser, some browsers tend to cut words in half even when the display on two lines was fine. And honestly the current display (which seems to have changed in the period since this task has been created) seems fine in most cases.

I added some terminology entries, hopefully that helps as well.

Either that or the same screenshots as above in the task would help, yes! I was under the impression this was the final state.

The contrast in dark mode, especially with links, has now become significantly less. I have normal eyesight and have huge issues to read the links when they have either the yellow or orange backgrounds.

I don't think these changes are actually an improvement in light mode. I've heard and read from several people of the Dutch Wikipedia they find the new background color of unpatrolled new pages too light. Concerns about this background color were already raised in T370423, this task is a duplicate of that one.

Did you do a full refresh, emptying your cache? I also had the issue on my work computer but it went away after that.

Due to the lack of a response so far I've already prepared the patch, I don't think there are other viable options and I rather have this fixed than waiting for a formality approval.

In T372702#10103189, @tanbiruzzaman wrote:

Just discovered something about this. On Wikimedia Commons, I was in desktop mode, and everything looks fine. Then I visited to Wikipedia (bnwiki), showing logout here. Then visited Commons again, still logged in until I changed it to mobile view. Commons and Meta shows logged in on the desktop view, logged out on the mobile view, while the rest of other wikis shows fully (mobile/desktop) logged out.

The first two things only happen on windows smaller than 1120 pixels wide and is needed to keep the content readable.

Closest option at the moment would be @background-color-progressive-subtle I would assume?

How can a wiki opt-out of this for their local banners (MediaWiki:Sitenotice) if they have the local (interface) moderators that are aware of these display issues and are able to mitigate these?

In T365311#10043176, @MusikAnimal wrote:

Proper dark mode styles are now ready for review: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CodeMirror/+/1059166

This includes reworking the search panel to use Codex CSS components (T371436), which in turn gives us dark mode styles for free.

In T365311#10042667, @hgzh wrote:

The temporary color inversion doesn't work with os clientpref by the way.

Works on https://test.wikidata.org/w/index.php?title=Wikidata:A_random_test_page&action=edit&useskin=vector-2022&vectornightmode=1

Fixed on my side.

Classes are inserted on the correct element with the above patch:

Sorry, wrong task ID!

With dark mode being more rolled out now could we please add the CSS classes for the time being?

In T369391#9958455, @Tacsipacsi wrote:

In T369391#9957534, @Jdlrobson wrote:

• Visit https://ru.wikipedia.org/wiki/%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:%D0%9D%D0%BE%D0%B2%D1%8B%D0%B5_%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D1%8B

I see no colors and thus no problems in safe mode. FlaggedRevs certainly does have a number of night mode incompatibilities, but this particular page is the fault of on-wiki scripts/styles.

In T369391#9957546, @Jdlrobson wrote:

https://gerrit.wikimedia.org/g/mediawiki/core/+/c86466f5dcf24c9ce51c482f1b7796bf511ad1d8/resources/src/mediawiki.special/newpages.less#13 likely also needs updating but I couldn't replicate how locally!

On a new pages patrolled ($wgUseNPPatrol) wiki, create a page with a user whose edits are not patrolled (e.g. an anon, but Translate’s FuzzyBot also works for me), and then look at Special:NewPages with a user who is User::useNPPatrol() (e.g. an admin).

However, I don’t think this style is in scope for this ticket – other than both having something to do with patrolling, there’s no connection between FlaggedRevs and core’s new pages patrol. I think the two should have their own tickets (and since FlaggedRevs was the first here, probably T369391 should be about FlaggedRevs).

In T369385#9994519, @Lucas_Werkmeister_WMDE wrote:

Using the “dark mode toggle” gadget, this looks totally fine to me to be honest:

I haven’t been able to find any other dark mode – even in Vector 2022 (which is not our default skin)., the toggle I know from English Wikipedia isn’t shown.

^ @Jdlrobson Dark mode works as expected, it's the font size that is the issue.

This would also be nice for class=skin-invert-image.

Also, when opening on of the popups that feature a new item it briefly flashes very light blue in dark mode.

This just shows the technical debt the Wikidata interface has had for more than 10 years. A rewrite to Codex is probably easier at this point.