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!

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.

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.

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

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.

michael.daly wrote:

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.

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.

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

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

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>

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

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:

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

• 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

dasch wrote:

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

dasch wrote:

A first try for fix

*enhancement ;)

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

Attached:

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

dasch wrote:

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.

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.

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

dasch wrote:

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.

dasch wrote:

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.

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.

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.