Oops, sorry about that. I thought that this kind of problem would be caught by automated checks, so I didn't think to check for it myself. (We definitely have checks in other repositories, but maybe the structure of the config files makes it more difficult…)

Actually, that may have been the intended use of lightbulbOutline.svg in T399175 all along, but perhaps it was missed during the implementation? The table on that task uses it for "Info (ar)":

Recently in T399175, a new 'lightbulbOutline' icon was added alongside existing 'lightbulb' (which is used instead of 'info' in Arabic). That icon is much closer in visual weight, and I think it will look a lot better in this context.

Interesting, I can now only reproduce it if I make some change that affects the link (changing its target, label, or un-linking it), but edits elsewhere on the page or even within the same paragraph do not cause the ref to disappear.

They're system users, which is not really the same thing as bots (it's not even a user group). We don't display that status on Special:ListUsers, maybe we should.

@diegodlh Yes. Yes, you can update the patch. It will reset the +1 vote, but that shouldn't be a problem, we're not so bureaucratic about it (and I'll give it a +1 again ASAP anyway).

$cfg['strict_param_checking'] = true; in Phan catches this bug, but it also reports 225 other issues, most of which are false positives.

src\Frontend\SpecialPages\SpecialMWOAuth.php:367 PhanPossiblyNullTypeArgument Argument 1 ($consumerKey) is $request->getVal('oauth_consumer_key', null) of type null|string but \MediaWiki\Extension\OAuth\Repository\ConsumerRepositoryInterface::getByKey() takes string (null is incompatible) defined at src\Repository\ConsumerRepositoryInterface.php:41

The warning is intended here, but maybe it could be phrased better, or marked as a notice rather than a warning.

Sorry I haven't been able to get back to you earlier. Your change looks good to me!

https://translatewiki.net/w/i.php?title=Special%3AContributions&target=Matma_Rex&namespace=all&tagfilter=&start=2026-07-31&end=2026-07-31&limit=50

I documented which messages are used where in a template on translatewiki.net:

• https://translatewiki.net/wiki/Template:CentralAuth_hidden_status
• https://translatewiki.net/wiki/Template:CentralAuth_locked_status

They are old messages, they were deleted in 529cff381f5f9efbac48a94f1cbcc9c2cbf9dd58, which replaced their use on Special:MultiLock, but we didn't realize they are also used on Special:CentralAuth. I'll fix it and document them better.

I don't understand why the libup-config change hasn't resulted in any automatic dependency updates, as far as I can see. Does someone need to kick it off manually?

I don't really see that as a long-term solution. In the longer term maybe someone should replace EventBusMonologHandler entirely with some hooks or domain events. But, while it exists, it needs to not send incorrect events, right? I suppose you could also silence the validation errors somehow, if there is a reason not to fix them.

I would suggest storing only the expected fields into mediawiki.api-request, instead of the entire log event. The log fields are not a stable API and can change. If you can, use a hook or a domain event, since those are documented and stable.

I'm strongly against backporting the league/oauth2-server updates, even if someone wanted to spend time on it, because it was complex enough that there's a high risk of making mistakes (and it would have to touch the MediaWiki release too, not just OAuth).

There are some other scenarios where DiscussionTools and NWE don't play well together. I found a couple of old tasks, which may be worth re-testing: T328041, T347146, T373246.

MediaWiki has a helper function with a similar purpose, Language::embedBidi(), but a) it uses the older "embedding" control characters rather than the "isolate" ones b) it is marked as deprecated in favor of using HTML markup. We generally prefer using HTML attributes rather than Unicode directional formatting characters, I believe it's mostly because they behave better when copy-pasting – it's easy to copy-paste text with just one control char out of a pair like LRI+PDI without realizing it, and unknowingly mess up the text direction somewhere else on the page. The copy-pasting concern doesn't really apply to a title attribute, since those are difficult to copy-paste anyway.

The real failures were also being caused by the PHP deprecation warnings (which were being promoted to exceptions by PHPUnit, and those were in turn being caught and turned into other exceptions by OAuth and REST code).

In T425691#12018591, @Tgr wrote:

In any case, how does this get triggered? I looked at release branch commits, but patches like this one seemed to pass the tests.

(Just for the record, the issue was introduced in 9aac1bba3655bf952063727c6e7fa69083814d50, so it wasn't in any tagged release. Thanks for the report.)

Fixed in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1256284 + https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DiscussionTools/+/1257710 (T347123).

The pipe is already being placed before the line break. That screenshot must have been taken before the patch from this task was deployed.

Hmm, is this done? There are some leftover references to this task (https://codesearch.wmcloud.org/core/?q=T384399), but I think we've updated all of the constraints now.

Per previous comments here and on the patch.

T401028 would happen around the same time.

This has been fixed in 963ef5d645e6acfdb9616a1efc7f3053086fd0ed (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/880465). Required options are now indicated on the Usage: line.

This has been fixed in 963ef5d645e6acfdb9616a1efc7f3053086fd0ed (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/880465). Parameters that take a value now indicate this in the list.

@Aristorkle The changes will be deployed next week, per the usual schedule. If you notice any problems in the translations, feel free to let us know here.

How do you think it should look?

I'm kind of sad how there's so much time spent over such a tiny thing (which I worked on a few years ago). I think it's up to English Wikipedia community to decide if they want to override it for themselves. Personally I think the space is neat and makes the titles more readable.

Support for other languages would IMO have to be considered first though. Not just French, where the proper punctuation is a space before and after the colon, but also East Asian languages where fullwidth colon may be appropriate (or it may not be; at least Japanese Wikipedia seems to use ASCII colons in articles, and I don't know if that's the preferred typography or if it's because of technical limitations), and other languages where the proper punctuation is a completely different character, as discussed in T315893#12125983. I'm sure this could be supported in the title parser, but it makes the change more complex.

I, for one, think that it would be neat (and I agree it's not a duplicate). I think proper punctuation would help people recognize pages in other namespaces as distinct from articles in main namespace, which in my experience is a common difficulty for newcomers. I'm surprised to see so much opposition to this idea.