Edit summaries length should have a countdown for remaining characters
Closed, ResolvedPublic


Edit summaries are currently a maximum of 200 characters. It would be useful for editors to be able to see while they are typing in the edit summary a countdown of the remaining characters.

Ideally, any solution to this would not hardcode the character length (because, see Bug 4715 and Bug 4714 - that might change) but base it on the maxlength attribute in the HTML.

Version: unspecified
Severity: enhancement
See Also:


bzimport raised the priority of this task from to Low.
bzimport set Reference to bz34984.
bzimport added a subscriber: Unknown Object (MLST).
tommorris created this task.Mar 5 2012, 1:21 PM

Usability bonus: the countdown's max value could account for autogenerated text which will be prepended or appended during save (e.g. manual undo, tagging, section title).

This might be solved by closing T6714 and/or T6715, depending on implementation. (Or at least I stared at those a while, plus T18921, before deciding this was a distinct issue and searching further. :>

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 27 2016, 9:28 PM

A gadget is used for this purpose in ruwiki (counter is shown when less than 80 bytes are left, but this can be configured in summaryBytesLeft_margin variable).

This is done in the visual editor and in the wikitext mode of said editor; it's probably not worth trying to shoe-horn it into the 2010 wikitext editor.

Jytdog added a subscriber: Jytdog.EditedJul 20 2017, 11:53 AM

Please roll this back. It breaks a basic function. I was unaware this was being considered and this is a perhaps-nice-to-have-gadget but not necessary. If re-implemented it should be an opt-in and not default. In my view this counter is clutter: I would never turn it on.

@Jytdog: Explaining which exact "basic function" is now broken and how would be required. If there are convincing arguments how this counter negatively impacts your workflow and why that impact is big enough that it justifies the additional maintenance costs and resources to long-term maintain some additional opt-in/opt-out code and add even more preferences, I am sure developers would be open to discuss such arguments. "I don't like it" is not an argument though.

Jytdog added a comment.EditedJul 20 2017, 1:47 PM

Yes I posted here since this appears to be where this was agreed to. Aklapper the problems with this counter are obvious and explained at depth at the phab thread just linked and at VPT.

The implementation of this twitter-like "bell and whistle" broke a basic function. This is obvious. If making it an opt-in "costs" too much than it should not be implemented at all.

If the problem is not explained and if no links are provided (I don't plan to go through the last weeks of "VPT") it's impossible to discuss the same topic. Your choice. :)
But if the "obvious problems" are "explained at depth" in T169982 then there is T169982 to discuss the best way forward. "Revert" is just one of the available options.