rowan.collins wrote:

The only thing that makes this slightly more complex than that is that it would
require the diff to be calculated for every edit [and preview?] submitted (or
more-or-less every: if the edit has been given a summary already, it needn't be
auto-summarised). This means a significant (I don't know how big, but in
statistical terms "significant") slow-down of each applicable preview/save while
the diff is computed (and the result measured against a threshold, but that's
trivial in comparison).

Also note that the section edit thing gets entered *before the user has changed
anything*, so it's not really the same proposition.

(In reply to comment #1)

The only thing that makes this slightly more complex than that is that it would
require the diff to be calculated for every edit [and preview?] submitted (or
more-or-less every: if the edit has been given a summary already, it needn't be
auto-summarised).

Yes, of course you are right. I forgot "if user has not entered a Summary, then
{auto-create edit summary}"

This means a significant (I don't know how big, but in
statistical terms "significant") slow-down of each applicable preview/save while
the diff is computed (and the result measured against a threshold, but that's
trivial in comparison).

Also note that the section edit thing gets entered *before the user has changed
anything*, so it's not really the same proposition.

Yes, but this is also not solved in the current version: if you create a new
section, still the old section heading is automatically pasted into the Edit
Summary (instead of the newly created one..... however, when applying my
proposal, it would detect this discrepancy)

In summary: thank you for your valuable feedback, I liked that. The processing
load issue must not be forgotten.
Tom

plugwash wrote:

on the other hand this may SAVE cpu because with an edit reason inserted there
will be less reason for people to diff the edit when they see it on thier watchlist.

rowan.collins wrote:

(In reply to comment #2)

Yes, but this is also not solved in the current version: if you create a new
section, still the old section heading is automatically pasted into the Edit
Summary (instead of the newly created one..... however, when applying my
proposal, it would detect this discrepancy)

That's an interesting point; it does beg the question though, of under what
circumstances the software would over-ride the summary text: if I go to edit a
section, the software grabs the heading and puts it in the summary box,
surrounded by /*...*/. I can edit this how I like (potentially messing up the
convenient arrow link it gives in change lists), or I can leave it be. So what
if I edit a section headed "foo", and submit the change with the summary "/* foo
*/ added new section bar" or "/* foo */ changed heading to bar" - should the
software silently change the summary to "/* bar */ ...", because that was the
section I actually ended up working on?

Perhaps that would be left alone because I'd changed the summary from its
default, which the software would presumably have to "remember" somehow. But
what about a case where I edit a ==top heading==, but the text I change turns
out to be inside a ===lower heading=== - should the software silently change my
summary to say "/* lower heading */"? Would it do so on preview, changing it
back to "/* top heading */" if necessary? And what about if I change the
heading, but don't change the summary - I guess it needs to grab the new
heading. It would probably work, but "we" would have to think quite carefully
about how it was to behave in different circumstances.

(In reply to comment #4)

(In reply to comment #2)

That's an interesting point; it does beg the question though, of under what
circumstances the software would over-ride the summary text:

I mean:
my proposal would simply *ADD* the diff-ed text (if less a threshold) to the
existing "section heading auto-summary texts"

So, a fixed text (the current section heading, if present) PLUS some parts of
the changed strings.

Wouldn't this solve all our (common) "problems" in a fine, nice and neat way ?

By the way, thank you all again for your really valuable and still encouraging
comments. Very often, when I contribute here, the proposals are smashed down in
a fraction of a second (without seeing a least one positive aspect), This
usually irritates me extremely. It's good to learn now, that open-minded
developers like you are around here....

rowan.collins wrote:

(In reply to comment #5)

So, a fixed text (the current section heading, if present) PLUS some parts of
the changed strings.

In comment 2, you suggested that your diff-based code could *over-ride* the "/*
heading name */" which is inserted as soon as you go to edit a section. I was
just trying, in my rambling way, to think through how well this would work. In
the case of *changing* the heading, it would be fairly easy: the same test could
be applied as the "first time round". But for the case of adding a heading, or
editting entirely within a sub-heading, it's not so obvious: the software can't
actually "see" sections, only look for text that resembles headings.

Which actually leads to a more serious problem than in my last comment: a diff
won't tell you that all the changes are under one sub-heading; nor will it
easily reveal the difference between adding one new section and adding two. And
given that it may be inserting this "corrected" heading name *after the user has
clicked save*, having it do too much "guessing" is just going to cause more
confusion than help, IMHO.

That's not to say your proposal in general is "bad" - something to generate
things like "+ I agree - ~~~~" when the user is too lazy to copy-and-paste could
be useful (depending, as I say, on what it does to server load). But I don't
think it can realistically solve the flaws in the existing section-edit summaries.

Probably not feasible. Marking LATER if someone wants to make a more solid proposal on how to do it and when to use it.

see also http://bugzilla.wikimedia.org/show_bug.cgi?id=2437
"Automatic edit summaries when none entered"

ui2t5v002 wrote:

(In reply to comment #1)

The only thing that makes this slightly more complex than that is that it would
require the diff to be calculated for every edit [and preview?] submitted (or
more-or-less every: if the edit has been given a summary already, it needn't be
auto-summarised). This means a significant (I don't know how big, but in
statistical terms "significant") slow-down of each applicable preview/save while
the diff is computed (and the result measured against a threshold, but that's
trivial in comparison).

Yes, it requires one diff calculation. But think how many people ask for that
diff if there is no edit summary otherwise. I don't know if diff pages are only
calculated once and remembered, or calculated on the fly each time someone views
one, but it could be a tremendous server load *savings* if you prevent lots of
people needing to view the same diffs in the first place.

(In reply to comment #8)

see also http://bugzilla.wikimedia.org/show_bug.cgi?id=2437
"Automatic edit summaries when none entered"

The only difference seems to be that my version (2437) puts an edit summary for
*any* size edit, but only if the user doesn't enter one themselves.

(In reply to comment #1)
Yes, it requires one diff calculation. But think how many people ask for that

....

Dear Omegatron,

can you edit soemthing ? As a proof of concept ??
I would be very interested in integrating this into my EnotifWiki.

Please let me know.
Wikinaut Tom

Yes, it requires one diff calculation. But think how many people ask for that

....

Dear Omegatron,

can you edit soemthing ? As a proof of concept ??
I would be very interested in integrating this into my EnotifWiki.

s/edit/program/

ui2t5v002 wrote:

(In reply to comment #10)

can you edit soemthing ? As a proof of concept ??
I would be very interested in integrating this into my EnotifWiki.

Please let me know.
Wikinaut Tom

What do you mean?

zigger wrote:

*** Bug 2437 has been marked as a duplicate of this bug. ***

zigger wrote:

See also bug 1687 (warn), bug 4630 (force).

ui2t5v002 wrote:

It looks like this has been implemented, albeit in a pretty limited fashion.
Where is the documentation for this feature?

robchur wrote:

http://en.wikipedia.org/wiki/Wikipedia:Automatic_edit_summaries

ui2t5v002 wrote:

(In reply to comment #16)

http://en.wikipedia.org/wiki/Wikipedia:Automatic_edit_summaries

Was this written to fulfill a specific bug request, or just kind of fulfilled
them incidentally?

I'm taking the LATER off this; it's probably actually fairly feasible.

Brion, was this implemented?

• Bug 9375 has been marked as a duplicate of this bug. ***