Feature summary (what you would like to be able to do and where):

Introduce two new attributes for page transclusion within the ProofreadPage extension (leveraging or extending Labelled Section Transclusion semantics):

• sections: allows inclusion of multiple named sections from a Page namespace page, in a defined order.
• nosection: allows explicit exclusion of one or more named sections from a transclusion.

These extend the current fromsection / tosection /onlysection model, which is limited to
single sequence, or (in respect of onlysection) single-section inclusion.

Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):

This feature is prompted by the layout here:-
https://en.wikisource.org/wiki/The_Septuagint_Version_of_the_Old_Testament/Volume_2

The current layout is built up as a "Jigsaw" construction which doesn't work as well as intended as each Pages call wraps the incomplete table portions concerned, and it is not possible (currently) to directly exclude a specfic section (as opposed to only including specific (singular named) sections.

It would be clearer to have a situation where the "pages" tag only includes specific sections

{{#tag:pages||index=Example.djvu|from=2,3|sections=ToCheader, Vol2ToC,TOCfooter}}

Benefits (why should this be implemented?):

Current workflows in ProofreadPage rely on:

• onlysection: includes a single labelled section (albiet from each page)
• fromsection/tosection: includes a single contiguous sequence.

Limitations:

• No native way to include multiple discrete sections, as opposed to a contiguous sequence in a single transclusion call.
• Editors must duplicate transclusion calls or refactor content into artificial section groupings, increasing maintenance overhead and risk of inconsistency.

This is particularly restrictive in:

• Composite works (e.g. anthologies, parliamentary proceedings, multi-part documents), and composite table of contents.
• Situations where a table of contents may need to be split by volume, even though it appears in print as a complete table.
• Pages where logical grouping differs from physical pagination.
• Situations requiring curated excerpts across non-contiguous sections.

Implementing nosection, or sections semantics, would provide a clearer syntax to indicate a specfic non contiguous sequence, by dropping out specific named sections.

It also :

• Improves editorial flexibility without requiring source restructuring.
• Aligns ProofreadPage workflows more closely with LST capabilities.
• Enables cleaner separation of content and apparatus in digitised texts.

Proposed Solution

1. sections Attribute (Multi-Inclusion)

A new parameter accepting a list of section names:

{{#Page:Example.djvu||from=5 to11|sections=Abstract, Intro,Conclusion}}

Behaviour:

• Transcludes the specified sections in the order listed.
• Order is determined by the parameter list, (but ideally respecting document order.)
• Missing sections are ignored (optionally emit tracking category or warning).
• Duplicate names are ignored or de-duplicated.

2. nosections Attribute (Multi-Exclusion)

A new parameter accepting a list of section names to exclude:

{{#tag:Pages||index=Example.djvu include 11,12|nosections=Footnotes,References}}

Behaviour:

• Transcludes all content except the specified sections.
• Useful for stripping apparatus (notes, marginalia, indices). or removing 'table' ribbons only applicable to paged content. ---

Interaction with Existing Parameters

Syntax Notes

• Section names follow LST conventions (<section begin="name" /> ... <section end="name" />)
• Separator: comma (,), with optional whitespace trimming.
• Future-proofing: consider pipe (|) or newline-separated lists if parsing complexity arises.

Backward Compatibility

• No breaking changes to existing templates or transclusion behaviour.
• Existing onlysection remains fully supported.
• New parameters are opt-in.

Implementation Considerations

• Likely implemented within ProofreadPage transclusion pipeline, delegating parsing to LST where possible.
• Requires:
  • Parsing and normalisation of section lists.
  • Ordered assembly of multiple section fragments.
  • Efficient handling to avoid repeated parse passes (performance concern on large works).
• Tracking categories for:
  • Missing sections
  • Duplicate section references

Open Questions

• Should missing sections produce parser warnings, tracking categories, (or hook into the existing Linter structure), or be silent?
• Should ordering override document order unconditionally, or be configurable?
• Is there value in supporting wildcard or pattern-based section selection?
• Should nested or overlapping sections be explicitly handled or left undefined?