Tasks that need input and discussion in the style of a technical proposal (request for comments).
For technical proposals reviewed by TechCom, use TechCom-RFC instead.
Tasks that need input and discussion in the style of a technical proposal (request for comments).
For technical proposals reviewed by TechCom, use TechCom-RFC instead.
@SD0001: Removing task assignee as this open task has been assigned for more than two years - see the email sent to all task assignees on 2024-04-15.
Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome! :)
If this task has been resolved in the meantime, or should not be worked on by anybody ("declined"), please update its task status via "Add Action… 🡒 Change Status".
Also see https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator. Thanks!
@hoo Have you find time yet to process the new run completely? For others: I've asked during the Hackathon for another run as the data is more than two years old at this point and there is no sign of progress on the other task.
Change #1029626 merged by jenkins-bot:
[mediawiki/extensions/CheckUser@master] Change use of AtEase to at operator
Change #1029626 had a related patch set uploaded (by Dreamy Jazz; author: 沈澄心):
[mediawiki/extensions/CheckUser@master] Change use of AtEase to at operator
The proposed patch on Gerrit addresses precisely these problem - it introduces feature parity between gadgets and user scripts ("user gadgets"). All ResourceLoader features available to gadgets like loading dependencies, allowing multiple source pages, specifying peers for FOUC-free CSS loading, CommonJS module support, and conditional loading (based on namespaces, content models, skins, etc), would become available to 'user gadgets'.
The big problem I have with user scripts is loading dependencies and the incompatibility between gadgets and user scripts more generally.
Mathoid stopped serving PNG images for quite a while, and there were no complains, even though the SVG images from mathoid are quite special. Thus, we have one more data point that the browsers svg support is quite good.
In a recent discussion in WikiProject Mathematics yet another rendering bug was encountered. Several users expressed the sentiment that SVG support in MediaWiki will never get fixed, and it is better to give up on them altogether and revert to PNGs. This is specially frustrating because the browsers can render the SVG correctly, but MediaWiki insists on passing it through librsvg and serving the resulting garbage instead.
I want to note that not only this would be a helpful feature; the current user script architecture is, in fact, broken. It has been tacitly assumed since old times that user scripts are all enduser scripts and not modules to be reused by other scripts. But there is benefit to them being reused, and some indeed are, like libraries or utilities like this one I just wrote. They can be made into gadgets, but that would clutter the definitions, affect the overhead for regular users, and require a tedious wiki-bureaucratic process.
I'm tentatively removing MediaWiki-extensions-WikibaseClient here, because this is not actually about changing functionality on the client, but rather bringing something that works on the client also to the repository. Or did I get something wrong?
MediaWiki Core now has support for conditional user defaults, which was the scope of this task => resolving the task. Rest of the work (such as actually using the new capability in Echo) is tracked under T354459 and subtasks.
Change 978537 merged by jenkins-bot:
[mediawiki/core@master] Add support for conditional user defaults
In T321527#9425854, @Tgr wrote:I think it would be nice to document in a comment here the envisioned syntax for the configuration setting, in part so people can give feedback without having to read the patch, and in part because the patch only implements the one condition we have an immediate need for (registration date), but have use cases for other options (e.g. autocreated account vs. account on home wiki), and it's not entirely obvious how the syntax would generalize. Would it be what @phuedx suggested in T321527#9215021 (except without the "old default" value)?
I think it would be nice to document in a comment here the envisioned syntax for the configuration setting, in part so people can give feedback without having to read the patch, and in part because the patch only implements the one condition we have an immediate need for (registration date), but have use cases for other options (e.g. autocreated account vs. account on home wiki), and it's not entirely obvious how the syntax would generalize. Would it be what @phuedx suggested in T321527#9215021 (except without the "old default" value)?
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/978537/ is now ready for code review.
Change 978486 merged by jenkins-bot:
[mediawiki/core@master] Move user options related classes into its own namespace
Change 978537 had a related patch set uploaded (by Urbanecm; author: Urbanecm):
[mediawiki/core@master] WIP: Add support for conditional user defaults
I started working on this today by reorganizing classes responsible for user options a bit (they were in MediaWiki\User, I moved them to MediaWiki\User\Options instead). I'm now working on a class to load conditional user defaults from configuration. After that, we'll also need to do this:
Change 978486 had a related patch set uploaded (by Urbanecm; author: Urbanecm):
[mediawiki/core@master] Move user options related classes into its own namespace