On Thu, Mar 13, 2008 at 12:11 AM, DanTMan <dan_the_man(a)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.