See http://lists.wikimedia.org/pipermail/wikitech-l/2012-March/058551.html

(In reply to comment #1)

See http://lists.wikimedia.org/pipermail/wikitech-l/2012-March/058551.html

Indeed. And this comment from Tim:

I think the feature should be reverted.

In the <title>, <h1>, links, URLs and lots of other places in
MediaWiki, page titles are presented as a single string. This is about
the closest thing we have to a title concept in MediaWiki. We have
namespace filters in a few places, but the full title is always shown
in the results list.

This move page feature seems confused about how MediaWiki users think
about titles. It would make sense in a wiki engine like Confluence,
where page titles are normally abbreviated, but it doesn't make sense

in MediaWiki.

Source: http://lists.wikimedia.org/pipermail/wikitech-l/2012-March/058587.html.

I'm not sure I agree with an outright revert, though.

https://www.mediawiki.org/w/index.php?title=Requests_for_comment/Simplify_thumbnail_cache&offset=20131008014647&limit=10&action=history

^ Another example of this happening.

The drop-down menu at Special:MovePage is problematic for all kinds of users.

(In reply to comment #3)

The drop-down menu at Special:MovePage is problematic for all kinds of users.

Indeed:
https://en.wikipedia.org/wiki/User:Mosca/wikEd_international_pt.js

Bug 60399 may be a duplicate of this bug.

Change #1110401 had a related patch set uploaded (by SD0001; author: SD0001):

[mediawiki/core@master] Remove namespace selector from Special:MovePage

https://gerrit.wikimedia.org/r/1110401

See e.g. how Google handles this with phone numbers:

Our case is more complicated since

• the namespace can be empty;
• the user may actually want the duplication to be (e.g. Wikipedia:Wikipedia:Foo).

I think a mistake was made when two separate inputs were created that act independently. Besides being a source of mistakes, it's just tedious to deal with two inputs separately, one of which requires clicking-scrolling-choosing (remember when you select a file in Windows and want to just insert a path, but it only allows you to navigate a directory tree, no text inputs?).

In fact, only the page name input should be meaningful (i.e. be a single source of truth), and the namespace dropdown should add the namespace prefix to it

• when the user chooses a namespace;
• and probably on submit when the user has the namespace chosen but it's not reflected in the page name input (not sure; maybe add an additional step to verify the user's intention).

Also, when the page is loaded with parameters from the URL, e.g. Special:MovePage/User:JWBTH/test (this happens when clicking "Move" in the page menu), it should appear in one input

The problem is that now, when the namespace isn't chosen, it shows "(Article)" which is confusing as well if you have a namespace in the page name input. Instead, we can have a "(Not chosen)" or just "" (empty) selected by default, and optionally have "(Article)" as a separate option.

Change #1110401 abandoned by SD0001:

[mediawiki/core@master] Remove namespace selector from Special:MovePage

https://gerrit.wikimedia.org/r/1110401

Change #1281746 had a related patch set uploaded (by Wbm1058; author: Wbm1058):

[mediawiki/core@master] MovePage: Warn users publishing user subpages to change 'User' to '(Main)' in dropdown

https://gerrit.wikimedia.org/r/1281746

Change #1281746 merged by jenkins-bot:

[mediawiki/core@master] MovePage: Warn users publishing user subpages to change 'User' to '(Main)' in dropdown

https://gerrit.wikimedia.org/r/1281746

Change #1281975 had a related patch set uploaded (by Novem Linguae; author: Novem Linguae):

[mediawiki/core@master] improve moveusersubpage-warning message

https://gerrit.wikimedia.org/r/1281975

A patch was merged recently that adds this warning message:

Ticket watchers, do we think this is sufficient to resolve the ticket?

Change #1281975 merged by jenkins-bot:

[mediawiki/core@master] i18n: Improve moveusersubpage-warning message

https://gerrit.wikimedia.org/r/1281975

It's a good improvement, and I hope it prevents some users' errors in this particular case (which is probably the most common), but the interface is still confusing.

I like the idea @Jack_who_built_the_house posted above, I have been thinking about something similar. I would like to keep a dropdown menu – because typing namespaces is also error-prone – but highlight that it is also a part of the title, and may need to be changed.

Here's a slightly more specific idea: moving the dropdown inside the text field, and making it look like the selected options in multiselect inputs. Similar to multiselect inputs, it should be possible to backspace over the dropdown to remove it, and to type in a namespace and cause the dropdown to appear automatically (if you're typing, this will serve as a visual confirmation that you typed it right).

I made a shoddy mockup, combined from some existing OOUI widgets on Special:ApiSandbox and Special:RecentChanges:

That seems a bit complex.

Another idea that comes to mind is to add a "new title preview" field below "new title", and it uses javascript to update this as you type, basically concatenating the chosen namespace, colon, and the typed in title. (With special handling for mainspace of course.)

However the status quo may also be OK.

I oppose the status quo and oppose any solutions where there is no way to have the full pagename in a single input. @matmarex's solution is quite sound and definitely better than the status quo. The warning just tries to explain away a bad status quo, just like the preview is a superstructure over it.

Users are quite used to full pagenames. They see them in titles and elsewhere. They will not be intimidated by one.

Users are quite used to full pagenames. They see them in titles and elsewhere. They will not be intimidated by one.

Agreed. Hence i'd rather just merge https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1110401 (effectively reverting https://static-codereview.wikimedia.org/MediaWiki/110209.html ) and display the full pagename rather than spending a lot of time building a completely new UI.

@matmarex Is it possible to enforce length limit with your solution (which was one of the reasons to move to separate inputs, based on Ppperry's link)?

I prefer the current dropdown to stay so I’ll brainstorm my own solution. To be honest, I really dislike typing in those selects that @matmarex proposes, so I feel like that would be an even bigger downgrade in comparison to a plain old <select>. To me the ideal for most people would be something like this:

1. We show the full title in the page title field while keeping the select. The validation for how long that title should be can happen on the server/client without counting namespace name, but we could limit the field itself to 256 + [number of symbols in the longest namespace name or alias] if we really cared. I think MW JS code that can count remaining symbols can be used to count it to specific amounts of characters, so we could adjust how many symbols are max allowed depending on the input before the first :.
2. When the namespace part of the title field changes without adjusting the namespace select, there is a checkbox prompt shown to user to confirm changing the namespace to the new one.
3. If they check the checkbox with JS enabled, the select instantly changes to the new namespace choice and the title gets normalised (WP: → Wikipedia: etc.). The prompt gets unchecked and hidden again until the next change. The label could be something like Confirm namespace change to Wikipedia (bolded).
4. If they have JS disabled, the prompt to confirm the namespace change gets displayed on form submission before a rename. The resulting name of the page should be displayed, so something like Confirm move to Wikipedia:Foo (bolded).
5. When someone changes the namespace in the namespace select on their own, we assume they did this willingly and don’t ask to check. With JS there should be a simultaneous corresponding change to the text field text. Without JS there should be a confirmation prompt if the title ends up to be something like User:Wikipedia:Foo.
6. There are titles like Category:Wikipedia:Articles for deletion in a number of wikis. Those shouldn’t be touched or asked about unless someone changes the namespace field.
7. Just so it’s not confusing, there should be a label above namespace select and the label beside the input can be changed to Full title.

This probably sounds more complicated than all the other options but it feels like how this sort of thing would function with minimum friction for everyone. Info about various namespaces and their aliases is available via wgFormattedNamespaces and wgNamespaceIds, so the bulk of the work on the client is not that hard to implement. The server-side validation is the hardest part here.

I noticed, after my patch went live on the English Wikipedia, that my warning message says
**Warning: **You are about to move a user subpage. If you are publishing a new article, be sure to change 'User' to '(Article)' on the New title: dropdown.
which is different from the '(Main)' we saw in our testing.
The New title: dropdown still shows '(Main)' rather than '(Article)'. These terms are used interchangeably on the English wiki, but when we're warning users we should tell them to select something they actually see on the dropdown.

en.json defines "blanknamespace": "(Main)", but somehow '{{int:blanknamespace}}' becomes (Article) on the English wiki.

I'm not sure whether we should change my warning message to say (Main) or the dropdown to say (Article).

I think the dropdown may be in function getNamespace() but I'm not sure where to find that function or whether Intelephense can point me to where to find it.

https://en.wikipedia.org/wiki/MediaWiki:Blanknamespace is locally defined to be (Article). If the dropdown somehow displays (Main) despite that, that’s a bug that should be fixed in a separate task. FWIW I see (Article) there.

I created MediaWiki:Blanknamespace on the test wiki on my development machine, with contents (Article), and that made my test wiki duplicate the behavior of the English wiki.
I believe the bug that makes the dropdown somehow display (Main) despite that is part of ComplexTitleInputWidget.php or more specifically NamespaceInputWidget.php

Wait. It does say (Article) on my test wiki. And when moving a subpage of my own enwiki user page, it said (Main) before, but now it says (Article). So I think maybe it's some sort of caching issue? Sometimes it says (Main) and sometimes it says (Article), as I bring up the move-page form on various user subpages of mine. This seems an ongoing issue, as my change should have had no effect on how the namespace input widgt behaves.

Sorry for spamming messages about this. It doesn't seem to be a problem on my 1-year old Linux machine, only on my 15-year old Windows 7 machine. So, I guess, disregard. Never mind.

I agree that keeping the namespace selector is the route to take, firstly because it gives visibility to the full list of valid namespaces to choose from, and secondly because it lends itself to implementing this UI with progressive enhancement and users with JavaScript disabled are catered to naturally. I also agree that a live preview of the final title is essential. Here's a quick mockup I've just built to demonstrate. It doesn't present a radical departure from the current UI, but I believe doing this would eradicate most common accidents when moving pages.

Notes:

• It's the JavaScript version. A full implementation would require implementing the same logic on the back end to run on form submission if JavaScript was not available. The live preview would be unavailable, but an interstitial confirmation page could be displayed.
• It doesn't do any namespace normalization when you initialize it or check for invalid characters.
• A confirmation dialog is presented if the user is about to move a page in or out of mainspace, which I think is important enough to require a little friction.
• There's no logic to warn people of a T62399 (duplicated namespace) error as the live preview makes that unnecessary in my opinion, but submission of that could be prevented both on front and back end.
• In the full implementation, the live preview would also flag collisions with existing titles and prevent form submission in that state.