Last modified: 2008-04-09 10:28:56 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 13653 - <references/> with no <ref> in article body should not output an error
<references/> with no <ref> in article body should not output an error
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
Cite (Other open bugs)
unspecified
All All
: Normal normal with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/w/index.php?t...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-08 13:16 UTC by Nicolas Dumazet
Modified: 2008-04-09 10:28 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Nicolas Dumazet 2008-04-08 13:16:21 UTC
A page with only "<references/>"

Will output a big, red "Cite error: Invalid <references group="" /> tag; group name "" not defined in <ref>"

I'm marking this as a critical issue, because according to the last dumps it affects more than 10K pages on fr: (Still counting how many en: pages are affected)
Comment 1 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-04-08 13:26:29 UTC
Why is this behavior incorrect?  If there are no <ref>s, it makes sense to raise an error if <references /> is present.  For instance, on enwiki, a <references /> with no refs will almost always give you an empty ==References== section, which is wrong anyway.  The error message does what it's supposed to do, draw attention to a mistake that should be fixed.

Arguably, you're right, this mistake is a minor one that would best be handled silently.  Honestly, our error-checking is very inconsistent and it's hard to say whether we should be silent (which we usually are) or noisy (which Cite usually is).  Either way, this is not major.  A few articles will look a little odd and people will fix them as they see them.  It helps to draw attention to articles without references, too.  ;)
Comment 2 ThomasV 2008-04-08 17:48:25 UTC
it also currently affects a few thousand pages on wikisource,
because the proofreadpage extension automatically appends <references/> 
to page footer.

I blanked the error message on fr.ws and en.ws, until the issue is resolved.
Comment 3 BrownHairedGirl 2008-04-08 20:13:00 UTC
A noisy warning about empty is wrong because it's a technical warning in the absence of a technical problem.  An empty <ref></ref> tag is a problem, because it indicates an incomplete footnote, but a <references /> tag without references is not a technical problem. Making it appear to be one will simply trigger the removal of <references /> tags  from articles which are currently unreferenced, which is a very bad idea.

That might sound like a good idea, having just encountered dozens of articles which had <ref></ref> references but no <references />.  That's a real problem, and it's more likely to occur if <references /> is removed from every article which is currently unreferenced ... and it's a much more serious problem than the minor stylistic glitch of an empty ==References== section.

Unreferenced articles should be tagged with {{unreferenced}}, and one widely-used  way of doing this is to add a section ==References== <references /> {{unreferenced}} -- in other words, the <references /> tag is already in place for when refs added.  Why impede this usage?

Comment 4 Derk-Jan Hartman 2008-04-09 10:28:56 UTC
Fixed in r33003

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links