Page number attribute for <ref> tags
OpenPublic

Assigned To
None
Priority
Lowest
Author
bzimport
Subscribers
jeremyb, DerHexer, Gadget850 and 11 others
Projects
Tokens
"Love" token, awarded by He7d3r.
Reference
bz13127
Security
None
Description

Author: stephen.bain

Description:
Patch to implement enhancement

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.


Version: unspecified
Severity: enhancement

attachment ExtensionCitePageNumberSupport.patch ignored as obsolete

bzimport added a project: Cite.Via ConduitNov 21 2014, 10:06 PM
bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz13127.
bzimport created this task.Via LegacyFeb 23 2008, 12:42 PM
bzimport added a comment.Via ConduitDec 18 2008, 6:44 PM

duncan.hill1 wrote:

This would enable a great improvement in the use of references in Wikipedia, enhancing the encyclopaedic value of the project.

It is requested regularly, so please do let us have it!

bzimport added a comment.Via ConduitDec 18 2008, 6:46 PM

happy_melon wrote:

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.

Mr.Z-man added a comment.Via ConduitDec 18 2008, 11:46 PM

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:

  1. ^ 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.

bzimport added a comment.Via ConduitDec 19 2008, 3:26 PM

michael.daly wrote:

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

bzimport added a comment.Via ConduitDec 19 2008, 5:08 PM

matthew.britton wrote:

{{cite}} is just a template, if you call it with only one parameter like that it has no way of "knowing" what the other parameters are supposed to be.

bzimport added a comment.Via ConduitDec 19 2008, 8:37 PM

michael.daly wrote:

That's why I suggested having ref load up Cite.

Mr.Z-man added a comment.Via ConduitDec 19 2008, 9:52 PM

(In reply to comment #4)

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.

bzimport added a comment.Via ConduitDec 20 2008, 3:12 AM

michael.daly wrote:

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.

bzimport added a comment.Via ConduitDec 21 2008, 2:08 AM

bill.mitchell wrote:

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

I've often done something like the following:
*a1<ref name=Doe1984p5>{{Harvnb|Doe1984|p=5}}.</ref>
*a2<ref name=Doe1984p5 />
*a3<ref name=Doe1984p50>{{Harvnb|Doe1984|p=50}}.</ref>
Or, without the templates:
*b1<ref name=Bloggs1990p123>Bloggs1990, p.123.</ref>
*b2<ref name=Bloggs1990p123 />
*b3<ref name=Bloggs1990p185>Bloggs1990, p.185.</ref>

Notes

<References />

References

*{{Citation

last=Doe
first=John
title=John's book
year=1984

}}.
Or, without the template:
*<cite id=Bloggs1990>Bloggs, Joe, ''A book by Joe Bloggs'' (1990).</cite>

bzimport added a comment.Via ConduitDec 21 2008, 2:27 AM

duncan.hill1 wrote:

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.

I've often done something like the following:
*a1<ref name=Doe1984p5>{{Harvnb|Doe1984|p=5}}.</ref>
*a2<ref name=Doe1984p5 />
*a3<ref name=Doe1984p50>{{Harvnb|Doe1984|p=50}}.</ref>
Or, without the templates:
*b1<ref name=Bloggs1990p123>Bloggs1990, p.123.</ref>
*b2<ref name=Bloggs1990p123 />
*b3<ref name=Bloggs1990p185>Bloggs1990, p.185.</ref>

==Notes==
<References />

==References==
*{{Citation
|last=Doe
|first=John
|title=John's book
|year=1984
}}.
Or, without the template:
*<cite id=Bloggs1990>Bloggs, Joe, ''A book by Joe Bloggs'' (1990).</cite>

Mr.Z-man added a comment.Via ConduitDec 21 2008, 3:58 AM

(In reply to comment #9)

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

If we do what I suggested, it would just turn something that's arguably broken right now (it just ignores text under the situation) into something useful.

bzimport added a comment.Via ConduitDec 21 2008, 6:26 AM

bill.mitchell wrote:

(In reply to #10 from DuncanHill)

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.

bzimport added a comment.Via ConduitJun 30 2009, 5:16 PM

stephen.bain wrote:

Patch to implement enhancement

Since the February 2008 patch was never reviewed, I've created this new patch to introduce the enhancement into the current version of the extension.

In order to implement the enhancement, the patch also replaces the current array-based datastructure with a more flexible object-based datastructure, which should make future enhancements easier.

My working copy passes all of the current 17 custom parser tests for the extension. It would certainly be possible to introduce some new tests to cover the new functionality.

Attached: patch.txt

bzimport added a comment.Via ConduitJan 30 2010, 1:38 PM

maxime.saintes wrote:

Any update on this improvement request ? Is a new function being tested to be implemented in MediaWiki ? What has been suggested by Alex Z. would be great.

Thanks.

Maxime

Peachey88 added a comment.Via ConduitJul 5 2010, 3:39 AM
  • Bug 22300 has been marked as a duplicate of this bug. ***
MarkAHershberger added a comment.Via ConduitNov 15 2011, 7:56 PM

Patch didn't apply. If you still want this, can you update the patch?

$ curl 'http://bug-attachment.wikimedia.org/attachment.cgi?id=6286&action=diff&collapsed=&context=patch&format=raw&headers=1' | patch -p7

% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                               Dload  Upload   Total   Spent    Left  Speed

100 28799 0 28799 0 0 33451 0 --:--:-- --:--:-- --:--:-- 37893
patching file Cite.i18n.php
Hunk #1 FAILED at 50.
1 out of 1 hunk FAILED -- saving rejects to file Cite.i18n.php.rej
patching file Cite_body.php
Hunk #1 FAILED at 23.
Hunk #2 FAILED at 75.
Hunk #3 FAILED at 128.
Hunk #4 FAILED at 186.
Hunk #5 FAILED at 208.
Hunk #6 succeeded at 325 with fuzz 2 (offset 107 lines).
Hunk #7 FAILED at 236.
Hunk #8 FAILED at 251.
Hunk #9 FAILED at 362.
Hunk #10 FAILED at 416.
Hunk #11 succeeded at 835 (offset 311 lines).
Hunk #12 FAILED at 565.
Hunk #13 FAILED at 585.
Hunk #14 FAILED at 606.
Hunk #15 succeeded at 1028 (offset 319 lines).
12 out of 15 hunks FAILED -- saving rejects to file Cite_body.php.rej
patching file Cite_ref.php
patching file Cite.php
Hunk #1 succeeded at 32 with fuzz 1 (offset -3 lines).

MarkAHershberger added a comment.Via ConduitFeb 24 2012, 4:37 PM

removing highest till this gets a working patch

bzimport added a comment.Via ConduitJan 22 2013, 9:16 PM

dasch wrote:

I hope somebody will take care of this, that would be a great enchantment

bzimport added a comment.Via ConduitJan 22 2013, 10:22 PM

dasch wrote:

A first try for fix

*enhancement ;)

I made this fast solution and this works quite well I think

Attached: cite.diff

bzimport added a comment.Via ConduitJan 22 2013, 10:25 PM

dasch wrote:

Working solution can be seen here
http://www.wecowi.de/wiki/Verelendungswachstum

Change to the message is here
http://www.wecowi.de/wiki/MediaWiki:Cite_reference_link

bzimport added a comment.Via ConduitJan 30 2013, 1:33 PM

dasch wrote:

Can somebody commit this to gerrit or will this be the next patch I submit and nobody will ever see it?

Aklapper added a comment.Via ConduitJan 30 2013, 3:05 PM

DaSch: It could help if you could answer bug 38783 comment 21 and 22, so we can make contributing easier for you and your patches more visible to reviewers.

Anomie added a comment.Via ConduitJan 30 2013, 3:27 PM

(In reply to comment #21)

Can somebody commit this to gerrit or will this be the next patch I submit
and
nobody will ever see it?

Personally, I really don't like the style you implemented here. Page numbers should be in the references section, not hidden next to the footnote link.

enwiki's [[Template:Rp]] is a dirty hack to get around the lack of some real support for subreferences. We shouldn't perpetuate that style, IMO.

matmarex added a comment.Via ConduitJan 30 2013, 6:19 PM

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.

bzimport added a comment.Via ConduitFeb 5 2013, 11:34 AM

dasch wrote:

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.

matmarex added a comment.Via ConduitFeb 5 2013, 5:37 PM

(In reply to comment #25)

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.

(Sorry about the OT rant.)

bzimport added a comment.Via ConduitApr 27 2013, 6:14 PM

dasch wrote:

I created a fork of the Cite Extension with this Feature on github.
https://github.com/DaSchTour/mediawiki-extensions-Cite

Anomie added a comment.Via ConduitApr 28 2013, 12:20 AM

Just because you created a fork somewhere else doesn't mean it's fixed.

bzimport added a comment.Via ConduitApr 28 2013, 5:15 PM

dasch wrote:

I just don't think that after five years of nearly no movement there will ever be anyone working on this ;)

matmarex added a comment.Via ConduitApr 28 2013, 5:38 PM

(In reply to comment #29)

I just don't think that after five years of nearly no movement there will
ever
be anyone working on this ;)

This is because a considerable number of people are against this solution.

I'm recommending WONTFIX-ing this and linking the fork in applicable places.

Anomie added a comment.Via ConduitApr 28 2013, 9:35 PM

(In reply to comment #29)

I just don't think that after five years of nearly no movement there will
ever be anyone working on this ;)

If I ever find a weekend where I'm both free and motivated to code (this weekend lacked the latter), I intend to take a shot at it.

(In reply to comment #30)

This is because a considerable number of people are against this solution.

Note DaSch's attempt is not what was originally proposed here.

bzimport added a comment.Via ConduitApr 29 2013, 9:16 PM

dasch wrote:

(In reply to comment #31)

(In reply to comment #29)
> I just don't think that after five years of nearly no movement there will
> ever be anyone working on this ;)

If I ever find a weekend where I'm both free and motivated to code (this
weekend lacked the latter), I intend to take a shot at it.

(In reply to comment #30)
> This is because a considerable number of people are against this solution.

Note DaSch's attempt is not what was originally proposed here.

So I would like to know what was proposed! Please explain.

Qgil added a comment.Via ConduitApr 30 2014, 6:54 AM

A year later...

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

Anomie added a comment.Via ConduitApr 30 2014, 1:09 PM

(In reply to Quim Gil from comment #33)

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.

He7d3r awarded a token.Via WebNov 24 2014, 12:54 PM
DerHexer added a subscriber: DerHexer.Via WebJan 29 2015, 11:48 PM
jeremyb-phone added a subscriber: jeremyb.Via WebFeb 26 2015, 5:10 PM
jeremyb-phone set Security to None.
MarkAHershberger removed a subscriber: MarkAHershberger.Via EmailFeb 26 2015, 5:54 PM

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.