https://bugzilla.wikimedia.org/show_bug.cgi?id=16921
--- Comment #7 from Purodha Blissenbach <[email protected]> 2009-01-20 09:55:41 UTC --- This becomes even worse, inho, with the selectable custom-made comments that are installation/localization dependant. It is also bad in the context of blocks, where you often want to refer to an edit (i.e. an URL of a diff) which is put behind the custom comment. The most significant part, oldid=xxxxx, is truncatd most likely. :-( A too restrictive solution was, to subtract punctuation and the longest message size from the count of available characters, and output it as the lenght restriction of the (additional) comment field to the browser, in the hope that it honors the parameter. Since that can be pretty easily implemented, it might be a solution to cope with until a better solution was developped. Better was to warn the user of the possible truncation (like one can be warned when an edit comment was omitted on a normal page edit, if one chooses so in ones preferences), letting him know of the allowance, the number of characters truncated, set the input field size, and if he alters his message, recycle until all fits, or an unaltered message comes a 2nd time. Best was, to allow longer comments per increased data base field length. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
