This happens with https://en.wikipedia.org/wiki/Yamato-class_battleship and 1121px width:

Nitpick: as I see, there are 20M and 50M accordingly.

If you add this rule for wikitable, I'll add it for standard. It should mirror wikitable styles except for colors.

@TheDJ As I see, it is not a ruwiki only issue; the same happens with the standard wikitable class. E.g., open https://en.wikipedia.org/wiki/Graham_Greene_(actor)#Filmography and make the window size smaller.

There is an incorrect white gradient in dark mode. Probably it should be fixed before wider deployment:

@Esanders, probably instead of the specific fix for .wikitable.mw-collapsed, there should be a wider fix for .mw-collapsed [ hidden='until-found' ]. In Russian Wikipedia, we have already found a case with a visible border around a hidden element. I believe there are similar issues in every wiki project.

.wb-error class is used to highlight warnings, and it uses #fee7e6 as background color:

@Arian_Bozorg It looks like all the listed pages work as intended. Is it possible to enable dark mode for them now?

There is still an incorrect colored link in system messages, e.g. https://ru.wikipedia.org/?title=Заглавная_страница&action=edit&uselang=en

Also, there is still an issue with the Expand all/Collapse all menu link.
E.g. https://en.wikipedia.org/wiki/Heritage_language

@Jdlrobson, I'm still actively working on the dark mode issues in Russian Wikipedia, and it is already better than some projects in Tier 1/2.
And literally, 3119 / 2617 = 1,19 - which means 19% of the increase.

Sorry, I was wrong. After some not-so-long timeout, it started to work.

@Ammarpad, done, but nothing was changed.

Yes, you are right. Now dark mode is enabled in all namespaces so this task can be closed.

You shouldn't be using system message boxes for non-system messages as it is important these are distinguishable from messages in content - we don't want vandals using them for phishing attacks for example.

Related task: T110329

@ovasileva

Suggested image tooltip in search results (example):

A small magnify icon inside the framed thumb image should be adapted for the dark mode:

In case the Use small icons and minimal text to show review status of pages mode is chosen, both full and minimal banners are shown:

Icons in dark mode currently have bad contrast, they need to be marked as convertible to white. Codex somehow allows this by adding .skin-invert-image class, but I don't know what property is required.

Hide/show button in the desktop collapsible block is not adapted for the dark mode:

@Krinkle A couple of possible use cases:

• autogeneration of documentation, template examples, TemplateData display improvements, etc:
  • https://ru.wikipedia.org/wiki/Модуль:TemplateDataDoc
  • https://en.wikipedia.org/wiki/Template:Format_TemplateData
• TemplateData validation
• autogenerated templated based on TemplateData

As a person with interface-admin rights, I don't have access to the UI but can edit JSON directly. To me, it looks like a logical error. Probably everybody who can edit JSON should be able to use this UI. Also, there could be some additional roles.

Also "hide stability log" doesn't look important enough to be bold:

I don't know how it is expected to be, but right now in Vector-2022 it looks very ugly:

• base font size is 16px instead of 14px
• it uses full width when the categories block uses only the content part
• it doesn't adapt on a desktop to use width at all

@Ladsgroup I know that it hasn't been reuploaded since 2009. And it is really strange because the main issue with this file is not that it is generated poorly, but that for some reason it has two different versions for the same size. Here, for example, 120 pixels:

@Ladsgroup Could you check https://commons.wikimedia.org/wiki/File:Wikitext-ru.svg ?

• https://upload.wikimedia.org/wikipedia/commons/thumb/4/47/Wikitext-ru.svg/43px-Wikitext-ru.svg.png
• https://upload.wikimedia.org/wikipedia/commons/thumb/4/47/Wikitext-ru.svg/120px-Wikitext-ru.svg.png
• https://upload.wikimedia.org/wikipedia/commons/thumb/4/47/Wikitext-ru.svg/472px-Wikitext-ru.svg.png

I would like to say out loud here something important in my opinion. Personally, I knew about the presence of a few critical vulnerabilities in Vega 2 a month ago during the creation of ticket T332096, because I needed to check information about versions for that. But since all my previous experience was that nobody cares (e.g. there is no interest in tickets created after T296855, although there was an actual attack case; T182536 has been around for more than five years), I did not even consider creating a ticket until I try to reproduce it myself when I have free time for this. I would like to understand the position and priorities of the Wikimedia Foundation about not even theoretically possible, but actually occurred attacks. While I am stunned and feel the inconsistency between the complete lack of reaction and such a sharp reaction.

Done in https://github.com/putnik/infobox-export/commit/0a223b0bc44d0109a1f95397d1610143915455c2

See also T118935

In T178249#4704878, @eranroz wrote:

This is very good idea,. However, the task description is slightly too technical, e.g can someone add a kind of "user story" to explain how a regular user is expected to link between the article to be created and Wikidata entity? (I'm missing what, if any, user interface support for it should be made)

I want to note that due to the lack of hints for form fields there are cases like enwiki which adds a banner with information at top of the page.

Since the T208305 has already closed, it is possible that on the technical side, everything is ready for this task. I will try to test the implementation shortly.

Done. Sorting order available at Commons: https://commons.wikimedia.org/wiki/Data:Wikidata/awards_order.tab
And there is a script for update Commons file: https://gist.github.com/putnik/7dcb92c0168392ec8b1c718093e36d1a

In T196501#4261621, @Anomie wrote:

One level of getParent() is useful to avoid having {{#invoke:}} used directly while keeping the wrapper template simple by not having it have to manually pass through every parameter. Additional levels seem more likely to be confusing and fragile as the template containing the invoke starts to depends on the context where it is called.

In Russian Wikipedia, we are now trying to switch to an inter-project solution instead of storing data in local templates. And tabular data on Wikimedia Commons is probably the most convenient way to do this.

https://www.wikidata.org/wiki/Help:Infobox_export_gadget

Perhaps the problem is somehow related to the fact that the developers reused the existing preference: T236780. Given that article previews are enabled for all users, this could cause footnotes previews to be enabled for all users as well. @awight, can you comment on this?

Great tool, many thanks for this work.