Page MenuHomePhabricator

Within <ref> the <noinclude> and <includeonly> tags are ignored, problematic when transcluded
Open, LowPublic

Description

This is a continuation of other non-nice interactive aspects of use of <ref> tag and other mediawiki tags.

Broken when transcluded
<ref>text text text text <noinclude> more text more text more</noinclude></ref>
https://en.wikisource.org/w/index.php?title=Page:The_study_of_the_Anglo-Norman.djvu/29&oldid=6370222
<ref>text text text text <includeonly>less text less text less </includeonly></ref>
example https://en.wikisource.org/w/index.php?title=Page:The_study_of_the_Anglo-Norman.djvu/30&oldid=6370229

with the transcluded version mimicking the non-transcluded version.

Both these are resolved with
{{#tag:ref|<noinclude></noinclude><includeonly></includeonly> }}

Two pages transcluded can be seen (and tested) at https://en.wikisource.org/w/index.php?title=Wikisource:Sandbox&oldid=6370282

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 3 2016, 10:04 AM
Billinghurst renamed this task from Within <ref> the <noinclude> and <includeonly> tags are ignored to Within <ref> the <noinclude> and <includeonly> tags are ignored, problematic when transcluded.Aug 3 2016, 10:05 AM
Izno added a subscriber: Izno.Aug 3 2016, 11:25 AM

This seems like a pathological edge case and can't personally understand what the desire is there.

Definitely an edge case, but it is one that should be queued for Cite addressing as we have numbers of situations of mediawiki tags inside <ref> that are hosed. Plus that is the point of phabricator.

You may not understand why it needs to be done that way, but is that pertinent? If you are going to present a better solution then do so, otherwise maybe hold judgmental commentary where you don't understand.

For the portrayed case the author of the original work had footnotes across multiple pages along with a split title of the work. It is the neatest (or least ugly) way to code it, so that it transcludes properly and it retains the character of the printed page when not transcluded.

Izno added a comment.EditedAug 3 2016, 2:08 PM

Definitely an edge case, but it is one that should be queued for Cite addressing as we have numbers of situations of mediawiki tags inside <ref> that are hosed. Plus that is the point of phabricator.

I was commenting on my perceived priority, for whenever someone comes along to triage.

You may not understand why it needs to be done that way, but is that pertinent? If you are going to present a better solution then do so, otherwise maybe hold judgmental commentary where you don't understand.

I don't see this as worth responding to.

For the portrayed case the author of the original work had footnotes across multiple pages along with a split title of the work. It is the neatest (or least ugly) way to code it, so that it transcludes properly and it retains the character of the printed page when not transcluded.

Less ugly would be to use a template with the text-to-be-transcluded. Still less ugly would be to repeat the text as necessary. Regardless, if you think this is a common use case, there is yet another solution: design a template to wrap the tag:ref cases, as with Template:Efn on en.wp. And these are besides the case which you have illuminated always works. There are workarounds aplenty, so yet another reason to lower the priority for the triaging person.

Trying to do tricks with templates to circumvent an underlying problem, especially one of problems in a similar series, is not a solution, just a complicating factor. Putting in replication of slabs of text is ugly, and adds to the difficulty in proofreading. It also increases the opportunity for errors especially when you can only check for errors once you have transcluded among multiple pages as wikisource requires in its presentation.

In your schema, I would need to have something like
<noinclude><ref name=$1>$2</ref></noinclude><includeonly><ref name=$1>$3</ref></includeonly>
as we are talking about continuing references, we usually have long text passages so that can be a lot of text with slight differences. In the example that I gave you were then requiring that on two different pages in two different way with wikilinks. That is not good transcription practice.

If we can fix the scenario so that we can have working <tags> inside a <ref>erence tag, that becomes a simple solution.

Izno moved this task from Unsorted backlog to Defect backlog on the Cite board.Aug 22 2016, 3:52 PM
Izno triaged this task as Low priority.Aug 22 2016, 5:03 PM
Izno removed subscribers: wikibugs-l-list, bzimport.
Billinghurst added a comment.EditedFeb 25 2017, 12:02 PM

To add an extra item of difficulty, if a reference has a table within it, it is decidedly better to use <ref> tags otherwise there is the ugliness of trying to use {{!}} in multiple places (even for simple tables this is butt ugly). So the ability to use {{#tag:}} is obviated.

Example of extra gumph that needs to be added
https://en.wikisource.org/w/index.php?title=Page:Considerations_on_the_state_of_Ireland.pdf/6&diff=6676916&oldid=6676821

and it doesn't work!

https://en.wikisource.org/wiki/Considerations_on_the_state_of_Ireland#cite_ref-2

To note that in the end I have managed the issue by use of html syntax of the body of the table and having to <noinclude> table open and close.

This was the way to get around the cite interplay with the second reference [1] to join (follow=) to the first

[1] https://en.wikisource.org/w/index.php?title=Page:Considerations_on_the_state_of_Ireland.pdf/7

Would this also be related to the issue that means {[nop}}'s have to be inserted to get multi paragraph formatted references?

Would this also be related to the issue that means {[nop}}'s have to be inserted to get multi paragraph formatted references?

Probably not, more likely related to the similar issue with <blockquote> where with two paragraphs the closing </blockquote> tag needs to be on a new line to maintain separation, otherwise it runs them together. With ref issues, I don't use a tag just use a standard <p> or <br />.