bugs wrote:

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.

Nikolas wrote:

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.

ayg wrote:

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

Nikolas wrote:

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.

TheMuuj wrote:

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>

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?

Attached:

TheMuuj wrote:

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.