Last modified: 2006-11-03 14:09:25 UTC
When several m:Cite.php <ref>s with the same name are used, only the first reference is considered for rendering by the <references/> tag; this applies both when the first <ref name=foo> is altogether empty, and when differing contents occur in multiple such named references. If this limitation were lifted, editors of pages would have a variety of more flexible options for organization of references. For example, using non-first named references when earlier ones were empty would allow references to be grouped together at the end of an article, or at the end of a section, if article editors judged this more desirable. I have examined the code for m:Cite.php, and believe that the fix for this is below. This change should cause no change in the rendering of articles that use Cite.php in a bug free manner, but will allow additional uses in the future and/or fix articles with current reference ordering errors. --- Cite.php 2006-05-04 13:12:19.000000000 -0400 +++ Cite.php.new 2006-05-04 12:47:24.000000000 -0400 @@ -291,7 +291,12 @@ $this->mRefs[$key]['number'] ); } else - // We've been here before + // We've been here before + $found_text = $this->mRefs[$key]['text']; + if ( empty($found_text) and !empty($str)) { + // If no text found before, use this text + $this->mRefs[$key]['text'] = $str; + } return $this->linkRef( $key,
See also bug 5997 (this one apparently solves one of two problems there)
Please see http://en.wikipedia.org/wiki/Wikipedia_talk:Footnotes#when_will_this_be_solved.3F 28 people on aggregate will you to fix this bug!!!! There is a patch right there ---^ Please please please apply this patch!
Restoring priority.
Do these people have to register and vote here too to increase priority? The result was 33 vs 5. This is compelling majority, through extensive discussion that lasted for more than a week! 1.It's crazy to force editors who re-organise articles to move refs from second-used-to- be-first-pars to first-used-to-be-second-ones. 2.Safety mechanism: non-first-ref text appears ONLY if first-refs before that are EMPTY.
(In reply to comment #4) > Do these people have to register and vote here too to increase priority? The result was > 33 vs 5. This is compelling majority, through extensive discussion that lasted for more > than a week! I believe you misunderstand the purpose of the "priority" tag. Wikimedia Foundation programming is done by two paid programmers (Tim and brion), who make the final decision on whether changes make it into the software, plus a team of unpaid volunteers. What this means is that all programmers fix whichever bugs they would like to fix: Tim and brion are in charge, so no one tells them what to do, and the others are volunteers, so no one tells *them* what to do. "Priority" is a way of indicating what bugs *will* probably be fixed soon due to programmer interest, not a way of indicating what bugs *should* be fixed soon according to what other people think. The latter is what votes are for. You could get everyone to vote here if you like, but it probably won't move up the timetable very much, if at all. Nagging various people who don't have any reason to listen to you isn't going to help, either. The only surefire way of getting anything done here is to do it yourself--and the difference between that and what happens in most commercial software is that here, you *can* do it yourself. And as for *why* people like brion have decided not to spend any time on this, please keep perspective. It would take time to test this patch, even for someone familiar with the code (such as Avar), and the gain would be small compared to many of the other open bugs and enhancement requests. 60 of those bugs are rated as "major" or more severe; try running a search and looking over those bugs and their implications before you complain about why this minor feature addition rates above all 1,610 other open bugs and enhancement requests. *As it happens*, *if* someone with SVN access volunteers to look over submitted code for such minor matters, I've been making tweaks to Cite.php lately anyway, largely because it's an extension and it doesn't deal with database stuff, so it's easier for someone new to MediaWiki to work with. I *might* therefore get around to doing this at some time in the next month or two, if all goes well. This is not, however, related to your behavior. I suggest you (and, e.g., Francis Tyers) just drop the issue and hope someone handles it rather than nagging, because nagging is just going to piss people off.
Point taken. No offence but it sounded simpler than that. No further nagging whatsoever. Also noted no mass-voting needed. Only too many editor-working-hours consumed due to this glitch to move around ref texts from one par to the other. Hope it's solved soon, and admire your work (wish I myself could write/test the darn code too to help).
Thanks for your time. Regards.
I'm all for this, but I'd like to see one additional change made. (I'm not sure if this warrants opening another bug or not). The <references> element should allow <ref> child elements. I'm not sure how hard this would be to parse given the existing code-base. Any <ref> elements inside the <references> element would not be rendered, and there'd be no back-links to them. This would allow the references to be defined at the bottom of a page, in the references section, without any CSS visibility hacks. Here's some example Wikitext: ==Content== * Item A <ref name="A"/> * Item B <ref name="B"/> * Item C <ref name="C"/> ==References== <references> <ref name="A">Reference A</ref> <ref name="B">Reference B</ref> <ref name="C">Reference C</ref> </references>
Created attachment 2533 [details] Patch for Cite.php to allow late definition of reference content I have submitted a patch which appears to work properly: it will register the content the first time that a non-empty reference appears rather than simply the first time. I have checked it with "php -l" but further testing would probably be a good idea. Would it be a good idea to display a warning message if no content is ever defined, or is it sufficient to display an empty reference?
Would the warning messages have to be localized? If so, I think an empty reference would stand out enough, and there's no need to complicate matters. Someone may very well want an empty reference for some reason.
Fixed in r17382.
