Last modified: 2014-11-01 07:27:27 UTC
There are quite often pages that use <ref> tags but often <references/> are quite often omitted. their should be a method to automatically track these. the best method would probably be a category.
Created attachment 5640 [details] A patch against r45293 to implement an error message when references are not displayed The normal thing to do seems to be to generate an error message for the error, and then override the default error message on enwiki to include {{broken ref}}. So I've made a patch to do just that. This patch implements two new error messages, cite_error_refs_without_references (for missing <references/>) and cite_error_group_refs_without_references (for missing <references group="..."/>). In the ParserBeforeTidy hook, Cite.php now appends the appropriate error messages for each missing references tag. I've also taken the opportunity to fix the "Erroneous refs" parser test that was failing.
Is their any method to track those errors? with a category or special page? or will it be a mediawiki namespace notice?
Track them by adding a category to the appropriate MediaWiki namespace notices, just as is done with the other errors (e.g. [[MediaWiki:Cite error references no text]]) on enwiki.
Patch applied in r45379.
There's a problem with this patch: When editing only a section of an article, the error message is printed in preview mode, although it shouldn't. See [http://test.wikipedia.org/wiki/A_page_with_references_and_sections This test page I created]. Start editing "Section 2" and then click preview. The reference error is generated although the article as a whole *has* a references section. The user should not add a second one.
Created attachment 5649 [details] Additional patch to add a check for preview Will it work well enough to just detect when we're doing a preview and not output the error in that case? This patch (apply on top of the first) takes a shot at that.
Wouldn't it make sense to check 'wpPreview' && 'wpSection', rather than 'action' being edit or submit. The latter seems too generalized.
Created attachment 5665 [details] Additional patch to add a check for preview, using wpPreview Ok. I tried asking how to detect preview mode on IRC before making the previous patch, but no one was interested in answering.
I don't really like this on general principle (checking GET/POST vars from within a parse operation). What I think I'd prefer is for the parser to provide some state data for section-ness and preview-ness, just like it carries title and version state. This would allow for extensions to handle previews and section-only display specially without tight coupling to the web UI. Possibly this best belongs in the ParserOptions state?
Created attachment 5672 [details] Patch to add IsPreview and IsSectionPreview to ParserOptions Sounds good to me.
Created attachment 5673 [details] Additional patch to add a check for preview, using ParserOptions
Applied in r46270 and r46271.
Please see bug 12930 ("Special page for errors during parsing").
Well these already been someone on the Village pump asking if we could output the footnotes instead of the error message and the message has already shown up in Google. I might suggest we take a quieter to fixing pages without <reference/> tags. Don't produce an error message, do output the footnotes, but also place the page in a category for fixing. This way readers wouldn't never find that a footnote was missing in action. And if editors wanted their footnotes under a different heading or somewhere else then at the bottom of a page, they could still do that. Moreover adding footnotes to pages without <references/> tags would also be nice way of fixing [[5984]], although I realise there a javascript way of doing this.
That should have been [[bugzilla:5984]]
Created attachment 5745 [details] Print the footnotes and report the error silently English Wikipedia have already blanked the error printed by this bug so you'd have to wonder if it was worth the effort in the first place. Here's a patch that will place footnotes at the bottom of pages which don't have <reference/> tags while silently reporting the error.
I disagree, since we already output a big red error message for all ''other'' ref tag errors. But if you want to include the references on the page, change [[MediaWiki:Cite error refs without references]] to something like this: <code><references /></code> not supplied. References are:</strong><references /><strong>[[Category:B0rken refs]] And change [[MediaWiki:Cite error group refs without references]] to the corresponding: <code><references group="$1"/></code> was not supplied. References are:</strong><references group="$1"/><strong>[[Category:B0rken refs]] (the unbalanced "<strong>" tags in there are to make the reference list itself not be big and red). It wouldn't really solve bug 5984 though, as a section preview with a named ref defined in a different section would show up as broken.
What en.wiki did was exactly what I was asking for, a hidden category that is used for tracking these error. huge red error messages are not as graceful as a hidden category.
I think the most intuitive way of applying the Cite extension would but to display the output of <ref>...</ref> tags without automatically requiring the input of <reference/> tags. New users will see and copy the <ref> tag format but then find out that their footnotes aren't being displayed.
(In reply to comment #18) > What en.wiki did was exactly what I was asking for, a hidden category that is > used for tracking these error. huge red error messages are not as graceful as a > hidden category. > Actually enwiki's approach is still badly borked. Because "Cite error: $1" is used in a filter in front of each error message, changing this specific message to a category results in an output of "Cite error:" with no visible error text, e.g. see [[1949_Grand_Prix_season]] for a current example. That can be fixed locally, but the solutions are generally inelegant, such as changing cite_error to "$1". Also, since people apparently don't want this message on talk pages (even as a category), a hack has been added with the effect of killing ALL cite error messages appearing outside the mainspace. Again, a solution to that could be put together locally but it won't be particularly pretty. Not to mention that the hard coding of the formatting on cite_error also makes changes to the presentation difficult to implement.
(In reply to comment #16) > English Wikipedia have already blanked the error printed by this bug so you'd > have to wonder if it was worth the effort in the first place. > I thought it was a rather informative error. Suggestions welcome on exact wording though. To be honest: it doesn't really matter what enwiki does with the message. Do other communities like it? If the general agreement is in favor, I fail to see how one wiki's actions should cause so much backpedaling. > Here's a patch that will place footnotes at the bottom of pages which don't > have <reference/> tags while silently reporting Eww eww eww. <references /> is almost never at the bottom, and this will just encourage lazy editing/formatting of pages. I would hope the wiki never outputs markup you didn't add, only warn you when something's wrong. On semi-related note: if there's issues with how Cite outputs errors, that's for a different bug. Not within the scope of this one.
(In reply to comment #21) > (In reply to comment #16) > > English Wikipedia have already blanked the error printed by this bug so you'd > > have to wonder if it was worth the effort in the first place. > > > > I thought it was a rather informative error. Suggestions welcome on exact > wording though. To be honest: it doesn't really matter what enwiki does with > the message. Do other communities like it? If the general agreement is in > favor, I fail to see how one wiki's actions should cause so much backpedaling. <snip> I think the primary complaint with the error message isn't the text, but rather that many people saw silently failing as the expected behavior under some circumstances. Specifically, when one copies text from an article to a talk page for discussion, that text may contain ref tags, but that does not necessarily mean that people want or expect a references section on the talk page. On enwiki, this modification added error messages to hundreds of pages where no one really thought there was a problem. Hence people are going out of their way to hide the error message from those pages, since they don't really see it as an error.
IMO the issue here is not that an error message in *X* circumstance or in *Y* circumstance is a Good or Bad Thing, it's that cite.php's error messages are so tied up in hardcoded HTML and each other that it's not possible for individual wikis to properly customise the appearance to suit their own preferences. We've already 'solved' the original problem as of comment 12, but the deeper issue is that we need to untangle cite.php's error tags so people can actually control them individually without inavdertantly borking the entire set in one.
*** Bug 17740 has been marked as a duplicate of this bug. ***
*** Bug 26976 has been marked as a duplicate of this bug. ***
I think the issues have been taken care of and comment 23 refers to a new problem. Opened bug 28843 for that one.
