Page MenuHomePhabricator

Multiple problems with refs inside <references>...</references> blocks
Closed, InvalidPublic

Description

Author: cyp

1

1.1: Issue

{{#tag:ref}}s in a <references> block supposedly cannot themselves contain _unnamed_ <ref>s (see also #2, below)

1.2: Test case

===Article text===
Lorem ipsum<ref name="expl_A" group="n" />
===Explanatory notes section===
<references group="n">
{{#tag:ref
|AAAA <ref>Ref #1</ref>
|group="n"|name="expl_A"}}
</references>
===References section===
<references />

1.3 Test case result

Failure. For one, it will generate a <ref> tag defined in <references> has no name attribute. message. Obviously, the <ref> here does not need a name. Secondly, the <ref> will not be dealt with. Third, just adding a name does not solve the problem. See #2, below.

2

2.1: Issue

For a _named_ <ref> (compare case #1) inside a {{#tag:ref}} inside a <references> block, the ref handler will carp and
ignore the ref.

2.2: Test case

===Article text===
Lorem ipsum<ref name="expl_A" group="n" />
===Explanatory notes section===
<references group="n">
{{#tag:ref
|AAAA <ref name="ref1">Ref #1</ref>
|group="n"|name="expl_A"}}
</references>
===References section===
<references />

2.3 Test case result

Failure. Error message <ref> tag with name "ref1" defined in <references> is not used in prior text. The <ref> is not dealt with.

3

3.1: Issue

ref handler will carp and ignore cross-refs to an existing, predefined, named <ref>s (compare case #1/#2)

3.2: Test case

===Article text===
Lorem ipsum<ref name="expl_A" group="n" />
Carpe diem<ref name="ref1">Ref #1</ref>
===Explanatory notes section===
<references group="n">
{{#tag:ref
|AAAA <ref name="ref1" />
|group="n"|name="expl_A"}}
</references>
===References section===
<references />

3.3 Test case result

Failure. Error message <ref> tag with name "ref1" defined in <references> is not used in prior text. The <ref> is not dealt with.

6

6.1: Issue

Ungraceful handling of refs that have no backlinks

6.2 Test case

===Article text===
Some text (no refs)
===References section===
<references>
{{#tag:ref
|This is a ref without backlinks
|name="some_name"}}
</references>

6.3 Test case result

The ref handler will emit an "error" that <ref> tag with name "expl_B" defined in <references> is not used in prior text. This is unnecessary bitchiness that second guesses the editor. What the ref handler really ought to do is print it without backlinks (in a separate <ul>). If the name has a typo, editors will figure it out. [the same should be done for <ref>s in a <references> block that have no name] Editors ought not to be screamed at.

Notes

  • These problems are all limited to tags inside <references>...</references>. They don't apply outside the <references> block.
  • The ref handler is much too emphatic. It probably needs to deal with input gracefully, and not shake its fist at editors so much. Please.

Details

Reference
bz22635

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 11:06 PM
bzimport added a project: Cite.
bzimport set Reference to bz22635.
bzimport added a subscriber: Unknown Object (MLST).

This looks like the same issue reported in Bug 20707.

All references defined in the reference list must be invoked in the content, else an error message will show "Cite error: <ref> tag with name "#1" defined in <references> is not used in prior text". But, the first undefined reference shows the message "Cite error: <ref> tag defined in <references> has group attribute "" which does not appear in prior text", even if there is no group defined.

http://en.wikipedia.org/wiki/Help:Cite_errors/Cite_error_references_missing_key

wiki wrote:

This looks like an ARRAY BASE issue to me. One piece of code is using an ARRAY BASE OF ZERO and the other is using a base of ONE. I'm not a good enough programmer to find the problem, but hopefully this will give someone a clue where to look.

matmarex set Security to None.

1, 2, and 3 are fixed by 944b24542827f827cdfb8646f1c2e87aeb929b65 / https://gerrit.wikimedia.org/r/#/c/181112/. The change will be deployed to all wikis on May 19/20, with MW 1.26wmf6, according to https://www.mediawiki.org/wiki/MediaWiki_1.26/Roadmap. You can test the new behavior on http://en.wikipedia.beta.wmflabs.org/ already.

4, 5 and 7 do not appear to be fixed yet. Somebody should split them into separate bugs.

6 is the expected behavior.

Split items 4, 5, 7, and a new bug identified at en.wp:Help talk:CS1 to subtasks.

Closing since I created those other tasks, where there's not a particular need for this as a tracking bug.