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 )

In T151305#2813932, @Jan_Dittrich wrote:

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"?

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

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.

Merged patch should have been tagged here: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Cite/+/555901/

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.

In T151305#5723309, @awight wrote:

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

In T151305#5726751, @Izno wrote:

In T151305#5723309, @awight wrote:

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.

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?