Mkay, D it is... getName will be depreciated... To go with the whole key/real namescheme I've been going with in Title.php a new getRealName function will get the name to use for interface display. And to match that, getKeyName will get the name for use in uniqueness checking and comparison, and getName will be aliased to it.
^_^ Actually about your note on User and Title normalization not being the same. There is no real reason for them not to be (With the exception of the stuff that we stick in functions like isValidName)... Why's that? A little bonus I already theorized but never mentioned (I'm good at grasping a lot of theory and wrapping my mind around how things work and are supposed to, so I get a lot of them) Because of the new extensible normalization, and how all the username stuff relies on getDBkey and directly uses getText for displaying the username, there is a little bonus. If you go and extend the normalization of Titles specifically for the User: namespace (remember that because of the way it's setup, you can now create per-namespace normalization), the normalization of Usernames will be directly affected by it (Which is kinda why I needed to alter User.php because of that login bug). So, if you go and make the User: namespace completely case-insensitive and leave other namespaces the way they are, the Usernames will suddenly all become completely case-insensitive to match that, without altering any normalization code for usernames.
Btw: I have a function inside of the normalizer. TitleNormalizer::backconvert( $title ); basically it does the normal replacing of underscores with spaces. The point of it is for when we don't have a page_real stored in the database (ie: nonexistant page), then backconvert will be used to create a temporary title for displaying while the page doesn't exist. Of course, there is a hook inside of it which lets extensions override it in case they do something like changing the ' ' to '_' normalization to ' ' to '-' for some reason.
Heh, I guess I'll take a look at that log stuff sometime later to see how easy it will be.
~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)
Simetrical wrote:
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.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l