Page MenuHomePhabricator

Support substitution of localisation in edit summaries when saving
Closed, DeclinedPublic

Description

Currently no parser functions are enabled for summaries.

It would be very useful if localized system messages can be used by automated scripts.

e.g. a summary containing "{{subst:int:autoredircomment|Mypage}}" would be replced by "Redirected page to [[Mypage]]" on a wiki with english as local lang and to "Weiterleitung auf [[Mypage]] erstellt" on e.g. dewiki.
So the local wiki (language) setting and no the user settings should be used like it is done for autosummary.

This feature would be very useful for bots and scripts which are used on different laguanges. So these scripts do not have to know the real summary text anymore and handling of the fallback-language is done automatically.

This feature should be enabled by a new parameter (e.g. parsesummary=1), so that there is not change for existing scripts.

This feature should be used by api and added as a hidden field to edit form at skins, so that scripts can use it, but it is not visible to all users.


Version: unspecified
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=33765

Details

Reference
bz34266

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 22 2014, 12:15 AM
bzimport set Reference to bz34266.
bzimport added a subscriber: Unknown Object (MLST).
Merl created this task.Feb 8 2012, 12:59 PM

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.

Krinkle renamed this task from Editpage: Add an option that enables subst+int for edit summaries to Support substitution of localisation in edit summaries when saving.Feb 9 2019, 7:08 PM
Krinkle removed a subscriber: wikibugs-l-list.

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.

Krinkle added a subscriber: daniel.Apr 21 2019, 3:50 PM
Restricted Application added a subscriber: Liuxinyu970226. · View Herald TranscriptApr 21 2019, 3:50 PM
Krinkle closed this task as Declined.May 10 2019, 3:43 PM

Declining per T37174.

Restricted Application removed a subscriber: Liuxinyu970226. · View Herald TranscriptMay 10 2019, 3:43 PM