On Sat, Mar 8, 2008 at 10:34 PM, DanTMan dan_the_man@telus.net wrote:
We've got a few options here: A) Create a new function getTitle which returns the title object which the User matches, and make use of it's functions for the standard displays and other things. Of course this is bascialy the same as getUserPage.
I don't like this. There's no reason username normalization can't be stricter than title normalization, for instance. (It had better not be less strict, of course, if you don't want user page collisions.) In general I don't like mixing up titles with users. Of course in practice the backend may use title normalization for users as well, but that fact should all be hidden in a User method, not exposed to callers.
B) Change getName's definition to be the display form of a user's name, and getTitleKey to be the key form of the user's name. And change the large number of comparison functions inside of MediaWiki to use getTitleKey instead of getName.
getTitleKey sounds like a poor name to me.
C) Create a new function getDisplayName, and have getName's definition changed to the key form of the user's name, and getDisplayName as the display form of the user's name. Depreciate the use of getTitleKey because of it's lack of use or need anymore (changing a single reference to it). And change the uses of getName as a display value inside of MediaWiki to use getDisplayName instead.
getName is then ambiguous: which name are you talking about? getNormalizedName or getNameKey or something would be better.
D) Create two new functions for the key and display forms of the user's name. And depreciate the old functions, slowly changing use of them to the new functions in MW to keep compatibility.
. . . so I would go for (D).
I'm probably in favor of C, as if it's definition is changed to key form, all the backend testing and stuff will still work fine, and we then will only need to worry about changing the areas that the username is used for display. Which won't really be a problem if we miss anything, because if we end up missing one conversion, the system will simply be displaying a semi-ugly form with underscores inside of it and none of the case stuff picked by the user. And it'll still be likable and won't break anything in the backend.
Your logic is good, and applies equally to (D): alias getName to getNormalizedName or whatever, rather than getDisplayName.
Oh, ^_^ an interesting new ability due to switching to key form: SELECT user_editcount FROM `user`, `page` WHERE user_name=page_title AND page_namespace=2 AND page_id=3 In this example, page_id 3 is the userpage of my user's userpage. What does it do? Well, if you were on the userpage of a user and just had the page ID, you could now easily grab any information from the database on that user himself because page_name and user_name are stored in the same format instead of different formats.
Interesting. Of course, my suggestion above that we don't rely on user and title normalization being the same would break this. I don't know if there's any good reason to go either way here.
Oh, minor off topic. But what about putting a log_user_text in at some point. Honnestly I know of a few extensions which intended to allow certain things to be done by anons in addition to normal users, but which broke when anons were allowed use of them because anon users were not properly logged.
Yes, please! That's been to-do for ages.