see also 18295

(In reply to comment #1)

see also 18295

bug 18295

BTW html generated from [[A|B<ref>C</ref>D]] wikitext snippet is invalid:

<a href="/wiki/A" title="A">B<sup id="cite_ref-1" class="reference"><a href="#cite_note-1">UNIQ9df68fa7c22a8f29-nowiki-00000004-QINU1UNIQ9df68fa7c22a8f29-nowiki-00000005-QINU</a></sup>D</a>

Compare [[A|B<charinsert>C</charinsert>D]]:

<a href="/wiki/A" title="A">B</a><a onclick="insertTags(&#39;C&#39;,&#39;&#39;,&#39;&#39;);return false" href="#">C</a><a href="/wiki/A" title="A">D</a>

Definitely a bug.

Still happens, after all those years.

This affects quite a lot of edits made with ContentTranslation and with VisualEditor, because the editors (justifiably) assume that the software will be smart enough to put the actual footnote reference after the link, but contenteditable is not actually smart enough, and this causes QINU's in the rendered page, and creates pretty ugly markup, too.

It would at least be nice if VE (and ContentTranslation) would automatically move the refs after the link, and fixing the underlying would be great as well. Normalizing the markup on the way to saving seems perfectly reasonable to me.

In T27417#1958957, @Amire80 wrote:

It would at least be nice if VE (and ContentTranslation) would automatically move the refs after the link, and fixing the underlying would be great as well.

VisualEditor already does this, since T58250 / rEVEDf9d712946519994a1b9e5e0cb3041568686a6106.

Hmm, then how did this happen?

In the Hebrew Wikipedia "הערה" is a template that inserts a <ref> tag. In this edit the word "ניוזוויק" (Newsweek) was made into a link, and the template, which had appeared after it, crawled into the link. You can also notice that the word "ניוזוויק" now appears twice in the wiki text, even though it would be enough to show it once.

Because it's a template, and VisualEditor doesn't "know" what's inside it. You can abuse this to do stupider things (like a link inside a template inside a link), which is of course also going to be messed up when turned into wikitext.

Meh. And a lot of references are actually templates :(

This is now also happening with <math> markup inside wikilinks, on en.wiki, in some math rendering modes. Specifically, there is no problem with the default bitmap rendering mode for math, but MathML/SVG-fallback mode causes the math to turn into UNIQ...QINU strings when they are inside wikilinks. I'm not sure whether this was broken long-term or whether recent changes to math have exposed math processing to this bug.

For math the problem is that the math tags have not been processed when the "onParserBeforeTidy" hook is called.

This also affects nowiki tags: see this thread on the Wikipedia village pump.

I'm pretty sure it doesn't. The following works as expected: [[foo|<nowiki>bar</nowiki>]]. I think that's a different bug.

Nice, thanks! Turns out this is because of some <nowiki> in the customized message https://en.wikipedia.beta.wmflabs.org/wiki/MediaWiki:Cite_reference_link somehow messing up one of the Parser and/or StripState steps.

For reference, this is the problematic version:

<sup id="$1" class="reference">[[#$2|<span><nowiki>[</nowiki></span>$3<span><nowiki>]</nowiki></span>]]</sup>

The default message doesn't cause this issue:

<sup id="$1" class="reference">[[#$2|&#91;$3&#93;]]</sup>

It's overridden that way in a couple of projects: https://global-search.toolforge.org/?q=nowiki&namespaces=8&title=Cite+reference+link

These also may or may not cause similar problems: https://global-search.toolforge.org/?q=nowiki&namespaces=8&title=Cite+.*

Change 982127 had a related patch set uploaded (by Thiemo Kreuz (WMDE); author: Thiemo Kreuz (WMDE)):

[mediawiki/extensions/Cite@master] Fix regular expressions not being case-insensitive

https://gerrit.wikimedia.org/r/982127