Last modified: 2014-11-17 10:36:00 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T36449, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 34449 - 1.19 change to display bytes added by [edit], as opposed to total page size after [edit]
1.19 change to display bytes added by [edit], as opposed to total page size a...
Product: MediaWiki
Classification: Unclassified
History/Diffs (Other open bugs)
All All
: Highest normal with 1 vote (vote)
: 1.19.0 release
Assigned To: Andrew Garrett
Depends on:
Blocks: 31217
  Show dependency treegraph
Reported: 2012-02-16 17:45 UTC by Oliver Keyes
Modified: 2014-11-17 10:36 UTC (History)
8 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Oliver Keyes 2012-02-16 17:45:52 UTC
So, 1.19 means that page histories, instead of displaying the total size of a page in rounded brackets by each edit, display the number of bytes added or subtracted in the same way that Special:RecentChanges or Special:Watchlist do. This is on occasion useful, but there are a lot of things that, communally, we've built on the implicit assumption that an editor can easily see the total size of a page. An example, on enwiki, is - the general guideline rule of thumb for when a page has become Too Large, and should be split. It's based around size in kb, and the 1.19 change means that can't easily be found any more. Even on pages not ruled by this (talkpages, ferinstance) it's still a useful rule of thumb. The only real alternative is to wait until browsers start to lag before you do anything.

That being said, I find knowing how much was added/taken away to be really useful. Maybe it should be (pagesize) +bytesadded instead of having to choose between (pagesize) and (bytesadded).
Comment 1 Philippe Elie 2012-02-17 12:09:32 UTC
I agree, delta is useful mostly for patroller not for working on article itself, on wikisource size gave us an estimate of the amount of work to do on a page, e.g. to reformat a page to know if it's worth to do it it manually or to use a bot.
Comment 3 Brandon Harris 2012-02-17 20:26:50 UTC
I don't see why we can't have both, unless there's a technical reason as to why.  Oliver's suggestion sounds good.
Comment 4 Aaron Schulz 2012-02-17 20:29:59 UTC
(In reply to comment #3)
> I don't see why we can't have both, unless there's a technical reason as to
> why.  Oliver's suggestion sounds good.

Any good UI suggestions that avoid clutter? As long as the diff sizes stay, I'm probably happy.
Comment 5 Brandon Harris 2012-02-17 20:32:29 UTC
I don't  know if it is *possible* to avoid clutter on these pages.  Ideally we'll eventually find a new way of displaying this kind of information but right now I can't see it.  It's probably only an additional 10-15 characters, maximum, so I think we can just in-line it for now.

Colorizing the size changes will be good.
Comment 6 Andrew Garrett 2012-02-17 22:51:41 UTC
Done in r111800. Deployed to cluster.
Comment 7 db [inactive,noenotif] 2012-02-18 17:56:24 UTC
See the revision, the size is inside the tooltip of the byte change. The bytechange is colored already.
Comment 8 Bawolff (Brian Wolff) 2012-03-05 00:08:13 UTC
Personally I think this would have been better as an optional parameter $2 to rc-change-size-new (that's not displayed by default). That way any community that super relies on it could customize it whichever way they like. Most people who don't care about it wouldn't see two things that are almost the exact same (Especially since all you have to do is hover to see the other value).

Anyhow, I rather dislike this change.

Note You need to log in before you can comment on or make changes to this bug.