Page MenuHomePhabricator

Incompatibility between <gallery>...</gallery> and Cite-Tags
Closed, ResolvedPublic

Description

Author: gnu1742

Description:
Let a page have several <ref>- and one <references/>-Tag. If you put a
<gallery>...</gallery>-Compound between the very last <ref> and the
<references/>, the declared references are not listed at the desired position.
If you put the Gallery in front of the last <ref> or after the <references/>,
the references are listed at the correct position. I made some experiments on
http://de.wikipedia.org/wiki/Benutzer:Gnu1742/test (my Userpage at
de.wikipedia.org). See the versions since
http://de.wikipedia.org/w/index.php?title=Benutzer:Gnu1742/test&oldid=17359531


Version: unspecified
Severity: major
URL: http://de.wikipedia.org/w/index.php?title=Benutzer%3AGnu1742%2Ftest&diff=17359721&oldid=17359646

Details

Reference
bz6164

Event Timeline

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

gnu1742 wrote:

To avoid possible misunderstandings: "...the declared references are not listed
at the desired position" should be "...the declared references ar not listed at all"

wallykramer wrote:

Seems to be broken now, first noticed Sunday 2006-10-08. Demonstrated at
[[en:Timberline Lodge ski area]] (references not visible) versus [[en:Magic
Mile]] (references visible). Mentioned in Technical village pump at
http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#Gallery_tag_messes_up_references

I think this is more than normal severity & priority, because some editors are
removing galleries to address the situation.

I can't reproduce the problem locally or even on test.wikipedia.org.
This is rather difficult to debug...

Parser state is being cleared by a message transformation for the bad image list.
The addition of a template invocation on [[MediaWiki:Bad image list]] a few days
ago triggered the new behavior.

Worked around in r16954.

Use ?action=purge or edit any affected pages.

Sounds like "a good permanent fix" in this case to me -- I didn't even realize
wfMsgForContent() was invoking the parser at all or I would've fixed it myself
earlier. All that the code wants, after all, is the raw wikitext.

It's not a good permanent fix since there might be a thousand other places
(open-ended) that might, quite legitimately, want to slurp in localized
message text during parsing.