@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.

@Isarra Please look at T225412. display: block broke the non-JavaScript interface.

It can be fixed with this code:

.mw-input-with-label {
    display: inline-block;
}

Description available at https://wikisource.org/wiki/Wikisource:Tesseract_OCR

The first version is ready. It is available on https://wikisource.org/wiki/User:Putnik/TesseractOCR.js

It seems that the issue above is resolved. Are there any barriers to specifying p=quarantine or p=reject for the wikimedia.org domain now? I do not mention sp specifically, since there may be problems with mailing lists.

I received a response from Mail.Ru, and as a result, the first priority is T211477.

In T211404#4805307, @Reedy wrote:

I don't think that's completely fair. Some received no further responses, so it's hard to do anything about them Some were marked as duplicates.

I made a patch that adds a method to get TemplateData in Lua. The method is currently named mw.ext.TemplateData.loadTemplateData(), which is long, but according to the conventions available, the prefix for the extension should be mw.ext.TemplateData. Alternatively, it's possible to change the name of the method itself (e.g. to load()). Or, perhaps, someone can indicate the reasons for which the prefix can be removed.

For namespace blocks, it should be possible to specify a list of excluded pages. For example, if the user talk namespace is blocked, there should be able to exclude a pages of several admins that the user can ask, or page for requests to administrators for project namespace block.