In T411834#11599489, @Amire80 wrote:

That's exactly what I'm saying: It's possible, but not practical.

This task is exploring how to "allow users to deploy Lua code which is stored in Git to multiple wikis", and I'm saying that it's already possible, but almost no one is actually doing it, and adding a new workflow that involves Git differently is not going to work.

In T411834#11598784, @Amire80 wrote:

The task T209310 is an example of moving the code of an on-wiki Scribunto module to a Git repository. It shows that this is already possible. However, there are almost no other examples of this, so the fact that it's already possible to put Lua code in Git and call it from on-wiki modules didn't cause many module developers to actually use it and move a lot of modules to Git, even common and stable ones.

Wikibase could use the wgContentLanguage for short descriptions.

Reported again on enwiki yesterday: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Edits_to_watched_article_not_appearing_on_watchlist

Also fixed 5 wikis that were using #wpTextbox1[readonly] + .ui-resizable > .ace_editor.

In T323330#11548778, @SD0001 wrote:

The selector can be changed to .mw-textarea-protected + div .ace_content. Doing this now.

Global search shows 51 site CSS pages using .mw-textarea-protected + .ui-resizable .ace_content selector to target the CodeEditor div on protected pages. This no longer works as there is no ui-resizable class.

In T393231#11544522, @Samwilson wrote:

I take it we want the resizing bar to be present even if the usebetatoolbar preference is false?

Why? Where can I read the reasoning behind adding this whitespace?

I suggest going with the first option for now and creating a separate task to explore the possibility of extensions extending the list of recognized globals.

In T413944#11512965, @Pppery wrote:

The problem is probably that the page_content_model field does not agree with the content model in the revision table.

The page is also non-editable. The error message seems self-contradicting:

This is live now.

As communities have started referring to category-triggered gadgets as "template gadgets", it seems to make sense to actually make them template-triggered. A category may or may not be required. When the template is used in interface messages, it's actually harmful to use a category as that causes views that use the interface message (even special pages, forms, etc) to oddly have the #catlinks footer.

In T413707#11490109, @Bawolff wrote:

Not sure if it would be better to do some of this in the CssSanitizer interfaces instead of solely in the TemplateStyles extension

The list of pages that need to pass can be obtained by going through every WikiModule in the module registry and calling getPages() on them. This isn't exposed client-side, but it can be done within the API implementation. Not sure how we want to expose it:

• Validate to ES2017 for pages needing to pass Peast, and ES2024 for other pages? (The API caller won't be able to tell what standard was used for validation.)
• Send error code syntax-error for issues on pages that need to be compliant, and syntax-warning for other pages?

In T413462#11484407, @Tacsipacsi wrote:

In particular, how would one specify the language in which the code needs to be highlighted? Different syntax highlighters have different language identifiers, with large overlaps, but also differences. If it’s a generic interface in core, it shouldn’t be Pygments-specific.

They are from CodeEditor's linter, which is outdated. Unlike true validation errors from css-sanitizer, these errors wouldn't block the save. You won't see the errors if you opt in to "Improved syntax highlighting" beta feature.

This is clearly a bug in the gadget. Should be reported on the gadget talk page.

Passing yes/no is very unusual in the Action API. It makes it look like a boolean param, so people might expect 1 to behave same way as yes. For an enum param, the names could have been more descriptive, eg. discussiontoolsautosubscribe = always / never / preferences.

There is an .nvmrc file, which says 20.19.5.

In T373711#11467068, @MusikAnimal wrote:

T310833 strikes again! As noted above, the screenshots are not visible :(

One thing that is not clear to me is how testing would take place when Lua modules are no longer developed on-wiki. While gadgets can be tested while they're sitting on your local filesystem using the localhost import method, I'm not aware of an equivalent way to test a module without saving it on-wiki. API:Scribunto-console can test output from an not-yet-saved module, but it's text-based and cannot display any html. Special:TemplateSandbox (and its API:Parse extensions) can display previews, but requires the modules to be saved on-wiki first.

~~~~ and {{subst: work through PST. The rest is parsing.

Some UI/UX suggestions, based on comparing with CodeEditor:

I think T373834 is a good middle ground, which ensures pages can be still be backlinked, categorized, and tagged for deletion.

Categorization doesn't work because subjectpageheader is used as an *interface* message. For it to work, the message will have to be added into the parser output (like with scribunto-doc-page-show). There are other things that will change by doing that:

not actively working on this; it turned out be more complex than initially anticipated.

In T362937#11449671, @tstarling wrote:

Why get the parser involved? Why not load from the pageviews API on the client side?

It has tests now, added in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/SyntaxHighlight_GeSHi/+/926661.

This doesn't actually work in production:

I think Tgr is talking about what is possible with Parsoid, not what it currently does. It does seem possible for the DeduplicateStylesDOM implementation to hoist style tags out from tables.

The order matches what shows up in the db (sorted by user id). It's stored after normalizing the names, adding @enwiki suffix, and removing duplicates. The last step in particular can make it difficult to preserve the original order. I don't think it's worth it.

TranslationRepo uses the same flawed pattern as the other pages which were fixed; this one wasn't fixed as there was no reproducible issue.

I create a Vue component such as "Foo.vue" similar to this (may need some changes to work with MediaWiki):

<script setup>import Component from './Bar.vue';</script><template><Component/></template>

For CSS, work needs to be done to have css-sanitizer and/or TemplateStyles return the violations in a structured format.

Okay, I see it now.

This is related to T200206 but not the same.

A new SVG sanitizer has been built (originally for T407783, hack attempts welcome!), which could be used for client-side rendering. This would avoid the security issues from users opening the image in a new tab, even without a CSP policy. Essentially, we could keep the transformation step but do SVG -> sanitized SVG instead of SVG -> PNG. While we're at it, multilingual SVGs can be handled with some postprocessing to avoid client-side language selection (process elements with systemLanguage attribute and check if it matches the lang= of the thumbnail - remove the attribute if it does, or remove the element if it doesn't).

The speak property isn't supported in Firefox or Safari. Chromium supports it but it implements what might be the old spec (bug 40813740). None of the other properties from Speech Level 1 are covered on MDN or caniuse.com, so not implemented in any browser. Probably best to to keep this out of css-sanitizer for now.

This can be announced together with T384992 which is similar. I'd suggest:

CSS variables defined by the skin, codex or using HTML style attributes in wikitext, can now by used in TemplateStyles within math and color functions such as calc() and rgb(). [[phab:T405519|1]] [[phab:T384992|2]]

I ran a little experiment: the lua module at https://en.wikipedia.org/w/index.php?title=Module:Sandbox/SD0001/ext&oldid=1323886587 has functions to show the existence status of 500 pages, with and without use of newBatch().

In T117884#11394985, @mszwarc wrote:

A thing that we also thought about is to remove the "Expires:" header above the dropdowns, and instead to pull it into the item labels. In this scenario, the list would look like "Does not expire" / "Expires in 1 day" / "Expires in ..." / "Other expiration time" (shown below). Would such a change improve the page in your opinion?

I believe the username is mentioned in the "To:" header of all Echo emails.

Is there a practical use case where it creates an issue? newBatch() is intended to help avoid hitting parser function limits, but if you are really going to abuse it for 7000+ page lookups, it'll inevitably hit some limit or another. That's not a performance issue, it's the system working as intended to prevent excessive load.

There's a user script that does this: https://en.wikipedia.org/wiki/User:SD0001/hide-reverted-edits

In T405861#11376657, @Wellverywell wrote:

So does this mean somebody can now port Vega library to Lua (at least some very small subset of it) and we'll finally get working graphs from dynamic data (non-interactive, but still)?

"b" indicates a bot edit, not an edit by a bot. There is a difference. Accounts with markbotedits right (given to administrators) are able to make bot edits that they are hidden from RecentChanges under default settings.

Will be fixed by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1205720 and/or its parent.

In T409659#11372994, @Krinkle wrote:

3. Enable "Move" in https://www.wikidata.org/wiki/Special:Preferences#mw-prefsection-gadgets

That was reverted unfortunately.

Curiously, English Wikipedia's Edittools appear to still be working.

Likely to be because of https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/460422 / T161278.

Would be good to make SVG/Svg and CSS/Css consistent as well. CamelCase seems better than all caps.

Resolved through https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/460422.

Current support in Lua is for rendering SVGs in <img> tags, which does not support any interactivity like clickable links. It's only possible with T407783.

In T399801#11333273, @Bhsd wrote:

@SD0001 Could you confirm the state of this task?

Sounds like a UBN. All drafts are expected to include external links (references).

Seconding what matmarex said about using a significantly higher limit. I think a reasonable limit would be one that's based on consideration of how many a user can have before it starts creating problems on the infrastructure. Does the infra crib with just 20 or 30 userjs options? I don't think constraints should be based on current usage alone - the software should be able to handle future requirements as well. Most limits are set once and never raised. The pattern I've mostly seen is scripts/gadgets storing prefs as a JSON string in a single userjs field. It's reasonable to install more than 30 scripts. On User:Queen of Hearts/common.js, I count 125. We wouldn't want script developers to resort to hacks (such as multiple scripts somehow trying to share the same userjs field) to circumvent the limit.

https://gitlab.wikimedia.org/repos/gadgets/unblock-wizard

In T334940#11292320, @Bugreporter wrote:

T405861: Add support for generating non-interactive SVG images via Scribunto are able to replace several kinds of graphs and charts. The only problem nowadays is graphs with off-wiki data (e.g. pageview and WDQS).

Instead of adding a magic word, I think this should be done via Lua: T362937.