Page MenuHomePhabricator

ref inside Wikilinks leave UNIQ (when MediaWiki:Cite_reference_link is overridden)
Open, MediumPublicBUG REPORT


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:



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:11 PM
bzimport added a project: Cite.
bzimport set Reference to bz25417.
bzimport added a subscriber: Unknown Object (MLST).

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

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, 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.

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 12:24 PM
Aklapper removed subscribers: GWicke, wikibugs-l-list.
thiemowmde closed this task as Invalid.EditedDec 11 2023, 2:28 PM
thiemowmde changed the subtype of this task from "Feature Request" to "Bug Report".
thiemowmde subscribed.

Appears to be fixed.

I can still reproduce here: (a test case for a related bug), although I can't reproduce locally.

Nice, thanks! Turns out this is because of some <nowiki> in the customized message 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>
matmarex renamed this task from ref inside Wikilinks leave UNIQ to ref inside Wikilinks leave UNIQ (when MediaWiki:Cite_reference_link is overridden).Dec 11 2023, 4:02 PM

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