There's also the fun and games of $wgLegalTitleChars...

There's also the thought of how we shall sort the list of users, taking into account prefixes on things like Special:ListUsers (if they'll appear there in with other users)...

In T332805#8719005, @Esanders wrote:

One should also consider the ability of users with a variety of different keyboard layouts to type the character. I suspect that the hyphen is the easiest to type for most users, dollar a close second (may be replaced with other currency symbol) and tilde the hardest, but I haven't done the actual research!

For reference, MW when importing pages does currently use > as a seperator/prefix, with a text string before (user selectable), called "interwiki prefix"

If these two issues can’t be fixed for 1.40.0, I’m going to propose we revert that patch out of the REL1_40 branch

I didn’t say it was the same issue ;)

Is this on your dev wiki/similar?

In T321160#8700791, @Tgr wrote:

But the immediate issue here is not v9.0.0-alpha being outdated, it's that currently our composer.json (both vendor and the extension) pin it to a specific commit that was the state of v9.0.0-alpha circa 2021 and is way behind current v9.0.0-alpha. Using v9.0.0-alpha without commit-level pinning would be fine.

It's pinned to the exact hash in wikimedia/oauth2-server (rEOAUaf26a29b05e2: composer.json: Pin league/oauth2-server to commit) because when I tried to update it after a rebase, it failed with some errors that looking at the vendor patch, I tagged in T302757: OAuth test failures. https://github.com/thephpleague/oauth2-server/issues/1266 as the upstream which was closed without anything really being resolved, even months later...

In T330508#8650458, @Krinkle wrote:

I like the idea of using an attribute in extension.json, that avoids the boilerplate indeed.

The downside, however, is that running the PHPUnit test and/or the maintenance script for "managing" foreign resources will operate on all of core and extensions at once. Maybe we can retain a way to operate on "all" the ones from a given extension still. That's the current value of the minimal boilerplate that creates its own PHPUnit and Maintenance class.

In T330049#8646353, @Calebgcooper wrote:

Is this the expected behaviour? I would have thought it should be enough to use ForeignDBRepo only.

In T330528#8645165, @Reedy wrote:

With the PHP version bump, I guess it should be version 4 - https://github.com/wikimedia/HtmlFormatter/compare/3.0.1...master

With the PHP version bump, I guess it should be version 4 - https://github.com/wikimedia/HtmlFormatter/compare/3.0.1...master

The existing foreign-resources.yaml files in extensions (ala T330432: Update existing foreign-resources.yaml files to add extra fields) have been updated, so merging the patch for this won't cause any failures when the various "MaintainForeignResources" maintenance scripts in them...

In T330427#8642761, @Reedy wrote:

Is it reasonable to add to the extension schema a field (that takes a string or an array of strings) with links to foreign-resources.yaml files in the extension/skin?

I will also note that I don't remember if I've tried an XML import to my dev wiki since I switched it to PHP 8.2; so it's possible this may have been the case since 8.2.0, or it could be new in 8.2.3.

Seemingly the same...

Seems to be caused by rMW771219475e11: import: Add a syntax check for xml imports by @Umherirrender.

Seems to be fine on PHP 8.1.16, so PHP 8.2.3 issue...?

Is it reasonable to add to the extension schema a field (that takes a string or an array of strings) with links to foreign-resources.yaml files in the extension/skin?

v1 of this has landed. There's definitely some followup and improvements to be done, but created as parent tasks...