On Thu, Mar 13, 2008 at 12:11 AM, DanTMan dan_the_man@telus.net wrote:
I'm not a fan of "Display". While it is used in normal interface it's not necessarily the actual title that will be displayed inside the title header. Remember that there is a third form if the wiki is supporting the upgraded DISPLAYTITLE, which by default will be enabled ^_^ in a semi-neutered state (lol) where it functions like the standard DISPLAYTITLE for backwards compatibility. But over top of that, there are many wiki which are likely to enable an option or an extension which allows less strict display titles, as well as some purely extension driven ones.
So, I think Display should be reserved for what goes inside of the header, rather than the un-normalized name of the title.
Okay, reasonable.
So potential words: (Normalized form for inside the database) Key, DB Key, Unique, Normalized (Non-Normalized form for interface use) Real, Text, Interface, Display, UI, UnNormalized (Format generated by extensions or other things for use in the title bar) Display, Generated
Hmm. Nothing leaps out at me as being the best.
No, @ should never be banned from the namespace. It's ok to make it invalid for creation and use, however it's not ok to kill any User namespace title using it. Remember that some things like the idea of Transwiki imports appending the wiki they came from after an @. Those still link to names inside the user namespace. It would be best to keep @ valid so that those can be created with information or such on that user from the other wiki.
I meant generically, that user pages should correspond exactly to usable usernames. This needs to be in a loose sense, I guess: anything that can show up in a user_text field should be valid. That may include cross-wiki usernames, for instance, which could contain @.
Hmmm... well, there are two things to actually consider with the format of the name. . . . Why not kill two birds with one stone? Instead of that, use that input as the actual title. This will even kill the normal confusion that a new editor encounters when they don't know how to create a new page. All you'll need to do is go to any new page with an &action=edit, even using something like http://en.wikipedia.org/w/?action=edit or use http://en.wikipedia.org/w/?action=create to clear it up, type in the title of the page into the input, and save it. Instead of mucking with other stuff, and extensions like the Inputbox. Of course, if that page already exists, then you'll simply get an error telling you it already exists, and you should either edit that page or find a new title.
Now that's an interesting idea. It would solve the problem neatly.
Now as for the redlinks and getting a real form through the url. I'd propose a secondary parameter, something like &titlesuggest= or something. Which a redlink would append to keep the formatting of the current title. As well as extensions like Inputbox could do.
Well, if it's a new action=create, then you can just use the title parameter, since it will be unused.
As for the current existing pages. We would probably leave that out and use Special:Movepage to do actual movement. It's possible that in the future someone could rewrite the edit system and move system to allow for a setup where you can both move, and edit the page text at the same time. However, that is a rewrite in an area which we probably should not attempt inside the scope of the current title rewrite. That can actually be done on it's own later without requiring any work here.
Of course. I don't know if such a thing would be desirable.
Because of that, I went for making use of the LinkCache for the getting of the real title. Of course there are a few issues. Firstly, because this is being stored in the cache, we should NEVER store a user inputed real title. For this reason, before the LinkCache stores the title in it's cache, it actually resets the real title using that database query, and if it doesn't find it, then it backconverts it. So it's not a good idea to use user supplied titles here. So that has two side effects. Firstly, if we were to make it so that the LinkCache just didn't set the real title when it doesn't find one... We are likely to end up with a Wiki error resulting from getText not normalizing to getDBkey at some point. Or even worse, there could be a small possibility of an infinite loop where something which needs that real title may query again until it gets it, which would never happen. Another affect could be the fact that since it does not have a real title stored, the LinkCache would be queried for a new real title every time you call getText or something else which depends on it. This would be a heavy database burden resulting from LinkCache not setting a fallback title. Secondly, just as another result, but if anyone uses getArticleId on your title object, there is the possibility that the real title will be reset. (I've made a warning of this inside the setter, that setter is meant strictly for temporary use where you know what is happening to the title. Primarily it is only used by the LinkCache firstly to actually set the title (Since it isn't from the same object and it's bad practice to externally edit a member variable, that could change names, and also because it would generate PHP errors if we later re-factored things to use actual private variables.), and also will be used when moving a page to set what new real title to move to)
From my detailed look at Title.php there is little other way to do this, which does not have a serious effect on the database, or bad coding which will result in a lot of bugs.
I'm not sure I get what you're saying. I'll have to look this over in more detail later to offer suggestions.