This would lead to inconsistent behaviour of {{int:}}. This is essentially a feature request for a new parser function that would substitute a UI message in user language, like {{substint:}} ;).

(In reply to Siebrand Mazeland from comment #1)

This would lead to inconsistent behaviour of {{int:}}. This is essentially a
feature request for a new parser function that would substitute a UI message
in user language, like {{substint:}} ;).

I don't understand. At the moment {{int:...}} is not consistent. In the wikitext it gets substituted and in the summary it gets not substituted. The summary contains a link to an anchor that does not exist.

(In reply to Fomafix from comment #2)

(In reply to Siebrand Mazeland from comment #1)

This would lead to inconsistent behaviour of {{int:}}. This is essentially a
feature request for a new parser function that would substitute a UI message
in user language, like {{substint:}} ;).

I don't understand. At the moment {{int:...}} is not consistent. In the
wikitext it gets substituted and in the summary it gets not substituted. The
summary contains a link to an anchor that does not exist.

A page is output. An edit summary input is not processed, except when it's output again. It's working consistently.

But the result is not consistent and the link is wrong.

Maybe a special parser for the summary is needed which only substitutes {{int:...}}.

Change 141941 had a related patch set uploaded by Gerrit Patch Uploader:
Substitute messages in comment

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

Maybe the headline should be processed into anchor-ish text (in content language?) when the edit summary is created, instead of when the edit summary is displayed.

[Just a thought. Not sure if that makes sense]

I strongly suggest to substitute all {{int:...}} simply to default English. To let be the {{int:...}} makes really no sense.

A complete different solution would be to expand the {{int:...}} before saving in the summary. Either before suggesting as auto comment for the summary or after suggesting and before saving the summary.

To fix the anchor problem the language for the expanding can not be the user interface language. It must be the page content language or the project language.

Real example: https://www.wikidata.org/w/index.php?title=Wikidata:WikiProject_Cross_Items_Interwikis&action=edit&oldid=344730625&section=8

Current workaround (JavaScript!?) would be to take (strip) the name of the int:"string" for summary and add an anchor with the same string to the headline, like template:anchor (https://www.wikidata.org/wiki/Template:Anchor seems to exist on any Wiki)

Adding a template is an impact to the content of the wiki text.

In T69068#2368030, @Fomafix wrote:

Adding a template is an impact to the content of the wiki text.

I don't understand you, adding a section is always an impact to the content of the wiki text. But my intended "workaround" seems anyway also not working.

I've rephrased the task to be only about the use case of /* Heading */ being linked to the correct heading on the page, when the heading in question uses parser functions (such as templates and int).

A patch from 2014 attempted to partially solve this by parsing int: in edit summaries at run time, but I disagree with that solution. (https://gerrit.wikimedia.org/r/141941)

The message will not actually render the same way, because:

• It cannot be parsed in the same context.
• The message can change or be removed at a later time - expanding them when viewing the history page would not work in the long-term. (Also: Performance concerns with parsing more messages messages at run-time.)
• The message can contain rich text and other syntaxes, which would remain unexpanding, causing the link to still break.

Also, there are many more syntaxes that can be used in heading aside from the specific case of :int:. There is also templates, parser functions, magic words, and much more. We should really find a more generic solution for the use case of heading links for section edits. Perhaps some way to remember the anchor for the section being edited while saving the edit, and using that for the edit summary. That way, it is saved as a simple link in the edit summary itself, locked in time, without extra computation cost to view the history page, and without extra parsing features for the edit summary.

@Krinkle

In T69068#4226965, @Krinkle wrote:

Perhaps some way to remember the anchor for the section being edited while saving the edit, and using that for the edit summary. That way, it is saved as a simple link in the edit summary itself, locked in time, without extra computation cost to view the history page, and without extra parsing features for the edit summary.

That would exclude new sections from generating section links; it would also break if the title of the existing section is edited.

I don't know the specifics of that previous commit, but here's my question: if the TOC can generate correctly working section links when the page is previewed, why can't the edit summary? I guess it's just a performance issue of avoiding rendering the whole page when a section is edited, but does it really require the whole page if the section that's being edited is known? Wouldn't parsing the text between the == ... == work in the majority of cases, and at least work much better than the existing implementation?

Also, I'm speaking with total ignorance of the wikitext parser, but it seems to me that time dependent things like ~~~~~ timestamps are the only wikitext that really couldn't theoretically work (at least not without showing the user a different comment in preview than actually gets saved to the page, which seems inideal).

In T69068#5184185, @Retro wrote:

That would exclude new sections from generating section links; it would also break if the title of the existing section is edited.

No, those cases would work just fine with the solution I proposed - which is to remember the relevant heading anchor while saving the page. Part of saving the page, is to parse the page. This happens even if you edited a specific section only. When saving a section edit, it will glue together the rest of the wikitext, save that, and then parse as normal. (This is required because otherwise many things that depend on context, such as citation counting and magic words, would be broken).

In T69068#5184185, @Retro wrote:

[..] if the TOC can generate correctly working section links when the page is previewed, why can't the edit summary? I guess it's just a performance issue of avoiding rendering the whole page when a section is edited, but does it really require the whole page if the section that's being edited is known? Wouldn't parsing the text between the == ... == work in the majority of cases, and at least work much better than the existing implementation?

I don't think it would be better. It would mostly have the same issues, and also introduce additional issues we don't have today. But more importantly, there is no performance issue because we already parse the whole page.

If we save the anchor (as seen by TOC) when saving the edit, it will always be correct. And this can be done during preview as well.

For time-dependent things, they can indeed change between preview and save. That is true for all wikitext. If you write {{subst:myspecialtemplate}} and preview it at 11:44 and save it at 11:45, and the template contains conditional logic based on the time that will be different on minute 45 than minute 44, then you will preview something different from what you actually save (e.g. showing in the diff "I like apples" instead of "I eat pears").

This is not something we can easily change, and changing it would then break many more things. Also, it would mean we don't fix this bug:

If you edit == {{subst:CURRENTIME}} ==, and at preview it says /* 11:44 */ new section you can only have one of two choices: stay as "11:44" from the preview and but the link is broken after save (because the real heading is 11:45), or be replaced by "11:45" during the save, and the link will work. I think the link should work :)

For me this task is nearly a duplicate of T36266 (same goal with only other approach) and I'm fully fine with Krinkles closing answer there T36266#4940650.
So for now the only adequate solution here is a separation of the dynamic headline text with a static anchor id, as common.
Technically the anchor id is already separated from the heading text (2 times, more/less encoded) and also not identically (e.q. get numbers attached).
So the question is, would this lead to other conflicts?

This would implicate the mentioned solution way #2344688 (from @Fomafix; always parsing internal to default language) with leaving only the text translated (appearance parsed). This would imply again to take the summary link from the internal id (and not the headline text?).

That would also be the solution for T2111.