This is a followup to bug 16162
Currently, special page links are not being recorded in the database.
Imho, it would be useful to start doing that so as to:

• allow "what links here" on special pages (at least useful to maintainers)
• gain the potential to speed up lookups by moving some servertime and usertime eating handling to the process of saving a page (once) rather than leaving it in the process of serving a page (likely performed more often)

Atm, there are various names addressing any special page
(generic, aliased, localized, fallback language(s), fallback
language(s) localized). They a are resolved via http redirects.
This may cause redirect chains of up to 5 http requests causing
server load, bandwidth use, and remarkable delays to users,
rewritten URLs in Browsers, and maybe other inconveniences.

Resolving all these once, during page saving, internally,
and later using the final result, should imho be advantagous.

Various nice side effects, such as added lookups, come with it.

(We should not abandon the redirect stuff though,
because there may be old, or hand-edited URLs, and we need to
cope with possible changes of localized names before the
database has been completely updated)

There is just one snag: Links to special pages may be parameterized. They come in several kinds:

1. Special:Page/parameter
2. {{Special:Page|parameterlist}}
3. {{fullurl:Special:Page|parameterlist}}

For the time being, I'd suggest to postpone version 3 until
a working solution for the others has been found (with 3 in
mind of course), and then transform these external links into
some kind of internal ones.

I momentarily have no proposal to make as to how to handle
parameters, since I am not familiar enough with the details
involved. Only two basic approaches:

• keep parameters in the database somehow (with the benefit to use them in queries, but inconsistent with e.g. template parameters)
• do not keep parameters in the db, rather let the parser get them when needed (with added flexibility of having less static parameters, such as current user, language, time, cookies, etc.)

I lean towards the latter.

During the process of saving such links, e.g.
Special:ListAdmins
Special:UserList/sysop
→ {{Special:UserList|group=sysop}}
needs to be completely broken down into an unambiguous final
canonical representation. That has implications:

• Parameters may not be visible in the original wikicode of a page. Where to keep them, if not in the db? Shall we accept to rewrite the Wikicode of "Special:ListAdmins" at least to "Special:UserList/sysop" so as to have a string reference to "sysop" when rendering?
• So as to obtain a way of breaking down parameters, we need to rely on the parameter handling of individual special pages. Thus, they need to get an additional entry point to be called during page save for this purpose. While that is generally not a big problem per se, it requires perhaps some care to be taken regarding cases such as:
• Special:UserList/{{#case:{{localtime-am-pm}}|am=sysop|pm=bot}} This example is silly. I could not find useful ones without resorting to such complex things like building a page on a users geo-coordiantes being used in an extension like Semantic MediaWiki e.g. collecting places of interest in walking distance to him or her. I do not know wether or not this is a problem. At least, the new internal parameter handling call of special pages needs generally be aware of the fact that, it may receive unparseable stuff which can only be resolved when the page is finally being rendered. Not having gone into the implementation details, a possible caveat might be: Special:UserList/{{something}} → {{Special:UserList|group={{something}}}} → {{Special:UserList|user={{something}}}} depending on {{something}}.

So, likely, this bug is going to spawn additional ones to be dealt with before it can be completely solved.

Version: 1.15.x
Severity: enhancement