Last modified: 2014-11-17 10:35:21 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 13127 - Page number attribute for <ref> tags
Page number attribute for <ref> tags
Status: REOPENED
Product: MediaWiki extensions
Classification: Unclassified
Cite (Other open bugs)
unspecified
All All
: Lowest enhancement with 5 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: need-parsertest, patch, patch-reviewed
: 22300 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-23 12:42 UTC by Stephen Bain
Modified: 2014-11-17 10:35 UTC (History)
18 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Patch to implement enhancement (18.32 KB, patch)
2008-02-23 12:42 UTC, Stephen Bain
Details
Patch to implement enhancement (29.40 KB, patch)
2009-06-30 17:16 UTC, Stephen Bain
Details
A first try for fix (4.57 KB, patch)
2013-01-22 22:22 UTC, DaSch
Details

Description Stephen Bain 2008-02-23 12:42:25 UTC
Created attachment 4669 [details]
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.
Comment 1 DuncanHill 2008-12-18 18:44:40 UTC
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!
Comment 2 Happy-melon 2008-12-18 18:46:42 UTC
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. 
Comment 3 Alex Z. 2008-12-18 23:46:51 UTC
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.
Comment 4 Michael Daly 2008-12-19 15:26:45 UTC
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)).
Comment 5 Gurch 2008-12-19 17:08:56 UTC
{{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.
Comment 6 Michael Daly 2008-12-19 20:37:15 UTC
That's why I suggested having ref load up Cite.
Comment 7 Alex Z. 2008-12-19 21:52:38 UTC
(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. 
Comment 8 Michael Daly 2008-12-20 03:12:47 UTC
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.
Comment 9 Bill Mitchell 2008-12-21 02:08:51 UTC
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|Bloggs1990]], p.123.</ref>
*b2<ref name=Bloggs1990p123 />
*b3<ref name=Bloggs1990p185>[[#Bloggs1990|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>
Comment 10 DuncanHill 2008-12-21 02:27:36 UTC
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|Bloggs1990]], p.123.</ref>
> *b2<ref name=Bloggs1990p123 />
> *b3<ref name=Bloggs1990p185>[[#Bloggs1990|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>
> 

Comment 11 Alex Z. 2008-12-21 03:58:23 UTC
(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.
Comment 12 Bill Mitchell 2008-12-21 06:26:33 UTC
(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.
Comment 13 Stephen Bain 2009-06-30 17:16:01 UTC
Created attachment 6286 [details]
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.
Comment 14 maxime.saintes 2010-01-30 13:38:21 UTC
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
Comment 15 p858snake 2010-07-05 03:39:57 UTC
*** Bug 22300 has been marked as a duplicate of this bug. ***
Comment 16 Mark A. Hershberger 2011-11-15 19:56:26 UTC
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).
Comment 17 Mark A. Hershberger 2012-02-24 16:37:18 UTC
removing highest till this gets a working patch
Comment 18 DaSch 2013-01-22 21:16:42 UTC
I hope somebody will take care of this, that would be a great enchantment
Comment 19 DaSch 2013-01-22 22:22:21 UTC
Created attachment 11668 [details]
A first try for fix

*enhancement ;)

I made this fast solution and this works quite well I think
Comment 20 DaSch 2013-01-22 22:25:31 UTC
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
Comment 21 DaSch 2013-01-30 13:33:04 UTC
Can somebody commit this to gerrit or will this be the next patch I submit and nobody will ever see it?
Comment 22 Andre Klapper 2013-01-30 15:05:28 UTC
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.
Comment 23 Brad Jorsch 2013-01-30 15:27:00 UTC
(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.
Comment 24 Bartosz Dziewoński 2013-01-30 18:19:33 UTC
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.
Comment 25 DaSch 2013-02-05 11:34:40 UTC
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.
Comment 26 Bartosz Dziewoński 2013-02-05 17:37:14 UTC
(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.)
Comment 27 DaSch 2013-04-27 18:14:32 UTC
I created a fork of the Cite Extension with this Feature on github.
https://github.com/DaSchTour/mediawiki-extensions-Cite
Comment 28 Brad Jorsch 2013-04-28 00:20:24 UTC
Just because you created a fork somewhere else doesn't mean it's fixed.
Comment 29 DaSch 2013-04-28 17:15:46 UTC
I just don't think that after five years of nearly no movement there will ever be anyone working on this ;)
Comment 30 Bartosz Dziewoński 2013-04-28 17:38:00 UTC
(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.
Comment 31 Brad Jorsch 2013-04-28 21:35:57 UTC
(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.
Comment 32 DaSch 2013-04-29 21:16:12 UTC
(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.
Comment 33 Quim Gil 2014-04-30 06:54:21 UTC
A year later...

Setting priority to Lowest because nobody seems to be working or planning to work on this.
Comment 34 Brad Jorsch 2014-04-30 13:09:17 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links