This patch adds support for a new "page" attribute to <ref> tags. Currently <ref>s can be grouped by the "name" attribute, this adds subgrouping by "page" also. This has been a fairly regularly requested feature (though I can't see an existing bug for it).

A "page" attribute will only have meaning on a <ref> which already has a "name" attribute specified. <ref>s with page attributes are presented in an ordered list element within the list item element for the named reference it is associated with.

Tested against 1.12 alpha (r30959). For some reason parserTests.php crashes PHP on my box (probably because it runs Windows), so I haven't run the parser tests on it, though some test pages on my wiki seem to render fine.

This would be more widely useful if it were a generic "name2" attribute
(perhaps transitioning "name"-->"name1"?); this would lead naturally to a
N-Dimensional reference structure which would be immeasurably more useful.

Rather than adding a confusing, vaguely named attribute to the refs, why not just make any calls to a named ref that have actual content, where the name has already been used, a "sub-reference" of the first instance?

Right now, if you something like:
Text<ref name=foo>Foo</ref>
More text<ref name=foo>Bar</ref>

You get:

^ a b Foo

the "Bar" in the second ref is just silently ignored. However,if it worked like:

^ a Foo

b Bar

it could be used for page numbers, or anything else.

The only problem with this is that it would require the first instance to be the "main" ref, which could cause problems. Though this could probably be worked around by either using the ref with the most content as the main, or with a "main" attribute to mark the main ref in a group based on name.

Rather than change this in <ref>, should it not be a change to Cite? This might be a tad complex by comparison, but Cite has the existing parameters that break the reference down into elements such as title, authors etc. For example,

<ref name=foo>{{Cite|...full set of parameters...}}</ref>

and in another place

<ref name=foo>{{Cite|pages=23-25}}</ref>

When Cite sees the partial data, it uses it to add to the existing info (or in a more practical sense, ref can load up Cite with the other info from the main <ref> and augment with the additional parameter(s)).

Rather than change this in <ref>, should it not be a change to Cite? This
might be a tad complex by comparison, but Cite has the existing parameters that
break the reference down into elements such as title, authors etc. For
example,

<ref name=foo>{{Cite|...full set of parameters...}}</ref>

and in another place

<ref name=foo>{{Cite|pages=23-25}}</ref>

As I said, this doesn't currently work. If you have multiple refs with the same name, the content in everything except the first is silently ignore. And as Gurch said, Cite is just a template. It has no way of knowing the name of the ref its in, or if its in a ref at all.

Well, if more than one with the same name is specified, it should be changed to look at the content for updates to the first Cite. Not a problem in concept.

And as I said - have ref load up Cite since it *does* know the info. For some reason that only some programmer knows, Cite is an extension that doesn't implement Cite; Cite is also a template that could have been an extension. The real Cite extension implements ref. Only a programmer would do something like that.

The trouble with Harvard refs is that they are (particularly when an article has a large number of references) difficult for the reader to follow. Also, when clicking on a ref number in a text, one is then taken to a reference which does not actually tell you what it is - one has to scroll around to find the list of works, and then read through that to find the surname that relates to the reference.
(In reply to comment #9)

I don't see any need for this. It adds complication without adding
functionality.

Scrolling around is not necessary. The havard refs are clickable and navigate to the associated cite. Navigation back is via the browser's <back> button. My example placed the clickable harvard refs in a ''Notes'' section, so click the footnote number to get to the harvard ref, click that (optionally page-number-specific) harvard ref to get to the full citation for the item being cited, click the <back> button to navigate back to the harvard ref, click the <back> button again to navigate back to the particular instance of the numbered footnote in the text.

I agree with Brad in general. Either this should be implemented on-wiki in citation templates (personally I'm quite fond of {{sfn}}-like style), or the entire thing with the citation styles included should be handled by the extension.

I'd prefer to do code-review in gerrit, but something that immediately springs to mind when looking at the patch is that the colon you're inserting is not localized nor customizable.

The point is. I'M NOT A SOFTWARE DEVELOPER! I have no experience with PHP and I hate working with PHP. What I have done is to make a Prototype that shows how it could look like can be used to insert such little things. The problem with mediawiki is, that nobody cares about such things. Nobody will take this patch and insert something. Here are just people saying, this is missing and I don't change anything so nothing is changed at the end.

With git it's no problem for me to maintain a fork of every extension with my personal changes and I don't care if anybody else will ever can use it even if there are thousands waiting for it.

The point is. I'M NOT A SOFTWARE DEVELOPER! I have no experience with PHP
and I
hate working with PHP.

Neither am I and so do I. Most people reading these bugs and (sometimes) acting on them are just volunteers, and they're not obligated to do *anything at all*. WMF staff are usually busy enough working on the things they're being paid to work on.

What I have done is to make a Prototype that shows how
it could look like can be used to insert such little things. The problem with
mediawiki is, that nobody cares about such things. Nobody will take this
patch
and insert something. Here are just people saying, this is missing and I
don't
change anything so nothing is changed at the end.

What you've shown is already possible reasonably easily using [[template:rp]] from English Wikipedia (you can copy it to any wiki in like 30 seconds). But personally, I just don't like this solution at all, so I'm not going to spend my time implementing it, as there's no shortage of things I care about to work on.

With git it's no problem for me to maintain a fork of every extension with my
personal changes and I don't care if anybody else will ever can use it even
if
there are thousands waiting for it.

If it works for you, great, I'm glad; but I believe it won't work for most people, and as you've shown, it's trivial for anybody wanting this to use it.

Setting priority to Lowest because nobody seems to be working or planning to
work on this.

Since Parsoid has reimplemented the Cite extension in their own code, any fixes to Cite are going to be very difficult to get merged unless someone wants to do all the work twice, once in PHP and once in nodejs.

Add Comment

Text is available under the Creative Commons Attribution-ShareAlike 3.0 License (CC-BY-SA); code is available under the GNU General Public License (GPL) or other appropriate open source licenses. By using this site, you agree to the Terms of Use and Privacy Policy. · Wikimedia Foundation · Privacy Policy · Terms of Use · Disclaimer · CC-BY-SA · GPL