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.

I kind of agree as well especially for most readers. I was kind of startled when RedWarn added a right-click menu to Wikipedia pages and promptly turned it off. But now I kind of see the value when Wikipedia behaves more like a progressive web app than like a website.

Declined per @Bawolff.

Maybe. I don't know.

The particular issue I was running into was connecting to Xdebug inside the container from WSL. That is what motivated me to submit this change in the first place.

In T387410#10591501, @Pppery wrote:

Again, what's the use case for this? Why would you not want links?

Let me clarify:

Wait what? I did not know that was there! Thanks.