Quoting bug 61416, which started this discussion:

(Jon from bug 61416 comment #19)

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).

(MZMcBride from bug 61416 comment #22)

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.

However (for anyone unfamiliar), there are already clashing accounts which are exactly the same other than case.

So for existing wikis, this requires a way to resolve those conflicts (and different wikis may want different rules for this). That means it probably has to be a config option, potentially defaulting to case-insensitive for new wikis.

For the WMF specifically, *if* we want to transition to this, we should probably do so at the same time as single login finalization (https://meta.wikimedia.org/wiki/Single_User_Login_finalisation_announcement). That way's there's only one huge "lots of usernames changed" event.

However, bear in mind this would increase the complexity of the SUL finalization process. Also, case-insensitive does not mean the same thing in every language, and it's not the same as "just lower case them both then compare them".

(In reply to Matthew Flaschen from comment #2)

However (for anyone unfamiliar), there are already clashing accounts which
are exactly the same other than case.

So for existing wikis, this requires a way to resolve those conflicts (and
different wikis may want different rules for this). That means it probably
has to be a config option, potentially defaulting to case-insensitive for
new wikis.

This naturally can be the case, and we will naturally have to provide such a upgrade path for wiki owners (and yes, probably keep the case-insensitivity off by default, or only enable it if we can confirm there are no conflicts somehow).

Still I'd risk a guess that this won't be a major issue – especially on WMF sites, as these have the AntiSpoof extension enabled, which blocks the creation of such conflicting usernames already.

Also, case-insensitive does not mean the same thing
in every language, and it's not the same as "just lower case them both then
compare them".

Well, I think it actually is, but it's the lowercasing part that's difficult :) We have luckily solved the issue already in our Language class, so regular wikis won't have any issues (just use the wiki content language for comparison). We'll have to come up with something cleverer for multi-language farms with shared users (like WMF wikis), though.

(In reply to Bartosz Dziewoński from comment #3)

Also, case-insensitive does not mean the same thing
in every language, and it's not the same as "just lower case them both then
compare them".

Well, I think it actually is, but it's the lowercasing part that's difficult
:)

No, there are cases where lowercasing them both them comparing is probably not the desired behavior.

For example:

mb_strtoupper( 'ς' ) === mb_strtoupper( 'Σ' ) === 'Σ'

Thus, most people would probably consider 'ς' and 'Σ' equal ignoring case.

However:

mb_strtolower( 'ς' ) -> ς
mb_strtolower( 'Σ' ) -> σ

so a simple lower-case (even a multi-byte one), then a binary compare will not work.

Yes, the right way is to 'casefold' them and then compare. In core, we have a Language#caseFold method, used in a few places, which seems to just uppercase the string – I'm going to assume that this is the proper way to do this, and if it's not for some reason, please file a bug or submit a patch. :)

elliotbrown2 wrote:

Making this non-optional could break a lot of third party use cases. If a wiki has a SSO with a forum or blog or whatever which allows EXAMPLE and Example to exist as separate users, which at best massively complicates SSO code with handling for clashes and determining which user to allow plus stops some users from signing into the wiki, and at worst could let users block eachother from the wiki by creating duplicate accounts and registering first due to SSO code with first come first served policies, or even open the door for taking admin credentials by duplicating an account if the SSO is custom by someone who does not know how to create the complex checks on usernames.

Similar issue to lowercase first usernames in general really, but considerably more likely to come up, and ideally that would get fixed rather than added to.

Why in the world would wiki Everything allow or require case sensitivity in usernames? It can and probably Has lead/led to impersonation and fraud issues. In the brilliant world of unix compliancy, usernames have always been lowercase or case insensitive for the most obvious of reasons. This is a High priority technical bug that needs fixing ASAP.

This isn't a bug, it is by design. This is a feature request that some people want, and that is fine. If you want to claim and work on proposed patches for this, that is certainly fine as well - and then you can prioritize it in your workflow.