This change was requested years ago and was on the top ten Community Wishlist requests, yet after I submitted the change in the Jerusalem Hackathon, nobody reviewed or merged it. Now it cannot be merged due to some conflict and my git-jitsu is insufficient to fix this.

CAN SOMEONE PLEASE REVIEW AND MERGE THIS? Thanks.

I'm working on a gadget that could make great use of this new functionality, and the community has been waiting for something like this for quite some time. Can we get it done already???

In T100645#2567999, @lfschenone wrote:

CAN SOMEONE PLEASE REVIEW AND MERGE THIS?

Please do not shout. :-(

Fundamentally, as I believe I said in 2015 at the Hackathon when this was discussed, I have some serious issues adding yet more complexity to the Cite extension to try to do structured references when it's already been roughly agreed that people want to move structured data for references to Wikidata.

However, that pipe-dream keeps being pushed back, so I suppose we should go ahead with your code (which solves T15127: Page number attribute for <ref> tags; I'm not sure that it solves this task, as I didn't write it and I don't speak German enough to properly understand whether everyone would be happy with this solution).

I'll get one of my team to look at it soon.

Sorry for the shout, I got carried away. I agree that structured references connected with Wikidata is the way to go, and in fact i'm working on something very much related to it (https://meta.wikimedia.org/wiki/Grants:IEG/Enhance_the_ProveIt_gadget). But I also agree that until all that becomes a reality, this note parameter may do lots of good.

I'd actually prefer to resolve T138601: Possibility to refine existing <ref>, e.g. reference individual pages in a book rather than this task because I think the implementation for "refines" would also be somewhat cleaner in read mode--I'd hate to inject "page 1"/"page 2". Would that also require a massive extension rewrite? Basically, the reader shouldn't care in the context of the statement whether it's on page 1 or 2--he should only care about that in the context of the citation. Maybe Design should have some input (if jdf isn't that person).

I don't agree with Fisch regarding having fixed parameters, but I understand his reasoning.

See also T15127#179448.

@lfschenone I understand your frustration as there has been no real motion around your patch for a while, and as you say, you're waiting for such feature be available to the gadget you're working on.

@Izno has already mentioned T138601 here, thanks. This task was result of a little brainstorming session that happened during Wikimania Hackathon. Personally I like the solution prosed in that task better than the approach you have been taking so far, ie. putting "refined" information in the reference in the reference list, not squeezing relevant information next to the tiny link. The other solution also does not have issues with the choice of "labels" one could use to refine the reference (one could basically whatever what makes sense in particular context, not just be limited to page, chapter number etc).

I feel personally sorry I haven't directed you @lfschenone to T138601 earlier. When I saw discussion that resulted in that ticket happening during the hackathon I had your work in mind for the whole time. Now I see I have even started writing comment pinging you in the other topic but it hasn't been finished and sent. Must have happened due to network problems during the hackathon. Lame excuse, I know. My apologies.

Could you please have a look at what has been propsed in T138601 and how does it sounds to you? I think it is very valuable to have multiple approaches discussed and then try to implement the one that seems the most right. This means more waiting for it to happen but I am really optimistic that we'll get there.

Speaking for WMDE devs in next few weeks we unfortunately won't be able to devote as much time as working on implementation of refined references (be it the way suggested in T138601, here, or any other) as this task would require. We would be glad to help with possible issues and code reviews (more actively than so far).

And as far as https://gerrit.wikimedia.org/r/#/c/280923 is concerned I could offer my "git-jitsu" skills and try to rebase it, if @lfschenone says after looking at T138601 that he stills wants to work on this patch. Please just let me know what you think.

Regarding the progress on this, could this task use help from an Outreachy intern( Dec 6 to March 6 )? Please note that applications are open until Oct - 17.

Let us know if possible at the earliest.
Ideally it should take about 2-3 weeks for an experienced developer to complete the task, in order to qualify as an intern project.

Hi @Sophivorus , I'm the product manager of the German-speaking community's technical wishlist. Thanks for your efforts of bringing this wish closer to realisation! During the past weeks, we have realized more and more how controversial the whole subject of referencing is within the community. Last week, we came to the conclusion that it would be really hard to get a community buy-in for the page-parameter solution. Currently, multiple different ways of referencing are used and by adding a page parameter we would have to decide on how references should be formatted in the future (e.g. will there be a full stop at the end or not?). However, the before mentioned T138601 still leaves the decision of how to reference sources with the person who uses it. This is why we decided to do a feedback round within the German community to see if they would accept this solution as a fulfilment of their wish. The survey is ongoing until September 22nd, and of course I will keep you updated about the outcome! If this solution is accepted, we should discuss the next steps. Hopefully the found solution also helps you in your work on your gadget.

In T100645#2568417, @Jdforrester-WMF wrote:

Fundamentally, as I believe I said in 2015 at the Hackathon when this was discussed, I have some serious issues adding yet more complexity to the Cite extension to try to do structured references when it's already been roughly agreed that people want to move structured data for references to Wikidata.

I'm not sure there are any consensus on this. I have no doubt that @Jdforrester-WMF want it, but I seriously doubt it is possible to sell this idea to the community at the moment.

In T100645#2172902, @WMDE-Fisch wrote:

To your patch: I like the idea of having additional parameters that can be used to specify the different parts in one work. But using arbitrary parameters might be not the best way to do it. If people start using them and later the Cite extension wants to use some of them for another propose they might run into conflicts with stuff thats already there.

Use of free attributes will create a lot of problems, please don't do that! Use fixed attributes or declare them somehow. If the tag function detects non-declared attributes that neither is fixed, then the page should be added to a tracking category of tags with erroneous calls.

In T100645#2173834, @Sophivorus wrote:

Hi @WMDE-Fisch, thanks for the review! The possibility of a future conflict could be solved by adding a prefix to any new parameters introduced by the Cite extension, or just picking parameter names that are unlikely to be used by any template. Allowing arbitrary parameters has the great advantage of making the solution multilingual, which would be very hard to accomplish with fixed parameters.

This is a tag, and as such should not be multilingual.

In T100645#2173834, @Sophivorus wrote:

Regarding the place where to display the additional info, at first I tried displaying it in the reflist, but I found out that doing so would require a big rewrite of the extension, which I'm unable to do in the Hackathon. And deploying the solution I submitted shouldn't create a compatibility problem if in the future someone decides to implement the big rewrite.

The right place for the additional info is probably the reference-tag, and this will also create the least noise in the text.

Change 280923 abandoned by Sophivorus:
Add "note" parameter for specifying page, chapter, volume, etc.

Reason:
There's lots of talking about this issue. This particular patch has no chance of ever being accepted.

https://gerrit.wikimedia.org/r/280923

We also need to make sure that the original source is also displayed on hover. If we are talking about https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Book_referencing

If you want more feedback, I can start discussing this implementation on the Russian Wikipedia.

How about using namespace to pass on extra attributes to a template in the ref?

Definition:
<ref name="Test">{{Cite|title=Test|page=50}}</ref>

Reference with different page:
<ref use="Test" t:page=47/>
Equivalent to:
<ref>{{Cite|title=Test|page=47}}</ref>

Named:
<ref name="Test47" use="Test" t:page=47/>
Equivalent to:
<ref name="Test47">{{Cite|title=Test|page=47}}</ref>
Re-use:
<ref name="Test47"/>

Not sure if you could resolve this easily on Parsoid level. But this would give much freedom of using various parameters and still allow adding different attributes to ref (if that ever happens). So that would not only allow pages, but also adding info on location (like in sfn template).

In editing GUI such reference could have collapsed fields with just the changed one shown. You could add an option/button to convert to full reference (which would replace wikicode with the equivalent).

When viewing this you would just see whole template rendered normally. I think this is more friendly then showing shorthand text like in {{sfn}} template. This problem was mentioned in: https://phabricator.wikimedia.org/T15127#179319. So instead of " Smith 2020, p. 25." you would just display "Smith, John (2020). Smith's Book, p. 25".

For showing the original source on hover, we can maybe instead just display the a trimmed tree down to the base ref (in the beta extends proposal). That is, for:

Lorem opsec.<ref name=a>Blurb</ref> Ipsum I don’t remember.<ref name=b extends=a>Baaaa?</ref> I really don’t.<ref name=C extends=a>Glurp</ref>

On hover of note C, we show a box saying something like the following:

Blurb
  ➡️ Glurp

(numbering can be omitted as with current preview)

I believe this is the simplest solution here given what we have… had. We wouldn't need to think about cramming it into a single line or anything. Just make the reference tooltips gadget & the extension ref-preview fetch the parent citation too.