Efficient way to refer to different pages of the same work when adding references to an article (#17)
Open, NormalPublic

Description

Survey: 2013 and 2015

Update sites on-wiki:

Insights:

  • There are very different styles of referencing. Some prefer
    • long references: when you move parts of the text, the references are still defined. Also, when reading through the wikitext, you don't need to scroll anywhere to find out what is referenced
    • short references: The wikitext syntax is much cleaner and shorter. Also you don't need to repeat what you have written --> less chances for errors
  • Often times, templates are used for referencing
  • The solution should not only cater to pages, but also to e.g. articles of a blog, parts of the bible etc. - i.e. it should allow any kind of specification

Plan:

  • Implement an "extends" attribute for the ref tag both in parsoid and in the cite extension
  • Make this usable not only with wikitext, but also through the Visual Editor

This is part of the Top 20 wishes of the German community and #24 on Community Tech's Wishlist Survey 2015.

There are a very large number of changes, so older changes are hidden. Show Older Changes
KasiaWMDE set Security to None.Jun 4 2015, 9:54 AM
KasiaWMDE renamed this task from Efficient way to refer to different pages of the same work when adding references to an article to [GTWL] Epic: Efficient way to refer to different pages of the same work when adding references to an article.Jun 18 2015, 4:31 PM
Restricted Application added a subscriber: Sadads. · View Herald TranscriptFeb 25 2016, 6:55 AM
Elitre added a subscriber: Elitre.Feb 26 2016, 1:15 PM
Sophivorus added a subscriber: Sophivorus.
Sophivorus removed Sophivorus as the assignee of this task.Mar 30 2016, 3:12 PM

I'll do my best to complete this task during the Hackathon 2016.

Change 280923 had a related patch set uploaded (by Luis Felipe Schenone):
Add support for specifying page, chapter, volume, etc.

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

Sophivorus added a comment.EditedApr 1 2016, 3:10 PM

I submitted what I think is a reasonable solution to the issue. It allows for arbitrary parameters (all except "name", "group" and "follow" that are reserved by the cite extension) which makes it very flexible and multilingual. I'm attaching a screenshot with some sample references and the wikitext that generates them, to illustrate how the solution works.

DannyH updated the task description. (Show Details)Apr 2 2016, 8:20 AM

Nice your looking into it @lfschenone ! I just added the members from the German community tech team. Most of them ( including me ) are here on the Hackathon as well.

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.

So maybe there should be one or several fixed parameter(s). There already was some discussion in T15127 but lead to solution so far. As a first step I would go for something like edition chapter(s) page(s) paragraph(s). Or to be more general some generic parameter that could be filled with all info needed.

Second I dont think that displaying the page/additional information in the text next to the annotation but it could be done in the reflist.

Either way we could just meet to talk about possible solutions. Are you in the IRC? I am the one with brown hat and blue sweater sitting outside :-)

Sophivorus added a comment.EditedApr 3 2016, 6:24 AM

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.

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.

I think that the proposed solution is a reasonable one for a request that has been open since 2008. Lets meet today and talk it further! I'm Felipe the guy from Argentina, see you!

Quoth added a subscriber: Quoth.Apr 12 2016, 4:32 PM

Hi @lfschenone, are you make progress here? I just got back to Berlin and wanted to ask if you need any help or have any issues to discuss related to this. Just leave a note and we can figure something out :-)

Sophivorus added a comment.EditedApr 19 2016, 3:49 PM

I submitted a second patch implementing the solution we discussed with @WMDE-Fisch (sorry for the delay, I was traveling and had a problem with my computer).

I named the new parameter "note" but maybe someone comes up with a better name.

The text added through the "note" parameter is added after the reference number, a comma and a space, like so: [1, page 123]
Other possible alternatives would be [1 (page 123)] or [1 - page 123]
Anyone has an argument to favor any of these?

Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptApr 19 2016, 3:49 PM
In T100645#2218284, @lfschenone wrote:

The text added through the "note" parameter is added after the reference number, a comma and a space, like so: [1, page 123]
Other possible alternatives would be [1 (page 123)] or [1 - page 123]
Anyone has an argument to favor any of these?

Why not have a message like cite-note-format? In English it'd be $1, $2 but other languages or wikis could easily customize it.

Sophivorus added a comment.EditedAug 19 2016, 4:49 PM

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.

Sophivorus added a comment.EditedAug 21 2016, 5:04 PM

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.

Izno added a subscriber: Izno.EditedAug 22 2016, 12:40 PM

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.

Lea_WMDE renamed this task from [GTWL] Epic: Efficient way to refer to different pages of the same work when adding references to an article to Efficient way to refer to different pages of the same work when adding references to an article (#17).Aug 23 2016, 12:41 PM
Lea_WMDE updated the task description. (Show Details)
Qgil removed a subscriber: Qgil.Aug 25 2016, 9:39 AM
Sumit added a subscriber: Sumit.Sep 13 2016, 7:11 AM

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.

Lea_WMDE moved this task from Backlog to Prio2 on the TCB-Team (Oct2016-March2017) board.
jeblad added a subscriber: jeblad.Jan 20 2017, 1:55 PM

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.

jeblad added a comment.EditedJan 20 2017, 1:59 PM

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.

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.

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.

Kjetil added a subscriber: Kjetil.Mar 26 2017, 5:39 PM
Lea_WMDE removed Sophivorus as the assignee of this task.May 21 2017, 7:30 PM
Lea_WMDE updated the task description. (Show Details)