Automated scripts do this already by parsing it ahead of time (e.g. the "move", "revert" etc. actions)

I think this bug is a dupe of bug 33765.

I think it would cause problems if we allow dynamic expansion of syntax when displaying the edit summary. Allowing that could cause existing summaries to no longer render correctly, and would also frequently change the meaning and rendering of new summaries based on the templates that currently exist on the wiki and their implementation (also: export/import?). Also, it would make the history pages, contribution pagers, and logs even more expensive to render than they are today, and lastly it would mean consumers of wiki information through the API can no longer statically render MediaWiki meta data independently as they can today. It would require a full parsing of the summary in a way that depends on the live database, relies on the remote wiki for with an online connection etc.

On the other hand, it seems fine (from a technical perspective) to allow expansion of syntax while saving the edit. That is, the result of the expansion would become your actual edit summary. This means nothing would change about the way we store and display edit summaries. Instead, we'd add a feature to the code that process the edit summary before saving.

This means we can't allow templates, and can't allow use of {{int:}}. Although we could, maybe, allow the specific shortcut {{subst:int:}}. I do wonder what problem this would solve, and how accessible this would be.

Rather than thinking about how or why we'd implement this particular technical ability, I think we should instead focus on the wider use case presented here, which seems to be solvable by other means well. In particular, the use case I see here is exclusively about semi-automated processes (such as bots and gadgets) being able to localise the edit summary.

That's something we can certainly solve, and as mentioned in 2012, something we already solve in MediaWiki itself for lots of use cases as well. Undo edits, Rollbacks, Page moves, Page protections, etc., these all have localised edit summaries. The way to solve that is for the bot to use the API for interface messages and/or the Parse API to obtain the desired edit summary and then submit it as part of their edit.

I'm proposing we decline this ticket as requested, with the recommendation to use our existing APIs for this use case, which seems adequate.