NS_USER is hardcoded to be uppercase-only. (see MWNamespace::$alwaysCapitalizedNamespaces)

This could maybe be changed one day, but I remember there being a lot of problems when I tried.

CobraSA wrote:

But in the manual it says $wgCapitalLinkOverrides can be used for User.

Then we should update the manual :)

CobraSA wrote:

where can I request the feature for lower cased user names please?

(In reply to comment #4)

where can I request the feature for lower cased user names please?

Changed this bug to a feature request.

Note to any future implementers: this is non-trivial because it includes support for first-letter lowercase user names as well.

CobraSA wrote:

Well it's no longer necessary it has been filed as a bug and should be fixed eventually.

CobraSA wrote:

Who changed to enhancement? It's a bug.

Do you have a use case for this?

CobraSA wrote:

Some titles need lower case enabled, example xXx a japanese anime

(In reply to comment #9)

Some titles need lower case enabled, example xXx a japanese anime

A use case for why user names, not titles in general, need to start with a lower case letter.

Sure I suppose if you wanted to be user:xXx after the japanese anime thingy, that'd be a use case, but I wouldn't consider it a very pressing one given that the number of people who want to pick usernames of proper nouns starting with a lowercase letter is low, and you can have customizing sigs/ {{displaytitle}} for those few exceptions who do want to do that.

CobraSA wrote:

Some members have a nickname similar xXx, and they don't like being XXx in my wiki, it removes the relevance of first letter not being capitalized. For example eBay23, iPod7... Yes some member actually have such nicks.

EN.WP.ST47 wrote:

Recategorize, as this appears to be a feature request, not a bug.
1.16 -> 1.19-svn
Normal -> Low
Major -> Enhancement
Summary -> "Allow uncapitalized user names and User: pages"

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

Copied from bug 48640 description:

<route> i've just modded 1.20.5 to permit all lowercase usernames, to do this
i've removed NS_USER from the $alwaysCapitalizedNamespaces array in
Namespace.php and i've removed calls to $wgContLang->ucfirst( $name ) in
User.php. i've created a user and it seems to have worked as i'd expect -- is
there anything i might be overlooking that could cause problems in future?

This was first allowed when the feature was implemented (r57558), then
disallowed back (r57559, r58401, r60063) with unclear comments about MediaWiki
crashing. This was back in 2009, though, and a lot might have changed.

elliotbrown2 wrote:

This may not be a bug for Wikimedia, but for sites using an auth extension with a forum or other user database which allows lowercase names it causes all sorts of problems (user rights not working for lcfirst users, users being told their account does not exist when trying to edit their user page). We're considering hacking the core, as annoying to keep updated as that will be, and the user from the duplicate bug above has already resorted to this.

I would like to request this is recategorized as a bug with higher importance than low since generates bugs for significant use cases, I've already run into it on three wikis I work on (one accepted the bugs, one gave up on SSO, and one is making a system which lcfirst names be shown to the wiki as ucfirst, making users names inconsistent across the site).

elliotbrown2 wrote:

On second thoughts, this could well be classed as a bug for Wikimedia sites as well as installations wanting to integrate users who already have lowercase first names. A new user registering with a lowercase first username will have their first experience as a new editor being mediawiki changing their name, which is kind of uncomfortable, especially for users such as myself who have used a lowercase first username on many sites and are quite fond of having it displayed the way we intend it to be. It's not an ideal first impression for an editor to have the software alter your username for unclear reasons.

Its extraordinarily unlikely that wikimedia sites will allow lower case usernames unless we get a compelling reason (which hasn't happened). However this is filed as a "MediaWiki" bug, not a Wikimedia one, so that is irrelevant.

I would like to request this is recategorized as a bug with higher importance

So far the general amount of complaints don't warrant that.

we're considering
hacking the core, as annoying to keep updated as that will be, and the user
from the duplicate bug above has already resorted to this.

If you're sure your patch won't break anything (and have a convincing argument that you've checked it won't cause anything to blow up), consider submitting a patch.

elliotbrown2 wrote:

Is allowing users to have the username they desire displayed as they are accustomed not at least a little compelling, even if not much of a priority on its own?

Even if not classed as higher priority, do you think that at least for sites trying to integrate existing users via an auth plugin not being able to display usernames correctly and opening up the risk of username conflicts (if the existing user database has two users, one with lowercase first and one with uppercase first, but otherwise same name) is be enough justification to class this as a bug? I'm not familiar with the policies around here as to what counts as a bug and feature request, but making it easier to properly support integrating mediawiki into other sites with SSO seems like something which should be a goal, and things which get in the way of that like this feel to me like bugs.

And speaking to our programmer, for now we're likely to just take the easy option and feed MW names forced to upper case, which will work but mean users with lcfirst on the rest of the sites have their usernames displayed inconsistently. Not a huge issue, but a bit of a hassle to have to set this up for a site encountering it, and a slightly uncomfortable thing to have in the long term for users who prefer lcfirst. Fixing it properly is a lower priority than quite a few other things for us right now, and if the patch ends up not being accepted it means reapplying the changes every time we update and the possibility of changes to the core making it incompatible. If we do get to this I'll post what we change here, but it'd be good to have some attention from people more familiar with MWs code to look into this and direct us towards any places other than those mentioned in the recently closed duplicate bug (he pastebinned his code changes, it expired and was not copied over, but the google cache was still live which I've re pastebinned here http://pastebin.com/JVxvhnhf ) which need changing for a way to turn this behaviour off to be added without problems.

Created attachment 12648
Contents of http://pastebin.com/JVxvhnhf

Adding contents of the pastebin as an attachment just in case.

Attached:

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

Quoting from #wikimedia-dev short discussion about this today:

<^d> I shouldn't have enforced NS_USER to be always-uppercased when I did the namespace casing stuff years ago.
<^d> It was based on flawed assumptions at the time.

Merging down rather than up.

• This bug has been marked as a duplicate of bug 1574 ***

mails2vichu wrote:

Im interested in this bug.Please assign it to me

Unduping because it's not a dupe. Other bug is a WMF bug (which should probably be wontfixed IMHO)

(In reply to comment #23)

Im interested in this bug.Please assign it to me

You can always submit a patch. Considering comment 1, though, for your first patch you probably don't want to start with something as hard as this.

mails2vichu wrote:

So its not better to try with this?

(In reply to comment #26)

So its not better to try with this?

You are welcome to try to fix any bug you want. The worst case scenario is that your patch gets rejected. With this bug you would have to test very carefully that you don't break anything.

The bugs on this list https://bugzilla.wikimedia.org/buglist.cgi?keywords=easy&resolution=---&list_id=261001 might be better choices as a first bug.

mails2vichu wrote:

Thank you sir..Can you please pass on your mail id please?

(In reply to comment #28)

Thank you sir..Can you please pass on your mail id please?

All bugzilla mail addresses are public. The link for the username is an email address. However for anything about the bug please just leave comments publically on the bug.

It's also an annoyance to me as well as my current user name is supposed to start with a small letter

You can use the {{lowercase}} template on your user name, which will ensure that the first letter is displayed lowercase on your user page at least. This uses the {{DISPLAYTITLE}} magic word. See https://web.archive.org/web/20190410170303/https://en.wikipedia.org/wiki/User:cscott .

*However*, there are a number of places this doesn't work:

• Urls of subpages, eg https://web.archive.org/web/20190410170303/https://en.wikipedia.org/wiki/User:cscott
• In the login banner at the top of the page
• In revision history, eg https://web.archive.org/web/20190814162140/https://en.wikipedia.org/w/index.php?title=User:Cscott/Ideas&action=history
• In signature expansion (~~~~)

These could be addressed one-by-one to improve the appearance for folks with lowercase usernames.

In my case, it became a problem when I integrated the wiki into the domain (in the lab for now).

I had taken care to create the same accounts as in AD, but what I didn't realize was that they had them all written
in uppercase (Windows doesn't care), while in the wiki only the first letter is capitalized, then the accounts are duplicated.

So I'm wondering what would be the most efficient method to integrate or merge the accounts?