fuhghettaboutit wrote:

Support for removal is unanimous and building at the English Wikipedia Village Pump. See http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29#The_new.2C_redundant_automatic_edit_summary_on_page_moves_should_be_reverted

According to [1], it stems from r96847, so assigning this to Niklas.

[1] https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=480665448#Moving_saves_username_in_edit_summary

I've marked the revision in question FIXME.

It's a feature.

This is a feature. Username should be part of this to have grammatically correct edit summaries. It should be WONTFIX.

In the log it makes sense as that's 1 line. But the edit summary is separated from rest of the line in the ChangesList, thus causing the username to be named twice on the page for every entry.

sreed wrote:

Definitely a bug. I don't know any way to get an edit summary without having the user name supplied with it. Including the user name in the summary text is redundant and consumes resources needed for meaningful content.

fuhghettaboutit wrote:

(In reply to comment #5)

This is a feature. Username should be part of this to have grammatically
correct edit summaries. It should be WONTFIX.

Whether looking at logs or edit histories it is not grammatically incorrect because a person normally reads the full line:

Username (talk | contribs) moved page X to Y

It now reads, utterly redundantly:

Username (talk | contribs) Username moved page X to Y (now that, is grammatically incorrect)

It bloats logs, edit summaries, diffs and it drastically reduces the number of characters a user can enter in the reason field upon a move--someone with a long username may be cut off with only a few characters entered.

(In reply to comment #8)

Whether looking at logs or edit histories it is not grammatically incorrect
because a person normally reads the full line:

Username (talk | contribs) moved page X to Y

You are ignoring languages other than English.

It now reads, utterly redundantly:

Username (talk | contribs) Username moved page X to Y (now that, is
grammatically incorrect)

Nope.

We could make it the same as how it is in Special:Logs, removing the first Username and not the username that is part of the message.

It bloats logs, edit summaries, diffs and it drastically reduces the number of
characters a user can enter in the reason field upon a move--someone with a
long username may be cut off with only a few characters entered.

We would like to hear suggestions for improvements other than removing the username from the log message.

Wikifram wrote:

Niklas Laxström, you probably won't hear any suggestions for other improvements, the name needs to go. There was nothing wrong with the previous edit summary (didn't anyone even ask for the new one, instead of fixing some of the bugs and feature requests that linger here for years?).

But the main problem I see is that when a user exercises his RTV (or a user name change and so on), the username in the log will be changed, but it will remain in the edit summary, which is not what is wanted at all. So the change has no actual benefit (you claim it is a feature, but no example of an actual benefit has been given), and has obvious disadvantages.

Why not simply " "Old name" renamed to "New name" "? What other languages would this create problems for?

Wikifram wrote:

(In reply to comment #9)

We could make it the same as how it is in Special:Logs, removing the first
Username and not the username that is part of the message.

No, we and you can't. In a page revision history, you always get the "first" username, it can hardly be removed from those entries in it where a page is moved (and it shouldn't be, as the first name contains the "talk/contribs/block" links which are obviously absent from the edit summary). By the way, in Special:Logs (e.g. [http://en.wikipedia.org/wiki/Special:Log/Fram]), the first user name (with the "talk" and so on) is kept, but you get a different (and better) message, without the user name but with the comment added by the user for the move.

(In reply to comment #9)

We could make it the same as how it is in Special:Logs, removing the first
Username and not the username that is part of the message.

That's a good idea, but the fact is. Currently change lists aren't like Special:Log, so it doesn't make sense to change the edit summary message while the rest is still as it was.

How about we set the edit summaries back to how they were. And when the changes list are made as awesome as you made the Log page, then it makes sense to do this.

(In reply to comment #5)

This is a feature. Username should be part of this to have grammatically
correct edit summaries. It should be WONTFIX.

Since when do edit summaries have to be complete sentences? Looking at [[en:Special:RecentChanges]], it seems the former edit summary followed the more common format: "Archiving text", "Removed category using HotCat", "Created page", "Added wikiproject template", "Disambiguated", "Undid revision 12345 by 1.2.3.4".

"Moved page X to Y" fits right in, while "Username moved page X to Y" doesn't.

(In reply to comment #9)

(In reply to comment #8)

Whether looking at logs or edit histories it is not grammatically incorrect
because a person normally reads the full line:

Username (talk | contribs) moved page X to Y

You are ignoring languages other than English.

You'll have to do a better job explaining it than that. And especially explain why forcing this on communities that don't want it is somehow preferable to allowing communities that do want the username redundantly repeated in the edit summary to adjust [[MediaWiki:1movedto2]] in that manner.

We could make it the same as how it is in Special:Logs, removing the first
Username and not the username that is part of the message.

So you intend to change the entire display of diffs, the article history, the output from the API's prop=revisions&rvprop=comment, and so on to display the dummy revision for a move in a format different from all other revisions? Or are you just entirely confused and not realizing we're talking about '''the edit summary attached to the dummy revision''' inserted in the article's history for the move?

(In reply to comment #12)

How about we set the edit summaries back to how they were. And when the changes
list are made as awesome as you made the Log page, then it makes sense to do
this.

This is the appropriate solution: revert, and *if* such a wider-reaching change is ever made then it can be revisited.

(In reply to comment #13)

(In reply to comment #5)

This is a feature. Username should be part of this to have grammatically
correct edit summaries. It should be WONTFIX.

Since when do edit summaries have to be complete sentences? Looking at
[[en:Special:RecentChanges]], it seems the former edit summary followed the
more common format: "Archiving text", "Removed category using HotCat", "Created
page", "Added wikiproject template", "Disambiguated", "Undid revision 12345 by
1.2.3.4".

It's not about edit summaries in that sense. Log entries need to be full sentences. The Wikipedia article on [[Word order]] should make it clear why this is necessary. Page histories are implemented in stupid way where the log entries are posing as normal edits with the log entry in edit summary.

(In reply to comment #12)

How about we set the edit summaries back to how they were. And when the changes
list are made as awesome as you made the Log page, then it makes sense to do
this.

This is the appropriate solution: revert, and *if* such a wider-reaching change
is ever made then it can be revisited.

It cannot be reverted. The two options are to either make horrible workarounds (like we did with IRC log output) or improve page history views to handle log entries better.

I will keep my stance and not do any workarounds. I can work towards another solution, but I'm not going back.

(In reply to comment #9)

(In reply to comment #8)

Whether looking at logs or edit histories it is not grammatically incorrect
because a person normally reads the full line:

Username (talk | contribs) moved page X to Y

You are ignoring languages other than English.

And you are ignoring English.

The problem is there seems to be no one-size-fits-all solution here.

(In reply to comment #15)

And you are ignoring English.

It doesn't seem about English or other languages to me: it's pretty hard to argue that the username shown as first is the subject of a sentence several cm apart with «(Talk | contribs)‎ m . . (4 bytes) (0)‎ . .» in the middle (do you read it all together aloud?) and a completely different style (or even language, is your interface language is not the wiki's language). Every element of the history is correct in English (and also other languages, now).
At first, I was surprised/annoyed by the username as well, but only because it's a change.

sreed wrote:

Is this the appropriate forum and audience for this discussion?

(In reply to comment #17)

Is this the appropriate forum and audience for this discussion?

wikitech-l (http://lists.wikimedia.org/pipermail/wikitech-l/) is your best bet.

I can see an argument to have two sets of messages: one for logs and one for snippets (like history comments). I'd be surprised if people made manual summaries that *had* to say "I changed X to Y" or "Person A changed X to Y"...in any language. People often (almost always on en) make edit summaries where they put in things like "fixed spelling" or other subject-less fragments.

On the other hand, it's possible in some language projects that people use sentences more like "Multiple spelling errors were fixed." or "This dubious section had to be removed." and such. It would be interesting to see examples (wiki projects) where such summary fragments are considered ugly and people avoid them. It would empirically bolster the case for the 1.19 change to log comments in history pages.

Overall, I lean towards keeping it as is in 1.19. If some projects don't care about summary comment grammar, it won't HURT to have a few grammatically *correct* entries. OTOH, for wikis that do, it sucks to have uncontrollably grammatically bad summaries. The only problem in EN and the like is that it is redundant, which is hardly a problem. The complaint about "taking up useful space" is a bit of a red-herring. I think it's a database layout issue that we are restricted to 255 bytes which should someday be fixed separately.

fut.perf wrote:

I wonder about that argument about languages other than English. Niklas, could you provide a concrete example of a language where a wording without the full agent noun phrase would be grammatically or stylistically problematic? I am not aware of any language where a full statement of a non-pronominal agent noun phrase is obligatory to make a sentence acceptable. Most languages have devices such as zero subjects, passive constructions etc. to make sentences without overt subjects possible. Or they might use sentences with simply a pronominal rather than a full NP subject. Or they are like English with its well-established stylistic tolerance for elliptical statements, in contexts where terseness of expression is desirable (like here). Indeed, most languages seem to be more tolerant towards such constructions than English is, for all I can see. I really cannot follow you with your claim that log entries "must" be complete sentences.

fut.perf wrote:

BTW, I'm probably very ignorant, but could this not be tweaked locally by simply editing [[MediaWiki:Logentry-move-move]] or some other MediaWiki message? And, if it is true that some other languages need a full subject, is there a technical need to express all the same parameters in all translations?

(In reply to comment #21)

BTW, I'm probably very ignorant, but could this not be tweaked locally by
simply editing [[MediaWiki:Logentry-move-move]] or some other MediaWiki
message? And, if it is true that some other languages need a full subject, is
there a technical need to express all the same parameters in all translations?

No, changing that would break Special:Log.

fut.perf wrote:

So, if I'm reading the code correctly, the pre-1.19 version (https://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/Title.php?revision=96846&view=markup&pathrev=96847) used two separate system messages: [[MediaWiki:Logentry-move-move]] for the actual log entries, which were and still are "$1 moved page $3 to $4", and [[MediaWiki:1movedto2]] for the null revision in the page history, which is "moved $1 to $2".

The new version (https://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/Title.php?revision=96847&view=markup&pathrev=96847) uses only [[MediaWiki:Logentry-move-move]], and applies it both to the log entry and to the null revision.

Nobody has a problem with how the log entry itself used to work and still works. What people want changed back is the edit summary of the null revision. I see Niklas above saying "Page histories are implemented in stupid way where the log entries are posing as normal edits with the log entry in edit summary." Indeed, but isn't that just what was now introduced? It's with the new system that the log text is crammed also into the page history, in a form that doesn't make that much sense there. In the old system, the page history had its own, tailor-made string, which made much more sense there.

Another lay question: if there are really localisations that need the full three-parameter form also in the page history and not only in the log entry, would it be possible to return to using [[MediaWiki:1movedto2]] but add the performer's name to it as a third, optional parameter, which localisations could choose to use or not use?

No, there did not used to be two message sets. Logs just used the one message set and prepended the username (along with a space) to create the final log wording. That pretty straightforwardly was bad for localization.

(In reply to comment #23)

Another lay question: if there are really localisations that need the full
three-parameter form also in the page history and not only in the log entry,
would it be possible to return to using [[MediaWiki:1movedto2]] but add the
performer's name to it as a third, optional parameter, which localisations
could choose to use or not use?

This is the part I'm not following. If r96847 is about better localization support, why isn't this configurable (or at least bypass-able) via a MediaWiki message tweak? That's the whole point of the namespace (in theory), isn't it? If the capability doesn't exist, it should be added and preferably made the default for languages such as English.

The underlying virtue of this change also remains a bit unclear to me. r96847 doesn't reference any bug number or wiki page or mailing list discussion. Is there relevant discussion somewhere about what this change was meant to do and why?

fut.perf wrote:

(In reply to comment #24)

No, there did not used to be two message sets. Logs just used the one message
set and prepended the username (along with a space) to create the final log
wording. That pretty straightforwardly was bad for localization.

That's not the way I read the code. According to the old version of the code in https://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/Title.php?revision=96846&view=markup&pathrev=96847, the text for the null edit in the page history was produced by these lines:

3336 $commentMsg = ( $moveOverRedirect ? '1movedto2_redir' : '1movedto2' );
3337 $comment = wfMsgForContent( $commentMsg, $this->getPrefixedText(), $nt->getPrefixedText() );

So this was based on [[MediaWiki:1movedto2]] (or [[MediaWiki:1movedto2_redi]] respectively).

The text for the log entry was produced by an entirely independent computation a bit further down, presumably calling[[MediaWiki:Logentry-move-move]] somehow:

$log = new LogPage( 'move' );
3453 $logType = ( $moveOverRedirect ? 'move_redir' : 'move' );
3454 $log->addEntry( $logType, $this, $reason, array( 1 => $nt->getPrefixedText(), 2 => $redirectSuppressed ) );

If there is a good localization-related reason to change this second part of the code and calculate the log entry in a different way, that's fine. But why couldn't we return the first part of the code to the way it was, making log entry and edit summary again independent of each other?

fut.perf wrote:

So, here's what I think would be a patch. (Sorry, I'm not familiar with how to submit patches here, so maybe someone with more experience could consider submitting it?)

Re-introduce the old system messages for the null edits in the page histories:
in .../language/messages.inc:
2209+ '1movedto2',
2210+ '1movedto2_redir',

in .../languages/messages/MessagesEn.php:
3236+ '1movedto2' => 'moved [[$1]] to [[$2]]',
3237+ '1movedto2_redir' => 'moved [[$1]] to [[$2]] over redirect',

Make the null edit summaries for the page histories be calculated independently of the log entries again:
in .../Title.php:
3353- $formatter = LogFormatter::newFromEntry( $logEntry );
3354- $formatter->setContext( RequestContext::newExtraneousContext( $this ) );
3355- $comment = $formatter->getPlainActionText();
3353+ $comment = wfMsgForContent(
3354+ ($moveOverRedirect ? '1movedto2_redir' : '1movedto2'),
3355+ $this->getPrefixedText(),
3356+ $nt->getPrefixedText(),
3357+ $wgUser);

The log entries themselves remain as in the current version, the way Niklas wanted them. The null edit summaries ("1movedto2') get the performing editor as a new, optional parameter, so that localizations can use that if the want to.

Wouldn't this make everybody happy?

I agree with Fut.Perf. (see also comment #12)

• The introduction of the username in the edit summaries is a 1.19 regression.
• In the log system is makes sense because the "user-tools" + "message" was replaced there with "message"
• the changes-list system was not fixed yet in that way, so forcing this message onto there is wrong
• although it is better for other languages to include the username in the message to allow better word order, we've used 1movedto2 for years, so going back to that until that changes-list are also upgraded, makes perfect sense
• the log system is kept in the new way as it is, no problem there afaics.

Moving to 1.20wmf deployment

fuhghettaboutit wrote:

Here's one concrete example of damage this has caused, completely aside from the affront to language parsimony that makes my writer's ear bleed each time I move a page: http://en.wikipedia.org/w/index.php?title=Northern_treeshrew&diff=485453813&oldid=485429405 (note the cut off URL)

(In reply to comment #30)

Here's one concrete example of damage this has caused, completely aside from
the affront to language parsimony that makes my writer's ear bleed each time I
move a page:
http://en.wikipedia.org/w/index.php?title=Northern_treeshrew&diff=485453813&oldid=485429405
(note the cut off URL)

I doubt so, that's just the usual bug about inconsistency of length checks of the summary/reason, bug 22967 or bug 4715 etc.

I think the best solution to this would be to split these into different messages again. They may be identical for all I care, but it should be possible to customize it in one place (e.g. history) without affecting the other (e.g. log).

fut.perf wrote:

By the way, the same issue applies to file upload log entries and the way these are mirrored as dummy entries in the file history. While for the log entry itself the new mechanism works fine, in the edit history entries it produces ugly and redundant repetition. See for illustration this [https://commons.wikimedia.org/w/index.php?title=File:Map_Greece_expansion_1832-1947-en.svg&curid=1868273&action=history] edit history, comparing the old "uploaded new version" entries from December 2008 with the new ones from April 2012.

I think that the best solution which kepps current messages intact might be transfering the first parameter for the message empty if the messages is shown on history and such pages, where two usernames are redudant. Is it possible?

So... is anything going to be done about this or are people just sticking their finger in their ears?

fuhghettaboutit wrote:

(In reply to comment #35)

So... is anything going to be done about this or are people just sticking their
finger in their ears?

The latter. This is what happens when the development community is divorced from the writing/hands on community. Unilateral decisions are the norm and there's no mechanism for enforcement or appeal, or at least no mechanism I know of. Vast support for reversing a change and even concrete suggestions for fixing it in a way that should mollify the naysayer's position and map a way forward and one person here just says no, I don't agree, all of you that think it's a problem and I don't, so there. It is infuriating.

1.20 is about to be released and this hasn't gotten a solution yet.

fuhghettaboutit wrote:

content hidden as private in Bugzilla

content hidden as private in Bugzilla

fuhghettaboutit wrote:

content hidden as private in Bugzilla

https://old-bugzilla.wikimedia.org/show_bug.cgi?id=34961

Hrm. I'm not sure why three comments were marked private/hidden.

In T36961#821920, @MZMcBride wrote:

https://old-bugzilla.wikimedia.org/show_bug.cgi?id=34961

Hrm. I'm not sure why three comments were marked private/hidden.

The first is an entirely offtopic personal attack, and the next two quote it (and are also off-topic). We're not missing anything useful by not seeing those comments.

For the record, these comments were not off topic at all, and I'm not sure the entire conversation has been imported, so some of the context seems missing. I'm remembering from over five years ago, but I expressed the opinion that what was going on here was malfeasance. One person, in a role of authority, with numerous people saying an action should be reversed, essentially refusing to discuss the matter except to say I have decided, go pound sand (I would be able to express the full situation better five years ago) should result in that person being fired from their position. At that point, someone who is not a native English speaker misunderstood my use of the word "terminated" in those posts, in the context obviously referring to my sentiment that the person should be fired from employment, as a death threat, and banned me from Bugzilla entirely.