In T241524#8197093, @Legoktm wrote:

<Krinkle> ... The only strong use case here is performance, which I think we can address better in other ways.

They're created by[[ https://meta.wikimedia.org/w/index.php?title=User:ESanders_(WMF)/commentlinks.js | User:ESanders_(WMF)/commentlinks.js ]]

There's also the question of what content model would the on-wiki vue pages take? Can they be JavaScriptContent, or do we need a new content model? For ES6 gadgets, no syntax checking is done (because the syntax validator only supports ES5 as of now), so it would technically be possible to use the JS content model, but that is a bad idea. If we were to make a new content model, should that go into MW core, or in the Gadgets extension?

The i18n strings controlling date formats can be edited from translatewiki.net. During the migration from date.js to moment, some of these may have stopped working correctly for non-English languages. (Since PageTriage is deployed only on enwiki, this wasn't considered a big deal.)

Stop putting the offset in the "System" type (it's already ignored)

Most importantly, I think the logic in PageTriage is wrong/fragile. Instead of using the offset, it should check if the timezone is geographical, and use that to compute the correct offset.

Rough outline of changes needed to implement this: (please let me know if I'm missing something)

Document how an admin could grant read-only API access to the default service account for a tool
Document how to request that your tool's default service account be granted read-only API access

--continuous option creates a k8s deployment, for which there is a quota of 3 per tool. I see that you already have 3 deployments running, which might be the reason for 403. You can request a quota increase by filing a ticket against Toolforge (Quota-requests).

Thanks for the approval @bd808, and @Legoktm for presenting it. Bot is functional now. I have not implemented the "edit ageing" requirement, but emergency-shutoff can now be activated from User:SDZeroBot/Shutoff, which is linked from the bot user page. Also created wikitech:Tool:SDZeroBot.

@Novem_Linguae Twinkle's rewrite strategy was:

• Rewrite from scratch in an object-oriented paradigm. Classes are hard to use in ES5, so twinkle uses TypeScript instead. (PageTriage should use ES6. IE 11 compat doesn't seem particularly desirable.)
• Provide a twinkle-core library which can used by each wiki to create their own custom Twinkle edition. If the workflows used on the wiki are really really standard, almost no custom code would be needed. The more the workflows are non-standard, the more custom wiki-specific code needs to be implemented.
  • For instance, the article tagging module is provided in core as TagCore. The enwp customisation would create a class Tag extends TagCore which inherits base functionality and adds customisation by overriding relevant methods in the base class.

Waiting for T315738, T306311 and T306312 to be resolved before I migrate – the latter two would make the required code changes more minimal.

A potential route of abuse here is for a user to set their email address to one which they wish to spam, not confirm it, and then trigger a script to send >20/day emails

This is causing CI failures on several random patches:

• https://gerrit.wikimedia.org/r/c/mediawiki/core/+/825907 (https://integration.wikimedia.org/ci/job/wmf-quibble-core-vendor-mysql-php72-docker/87182/console)
• https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/826304 (https://integration.wikimedia.org/ci/job/wmf-quibble-vendor-mysql-php72-docker/109110/console)

In T306391#8146790, @MusikAnimal wrote:

It's possible it did run out of memory, but that's what the auto-restarts are supposed to fix...

In T305424#7857095, @MusikAnimal wrote:

... In either case, T174145: Our standard highlight icon (used to enable/disable CodeMirror) cdxIconHighlight looks too much like our standard edit icon, cdxIconEdit should be addressed first. Community Tech has its own designer now so we can see what he thinks.

https://en.wiktionary.org/wiki/MediaWiki:Gadget-CodeLinks.js is another wonderful gadget implementation.

T315072: Add a new edit filter trigger action: pop-up box is a possible way to implement some of the components described in this ticket, which keeps the edit checks fully customisable on wikis locally using the existing AbuseFilter language familiar to communities.

Ideally, either the gadget repo or API code in Gadgets extension should strip trailing whitespaces.

This is occurring on wikis where $wgSpecialGadgetUsageActiveUsers is enabled. Gadget is a recognized namespace on all of these wikis.

In T121049#8083303, @AlexisJazz wrote:

https://en.wikipedia.org/wiki/User:Alexis_Jazz/GUS2Wiki

Takes 2-5 regulars per project. (someone using it has to visit the wiki when the stats have been updated, a single regular who never misses a day would also suffice) Currently just overwrites the page so for history you'll have to dig through the page history.

I think A or C make the most sense. B seems problematic as the tabs not visible without scrolling horizontally will be less discoverable.

The JSMinplus validator does not even support ES6 ( T75714). Even when it does, it's unlikely it would be constantly updated to support the latest ES variant of the day.

I think validating on save and saving the result as a page property is a pretty good approach.

I disabled the check for ProcseeBot's activity.

Now that ResourceLoaderModule::getSkins() patch has merged, possible approaches to move forward with this:

@Ankur0710 Please review https://www.mediawiki.org/wiki/New_Developers#Some_general_communication_tips and https://www.gerv.net/hacking/how-to-ask-good-questions/. In short, to get further guidance you should mention what you've tried so far and where exactly you're stuck.

Have we thought about coupling parse requests with the action=stashedit requests? The latter is also "real-time" with a debounce of 3 seconds IIRC. Instead of sending the full wikitext twice, how about creating a single API endpoint that does parse + stashedit? Or maybe modify either of those APIs to add an option to also do the other operation?

@Novem_Linguae What timezone have you set in Special:Preferences?

See also: T263931: Special:ActiveUsers misses some active users on some(?) wikis, T261290: Number of active users from ApiQueryAllUsers grossly different from Special:Statistics page

Couldn't SaveUserOptionsHook be used instead, as that's abortable?

In T241524#7733969, @Ciencia_Al_Poder wrote:

This also serves the purpose of tracking which pages will be using the gadget.

Do you perhaps have wgResourceLoaderValidateJS set to false?

In T241524#7673707, @Izno wrote:

That said, I remain in the position that on-click interaction with supportsUrlLoad already fits 95% of the use cases ...

With the above patch, preferences of enabled user gadgets are public. This helps with caching of the gadget startup module (group=user which enables them to be cached, unlike group=private which adds them to the HTML on every page load) – they get exposed from load.php?modules=ext.gadgets.userstartup&user=<username>.

After doing some more research, I figured out a better approach (see linked patch, ready for review) that does not involve embedding modules on the page. This approach enables user gadgets to exist as normal modules, triggered by a user-level startup module. The issues with the earlier approaches are resolved, and only trivial resourceloader changes are needed. Contrary to bullet 5 in T36958#7594392, user gadgets can be loaded adhoc via load.php?modules=ext.usergadget.p12345 (where the number is the pageid of the definition page) though this would not be considered officially supported.

@Nux This task is essentially about T36958#387742, though I believe setting position is no longer an explicit RL feature (any module with just styles load without flicker).

@Ammarpad I forgot that sitenotices on enwiki were dismissable. In testing on my localhost wiki, they were persistent – as MW core doesn't have a dismiss capability. Which is the extension that makes them dismissable? I think the usecases are for persistent namespace notices, so maybe we could change the extension to not work on ns notices.

A hacky alternative to provide ES6 support in gadgets would be:

• Introduce a new reserved group which disables validation.
• Gadgets which mark themselves as es6-only are put in that group - so they are retrieved in a separate request than other gadgets and core/extension-loaded JS.

This means that if any one of these ES6-only gadgets contains a syntax error, all other enabled ES6-only gadgets would also fail, but core/extension-loaded modules and non-ES6 gadgets would work as usual. That seems like a reasonable compromise. Thoughts?

Thanks @Krinkle for investigating this.