- User Since
- Nov 9 2018, 4:09 PM (227 w, 2 d)
- LDAP User
- MediaWiki User
- SD0001 [ Global Accounts ]
Sun, Mar 12
Sun, Mar 5
Sun, Feb 26
They're created by[[ https://meta.wikimedia.org/w/index.php?title=User:ESanders_(WMF)/commentlinks.js | User:ESanders_(WMF)/commentlinks.js ]]
Sat, Feb 25
Fri, Feb 24
Dec 3 2022
Nov 23 2022
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.)
Nov 19 2022
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.
Nov 16 2022
Nov 15 2022
Rough outline of changes needed to implement this: (please let me know if I'm missing something)
Nov 3 2022
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
Nov 1 2022
Oct 31 2022
--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).
Oct 30 2022
Oct 29 2022
Oct 27 2022
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.
Oct 25 2022
@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.
Oct 12 2022
Oct 11 2022
Oct 9 2022
Waiting for T315738, T306311 and T306312 to be resolved before I migrate – the latter two would make the required code changes more minimal.
Oct 8 2022
Sep 17 2022
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
Aug 27 2022
Aug 26 2022
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)
Aug 25 2022
Aug 22 2022
Aug 20 2022
Aug 15 2022
https://en.wiktionary.org/wiki/MediaWiki:Gadget-CodeLinks.js is another wonderful gadget implementation.
Aug 13 2022
Aug 12 2022
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.
Aug 10 2022
Aug 8 2022
Aug 7 2022
Jul 21 2022
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.
Jul 18 2022
Jun 13 2022
Jun 7 2022
I think A or C make the most sense. B seems problematic as the tabs not visible without scrolling horizontally will be less discoverable.
Apr 22 2022
Apr 18 2022
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.
Apr 7 2022
I disabled the check for ProcseeBot's activity.
Apr 3 2022
Now that ResourceLoaderModule::getSkins() patch has merged, possible approaches to move forward with this:
Mar 19 2022
@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.
Mar 13 2022
Mar 12 2022
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?
Mar 6 2022
@Novem_Linguae What timezone have you set in Special:Preferences?
Feb 27 2022
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?
Feb 26 2022
Feb 18 2022
Feb 14 2022
Feb 12 2022
Do you perhaps have wgResourceLoaderValidateJS set to false?
Feb 4 2022
Jan 31 2022
Jan 26 2022
Jan 25 2022
Jan 23 2022
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.
Jan 20 2022
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?
Jan 19 2022
Thanks @Krinkle for investigating this.