Last modified: 2014-11-17 10:35:21 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.
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!
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: 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.
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)).
{{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.
That's why I suggested having ref load up Cite.
(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.
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.
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>
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> >
(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.
(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.
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.
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
*** Bug 22300 has been marked as a duplicate of this bug. ***
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).
removing highest till this gets a working patch
I hope somebody will take care of this, that would be a great enchantment
Created attachment 11668 [details] A first try for fix *enhancement ;) I made this fast solution and this works quite well I think
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
Can somebody commit this to gerrit or will this be the next patch I submit and nobody will ever see it?
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.
(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.
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.
(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.)
I created a fork of the Cite Extension with this Feature on github. https://github.com/DaSchTour/mediawiki-extensions-Cite
Just because you created a fork somewhere else doesn't mean it's fixed.
I just don't think that after five years of nearly no movement there will ever be anyone working on this ;)
(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.
(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.
(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.
A year later... Setting priority to Lowest because nobody seems to be working or planning to work on this.
(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.
