Last modified: 2014-11-17 09:21:29 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.
*** Bug 4712 has been marked as a duplicate of this bug. ***
agree...at least for admins [ah, self-interest], please consider doubling the permitted length of edsums. ~~~~
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.
(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.
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.
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.
*** Bug 11550 has been marked as a duplicate of this bug. ***
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.
Adding 'tracking' keyword.
fixed blocking and depends on bug numbers. bug 4718 depends on this and does not block this bug.
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.
Now all the Wikimedia projects allows IPv6 connexions, there is a problem : the default undo summary is too long. For example, on [http://ipv6test.wmflabs.org/wiki/index.php?title=Sandbox&diff=227&oldid=223 this diff], 32 characters are lacking to the summary ...
[ 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."
(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: https://commons.wikimedia.org/wiki/Special:Contributions/OverBot (search for "...)" to find truncated edit summaries) ---- Furthermore there was a discussion on de.wiki 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" https://de.wikipedia.org/wiki/Wikipedia:Umfragen/Technische_W%C3%BCnsche/Versionsgeschichte_%26_Zusammenfassung#4714
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).
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.
(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.
