Page MenuHomePhabricator

More edge case handling for "extends" parameter
Closed, ResolvedPublic5 Estimate Story Points

Description

There are two errors that might occur. In both cases an error message should be shown.

  1. Extends points to a reference, that cannot be found (e.g. does not exist, not yet defined).
  2. Extending more than one level.

Background
The wish to improve the referencing of multiple parts of the same source was part of the German-speaking community's technical wishlist in 2013, 2015 and of the international technical wishlist in 2015. For more info, see T100645.

Details

Related Gerrit Patches:
mediawiki/extensions/Cite : masterTest for numeric `extends` attribute

Event Timeline

Tobi_WMDE_SW triaged this task as Medium priority.Nov 22 2016, 10:44 AM
Tobi_WMDE_SW created this task.
Restricted Application added a project: Design. · View Herald TranscriptNov 22 2016, 11:44 AM
Jan_Dittrich added a subscriber: Jan_Dittrich.EditedNov 22 2016, 11:45 AM

Is there any mechanism to show error messages? As far as I am concerned, if you do an edit and save it you are directed to the view of the rendered text again.
If you leave any bracket open or whatever else, I assume that the wikitext will just be saved now. (CC @Tobi_WMDE_SW , @thiemowmde )

Volker_E moved this task from Incoming to WMDE on the Design board.Jan 5 2017, 5:57 PM
Lea_WMDE renamed this task from Error handling for "refines" parameter to Error handling for "extends" parameter.May 21 2017, 7:33 PM
Lea_WMDE updated the task description. (Show Details)
petr.matas added a subscriber: petr.matas.EditedJun 23 2017, 11:22 AM

Is there any mechanism to show error messages? As far as I am concerned, if you do an edit and save it you are directed to the view of the rendered text again.

There is, look:

But beware of T168719: On enwp, Cite error messages are not shown in User namespace if UI language is English (due to custom on wiki code).

@Lea_WMDE shall we build this on the existing solution as shown above? Or did you have something else in mind with "Error Message"?

Addshore removed a subscriber: Addshore.Apr 3 2018, 9:03 AM
awight set the point value for this task to 5.Nov 20 2019, 1:27 PM

Change 553040 had a related patch set uploaded (by Awight; owner: Awight):
[mediawiki/extensions/Cite@master] Test for numeric attributes earlier

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

Change 553050 had a related patch set uploaded (by Awight; owner: Awight):
[mediawiki/extensions/Cite@master] Test for numeric extends attribute

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

Change 553050 merged by jenkins-bot:
[mediawiki/extensions/Cite@master] Test for numeric extends attribute

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

awight added a subscriber: awight.Dec 5 2019, 1:20 PM

I merged an edge case patch yesterday, which I now believe does the wrong thing. My notes from review:

I realized that this will cause mismatched numbering, and is probably wrong conceptually as well.
For example, the attempted sequence "[1] [1.1] [1.1.1] [1.1.2] [2]" will, with or without this patch, result in footnote markers "[1] [1.1] [1.2] [1.3] [2]", and matching footnote body numbering. However, after the patch the footnote markers will be the same but the body will have "[1] [1.1] [2] [3] [4]", which no longer matches the text numbering.
Also, conceptually [1.1.1] was intended to be a grandchild of [1], so it seems that leaving it indented below [1] and as a sibling of [1.1] is better than kicking it all the way out to [2].
Now I think it would be ideal to rewrite the "extends" to point to the grandparent, but I'm not sure this is possible or simple: e.g. circular extends between two or more refs.

awight assigned this task to thiemowmde.Dec 9 2019, 10:04 AM

I think we should forbid extends inside the references tag.

  • On a technical level, see parser test "Extends <ref> defined in <references> called with #tag", this case cannot be detected early enough to do footnote numbering correctly.
  • Regarding content, it feels wrong to use extends outside of the content, since the point is that we've made the ref short and sweet. Using an empty, named ref defined in references is insane.
awight renamed this task from Error handling for "extends" parameter to More edge case handling for "extends" parameter.Dec 9 2019, 12:42 PM
Izno added a subscriber: Izno.Dec 10 2019, 1:46 AM

I think we should forbid extends inside the references tag.

I'd like to provide feedback, but I'm not sure entirely what you're suggesting should be forbidden. (Not having the specific code in front of me as a not-quite-technical contributor.)

I think we should forbid extends inside the references tag.

I'd like to provide feedback, but I'm not sure entirely what you're suggesting should be forbidden. (Not having the specific code in front of me as a not-quite-technical contributor.)

Thank you for the nudge to explain myself! Here's an example snippet for this case,

<ref name="child" />

<references>
<ref name="parent">All about a book.</ref>
<ref name="child" extends="parent">page 10</ref>
</references>

The difficulty is that we cannot know that <ref name="child" /> is a subreference and should receive a footnote marker like "[1.1]", without major changes such as running through the article text twice.

Izno added a comment.EditedDec 10 2019, 10:01 PM

Okay, that's what I thought.

As a minimum viable product, it's probably okay if list-defined referencing (LDR) does not fully support book referencing.

As a fully-functional product, I'd guess the community will request/require support here rather than an error message. That's because a consistent style is seen to be important, and LDR is generally considered to be its own style (or part of it, anyway) covered under the importance of a consistent style. (See also CITEVAR and other material in that subsection's parent section.)

We need to split this off to a new, separate ticket. @awight, I guess you are most knowledgeable about this edge case at the moment. Can you create such a ticket so we can close this one here?

thiemowmde closed this task as Resolved.Dec 11 2019, 12:20 PM
thiemowmde reopened this task as Open.Dec 11 2019, 12:34 PM
thiemowmde moved this task from Sprint Backlog to Demo on the WMDE-QWERTY-Sprint-2019-12-11 board.