That's great! The only issue (and this can potentially be a very low priority task) is that non-LDoc tags are also being highlighted:

I agree, one can't avoid sanction simply by ignoring legitimate concerns. However, I see a feature similar to blocking on SNS a way to "hide" problematic user conduct from one's own eye, rather than the community as a whole. In other words, for professional use, a user who "hides" another user in their opinion believes that engaging further is counterproductive, no matter how professional they try to be.

It is different in that it is per user rather than for the whole site. Very much like the block functionality on social media. I was thinking something along the lines of Discord. Discord user "blocks" only stop a few kinds of interactions: DMs (which is akin to email), friend requests (irrelevant since a wiki is unlikely to ever use a social network), reactions, viewing profile details (again, we are not a social network and we don't want to stop users from viewing each other's profiles even if hidden), and everywhere else the message is collapsed into "blocked message".

Same. I would recommend a beta preference flag to enable responsive vector.

I don't know. Fandom still uses DPL3 it seems.

Maybe just for wiki text pages we can have it. CSS, JS, etc. could just stick with the default PST. Like I said as well this should be something that can be switched on and off by the end user.

I like the idea. I don't know if something like this would actually work though.

I renamed the task again because this is not just for highest group membership. This is for all groups.

So I took a peek for syntaxhighlight and I don't know if Pygments supports adding doc tags or not. It would be nice if it did, but if it does not then we can at least focus on the code editor. Ideally the code editor should behave a bit like Visual Studio Code or one of the several IDEs.

I did get the ball rolling a little bit. I do think it is a good temporary solution, but I do think there will be some major blockers given I was very sleep deprived and thus working a bit more sluggishly than other days.

If it is not going to be significant dev time, then maybe it is worth it (until Codex can support environments that do not support JS) until the task mentioned is completed.

I think it should actually be valid Vue, because user script authors might want to design Vue components to use in scripts (see T401975 which I created because there isn't an easy way to load Vue components in user scripts).

Sorry for the lack of clarity.

In T411403#11420790, @Aklapper wrote:

Wikis that try to color admin usernames end up resorting to adding an expensive CSS stylesheet based on what the href of the userlink is

How can I find out simply via the href in which user groups a user is?

In T411068#11409972, @Johannnes89 wrote:

If the issue is about autoblocks affecting registered users (I don’t think I've heard about a single case in the past couple of months, per perhaps that’s different on enwiki?), the solution might be introducing "temp account autoblocks" instead of adding new block options to manually block an unknown IP address.

Btw I don’t understand why the admin can’t just enable their IP access via Special:Preferences if they want to check whether different temp accounts belong to the same person?

Looking good! Probably could use some minor tweaks regarding spacing (particularly in the bottom left corner) and I hope that the icon appears in red to draw more attention to it but otherwise I like it.

I do wonder as well if there may be better solutions than what I suggested. Maybe some sort of IP hashing so that one can know if two temporary accounts share the same IP without actually sharing the same IP.

I edited because I thought I saw a privacy risk. Specifically, an attacker could record the IP address of a temporary account, and after the username is changed, anywhere where the temporary account username was added could be attributed to the new username.

What about code pages on existing wikis? For example files are licensed differently from a wiki's content license (often more permissible). And CC licenses are strongly recommended against software (see here) and GPL works cannot be relicensed under CC. A dual licensing scheme may work fine for templates, CSS, JS, and related pages. GFDL is not really good for software but is good for software documentation.

I think I should have been clearer.

The reason I am raising this is there was a VPT discussion regarding licensing the WIP Wikipedia unblock wizard script under MIT, and such a clarification could help Wikipedia use and adapt more scripts for its own purposes.

And I do agree that EventStreams probably should be what is used if we choose to integrate into MW Core.

Maybe that documentation should be provided.

I am aware of the implementations for Wikimedia, yes. As for the Python and JS libraries I think polling might have to be done somewhere unless if someone has a backend connection to the database (please check I am not certain). Implementing in Core means we can fire events as soon as they happen rather than having to wait for some library to poll that the new event has happened.

If there was such a tool that converted JS code instantiating OOUI to JS code instantiating Codex, that would be really awesome.

I think that is what should ideally happen, unless if a legacy parameter is specified, in which case legacy behavior is activated instead. OOUI was already quite featured at the time Codex was announced, and there are still quite a lot of people especially user script developers like me who are more familiar with OOUI than with Codex. All the OOUI components should be reimplemented in Codex and should be instantiable with the current OOUI libraries. I never was a big fan of how OOUI got suddenly replaced by Codex, but that is the path WMF wants to take probably because they want to move to a React.js framework.

As for my two cents I think "deprecated" implies future removal or end of life, "maintenance mode" is quite confusing language, and "will replace" might be the best language except that it already kind of has been replaced by Codex for some use cases. It may be best to just have nothing in the bold. We can still have the banner though explaining the rest.

I think there are still many use cases for OOUI right now, but I did create a task regarding how OOUI calls should be ported to Codex (T398742) so that all existing scripts would still work, they would just use Codex components instead of OOUI components. But for now, OOUI is still quite full featured, and I do think that OOUI might continue to be used even in a React.js framework.

Ok this idea is dead for now. Until the broader community demonstrates that there indeed is a need to have these pages open for some reason, it is not going to happen.

In T403290#11135365, @A_smart_kitten wrote:

Autolinks are available in repositories with GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub Enterprise Server.

…so I guess, whether or not it's a possibility might partially depend on whether the wikimedia GitHub org subscribes to any of those plans?

I think it would be best to probably do it for the most popular repositories such as MediaWiki Core and several extensions.

In T374483#11130846, @Bawolff wrote:

There already are dozens of "sandbox" subpages here. https://en.wikipedia.org/w/index.php?title=Special%3ASearch&limit=500&offset=0&ns8=1&ns9=1&search=Sandbox+intitle%3Asandbox&advancedSearch-current=%7B%22fields%22%3A%7B%22intitle%22%3A%22sandbox%22%7D%7D&searchToken=1n5z6m27hh4vgy1npwyyfk3cq

Sure, and they are mostly in the mediawiki_talk namespace.

There already are dozens of "sandbox" subpages here. https://en.wikipedia.org/w/index.php?title=Special%3ASearch&limit=500&offset=0&ns8=1&ns9=1&search=Sandbox+intitle%3Asandbox&advancedSearch-current=%7B%22fields%22%3A%7B%22intitle%22%3A%22sandbox%22%7D%7D&searchToken=1n5z6m27hh4vgy1npwyyfk3cq

In T402097#11108765, @Bawolff wrote:

The DPL cache would work to cache results across all DPL entrypoints and would have multiple levels. For example if one wants to filter all articles in categories "Foo" and "Bar", DPL would cache the results of "Foo", cache the results of "Bar", and then filter and cache the results for "Foo" and "Bar". That way if one adds another category "Baz" to filter by, DPL could just look at the cache of "Foo" and "Bar", as well as the cache of "Baz", and combine to build the cache for "Foo" and "Bar" and "Baz".

So essentially materialize every substep of the query, cache heavily, and reuse the substeps later (as an aside i think this is the strategy qlever uses).

I do see some potential difficulties with this strategy (not saying these dont have potential solutions, just that they can be annoying to deal with)

• potential exponential explosion of substeps. There is a lot of potential queries one could do. You have to store all the substeps separately. This could potentially be a lot of data. (Probably easiest to solve via LRU eviction)
• difficultly of pushing optimization downstream. E.g. if you only need 10 results, do you fetch only 10 or do you fetch all of them so your cache of intermediate results is more useful in other queries
• stale results - wikis are always changing, how do you deal with cache invalidation? If you make the intermediate cache expire quickly then it isnt very useful. If you try to update all the caches as wiki updates (like a materialized view) this can be computationally expensive if you have a lot that need to be updated.

When you start heading down this path, you are halfway to making your own database engine which can get really complicated. (Not trying to discourage, just be aware its complex)

I like the full feature functionality of DPL3, for example the following query would fetch data from an infobox template and put it in a neatly formatted table:

Here is my WM GitLab user page I think: https://gitlab.wikimedia.org/awesomeaasim

I do see that banner but it took me finding my unactivated account to confirm that the username was even correct.

BTW I am struggling to authenticate with WM GitLab because I am getting the message "Your account is pending approval from your GitLab administrator and hence blocked. Please contact your GitLab administrator if you think this is an error." I am able to access Gerrit though.

Has the patch been abandoned? It has been over a year since a patch set has been uploaded and it is still a work in progress. I am still relatively new to contributing on Gerrit so am not entirely sure if it is possible to contribute to a patchset that is owned by someone else.

I did submit a patch to Core attempting to create a parser tag for Codex icons. But now that I see this task and hearing feedback from other contributors on Discord, I am debating whether it is better for this to be in the same extension as defined in this task, or if all the Codex tags should be defined in MediaWiki Core. If we do the latter, there is possibly (I don't know because I am still relatively new to contributing to MW) the option of unbundling later and putting into their own extension for backwards compatibility if it is decided to move on from Codex.

Okay thanks. I was not sure if I should have used the feature request or generic task on this one.

This probably should have Lowest priority but I can't find this priority in Phabricator (maybe because I don't have access to it). This is a rainy day task maybe. The whole point of qqx is specifically to identify interface messages and their parameters and at this time I have not identified any potential rendering issues with inserting a non-breaking space between a comma and a colon in qqx. The only issue I was running into was with unit tests when working on a different feature as the feature I was working on called wfMessage(...)->parse() and it was inserting problematic characters during my tests.

In T401158#11060088, @Aklapper wrote:

In case a Vue component moves the old component location should link back.

Why/when would that happen? What would that mean if a new, different Vue component was created at the old component location?

Maybe what should happen is we identify actionable items that use a layout that would not be annoying as a popup on the current page. On second thought, maybe this task would be redundant anyway to all of the work already being done on Codex. I don't know at this point.

the solution is to configure your browser differently and not to throw more disrupting popup dialogs at users to make them more annoyed

I don't think I was very clear in my task description.

How would this OOUI icon work: https://commons.wikimedia.org/wiki/File:OOjs_UI_icon_cancel-destructive.svg

@Tgr Yeah GeeTest isn't open source.

I want to reopen this task (and potentially reword it) because I found where the original "slider captcha" came from a long time ago: https://www.geetest.com/en/adaptive-captcha-demo

OK thank you, I will take a look.

I don't know. This may be or be related to a long term goal and I am not entirely sure what should be done to achieve it. I could not find any existing tasks that suggest that this is something being worked on or declined. I imagine this as ideation right now to determine what needs work and what doesn't. This is a legitimate issue right now, if not then will be a legitimate issue in the future.

Maybe the Streisand effect is a benefit of itself. I was very jetlagged when I first wrote this, but now that I have gotten some sleep, I can probably think this through even better.