And I just ran into this as well.

#tag produces balanced tags:

{{#tag:section|content|begin=abcd}}

<section begin="abcd">content</section>

Where the required output is:

<section begin="abcd" />content<section end="abcd" />

I wasn't very clear about it in my original report, but my suggested way of solving this problem is for #tag to produce a single self-closing tag if "content" is empty, in your example. So, this:

{{#tag:section||begin=abcd}}

Would produce this:

<section begin="abcd" />

To get the required output for LST, you would have to do this:

{{#tag:section||begin=abcd}}content{{#tag:section||end=abcd}}

To get this:

<section begin="abcd" />content<section end="abcd" />

If the empty opening and closing tag behavior has no function, then maybe it
would be better to change it to produce a self closing tag by default
instead.

LST uses the singular tags so that you can use nested or overlapped sections. If normal pairs were used, then this would not be possible.

(In reply to comment #4)

LST uses the singular tags so that you can use nested or overlapped sections.
If normal pairs were used, then this would not be possible.

Does that make this request WONTFIX or INVALID?

Does that make this request WONTFIX or INVALID?

Not in my opinion. LST is limited if we can't use wikimarkup. Perhaps the simplest solution would be to add a switch to #tag for singular output.

(In reply to comment #5)

(In reply to comment #4)

LST uses the singular tags so that you can use nested or overlapped sections.
If normal pairs were used, then this would not be possible.

Does that make this request WONTFIX or INVALID?

Neither. Comment #4 doesn't add any new information that hasn't already been said, it's basically just a more clear restatement of the quoted text. LST's self-closing tags are nothing special, and #tag should just automatically produce a self-closing tag when there's no content. When that is done, this bug will be resolved as FIXED.

dovijacobs wrote:

Hi, a very basic and problematic limitation just came up regarding this: Wikisource formats poetic texts using <poem>...</poem> tags. Apparently because of this bug, sections cannot be transcluded from within poems, even if the poem uses the {{#tag:poem| form.

Please see the discussion here:
http://en.wikisource.org/wiki/Wikisource:Scriptorium#Transclusion_of_text_from_within_.22poem.22_tags

Is this fixable?

Correct me if I'm wrong, but it looks like you're trying to use #tag to workaround the limitations of <poem>...</poem>, and to get that to work, you need #tag to produce independent opening and closing tags, on command. That is roughly what Gadget850 was proposing in comment #6, but your use case requires #tag to be able to explicitly produce ONLY an opening tag and ONLY a closing tag, when called to do so. In that case, then we need 2 new features in #tag:

1. Produce a self-closing tag automatically if there is no content.
2. Produce ONLY an opening tag or ONLY a closing tag, when(?) specified.

1 above does not require any changes to the syntax of #tag, but 2 above does require some sort of new syntax. How would you like to be able to specify that #tag should produce an opening or closing tag? Maybe some sort of keyword parameters, like "open", "close", and maybe also "self"?

dovijacobs wrote:

Hi, yes I was trying to use #tag as a workaround, as suggested in the Wikisource discussion, though not being a programmer I don't understand what the difference is and why it might have worked (it didn't).

I wish I understood the issue in #2 better to be able to understand what you are asking. If the idea is a special paramater for #tag specifying that it will allow ("produce"?) "section begin" and "section end" tags, then maybe the syntax could be "sections-yes" or something like that.

Have I understood your question (and the issue) correctly?

#1 will produce the section begin and section end tags that Labeled Section Transclusion (LST) requires. The fact that <poem>...</poem> does not cooperate with LST is a problem within the poem tags. The workaround that people were suggesting is to use #tag to produce the poem tags. The reason why that might "work around" the problem is because it would change the order in which the code is parsed. Then, LST would be given an opportunity to do its thing before the poem tag screws it up.

I think.

#tag itself is kind of a workaround, so we're doing workarounds to work around our workarounds. If we can get #tag to produced the self-closing tags that LST requires, that might be enough to solve your issue. I'm not sure I've understood your exact problem completely, but since that's what this bug report is about, I think we should get #tag to work with LST, then re-examine what needs to be done in your circumstance, if anything. It might work out of the box for you, once LST works.

In the meantime, there might be other, simpler workarounds for your problem with the poem tags, but that's another subject, and I'm sure I'm misunderstanding something about it. Try using #var to make your opening and closing tags, and see what happens. Before I run out of time for this, try:

{{#var: poem1 }}
<section begin="stupid poem" />
I saw a bird fall from the sky.
His wings were broke, he could not fly.
I coaxed him near, with bits of bread.
Then I squashed his little head.
<section end="stupid poem" />
{{#var: poem2 }}

{{#lst: Bug 37256 | stupid poem }}

I don't know if that above will work, but maybe.

dovijacobs wrote:

"If we can get #tag to produced the self-closing tags that LST
requires, that might be enough to solve your issue."

That sounds logical. Can it be implemented? It would be great if during tests #tag:poem could be tested too.

Regarding your #var: suggestion, it works! Just need a way to hide the code on a wikipage:

User:Dovi/Experiments#Yet_another_experiment

dovijacobs wrote:

Wait, sorry, I take that back: The poem within the #var tags doesn't format in new lines, which is the function of the <poem> tags.

Which wiki page is your experiment on? I like to document workarounds in bug reports once I have them pinned down, because I know how much people appreciate them. It gives people confidence that WMF and volunteers are aware of the problem, and care about making sure it causes as little disruption as possible. Until then, we should take the discussion elsewhere to flesh out exactly what the workaround should be.

No guarantees, though. I'm tight for time, but I suspect I'll be able to quickly give you some alternatives that will work for you.

dovijacobs wrote:

Hi, and thanks for your good will and attention to the problem. The link to the wikipage experiment (as above) is here:

http://en.wikisource.org/wiki/User:Dovi/Experiments

I'm puzzled... Does:

{{#tag:section||begin=abcd}}content{{#tag:section||end=abcd}}

work as expected or not? Because:

{{#tag:references||group=abcd}}

*does* work as expected. In which case, this bug would be invalid

Last I checked LST's section tags don't even work when transcluded through templates. I'm pretty sure LST is a hack that involves string manipulation of page contents. I seriously doubt that {{#tag will EVER work for it even if it does output self-closing tags. So I'd say this is WONTFIX/INVALID.

(In reply to comment #16)

I'm puzzled... Does:

{{#tag:section||begin=abcd}}content{{#tag:section||end=abcd}}

work as expected or not? Because:

{{#tag:references||group=abcd}}

*does* work as expected. In which case, this bug would be invalid

No. As discussed, #tag essentially creates tag pairs <poem>...</poem> where LST uses singular tags like <section begin="abcd" />content<section end="abcd" />.

See Template:Section/testcases and Template:Section/testcases2 on enwiki.

(In reply to comment #9)

Correct me if I'm wrong, but it looks like you're trying to use #tag to
workaround the limitations of <poem>...</poem>, and to get that to work, you
need #tag to produce independent opening and closing tags, on command. That
is
roughly what Gadget850 was proposing in comment #6, but your use case
requires
#tag to be able to explicitly produce ONLY an opening tag and ONLY a closing
tag, when called to do so. In that case, then we need 2 new features in #tag:

1. Produce a self-closing tag automatically if there is no content.
2. Produce ONLY an opening tag or ONLY a closing tag, when(?) specified.

1 above does not require any changes to the syntax of #tag, but 2 above does
require some sort of new syntax. How would you like to be able to specify
that
#tag should produce an opening or closing tag? Maybe some sort of keyword
parameters, like "open", "close", and maybe also "self"?

This has nothing to do with <poem>. If you look at the markup, it is using:
{{#tag:section||begin=nineteen}}part nineteen{{#tag:section||end=nineteen}}

The problem is with #tag and <section>.

Right, I understand that this issue is specific to #tag. <poem> just happens to be Dovi's use case. My proposed features cover any use case I can think of, with opening, closing, and self-closing tags. #tag is a general purpose tool, so if new features are added, it's wise to ensure they well-thought out, and can handle the common use cases where #tag is most needed.

(In reply to comment #17)

Last I checked LST's section tags don't even work when transcluded through
templates. I'm pretty sure LST is a hack that involves string manipulation of
page contents. I seriously doubt that {{#tag will EVER work for it even if it
does output self-closing tags. So I'd say this is WONTFIX/INVALID.

Yes, according to the extension page, LST can transclude ordinary sections, but it cannot itself be transcluded:

https://www.mediawiki.org/wiki/Extension:Labeled_Section_Transclusion#Limitations

Fortunately, all of the common use cases that we have discussed do not require transclusion. For your concerns about the technical hurdles involved in resolving this bug as FIXED, I think we should defer to the extension maintainer. However, I think you're saying that LST performs it's work after the MediaWiki parser is done, which you conclude means that the <section /> tags would output literally for the web browser, instead of being interpreted by the MW parser. More clearly, the procedure would like this:

1. #tag expanded by MW parser into <section /> tags.
2. <section /> tags expanded by LST.

If the above is correct, then I suspect that order of operations will not be a problem, assuming you're right (and I'm paraphrasing your comment correctly) that LST is doing string replacement after the MediaWiki parser has finished its work. If those 2 steps above were reversed, then we would have a more difficult problem, but certainly nothing that's impossible.

I feel like I've misunderstood something.

Yes, according to the extension page, LST can transclude ordinary sections, but it cannot itself be transcluded:

https://www.mediawiki.org/wiki/Extension: Labeled_Section_Transclusion#Limitations

That is a circular argument. From that page:

"Section tags cannot themselves be transcluded in order to work on other pages... The #tag magic word does not work with section tags. #tag produces balanced tags, while the section tags uses singular tags. See bug 37256."

I'm not sure why this is so difficult to understand.

#tag currently produces markup with an open and close tag of the form

<tag>content</tag>

LST requires markup using two singular tags of the form:

<section />content<section />

Gadget850, I understand your frustration with this issue, but I don't think anyone is having difficulty understanding what isn't working as expected. What Daniel Friesen was trying to say is that simply having #tag output self-closing <section /> tags for consumption by LST may not be enough to get the result we want, due to the way LST is implemented. I haven't studied LST's implementation details, so I cannot refute that. The maintainer of LST probably should be consulted.

This is easy to fix, as long as a consesus of the exact requirement can be reached (is it still {{#tag:name||arg1=value1|close}}?).

(In reply to comment #24)

This is easy to fix, as long as a consesus of the exact requirement can be
reached (is it still {{#tag:name||arg1=value1|close}}?).

Besides the possibility that this won't even fix the LST issue. Bugs which require consensus on something like the syntax to use for something are not considered "easy" as far as the easy tag goes.

(In reply to comment #24)

This is easy to fix, as long as a consesus of the exact requirement can be
reached (is it still {{#tag:name||arg1=value1|close}}?).

I agree with that. It may also be sensible to have it produce a self-closing tag when there is no content, like this:

{{#tag:section||arg1=value1}}

That was one possibility I proposed initially, but upon further consideration, it is possible that self-closing tags may not always be desired when the content is empty. Maybe there could be some case where JavaScript is intended to insert content in some empty tag pairs, or something like that. Perhaps it's best to just keep it simple and require an explicit "close" parameter when a self-closing tag is desired. It looks to me that the syntax consensus is established for a "close" parameter to indicate when a self-closing tag should be output, like this:

{{#tag:name||arg1=value1|close}}

There should probably be an error if the "close" parameter is specified and the content is not empty, like this:

{{#tag:name|This content should not be here|arg1=value1|close}}

I also agree with Daniel that this is not an easy task that would be appropriate for introductory programming exercises for pre-university students. Right now, the only person qualified to fix this immediately is probably the current maintainer, and even that isn't certain. It's likely that the code behind #tag will need to be rewritten to make it work as we expect it to. That would mean nobody is an expert on it yet.

This issue was impacting us on our private wiki. I had my colleague (who has a lot more experience editing MediaWiki than I do) try and fix the bug. He said it required a 1 character change to the #tag functionality to make it create self-closed tags when the content is empty, so the problem with #tag seems to be a very easy bug to fix.

However after doing that change, it still didn't function as we wanted.

I suspect what is happening, is that the labelled section transclusion extension will parse the target page for the begin and end tags, and then all wiki text within those tags will be fully parsed and rendered, so all templates will be expanded etc.

But if you put the begin and end tags *inside* a template and include that template on page A, when the extension parses the page looking for the begin and end tags, it can't find any and so simply does nothing. It seems it would need to fully-parse page A, expanding all templates, and then look for the begin/end tags and transclude that content. This would seem to be an expensive operation, so would best be served by a new function, rather than #lst or #lstx, it could be #lstvt for "labelled section transclusion via template". That's a pretty crummy name, but it gets the idea across that for performance reasons I think this would need to be an entirely new function.

In T39256#1390633, @Gregoryhltnz wrote:

It seems it would need to fully-parse page A, expanding all templates, and then look for the begin/end tags and transclude that content. This would seem to be an expensive operation, so would best be served by a new function, rather than #lst or #lstx, it could be #lstvt for "labelled section transclusion via template". That's a pretty crummy name, but it gets the idea across that for performance reasons I think this would need to be an entirely new function.

Alternatively, this could be achieved by having a new class of templates that are parsed (say, 1 level only) before LST looks for <section>'s. Does anyone know a good reference to learn what is parsed in which order, and at which point in the process the page is read by some of the common extensions?

I requested the missing section tag transclusion feature at https://phabricator.wikimedia.org/T179482