Qgil's MediaWiki URL in the M2 mock, https://www.mediawiki.org/w/index.php?title=User%3AQgil-WMF, works: it doesn't have a space or parentheses.

This is a lot more complex than it looks. Because the wikimedia oauth plugin needs to work with other mediawiki installs, and those can have different url schemes, we can't hard-code it to assume the conventions used on mediawiki.org, specifically, clean urls can't be assumed to be on so we can't leave out the index.php?title= part of the url or assume that /wiki will work as a path prefix. Additionally, upstream rejected the code when I had it customized specifically for our use case. As upstream acceptance has been considered extremely important, I made changes in response to D9202 (upstream).

This was done with the advice of other wikimedia developers:

In D9202#83860, @csteipp wrote:

In D9202#48, @WikiChad wrote:

In D9202#47, @20after4 wrote:

The /w/ and /wiki/ urls are the default and recommended mediawiki configuration:

https://www.mediawiki.org/wiki/Manual:Short_URL

One issue is that the plugin only works with mediawiki.org when it uses /w/ and /wiki/ in appropriate places. I'm not sure how to make that part configurable without making it sorta confusing...

@csteipp can you offer any suggestions here?

I think it's pretty easy actually. Don't use /wiki/ and assume the wiki never has short URLs (which they very well might not). We don't have to use them. Then include /w/ in the base part of the URI you configure and you're set.

We can just use whatever url the user inputs (maybe suggest they use the script path, /w/, etc), but then mobile redirects don't work.

We could add an optional parameter in the setup, which asks for the optional url to redirect the user's browser to, and suggest a /wiki/Special:OAuth url. If the user fills it out, we use that for the /authorize url. Otherwise we just use the one url they gave us?

The double url-encoding might be fixable, however, the short url is not a simple thing to implement.

I think the fixes needed sorted by priority are:

1. The URL to the user page must be functional in all cases, regardless of the characters involved.
2. The visible string should be the username correctly formatted, hiding the URL itself i.e. "S Page (WMF)"
3. This needs to be implemented in all the places where we are showing this link
   • Registration dialog (pending)
   • User profile (fixed)
   • User preferences (pending)
   • Anywhere else?
4. The "long URL" shouldn't show unnecessary url-encoding.

How much of this can we reasonably include before the Bugzilla migration?

Personally I don't think it is relevant whether these encodings exist in the background as long as the URLs work and the ugly encodings are not exposed in the UI.

Providing "short URL" format is not possible today and it would require significant changes in the extension if we want to upstream them, something that we are not going to pursue now, if ever. If you are interested in showing short URLs, then please create a new task, but as said we will not look at it anytime soon.