On Thu, Sep 17, 2009 at 4:43 PM, Steve Bennett <stevagewp(a)gmail.com> wrote:
On Fri, Sep 18, 2009 at 8:46 AM, Andrew Garrett
<agarrett(a)wikimedia.org> wrote:
A fix for this went live today. You can now put
your <ref name="">
tags into the <references> tag, and then reference them by name.
Oh, so it did. And it works!
http://en.wikipedia.org/w/index.php?title=Gippsland_Lakes_Discovery_Trail&a…
What's great about this kind of improvement is that it lets you see
where the next possible improvements could be:
- Separate out infoboxes
- Separate out images
*shrug*
Anyway, I look forward to a new era of editing without massive cite
templates in my face!
(And yes, a bot should go through and move them all...or at least ones
where the definition > X characters)
Before we get all excited about having a bot move all the references,
it is worth noting that there is a rare use case that is known to fail
when moved inside the references block (bug 20707).
Specifically, it consists of nested refs constructed with the #tag
syntax. (Ordinarily, the parser and Cite make it impossible to place
a <ref> inside another <ref>, but someone figured out that you can
work around this by exploiting the out of order parser evaluations
created by #tag to create nested refs.) These nested ref
constructions universally fail when moved into the references block,
and often do so in a not very informative way.
In practice it is very rare to have a ref be placed inside the content
of another ref, so the problem of nested refs will almost never come
up, but it is something to be aware of if one is considering any mass
effort to relocate refs inside the references block.
It is actually a rather tricky problem to solve. The right answer is
probably to build in generic support for nested references but that
would require significant changes to Cite's data stack and probably a
couple modifications and / or new hooks in the parser itself. If I
reach a point of having more free time, this is an issue I've been
planning to look at.
-Robert Rohde