Possibly related: T114454 -- "handlebars" style templates have a context object they pass down through nested invocations.

In the request thread, I mentioned the alternative of letting templates and modules access the full "tree" of headings they are nested in. For Wiktionary's purposes, custom variables aren't strictly needed, it's only necessary that templates and modules have some way to figure out what L2 header they appear under.

@tstarling wrote:

the current (most deeply nested) <section> tag

As far as I can see, the preprocessor XML doesn't generate <section> tags, and neither does Parsoid. Were you thinking of T114072?

I think the #sectionproperty that Tim is suggesting is (1) very difficult to implement in our current parser, and (2) beyond Wiktionary's needs.

I hacked up a working (though imperfect) implementation of CodeCat's suggestion. It's a magic word {{#section:N}} that returns the text of the most recent level N heading. See

In T122934#1921615, @TTO wrote:

As far as I can see, the preprocessor XML doesn't generate <section> tags, and neither does Parsoid. Were you thinking of T114072?

Yes, this task would be implemented after T114072, which is pretty close to a sure thing.

That seems like a change that could take a while, though. Would TTO's proposal work in the interim?

What is the status on this?

Like CodeCat, I'm also interested: what is the status on this?

See also this link: https://en.wiktionary.org/wiki/Wiktionary:Beer_parlour/2016/August#Variables_extension

In the linked discussion, another user is basically asking the same. This voted and approved project would be a great help to us in the English Wiktionary. Thank you.

The status is that someone needs to work on T114072 first - see T122934#1929650 :)

Seeing that T114072 is marked as resolved, is it now possible to implement this?

T331906: Add Lua function to read out previous section heading suggests another, possibly cleaner and simpler solution to the same problem.

I'm not in favor of T331906 at all. This task (or something like it) is a much better solution.

We do have <section> tags in Parsoid read views. I'm not entirely convinced that hanging the data on the section is the right approach. My personal feeling is that variable declarations in a patch should be scoped and that heredoc quoting (T114432) will greatly help with the visual appearance of this. I think something like this is all that's needed:

{{#set|lang=en|<<<

...the rest of the content here...

>>>}}}

Somewhat related is the idea of "page context data" due to SMW, see https://en.wikipedia.org/w/index.php?title=File:SMWCon_2022_-_Updates_from_the_Wikitext_Parsing_World_01.pdf&page=14 for some details. I don't know if this "page variable" data should be folded into the page context data or not, but my intuition is that they are aspects of the same thing. Unresolved is how this data is passed down into template/subpage invocations. As discussed some in T114454 (referenced above in T122934#1918310), a handlebars style evaluation context could have additional scopes pushed onto it via {{#set}} or altered using {{#each}} or {{#with}} and then can be explicitly (not implicitly) passed into subpages or modules (see the "block helpers" section of the handlebars documentation).

I think it is important that templates *not* have implicit access to the evaluation context, because once you do that then tracking dependencies between page fragments becomes very complicated, and you can't cache and reuse a page fragment without the implicit evaluation context being identical, which then means it needs to be serialized and used as part of the lookup key, etc.