ref inside Wikilinks leave UNIQ
Open, NormalPublic


See URL. See ref inside the wikilink ([[Lemma|<ref>Text</ref>]]) leaves UNIQ-Marker on the parsed side.

This looks like a bug. I think it is no good idea to put the ref as a linktext, but that should not leave in UNIQ-Marker. Thanks.

Version: unspecified
Severity: enhancement
See Also:


T28213: Strip marker issues (tracking)
bzimport set Reference to bz25417.
bzimport added a subscriber: Unknown Object (MLST).

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>

mlk added a subscriber: mlk.Mar 26 2015, 5:10 AM

Definitely a bug.

Still happens, after all those years.

This affects quite a lot of edits made with MediaWiki-extensions-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.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 23 2016, 12:43 PM

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 :(

DavidEppstein added a subscriber: DavidEppstein.EditedMar 18 2016, 11:41 PM

This is now also happening with <math> markup inside wikilinks, on, 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.

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

Add Comment