Hmm. So essentially list-defined references, but with the list of named references defined on a separate wikipage rather than at the end of the same wikipage?

PS: this probably isn't relevant to ProofreadPage or LabeledSectionTransclusion projects (just Cite and Wikisource).

The current authority reference template uses named sections, but LDR looks to be partially like what I had in mind.

Bear in mind that on Wikisoruce you are also going to have references that could have "follow=" in the nominal set of "list" pages. I don't think a follow= for Reflist currently exists, and if implemented is going to need a LOT of parser tests to checks for mismatched /misnested REF name= and REFfollow= tags.....

If you are just focusing on the main namespace output this can be done now. There are just consequences [downsides or errors to manage.]

Solution 1

• <ref name="..."> tags normally in the endnotes in the Page: ns, wrapped in <references></references> (will need open close treatment if multi-page)
• add <ref name="..." /> tags appropriately, on the respective Page:

1. consequence: Page: ns—error messages on the individual pages
2. no consequence transclusion (does require matching endnotes transcluded, maybe multipage management)

Solution 2

• <ref name="..."> tags normally in the endnotes in the Page: ns wrapped in <references></references> (will need open close treatment if multi-page)
• add <ref name="..." /> tags appropriately, on the respective Page: but wrap them in <includeonly>

1. consequence: Page: ns—no ref mark superscripts
2. no consequence: Main ns transclusion, place your <references /> (does require matching endnotes transcluded)

Solution 3

• <ref name="..."> tags normally in the endnotes in the Page: ns wrapped in <references></references> (will need open close treatment if multi-page)
• add <ref name="..." /> tags within a template that has a #switch based on Page: ns show the superscript number, and other ns normal <ref>

1. consequence: Page: ns—ref mark superscripts, though no active links (this replicates the work as viewed)
2. no consequence: Main ns transclusion, place your <references /> (does require matching endnotes transcluded)

Solution 4

• Proofread and format endnotes
• Put the endnotes as named footnotes in Page: ns

1. consequence: Page: ns—body of work is normal, <references/> need to be managed in footer and wrapped in <includeonly> or not as preferred
2. consequence: Main ns— (UNTESTED umm thinking out loud, the <references> should all transclude well, with the appropriate multiple a, b, c, tags concatenating if refs added properly)

Solution 5

Use of {{authority reference}} as described (though noting I never bothered to set it up for follow =

1. consequence: Page: ns active hyperlinks to endnote in Page: ns (note: this is above and beyond work as viewed)
2. no consequence: Main ns transclusion (does NOT require endnotes transcluded)

Comment about solutions

I designed for solution 5 to get around error messages, AND that for biographical works where we can have multiple biographical entries per page, that I needed to pull the refs rather than rely on endnotes (see [[s:en:Template:IrishBio ref]] and an example of its use at https://en.wikisource.org/wiki/A_Compendium_of_Irish_Biography/Ailbe,_Saint

@ShakespeareFan00 if you need an immediate solution for your work at enWS and formatting endnotes with {{authority ref}} is problematic then, I would recommend solution 3, as that it is pretty easy to develop and can be done working from front to back without specific knowledge of the endnotes themselves. If the work is in chapters, and the endnotes are all together for a work, it will take some section tweaking and section transclusion, though that should be rudimentary as long as there is no repeat numbering.

Comment about situation

The request to inhale through citation itself is going to need the interconnectivity between ref and references, it is just that the system has challenges due to how it is primarily designed for Wikipedias, and the expectation that they are all present on the page, and that they are all <span> related.

We saw consequences of changes recently where the means that Wikisources use this differently (Page: nss) and have different display requirements to WPs.

To me this request is adding complexity to an already muddled extension, and one that has little progress in its development. I could well understand that this would just developers going further away than closer to developing solutions. To me it seems that Wikisources need separate hooks within the extension for its Page: ns displays, which would mean an interconnection to the knowledge of whether the page of use is an environment of ProofreadPage (not a standard ns:dd).

Page: namespace logic is simply different, and testcases need to be developed for purposefully absent, or accidentally missing. Similarly checking the error logic so when an error is made in the Page: namespace and that flows through to main ns, that one can identify the respective Page: ns page for fixing. For example, a broken follow = can be problematic to find.

Typically WS main ns presentations are standard output as it is just concatenated data.

I'm pretty sure this is ancient T18371: Allow reference definitions to be included from other pages?

In T244346#6879277, @Izno wrote:

I'm pretty sure this is ancient T18371: Allow reference definitions to be included from other pages?

Do folks in this ticket agree?

In T244346#7471013, @Aklapper wrote:

In T244346#6879277, @Izno wrote:

I'm pretty sure this is ancient T18371: Allow reference definitions to be included from other pages?

Do folks in this ticket agree?

Possibly. If you are going to merge, please merge here than the other way.