Page MenuHomePhabricator

Possibility to refine existing <ref>, e.g. reference individual pages in a book
Closed, InvalidPublic

Description

Current state

Actually used: https://de.wikipedia.org/wiki/N%C3%BCrnberg#Einzelnachweise_und_Anmerkungen, https://de.wikipedia.org/wiki/Suizid#Fu.C3.9Fnoten, …

Some text.<ref group="Adam2001">Page 1</ref>
More text.<ref group="Adam2001">Page 2</ref>

== References ==
* Scott Adam: I wrote a Book. London, 2001.
<references group="Adam2001" />

This is currently rendered as [Adam2001 1] and [Adam2001 2], and the references section as follows:

  • Scott Adam: I wrote a Book. London, 2001.
    1. ↑ Page 1
    2. ↑ Page 2

Key issues

  • No semantic connection between the full and refined references.
  • Can not reuse the full book as a reference.
  • Requires multiple <references group="…"> per book, which makes the references section hard to maintain.
  • Long prefixed superscripts in the article text. Authors generally do not like these.

Otherwise it's quite close to what authors want, I was told during Wikimania.

Proposal

Some text.<ref refines="Adam2001">Page 1</ref>
More text.<ref refines="Adam2001">Page 2</ref>

== References ==
<references>
<ref name="Adam2001">Scott Adam: I wrote a Book. London, 2001.</ref>
</references>

This will be rendered as [1a] and [1b], and the references section as follows (the upper case A is a limitation of Phabricator, should be lower case):

  1. ↑ Scott Adam: I wrote a Book. London, 2001.
    1. ↑ Page 1
    2. ↑ Page 2

Advantages

  • Main and refined references build a semantic group.
  • Flexible to use. The full reference can also be up in the text. The order of the full and refined references does not matter.
  • Does not interfere with existing attributes (group and name) and how they are used.
  • Meaningful error messages and maintenance categories in all cases that break the semantic meaning. Mostly when refines="…" refers to a removed reference. Also when refines is used with group or name, which should both be disallowed.

Key issues

  • How the superscripts ([1a] in my example) are rendered depends on the language and local project's consensus. Could also be [1.1], for example.
  • The way the references section is rendered (with the refines being indented one level) is fixed, which is usually what's wanted. But this means the Harvard style on English and other Wikipedias with two sections, one for abbreviated references to pages and an other one for the full descriptions of the books used (example: https://en.wikipedia.org/wiki/Virginia#References), is not possible.

Event Timeline

Restricted Application added subscribers: Zppix, Aklapper. · View Herald TranscriptJun 24 2016, 3:10 PM
Izno added a subscriber: Izno.EditedJun 24 2016, 3:16 PM

This is T138260: Solution for multiple refs varying only by page number. I think this is a slightly cleaner presentation of that bug, so I might suggest the other be closed as a duplicate, even though it's earlier.

That said, en.WP's solution is to have long-form references in a single group and short-form references with hyperlinks. See e.g. Template:Sfn.

WMDE-leszek added a comment.EditedJun 24 2016, 3:20 PM

I'd also consider this a possible solution to T15127. OTOH I am not sure if this should this be seen as a duplicate of T15127.

fbstj awarded a token.Jun 27 2016, 7:38 AM
Lea_WMDE moved this task from Incoming to Other on the TCB-Team board.Jun 29 2016, 9:50 AM
Anomie added a subscriber: Anomie.

I like this solution! I think I even proposed something like this years ago, although it might have been on an enwiki talk page. ;) The somewhat difficult part now is that you'll probably have to implement it twice, once in Cite and once in Parsoid.

BTW, what do you think if someone does something like this?

Some text.<ref name="Adam2001 page 1" refines="Adam2001">Page 1</ref>
Then something that refers to a direct quote.<ref refines="Adam2001 page 1">"Blah blah blah"</ref>

intending to get something like

  1. ↑ Scott Adam: I wrote a Book. London, 2001.
    1. ↑ Page 1
      1. ↑ "Blah blah blah"
    2. ↑ Page 2
This comment was removed by thiemowmde.
  • Refined references use the same name as the full reference, just with something like …-a, …-b and so on added. Specifying names for refined references isn't of much advantage, as far as I can see, but creates multiple issues including the one you just described.

This one is a bad idea. It's much more user friendly for the user to be able to do

Some text.<ref name="Adam2001 p.42" refines="Adam2001">Page 42</ref>
...
Some other text later in the article.<ref name="Adam2001 p.42" />

just like they do with any other reference than to have to guess what name you auto-generated for it.

As for omitting the group parameter, that's not going to work too well either:

<ref refines="Foo">What does this refine?</ref>

<references>
<ref name="Foo">This one?</ref>
</references>

<references group="Notes">
<ref name="Foo">Or this one?</ref>
</references>

I wonder why we are discussing this right now. Do you plan to implement this?

I thought you were, since you proposed this.

I will try to make this part of my proposal more clear:

The intention of the "all combinations of attributes including a refines should be disallowed" statement was to:

  • Reduce complexity as much as possible. The 2 existing attributes (name and group) can already be used in 4 different combinations (none, only one, or both). A third attribute will double this to 8, which I really, really want to avoid.
  • Make this as easy to use as possible. If there is a <ref refines="…">, that's it. There can't be anything else.
  • If it turns out that a certain combination of attributes is needed and wanted, this can be added later. It's much easier to allow something that was originally not allowed. The other way around is almost impossible without breaking stuff and making users angry.

However, you are outlining relevant edge cases in your comments above. I would expand my proposal as follows:

  • If the user wants to reuse a refined reference, simply copy and paste it. I expect these to be merged automatically.
  • If two references in two groups have the same name, they can not be refined. Names must be unique to be available for refinement.

If the user wants to reuse a refined reference, simply copy and paste it. I expect these to be merged automatically.

Which isn't how any other references work, and while it seems sensible for "Page 42", it's not really sensible if the refinement includes a quotation or the like.

If two references in two groups have the same name, they can not be refined. Names must be unique to be available for refinement.

That's a silly, unintuitive restriction. Someone adds a reference in a different group and suddenly other unrelated references on the page stop working because they happened to choose a name that was used in a different group.

Which isn't how any other references work […]

"Not working" how? It already works perfectly fine for users that prefer copy-pasting full references over reusing them by name. Refinements will not be reused as much as full references anyway. This is kind of the whole point of this feature.

That's a silly, unintuitive restriction. […]

Your opinion. I explained why I'm intentionally proposing these restrictions for now.

Izno added a comment.Sep 6 2016, 9:57 PM

The intention of the "all combinations of attributes including a refines should be disallowed" statement was to:

  • Reduce complexity as much as possible. The 2 existing attributes (name and group) can already be used in 4 different combinations (none, only one, or both). A third attribute will double this to 8, which I really, really want to avoid.

Going from 4 to 8 doesn't really look that scary to me as an editor, but maybe the programming side is complex. Taking as an assumption that there exists at least one other reference on the page with the same name as the target of the refinement (I think it's always an error if you're trying to refine a reference with a name that does not exist elsewhere in the page):

casenamegrouprefinesresult
1000reference grouped to the default
2100named reference grouped to the default
3010grouped reference
4110named and grouped reference
5001refines a case 2
6101refines a case 2, and is itself a case 2
7011refines a case 4
8111refines a case 4, and is itself a case 4

However, what does look scary to me as both an editor (it probably won't look pretty at the least given the use of columns on the various wikis) and as a system-thinker, would be refining a refinement. I expect anomie's case of "quotation and page" should probably be two separate refinements rather than 2 refined references refining a refined reference. (Aside: It's likely that, if two references were to refine like so, that they will appear near-enough in the article that they'll end up displaying next to each other in the list.) Basically, were we to take the path of coding for each of these 4 additional options, we should restrict refinement to only refining a completely unrefined statement. But we can ask Design if we think that's valuable and agree to take this path.

  • If it turns out that a certain combination of attributes is needed and wanted, this can be added later. It's much easier to allow something that was originally not allowed. The other way around is almost impossible without breaking stuff and making users angry.

I can almost assure you, we'll want all of the functionality expressed above. I can probably go look at the uses of {{sfn}} or {{harv}} or their sister templates to see if I can find already-extant desire for it... I would definitely suggest that re-use of a refining reference will be expected at a minimum, and grouping probably not much later.

If the user wants to reuse a refined reference, simply copy and paste it. I expect these to be merged automatically.

If naming a refinement is not available, what do you mean by "merge" automatically?

If two references in two groups have the same name, they can not be refined. Names must be unique to be available for refinement.

That's a silly, unintuitive restriction. Someone adds a reference in a different group and suddenly other unrelated references on the page stop working because they happened to choose a name that was used in a different group.

Generally agree with anomie here. Aside: I think this occurrence would be rare in practice if it were programmed like this, and changing names is not hard. Either way, you have to program for the case, if even just to emit an error, otherwise users will not know that the page broke.

Anomie added a comment.Sep 7 2016, 3:41 PM

If naming a refinement is not available, what do you mean by "merge" automatically?

Presumably that the editor would be expected to enter <ref refines="foo">Page 42</ref> everywhere the refined reference is needed and Cite would automagically collapse them into one because they have the same content. That, of course, fails if one instance gets changed to <ref refines="foo">page 42</ref> or <ref refines="foo">Page 42.</ref> and becomes massively inconvenient when the refinement is longer than just "Page X".

@Lea_WMDE and I talked about this and realized this "merging" behavior I'm proposing is a separate feature request that should be discussed independently from this ticket.

Currently, named references are only merged if they have the same name and (optionally) the same content. If two references have the same name but different content an error message appears. The proposed refines="…" feature should behave the same. They should only be merged if the have the same name and (optionally) the same content.

So as @Izno already pointed out it's indeed necessary to allow naming refined references (<ref refines="…" name="…">), to be able to reuse them. Same for groups (<ref refines="…" group="…">), to be able to refine a reference from a group. What must be disallowed is nesting and stacking (the attempt to refine a refined reference further).

Arlolra moved this task from Backlog to Non-Parsoid Tasks on the Parsoid board.Nov 24 2016, 2:25 AM
Kjetil added a subscriber: Kjetil.Mar 26 2017, 5:37 PM
Lea_WMDE closed this task as Invalid.May 21 2017, 7:39 PM

This task was the basis for an updated solution, which can be found in T151301: Implement "extends"-attribute for ref-tag