Page MenuHomePhabricator

Change the history view to accommodate larger edit summaries
Closed, ResolvedPublic

Description

Original author: avarab

Description:
The history view should be changed to accommodate larger edit summaries.

After T6714 was deployed, the English Wikipedia raised some concerns (permalink) about the new edit summary lengths. There are some cases where the full edit summary length was accidentally used, and this is cluttering the revision history (example). Additionally, there are worries it could be intentionally misused, possibly as a venue for discussion during edit wars, for instance.

A possible solution is to truncate the display only within the interface, and not the storage (props to @Legoktm for the idea!). A clickable/hoverable ellipsis "..." or something similar would reveal the full summary. This way everybody wins -- we can take full advantage of the longer edit summaries, and abuse and visual distraction will be minimized.

Details

Reference
bz4717

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 9:03 PM
bzimport set Reference to bz4717.
bzimport added a subscriber: Unknown Object (MLST).

I don't think this is really necessary. Edit summaries aren't supposed to be very long. If the edit summary length issues are fixed, there will still probably be a fairly low maximum size for edit summaries, although we might have saner rules than measuring by byte counts, which wouldn't affect the actual visual size. (IMO, all unicode characters should count as 1 letter, and link targets shouldn't be counted at all, so "[[Page target|Word]]" should only count as four letters.)

MusikAnimal updated the task description. (Show Details)
MusikAnimal added subscribers: MusikAnimal, stjn, DoRD and 5 others.

Copying from T188696: Possible MediaWiki implementation (again props to lego) -- server-side we wrap the too-long part of the edit summary in a CSS class that is hidden for JavaScript users. Then when clicking/hovering the class is simply removed to reveal the full summary. A pure JavaScript solution seems hacky but totally doable, too.

https://en.wikipedia.org/w/index.php?diff=828381447&oldid=828377910&type=revision&diffmode=source has some possibly relevant JavaScript codes. It seems like the consensus has not been established at enwiki, there are many solutions being discussed in a chaotic fashion.

You also have to consider the fact that by this you will completely hide big parts of edit summaries to readers and, potentially, other editors, which can cause disruption and harassment happening in the parts of edit summary that not every one of editors would be interested in opening each time one by one. If Wikimedia developers decide for us to go through with this change and we in turn decide to hide some parts of edit summaries under the rug, there also has to be an option to ‘Show all’ so to speak.

@stjn I think the optimal would be a show/hide javascript (or whatever) link for long edit summaries with the default being selectable in your preferences. I don't know how much work would be, but I guess it is not astoundingly trivial.

We should probably avoid introducing another preference -- too many of those as it is. But with the proposed implementation, it's just a CSS class. So you could add a single line of code to your personal CSS to always show the full summary. For convenience we could make this a gadget.

I'm interested in taking a stab at the MediaWiki implementation, but I'd like to hear from more that this is a good idea.

TBolliger renamed this task from The history view should be changed to accommodate larger edit summaries to Change the history view to accommodate larger edit summaries.Mar 2 2018, 10:27 PM
TBolliger added a project: Community-Tech.

Note that the "original" discussion was about keeping things better aligned in all conditions within the recentchanges-related special pages, action=history and so on. Compacting or hiding stuff via JavaScript is what the CleanChanges extension does; previously discussed solutions included a switch to a table format as we see in the various Special:ListFiles, LQT history etc. Was the table format in another feature request?

Community Tech's current proposal (being discussed at ENWP's Village Pump) is to set the edit summary input on all desktop and mobile web editing interfaces to 500 characters. We also offered to help build/review/participate in creating a gadget or user script to visually truncate long edit summaries on recent changes, histories, logs, etc.

Making the summaries 500 characters should solve most of the visual problems, but for folks who really want to go back to the days of 255 can opt-in to a visual change.

TheDJ claimed this task.
TheDJ subscribed.

Was solved by setting a frontend limit of 500 in T188798. Any further improvements should be filed as separate tickets.