ayg wrote:

Or else we should make other reason boxes multiline? A larger box is needed to hold a full summary, otherwise you have to scroll. On Special:Movepage we have lots of screen real estate, so we can afford to have a nicely-sized reason box. We only arguably need small reason boxes when we have a huge text area right above it, and even then I'm not sure we do. (Certainly not if we allow longer edit summaries than we do now.)

mike.lifeguard+bugs wrote:

(In reply to comment #1)

Or else we should make other reason boxes multiline? A larger box is needed to
hold a full summary, otherwise you have to scroll. On Special:Movepage we have
lots of screen real estate, so we can afford to have a nicely-sized reason box.
We only arguably need small reason boxes when we have a huge text area right
above it, and even then I'm not sure we do. (Certainly not if we allow longer
edit summaries than we do now.)

Apparently there is talk of allowing longer edit summaries etc, so perhaps everything will become multiline. Someone should decide what is going to happen here, and then make everything match up one way or the other.

mike.lifeguard+bugs wrote:

(In reply to comment #2)

(In reply to comment #1)

Or else we should make other reason boxes multiline? A larger box is needed to
hold a full summary, otherwise you have to scroll. On Special:Movepage we have
lots of screen real estate, so we can afford to have a nicely-sized reason box.
We only arguably need small reason boxes when we have a huge text area right
above it, and even then I'm not sure we do. (Certainly not if we allow longer
edit summaries than we do now.)

Apparently there is talk of allowing longer edit summaries etc, so perhaps
everything will become multiline. Someone should decide what is going to happen
here, and then make everything match up one way or the other.

Even if that does happen (and I guess nothing has happened on that front since that comment), then we should probably have a one-line field, but longer. I've seen no problems with one-line fields on the deletion form, edit summary, block reason etc etc

The comment/reason field on Special:Movepage was turned into a textarea in r10436 (August 2005) "to reduce confusion between destination title and reason input boxes".

I'm not sure the pressures have particularly changed here, so I'm not inclined to just change it back. :)

Daedalus969 wrote:

It's fine the way it is, making it smaller will only increase confusion.

matthew.britton wrote:

This was fixed as a side effect of r45517, which addressed bug 16921.

r45517 was reverted in r45571, as it doesn't properly address bug 16921 and causes a usability regression here.

mike.lifeguard+bugs wrote:

(In reply to comment #7)

r45517 was reverted in r45571, as it doesn't properly address bug 16921 and
causes a usability regression here.

Isn't there some other way to have this be one line while making things clearer for the end-user to avoid mishaps? Perhaps the spacing between the destination and log entry boxes could be increased, or maybe next to one another on the same line would be preferable. I don't think having it as a multiline input is necessarily the only or even the best way of doing this.

mike.lifeguard+bugs wrote:

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

mike.lifeguard+bugs wrote:

(In reply to comment #9)

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

Ermm, bug 17130 comment 3 has a patch, which I thought would be moved. Someone who knows how should perhaps do so.

No need for a patch if it just replicates the change in SVN linked above.

happy.melon.wiki wrote:

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

folengo wrote:

I think this is a major bug. Cutting a user's text without warning that the text is going to be cut if the text is "too" long, is a major bug in my view. I don't see this as mere "enhancement".

Can you imagine the same happened with this very "Additional comment" box on bugzilla ?

At least here you would be able to add a second comment below to replace the cut text. But is it reasonable to tell people to move the wiki page back and move it again with a shorter text when they experience such difficulty ?

We have JS for the edit summary box to limit it to 255 bytes (taking utf8 into consideration). It shouldn't be that hard to adapt it to the textarea on move. I'll try and look into doing that sometime in the nearish future (but if someone wants to beat me to it, by all means).

As for the "textareas are ugly, I only want a one line input" part of this bug, I think that is a wontfix.

Another problem with textarea is, that Enter to submit doesn't work.

Note, Jan Paul Posma fixed the reason gets cut off issue in r86846.

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

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

I like one-line (move) summary as that can auto complete which saves time when I am moving multiple files for similar reasons.

Why not allow user settings to determine if summary box is going to be a single or multi-line textbox. Also having a dropdown+optional comment would work better as it would allow linking to the policy more effortlessly.

Why not allow user settings to determine if summary box is going to be a single
or multi-line textbox.

Because of our unrelenting hate of user preferences ;)

Note, its possible using user js to change the box to a single line box, fairly easily.

Sure I can java script hack my way on all of life's problems for everything else there is mastercard. Right? It could also be a simple set of check boxes allowing user to customize input fields.

Currently as previously mentioned... The page-file move box/edit summary box/delete box/block box/protection box are different. Only one is multi-lined other are single-lined. This irks me greatly. I however do not want to force people who want to use multi-lined text boxes to use single lined.

The reasons of moving a page or file is routine. Far more routine than anything else. You almost always use the same rationale so WHY is it that it is multi-lined?

For filemove at least on commons and English wikipedia, drop down bot quoting the rationale would be helpful. Drop down box input can be determined locally just like how license list can be adjusted.

Sure I can java script hack my way on all of life's problems for everything
else there is mastercard. Right?

Exactly! I think this should be MW's new slogan.

I do agree with comment 8 that the spacing between the reason box and the destination box should be increased (even if the reason box is kept multi-line).

Seriously? Why do you want to force users to use interface they are not happy with. I might as well suggest people wanting his multi-lined to use a java script hack. It is bad enough for users to get used to the MediaWiki markup now you want them to learn how to use java script to modify interface.

(In reply to comment #23)

Seriously? Why do you want to force users to use interface they are not happy
with. I might as well suggest people wanting his multi-lined to use a java
script hack. It is bad enough for users to get used to the MediaWiki markup now
you want them to learn how to use java script to modify interface.

I was being a bit sarcastic in comment 22. I don't want people to modify the interface with javascript. I want the interface to be reasonable and usable to all people. For the same reason I don't want user preferences to trigger subtle changes in the interface (Otherwise we would have 10 billion prefs, and usability should not be a preference, etc).

I also do not want to force people to use an interface they are not happy with. However at the same time it is unclear if the change suggested (making it a single line for everyone) would make more or less people unhappy. Thus I feel such a change should be done cautiously.

Similarly, I am not neccesarily opposed to making the box one line, adding a drop down for an auto-reason, and having some extra whitespace between the reason fields and the move target field. I think such an approach may possibly make everyone happy. Or perhaps it won't. I suppose we should make mock-ups and talk to the users and so on.

Alright here is the issue from my perspective. All summary boxes (move, delete, block, edit, whatever) to me should always be single-lined since it will be displayed as a single line anyways.

Mind that this is merely my preference and no one should be forced to use my preference so I acknowledge that some people may want it multi-lined. If we force a single-line summary field on them they will of course complain. Additional stuff such as drop down boxes would probably be warmly welcomed since move actions are typically routine.

The default used to be single lined as far as I know. It was changed without asking users (which alone is fine since some people wanted it this way).

I would support mock-ups and perhaps enable it on some wiki like test.wikipedia for users to actually see.

(In reply to comment #15)

Another problem with textarea is, that Enter to submit doesn't work.

(In reply to comment #19)

I like one-line (move) summary as that can auto complete which saves time when
I am moving multiple files for similar reasons.

I agree with both, Special:Move is currently very counterintuitive and user-unfriendly because of this. Switching to Normal/Major.

I'm marking this bug as easy because it is an easy bug for any developer to work on. It needs a very simple changeset in Gerrit to move forward. The broader question is whether this bug should be marked resolved/wontfix.

(CC'ing a few people who may be interested in the topic. It's basically a question of usability, consistency, and user expectation.)

(In reply to comment #27)

I'm marking this bug as easy because it is an easy bug for any developer to
work on. It needs a very simple changeset in Gerrit to move forward. The
broader question is whether this bug should be marked resolved/wontfix.

(CC'ing a few people who may be interested in the topic. It's basically a
question of usability, consistency, and user expectation.)

I disagree that bugs like this should be marked "easy". Easy is supposed to denote a good task for a newbie. While you're correct that making the change is easy, the broader question of should this be Fixed or WONTFIXED is not an easy question, and probably not something a newbie would be prepared to deal with as a first contribution to MediaWiki.

This should definitely be fixed.

Two lines of textarea is harder to use than one line of input, not just because it's smaller in practice on many screens, but also because it prevent users from hitting enter when they're done to submit like they would on other summary and reason inputs, because textareas take enter as a linebreak - which makes no sense here because log entries don't allow linebreaks.

While there are concerns about one line inputs being a constraint on how much of a reason a user can give, the character limit is 200 characters (for database reasons apparently) anyway - sufficiently low that even if someone does hit the limit it is relatively trivial to scroll through it - and generally reasons are a lot shorter than that. If a reason to move something truly does require that many characters or more, chances are there is a bigger issue behind the move itself and folks really should be using a link to a policy or talkpage discussion or some such instead of putting it all in the summary, not in the least so that people can respond to the lengthy matter if need be.

I share Isarra's sentiment. I think it summarizes the entire issue very well.

I've always been interested in the thought that with some level of extra effort. contentEditable could actually be used to build a custom input that could be one line but nicely word wrapped. And as a bonus it would be possible to make things like the "/* Section */" we give special styles outside have styles inside the input form.

Daniel, feel free to have a go at implementing that. For the time being I'm going to submit a patch to make the input single-line again and add some space between the new title field and the summary, per comment 22 (since apparently everybody else is afraid to touch this bug with a stick).

Actually, I'm pretty sure that the original reason for this is invalid now that the new name field is split in two parts – the namespace and the title, so I'm just going to revert r45571 back.

Related URL: https://gerrit.wikimedia.org/r/62163 (Gerrit Change I5ab2092c32682e7a8a1494bf58553971568fa6cf)

Merged, fixed, thanks to Bartosz.

Rock on!