Last modified: 2014-08-26 19:29:53 UTC
When a account is created the user name can be adjusted silently due to some technical restrictions, like first letter capitalized or double spaces. Please add a warning, so the user get a hint, that he choose a user name, which is not usable as entered. See Gerrit change #104926 for a discussion about this. See http://lists.wikimedia.org/pipermail/design/2014-January/001320.html for a discussion about this. The patch set adds a warning after the submit of the form, which needs retype of the password and resubmit, which is not the best way to do this. Along to the warning it can be possible to add a api call for validation of the username and provide ajax warnings, so the user has not to resubmit the form. This can be reached by a dry-run parameter for API's action=accountcreation. For non-javascript users the warning should stay.
Change 114400 had a related patch set uploaded by Bartosz Dziewoński: Warn on account creation when username is adjusted https://gerrit.wikimedia.org/r/114400
Change 114400 merged by jenkins-bot: Warn on account creation when username is adjusted https://gerrit.wikimedia.org/r/114400
I found the "Erik-Gryllida proposal" convincing: http://thread.gmane.org/gmane.org.wikimedia.mediawiki.design/253/focus=468 I understand that the implementation issues with JavaScript described in http://lists.wikimedia.org/pipermail/design/2014-January/001357.html were solved, so it's "just" a matter of * reducing code duplication perhaps, 100+ lines sounds suboptimal and there should be a WebAPI module to ask MediaWiki how a string will be acccepted/rejected/transformed by the wiki; * tweaking the display, from a warning to a username preview: right? If yes please file bugs for the followups.
(In reply to Nemo from comment #3) > I understand that the implementation issues with JavaScript described in > http://lists.wikimedia.org/pipermail/design/2014-January/001357.html were > solved Yes, there is a non-JavaScript fallback and I solved the validity checking thing by just doing everything server-side. A better solution would be to do what Umherirrender suggested in comment 0: > Along to the warning it can be possible to add a api call for validation of > the username and provide ajax warnings, so the user has not to resubmit the > form. This can be reached by a dry-run parameter for API's > action=accountcreation. For non-javascript users the warning should stay. (I currently implemented some custom checking for just the username.) This would require some reworking of the internals, I'm afraid.
Change 117234 had a related patch set uploaded by Nemo bis: Revert "Warn on account creation when username is adjusted" https://gerrit.wikimedia.org/r/117234
Out of interest why does this matter? I seem to have missed the problem here. If I register with the username "an unusual username" and it gets corrected to "An unusual username" in my opinion as long as if I login with username "an unusual username" and it still logs me in as that user (if it doesn't then in my opinion that is the bug here) it shouldn't be a problem. Also the original patch used the words "technical issues" - this to me suggests the site itself is having problems and it is not obvious it is actually related to some MediaWiki code constraint. The word 'standardise' seems more applicable here. Please re-think about mobile when rewriting this patch. Warnings about changed usernames shouldn't require the user to re-fill the entire form.
Change 117234 merged by Cmcmahon: Revert "Warn on account creation when username is adjusted" https://gerrit.wikimedia.org/r/117234
Change 117247 had a related patch set uploaded by Bartosz Dziewoński: Revert "Revert "Warn on account creation when username is adjusted"" https://gerrit.wikimedia.org/r/117247
(In reply to Jon from comment #6) > Out of interest why does this matter? I seem to have missed the problem > here. > > If I register with the username "an unusual username" and it gets corrected > to "An unusual username" in my opinion as long as if I login with username > "an unusual username" and it still logs me in as that user (if it doesn't > then in my opinion that is the bug here) it shouldn't be a problem. What if you register "this__is__my__username" and it gets corrected to "This is my username"? Also, when a username is canonicalized, it is passed through $wgAuth->getCanonicalName(), which could do literally *anything* to the username depending on what authentication extension you have installed.
(In reply to Tyler Romeo from comment #9) > (In reply to Jon from comment #6) > > Out of interest why does this matter? I seem to have missed the problem > > here. > > > > If I register with the username "an unusual username" and it gets corrected > > to "An unusual username" in my opinion as long as if I login with username > > "an unusual username" and it still logs me in as that user (if it doesn't > > then in my opinion that is the bug here) it shouldn't be a problem. > > What if you register "this__is__my__username" and it gets corrected to "This > is my username"? This is part of the problem. This is basically the first time I've heard this brought up. On the Design list where this was brought up, I don't think anyone shared a list of everything canonicalization currently does? On top of that, no one knows how often any of these cases *actually happen*. It's entirely possible that hundreds of thousands of new account creators register with lowercase via mobile, and less than 1,000/year do with underscores. Or the opposite. Or neither. We don't know. The fact that the problem is partially undefined and definitely unmeasured makes it difficult for people who care about having a clean, not annoying user experience accept that we should throw additional warnings and barriers at so many users during a critical step. > Also, when a username is canonicalized, it is passed through > $wgAuth->getCanonicalName(), which could do literally *anything* to the > username depending on what authentication extension you have installed. We can't design a case for "literally anything". We can only design for what we might reasonably think would happen to users.
Why don't we just show the user a notice *after* the account has been created whenever a username has been canonicalized? IMO, canonicalization should not be something that we interrupt the user about. It should just be something that we notify them of after the fact.
(In reply to Tyler Romeo from comment #9) > What if you register "this__is__my__username" and it gets corrected to "This > is my username"? I tried logging in as nemo________bis and it worked just fine.
(In reply to Steven Walling from comment #10) > We can't design a case for "literally anything". We can only design for what > we might reasonably think would happen to users. The fact remains that it's very possible the username can change to something significantly different. If you're suggesting we restrict the $wgAuth interface, then that's an entirely different issue. (In reply to Nemo from comment #12) > I tried logging in as nemo________bis and it worked just fine. Indeed. My point exactly.
Change 117348 had a related patch set uploaded by Kaldari: Revert "Warn on account creation when username is adjusted" https://gerrit.wikimedia.org/r/117348
Change 117348 merged by jenkins-bot: Revert "Warn on account creation when username is adjusted" https://gerrit.wikimedia.org/r/117348
(In reply to Ryan Kaldari from comment #11) > Why don't we just show the user a notice *after* the account has been > created whenever a username has been canonicalized? If I register as "mzmcbride", I want the opportunity to change my username to something other than "Mzmcbride", which looks stupid and isn't what I specified. The "first letter is auto-capitalized" rule is a trick on the user and is completely unexpected. It's only fair to give warning _prior_ to account registration. I could have sworn I already made this exact point somewhere else. I wonder where that discussion went.
(In reply to MZMcBride from comment #16) > (In reply to Ryan Kaldari from comment #11) > > Why don't we just show the user a notice *after* the account has been > > created whenever a username has been canonicalized? > > If I register as "mzmcbride", I want the opportunity to change my username > to something other than "Mzmcbride", which looks stupid and isn't what I > specified. The "first letter is auto-capitalized" rule is a trick on the > user and is completely unexpected. It's only fair to give warning _prior_ to > account registration. That's the thing though. The user can't register a lowercase username. Or one with underscores. Or ones with trailing whitespace. If the user can't change their name to get those things, there is no point in telling them so. You're not warning them about things they can control. You're just throwing information at them they can't really act on, other than to not register or pick a completely different username which will be subject to the same rules.
Sounds like you want a preference to change how your name is displayed....
FWIW I think all usernames should be case insensitive and I think it's a terrible design oversight that we support case sensitive usernames. The username Jdlrobson should be the same as jdlrobson and should be the same as JdlRobson in a username lookup. I think this is a huge bug (I'm not sure if it has previously been raised). If I want it to appear as Jdlrobson or JdlRobson or Jon Robson when viewed that's a different story that I can get behind.
(In reply to Steven Walling from comment #17) > That's the thing though. The user can't register a lowercase username. Or > one with underscores. Or ones with trailing whitespace. If the user can't > change their name to get those things, there is no point in telling them so. > You're not warning them about things they can control. You're just throwing > information at them they can't really act on, other than to not register or > pick a completely different username which will be subject to the same rules. The point he's trying to make is that mzmcbride is a good username, so is MZMcBride, but Mzmcbride looks stupid. It's not that usernames are uniformly lowercase or uppercase; only the first letter is changed to be uppercase. This can cause problems, especially since, like I mentioned, $wgAuth->getCanonicalName() can actually change the username more (for example, LdapAuthentication actually makes the entire name lowercase).
(In reply to Steven Walling from comment #17) > That's the thing though. The user can't register a lowercase username. Or > one with underscores. Or ones with trailing whitespace. If the user can't > change their name to get those things, there is no point in telling them so. I think you're missing the point. If I want to register as "mzmcbride" and I know that my account name will be "Mzmcbride" (which makes absolutely no sense as an end-user and completely contradicts expected behavior from other sites such as GitHub or Twitter or ...), I might choose "MZMcBride" or something completely different. I don't need to be the one to reiterate the importance of user account names in user identity, do I? I'm not sure what kind of evidence you and Jon are looking for that this is a problem. Have you two looked at user rename requests on any wiki? Rename requests are a fairly common symptom of this problem.
Jon: you're raising perfectly valid points, but they're outside the scope of this bug report. If you're interested in a user.user_display_name field or in case insensitivity of usernames, please file separate bug reports, if such bug reports don't exist already. Regarding this bug report, I think there's clearly sufficient evidence that the current behavior is unexpected. I think providing warning prior to account registration is a sufficient and acceptable solution. If you disagree, please explain why (setting aside any particular mobile implementation flaws).
I don't think they are out of scope. It seems to me that your issue is that you register as "mzmcbride" and now you see "Mzmcbride" in the interface and this bothers you. If you login and treat your username as "mzmcbride" for the rest of your life you can still login. It's just the fact when you see it in the interface it bugs you no?
Also to be clear, for the xth time there is no "mobile flaw " here, there is a fundamental issue with this patchset. Without JavaScript it gives a crappy experience and the entire form is flushed. Simply drop the check for non-Javascript users and make the change silently for these users and you will make me happy.
(In reply to Jon from comment #24) > Also to be clear, for the xth time there is no "mobile flaw " here, there is > a fundamental issue with this patchset. Without JavaScript it gives a crappy > experience and the entire form is flushed. Simply drop the check for > non-Javascript users and make the change silently for these users and you > will make me happy. And again I disagree. The user creation form does not flush the entire form. If you look at includes/templates/Usercreate.php, all the fields have default values of whatever was already submitted to the form.
Tyler.. I'm not sure what to say. Evidence suggests otherwise... With JS disabled... Exhibit A: Before: http://imgur.com/SOO7Es9,rtMZvCS#0 After: http://imgur.com/SOO7Es9,rtMZvCS#1 I now have to reenter the captcha and retype my password twice on account of title casing my username. Not cool - maybe enough to put someone off registering - all for the sake of a capital letter. On mobile the email also gets reset (probably a bug) but still the experience is as bad as desktop... typing on a phone keyboard is not fun: Before: http://imgur.com/5wihjEt,ZHdvf8m#0 After: http://imgur.com/5wihjEt,ZHdvf8m#1
First off, wanted to thank everyone who's been working on trying to improve this. I wanted to try to clarify where I think the problem exists and maybe try to reach a solution that addresses the problem more abstractly. In systems which distinct user names are required there is a high probability that a user name may be taken already On foundation wikis there are both policies and extensions which attempt to prohibit the selection of certain user names due to similarity with other user names, prohibited characters, structure of name (no email addresses) and other rules that establish what a user name can and cannot be. These are both real issues, and can't really be "solved" per se. There are other issues, for example, mediawiki’s current inability to resolve user names irrespective of their capitalization The need for usernames to start with an initial capital. These are issues that can be changed, not to say that they are simple or easy to change, but they are changeable. Penalizing users, making user flows more difficult or doing anything that causes account creation to be harder than it already is (CAPTCHAs, complex name rules, lack of federated login and asynchronous validation of errors in the forms) is a misstep we cannot afford. While I respect the goals of this work, I feel the execution causes more issues than it solves.
Change 117247 abandoned by Bartosz Dziewoński: Revert "Revert "Warn on account creation when username is adjusted"" Reason: I'm going to split and rework this a little bit. https://gerrit.wikimedia.org/r/117247
Change 117438 had a related patch set uploaded by Bartosz Dziewoński: Check normalization rules of usernames during signup via AJAX https://gerrit.wikimedia.org/r/117438
Re comment 19 and comment 22 and others, I filed bug 62396 "Usernames should be case-insensitive". We have some related, bug slightly different ones (e.g. bug 26396), I couldn't find a duplicate.
(In reply to Steven Walling from comment #10) > (In reply to Tyler Romeo from comment #9) > > What if you register "this__is__my__username" and it gets corrected to "This > > is my username"? > > This is part of the problem. This is basically the first time I've heard > this brought up. On the Design list where this was brought up, I don't think > anyone shared a list of everything canonicalization currently does? I'm afraid this is not cleanly documented anywhere, and these things are too many to sanely list. The parts that could reasonably be encountered by normal people ;) are I think underscores → spaces, capitalization, and removing excess spaces. For details, see Title::newFromText() and Title::secureAndSplit() (a total of around 200 lines of rather well-commented code). > On top of that, no one knows how often any of these cases *actually happen*. > It's entirely possible that hundreds of thousands of new account creators > register with lowercase via mobile, and less than 1,000/year do with > underscores. Or the opposite. Or neither. We don't know. > > The fact that the problem is partially undefined and definitely unmeasured > makes it difficult for people who care about having a clean, not annoying > user experience accept that we should throw additional warnings and barriers > at so many users during a critical step. Would it be possible to measure that? Could we do it?
bug 64728 was created for checks in CentralAuth
Change 117438 abandoned by Bartosz Dziewoński: Check normalization rules of usernames during signup via AJAX Reason: Sorry, I'm not very keen on rewriting this. Maybe someone else wants to pick it up? https://gerrit.wikimedia.org/r/117438
