Last modified: 2014-11-17 09:21:29 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 4714 - Increasing the length of the edit summary (tracking)
Increasing the length of the edit summary (tracking)
Status: NEW
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
All All
: Normal trivial with 12 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: tracking
: 4712 11550 (view as bug list)
Depends on: 4715 4716 4717 12359 10089 16921 22967
Blocks: tracking 4718
  Show dependency treegraph
Reported: 2006-01-22 08:28 UTC by Ævar Arnfjörð Bjarmason
Modified: 2014-11-17 09:21 UTC (History)
16 users (show)

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


Description Ævar Arnfjörð Bjarmason 2006-01-22 08:28:47 UTC
This bug tracks all the issues that should be resolved in order to allow
increasing the length of edit summaries from their current database limit of
2^8-1 bytes and UI limit of 200 characters.
Comment 1 Ævar Arnfjörð Bjarmason 2006-01-22 08:31:56 UTC
*** Bug 4712 has been marked as a duplicate of this bug. ***
Comment 2 Tomer Shiloach 2006-01-22 08:42:13 UTC least for admins [ah, self-interest], please consider doubling the
permitted length of edsums.  ~~~~
Comment 3 Filip Maljkovic [Dungodung] 2006-01-22 11:00:01 UTC
I disagree. As Brion said in #4712 comment #1 the comments should be concise and
up to the point. There have been several cases where people put the whole text
they wrote in the article into the edit summaries and that is, quite frankly,
abusive. There's no point in writing long summaries. If you want it long, write
in the talk page.
Comment 4 Ævar Arnfjörð Bjarmason 2006-01-22 11:52:49 UTC
(In reply to comment #3)
Talk pages are meant for discussion of content, edit summaries are meant for
summarizing edits. The limit on the length of edit summaries is currently way
too short to properly provide a summary for large (and some short) edits,
especially in multibyte enviroments and the workaround you suggest is
inadequate, that would require someone wishing to view the summary for the edit
to view the talk page (which they may not have if they imported an XML export)
which may be archived, blanked or even deleted.
Comment 5 Max Semenik 2006-06-07 09:46:00 UTC
Don't forget that UTF-8 uses at least 2 bytes for non-Latin1 characters, currently 
length of log entries is a big problem on non-latin wikis. We are basically unable 
to provide diffs in block comments, user creation log shows bogus entries such as: 

Винцевич Евгений Васильевич (Обсуждение | вклад | блок) (Новый участник: Обсуждение 
| вклад | [[Special:Blockip/Винцевич Евге�

when user with long name is created. Please increase length of all logs.
Comment 6 Ral315 2007-01-07 23:44:05 UTC
I don't think the UI limit of 200 characters need be changed (though others do),
but I think the UTF-8 worries are worth possibly increasing the limit.  
Comment 7 Rob Church 2007-10-03 23:26:04 UTC
*** Bug 11550 has been marked as a duplicate of this bug. ***
Comment 8 Tisza Gergő 2007-10-04 08:30:31 UTC
The undo autosummary is around 90 characters on en:, plus the section title, plus three times the username. That can easily eat up the 200 characters in itself, and undoing without an explanation is usually rude. Moving undo/rollback information to a separate field might be a partial solution.
Comment 9 Andrew Garrett 2009-07-29 16:38:51 UTC
Adding 'tracking' keyword.
Comment 10 Karun 2009-12-08 11:29:23 UTC
fixed blocking and depends on bug numbers.
bug 4718 depends on this and does not block this bug.
Comment 11 Aryeh Gregor (not reading bugmail, please e-mail directly) 2011-04-24 18:35:54 UTC
I've discussed this with Domas, and he pointed out that lengthening the column much could have serious implications for (IIRC) the covering index on the recentchanges table.  We certainly can't make rc_comment a smalltext on Wikimedia, that would be bad.  varchar(n) for some n > 255, maybe, but the consequences would have to be considered carefully.
Comment 12 Pic-Sou 2012-06-28 19:59:38 UTC
Now all the Wikimedia projects allows IPv6 connexions, there is a problem : the default undo summary is too long. For example, on [ this diff], 32 characters are lacking to the summary ...
Comment 13 Dereckson 2012-07-30 15:28:51 UTC
[ IPv6 and summary edit length ]

Some French Wikipedia contributors (Geralix, Ltrl) point there is a new issue raising a little bit the priority of this bug: IPv6.

Geralix said about the undo/rollback feature: "En effet, dans ce cas, le texte préformaté dans la boîte de résumé est d'une telle longueur qu'il reste seulement une zone disponible un peu courte pour expliquer les raisons de l'annulation, sauf à utiliser un langage en style télégraphique ou de renvoyer vers la page de discussion de l'article où il faut rédiger un explication plus détaillée.".

Translation: "Indeed, in this case, the [prefilled] text in the summary box is so long there is few space to explain the undo rationale, save to use a telegraphic speech or to redirect users to the article talk page where we must write a more comprehensive explanation."
Comment 14 Marco 2014-01-12 21:11:22 UTC
(In reply to comment #3)
> There's no point in writing long summaries. If you want it long,
> write in the talk page.

There is a bot running on Wikimedia Commons which cleans up overcategorization. It is essential to explain every edit in detail. (i.e. what categories are removed and why!) Of course the bot can not create a new talk page for every edit.
The length of the edit summary needs to be increased because if two, three or more categories are removed the space is not enough.

Link to the Bots contributions: (search for "...)" to find truncated edit summaries)


Furthermore there was a discussion on about this bug. The result was 100% support (13) and 0% oppose (0). The discussion concluded that in some cases about 512 bytes are necessary to explain a rollback/revert.

Quote: "speziell beim Revertieren während des Sichtens muss ich ständig den vorgegebenen Text "Änderung von xxx wurde rückgängig gemacht und ... wiederhergestellt" kürzen, um einem Anfänger höflich und genau mitzuteilen, warum ich seine Änderung verworfen habe"
Comment 15 Andre Klapper 2014-01-13 09:57:24 UTC
Realistically speaking this tracking bug is not high priority (until somebody volunteered to work on it maybe, but first the blocking tickets would need to get solved that this bug depends on).
Comment 16 Quim Gil 2014-04-09 16:52:35 UTC
What process do we need to resolve this request in a way or another? A chat between maintainers? A thread in wikitech-l? A formal architecture RfC seems excessive.

Even if the implementation is technical, the question is social: do we as MediaWiki / Wikimedia communities want the possibility to post longer edit summaries?

Also, the severity says "trivial" but comment #11 says that "the consequences would have to be considered carefully". 

This request was filed in 2006! Let's kick the discussion to resolve it.
Comment 17 Tim Starling 2014-04-09 22:15:11 UTC
(In reply to Quim Gil from comment #16)
> What process do we need to resolve this request in a way or another?

For a start, Sean Pringle needs to comment on bug 4715. In 2010, Domas was very emphatically against it.

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