Summarizing and elaborating upon discussion with @bvibber and Tbodt (Tepo) at https://wikis.world/@tamzin/114753248831947961: Brooke says that "it might be tricky to get the redirecting page as a variable into the article without extra parser cache fragmentation" and suggests that it would be easier to set up something where the message is on the redirect, e.g.

= Foo =
#REDIRECT [[Foobar]]
{{PREAMBLE:code to display at top of target page, e.g. {{DISPLAYTITLE:Foo}} or {{redirect|Foo|other uses|Foo (disambiguation)}}}}

I agree that this is a good approach, since there isn't much practical difference between "Enabled across whole wiki but only used on target pages when a redirect is followed" and "Only used on redirects where it's needed, and displayed on target pages when they're followed". Enwiki could enable it by default for redirect tags like {{r mentioned in hatnote}}. Tokwiki could distinguish between redirects for valid alternate names (which should become the displayed title) and from things like misspellings, historical names, or related concepts (which shouldn't).

The three of us then also discussed the problem that if a user goes to [[X]] and is redirected to [[Y]] (and is using JavaScript), the link in their browser history will be to [[Y]], not to [[X]], which means that someone who consults a page many time will see the pseudo-canonical title all but the first time. Either a config variable could be added to disable this behavior independent of what's being discussed here, or they could be, per Brooke, tied together, so that the URL doesn't get updated if a reader follows a redirect with this magic word on it. In either case, this would just be a reversion (either on a per-wiki basis or per-page) to what things were like before T37045.

Please let me know if I've misstated any of that, Brooke and Tbodt.

As an alternative you can just transclude the target page instead of redirecting. However this obviously will result in both page be counted as content pages.

Extension:MultiTitle is not perfect; Especially if you want multiple names be displayed neutrally in categories.

We considered this, but the problem is that the edit buttons would go to the wrong place. We could do editnotices and page protection to steer people in the right direction, but putting any additional hurdles between "edit" and "publish" vastly decreases people's interest in editing.

A simple workaround is using a gadget to display an edit button to canonical page.

A much simpler one is create a template that display a canonical edit button, and place this template to any non-canonical pages.

As I think @bvibber probably has already noted, implementing this literally as the bug description states would be A Bad Idea, since it would mean the each redirected title would have to be cached as an entirely separate object, since the content of each page could depend on arbitrary ways on the "original title". That's a nonstarter, and I suspect the task description should be changed to describe /what/ is wanted, ie "text at the top that depends on the original redirect title" not the /how/ (a specific magic word).

We do have robust support for a post-cache processing pipeline now, so having a post-cache hook would be a much more sustainable mechanism. For example, a parser function could add a table of (redirect title => message) to the extension data, and then a post processing hook would insert the correct message based on the (normalized?) title that was actually requested.

For the record, I'm on a personal quest (T204370) to eventually replace all the "magic words" in wikitext with a uniform alternative {{#....}} syntax. This would make it easier to add additional arguments, as was noted. So:

{{#redirect|NewTitle|special message}}

is a somewhat reasonable straw-proposal. That would put 'old title' => 'special message' in a db table (maybe a new column of the existing redirects table), and then the existing code which puts the redirect header at the top (OutputTransform/Stages/AddRedirectHeader.php and the post-cache part of WikitextContentHandler::fillParserOutput which calls setRedirectHeader) could swap in a custom redirect header where appropriate. Since this modification was done post-cache it wouldn't require splitting the parser cache.

I'd strongly suggest that 'special message' be parsed *before* storage in the DB, and RefreshLinksJob will then operate in its normal way to ensure that it is kept up-to-date when the redirect page changes. That might seem obvious, but there are tricks you could play if the 'special message' was stored as wikitext, and then parsed on-demand when you followed the redirect and then potentially had access to various magic words that could further customize the message. Although clever, those games strike me as somewhat dangerous (and costly in performance, since it requires deferring the parse of 'special message' to the post-cache render) and we should probably nip that in the bud.

EDIT: There are two different "redirect header" paths. One is *when displaying the redirect page itself*, and is what I inadvertently cited above. The other is for the "redirectedfrom" message. That's handled entirely in Article.php as far as I can tell, and there's already an "onArticleViewRedirect" hook that could be used to customize it. In theory an extension could trial this by hooking ArticleViewRedirect. It's worth thinking through whether/how the stock redirect message is overridden.

Also worth noting that the DOM structure is different for a hat note and for mw-redirected from. For example, on https://en.wikipedia.org/w/index.php?title=H%E2%82%82O the DOM looks like:

<main id="content" class="mw-body">
...
 <div id="contentSub">
  <div id="mw-content-subtitle">
   <span class="mw-redirectedfrom">(Redirected from <a href="/w/index.php?title=H%E2%82%82O&amp;redirect=no" class="mw-redirect" title="H₂O">H₂O</a>)</span>
  </div>
 </div>
 <div id="mw-content-text" class="mw-body-content">
  <div class="mw-content-ltr mw-parser-output" lang="en" dir="ltr"...>
   <section>
     ...
     <div role="note" class="hatnote ...">
       <span>For other uses, see...

So moving a hatnote into the subtitle means leaving the mw-body-content and mw-parser-output styling, as well as changing lang domains -- the mw-content is in the *wiki language* while the stuff above it (including the "redirected from" message) is in the *user interface language*, which you can confirm with https://en.wikipedia.org/w/index.php?title=H%E2%82%82O&uselang=es

tl;dr there are styling and language issues to consider when proposing to move hatnote content out of the article body.

I've also looked at the code for Extension:KeepTitle which actually seems like a relatively small and efficient way to do what you want, using existing Hooks in completely appropriate ways. The main code file is only 46 lines long! I'm inclined to think it would be easier to have WMF adopt that extension than to have WMF resource a new #redirect functionality, but ¯\_(ツ)_/¯

@cscott Speaking just for the tokwiki half of this, rather than the general case that applies to hatnotes and similar, a WMF team's assistance in getting this enabled in prod would be more than welcome—even just an agreement in principle, conditional on tokwiki getting final LangCom approval. But I'll confess I don't really know much about the process of getting that stewardship. One dev did suggest I talk to the Language team, so, @Aaharoni-WMF, if you'll pardon the ping, could I ask if y'all would be interested in those 46 lines of code?

I think the display of

X redirects here; you may have been looking for Y/X (disambiguation)

only when coming via X is a good idea for wikis in general, including Wikipedia, as it reduces the clutter at the top of a page, where the reader expects to start to get information, so they don't get irrelevant disambiguation warnings.

Discussed this task at the Content-Transform-Team tech forum today. A few notes:

• @ihurbain was wondering how you planned to handle self links to redirects.
• @ssastry noted that, if you wanted this to be a uniform feature of articles on toki wikipedia, you don't need the explicit __keeptitle__ page property, you could just make this a configuration variable. That would shrink the already-small Extension:MultiTitle by quite a bit, since a lot of what's going on at the moment is just boilerplate related to the __keeptitle__ magic word.

While, as @Bugreporter2 states, in the abstract greater customization of hatnotes would be Nice To Have for wikis in general, looking just at https://en.wikipedia.org/wiki/H2O as an example, there are five different "H2O" related redirects and you'd want to match them all and add the "H2O" redirects here. For other uses, see H2O (disambiguation)." text for each. It seems like on a large page managing the appropriate disambiguation text for each would be quite cumbersome, and potentially error-prone. It's an interesting idea, but I think would best be considered as a separate feature request. Probably putting the additional disambiguation text in a {{#redirect|....}} parser function would still be reasonable, but there's also styling questions to deal with and other issues. If it is not strictly relevant for tokipona, I think the better approach is to simplify Extension:MultiTitle and get it adopted by WMF. As a fallback, adding a $wgXXXXX configuration variable to do what Extension:MultiTitle does (ie, suppress the javascript url rewriting, use an alternate page title) is probably an easier patch to review and merge than adding a broader new redirect functionality.

if you wanted this to be a uniform feature of articles on toki wikipedia, you don't need the explicit keeptitle page property, you could just make this a configuration variable. That would shrink the already-small Extension:MultiTitle by quite a bit, since a lot of what's going on at the moment is just boilerplate related to the keeptitle magic word.

We don't :) some names are worth redirecting away from, others worth declaring equally valid. So we do want to determine per-page.

@ihurbain was wondering how you planned to handle self links to redirects.

I noticed this (that it's quite hard to get to the actual redirect page to edit it) and I don't have a solution yet.

Yes, for instance, a redirect from a misspelling shouldn't have its title kept, nor from a related topic, and probably also not a redirect from a historical name (especially if now disfavored). What this is meant to be used on is redirects where the name refers to the same thing as the target's name, and would be acceptable to use in normal speech in Toki Pona—that is to say, it could just as well be the title of the target page, but for the fact that it isn't.

(This discussion seems to have started as a request to integrate this feature info MediaWiki core, but seems to have partially morphed into a discussion to request WMF stewardship of ext:MultiTitle. Should that discussion be split out into a different task / should this task be reframed to be about requesting a steward for MultiTitle? /genq)

In T397999#10959526, @cscott wrote:

to simplify Extension:MultiTitle and get it adopted by WMF

If there was a request to deploy MultiTitle on Wikimedia servers, then https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment should be followed (which will require moving off Github, having WMF stewardship, etc etc) instead.

In T397999#11084668, @Aklapper wrote:

In T397999#10959526, @cscott wrote:

to simplify Extension:MultiTitle and get it adopted by WMF

If there was a request to deploy MultiTitle on Wikimedia servers, then https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment should be followed (which will require moving off Github, having WMF stewardship, etc etc) instead.

Most of the tasks there haven't happened yet because the "WMF stewardship" says "Do this step before any other steps." :P

I believe MutliTitle is a bad solution. e.g. something can be known as A or B, but only one can be listed in categories. Also, MediaWiki does not support one category having multiple names.

The fact that pages have a single canonical title is a fundamental limitation of MediaWiki, and not one that any extension, script, or combination of hacks will fix. But the MultiTitle approach solves most of the issues that this causes for Toki Pona, those related to not giving artificial weight to one of multiple valid page titles. So I'll second A_smart_kitten's request of whether this should be split off to a request for that, without prejudice against this task arriving at some more holistic solution eventually. As Tbodt alludes to, the documentation for getting WMF stewardship is rather vague for those of us who've never been through this process before.

My suggestion would be split off a task for Extension:Multititle, yes. It is sufficiently small that I think reviewing and deploying it should not be /too/ painful, and IMO that's probably the easiest path to resolution here. We can maintain this task for brainstorming approaches /other/ than the one in Extension:Multititle which might be appropriate for wikis in general. I don't fully understand what's being requested in T55854: Allow extensions to modify label of a page link (in Parser, or LinkRenderer), for instance, but it may be that some common functionality could be found.