The first sentence is correct, but please don't ask community members to go away. Imho, this is not the best problem resolution.

Please, this is not the venue for parochial on-wiki community disputes; take it there.

12 Support votes for en.wp does not qualify as "overwhelmingly decided", even if there were only few opposing voices because this small number is far from being representative and therefore is prone to small group bias. I really doubt that a community representative vote was wanted. Imho, that was underwhelming.

In T145604#9804125, @Rich_Farmbrough wrote:

Why, since the comments on the RFC were overwhelmingly against this proposal, was it implemented?

Why, since the comments on the RFC were overwhelmingly against this proposal, was it implemented?

The main issue that I see with both this and T331906 is that neither has a good way to handle (a) headings parsed by the preprocessor which fail on expansion (e.g. a heading containing a template which expands into multiline text), or (b) headings which aren't parsed as such by the preprocessor, but which are created via expansion (e.g. headings in template outputs).

In T122934#9196348, @cscott wrote:

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.

This is an interesting problem however, this thread is getting into TL;DR territory (I need to come back to this and read everything). However, referring to the problem statements in the issue's description:

• issue no. 2 can be mitigated by using a single template in a fashion like {{table|start}} ... {{table|end}}

Change 975064 merged by jenkins-bot:

[mediawiki/core@master] Use DOM to clean up headings for the table of contents (TOC)

https://gerrit.wikimedia.org/r/975064

(this issue is already fixed in Parsoid)

Change 975064 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@master] Use DOM to clean up headings for the table of contents (TOC)

https://gerrit.wikimedia.org/r/975064

Works now for me, seems fixed as part of T317582, there was a check if the page can have a talk page, as special page cannot have talk pages there was no return value. It does not feel like a regression as the check was there from the begin.

Change 933174 merged by jenkins-bot:

[mediawiki/extensions/TimedMediaHandler@master] Remove message keys which are no longer in use

https://gerrit.wikimedia.org/r/933174

Change 962706 merged by jenkins-bot:

[mediawiki/vendor@master] Bump wikimedia/parsoid to 0.18.0-a26

https://gerrit.wikimedia.org/r/962706

Change 962706 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):

[mediawiki/vendor@master] Bump wikimedia/parsoid to 0.18.0-a26

https://gerrit.wikimedia.org/r/962706

Change 933177 merged by jenkins-bot:

[mediawiki/services/parsoid@master] Remove attributes deprecated in TMH

https://gerrit.wikimedia.org/r/933177

Change 933173 merged by jenkins-bot:

[mediawiki/extensions/TimedMediaHandler@master] Reduce TMH html footprint

https://gerrit.wikimedia.org/r/933173

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

@brion would you be able to review https://gerrit.wikimedia.org/r/c/mediawiki/extensions/TimedMediaHandler/+/933173 ? It seems like a good change and has been sitting in Gerrit for a while.

Change 508295 abandoned by TTO:

[mediawiki/core@master] Add a new {{USERLANGUAGE}} variable for use in wikitext

Reason:

Task was declined.

https://gerrit.wikimedia.org/r/508295

@aaron Assinging to you for awareness as part of cleaning up the perf board. Feel free to evaluate or un-assign as you see fit. If you un-assign, I would ask if you could write up what is remaining on this task. Or if you like help finishing the last bits of it, let me know what you need.

Change 933177 had a related patch set uploaded (by Arlolra; author: Arlolra):

[mediawiki/services/parsoid@master] Remove attributes deprecated in TMH

https://gerrit.wikimedia.org/r/933177